This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

Build and Deploy Tasks

The Cyber Reslience Act for Build/Deploy CI/CD Steps: Phase 2

1: Artifact Integrity and Secure Distribution - Build and Deploy

2: Release Security Validation - Build and Deploy

3: SBOM Genearation and Management - Build and Deploy

4: Technical Documenatation and Evidence - Build and Deploy

Achieving Build and Deploy Tasks of the The Cyber Reslience Act

The European Union Cyber Resilience Act (CRA) establishes cybersecurity requirements for products with digital elements throughout their lifecycle. During Build and Deploy, organizations should validate product security, generate and maintain Software Bills of Materials (SBOMs), protect software artifact integrity, and collect the technical evidence necessary to demonstrate compliance.

This phase focuses on ensuring that software releases satisfy applicable cybersecurity requirements before they are distributed or placed on the market. By integrating security testing, vulnerability scanning, SBOM generation, artifact verification, and evidence collection into CI/CD workflows, organizations can identify security weaknesses, prevent the release of insecure artifacts, and establish traceability between source code, builds, releases, and deployed products.

The following activities map CRA requirements to actionable CI/CD practices and suggested open-source tools. The tools are illustrative and are not mandated by the regulation.

1 - Artifact Integrity and Secure Distribution - Build and Deploy

Artifact Integrity and Secure Distribution for Build and Deploy Activities.

Artifact Integrity and Secure Distribution - Phase 2: Build and Deploy

Objective: Protect software artifacts against unauthorized modification and establish secure mechanisms for distributing products and security updates.

The CRA requires manufacturers to protect the integrity of products with digital elements and provide mechanisms for securely distributing security updates. These requirements help ensure that software received by users has not been tampered with and that product updates can be delivered securely.

During Build and Deploy, DevOps teams should establish controls that verify the authenticity and integrity of software artifacts as they move through build pipelines, artifact repositories, distribution channels, and deployment environments.

Artifact signing, cryptographic verification, software supply chain attestations, and deployment policy enforcement can support these objectives. Organizations should also validate that security updates can be delivered reliably and that update mechanisms protect against unauthorized modifications.

Although the CRA does not mandate specific artifact signing or provenance technologies, these practices can provide supporting evidence of software integrity and secure distribution controls.

CRA Requirements and Open-Source Tooling

CRA Reference	Security Activity	CI/CD Implementation	Suggested Open-Source Tools
Annex I, Part I(2)(f)	Software integrity protection	Protect software artifacts, configurations, and release packages against unauthorized modification.	Sigstore Cosign, Harbor
Annex I, Part I(2)(c)	Secure update capability	Validate that products support appropriate mechanisms for receiving and applying security updates.	TUF, Sigstore Cosign
Annex I, Part II(7)	Secure update distribution	Establish mechanisms for securely distributing security updates and protecting update integrity.	TUF, Sigstore Cosign, Harbor
Annex I, Part II(8)	Security update delivery and user information	Validate update availability and delivery workflows, including appropriate user notifications and update instructions.	Harbor, Flux, Argo CD
Article 13(4), Annex VII(2)(c)	Build and release traceability	Record build provenance, artifact metadata, and release validation evidence to support the documented security processes.	in-toto, SLSA, Tekton Chains
Annex I, Part I(2)(f)	Deployment integrity verification	Validate approved software artifacts and enforce deployment policies before promotion.	Kyverno, OPA Gatekeeper, Sigstore Cosign

Expected Compliance Evidence

Signed software artifacts and verification records.
Build provenance and software supply chain attestations.
Artifact repository access and integrity records.
Secure update validation and distribution test results.
Deployment policy enforcement logs.
Release version and artifact traceability information.
Documented software update and rollback procedures.

2 - Release Security Validation - Build and Deploy

Release Security Validation for Build and Deploy Activities

CRA Release Security Validation - Phase 2: Build and Deploy

Objective: Verify that software releases satisfy applicable cybersecurity requirements and that known exploitable vulnerabilities are addressed before release.

