Services / Supply Chain Security & Software Bill of Materials
Every organisation runs software it did not write. In most organisations, this software is running on production infrastructure, processing sensitive data, and performing security-critical functions — and the organisation does not have a complete inventory of what it is, where it came from, who maintains it, or whether any of it has known vulnerabilities or has been compromised. The dependency graph of modern software makes this not a governance failure but a structural condition: a typical enterprise application has 200–500 direct and transitive dependencies, each of which has its own dependency graph, its own maintenance status, and its own exposure to the supply chain attacks that have made third-party software components the most productive attack surface in the threat landscape.
SolarWinds demonstrated that trusted software distribution channels can be compromised to deliver backdoored updates to 18,000 organisations simultaneously. XZ Utils demonstrated that a patient adversary can spend two years establishing trust as an open-source maintainer before inserting a backdoor into a cryptographic library used by millions of systems. Log4Shell demonstrated that a vulnerability in a library most organisations did not know they were running was present in systems across every sector simultaneously. Each of these incidents exploited the same structural gap: organisations assumed that software they had not audited was safe because it came from a trusted source or was widely used. Neither assumption holds.
This service establishes the software supply chain security programme that transforms an organisation’s relationship with its software dependencies from assumed-trusted to continuously-verified: comprehensive Software Bill of Materials (SBOM) generation and maintenance, vulnerability management integrated with the dependency inventory, provenance verification for software artefacts, secure software development lifecycle (SSDLC) integration, third-party supplier security assessment, and the governance processes that keep the programme effective as the dependency landscape evolves. It satisfies the SBOM requirements of US Executive Order 14028, DORA Article 28 ICT third-party risk management, UK NCSC software supply chain guidance, and the emerging SBOM mandates in UK and EU procurement.
Price Range
£24,000 – £220,000+
SBOM programme design, dependency inventory, vulnerability management integration, SSDLC specification, and supplier assessment framework. Toolchain implementation is additional.
SBOM programme design, dependency inventory, vulnerability management integration, SSDLC specification, and supplier assessment framework. Toolchain implementation is additional.
Duration
6 – 20 weeks
Programme design phase. Full SBOM programme operationalisation typically adds 3–12 months of implementation and integration work.
Programme design phase. Full SBOM programme operationalisation typically adds 3–12 months of implementation and integration work.
Standards
US EO 14028 · NTIA SBOM minimum elements · CycloneDX 1.5 · SPDX 2.3 · DORA Article 28 · NCSC software supply chain guidance · NIST SSDF (SP 800-218) · SLSA framework · OpenSSF Scorecard
Formats
CycloneDX (recommended for security use cases) and SPDX (licence compliance focus) — both produced where procurement or regulatory requirements specify a format
Contract
Fixed-price. 50% on signing, 50% on delivery acceptance.
An SBOM that is not maintained is not a security controlA point-in-time SBOM snapshot satisfies a compliance checkbox. It does not provide ongoing supply chain security visibility. Dependencies change with every build. New vulnerabilities are published daily. Maintainers abandon projects. Packages are typosquatted. The SBOM that was accurate when it was generated is wrong by the time it is reviewed. An SBOM programme is a continuous process, not a document. The compliance requirement is for the programme, not the snapshot.
The Software Supply Chain Attack Surface — Six Attack Categories
Six attack categories. Each exploits a different trust relationship in the software supply chain. Each requires a different detection and prevention approach.
Software supply chain attacks are the fastest-growing category of cyber attack by both frequency and impact. They are attractive to adversaries for a structural reason: a single successful compromise of a widely-used component creates simultaneous access to every organisation that uses it, multiplying the return on the adversary’s investment by orders of magnitude relative to individual organisation targeting. The categories below represent distinct attack patterns that require distinct defences; treating them as a single problem produces defences against none of them.
Attack Category 1
Build System Compromise — Injecting Malicious Code at Compilation
The adversary compromises the software vendor’s build system — the infrastructure that compiles source code into the binary artefacts distributed to customers. Malicious code is injected into the build process after the source code passes code review, meaning that the source code repository contains no malicious content, all code reviews find nothing suspicious, and the binary output distributed to customers contains malicious code that was never in any source file a human reviewed. This attack exploits the assumed-trusted relationship between source code and built artefacts.
Definitive example: SolarWinds Orion (2020)
The SUNBURST backdoor was injected into the SolarWinds Orion build process. The source code was clean; the build system was compromised. The compiled update package contained the backdoor. 18,000 organisations installed a cryptographically signed, vendor-distributed update that contained an NSA-attributed nation-state backdoor. The signing certificate validated that the package came from SolarWinds. It did not validate that the source code was unmodified during compilation. No source code review would have found the attack.
Detection and prevention approach
Reproducible builds: building the same source code twice should produce bit-identical output. If it does not, the build process is not deterministic and cannot be trusted. SLSA (Supply-chain Levels for Software Artefacts) framework: a set of requirements for build system security ranging from SLSA 1 (provenance attestation) to SLSA 4 (hermetic, reproducible, two-party reviewed build). Artefact signing with Sigstore/cosign: cryptographic attestation that a build artefact was produced by a specific CI/CD pipeline at a specific commit. Binary composition analysis: comparing compiled artefacts against the expected output of clean source compilation to detect unexpected code.
Attack Category 2
Dependency Confusion & Typosquatting — Malicious Packages in Trusted Registries
Package managers that resolve dependencies from public registries (npm, PyPI, Maven, NuGet, RubyGems) can be manipulated in two related ways. Typosquatting: publishing a malicious package with a name that closely resembles a legitimate popular package (colour vs color, requests vs request, lodash vs 1odash). A developer mistyping a package name or a build system configured with a typo installs the malicious package. Dependency confusion: exploiting the resolution order of package managers that check both private and public registries by publishing a package with the same name as an internal private package but a higher version number on the public registry, causing the package manager to prefer the malicious public version over the legitimate internal version.
Dependency confusion at scale (2021)
A security researcher demonstrated dependency confusion by publishing packages to npm and PyPI with the same names as internal packages identified from public JavaScript files at Apple, Microsoft, PayPal, Netflix, Uber, and dozens of other large organisations. Build systems at these organisations automatically downloaded and executed the researcher’s packages, executing his proof-of-concept payload. He received bug bounty payments totalling over $130,000. Malicious actors performing the same research with a malicious payload would have had code execution inside the build systems of over 35 major organisations.
Detection and prevention approach
Private registry with mirror and allow-list: all dependencies resolved from a private registry that mirrors approved public packages. New packages are vetted before being added to the allow-list. Dependency pinning: lock files (package-lock.json, Pipfile.lock, requirements.txt with exact hashes) that specify the exact version and cryptographic hash of every dependency. Namespace ownership: organisations using private packages register their namespace on public registries to prevent dependency confusion. Automated scanning for new typosquatting packages that match the organisation’s dependency inventory.
Attack Category 3
Maintainer Compromise & Account Takeover — Hijacking Trusted Upstream Projects
Open-source packages are maintained by individuals who, in many cases, are single maintainers working in their personal time with no security hardening on their accounts. Compromising a maintainer’s account — through credential theft, phishing, or SIM swapping — gives the adversary the ability to publish malicious package updates that are automatically distributed to every project that declares the package as a dependency. The adversary exploits the trust relationship between downstream projects and the maintainer’s account, which is assumed to publish only legitimate updates.
event-stream (2018) and ua-parser-js (2021)
The event-stream npm package (2 million weekly downloads) was transferred to a new maintainer who then added a malicious dependency targeting a specific Bitcoin wallet application. The ua-parser-js package (7 million weekly downloads) had its maintainer account compromised; three malicious versions were published that installed cryptomining and credential-stealing software on developer and CI/CD systems that ran npm install. In each case, the malicious code arrived through the same mechanism as legitimate updates: a published version from the authoritative maintainer account.
Detection and prevention approach
Dependency pinning to exact hash: a compromised maintainer cannot push an update that automatically affects pinned dependencies because the hash no longer matches. Policy-based update approval: dependency updates require review and explicit approval before entering the build rather than being automatically consumed. Maintainer health monitoring: tracking the OpenSSF Scorecard and security posture of critical dependencies’ maintainers, alerting when maintainer account MFA status or project activity patterns change in ways consistent with compromise. Dependency risk scoring weighted by download count, maintainer count, and last activity date.
Attack Category 4
Social Engineering of Maintainers — Long-Term Trust Building
The most sophisticated supply chain attacks do not compromise accounts — they compromise maintainers. An adversary creates a persona, contributes legitimate code to a project for months or years, builds a trusted reputation, is granted commit access, and then uses that access to insert a backdoor. This attack is resistant to technical controls because it exploits the social trust structure of open-source development: contributions are evaluated by humans, reviewer fatigue creates opportunities for subtle malicious commits to pass undetected, and the long trust-building period makes the eventual attack difficult to attribute to a deliberate programme rather than an honest mistake by a trusted contributor.
XZ Utils (2024) — the definitive case
An adversary operating as “Jia Tan” spent approximately two years contributing to XZ Utils, a compression library present in virtually every Linux distribution. The contributions were legitimate and high-quality. Jia Tan gradually took on maintainer responsibilities. In early 2024, a carefully obfuscated backdoor was added that modified the SSH authentication process in systemd-linked OpenSSH, allowing unauthorised remote code execution on affected systems. The backdoor was discovered by a Microsoft engineer who noticed anomalous CPU usage during routine investigation — not through any security scanning. XZ Utils was days away from being included in major Linux distributions’ stable releases.
Detection and prevention approach
No technical control reliably detects this attack before the malicious commit. Mitigations focus on reducing the blast radius when it occurs: dependency pinning so malicious updates are not automatically consumed, staged rollout of dependency updates through dev/staging before production, binary composition analysis to detect unexpected code in compiled artefacts relative to source, runtime monitoring for anomalous behaviour consistent with backdoor activation, and rapid response process for supply chain incidents affecting critical dependencies.
Attack Category 5
Known Vulnerability Exploitation — Unpatched Dependencies
The most common supply chain risk is not sophisticated targeted attack — it is the routine exploitation of known vulnerabilities in unpatched dependencies. CVEs are published daily across the open-source ecosystem. An application that depends on a vulnerable library version is exploitable from the moment the CVE is published, and remains exploitable for as long as the vulnerable version is in use. The gap between publication and exploitation has decreased significantly: some vulnerabilities are weaponised within hours of CVE publication. Organisations without an SBOM-driven vulnerability management process are discovering their exposure reactively — when a critical CVE is published and they do not know if they are affected.
Log4Shell (CVE-2021-44228)
Log4j 2 is a widely-used Java logging library. The Log4Shell vulnerability allowed remote code execution by logging a malicious string. Within 72 hours of disclosure, mass scanning and exploitation was observed. Every organisation running any Java application that used Log4j 2 (directly or transitively) was at risk. Organisations without an SBOM did not know whether they were affected. Log4j 2 appears as a transitive dependency of many applications whose developers had no direct relationship with the Log4j project — it was included because a dependency of their dependency used it. Discovery without SBOM required manual inventory of every application, which took weeks for large organisations during active exploitation.
Detection and prevention approach
Continuous SBOM-driven vulnerability scanning: every dependency in the SBOM checked against CVE databases (NVD, OSV, GitHub Advisory Database) continuously, not just at build time. Alert within hours of a new CVE being published for any affected dependency in the inventory. Defined SLAs for vulnerability remediation by severity: critical CVEs remediated within 24–72 hours, high within 7 days, medium within 30 days. Reachability analysis to prioritise: is the vulnerable code actually called in the application’s execution paths? False-positive reduction from reachability analysis reduces remediation burden without reducing coverage.
Attack Category 6
Third-Party Service Compromise — Attack via Managed Services and SaaS
The software supply chain includes not just code dependencies but the services that production systems depend on: CI/CD platforms, secrets management services, identity providers, CDNs, monitoring agents, and the SaaS tools embedded in the development and operations workflow. Each of these services has privileged access to the organisation’s systems — CI/CD pipelines have access to source code, build credentials, and deployment targets; monitoring agents run with elevated privileges on production systems; CDN providers serve the organisation’s customer-facing content. Compromising any of these services gives an adversary access equivalent to the service’s own access level across all the service’s customers simultaneously.
CircleCI (2022–2023) and Codecov (2021)
In the CircleCI incident, an attacker compromised an engineer’s laptop, used the session token to access production systems, and exfiltrated customer secrets — API keys, access tokens, and other credentials stored in CI/CD pipelines. In the Codecov incident, a bash uploader script distributed by Codecov was modified to exfiltrate environment variables (including secrets) from CI/CD pipelines that used it. Both incidents gave the adversary access to the credentials of every affected organisation’s CI/CD environment. Organisations with the most secrets in their CI/CD pipelines — typically those with the most complex build and deployment processes — were most exposed.
Detection and prevention approach
Principle of least privilege for all third-party service integrations: CI/CD pipelines have only the permissions they need for the specific build and deploy operations they perform. Secrets minimisation: long-lived credentials in CI/CD pipelines replaced with short-lived OIDC tokens issued at build time. Third-party service security assessment: SSCA (Software Supply Chain Assessment) for all services with privileged access to production systems. Anomalous access detection: monitoring for access patterns from third-party services that deviate from their established baseline, alerting when a monitoring agent, CI/CD platform, or CDN performs actions outside its normal behaviour pattern.
What a Complete SBOM Programme Requires
Seven programme components. The SBOM document is one of them. The rest are what make it a security control rather than a compliance artefact.
An SBOM generated once and filed is not a security programme. It is a compliance document. The security value of an SBOM is in its continuous use: scanning new vulnerabilities against the current dependency inventory, detecting when dependencies change in ways that introduce new risk, verifying that the artefacts deployed to production match the artefacts produced from reviewed source code. All of this requires the SBOM to be integrated into the build pipeline, the vulnerability management process, and the deployment verification workflow — and to be maintained with every build rather than generated periodically as a compliance exercise.
Component 1
SBOM Generation & Pipeline Integration
The SBOM must be generated automatically at every build from the build artefacts themselves — not from the declared dependencies in package manifest files, which may not reflect what was actually resolved and included. Generation from artefacts (binary composition analysis) captures transitive dependencies that manifest files do not declare, detects discrepancies between declared and actual dependencies, and produces an SBOM that reflects the built product rather than the intended product.
Programme elements
SBOM tooling selection and integration: Syft, cdxgen, or Microsoft sbom-tool integrated into the CI/CD pipeline at the post-build stage
Format selection: CycloneDX 1.5 for security-focused use cases; SPDX 2.3 for licence compliance or when procurement contracts specify SPDX
SBOM depth specification: which layers of the dependency graph are included (direct only, transitive, all), calibrated to the organisation’s risk appetite and tooling capability
SBOM storage and versioning: every build’s SBOM stored alongside the build artefact with the same version identifier, enabling retrospective analysis of what was running at any point in time
Multi-language and multi-ecosystem coverage: Java, Python, JavaScript/Node, Go, Rust, .NET — each language ecosystem has different SBOM tooling requirements and coverage characteristics
Why artefact-based generation matters
A manifest-based SBOM lists the packages declared in package.json, pom.xml, or requirements.txt. An artefact-based SBOM lists what was actually resolved and bundled. These differ when: version ranges in manifests resolve to different versions than expected, peer dependencies resolve to transitive versions not in the manifest, bundling tools include additional packages, and in Go’s module graph where indirect dependencies are not in go.mod. The discrepancy between manifest and artefact is where supply chain attacks often live — precisely because the manifest is clean but the resolved artefact is not.
Component 2
Continuous Vulnerability Scanning
The SBOM is the input to a continuous vulnerability scanning process that checks every component in the inventory against multiple vulnerability databases. Scanning at build time alone is insufficient: vulnerabilities are published after builds complete, and the deployed version of an application may run for months between builds. Continuous scanning of the deployed SBOM against current vulnerability databases provides ongoing visibility into the exposure of running systems.
Programme elements
Vulnerability database coverage: NVD (National Vulnerability Database), OSV (Open Source Vulnerabilities), GitHub Advisory Database, and ecosystem-specific sources (npm Advisories, PyPA Advisory Database, RustSec)
Continuous scanning cadence: every SBOM in the inventory scanned against new CVE publications on a daily or near-real-time basis, not only at build time
Reachability analysis integration: for languages with reachability analysis tooling (Java, JavaScript), reducing false positives by verifying that the vulnerable function is in an execution path of the application before raising an alert
Severity-based SLA: alert routing and escalation path for each severity level, with defined remediation SLAs (critical: 24–72 hours, high: 7 days, medium: 30 days)
Operational age tracking: components that are significantly out of date relative to the latest available version, flagged for review even without a specific CVE — unmaintained components are inherently higher risk
The lag that continuous scanning addresses
Build-time scanning catches vulnerabilities that existed when the application was built. It does not catch vulnerabilities published after the build. An application built 3 months ago has had 3 months of CVE publications it was not scanned against. Without continuous scanning of deployed SBOMs, a CVE published today is not detected in running production systems until the next build — which may be days or weeks. For critical CVEs, that lag is the exploitation window.
Component 3
Provenance Verification & Artefact Signing
Knowing what components are in an application is necessary but not sufficient: you also need to know that each component is what it claims to be, that it was produced by the declared source, and that it has not been tampered with in transit. Artefact signing and provenance attestation provide cryptographic evidence that a build artefact was produced by a specific pipeline from a specific source at a specific time — making substitution attacks and binary tampering detectable rather than invisible.
Programme elements
Sigstore/cosign integration: cryptographic signing of build artefacts (container images, binaries, packages) with short-lived certificates via Fulcio, recorded in the Rekor transparency log
SLSA provenance attestation: generating and attaching SLSA provenance attestations to build artefacts, recording the source commit, build system, and build environment for each artefact
Signature verification in deployment pipeline: deployment workflows that verify artefact signatures and provenance attestations before deploying to any environment
Container image provenance: for containerised deployments, signing and verification of every container image and its constituent layers, with policy enforcement that refuses to deploy unsigned or unattested images
Key management for signing: signing key lifecycle management, rotation policy, and revocation procedure for compromised signing keys
Why signing alone is not sufficient
SolarWinds was signed. The signature verified that the package came from the SolarWinds signing key. The signing key had not been compromised. The build system had been compromised before signing. Artefact signing proves that the output of the build process is authentic — it does not prove that the build process itself was uncompromised. SLSA provenance attestation addresses this by also attesting the build system’s identity and integrity, not just signing the output.
Component 4
Dependency Governance & Policy Engine
Continuous SBOM generation and vulnerability scanning produce signals; a policy engine converts those signals into decisions. The dependency policy defines which packages are permitted, which are restricted, which are prohibited, and what conditions govern the use of each. The policy is enforced in the CI/CD pipeline: a build that introduces a prohibited dependency fails. A build that introduces a new dependency not yet reviewed is flagged for review before merging. A build that increases the severity of existing vulnerability findings above the threshold fails.
Programme elements
Dependency allow-list and block-list: approved packages list with version ranges, prohibited packages list (known malicious, abandoned, or licence-incompatible), and review-required list for packages not yet assessed
Licence compliance policy: automated detection of licence compatibility issues — GPL code in a commercial application, AGPL in a SaaS product, conflicting licence terms in combined dependencies
Dependency risk scoring: automated risk assessment of new dependencies added to the codebase, based on maintainer count, download count, OpenSSF Scorecard, CVE history, and last commit date
PR-level dependency review: automated comment on every pull request that adds or updates a dependency, surfacing the risk score, licence, maintainer health, and any existing CVEs before the PR is merged
Policy exception governance: documented process for approving exceptions to the dependency policy, with named approvers, review dates, and mandatory re-assessment triggers
The policy-as-code principle
Dependency policy documented in a policy document that no build system enforces provides guidance to developers who remember to read it. Dependency policy enforced in the CI/CD pipeline as code provides a gate that applies to every build regardless of whether any individual developer has read the policy. The policy document and the enforced policy will diverge over time unless both are maintained synchronously. The enforced policy in the pipeline is the authoritative policy; the documentation is the explanation of it.
Component 5
Secure Software Development Lifecycle (SSDLC) Integration
Supply chain security is most effective when integrated into the software development lifecycle rather than applied as a separate audit after the fact. SSDLC integration means that security checks happen at the point where changes are made — in the IDE, at PR review, at CI build, and at deployment — rather than in a periodic security assessment that finds issues after they have been in production. This requires tooling embedded in the development workflow and a development culture that treats dependency security as a first-class concern rather than a security team responsibility.
Programme elements
IDE security plugins: Dependabot alerts, Snyk IDE plugin, or equivalent giving developers immediate visibility into known vulnerabilities in the packages they are adding
Pre-commit hooks: client-side hooks that check for dependency policy violations before a commit reaches the remote repository, catching issues before they enter the review process
Automated dependency update PRs: Dependabot, Renovate, or equivalent that creates pull requests for dependency updates, keeping the dependency inventory current without requiring developers to manually monitor for updates
Security pipeline gates: defined quality gates in the CI/CD pipeline that fail the build when SBOM scanning finds critical or high CVEs, when new dependencies fail the policy check, or when provenance attestation is missing
Developer security training: specific to supply chain risk — how to evaluate a new dependency before adding it, what the risk signals are, and how to use the dependency review tooling
Component 6
Third-Party Supplier Security Assessment
The software supply chain extends to the commercial software and SaaS services the organisation purchases and integrates. These third parties have access to the organisation’s data and systems through their integrations, and their security posture directly affects the organisation’s exposure. The supplier assessment framework establishes the security requirements for third-party software, the assessment process for evaluating new suppliers, and the ongoing monitoring of existing suppliers’ security posture.
Programme elements
Supplier security requirements: minimum security standards for software vendors and SaaS providers, including SBOM availability, vulnerability disclosure policy, patch SLA commitments, and security certification requirements
SBOM collection from vendors: for commercially-licensed software, requiring vendors to provide SBOMs as part of procurement, enabling the organisation’s own vulnerability management to cover third-party software
Vendor security questionnaire and assessment: structured assessment of new software vendors’ supply chain security practices before procurement, with risk-tiered assessment depth based on integration scope and data access
Ongoing vendor monitoring: annual re-assessment for critical vendors, monitoring for vendor security incidents that may affect the organisation, contractual obligations for incident notification
Integration privilege review: periodic review of the permissions granted to every third-party integration, applying least privilege and removing permissions that are no longer needed
The integration privilege problem
Most SaaS integrations request the maximum permissions available and are granted them at implementation because it is easier than determining which permissions are actually needed. A marketing analytics tool with read access to the entire CRM, a code quality tool with read/write access to all repositories, a time tracking tool with access to calendar and email — each of these has permissions far exceeding the function it performs. When any of these services is compromised, the adversary inherits those permissions. Least-privilege integration review reduces the blast radius of supplier compromise without reducing functionality.
Component 7
Incident Response for Supply Chain Events
When a supply chain incident occurs — a widely-used dependency is found to contain malicious code, a vendor announces a breach of their CI/CD infrastructure, a new critical CVE is published for a component known to be widely deployed — the organisation must be able to answer two questions immediately: are we affected, and what do we do? Without an SBOM and a playbook, answering the first question takes days or weeks of manual inventory. With an SBOM and a playbook, it takes minutes.
Programme elements
Supply chain incident playbook: step-by-step response procedure for each incident type — malicious package discovered, vendor breach disclosed, critical CVE published, CI/CD compromise suspected
Rapid impact assessment: the process for querying the SBOM inventory to determine in under 30 minutes whether the organisation uses the affected component and in which systems
Emergency dependency replacement: process for replacing a compromised or critically vulnerable dependency with a safe alternative on an accelerated timeline, including the approvals required for emergency policy exceptions
Communication templates: internal stakeholder notification, vendor communication, and where required, regulatory notification templates for supply chain incidents affecting personal data
Post-incident review process: structured review to determine whether the incident was preventable with better supply chain controls, and to add the attack pattern to the monitoring programme
Component 8
SBOM Operationalisation, Observability & Executive Reporting
The SBOM only becomes strategically valuable when it is operationalised beyond security tooling into organisational visibility, decision-making, and governance. This component transforms SBOM data into measurable risk posture, operational telemetry, and executive-level reporting. It ensures that supply chain security is not confined to engineering teams but is visible, quantifiable, and actionable at every level of the organisation, from real-time operational dashboards to board-level risk oversight.
Programme elements
Central SBOM inventory platform: aggregation of all SBOMs across applications, environments, and business units into a unified, queryable system of record
Real-time exposure dashboards: live visualisation of vulnerability exposure, dependency risk distribution, and remediation status across the organisation
Risk quantification models: translating SBOM data into measurable risk metrics such as mean time to remediate (MTTR), exposure window duration, and dependency criticality scoring
Executive reporting cadence: structured reporting to leadership on supply chain risk posture, trends over time, and alignment against defined risk thresholds and regulatory expectations
Regulatory and audit integration: mapping SBOM controls and outputs to frameworks such as ISO 27001, NIST SSDF, and emerging software supply chain regulations, ensuring audit readiness
The visibility gap this closes
Most organisations generate SBOMs and perform scanning but fail to aggregate and interpret the data at scale. The result is fragmented visibility: individual teams may understand their own exposure, but the organisation as a whole cannot quantify systemic risk. Without centralised observability, leadership decisions are made without a clear understanding of software supply chain exposure. Operationalising SBOM data converts fragmented technical outputs into a unified risk intelligence layer, enabling prioritised remediation, defensible governance decisions, and demonstrable compliance under regulatory scrutiny.
Engagement Types — Scope, Price, Timeline
Three engagement types. Rapid exposure assessment, full SBOM programme design, and enterprise supply chain transformation.
Every engagement produces programme specifications and implementation guidance. Toolchain configuration and pipeline integration are performed by your DevSecOps and engineering teams from our specifications. The Type 1 rapid assessment provides immediate vulnerability visibility without waiting for a full programme design — appropriate when a critical supply chain incident has just occurred or when regulatory deadlines require demonstrable action quickly.
Engagement Type 1
Rapid Supply Chain Exposure Assessment
For organisations that need immediate visibility into their software supply chain exposure — either because a supply chain incident has just occurred and they need to know if they are affected, because a regulatory deadline requires demonstrable action, or because they have never assessed their supply chain security posture and need a baseline before committing to a full programme. The rapid assessment generates SBOMs for the specified applications, scans them against current vulnerability databases, and produces a prioritised exposure report within 4 weeks. It is a starting point, not a programme — but it provides immediate actionable intelligence.
£24,000
Fixed · up to 10 repos · VAT excl.
4 weeksAdditional repositories: £1,500 each. For organisations experiencing an active supply chain incident, emergency assessment available within 5 business days at £32,000.
SBOM Generation
SBOM generation for up to 10 code repositories using artefact-based analysis (Syft, cdxgen) in addition to manifest-based analysis, capturing discrepancies
Multi-language coverage for the languages present in scope: Java, Python, JavaScript/Node, Go, Rust, .NET, Ruby — each with appropriate tooling
Container image SBOM analysis for containerised applications: base image layers and application layers separately catalogued
Transitive dependency coverage: the full dependency graph, not just direct dependencies — the transitive dependencies are where most CVEs and supply chain attacks occur
Discrepancy report: where artefact-based analysis finds dependencies not present in manifest declarations
Vulnerability Scan & Triage
Vulnerability scan against NVD, OSV, GitHub Advisory Database, and ecosystem-specific sources for every component in the generated SBOMs
Severity classification: critical, high, medium, low — with CVSS score, EPSS (exploitability) score, and known exploitation status for each
Reachability analysis where tooling supports it (Java, JavaScript) to reduce false positives and prioritise remediable vulnerabilities
Licence compliance scan: identification of licence compatibility issues for commercial or open-source distribution requirements
Dependency health assessment: identification of abandoned, unmaintained, or significantly outdated components regardless of CVE status
Assessment Outputs
SBOM inventory: CycloneDX-format SBOMs for all assessed applications, ready for integration into vulnerability management tooling
Vulnerability exposure report: all findings with severity, EPSS score, affected component, and affected applications
Critical and high priority remediation list: the specific dependency updates or replacements required, with prioritisation by exploitability and business criticality of the affected application
Rapid programme recommendations: the 5 highest-impact supply chain security improvements the organisation can implement in the next 30 days without a full programme investment
SBOM programme readiness assessment: the gaps in current build pipeline and tooling that must be addressed before a continuous SBOM programme can be implemented
What a rapid assessment cannot tell youThe rapid assessment generates SBOMs from the source code and artefacts available at the time of assessment. It does not provide continuous monitoring — new vulnerabilities published after the assessment will not be detected until the next assessment. It does not assess the build pipeline security — whether the build process itself has been compromised. It does not assess third-party service integrations. It is a baseline measurement, not a monitoring programme. The value of the rapid assessment is providing immediate actionable intelligence and a foundation for the programme design in Type 2.
What Your Team Must Provide
Read-only access to up to 10 source code repositories — the assessment runs analysis against the repository content and build artefacts, not against production systems
Build artefacts for each application if available: compiled JARs, container images, or deployment packages — artefact-based analysis is more complete than source-only analysis
Application inventory with business criticality ratings: which of the 10 repositories are most business-critical, to prioritise the remediation list
Language and framework inventory if known: not required but accelerates tooling configuration for multi-language estates
What Is Not in This Engagement
Continuous SBOM monitoring: the assessment generates a point-in-time snapshot; continuous monitoring is the subject of Type 2
Pipeline integration: the SBOMs are generated by our tooling for assessment purposes; integration into the CI/CD pipeline is part of Type 2 programme design
Supplier security assessment: third-party commercial software and SaaS service assessment is in Type 2 and Type 3 only
Type 1 fee credited against Type 2 if engaged within 90 days of Type 1 delivery
Engagement Type 2
Full SBOM Programme Design & Implementation Specification
For organisations designing or redesigning their complete software supply chain security programme. Covers all seven programme components: SBOM generation integrated into the build pipeline, continuous vulnerability scanning, provenance verification and artefact signing, dependency governance and policy engine, SSDLC integration, third-party supplier assessment framework, and incident response for supply chain events. The deliverable is a complete programme specification that your DevSecOps and security engineering teams implement, with tooling recommendations, configuration specifications, and policy documentation.
£75,000
Fixed · less £24k Type 1 credit · VAT excl.
14 weeksPipeline integration design is the most complex phase and depends on the diversity of CI/CD platforms and build systems in the estate.
Programme Architecture
SBOM toolchain selection and integration specification: the complete toolchain for SBOM generation, storage, and scanning integrated into the specific CI/CD platforms in use (GitHub Actions, GitLab CI, Jenkins, Azure DevOps, etc.)
Continuous scanning platform design: tooling selection (Grype, Trivy, Snyk, Dependabot, or similar) and integration with the vulnerability management workflow, including alert routing and SLA enforcement
Sigstore/SLSA provenance pipeline: the complete artefact signing and provenance attestation pipeline, from source commit to deployment verification
Dependency policy engine: the policy-as-code implementation for dependency governance, including allow-list, block-list, licence policy, and risk scoring integration
SSDLC toolchain specification: IDE plugins, pre-commit hooks, PR-level dependency review automation, and pipeline security gates
Supplier assessment framework: security requirements for software vendors, SBOM collection process, vendor assessment questionnaire, and ongoing monitoring process
Policy & Governance
Dependency policy: the complete policy document, its enforcement configuration, and the exception governance process — designed for enforcement as code, not as a reference document
Vulnerability management SLAs: severity-based remediation timelines, escalation paths, and tracking mechanisms integrated with the organisation’s existing vulnerability management process
SBOM programme governance: who owns what in the programme, the review cadence for each component, and the escalation path for programme gaps
Regulatory mapping: explicit mapping of the programme components to US EO 14028, DORA Article 28, NCSC software supply chain guidance, and any sector-specific requirements
Developer security standards: the security requirements for dependency selection, assessment, and maintenance written for a developer audience and integrated into the engineering handbook
Incident Response & Outputs
Supply chain incident response playbooks: one per major incident type (malicious package, vendor breach, critical CVE, CI/CD compromise), with step-by-step procedures and defined decision authorities
SBOM programme implementation roadmap: sequenced implementation phases with priorities, effort estimates, and quick wins deliverable within 30 days
Tooling configuration specifications: ready-to-implement configuration files for the selected toolchain components — not descriptions of what to configure, but the configuration itself
60-day advisory support: implementation questions answered within 1 business day
Toolchain implementation: DevSecOps team implements from specifications
Ongoing programme operation
What Your Team Must Provide
CI/CD platform inventory: the build and deployment platforms in use, their versions, and which applications use which platforms — the programme design must accommodate the actual pipeline architecture
Application portfolio: the full inventory of applications in scope, their languages, their build processes, and their deployment targets
DevSecOps lead: available for 3 design review sessions to validate that the programme architecture accommodates operational constraints not captured in the inventory
Security lead: available for policy and governance design sessions and supplier assessment framework review
What Is Not in This Engagement
Toolchain implementation: all pipeline configuration, tooling deployment, and integration is performed by your DevSecOps team
Ongoing SBOM programme operation and monitoring: programme design only — operation is your team’s responsibility from the specifications and governance framework we deliver
For portfolios above 50 repositories or with highly heterogeneous build pipelines: scoped as Type 3
Engagement Type 3
Enterprise Supply Chain Security Transformation
For large organisations with complex software portfolios: 50+ repositories across multiple teams, multiple CI/CD platforms, acquired codebases at different maturity levels, or regulated environments where the supply chain security programme must satisfy specific regulatory requirements with documented evidence. Also appropriate for software vendors who are being asked by their customers or by procurement requirements to provide SBOMs, attest to their SLSA maturity level, or demonstrate supply chain security practices as part of B2B or government contract qualification. All enterprise engagements individually scoped.
From £140,000
Individually scoped · VAT excl.
From 18 weeksEnterprise programmes with 100+ repositories and multiple business units commonly run 24–30 weeks for programme design and initial rollout specification.
What Enterprise Adds
Portfolio-scale SBOM generation: architecture for generating, storing, and continuously scanning SBOMs across 50+ repositories without creating a maintenance burden that development teams will circumvent
Multi-team programme governance: a governance framework that applies consistent supply chain security standards across autonomous engineering teams without requiring central approval for every dependency decision
Acquired codebase integration: for M&A integration, supply chain security assessment of acquired software and a migration path to the acquirer’s SBOM programme standards
Regulatory evidence pack: for DORA Article 28, US EO 14028 federal supplier requirements, or sector-specific mandates, the documented evidence that the programme satisfies the specific regulatory requirements — not just that a programme exists
Software vendor programme: for organisations that develop and distribute software to customers, the customer-facing SBOM programme including format selection, distribution mechanism, update process, and vulnerability disclosure integration
Why Enterprise Is Different
Heterogeneous build pipelines: 50+ repositories across 10 teams means 10 different build configurations, potentially on multiple CI/CD platforms, each requiring different tooling integration — the programme architecture must accommodate this without requiring each team to implement independently
Developer autonomy vs. central control: enterprise development organisations have teams with strong opinions about their toolchains. Supply chain security requirements that are perceived as imposed overhead will be circumvented. The programme design must create sufficient value for developers (better visibility, fewer emergency patches) that adoption is motivated rather than mandated
Signal volume management: an enterprise with 100 repositories continuously scanning against CVE databases generates thousands of vulnerability signals per day. The programme must include triage and prioritisation architecture that prevents alert fatigue while ensuring critical issues are addressed
Enterprise Requirements
Named programme sponsor at the CISO or VP Engineering level with authority to mandate supply chain security standards across engineering teams
Engineering team leads from all major product areas: available for programme design workshops to capture team-specific constraints
DevSecOps platform team: the team that owns the CI/CD infrastructure and will implement the toolchain integration across all pipelines
For software vendor programmes: legal and sales input on customer SBOM requirements, including contractual obligations already in place
Bilateral Obligations
Client Obligations
Provide access to actual build artefacts, not only source manifests
Manifest-based SBOM analysis — reading package.json, pom.xml, or requirements.txt — produces an SBOM that reflects what developers declared as dependencies, not what the build system actually resolved and included. The gap between declared and actual is where typosquatting, dependency confusion, and resolution anomalies appear. Artefact-based analysis requires access to compiled JARs, container images, or deployment packages. For organisations without a centralised artefact repository, providing repository access enables us to run the build and analyse the output. SBOM analysis conducted only from manifests will miss discrepancies that represent supply chain risk.
If build artefacts cannot be providedWe conduct manifest-based analysis and explicitly document the coverage limitation. The rapid assessment report distinguishes between findings from artefact analysis (higher confidence) and manifest analysis (lower confidence). The programme design for Type 2 will include artefact repository design as a requirement, since continuous SBOM generation requires access to build outputs.
Vulnerability findings must be acted on according to the defined SLAs, not accumulated in a backlog
A supply chain security programme that generates vulnerability findings but does not remediate them is a monitoring programme, not a security programme. The value of knowing about a critical vulnerability in a production dependency is the ability to remediate it before it is exploited. An organisation that accumulates a backlog of hundreds of known critical vulnerabilities has not received security value from the SBOM programme — it has received liability: it knows it is vulnerable and has not acted. The SLAs in the programme design are not aspirational targets; they are the commitments required to convert vulnerability visibility into security improvement.
If remediation SLAs cannot be met for specific vulnerabilitiesThe programme design includes an exception process for vulnerabilities that cannot be remediated within the standard SLA due to specific technical or operational constraints. Exceptions are documented with the blocking reason, a compensating control, and a target remediation date. An exception with a documented compensating control is a managed risk. An exception without either is an unmanaged vulnerability that the programme has documented but not addressed.
RJV Obligations
Tooling recommendations are vendor-neutral and based on technical fitness, including open-source alternatives
The software supply chain security tooling market includes both commercial products and high-quality open-source alternatives for every major programme component. Syft and Grype provide SBOM generation and vulnerability scanning that is comparable to commercial alternatives for many use cases; Sigstore is the CNCF-backed open standard for artefact signing; Renovate is a capable open-source alternative to commercial dependency update tools. Our tooling recommendations are based on what best fits the organisation’s existing infrastructure, team familiarity, and licensing constraints — not on commercial relationships with tool vendors. We declare any commercial relationships before making any recommendation.
If a recommended tool is unavailable in the organisation’s environmentWe identify the best available alternative and document the trade-off relative to the primary recommendation. Where the best available option is materially inferior for the specific use case, we say so rather than presenting the inferior option as equivalent.
False negative disclosures: where SBOM coverage has known gaps, we document them explicitly
No SBOM generation tool achieves 100% coverage for all languages, build systems, and dependency types. Native binaries compiled without package manager metadata cannot be fully inventoried by current tooling. Vendored dependencies copied into a repository rather than declared in a manifest may not be detected. Languages without mature SBOM tooling (some Rust configurations, bespoke build systems, specific C/C++ configurations) may have incomplete coverage. Where we know the coverage is incomplete, we document the gap explicitly in the SBOM and in the programme report. An SBOM presented as complete when it has known gaps is not a security control; it is a false assurance. We do not present incomplete coverage as complete.
If coverage gaps are identified after deliveryWe review the gap and provide an updated assessment of what can be covered with available tooling and what requires alternative approaches (manual inventory, architecture changes, or acceptance of the gap with documented risk).
The assessment session answers one question: if a supply chain incident affecting one of your dependencies occurred today, how long would it take to determine whether you are affected?
The answer to that question is the primary indicator of supply chain security maturity. If the answer is “minutes, because we have a current SBOM and continuous scanning” — the programme exists. If the answer is “days or weeks, because we would need to check each application manually” — you experienced exactly what every organisation without an SBOM experienced during Log4Shell, and will experience again in the next major supply chain incident. 90 minutes to review your current dependency inventory and pipeline security posture, and to understand the gap.
If a supply chain incident is affecting your organisation right now, contact us directly by email for emergency assessment within 5 business days. For planned programme development, the standard assessment session begins the discovery process.
Format
Video call or in-person in London. 90 minutes.
Cost
Free. No commitment. Emergency assessment for active incidents: contact by email for 5-business-day response.
Lead time
Within 5 business days of contact for planned assessments.
Bring
Your software portfolio overview: how many applications, what languages, which CI/CD platforms. Whether you currently generate SBOMs and in what format. Your current vulnerability management process for third-party dependencies. Any recent supply chain incidents that have affected you or your sector. Regulatory requirements you are subject to that reference SBOM or supply chain security (US EO 14028, DORA, government procurement contracts).
Attendees
DevSecOps or security engineering lead and the CISO or security lead. Both are needed — the pipeline context and the security risk context must be in the same room. From RJV: a supply chain security specialist.
After
Written preliminary supply chain security assessment within 2 business days. Scope proposal within 5 business days if you want to proceed.