Topic starter
18/08/2026 2:47 pm
TL;DR: The EU Cyber Resilience Act shifts software security from intent to evidence, and Kusari argues that most organisations are not yet able to prove what they ship, where vulnerable dependencies run, or how quickly they can respond. That gap turns dependency visibility, shared build controls, and continuous evidence collection into compliance-critical capabilities.
Editorial analysis by NHI Mgmt Group, based on content published by Kusari: “Why the EU Cyber Resilience Act Will Catch US Software Companies Off Guard”.
By the numbers:
- Only 28% of teams report strong visibility into transitive dependencies, where most inherited risk hides.
- Nearly 47% of respondents spend five or more hours per week responding to software supply chain security incidents.
Key questions
Q: How should teams make AppSec evidence audit-ready for the EU Cyber Resilience Act?
A: Teams should design evidence capture into the software lifecycle, not bolt it on at the end.
Q: Why do fragmented build pipelines create CRA compliance risk?
A: Fragmented pipelines produce inconsistent controls, which means the organisation cannot prove that every team applies the same security assumptions.
Q: What fails when teams rely on SBOMs without runtime context?
A: Teams lose the ability to tell which dependencies are actually active, reachable, or exploitable.
Practitioner guidance
- Build a dependency graph that spans source, build, and runtime Link declared components to transitive dependencies and deployed environments so teams can answer where a vulnerable version is actually running.
- Standardise security controls across build pipelines Define common approval, attestation, and release-gate requirements so each team produces comparable evidence regardless of tooling.
- Automate post-release vulnerability ownership Assign clear ownership for customer notification, patch tracking, and upstream fix contribution so remediation continues after software leaves the build stage.
Bottom line: The CRA makes software assurance measurable, which means security claims must be supported by traceable evidence across the build and release lifecycle.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
18/08/2026 3:29 pm
Provable security is now a software governance discipline, not an AppSec slogan. The CRA forces organisations to connect design intent with operational evidence, and that changes what counts as control maturity. If a team cannot show what it ships, where it runs, and how it is remediated, it does not have a compliance story. Practitioners should treat evidence quality as part of the control itself.
A few things that frame the scale:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
- Breaches involving third parties rose to 48% of all breaches, a 60% increase on the previous year, according to Verizon's 2026 Data Breach Investigations Report.
A question worth separating out:
A: Security teams should treat CRA compliance as a product control problem, not only a policy exercise. Build security into design, code, testing, release gating, and runtime monitoring. Focus on shipping without known exploitable vulnerabilities, maintaining an SBOM, proving secure-by-default settings, and documenting evidence for audits and reporting obligations. Continuous checks work better than one-time assessments.
👉 Read our full editorial: EU Cyber Resilience Act turns AppSec visibility into provable security