SECURE DEV ENVIRONMENT CHECKLIST · MAY 2026

Field Checklist · v1.0

Securing the medical device development environment

A practical checklist for AI-era development in regulated MedTech.

Why this exists

In May 2026, a poisoned VS Code extension (Nx Console) exposed approximately 3,800 internal GitHub repositories. It was live for 18 minutes. Auto-update did the rest.

This is one of several supply chain attacks in 2026 targeting developer workstations, AI coding tools, and MCP servers. For medical device manufacturers, the development environment is part of your evidence chain. If a tool can touch code, credentials, or build workflows, it needs to be governed like any other supplier.

How to use this checklist. Items are grouped by where the control lives. Each section maps to a specific regulatory or industry framework. Use it as a self-assessment or a gap analysis input.

Workstation & IDE hardeningCorporate Cybersecurity / IT Security
AI coding tools & MCP governanceQMS Supplier Management
Build & release integrityEngineering / DevSecOps · QMS oversight
Detection, response & vulnerability managementProduct Security · Corporate IR
Team training & awarenessQuality / HR · Product Security input

Section 01 · Workstation & IDE

01

Section one

Workstation & IDE hardening

Owner: Corporate Cybersecurity / IT Security
Reference: IEC 81001-5-1 §5.1.2 · Development environment security

IDE extension allowlist enforced via central policy (Group Policy, MDM, or equivalent).
Minimum-age policy for new extensions and packages. Recommend 7–14 days to avoid short-window attacks.
Auto-update disabled or gated for IDE extensions, MCP servers, and developer plugins.
Endpoint detection and response (EDR) deployed on all developer workstations.
Credential store monitoring covers 1Password vaults, AI coding tool configs (Claude Code, Cursor, Copilot), cloud CLI tokens, and SSH keys.
Short-lived, scoped tokens replace long-lived personal access tokens (PATs).
Network egress monitoring from developer endpoints with alerting on unusual destinations.
MFA required for all developer identity providers, source control, and cloud accounts.

Example tools Microsoft Defender for Endpoint · CrowdStrike Falcon · SentinelOne · Aikido Endpoint · Snyk Developer Security · Intune / Jamf for policy enforcement.

Section 02 · AI Coding Tools & MCP

02

Section two

AI coding tools & MCP governance

Owner: QMS Supplier Management
Reference: ISO 13485 §7.4 (Purchasing) · JSP v2 §C (Supplier Management) · FDA Premarket Guidance §V

Approved-tool list maintained for AI coding assistants and agents.
Each AI coding tool has documented data handling terms covering what leaves the environment, retention, and training use.
MCP server inventory exists and is reviewed quarterly.
Only verified-publisher MCP servers permitted in production developer environments.
Least-privilege scoping applied: agents start with read-only access; write access is added with explicit guardrails.
Autonomous agents execute in sandboxed environments, not directly on developer workstations.
Data egress rules define what source code and data can be sent to external AI services.
Tool qualification records exist for SAST, SCA, DAST, and vulnerability scanners.
AI-generated code is reviewed by a human before merge, with the AI tool identified in commit metadata or PR labels.

Example tools GitHub Copilot Enterprise · Claude Code · Cursor · Checkmarx One Assist · Snyk Code · Lasso Security (agent inventory) · Arcade.dev (MCP governance).

Section 03 · Build & Release Integrity

03

Section three

Build & release integrity

Owner: Engineering / DevSecOps, with QMS oversight
Reference: IEC 81001-5-1 §7.2 · AAMI SW96 Annex D.3.1 (Supply chain threat scenario) · AAMI SW91 §6.4 (Build and release tools) · FDA Premarket Guidance §V.B (Security Architecture)

Trust boundary documented from commit to signed release artifact in the device threat model.
Build environment isolated from developer workstations; no developer credentials in build.
Code signing uses hardware-backed keys (HSM or equivalent).
CI/CD runners are ephemeral and use short-lived credentials.
SBOM generated automatically in the build pipeline, including build tools and not just runtime components.
VEX (Vulnerability Exploitability eXchange) files produced for known vulnerabilities (FDA expectation as of March 2026).
Reproducible builds implemented where feasible.
Supply chain compromise scenario included in the device threat model, with explicit consideration of dev tool poisoning.

Example tools GitHub Actions with OIDC · GitLab CI · Sigstore / cosign · in-toto · Anchore · Syft / Grype · Dependency-Track · AWS Signer · HashiCorp Vault.

Section 04 · Detection, Response & Vuln Mgmt

04

Section four

Detection, response & vulnerability management

Owner: Product Security, with Corporate IR support
Reference: FDA Postmarket Cybersecurity Guidance · JSP v2 §F (Maintenance) · AAMI TIR97 (Postmarket Risk Management)

Anomalous repository access alerting in place for mass clone, unusual hours, and new geolocation.
Vulnerability monitoring covers the development toolchain, not only device components.
CISA KEV Catalog and NVD monitored with defined SLAs for triage.
Incident response playbook exists for compromised developer credentials or poisoned dev tool.
Credential rotation procedure tested at least annually.
Coordinated vulnerability disclosure process documented (per ISO/IEC 29147).
Postmarket findings feed back into the device threat model and security risk assessment.

Example tools GitHub Advanced Security · GitGuardian · Wiz · Datadog Cloud SIEM · Splunk · CISA KEV feed · NVD API · OSV.dev.

Section 05 · Team Training & Awareness

05

Section five

Team training & awareness

Owner: Quality / HR, with Product Security input
Reference: ISO 13485 §6.2 (Human resources / competence) · FDA QMSR (2026) · IEC 81001-5-1 §6.1

Secure development training required for all engineers, with a refresher at least annually.
AI coding tool usage training covers prompt hygiene, data sensitivity, and review obligations.
Supply chain attack recognition covers poisoned extensions, malicious packages, slopsquatting, and prompt injection.
MCP server and agent permission concepts covered for any team using them.
Developer-targeted phishing & social engineering training covers fake extension publishers and fake package maintainers.
Onboarding includes the approved-tool list and the process to request additions.
Training records maintained as quality records per ISO 13485.
Tabletop exercise for a "developer workstation compromise" scenario conducted at least annually.

Example tools & programs SANS Secure Coding · Secure Code Warrior · AppSec Engineer · Anthropic and OpenAI usage policy training · internal lunch-and-learns on recent incidents.

FDA eSTAR Submission Mapping

06

Appendix

Mapping to FDA submission documentation

The controls in this checklist directly support the cybersecurity attachments in an eSTAR submission. Use this table during pre-submission planning to confirm each attachment has supporting evidence from the relevant section.

Checklist section	eSTAR attachment
1, 5	Secure Product Development Framework (SPDF) documentation
2	Cybersecurity Risk Management Plan · Supplier Management Records
3	Security Architecture Views · SBOM · VEX
3, 4	Threat Model · Security Risk Assessment
4	Postmarket Cybersecurity Management Plan · Vulnerability Communication Plan
5	Personnel competence records (QMS)

Self-assessment

Walk the list with the owner named in each section. Tick boxes that are fully implemented; flag partials for a follow-up gap analysis.

Pre-submission readiness

Pair each ticked control with the eSTAR attachment it supports. Unticked rows become the cybersecurity work plan for your next submission.