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.
NHIMG editorial — based on content published by Kusari: EU Cyber Resilience Act readiness, visibility gaps, and what provable security means in practice
By the numbers:
- Only 28% of teams report strong visibility into transitive dependencies, where inherited risk often hides.
- Nearly 47% of respondents spend five or more hours per week responding to software supply chain security incidents.
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.
Questions worth separating out
Q: What breaks when software teams cannot prove what they ship?
A: When teams cannot prove what they ship, compliance becomes guesswork and incident response becomes slower.
Q: Why does transitive dependency visibility matter for CRA compliance?
A: Transitive dependencies often carry the inherited risk that teams miss in direct package reviews.
Q: How do build pipelines create governance risk in software delivery?
A: Build pipelines create governance risk when they differ too widely across teams and produce inconsistent evidence.
Practitioner guidance
- Standardise release evidence across all teams Define a minimum evidence pack for every release, including component inventory, dependency lineage, security gates, and remediation traceability.
- Map transitive dependencies to production exposure Build a shared dependency graph that ties packages, libraries, and versions to specific runtime environments.
- Govern build and release identities as privileged access Treat CI/CD tokens, signing keys, deployment accounts, and pipeline service identities as privileged assets with ownership, rotation, and offboarding rules.
What's in the full article
Kusari's full article covers the operational detail this post intentionally leaves for the source:
- How the CRA maps to practical software supply chain evidence, including what auditors are likely to ask for at release time
- The specific role of SBOMs, shared dependency graphs, and automated evidence collection in demonstrating secure-by-design practices
- Why internal standardisation across pipelines matters more than isolated team-level tooling decisions
- How organisations should structure vulnerability handling and upstream contribution workflows across the product lifecycle
👉 Read Kusari's analysis of CRA readiness, dependency visibility, and software supply chain evidence →
EU Cyber Resilience Act: is your AppSec programme audit-ready?
Explore further