Cyber resilience act readiness depends on codebase controls now

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Sonar's blog post: Cyber Resilience Act readiness is a codebase control problem, with secure defaults, release traceability, pre-merge checks and runtime testing forming the core evidence for reporting and compliance.

Why it matters: For IAM and security practitioners, the key lesson is that compliance evidence now has to be generated inside developer and AI-assisted workflows, especially where software release controls affect identity, access and trust decisions.

Context

The governance gap here is not whether products ship code, but whether manufacturers can prove that security controls are embedded before release and can be evidenced later. Under the Cyber Resilience Act, reporting obligations create a deadline-driven need for traceability, testing and enforcement that cannot rely on manual recall after an incident.

In practical terms, the article is about codebase governance for products with digital elements: secure defaults, pre-merge review, dependency traceability, misuse testing and runtime verification. That is primarily a software security problem, but it also intersects with identity because release controls, secrets, authentication behaviour and AI-assisted coding workflows all affect how access and trust are governed.

Key questions

Q: What breaks when secure defaults are not built into software releases?

A: When secure defaults are missing, the product ships in a state that depends on customers or operators to close the gap later. That weakens the manufacturer’s ability to show preventive control, increases the chance of exploitable misconfiguration and makes post-incident explanation harder because the unsafe state was present at release.

Q: Why do traceability and dependency inventory matter for Cyber Resilience Act reporting?

A: They determine whether a manufacturer can identify exactly which release, component or build path was affected by an exploited vulnerability or severe incident. Without that lineage, scope analysis becomes guesswork, remediation is slower and the organisation may struggle to defend the timeliness and adequacy of its response.

Q: How do security teams know if pre-merge checks are actually preventing risk?

A: They know it is working when unresolved findings cannot move into the main branch or release pipeline and when exceptions are rare, documented and time-bound. If insecure code still reaches production, the control is acting as a detector, not an enforcement mechanism.

Q: How should organisations govern AI tools that analyse source code?

A: Set evidence thresholds, require secondary validation for high-impact findings, and define who owns the final decision. Governance should cover prompt scope, output format, reviewer sign-off, and auditability. That keeps AI in an advisory role and prevents noisy model output from becoming an unreviewed security decision.

Technical breakdown

Secure defaults and release traceability in CRA readiness

Secure defaults mean the shipped product starts in a constrained state, with risky capabilities disabled unless intentionally enabled. Release traceability means each build can be mapped back to source, dependencies and inputs, so the organisation can identify affected versions when a vulnerability or incident appears. Together, they turn a product release into an auditable security object rather than an opaque software artefact. For CRA readiness, that matters because regulators will expect manufacturers to explain what was shipped, what was exposed and why a control failed if exploitation occurs.

Practical implication: tie secure-by-default settings to build and release records so affected versions can be proven quickly.

Pre-merge security checks and enforcement gates

Pre-merge checks are the control point where insecure code, misconfigurations and weak authentication logic can be stopped before they reach the main branch. Enforcement gates raise that from detection to prevention by blocking release when serious findings remain unresolved. In CRA terms, this is the difference between a vulnerability that is merely discovered and one that is allowed to become part of a marketed product. The article’s core point is that control strength depends less on finding issues than on making unresolved issues unable to progress.

Practical implication: make merge and release gates fail closed for unresolved security findings that could reach customers.

Runtime security behaviour and evidence of effective testing

Runtime security behaviour is what the product actually does under stress, misuse or attack. Release tests need to verify that update integrity, rollback protection, isolation, secure deletion and resilience behave as intended, not just that the code compiles or passes unit tests. This is a deeper assurance layer than static analysis because it checks whether controls survive contact with real execution conditions. For regulated products, that runtime evidence helps determine severity, corrective action and whether an incident meets reporting thresholds.

Practical implication: add tests that exercise security behaviour at runtime, not just code correctness before shipment.

Threat narrative

Attacker objective: The attacker aims to turn a code-level weakness into exploitable product behaviour that affects customer environments and creates regulatory reporting exposure.

1. Entry occurs when insecure defaults, weak validation or unmanaged dependency changes enter the codebase and survive normal development flow.
2. Escalation follows when security-sensitive changes are not recognised or tested, allowing a defect to become releasable product behaviour.
3. Impact occurs when the shipped product contains an actively exploitable weakness or severe incident condition that triggers CRA reporting duties.

Breaches seen in the wild

• Sisense breach 2024: A credential in Sisense's GitLab reportedly opened S3 buckets of customer tokens, passwords and certificates; CISA urged a full reset.
• United Nations breach 2021: Sakura Samurai used exposed Git credentials to reach 100,000+ UNEP staff records, then reported the flaw through the UN disclosure programme.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