The CRA requires manufacturers to ensure that products with digital elements meet essential cybersecurity requirements appropriate to their intended purpose and documented cybersecurity risk assessment. These requirements include making products available without known exploitable vulnerabilities, providing secure default configurations, protecting against unauthorized access, and maintaining product integrity and availability.

During Build and Deploy, DevOps teams should integrate automated security testing and vulnerability scanning into CI/CD pipelines. Release security gates should evaluate identified vulnerabilities, validate security configurations, and verify that software meets established security requirements before artifacts are promoted to production or distribution environments.

Security validation should include documented decisions regarding identified vulnerabilities, remediation outcomes, and any remaining risks requiring further evaluation.

CRA Requirements and Open-Source Tooling

CRA Reference	Security Activity	CI/CD Implementation	Suggested Open-Source Tools
Annex I, Part I(2)(a)	Known exploitable vulnerability checks	Scan release dependencies and software artifacts for known vulnerabilities; assess exploitability and resolve identified risks before release.	Trivy, Grype, OSV-Scanner
Annex I, Part II(3)	Security testing and validation	Execute automated security tests, vulnerability scans, and security reviews as part of build pipelines.	OWASP ZAP, Trivy, Semgrep
Annex I, Part I(2)(b), (d)–(g)	Secure configuration and data protection	Validate secure defaults, authentication, authorization, confidentiality, integrity, and data minimization controls.	Kyverno, Open Policy Agent, OWASP ZAP
Annex I, Part I(2)(h)–(l)	Product security and resilience	Test availability, attack surface reduction, exploit mitigations, and other applicable security requirements.	OWASP ZAP, Trivy, Checkov
Article 13(2)–(4)	Risk-based release approval	Evaluate security findings against the documented product risk assessment and record release decisions.	DefectDojo, Open Policy Agent

Expected Compliance Evidence

Software vulnerability scanning reports.
Static and dynamic application security testing results.
Security configuration validation results.
Identified vulnerability remediation records.
Release security approval decisions.
Documented security exceptions and supporting risk assessments.
CI/CD security gate execution logs.

3 - SBOM Genearation and Management - Build and Deploy

SBOM Genearation and Management for Build and Deploy Activities.

SBOM Genearation and Management - Phase 2: Build and Deploy

Objective: Establish software component transparency by generating, validating, and maintaining machine-readable Software Bills of Materials.

The CRA requires manufacturers to identify and document vulnerabilities and components contained in their products, including by creating a Software Bill of Materials (SBOM) in a commonly used, machine-readable format covering at least the product’s top-level dependencies.

For DevOps teams, SBOM generation should be integrated into automated build processes. SBOMs should identify software components and dependencies associated with each release and provide a foundation for vulnerability assessment, dependency tracking, and future security updates.

Organizations should maintain version-specific SBOMs and associate them with corresponding build artifacts, release identifiers, and product versions. While the CRA establishes minimum SBOM requirements, including transitive dependencies and retaining deployment associations can improve vulnerability impact analysis and remediation efficiency.

SBOMs should be stored securely, maintained as appropriate throughout the product support period, and made available to competent authorities when legally required.

CRA Requirements and Open-Source Tooling

CRA Reference	Security Activity	CI/CD Implementation	Suggested Open-Source Tools
Annex I, Part II(1)	SBOM generation	Automatically generate machine-readable SBOMs covering at least top-level software dependencies.	Syft, CycloneDX, SPDX
Annex I, Part II(1)	Software component identification	Identify and document software components, versions, and dependency relationships associated with each product release.	Syft, OWASP Dependency-Track
Annex I, Part II(1)–(2)	SBOM-based vulnerability analysis	Correlate SBOM components with known vulnerabilities and initiate remediation workflows.	OWASP Dependency-Track, OSV-Scanner, Grype
Article 13(5), Annex I, Part II(1)	Third-party dependency traceability	Track third-party dependencies and associate component information with specific product versions.	CycloneDX, Syft
Article 31, Annex VII(2)(b), (8)	SBOM retention and documentation	Maintain SBOM records as part of product technical documentation and support legally required access by market surveillance authorities.	OWASP Dependency-Track, CycloneDX, SPDX

