CI/CD Security Gates for Medical Devices

The SPDF is what the FDA expects you to have. CI/CD gates are how you prove you have it on every build, not just the one you put in the submission. Most teams we audit have respectable SPDF documentation and a CI pipeline running half the right tools, but the gates are advisory, the outputs aren't versioned, and there's no traceability from a deficiency response back to the build that produced the evidence. That gap is what becomes a deficiency letter.

Why This Matters

The the FDA's February 3, 2026 final premarket cybersecurity guidance, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions, expects security activities to be integrated into design controls, now ISO 13485 clause 7.3 as incorporated into 21 CFR Part 820 by the QMSR, with objective evidence that the activities actually ran. AAMI/ANSI SW96 reinforces this: the security risk management process must be auditable across the lifecycle, not reconstructed at submission time.

CI/CD gates produce that evidence as a byproduct of building the software. A SAST report tied to a commit SHA and a build ID is exactly the artifact reviewers want to see, what was tested, when, with what tool version, with what findings, and what was done about them. Without gates, the same activities still happen, but they happen in someone's IDE without traceability, and the submission has to reconstruct after the fact what was done. That reconstruction is the gap reviewers exploit.

Official sources: FDA, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (February 2026); CISA Software Bill of Materials resources; NIST SP 800-218, Secure Software Development Framework; FDA, Content of Premarket Submissions for Device Software Functions.

Why CI/CD Gates Are the SPDF's Enforcement Layer

The SPDF defines security activities across the lifecycle: threat modeling, secure coding, vulnerability management, SBOM generation, security testing, postmarket monitoring. Each activity has an owner, an input, and an output. CI/CD is one place in the development workflow where you can enforce that the activity actually ran with the right inputs before the code merges.

Documentation says the team performs SAST. The CI pipeline configuration shows whether the SAST gate is mandatory or advisory. Resolve discrepancies between documented processes and implementation.

The Five Gates and Where They Live in the SPDF

SAST, Implementation phase

Static analysis on every pull request, against the merge target. Findings above the threshold block the merge. Tool version, ruleset hash, and findings JSON are uploaded to the evidence store keyed by build ID.

SCA / SBOM, Implementation, Verification, Postmarket

Software composition analysis produces both the vulnerability list and the SBOM. CycloneDX or SPDX, generated by the build (not by hand later), with cryptographic hashes for each component. The SBOM produced at release is the one the FDA expects in the submission; the SBOMs produced on subsequent builds are what feed postmarket VEX diffing.

Secrets scanning, Implementation

Pre-commit hook plus a pre-merge gate. The pre-commit hook prevents the secret from entering history; the pre-merge gate catches anything the hook missed. A leaked secret that reaches main is a CAPA event regardless of whether it was rotated, the gap in the control is the finding.

Container / dependency scan, Implementation, Verification

For container-shipped devices and for build-environment hardening. Same threshold model as SAST. VEX dispositions for known-but-not-exploitable findings get written into the evidence store the same day the finding lands, not at submission time.

Signed-artifact verification, Release, Postmarket update

Builds are signed; the signature is verified at every promotion step (staging → production → device). The signature manifest is part of the release record. This is the gate that the FDA 2026 guidance V.B.4 (secure update mechanism) reads against, both at premarket review and during any postmarket update incident.

What Each Gate Must Produce as Evidence

[RECOMMENDED PRACTICE] As a recommended evidence-management practice, security activities must produce objective evidence retrievable across the device lifecycle. For a 10-year device, that means the build evidence from year 1 needs to be queryable in year 10.

Every gate output, regardless of tool, needs five things:

1. Build ID + commit SHA, what was tested.
2. Tool name + version + ruleset hash, how it was tested.
3. Timestamp, when (ISO 8601 with timezone).
4. Findings JSON + dispositions, what was found, what was done.
5. Retention metadata, where it lives, for how long, who can purge it.

The evidence store should be content-addressable (hash-keyed) so a deficiency response can cite an exact artifact, not a snapshot that's been overwritten.

