Red Hat maps CRA software risk beyond SBOM inventories

The EU Cyber Resilience Act is pushing software makers to treat open source dependencies as lifecycle obligations rather than entries in a software bill of materials, Red Hat argues in new guidance published October 2.

The practical consequence for platform and product teams is straightforward: an SBOM can establish what is present, but it does not show whether a dependency is maintained, how its project handles vulnerabilities or what happens if the component becomes unsustainable.

A dependency needs an owner and an exit

Red Hat's checklist asks teams to document the component and version, its origin and dependency relationships, its maintenance state, vulnerability-handling process and importance to the product. It also asks two operational questions that static inventories often leave unanswered: who can fix the component, and what is the exit strategy if it can no longer be supported.

Those answers can change the response to the same vulnerability. A deeply nested inactive library may carry a different product risk from a component that implements a critical security function. Compatibility testing, certification and release schedules can also make a nominally available upgrade impractical in production.

Red Hat describes the resulting context as “dependency intelligence.” The framing connects inventory data to decisions about compensating controls, replacement, upstream contribution and investment in project health.

CRA makes lifecycle evidence harder to defer

The guidance says the CRA requires manufacturers placing products with digital elements on the EU market to assess cybersecurity risk, handle vulnerabilities through the stated support period and specify that support period. It also distinguishes ordinary open source contributors from the act's category of open source software stewards, whose obligations are tailored to organizations providing sustained support for commercially used projects.

This is not a claim that every open source user or contributor falls into the same regulatory category. Red Hat points teams to the European Commission's 2026 guidance and says applicability depends on how software is made available and the role an organization plays.

Two remediation paths

The post names two Red Hat-backed mechanisms for gaps that inventories expose. Akrites is intended to coordinate vulnerability findings, remove duplicate reports and work with maintainers on remediation and disclosure. Lightwell is positioned for cases where a third-party component needs a security fix but an immediate upgrade would create compatibility or operational risk.

The larger platform-engineering lesson is that compliance evidence cannot stop at producing an SBOM. Teams need a repeatable ownership record for critical dependencies, a way to monitor project health and vulnerability response, and a tested replacement or mitigation path before support disappears.