Notifications
Clear all
Topic starter
18/08/2026 2:53 pm
TL;DR: 2026 will force software teams to accept real accountability for open source, security standards, and AI-produced code as the EU Cyber Resilience Act, insurance pressure, and software complexity converge, according to Kusari. The practical shift is toward measurable governance, least-privilege AI use, and contextual visibility, not SBOM-only compliance.
NHIMG editorial — based on content published by Kusari: the 2026 accountability shift across open source, AI, and CRA pressure
Questions worth separating out
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.
Q: Why are SBOMs not enough to secure the software supply chain?
A: SBOMs improve visibility into what is inside a package, but they do not prove who built it or whether the build was tampered with.
Q: What do teams get wrong about AI security and access management?
A: Teams often treat AI security as a data classification problem alone.
Practitioner guidance
- Map software accountability to named owners Assign a human owner for every repository, pipeline, and AI-assisted workflow that can introduce code or configuration changes.
- Add reachability context to component inventories Move beyond SBOM-only reporting by adding dependency reachability, exposure paths, and exploitability context.
- Standardise minimum secure development controls Adopt a common baseline for code review, automated checks, secret handling, and escalation so every team produces comparable evidence.
What's in the full article
Kusari's full article covers the operational detail this post intentionally leaves for the source:
- Specific examples of how Kusari expects CRA accountability to affect software teams working with open source dependencies
- The practical shape of OSPS-aligned controls and how organisations are using them to reduce delivery variance
- The article’s broader view of AI security as a governed software discipline, including policy and review boundaries
- How insurance pressure is changing expectations for AI-driven products and accountable engineering
👉 Read Kusari's analysis of CRA, open source accountability, and AI security →
EU CRA, open source risk, and AI accountability: what changes now?
Explore further
18/08/2026 3:36 pm
Software accountability is becoming an identity problem as much as a compliance problem. Once AI-generated code, third-party libraries, and automated pipelines can all introduce change, the real control point becomes who or what is authorised to alter the system. That shifts attention from static policy documents to governed identities, approvals, and traceable execution paths. Practitioners should treat software supply chain accountability as a privilege and identity governance issue, not just a build-time assurance task.
A question worth separating out:
Q: Which controls matter most for reducing exposure across software supply chains?
A: The most effective controls combine accurate inventory, rapid containment, validated remediation and ownership for every critical dependency. Teams should also map which non-human identities and secrets are tied to vulnerable applications, because exploit impact is often driven by what the software can reach, not just by the code defect itself.
👉 Read our full editorial: EU CRA and AI security accountability are converging in 2026
