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.
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 control | Engineering practice | Useful evidence |
| A.5.9 Inventory of information and associated assets | Maintain a release-linked component inventory | Dated SBOMs mapped to the deployed service |
| A.5.21 ICT supply chain | Assess and manage third-party software risk | Dependency policies, licence checks and supplier decisions |
| A.8.8 Technical vulnerabilities | Continuously identify, assess and address known flaws | SCA 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 lifecycle | Automated 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.