OSS governance has always been an engineering problem. The EU CRA just set a deadline for it.

Most existing SBOM processes only capture direct dependencies. The risk the EU CRA is most concerned with sits largely in transitive dependencies, and the SBOM itself needs to be machine-readable and kept current as your dependency graph changes, not a point-in-time export.

Generally, yes. They pull open source packages into your build path faster than a team can vet them manually, and every unvetted package, plus its own transitive dependencies, widens the gap between what's actually running in production and what your organization could defend in an audit.

It's the evidence set a conformity assessment runs on: risk assessments, test records, SBOM data, and vulnerability handling history, accumulated throughout the product lifecycle rather than assembled after the fact. Engineering generates most of the underlying artifacts, build records, dependency data, and remediation history, so most of the ongoing work of keeping that file current lands on engineering.

The EU CRA requires manufacturers to commit to, and disclose, the period during which a product will receive security updates. That has to be budgeted and decided in advance, not improvised reactively once a vulnerability turns up in a component whose maintainer has already stopped patching.

You could. The honest framing is that it's an ongoing resourcing commitment, continuous SBOM maintenance, provenance tracking, remediation SLAs, not a one-time project. The question worth asking internally is whether engineering has the standing capacity to run that indefinitely, or whether it competes with roadmap work every release after December 11, 2027.