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

Return to the regular view of this page.

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 - 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 Requirements and Open-Source Tooling

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.

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 Requirements and Open-Source Tooling

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.

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 Requirements and Open-Source Tooling

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.

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 Requirements and Open-Source Tooling

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.

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.