Tools you need for a CRA-ready codebase

The Cyber Resilience Act turns secure software development, component transparency, and vulnerability handling into requirements for products sold in the EU.

Preparing your codebase means putting the right controls into development: identifying vulnerabilities early, understanding every software component, preventing unacceptable risks from reaching release, driving remediation, and retaining evidence that these controls are working.

SonarQube brings the majority of these capabilities into everyday engineering workflows across human-written, AI-generated, and agent-modified code.

What capabilities support CRA codebase readiness?

Cyber Resilience Act deadlines and who must act

The CRA applies to manufacturers, importers, and distributors of products with digital elements placed on the EU market. This includes many commercial software applications, connected products, embedded systems, and supporting software.

The principal deadlines are:

• September 11, 2026: Article 14 reporting obligations begin for actively exploited vulnerabilities and severe security incidents.
• December 11, 2027: Most remaining CRA requirements become applicable, including essential cybersecurity and vulnerability-handling requirements.

CRA compliance is assessed at the product and organizational level. Codebase controls are an essential part of that program, alongside product risk management, incident response, technical documentation, and conformity assessment.

See SonarQube in action

Secure-by-default code

CRA readiness requires manufacturers to identify and address security weaknesses throughout the product lifecycle. The most effective place to begin is while code is being written and reviewed.

SonarQube provides:

• Layered code verification
• Advanced taint analysis
• Security and code-quality rules
• IDE and pull-request feedback
• Branch and CI/CD analysis
• Centrally managed quality profiles
• Enforceable quality gates

Together, these capabilities create a consistent workflow:

1. Define applicable standards through quality profiles.
2. Set release conditions through quality gates.
3. Analyze every code change.
4. Give developers actionable feedback.
5. Prevent changes that fail required conditions from merging.
6. Remediate identified issues.
7. Reanalyze the code to verify the fix.

This helps make secure-by-default development operational instead of relying on security reviews at the end of a release.

CRA Vulnerability identification management across code and components

CRA vulnerability management must cover both proprietary code and the third-party components included in a product.

SonarQube analyzes first-party source code for security vulnerabilities, including complex data flows identified through taint analysis. SonarQube Advanced Security extends this visibility to direct and transitive open-source dependencies.

Dependency findings can include:

• The affected component and version
• The associated vulnerability
• CVSS severity
• EPSS exploitation probability
• CISA Known Exploited Vulnerabilities status
• Available fixed versions

This creates a more complete view of potential vulnerabilities across the codebase and helps teams focus remediation using relevant risk context.

Software supply chain controls: Component transparency with SCA and SBOMs

The CRA requires manufacturers to identify and document components included in their products. This supports vulnerability monitoring, impact assessment, and timely response when new risks are disclosed.

SonarQube Advanced Security identifies direct and transitive dependencies and generates machine-readable SBOMs in:

• CycloneDX
• SPDX
• Both of the above exportable as JSON or XML

Organizations can export and retain an SBOM for each relevant product release. The CRA requires component documentation covering at least top-level dependencies, although greater depth can provide stronger visibility and more useful evidence.

Vulnerability prioritization: CVSS, EPSS, KEV, and reachability

Not every dependency vulnerability presents the same level of application risk. Teams need context to determine where investigation and remediation should begin. SonarQube provides this context with CVSS, EPSS, and CISA KEV information to support more informed prioritization.

VEX reports and documented risk decisions

Vulnerability Exploitability eXchange helps organizations communicate the assessed status of vulnerabilities affecting software components.

SonarQube VEX reports can include:

• Component and vulnerability details
• Current vulnerability status
• The justification recorded when a risk is marked Safe
• Supporting assessment information

This creates a consistent record of dependency-risk decisions and can contribute to CRA technical documentation and vulnerability-handling evidence.

Protect access and secure configurations: Secrets detection and IaC scanning

Secure-by-default development also requires controls for credentials and infrastructure definitions.

SonarQube detects secrets committed to source code and analyzes supported infrastructure-as-code files for security misconfigurations. These checks can run during development and before merge, helping teams correct risks before they become part of a release.

For live environments, these preventive controls work alongside runtime infrastructure, cloud, identity, and secrets-management systems.

Consistent security governance

CRA controls need to operate consistently across teams, projects, and product codebases.

Quality profiles allow organizations to define applicable code and security standards centrally. Quality gates translate those standards into release conditions that can be applied consistently across development workflows.

This helps organizations:

• Establish common security expectations
• Apply them across human and AI contributors
• Prevent non-compliant changes from merging
• Reduce variation between teams
• Scale governance across projects and applications
• Demonstrate that defined controls are actively enforced

Vulnerability remediation and verification

Finding vulnerabilities is only useful when teams can move them through remediation and confirm that the risk has been addressed.

SonarQube supports a continuous process:

1. Identify vulnerabilities in code and components.
2. Review the finding and available risk context.
3. Assign and track remediation.
4. Apply the code or dependency change.
5. Reanalyze the project.
6. Verify that the finding has been resolved.
7. Retain the resulting analysis record.

For supported dependency risks, the Sonar Remediation Agent can propose upgrades and open pull requests, helping teams move dependency remediation into their existing backlog and review workflow.

Article 14 reporting readiness

From September 11, 2026, manufacturers must report actively exploited vulnerabilities and severe security incidents within defined timelines. The first notification may be required within 24 hours of awareness.

Readiness depends on being able to identify affected code and components, assess the issue, coordinate remediation, verify corrective action, and assemble reliable technical information quickly.

SonarQube supports this process with:

• Code and dependency findings
• Severity and exploitation context
• Component inventories and SBOMs
• Remediation and verification records
• VEX assessments
• CRA-focused security reporting
• Administrative audit logs

These inputs can support vulnerability investigation and reporting preparation. The determination that an issue is legally reportable, and submission through the EU Single Reporting Platform, remain part of the organization’s Article 14 response process.

Code-level evidence for CRA compliance

CRA readiness requires evidence that security controls are defined, applied, and maintained throughout development.

SonarQube can provide:

• Quality profiles showing applicable standards
• Quality gates showing release conditions
• Analysis results and security findings
• Dependency inventories
• Exported SBOMs
• VEX reports and risk justifications
• Remediation and verification records
• Security reports
• Audit logs

This turns normal development activity into reusable code-level evidence for technical documentation, internal reviews, vulnerability investigations, and conformity-assessment preparation.