Threshold Policy: How to Decide What Fails the Build

A gate that fails on every Low finding gets disabled within a week. A gate that only fails on Critical findings misses the High-severity issues that actually matter. The defensible policy is severity-gated with a documented exception workflow:

• Critical → fails the build, no exceptions.
• High → fails the build, exceptions require security lead sign-off recorded in the PR.
• Medium → does not fail the build, but logged to a tracked backlog with SLA.
• Low / Informational → logged, not blocking.

See also: SPDF and IEC 62304 Mapping: FDA Cyber, IEC 62304 Classes vs FDA Device Classes, and Premarket Cybersecurity in Your QMS: ISO 13485 & QMSR.

The exception workflow itself is auditable. Reviewers look at how many High-severity findings were waived, by whom, with what justification, in the year before submission. A pattern of waivers without justification is a finding.

Common Mistakes That Show Up in Deficiency Letters

• Warn-only gates. The pipeline runs SAST but the job is marked allow_failure: true. Reviewers read the YAML.
• SBOM regenerated but not diffed. Postmarket monitoring requires comparing today's SBOM against the last released one to detect drift. A regenerated SBOM with no diff is a snapshot, not monitoring.
• Gates on nightly builds, not on merge to main. A finding that lands in main is already a CAPA candidate. The gate has to run before the merge.
• Tool version not captured. Two builds with "SAST passed" but different tool versions are not equivalent evidence. The version needs to be in the artifact.
• Exception workflow without expiry. A waiver that has no expiry becomes a permanent acceptance. Waivers need a re-review date.
• Container scan output without assessed dispositions. Findings without dispositions are deficiency exposure. Assess and record them as the build produces them, not in a panic before submission.
• No retention policy. A 10-year device with a 90-day pipeline log retention loses the build evidence the FDA expects to see during a postmarket review.

Need help? Our team supports manufacturers with FDA cybersecurity submissions end-to-end. Explore our medical device cybersecurity services or book a discovery call.

How Blue Goat Cyber Approaches CI/CD Gating

We do not run your pipeline. Your engineering team owns it, they know the build. What we do is design the gate-and-evidence layer your SPDF needs to be defensible: which gates, what thresholds, what evidence schema, what retention, and how each gate output maps back to the SPDF documentation the FDA expects in the submission. We also build the traceability between gate outputs and the threat model entries they verify, so a reviewer can follow any finding from the SBOM back to the attack path it relates to.

Our team holds CISSP, OSCP, and prior military red-team credentials. We have built the gate-and-evidence layer for Class II and Class III connected-device submissions. If the FDA raises a cybersecurity question, we answer it at no extra cost until the cybersecurity portion is closed.

To build these controls in from the start, see our secure product design consulting.

Inline CTA

If your CI pipeline runs SAST and SBOM but you cannot cite the build that produced the evidence in your last submission, you have a deficiency exposure today. Schedule a 30-minute discovery call and we will tell you what reviewers will see.

FAQ

Ready to make your CI pipeline the SPDF's enforcement layer?

If your SPDF documentation describes security activities your pipeline does not enforce, your submission has a documented gap. We design the gate-and-evidence layer that makes the SPDF defensible, and we stand behind it. If the FDA raises a cybersecurity question, we answer it at no extra cost until the cybersecurity portion is closed. Schedule a discovery call.

Christian Espinosa, Founder, Blue Goat Cyber. Christian has led premarket and postmarket cybersecurity programs for connected medical devices across Class II and Class III submissions and previously commanded military red-team operations. Read more at christian-espinosa.

Related SPDF reading

• Pillar guide: Medical Device Cybersecurity SPDF Playbook
• SPDF Cybersecurity Documentation: What FDA Reviewers Expect
• SPDF and IEC 62304 Mapping for Medical Device Cybersecurity
• SPDF vs SSDLC: What Medtech Teams Get Wrong
• SPDF vs TPLC in Medical Device Cybersecurity

More on this topic

• IEC 62304 Classes vs FDA Device Classes