CI/CD is most useful for CRA readiness when it converts product security requirements into repeatable engineering checks and preserves evidence. The pipeline should not automatically replace human security decisions, especially where findings need risk interpretation or an exception must be approved.
CI/CD Is an Implementation Mechanism, Not a CRA Requirement
The Cyber Resilience Act does not require manufacturers to adopt continuous integration or continuous delivery. It requires security outcomes, risk-based development and effective and regular testing and review. CI/CD can support those obligations by making selected security controls repeatable whenever code or product artefacts change. ENISA's Secure by Design and Default Playbook is expressly designed to apply repeatable actions to existing engineering, product and release processes, which makes CI/CD a natural implementation point for many software products.
- Do not describe CI/CD itself as legally mandatory.
- Use pipelines to automate relevant security controls.
- Connect checks to product security requirements.
- Keep manual review where risk interpretation is required.
Start With Controls That Already Have Clear Pass or Fail Conditions
Pipeline automation works best where the expected security result can be evaluated consistently. Examples include prohibited secrets, known vulnerable dependencies above an approved threshold, failed security regression tests, missing signatures or unexpected configuration. More complex questions, such as whether a vulnerability is exploitable in the product context or whether residual risk is acceptable, may still require human review. The pipeline should therefore automate repeatable evidence while routing ambiguous security decisions to appropriate owners.
- Automate deterministic security checks first.
- Define clear pass or fail conditions.
- Send ambiguous findings for human review.
- Avoid pretending that every security risk can be reduced to one score.
Run Static Analysis Close to the Code Change
Static application security testing can run during pull requests or builds so developers receive findings while the relevant change is still fresh. High-confidence rules can block a change, while lower-confidence findings can create review tasks rather than stopping every build. The important design decision is not merely whether SAST exists, but which findings matter, who owns them and how unresolved findings affect release approval.
- Run SAST during pull requests or builds.
- Tune rules to the supported technology stack.
- Define blocking thresholds carefully.
- Preserve relevant results for the release candidate.
Use Software Composition Analysis for Dependency Control
Software composition analysis can identify dependencies, versions and known vulnerability information during builds. Pipeline checks can prevent introduction of prohibited packages, identify unsupported components or flag severe vulnerabilities for assessment. A vulnerability database match should still be evaluated in product context because presence does not automatically establish exploitability. The CI/CD process should connect relevant findings to the manufacturer's vulnerability-handling workflow rather than simply producing warnings that nobody owns.
- Identify dependencies and versions.
- Flag known vulnerabilities.
- Define ownership for dependency findings.
- Assess exploitability in product context.
- Track remediation across relevant branches and versions.
Secret Scanning Should Run Before Sensitive Values Reach Release
Secret scanning can detect credentials, tokens, private keys and other sensitive values accidentally committed to repositories or configuration. Pipeline controls can reject obvious secrets before they become part of a distributed artefact. If a real secret has already been committed, the response should include rotation or revocation where appropriate because deleting the visible value from the latest commit does not necessarily eliminate the exposure.
- Run secret scanning on relevant repositories.
- Block high-confidence secret findings.
- Investigate suspected false positives.
- Rotate or revoke exposed secrets.
- Keep sensitive signing material outside ordinary source control.
Run Security Regression Tests Automatically
Important security tests can be added to the normal automated test suite. These can include unauthorised access checks, malformed input handling, update-signature rejection, privilege-boundary tests and tests created after previous vulnerabilities. Running them repeatedly reduces the chance that a later code change reintroduces a known weakness. Security regression is particularly useful because it turns earlier incident and vulnerability lessons into permanent engineering controls.
- Automate repeatable negative tests.
- Add tests for important historical vulnerabilities.
- Test authentication and authorisation boundaries.
- Test update validation.
- Investigate security-regression failures before release.
Verify Secure Configuration in the Built Artefact
Source-level checks cannot confirm every property of the product that users actually receive. CI/CD can inspect built packages, container images, firmware images or deployment templates to verify security-sensitive configuration. Checks can confirm enabled services, configuration defaults, permissions, debug features and packaging settings. This provides stronger evidence that secure-default design decisions survived the build and packaging process.
- Inspect the actual release artefact.
- Verify default configuration.
- Check for unexpected debug features.
- Check permissions and exposed services.
- Tie results to the artefact identifier.
Protect the Pipeline Itself
A CI/CD pipeline can become part of the product's security boundary because it may hold signing keys, deployment credentials and authority to create release artefacts. Manufacturers should therefore protect pipeline permissions, runners, secrets, branch controls and release credentials. Unauthorised modification of a build process can undermine the integrity of otherwise secure source code. Pipeline security should be treated as part of the manufacturer's secure production and release environment.
- Restrict pipeline administration.
- Protect build and signing credentials.
- Control privileged runners.
- Protect release branches or equivalent controls.
- Audit important release actions.
Keep Release Evidence Linked to the Build
CI/CD can create useful CRA evidence automatically if results are retained with the release candidate. A release record can identify the commit or source revision, dependency state, test results, SAST status, secret-scanning status, configuration checks and artefact identity. This makes later technical-documentation work easier because the manufacturer can show which security checks applied to the version actually distributed rather than relying on generic process descriptions.
- Record source revision.
- Record build or artefact identifier.
- Retain relevant security-test status.
- Retain dependency and analysis results.
- Connect the evidence to the released version.
Exceptions Need Governance
A security pipeline should not become impossible to operate when a legitimate exception occurs. At the same time, developers should not be able to bypass security checks silently. A controlled exception can record the failing control, reason for proceeding, risk assessment, approving owner and review or expiry date. This creates a distinction between intentional risk acceptance and accidental disabling of a security control.
- Require documented exceptions.
- Name the approving owner.
- Record the reason and residual risk.
- Use expiry or review dates where appropriate.
- Prevent silent bypass of security checks.
Use CI/CD Outputs as Evidence, Not as the Compliance Conclusion
A green pipeline does not automatically prove CRA compliance. Automated checks cover only the security properties they were designed to evaluate. The manufacturer still needs a cybersecurity risk assessment, product security requirements, appropriate architecture, security reviews and broader testing. CI/CD is most valuable when its outputs provide reliable, version-specific evidence within that larger secure-development system.
- Treat pipeline results as evidence.
- Do not equate a green build with legal conformity.
- Maintain architecture and risk review.
- Keep human approval for material residual risk.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.