CI/CD Security Gates for Medical Devices: SPDF in Practice

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.

Key Takeaways

• Five build-blocking gates cover the SPDF's enforceable surface: SAST, SCA/SBOM, secrets, container, signed artifacts.
• "Warn-only" gates are not gates. The FDA reads the pipeline configuration, not just the report.
• Every gate output needs a build ID, a commit SHA, a tool version, and a retention policy long enough to outlive the device.
• SBOM generation without SBOM diffing produces a snapshot, not the postmarket monitoring evidence AAMI SW96 expects.
• Threshold tuning (severity gates, exception workflows) is itself an auditable control — document the policy, not just the threshold.
• Gates belong on the merge to main, not the nightly build. A finding that lands in main is already a CAPA candidate.

Table of Contents

• Why CI/CD Gates Are the SPDF's Enforcement Layer
• The Five Gates and Where They Live in the SPDF
• What Each Gate Must Produce as Evidence
• Threshold Policy: How to Decide What Fails the Build
• Common Mistakes That Show Up in Deficiency Letters
• How Blue Goat Cyber Approaches CI/CD Gating
• FAQ

Why This Matters

The FDA's February 3, 2026 final premarket cybersecurity guidance, Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions, expects security activities to be integrated into the design controls under 21 CFR 820.30, 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.

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 the only 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. Reviewers read both — and when they conflict, the pipeline wins.

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

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

See also: SPDF and IEC 62304 Mapping: FDA Cyber Guide, IEC 62304 Classes vs FDA Device Classes: Cybersecurity Impact, and FDA Section 524B Explained Subsection by Subsection: What Each Requirement Means in 2026.

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.

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 not VEX-mapped. Findings without dispositions are deficiency exposure. Map 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.

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 cybersecurity deficiencies after our submission, we resolve them at no additional cost.

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

What CI/CD security gates does the FDA require for a medical device submission?

The FDA does not require specific tools, but the February 3, 2026 final premarket cybersecurity guidance and AAMI SW96 expect objective evidence that security activities ran during development. In practice that means five build-blocking gates: SAST, SCA/SBOM generation, secrets scanning, container/dependency scanning, and signed-artifact verification. Submissions that cite "we run SAST" without artifacts tied to specific builds receive deficiency letters citing insufficient security activity evidence.

Do CI/CD gates replace threat modeling or penetration testing?

No. Gates enforce the activities they can automate — finding known-pattern issues at build time. Threat modeling identifies what to defend; gates verify that specific defenses were not regressed. Penetration testing exercises the system from the outside against the realized device. The three are complementary: gates produce the cadenced evidence, the threat model and pen test produce the depth-of-analysis evidence. A submission needs all three.

Should security gates fail the build or just warn?

Fail the build above the documented severity threshold. A warn-only gate is not a control under AAMI SW96 §7 — it is a notification. Reviewers read the pipeline configuration to verify the gate is enforced, not just the report. The defensible pattern is severity-gated failure with a documented exception workflow (security-lead sign-off, recorded in the pull request, with an expiry date on every waiver).

How long do we need to retain CI/CD security gate evidence?

For at least as long as the device is on the market plus the postmarket reporting window — which for most Class II and Class III devices is the device's full commercial life plus several years. AAMI SW96 §8.4 expects objective evidence retrievable across the lifecycle. Pipeline logs with 90-day retention do not meet this; gate evidence belongs in a content-addressable evidence store with retention policy aligned to the device's commercial life.

How do CI/CD gates relate to SBOM and VEX requirements?

The SCA gate generates the SBOM as a build artifact (CycloneDX or SPDX, with component hashes). The container/dependency scan produces the vulnerability list against the SBOM. VEX dispositions get written as the findings land — not in a batch before submission. Postmarket SBOM monitoring requires diffing today's build SBOM against the last released SBOM to detect drift; the diff itself is evidence the FDA's 2026 guidance expects under postmarket cybersecurity controls.

What about DAST and fuzzing — do those belong in CI?

They belong in the evidence registry but cadence differently from build-time gates. DAST and fuzzing need a deployed target and longer run times, so they typically run on a scheduled job against a staging build rather than gating every PR. The output schema (build ID, tool version, timestamp, findings, dispositions, retention) is the same as the build-time gates. The difference is the trigger and the SLA, not the evidence requirements.

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 cybersecurity deficiencies after our submission, we resolve them at no additional cost. Schedule a discovery call.

---

Christian Espinosa, Founder, Blue Goat Cyber, CISSP, OSCP. 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