supply chain security

Three Open-Source Security Questions Teams Should Answer Before 2027 Planning

roseagbaw, , , , Leave a comment
3–4 minutes


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.

Infographic of the continuous open-source security cycle (Choose, Check, Record, Monitor, Respond), illustrating the EU Cyber Resilience Act requirements to provide an early warning within 24 hours of an actively exploited vulnerability or severe incident, followed by a fuller notification within 72 hours.

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.

Infographic on tracing vulnerable packages by product, version, and owner. It includes ENISA 2026 stats showing 78% of organisations have started their SBOM journey, but only 9% are fully automated, highlighting a massive gap between simply generating SBOMs and actively using them.

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.

Three Open-Source Security Questions Teams Should Answer Before 2027 Planning

Securing the Sovereign Supply Chain: ISO 27001 for the UK Public Sector

Mohammad Shahid, Leave a comment

At a time of heightened geopolitical tension and AI risk, the threat to the public sector is not discussed enough. In 2024, attackers compromised a Ministry of Defence payroll contractor in what Parliament’s House of Lords Library later described as a supply-chain ransomware attack. 

The wider threat has continued to grow. In May 2026, the NCSC managed more than 200 incidents affecting UK critical national infrastructure and its supporting ecosystem, with around 75% believed to be linked to state actors. 

For public-sector organisations, ISO/IEC 27001 therefore needs to operate as a live Information Security Management System supported by continuous technical evidence, rather than a checklist revisited before an audit.

ISO/IEC 27001 provides a risk-based framework for an information security management system. Operationalising it for software supply chain security requires engineering decisions the standard does not prescribe, including which open-source package to approve and how often to scan it.

That gap matters in the public sector, where digital services can depend on large trees of direct and transitive components.

iso 27001 for the public sector

UK guidance is becoming more explicit. The Home Office engineering standard requires teams to assess external components, maintain a discoverable dependency tree, automate vulnerability scanning and keep dependencies updated.

The 2026 Software Security Code of Practice also expects software vendors to understand composition and manage third-party component risks throughout the lifecycle. These practices turn control language into technical evidence.

Where software supply chain risk fits ISO 27001

ISO 27001 does not mandate a software bill of materials (SBOM) or software composition analysis (SCA). Both can support several Annex A controls when they are tied to ownership, risk decisions and remediation.

ISO 27001:2022 controlEngineering practiceUseful evidence
A.5.9
Inventory of information and associated assets		Maintain a release-linked component inventoryDated SBOMs mapped to the deployed service
A.5.21
ICT supply chain		Assess and manage third-party software riskDependency policies, licence checks and supplier decisions
A.8.8
Technical vulnerabilities		Continuously identify, assess and address known flawsSCA results, triage records, fixes and approved exceptions
A.8.25, A.8.28 and A.8.29
Secure development, coding and testing		Run security checks within the development lifecycleAutomated scans, CI/CD gates and retained build reports

An SBOM is an inventory, rather than a security control on its own. The NCSC recommends generating a new SBOM with each build and pairing it with vulnerability scanning. An inaccurate or stale inventory can create false assurance.

Move from an audit snapshot to continuous evidence

A periodic scan becomes stale when a dependency changes or a new vulnerability is disclosed. A practical workflow places checks at three points:

  • Before selection: developers verify the exact package and version before adding it. HEIDI brings known-vulnerability information and suggested safe versions into the IDE, including when an AI coding assistant proposes an unfamiliar dependency.
  • During the build: BOSS scans direct and transitive dependencies, identifies licence risks and outdated components, generates an SBOM and applies policy gates in CI/CD.
  • After release: teams rescan component inventories as vulnerability intelligence changes, record patch decisions and track exceptions. BOSSC extends the same visibility to components inside container images.

What auditors and security teams need to see

The useful output is a repeatable evidence trail, rather than a dashboard viewed once before an audit. Retain:

  • A dated SBOM for each relevant build or release.
  • Scan results linked to triage decisions and service owners.
  • Remediation tickets, accepted risks and time-bound exceptions.
  • Proof that CI/CD policies ran and blocked releases when thresholds were exceeded.


This supports the wider direction of UK public-sector guidance. In May 2026, the government told departments operating public code to use dependency-update tooling, vulnerability scanning and patching timelines that teams can demonstrate.

AI-assisted discovery may shorten the time between a weakness appearing and exploitation, which makes rapid remediation more important.

Operationalising the controls with Meterian

Meterian BOSS supports continuous SCA, SBOM generation and CI/CD policy enforcement. HEIDI moves the first check into the developer’s workflow, while BOSSC covers container images.

Together, these controls help public-sector teams reduce the time between vulnerability disclosure and remediation while keeping evidence ready for ISO 27001 reviews.

A sensible starting point is one service: generate an SBOM on every build, set risk-based patch timelines, enforce a pipeline threshold and measure time to remediation. Once the process works, extend it across the application estate.

Securing the Sovereign Supply Chain: ISO 27001 for the UK Public Sector