Notifications
Clear all
Topic starter
18/08/2026 2:56 pm
TL;DR: CRA readiness depends on operational controls across the software supply chain, from SBOMs and CI/CD hardening to policy-driven deployment governance, because documentation alone will not satisfy auditors or reduce exposure, according to Kusari. The core shift is from checklist compliance to measurable traceability, accountability, and enforced security across development pipelines.
NHIMG editorial — based on content published by Kusari: a practical roadmap for EU Cyber Resilience Act readiness
Questions worth separating out
Q: How should organisations enforce CRA-ready controls in CI/CD pipelines?
A: They should combine least-privilege build access, signed artifacts, policy-as-code, and automated verification at release time.
Q: Why do software supply chains need identity governance for CRA compliance?
A: Because build accounts, signing keys, deployment tokens, and artifact permissions control whether software can be trusted at all.
Q: What fails when SBOMs are generated only once per release cycle?
A: They stop reflecting the real dependency state of the shipped product as soon as packages change, vulnerabilities emerge, or build inputs shift.
Practitioner guidance
- Baseline the software supply chain end to end Map first-party code, third-party dependencies, build systems, artifact stores, and deployment paths so you can identify where trust is created and where it is inherited.
- Govern build identities and secrets as production-grade assets Apply least privilege, rotation, and lifecycle ownership to CI/CD service accounts, signing keys, and automation tokens, because compromised build identities can alter shipped software.
- Automate SBOM generation and reconciliation Generate SBOMs on every meaningful release, reconcile them against dependency changes, and retain evidence that the inventory matched the deployed artifact at release time.
What's in the full article
Kusari's full guide covers the operational detail this post intentionally leaves for the source:
- A step-by-step CRA readiness roadmap for software-producing organisations across code, build, and deployment workflows
- Specific SBOM implementation expectations, including transitive dependency mapping and continuous update processes
- Recommended control patterns for CI/CD hardening, signed builds, and binary authorization enforcement
- Practical documentation and audit-trail requirements for proving accountability during compliance reviews
👉 Read Kusari's CRA readiness guide for software supply chain controls →
EU Cyber Resilience Act readiness: what software teams need to change?
Explore further
18/08/2026 3:39 pm
CRA compliance is becoming an identity governance problem as much as a software assurance problem. The article rightly treats build access, artifact trust, and secret handling as core compliance issues, because those controls determine whether software provenance can be trusted at all. In modern delivery pipelines, privileged build identities and machine secrets are part of the attack surface, not plumbing. Practitioners should therefore align CRA readiness with IAM, PAM, and NHI governance rather than leaving it isolated in engineering.
A question worth separating out:
Q: Who is accountable when unsigned software reaches production?
A: Accountability sits with the owners of the release process, the platform controls, and the governance team that allowed the exception path to exist. In software supply chains, release integrity is an operating model issue, not just a development issue. NIST Cybersecurity Framework 2.0 helps structure that accountability across govern, protect, and respond.
👉 Read our full editorial: EU Cyber Resilience Act readiness means governing software supply chains
