This is the multi-page printable view of this section.
Click here to print.
Return to the regular view of this page.
The Cyber Reslience Act (CRA) - Overview
The European Union Cyber Resilience Act (CRA) is a regulation designed to strengthen the cybersecurity of products with digital elements throughout their entire lifecycle. It establishes mandatory cybersecurity requirements for manufacturers, including secure-by-design development, cybersecurity risk assessments, software component transparency, vulnerability management, security updates, and coordinated vulnerability disclosure. Unlike traditional security practices that focus primarily on development and release, the CRA emphasizes continuous security after deployment, requiring manufacturers to identify, assess, and remediate vulnerabilities throughout a product’s support period. The regulation also establishes requirements for reporting actively exploited vulnerabilities and severe security incidents. For DevOps and platform engineering teams, the CRA reinforces the need to integrate cybersecurity practices across the entire CI/CD lifecycle—from Code and Prebuild through Build and Deploy to Post Deployment—while maintaining the evidence necessary to demonstrate compliance.
The CRA requirements which are addressed by this guide are principally found in Article 13, Article 14, Annex I Part I, Annex I Part II, and Annex VII. These requirements span several phases, so the mapping below assigns each activity to its primary implementation point.
Phase 1 — Code and Prebuild
Objective: Prevent cybersecurity risks from being introduced during product planning, design, coding, and dependency selection. The CRA requires manufacturers to assess cybersecurity risks throughout the product lifecycle and design products with security appropriate to those risks. For DevOps teams, Phase 1 converts these requirements into development policies, threat modeling, dependency governance, secure coding practices, and vulnerability disclosure procedures.
Phase 2 - Build and Deploy
Objective: Produce, validate, and distribute software releases that meet the product’s applicable cybersecurity requirements. Phase 2 ensures that security requirements established during development are verified before a software release is made available. The CRA requires products to meet applicable security requirements, including the absence of known exploitable vulnerabilities when placed on the market, subject to the product risk assessment and regulatory provisions.
Post Deployment
Objective: Continuously identify and address vulnerabilities, maintain security throughout the support period, and provide required disclosures and incident notifications. This phase deserves particular attention. The CRA does not treat security as complete when a software release passes its build-time checks. Manufacturers must operate vulnerability handling processes throughout the applicable support period, including handling vulnerabilities in third-party components and making security updates available.
1 - Code and Prebuild Tasks
The Cyber Reslience Act Tasks related to Code and Prebuild: Phase 1
Achieving Code and Prebuild Tasks of the Cyber Resilence Act
The European Union Cyber Resilience Act (CRA) establishes cybersecurity requirements for products with digital elements throughout their lifecycle. During Code and Prebuild, organizations should incorporate cybersecurity risk assessments, secure-by-design principles, third-party dependency reviews, and vulnerability disclosure planning into their software development practices.
This phase focuses on preventing security vulnerabilities before software enters the build pipeline. By integrating CRA-aligned practices into developer workflows, organizations can identify risks earlier, reduce dependency exposure, and establish the processes needed to maintain product security after deployment.
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.1 - Security Risk Assessment - Code and Prebuild
Security Risk Assessment for Code and Prebuild Activities
CRA Security Risk Assessment - Phase 1: Code and Prebuild
The European Union Cyber Resilience Act (CRA) establishes cybersecurity requirements for products with digital elements throughout their lifecycle. During Code and Prebuild, organizations should incorporate cybersecurity risk assessments, secure-by-design principles, third-party dependency reviews, and vulnerability disclosure planning into their software development practices.
This phase focuses on preventing security vulnerabilities before software enters the build pipeline. By integrating CRA-aligned practices into developer workflows, organizations can identify risks earlier, reduce dependency exposure, and establish the processes needed to maintain product security after deployment.
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.
CRA Security Risk Assessment
Objective: Identify, evaluate, and document cybersecurity risks before software development and throughout the product lifecycle.
Article 13 requires manufacturers to perform cybersecurity risk assessments that consider the intended purpose, reasonably foreseeable use, operational environment, and expected lifetime of products with digital elements. These assessments inform the selection of appropriate cybersecurity controls and must be documented and updated as appropriate during the product’s support period.
For DevOps teams, risk assessments should be integrated into application planning, architecture reviews, and development workflows. Threat modeling can help identify potential attack vectors, vulnerable components, insecure configurations, and risks introduced by software dependencies. Identified risks should be tracked as development tasks, with appropriate mitigation strategies and documented decisions.
| CRA Reference |
Security Activity |
CI/CD Implementation |
Suggested Open-Source Tools |
| Article 13(2)–(3) |
Cybersecurity risk assessment |
Identify and assess security risks during planning and design; reassess when product functionality or threats change. |
OWASP Threat Dragon |
| Article 13(3) |
Threat identification and analysis |
Evaluate potential attack vectors, operational environments, and assets requiring protection. |
OWASP Threat Dragon, OWASP pytm |
| Article 13(4), Article 31, Annex VII |
Risk assessment documentation |
Record identified risks, mitigation decisions, and applicable security requirements as part of product technical documentation. |
OWASP Threat Dragon, DefectDojo |
| Annex I, Part I(1) |
Risk-based security controls |
Define appropriate security controls based on product risks and expected operational conditions. |
Open Policy Agent, Semgrep |
Expected Compliance Evidence
- Documented cybersecurity risk assessments.
- Threat models and architectural security reviews.
- Security requirements derived from identified risks.
- Risk mitigation decisions and assigned responsibilities.
- Records of risk assessment updates.
1.2 - Secure-by-Design Requirements - Code and Prebuild
Secure-by-Design Requirements for Code and Prebuild Activities
Secure-by-Design Requirements - Phase 1: Code and Prebuild
Objective: Integrate security requirements directly into software architecture, coding practices, and configuration management.
The CRA establishes essential cybersecurity requirements designed to reduce vulnerabilities and ensure products provide an appropriate level of security. These include secure default configurations, protection against unauthorized access, data confidentiality and integrity, minimization of attack surfaces, and mechanisms for addressing vulnerabilities through security updates.
During Code and Prebuild, development teams should define security requirements before implementation and incorporate automated security checks into developer workflows. Secure coding practices, static application security testing (SAST), secret detection, and policy validation help identify potential weaknesses before software is committed or promoted to the build pipeline.
| CRA Reference |
Security Activity |
CI/CD Implementation |
Suggested Open-Source Tools |
| Annex I, Part I(1) |
Secure-by-design development |
Incorporate security requirements into application architecture, coding standards, and development workflows. |
Semgrep, OWASP Threat Dragon |
| Annex I, Part I(2)(b) |
Secure default configurations |
Establish secure configuration baselines and validate configuration policies before release. |
Open Policy Agent, Checkov |
| Annex I, Part I(2)(d)–(f) |
Access control and data protection |
Define requirements for authentication, authorization, encryption, confidentiality, and data integrity. |
Semgrep, Gitleaks |
| Annex I, Part I(2)(g) |
Data minimization |
Identify unnecessary data collection and define controls to limit data processing. |
Semgrep, Open Policy Agent |
| Annex I, Part I(2)(j)–(k) |
Attack surface reduction and exploit mitigation |
Identify unnecessary services, exposed interfaces, and potential exploit paths. |
OWASP Threat Dragon, Semgrep |
| Annex I, Part I(2)(c) |
Security update readiness |
Design software components and configurations to support secure vulnerability remediation and updates. |
Open Policy Agent, Renovate |
Expected Compliance Evidence
- Secure coding standards and development policies.
- Application security architecture documentation.
- Static analysis and secrets scanning results.
- Configuration policy definitions and validation results.
- Security-focused code review records.
- Documented security update design requirements.
1.3 - Third-Party Dependency Due Diligence - Code and Prebuild
Third-Party Dependency Due Diligence for Code and Prebuild Activities
Third-Party Dependency Due Diligence - Phase 1: Code and Prebuild
Objective: Reduce software supply chain risks by evaluating open-source and commercial dependencies before they are incorporated into products.
Article 13(5) requires manufacturers to exercise due diligence when integrating third-party components, including free and open-source software, to ensure those components do not compromise product cybersecurity.
For DevOps teams, this means establishing dependency governance practices that evaluate known vulnerabilities, project maintenance, security practices, and dependency provenance before adding new libraries, frameworks, or packages.
Dependency inventories should be maintained throughout development and should provide the foundation for generating a machine-readable Software Bill of Materials (SBOM) during the build process. Automated scanning can identify known vulnerabilities, while project security assessments can help teams understand risks associated with open-source components.
| CRA Reference |
Security Activity |
CI/CD Implementation |
Suggested Open-Source Tools |
| Article 13(5) |
Third-party dependency due diligence |
Evaluate security risks associated with open-source and commercial dependencies before adoption. |
OpenSSF Scorecard, OSV-Scanner |
| Article 13(5) |
Open-source project security assessment |
Review project maintenance, security policies, vulnerability history, and development practices. |
OpenSSF Scorecard |
| Annex I, Part II(1) |
Dependency identification and inventory |
Track direct and transitive dependencies and prepare component information for SBOM generation. |
Syft, CycloneDX |
| Annex I, Part II(1)–(2) |
Known vulnerability identification |
Identify known vulnerabilities in dependencies and initiate risk-based remediation. |
OSV-Scanner, OWASP Dependency-Check |
| Article 13(5)–(6) |
Dependency vulnerability response |
Establish processes for reviewing, updating, replacing, and reporting vulnerabilities in third-party components. |
Renovate, OSV-Scanner |
Expected Compliance Evidence
- Approved dependency inventories.
- Third-party component security assessments.
- Open-source project risk evaluations.
- Dependency vulnerability scanning results.
- Dependency upgrade and remediation records.
- Documented component selection and exception decisions.
1.4 - Vulnerability Disclousres Preperation - Code and Prebuild
Vulnerability Disclousres Preperation for Code and Prebuild Activities
Vulnerability Disclosure Preparation - Phase 1: Code and Prebuild
Objective: Establish processes for receiving, evaluating, coordinating, and responding to vulnerability reports before a product is released.
The CRA requires manufacturers to establish and enforce coordinated vulnerability disclosure policies and provide mechanisms for reporting potential vulnerabilities in their products and included third-party components.
During Code and Prebuild, organizations should define how security researchers, customers, developers, and external contributors can report vulnerabilities. These processes should include a published security contact, confidential reporting channels, vulnerability triage procedures, and clear responsibilities for investigation and remediation.
For DevOps teams, disclosure preparation should integrate with development issue tracking, dependency management, and security response workflows. Establishing these processes early ensures that vulnerabilities discovered after deployment can be evaluated, assigned, and addressed efficiently.
| CRA Reference |
Security Activity |
CI/CD Implementation |
Suggested Open-Source Tools |
| Annex I, Part II(5) |
Coordinated vulnerability disclosure policy |
Publish and maintain procedures for vulnerability reporting, evaluation, coordination, and disclosure. |
GitHub Security Advisories, DefectDojo |
| Annex I, Part II(6) |
Vulnerability reporting contact |
Establish a security contact and confidential reporting mechanism for product and third-party component vulnerabilities. |
GitHub Private Vulnerability Reporting |
| Annex I, Part II(2), Article 13(6) |
Vulnerability triage and remediation planning |
Define processes for assessing reported vulnerabilities, assigning ownership, and coordinating fixes with component maintainers. |
DefectDojo, OSV |
| Annex I, Part II(4) |
Security advisory preparation |
Establish procedures for documenting affected products, vulnerability severity, fixes, and public security advisories. |
GitHub Security Advisories, OSV |
| Article 14 |
Regulatory reporting readiness |
Define escalation and notification procedures for actively exploited vulnerabilities and severe security incidents that meet CRA reporting criteria. |
DefectDojo, TheHive |
Expected Compliance Evidence
- Published coordinated vulnerability disclosure policy.
- Documented vulnerability reporting contact and channels.
- Vulnerability triage and response procedures.
- Defined vulnerability remediation responsibilities.
- Security advisory templates and disclosure workflows.
- Regulatory incident escalation and reporting procedures.
1.5 - Compliance Evidence Summary - Code and Prebuild
Compliance Evidence Summary for Code and Prebuild Activities
Compliance Evidence Summary - Phase 1: Code and Prebuild
Code and Prebuild activities should establish a documented foundation for cybersecurity risk management and secure software development.
Organizations should retain evidence demonstrating that product risks, security requirements, third-party dependencies, and vulnerability disclosure processes were addressed before software entered the build pipeline.
These records should be maintained and updated as appropriate throughout the product lifecycle and should support the technical documentation and vulnerability handling obligations established by the CRA.
References
Implementation Note: The CRA establishes legal obligations for covered products and economic operators. The open-source tools listed above are examples of possible engineering implementations. Their use does not independently demonstrate CRA compliance, and individual security controls should be selected according to the documented product cybersecurity risk assessment.
2 - Build and Deploy Tasks
The Cyber Reslience Act for Build/Deploy CI/CD Steps: Phase 2
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.
2.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 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.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 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.
2.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 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.
2.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 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.
3 - Post Deployment Tasks
The Cyber Reslience Act for Post Deploy CI/CD Steps: Phase 3
Achieving Post Deploy Tasks of the Secure Software Development Framework
The European Union Cyber Resilience Act (CRA) establishes cybersecurity obligations that extend beyond software development and initial release. Manufacturers of covered products with digital elements must maintain processes for identifying, evaluating, and addressing vulnerabilities throughout the applicable product support period. These responsibilities include monitoring software components for newly disclosed vulnerabilities, determining which products are affected, distributing security updates, and coordinating vulnerability disclosures.
During Post Deployment, organizations must be prepared to respond to vulnerabilities discovered after software has been released. A software component that was considered secure during development may become vulnerable when a new Common Vulnerabilities and Exposures (CVE) record is published. Build-time scanning alone cannot identify every future vulnerability.
For DevOps and platform engineering teams, continuous vulnerability management should extend the CI/CD pipeline into operational environments. By correlating software component inventories, SBOMs, product versions, and deployment records with emerging vulnerability intelligence, organizations can identify affected products, prioritize remediation, and maintain evidence demonstrating ongoing security activities.
The following sections map CRA requirements to actionable Post Deployment practices and suggested open-source tooling. The tools are illustrative and are not mandated by the regulation.
3.1 - Affected-Product Identification - Post Deployment
Affected-Product Identification for Post Deployment Activities.
Affected-Product Identification - Phase 3: Post Deployment
Objective: Identify which released products, software versions, and operational deployments are affected when new vulnerabilities are disclosed.
The CRA requires manufacturers to identify and document vulnerabilities and components contained in their products and to assess vulnerabilities according to the risks they pose. Effective vulnerability handling depends on understanding which products contain affected components and whether those components introduce exploitable security risks.
For DevOps teams, this requires establishing traceability between software components, SBOMs, product versions, release artifacts, and the environments where software is deployed.
An SBOM identifies the components contained in a software product or release, but an SBOM alone does not necessarily identify where affected software is currently running. Correlating component inventories with release and deployment metadata provides additional visibility into the operational impact of newly disclosed vulnerabilities.
This process, commonly referred to as vulnerability impact analysis or blast-radius assessment, helps organizations distinguish vulnerabilities affecting actively deployed products from vulnerabilities associated with obsolete or unused releases.
Where deployment information is available, teams can associate affected products with specific environments, endpoints, applications, and responsible owners. This supports faster investigation, targeted remediation, and improved communication with affected users.
While the CRA does not explicitly mandate endpoint-level deployment mapping, this capability can strengthen vulnerability handling and provide supporting evidence of product-specific risk assessment.
| CRA Reference |
Security Activity |
CI/CD Implementation |
Suggested Open-Source Tools |
| Annex I, Part II(1) |
Affected-component identification |
Correlate disclosed vulnerabilities with SBOM components, software versions, and supported products. |
OWASP Dependency-Track, OSV.dev, Ortelius |
| Article 13(8), Annex I, Part II(2) |
Product vulnerability impact assessment |
Determine which product versions are affected and evaluate the risks associated with identified vulnerabilities. |
Ortelius, DefectDojo, OWASP Dependency-Track |
| Annex I, Part II(1)–(2) |
Release and deployment traceability |
Associate software components and SBOMs with release artifacts and available deployment records. |
Ortelius, Argo CD, Flux |
| Annex I, Part II(2) |
Vulnerability blast-radius assessment |
Identify affected product versions and, where supported, deployed applications, environments, and endpoints. |
Ortelius, OWASP Dependency-Track |
| Annex I, Part II(2), (4) |
Remediation ownership and affected-product communication |
Identify responsible teams and maintain records of affected products for remediation and security advisories. |
Ortelius, DefectDojo |
| Annex I, Part II(1)–(2) |
Vulnerability status and exploitability documentation |
Document product-specific vulnerability assessments, including whether vulnerabilities are affected, not affected, fixed, or under investigation. |
OpenVEX, CycloneDX, Ortelius |
Expected Compliance Evidence
- Component-to-product vulnerability mappings.
- Product and release version inventories.
- SBOM-to-release associations.
- Available deployment and endpoint inventory records.
- Affected-product and vulnerability impact assessments.
- Product-specific vulnerability status statements.
- Assigned remediation ownership and tracking records.
- Documented decisions concerning product exposure and exploitability.
3.2 - Remediation and Security Update - Post Deployment
Remediation and Security Update for Post Deployment Activities.
Remediation and Security Update - Phase 3: Post Deployment
Objective: Address identified vulnerabilities without delay and securely distribute appropriate security updates to affected products.
The CRA requires manufacturers to address and remediate vulnerabilities in relation to the risks they pose to their products. Remediation may involve updating vulnerable dependencies, modifying application code, applying configuration changes, replacing affected components, or implementing other appropriate mitigation measures.
Where technically feasible, security updates must be provided separately from functionality updates. The CRA also establishes requirements for securely distributing security updates and making them available without delay and, subject to specified exceptions, free of charge.
For DevOps teams, vulnerability remediation should connect Post Deployment monitoring with development and build workflows. When a vulnerability is identified, teams should evaluate available fixes, determine compatibility with affected products, create remediation changes, and validate those changes through automated build and security testing.
Remediation workflows should support dependency upgrades, application changes, regression testing, release approval, and controlled deployment of security updates.
Where applicable, organizations should maintain records demonstrating that fixes were developed, tested, released, and communicated to affected users. Deployment verification provides additional operational assurance that updated software has reached the intended environments.
Automating these workflows can reduce remediation delays while maintaining required security reviews and release authorization controls.
| CRA Reference |
Security Activity |
CI/CD Implementation |
Suggested Open-Source Tools |
| Annex I, Part II(2) |
Vulnerability remediation |
Investigate identified vulnerabilities and implement appropriate fixes or mitigating measures without delay, based on product risk. |
Renovate, DefectDojo, Ortelius |
| Article 13(6) |
Third-party vulnerability remediation coordination |
Coordinate identified component vulnerabilities and applicable fixes with upstream maintainers. |
GitHub Security Advisories, Renovate |
| Annex I, Part II(2) |
Dependency and application updates |
Update vulnerable dependencies or application code and validate remediation through automated builds and tests. |
Renovate, Trivy, Grype |
| Annex I, Part II(2) |
Separation of security and functionality updates |
Maintain workflows capable of delivering security fixes independently of unrelated functionality changes where technically feasible. |
Renovate, Argo CD, Flux |
| Annex I, Part I(2)(c) |
Security update capability |
Support product mechanisms for receiving and applying appropriate security updates. |
The Update Framework (TUF), Sigstore Cosign |
| Annex I, Part II(7) |
Secure update distribution |
Verify the authenticity and integrity of security updates before delivery or installation. |
The Update Framework (TUF), Sigstore Cosign, Harbor |
| Annex I, Part II(8) |
Timely update availability and user advisories |
Distribute available security fixes without delay, subject to CRA requirements, and communicate relevant user actions. |
Argo CD, Flux, GitHub Security Advisories |
| Article 13(8)–(9) |
Support-period security maintenance |
Maintain vulnerability handling capabilities and ensure security updates remain available for the applicable period. |
Harbor, Ortelius |
| Annex I, Part II(2)–(3) |
Remediation validation |
Reassess vulnerability status after remediation and verify that updated software addresses the identified security issue. |
Trivy, Grype, OWASP Dependency-Track |
Expected Compliance Evidence
- Vulnerability remediation records and assigned responsibilities.
- Dependency upgrade and application modification history.
- Security update build and test results.
- Documented remediation risk assessments.
- Security update release and distribution records.
- Signed update artifacts and integrity verification results.
- User notification and security advisory records.
- Product version and deployment verification records.
- Security update availability and retention records.
- Documented mitigation decisions for vulnerabilities that cannot be immediately patched.
3.3 - Continuous Vulernability Management - Post Deployment
Continuous Vulernability Management for Post Deployment Activities.
Continuous Vulernability Management - Phase 3: Post Deployment
Objective: Continuously identify, assess, and track newly discovered vulnerabilities affecting released software throughout the product support period.
The CRA requires manufacturers to maintain effective vulnerability handling processes and address cybersecurity risks associated with their products and integrated components. These responsibilities extend throughout the applicable product support period and include regularly reviewing product security, identifying newly disclosed vulnerabilities, and taking appropriate remediation measures.
For DevOps teams, continuous vulnerability management requires maintaining visibility into software components after release. SBOMs generated during Build and Deploy should be retained and monitored against evolving vulnerability intelligence from sources such as the National Vulnerability Database (NVD), OSV, and other security advisory databases.
When new vulnerabilities are identified, organizations should determine whether affected components are included in supported product versions, evaluate their potential exploitability and impact, and assign remediation activities to responsible teams.
Automated vulnerability correlation, risk-based prioritization, and integration with development issue tracking can help reduce the time between vulnerability disclosure and remediation.
| CRA Reference |
Security Activity |
CI/CD Implementation |
Suggested Open-Source Tools |
| Article 13(8) |
Ongoing vulnerability management |
Maintain effective vulnerability handling processes throughout the applicable product support period. |
OWASP Dependency-Track, Ortelius |
| Annex I, Part II(1) |
Continuous component vulnerability identification |
Monitor SBOM components against newly disclosed vulnerabilities and maintain product component inventories. |
OWASP Dependency-Track, OSV.dev, Grype |
| Annex I, Part II(2) |
Vulnerability risk assessment and prioritization |
Evaluate newly discovered vulnerabilities for product relevance, exploitability, impact, and required remediation. |
DefectDojo, Ortelius, OSV-Scanner |
| Annex I, Part II(3) |
Continuous security testing |
Conduct effective and regular security tests and reviews of supported product versions. |
Trivy, OWASP ZAP, Wazuh |
| Article 13(5), Annex I, Part II(1)–(2) |
Third-party component vulnerability monitoring |
Identify newly disclosed vulnerabilities in integrated open-source and commercial dependencies and assess product impact. |
OSV-Scanner, OWASP Dependency-Track, OpenSSF Scorecard |
| Article 13(8), Annex I, Part II(2) |
Vulnerability lifecycle tracking |
Track identified vulnerabilities through investigation, remediation, validation, and closure. |
DefectDojo, Ortelius |
Expected Compliance Evidence
- Maintained product SBOMs and component inventories.
- Continuous vulnerability monitoring records.
- Newly identified vulnerability assessment reports.
- Product-specific vulnerability risk and exploitability determinations.
- Vulnerability remediation assignments and tracking history.
- Periodic security test and review results.
- Evidence of vulnerability handling activities throughout the product support period.
3.4 - Vulnerability Disclosure and Regulatory Reporting - Post Deployment
Vulnerability Disclosure and Regulatory Reporting for Post Deployment Activities.
Vulnerability Disclosure and Regulatory Reporting - Phase 3: Post Deployment
Objective: Establish processes for coordinated vulnerability disclosure, communicate security information to affected users, and satisfy applicable CRA regulatory reporting obligations.
The CRA requires manufacturers to maintain coordinated vulnerability disclosure processes and provide mechanisms through which security researchers, customers, and other parties can report potential product vulnerabilities.
Manufacturers must also disclose appropriate information about fixed vulnerabilities once a security update becomes available, subject to the regulation’s provisions concerning disclosure timing and security risks. Such information includes affected products, vulnerability impact and severity, and actions users can take to remediate the issue.
In addition, Article 14 establishes mandatory regulatory reporting obligations for qualifying actively exploited vulnerabilities and severe incidents affecting the security of products with digital elements.
These reporting requirements have applied to manufacturers since September 11, 2026. They require early warning notifications within 24 hours of awareness, followed by more detailed notifications within 72 hours. Final reporting deadlines vary depending on whether the report concerns an actively exploited vulnerability or a severe security incident.
For DevOps and security operations teams, disclosure and reporting processes should integrate vulnerability intelligence, incident investigation, affected-product identification, remediation tracking, and communication workflows.
Organizations should establish procedures for determining whether a vulnerability meets the CRA’s regulatory reporting criteria, collecting required information, and submitting notifications through the designated reporting mechanisms.
Not every newly disclosed CVE triggers regulatory reporting. Article 14 applies to the specific categories of reportable vulnerabilities and incidents defined by the regulation.
| CRA Reference |
Security Activity |
CI/CD Implementation |
Suggested Open-Source Tools |
| Annex I, Part II(5) |
Coordinated vulnerability disclosure |
Maintain and enforce a documented coordinated vulnerability disclosure policy. |
GitHub Security Advisories, DefectDojo |
| Annex I, Part II(6) |
Vulnerability reporting channels |
Provide mechanisms and security contacts for reporting vulnerabilities in products and third-party components. |
GitHub Private Vulnerability Reporting, security.txt |
| Annex I, Part II(4) |
Public disclosure of fixed vulnerabilities |
Publish appropriate information about fixed vulnerabilities, affected products, severity, impacts, and remediation actions, subject to CRA disclosure provisions. |
GitHub Security Advisories, OSV, CSAF |
| Article 14(1)–(2) |
Actively exploited vulnerability reporting |
Establish procedures for identifying and reporting qualifying actively exploited vulnerabilities. |
TheHive, DefectDojo, Ortelius |
| Article 14(3)–(5) |
Severe security incident reporting |
Identify, investigate, and escalate qualifying severe incidents affecting product security. |
Wazuh, Falco, TheHive |
| Article 14(2), (4) |
Regulatory notification timelines |
Establish escalation workflows to meet applicable 24-hour, 72-hour, and final reporting deadlines. |
TheHive, DefectDojo |
| Articles 14 and 16 |
Regulatory notification submission |
Collect required incident and vulnerability details and submit mandatory notifications through the ENISA CRA Single Reporting Platform. |
TheHive, DefectDojo |
| Annex I, Part II(4), (8) |
User security advisories |
Communicate affected-product information, available security updates, and recommended remediation actions to users. |
GitHub Security Advisories, CSAF |
| Article 13(6) |
Upstream vulnerability coordination |
Notify relevant third-party component maintainers of identified vulnerabilities and share applicable fixes as required. |
GitHub Security Advisories, OSV |
CRA Regulatory Reporting Deadlines
The following timelines apply to qualifying actively exploited vulnerabilities and severe security incidents under Article 14.
| Reporting Requirement |
Deadline |
Required Action |
| Early warning notification |
Within 24 hours of awareness |
Submit an initial notification concerning a qualifying actively exploited vulnerability or severe security incident. |
| Vulnerability or incident notification |
Within 72 hours of awareness |
Submit a more detailed notification with available product, vulnerability or incident, and mitigation information. |
| Final report — actively exploited vulnerability |
No later than 14 days after a corrective or mitigating measure becomes available |
Provide the required final vulnerability information, including severity, impact, and corrective measures. |
| Final report — severe security incident |
Within one month after submission of the 72-hour incident notification |
Provide the required final incident analysis and corrective or mitigating measures. |
Mandatory notifications are submitted through the ENISA CRA Single Reporting Platform.
Reporting deadlines are triggered by awareness of qualifying events, rather than the publication of every CVE.
Expected Compliance Evidence
- Published coordinated vulnerability disclosure policy.
- Documented vulnerability reporting contacts and channels.
- Vulnerability reports and investigation records.
- Published security advisories and disclosure history.
- Affected-product identification and impact assessments.
- Reportability assessments for actively exploited vulnerabilities and severe incidents.
- Regulatory notification timestamps and submission records.
- Security incident investigation and root-cause analysis records.
- Remediation decisions and corrective action records.
- User notification and security update communication records.
Phase 3 Compliance Evidence Summary
Post Deployment activities should establish a continuous and traceable process for identifying vulnerabilities, determining affected products, implementing remediation, and communicating security information throughout the product support period.
Organizations should integrate SBOM monitoring, vulnerability intelligence, release inventories, and available deployment records to maintain visibility into software security after release.
When vulnerabilities are discovered, teams should document their relevance to supported products, assess exploitability and impact, assign remediation responsibilities, and preserve records of corrective actions.
Where practical, correlating vulnerable components with deployed product versions and operational endpoints can improve remediation prioritization and reduce the time required to identify affected environments.
For qualifying actively exploited vulnerabilities and severe security incidents, organizations must also maintain procedures capable of supporting statutory CRA reporting deadlines.
The resulting evidence should demonstrate that vulnerability handling is an ongoing operational process rather than a one-time activity performed during software development or release.
References
Implementation Note: The CRA establishes obligations for covered manufacturers and, where applicable, other economic operators and open-source software stewards. The open-source tools listed are illustrative technica