CRA readiness is now a codebase governance problem, not a post-incident documentation exercise. The article makes a strong case that reportability depends on whether security evidence already exists in the build and release pipeline. That changes compliance from a paperwork function into a control-design question. Practitioners should treat release traceability and fail-closed gates as audit evidence, not optional engineering polish.

Secure defaults are the named control gap most likely to define early CRA failures. If a product relies on operators or customers to harden an unsafe initial state, the manufacturer has already lost part of the compliance argument. That is a classic governance weakness because it shifts risk out of the product boundary and into hope. Practitioners should make default security settings part of release acceptance criteria.

Runtime verification closes the gap between code review and real product behaviour. Static scanning can show that a control exists in source, but it cannot prove that rollback protection, isolation or update integrity still works at execution time. This is where the article’s control model becomes operationally meaningful. Practitioners should use runtime evidence to validate that security claims survive deployment.

CRA is forcing identity and software assurance to overlap inside the development lifecycle. The article’s discussion of AI coding agents and release enforcement shows that identity is no longer only about users and admins. It now includes who or what is permitted to change code, approve it and ship it. Practitioners should govern AI-assisted development with the same access, review and evidence standards as human delivery.

Release traceability is the specific governance concept that makes regulated remediation possible. Without exact source, build and dependency lineage, manufacturers cannot reliably determine affected versions, prove scope or support timely reporting. That is not a tool problem alone. Practitioners should make traceability a prerequisite for claiming CRA readiness.

From our research library:

• Organisations that rely heavily on static credentials reported a 20-percentage-point increase in security incidents compared with those with low reliance, according to the 2026 Infrastructure Identity Survey.
• Read next: Identity Security Regulatory Map

What this signals

Codebase evidence will become the compliance boundary for product security teams. Manufacturers that cannot show secure defaults, traceability and enforced checks inside the delivery pipeline will struggle to defend their readiness position once reporting obligations bite. The practical shift is from documenting controls after release to proving them before release.

Release traceability is the control that turns remediation into accountability. Once a product is fielded, teams need to know which build, dependency and code path is implicated before they can explain impact or corrective action. That is why code lineage now belongs in the same governance conversation as vulnerability management and change control.

Static credentials still widen incident exposure in delivery environments. Organisations that rely heavily on static credentials reported a 20-percentage-point increase in security incidents compared with those with low reliance, according to the 2026 Infrastructure Identity Survey. For practitioners, that reinforces why secrets handling and release-path identity controls must be part of CRA readiness, not a side concern.

For practitioners

• Define CRA evidence controls in the release path Map secure defaults, dependency traceability, security-sensitive change review and runtime tests to specific release checkpoints so they can be evidenced during audits.
• Block release when serious findings remain open Make quality gates and pull request checks fail closed when unresolved security issues would allow risky code or dependencies into a shipped product.
• Trace every build back to source and inputs Maintain a verifiable link from each release to source code, build artefacts and third-party dependencies so impacted versions can be identified quickly.
• Test security behaviour at runtime Exercise update integrity, rollback protection, isolation and hostile-input handling in release tests so security claims are validated in execution, not just in code review.
• Govern AI-assisted code changes with human approval boundaries Require AI-generated changes to pass the same review, identity and evidence controls as human-authored code before merge or release.

Key takeaways

• CRA readiness for products with digital elements depends on proving security controls inside the codebase and release pipeline, not just documenting them after defects appear.
• Secure defaults, traceability, pre-merge checks and runtime validation are the controls that determine whether vulnerabilities remain theoretical or become reportable incidents.
• The CRA pushes product security, identity governance and developer workflow enforcement into the same operating model, especially where AI-assisted code changes are involved.

Key terms

• Security Defaults: Baseline identity and access configurations that reduce exposure before advanced tooling is added. They are especially valuable in fragmented environments because they establish minimum protections, consistent logging, and safer starting conditions for both human and machine identities.
• Identity Traceability: Identity traceability is the ability to link each action back to a specific identity, authorisation path, and time window. It is essential when humans, service accounts, and AI agents all operate in the same environment and auditors need a defensible record.
• Pre-Merge Security Control: A pre-merge security control is any check that evaluates code before it enters the main branch or release path. In practice, it is most effective when it is contextual, low-noise, and embedded in the same review flow that developers already use for acceptance decisions.
• Runtime Security: Runtime security is the practice of detecting and constraining malicious behavior while software is executing. It focuses on live workload activity, not just code quality or pre-deployment checks, so teams can contain abuse after a system is already running.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security and secrets management in the context of modern delivery pipelines. It is a fit for practitioners who need to connect identity controls to engineering workflows and audit evidence.