Expected Compliance Evidence

Machine-readable SBOMs associated with product releases.
Software component and dependency inventories.
SBOM generation and validation records.
Component vulnerability assessment reports.
Product version and SBOM traceability records.
Documented SBOM retention and access procedures.
Third-party component identification records.

4 - Technical Documenatation and Evidence - Build and Deploy

Technical Documenatation and Evidence for Build and Deploy Activities.

Technical Documenatation and Evidence - Phase 2: Build and Deploy

Objective: Maintain the technical records and supporting security evidence needed to demonstrate conformity with applicable CRA requirements.

The CRA requires manufacturers to prepare technical documentation before placing covered products with digital elements on the EU market. This documentation must demonstrate how the product and its associated vulnerability handling processes satisfy applicable essential cybersecurity requirements.

Article 31 and Annex VII establish requirements for technical documentation, including product descriptions, software architecture, cybersecurity risk assessments, vulnerability handling procedures, security testing results, and relevant conformity information.

During Build and Deploy, CI/CD pipelines can automate the collection of evidence generated throughout development and release processes. Security scan results, SBOMs, build attestations, test reports, and release metadata can be associated with specific product versions to establish an auditable record of security activities.

This evidence supports the manufacturer’s conformity assessment obligations, but automated evidence generation does not independently establish CRA conformity. Manufacturers must complete the applicable assessment procedures, prepare the EU declaration of conformity, and affix CE marking when required.

CRA Requirements and Open-Source Tooling

CRA Reference	Security Activity	CI/CD Implementation	Suggested Open-Source Tools
Article 13(12), Article 31	Technical documentation preparation	Assemble technical records demonstrating compliance with applicable product and vulnerability handling requirements before market placement.	CycloneDX, Syft, Tekton Chains
Annex VII(1)–(2)	Product and release documentation	Maintain product descriptions, software versions, architecture information, and vulnerability handling procedures.	CycloneDX, SPDX
Annex VII(3)–(4)	Cybersecurity risk and support-period documentation	Link documented cybersecurity risk assessments and support-period decisions to product releases.	DefectDojo, Open Policy Agent
Annex VII(6)	Security test evidence	Preserve results of security testing and conformity verification activities for each applicable product release.	OWASP ZAP, Trivy, Tekton Chains
Annex VII(2)(b), (8)	SBOM and vulnerability handling evidence	Maintain SBOMs, vulnerability disclosure procedures, security contacts, and documentation of secure update mechanisms.	OWASP Dependency-Track, CycloneDX
Article 13(12)–(13), Article 31	Documentation maintenance and retention	Maintain technical documentation and the EU declaration of conformity for the legally required retention period, updating documentation as appropriate.	Harbor, in-toto
Articles 28–30, Article 32	Conformity assessment evidence	Organize release evidence and supporting technical records for the applicable conformity assessment, declaration, and CE marking processes.	SLSA, Tekton Chains, Sigstore Cosign

Expected Compliance Evidence

Product technical documentation and architecture descriptions.
Version-specific SBOMs and software inventories.
Cybersecurity risk assessment documentation.
Security testing and vulnerability scanning reports.
Artifact integrity and build provenance records.
Vulnerability handling and secure update procedures.
Records of applied cybersecurity standards and specifications.
EU declaration of conformity and applicable conformity assessment records.
Documentation maintenance and retention policies.

Compliance Evidence Summary

Build and Deploy activities should establish a verifiable record demonstrating that cybersecurity requirements were evaluated and appropriate security controls were applied before a product was distributed or placed on the market.

Organizations should integrate evidence generation into their CI/CD pipelines wherever practical, linking security validation results, SBOMs, signed artifacts, and technical documentation to specific product versions and releases.

These records should support vulnerability management throughout the product support period, enable investigation of newly discovered security issues, and provide traceable documentation for applicable CRA conformity assessment requirements.

References

Implementation Note: The CRA establishes legal obligations for manufacturers and other covered economic operators. The suggested tools represent possible technical implementations and supporting evidence-generation mechanisms. They are not individually mandated by the CRA, and their use alone does not establish regulatory conformity.