Does the CRA apply to AI-generated code?
The Cyber Resilience Act does not set different cybersecurity requirements based on whether code was written by a person, generated by an AI assistant, or modified by an autonomous agent.
When that code becomes part of an in-scope product with digital elements, the manufacturer remains responsible for its security. The same CRA expectations around secure development, vulnerability handling, component transparency, remediation, and technical evidence continue to apply.
CRA compliance for AI-generated code therefore depends on one principle: verify every change against the same enforceable standards, regardless of its origin.
One standard for human and agent-generated code
AI coding increases development capacity, but it can also increase the volume, speed, and variability of change entering the software lifecycle. Generated code may introduce insecure patterns, vulnerable dependencies, exposed secrets, maintainability problems, or infrastructure misconfigurations.
Manual review alone becomes harder to scale as coding agents produce and modify more code.
SonarQube applies deterministic analysis, zero-trust, multilayered verification before merge to every change included in the analysis scope. The checks do not depend on the agent recognizing its own mistakes or accurately describing what it changed.
This provides:
- Consistent standards for human and AI contributors
- Verification separate from the code-generating model
- Actionable feedback during development
- Enforceable conditions before merge
- Traceable findings and remediation
- Consistent governance across projects and teams
Make AI code assurance operational with governed quality gates
Sonar allows organizations to designate projects containing AI-generated code and apply a dedicated quality gate. This makes assurance requirements and project status visible to development, security, and governance teams.
AI code assurance is supported by SonarQube analysis capabilities including:
- Static application security testing
- Advanced taint analysis
- Secrets detection
- Infrastructure-as-code analysis
- Software composition analysis
- Code-quality and maintainability analysis
- Quality profiles and quality gates
Together, these capabilities help teams govern the complete change rather than trusting the output because it came from a particular AI platform or coding assistant.
Verify every AI code change before merge
CRA-ready AI development requires verification to be embedded throughout the workflow, not added as a separate review after the agent finishes working.
A practical verification flow is:
- Define standards: Use quality profiles to establish the security and code-quality rules that apply.
- Set release conditions: Configure quality gates to define what must pass before code can proceed.
- Analyze code: Inspect human-written, AI-generated, and agent-modified code using the same rules.
- Give feedback: Surface findings while developers or agents can still act on them.
- Enforce before merge: Prevent changes that fail defined release conditions from progressing.
- Remediate: Correct code, dependency, secret, and configuration findings.
- Verify: Reanalyze the change to confirm that the issue has been resolved.
- Retain evidence: Preserve relevant analysis results, gate status, component records, and remediation history.
This makes secure-by-default development scalable as AI increases the amount of code moving through the delivery pipeline.
Identify security vulnerabilities in AI-generated code
Generated code can reproduce insecure patterns found in training data, use APIs incorrectly, omit validation, or create dangerous data flows that are difficult to spot during manual review.
SonarQube analyzes generated code for security weaknesses using the same SAST and taint-analysis rules applied to developer-written code.
This can help identify:
- Injection vulnerabilities
- Authentication and authorization weaknesses
- Unsafe data flows
- Cryptographic mistakes
- Exposed secrets
- Insecure API usage
- Security-sensitive configuration issues
- Other supported vulnerability classes
Quality gates can prevent code containing findings that violate defined conditions from being merged or released.
Analysis reduces risk but does not prove that software contains no vulnerabilities. It should operate as one layer within the organization’s wider product-security and testing strategy.
Govern dependencies introduced by AI
AI assistants and coding agents can add libraries quickly, sometimes without fully evaluating their security, maintenance status, or transitive dependencies.
SonarQube Advanced Security helps teams identify:
- Direct dependencies
- Transitive dependencies
- Associated vulnerabilities
- Affected and fixed versions
- CVSS severity
- EPSS exploitation probability
- CISA Known Exploited Vulnerabilities status
- Supported reachability information
This gives teams visibility into the software-supply-chain consequences of AI-generated changes before those components become part of a release.
Maintain component transparency with SBOM and VEX
The CRA requires manufacturers to identify and document product components in a commonly used, machine-readable format, covering at least top-level dependencies.
SonarQube Advanced Security generates SBOMs in CycloneDX and SPDX formats. Organizations can export and retain an SBOM for each relevant product release, creating a record of the components included in AI-assisted development.
VEX reports complement the SBOM by documenting the assessed status of dependency vulnerabilities, including justifications recorded when risks are marked Safe.
Together, SBOM and VEX support:
- Component identification
- Vulnerability impact assessment
- Transparent risk decisions
- Remediation planning
- Technical documentation
- Vulnerability investigation
They contribute code-level evidence but do not independently establish CRA compliance.
Turn quality gates into CRA-relevant evidence
AI-assisted development needs controls that are both enforceable and defensible. It should be possible to demonstrate which standards applied, whether a change passed them, what issues were found, and how those issues were resolved.
SonarQube can provide code-level records including:
- Applied quality profiles
- Quality gate conditions and results
- Code-security findings
- Dependency inventories
- Exported SBOMs
- VEX reports and risk justifications
- Remediation and verification history
- Security reports
- Administrative audit logs
Because these records come from normal development activity, evidence collection can scale with AI-generated change instead of becoming a separate manual exercise.
Map SonarQube capabilities to CRA workflows
SonarQube supports the code and component controls behind these expectations. Product risk assessment, incident classification, conformity assessment, and regulatory submission remain part of the organization’s wider CRA program.
Operationalize CRA verification from IDE to release
In the IDE
SonarQube for IDE provides feedback while code is being created or reviewed. Developers can address supported security and quality issues before the change reaches a pull request.
In the pull request
Analyze the complete proposed change, including modifications produced by coding agents. Surface code, secret, infrastructure-as-code, and supported dependency findings within the review workflow.
In CI/CD
Run full analysis and evaluate the result against the project’s quality gate. Changes that fail defined conditions can be prevented from progressing.
At release
Retain relevant quality gate results, security reports, SBOMs, VEX records, and other technical evidence associated with the release.
During maintenance
Reanalyze maintained code, investigate newly identified dependency risks, track remediation, and verify corrective changes. This supports the continuous vulnerability-handling model expected by the CRA.
Prepare AI development for Article 14 reporting
From September 11, 2026, manufacturers must report actively exploited vulnerabilities and severe security incidents within defined timelines. Initial notification may be required within 24 hours of awareness.
AI-generated code does not create a separate reporting category, but a higher volume of change can make investigation more difficult without consistent records.
SonarQube helps teams establish:
- Visibility into affected code and components
- Consistent vulnerability information
- Component inventories and release SBOMs
- Documented dependency-risk assessments
- Remediation and verification history
- Code-level inputs for CRA reporting workflows
The organization remains responsible for determining whether an issue is reportable and submitting notifications through the EU Single Reporting Platform.
How the CRA relates to the EU AI Act, and other EU regulations
The CRA and EU AI Act address different risks. The CRA focuses on the cybersecurity of products with digital elements, while the AI Act regulates the development and use of AI systems according to their risk and purpose.
An AI-enabled product or AI platform may fall within the scope of both regulations. Depending on the organization and use case, GDPR, NIS2, and DORA may also apply.
Consistent code verification can support secure development across these regulatory programs, but it does not replace the separate legal, operational, and governance requirements of each regulation.