Notifications
Clear all
Topic starter
14/09/2026 10:09 am
TL;DR: Cyber Resilience Act readiness now hinges on whether manufacturers can prove secure defaults, traceability, pre-merge checks, and runtime security behaviour across codebases before the 2026 reporting deadline, according to Sonar. The governance lesson is that compliance evidence must be built into development workflows, not assembled after defects surface.
NHIMG editorial — based on content published by Sonar: Cyber resilience act readiness depends on codebase controls now
By the numbers:
- 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, with 46% confirmed and 26% suspected.
Questions worth separating out
Q: What fails when secure defaults are not encoded in a product release process?
A: When secure defaults are missing, the product can ship in a state that depends on operators or customers to fix risky settings later.
Q: Why does traceability of source, build inputs, and dependencies matter for CRA reporting?
A: Traceability lets teams identify which releases are affected, which components are implicated, and what corrective action is required.
Q: How should security teams govern AI-generated code in production environments?
A: Security teams should treat AI-generated code as normal production code with extra provenance risk.
Practitioner guidance
- Map each CRA reporting trigger to a specific evidence source Link actively exploited vulnerability and severe incident scenarios to the logs, test results, issue records, and build metadata that will support notification decisions and audit review.
- Block release when security-critical findings remain unresolved Configure quality gates and approval workflows so serious issues stop the build or release rather than merely creating a backlog item.
- Trace every shipped build to source and dependency inputs Preserve provenance for each release so affected versions, third-party components, and corrective actions can be identified quickly when a vulnerability emerges.
What's in the full article
Sonar's full article covers the operational detail this post intentionally leaves for the source:
- Seven assessment questions with control maturity thresholds for CRA readiness
- How SonarQube, Sonar Vortex, and CI/CD enforcement are positioned inside developer workflows
- Examples of evidence artefacts used to support release traceability, testing, and remediation records
- The article's sequencing guidance for prioritising gaps ahead of the 2026 and 2027 deadlines
👉 Read Sonar's CRA readiness guide for codebase security and reporting controls →
Cyber resilience act readiness: are your codebase controls enough?
Explore further
14/09/2026 10:10 am
CRA readiness is really release-governance readiness. The article frames compliance through codebase questions, but the deeper issue is whether organisations can prevent unsafe software from shipping and prove that they did. That aligns with broader supply-chain governance principles in NIST CSF and secure development control sets, where evidence and enforcement matter as much as design intent. Practitioners should treat release gates, build provenance, and exception handling as part of security governance, not engineering housekeeping.
A question worth separating out:
A: Functional tests show that code does what it was intended to do, while security behaviour tests show how it behaves under misuse, hostile input, or failure conditions. CRA readiness depends on both, because a feature that works in normal use can still expose exploitable weakness at runtime. Security testing is therefore a release evidence control, not an optional extra.
👉 Read our full editorial: Cyber resilience act readiness depends on codebase controls now
