Open-source security is moving into a more demanding phase.

The UK Software Security Code of Practice expects software vendors to understand their third-party components, assess their risks, verify updates, and maintain them throughout the product lifecycle.

The NCSC’s June warning added urgency. Recent attacks have compromised trusted packages, maintainer accounts, and developer tooling. Automated installation can spread malicious code before a person reviews it.

Regulatory pressure is becoming operational too. The EU Cyber Resilience Act’s reporting duties for actively exploited vulnerabilities and severe incidents begin on 11 September 2026. Broader product-security obligations follow in December 2027.

Before teams set their 2027 priorities, they should be able to answer three questions.

1. Can we identify every dependency in a released product?

An inventory that stops at direct dependencies gives an incomplete picture. A small package can bring in a much larger transitive tree, and the vulnerable component may sit several layers below the one a developer selected.

The useful test is practical: when a new vulnerability is disclosed, can the team identify every affected product, version, and owner quickly?

That requires release-linked component records that stay current. An SBOM can support the process, though generating one is only the beginning.

ENISA’s 2026 survey found that 78% of responding organisations had started their SBOM journey. Only 9% described their implementation as mature and fully automated. It also found a wide gap between generating SBOMs and using them: 44% reported a moderate gap, while 23% reported a significant one.

For planning, ask whether the inventory is complete enough to guide patching and incident response. If it cannot support a decision, it is documentation rather than an operational control.

2. Who decides whether a package and version are acceptable?

A vulnerability scanner can identify a known issue. It cannot define the organisation’s full acceptance policy on its own.

Teams still need rules for package provenance, project maintenance, licences, transitive dependencies, update behaviour, and acceptable exceptions. They also need a named owner for the decision.

This matters because open-source risk now includes more than vulnerable code. The NCSC describes maintainer-account compromise, abandoned-package takeover, typosquatting, and self-propagating attacks. A newly released version can therefore carry a different kind of risk from an old, unpatched one.

A workable policy should be clear enough for developers to apply during normal delivery. It should also record exceptions with an owner and an expiry date.

3. How quickly can we act when the risk changes?

Dependency approval is temporary. A package that is acceptable today may disclose a vulnerability next month, lose its maintainer, or publish a compromised update.

Teams should measure the path from new intelligence to action:

• How quickly can they locate the affected component?
• Who assesses exploitability and operational impact?
• How long does a safe update take to reach production?
• Can they retain evidence of the decision?

The CRA’s reporting timetable makes this speed visible. From 11 September 2026, affected manufacturers must provide an early warning within 24 hours of learning about an actively exploited vulnerability or severe incident, followed by a fuller notification within 72 hours.

Those deadlines are hard to meet when ownership and component visibility are assembled after the event.

Put the first decision closer to the developer

The answers to these questions should produce a joined-up workflow.

Developers check a package and exact version before adoption. CI/CD applies the organisation’s policy and retains evidence. Continuous monitoring catches risk that appears after release. Security and product owners handle exceptions and remediation timelines.

HEIDI supports the first point in that chain. It brings known-vulnerability information and safer-version suggestions into the IDE, while the dependency is still easy to change. That early feedback should work with pipeline enforcement, SBOMs, and post-release monitoring.

A useful 2027 plan should leave each team able to identify what it ships, explain why each component is trusted, and respond quickly when that trust changes.