---
name: meddev-pipeline-design
description: Define regulated-friendly CI/CD pipelines with compliance checks, artifact management, and auditability for medical device software. Use when working on pipeline design in medical device software.
license: MIT
metadata:
  skill_id: CICD-PIPELINE
  version: 1.1.0
  last_updated: '2026-05-21'
  applies_to: Class A, Class B, Class C
  jurisdiction: Global
  prerequisites: REG-IEC62304, SEC-THREAT-MODELING
  category: ci-cd
---

# CI/CD Pipeline Design for Medical Devices

## Purpose
Define regulated-friendly CI/CD pipelines with compliance checks, artifact management, and auditability for medical device software.

## When to Apply
- Establishing or modifying pipelines for regulated codebases.

## Requirements (testable)
1. Stages: Include lint/SAST, build, unit/integration tests, coverage, package signing, and artifact archival. Rationale: comprehensive verification.
2. Traceability: Capture build provenance (commit, toolchain versions, dependencies) and tie artifacts to requirements/tests. Rationale: auditability.
3. Access Control: Restrict pipeline credentials; separate duties for signing and deployment; no shared secrets. Rationale: security.
4. Artifact Integrity: Sign build artifacts; store immutably with checksums and SBOM. Rationale: integrity and provenance.
5. Environment Parity: Align CI and release build environments; pin toolchain versions. Rationale: reproducibility.
6. Controlled Dev Tools [Class B, C]: Include compilers, assemblers, build scripts, and environment settings that could affect software as configuration items; baseline before verification. Rationale: 5.1.10–5.1.11.
7. Audit Trail: Log pipeline runs, approvals, and results; retain for submissions. Rationale: compliance evidence.

## Recommended Practices
- Use templates for regulated projects with required stages preconfigured.
- Run security scans (SAST/DAST/depscan) regularly; fail on high findings.
- Gate releases on tests/coverage and change control approvals.
- Store SBOM and test/coverage reports with artifacts.

## Patterns
Pipeline stages (concept):
```
stages: [lint, build, test, coverage, package, sign, publish]
```

Provenance record (YAML):
```yaml
build_id: 1234
commit: abcdef
toolchain: gcc-13.2
artifacts:
  - path: fw.bin
    sha256: ...
sbom: sbom.json
tests: [unit.xml, integ.xml]
```

## Anti-Patterns (risks)
- Unauthenticated artifact storage -> risk: tampering.
- Mutable build environments -> risk: irreproducible builds.
- Skipping security scans -> risk: latent vulnerabilities.
- No audit logs -> risk: submission/audit gaps.

## Verification Checklist
- [ ] Pipeline includes lint/SAST, tests, coverage, signing, and artifact archival.
- [ ] Provenance recorded (commit, toolchain, deps) and stored with artifacts.
- [ ] Credentials/secrets controlled; signing isolated; no shared secrets.
- [ ] Artifacts signed/checksummed; SBOM stored.
- [ ] CI/release environments pinned and documented.
- [ ] Pipeline runs and approvals logged and retained.

## Traceability
- Link pipeline runs to change requests/commits and test reports; store build metadata with release.

## References
- IEC 62304:2006+A1:2015, 5.1.10–5.1.11 (development tools under CM).
- `DOC-SCM`, `REG-IEC62304`.
- SLSA (Supply-chain Levels for Software Artifacts) as informative.
- FDA cybersecurity guidance (integrity, SBOM).

## Changelog
- 1.1.0 (2026-05-21): Added 5.1.10–5.1.11 controlled development tools in CI.
- 1.0.0 (2026-01-04): Initial pipeline design skill with stages, integrity, and audit trail.

## Audit History
- **2026-01-04**: Audit performed. Verified:
  - IEC 62304 config/verification expectations correctly referenced
  - SLSA (Supply-chain Levels for Software Artifacts) appropriately marked as informative
  - FDA cybersecurity guidance references accurate