How does SBOM fit into software supply chain security?

A Software Bill of Materials (SBOM) is the structured inventory of every component that goes into a software product. SBOMs are produced in SPDX or CycloneDX format and contain the component name, version, supplier, hash, and licence at minimum. The SBOM is the foundation of supply chain transparency. Without one, the team cannot answer the question "is this CVE in our product" in less than a week. With one, the answer is a database query. SBOMs flow into vulnerability management for matching against CVE feeds, into VEX publishing for stating which CVEs are exploitable in context, into procurement for evaluating vendor risk, and into customer assurance for releasing component inventories to regulated buyers. SBOM is necessary but not sufficient for supply chain security; signing, attestation, and build provenance sit alongside it.

What is SLSA and how do the levels work?

SLSA (Supply-chain Levels for Software Artefacts) is a framework for build integrity. SLSA defines four levels that progressively raise the bar on build trustworthiness. Level 1 requires a documented build process. Level 2 requires version control of source plus a hosted build service that generates signed provenance. Level 3 requires hardened, isolated builds with non-falsifiable provenance and a verified build platform. Level 4 (now folded into the build-track design) requires two-party review, hermetic builds, and reproducible outputs. Most enterprise programmes target SLSA Build Level 2 or 3 as the operating standard. The level is not the goal in itself; the goal is provenance that lets a downstream consumer verify how the artefact was built and by whom.

What does NIST SSDF require for software supply chain security?

NIST SSDF (Secure Software Development Framework, SP 800-218) defines four practice groups: prepare the organisation (PO), protect the software (PS), produce well-secured software (PW), and respond to vulnerabilities (RV). For software supply chain security specifically, the load-bearing practices are PS.1 (protect all forms of code from unauthorised access and tampering), PS.2 (provide a mechanism for verifying software release integrity), PS.3 (archive and protect each software release), PW.4 (reuse existing, well-secured software when feasible), PW.5 (create source code by adhering to secure coding practices), PW.6 (configure the compilation and build processes to improve executable security), PW.8 (review and analyse human-readable code), and RV.1 (identify and confirm vulnerabilities on an ongoing basis). SSDF is the foundation for CISA Secure Software Development Attestation and is increasingly cited in federal procurement requirements.

What does the EU Cyber Resilience Act require for software supply chain security?

The EU Cyber Resilience Act (CRA) imposes essential cybersecurity requirements on products with digital elements placed on the EU market. For supply chain security, the CRA requires manufacturers to identify and document vulnerabilities and components contained in the product (SBOM as a structured artefact), to apply effective and regular tests and reviews of the security of the product, to provide security updates for the support period, to deliver a coordinated vulnerability disclosure policy, and to notify ENISA and CSIRTs of actively exploited vulnerabilities and severe incidents within 24 and 72 hour windows. The CRA materially raises the bar for software vendors selling into the EU and is now driving supply chain programme investment across enterprise software product teams.

What is VEX and why does it matter for supply chain security?

VEX (Vulnerability Exploitability eXchange) is the machine-readable statement a software publisher releases to say whether a known CVE in a component is exploitable in the specific product, with the status set to Affected, Not Affected, Fixed, or Under Investigation, plus a justification for Not Affected statuses. VEX is the companion to SBOM: the SBOM enumerates components, the VEX statement filters the long tail of CVEs that match those components but are not exploitable in the product context (because the vulnerable function is never reached, the affected protocol is disabled, the affected configuration is not deployed, etc.). VEX cuts CVE noise in customer security questionnaires and in regulator filings. The 24-hour CRA exploitation reporting requirement is significantly easier to meet when the team already publishes VEX.

How do CI/CD pipeline attacks happen and how are they prevented?

CI/CD pipelines are an attractive target because a single compromise produces code that ships to customers without the source ever changing. Common patterns: compromised CI runners that inject code at build time, leaked or stolen build secrets that authorise malicious uploads to package registries, malicious dependency updates pulled in by automated bumps without review, build agents reused across tenants without isolation, and SCM webhook misconfiguration that triggers builds from forks under attacker control. Prevention is layered. Ephemeral, isolated runners. Short-lived, scoped secrets fetched from a vault. Branch protection plus required code review on every merge. Signed commits and signed artefacts. Provenance attestation per build (SLSA Build Level 2 or 3). Two-party review on changes to pipeline definitions. Pinned dependency versions in lock files. Scoped registry credentials. Audit logs that capture every pipeline run with the triggering identity.

What is dependency confusion and how is it prevented?

Dependency confusion is the attack where an attacker publishes a package to a public registry (npm, PyPI, Maven Central, RubyGems) with the same name as an internal private package, and a misconfigured client resolves the public copy first. The 2021 Birsan research disclosed the attack against major companies. Prevention combines several controls. Scope every internal package to a private namespace or organisation prefix that does not collide with any public name. Configure package managers to pull internal names only from the internal registry. Reserve the internal package names on the public registry as defensive placeholders so they cannot be hijacked. Use lockfiles and checksum pinning so a name resolution change produces a verification failure rather than a silent substitution. Audit transitive dependencies for the same risk pattern.

What does a software supply chain security programme look like inside an enterprise?

A working enterprise programme combines five workstreams. Inventory: continuously generate and ingest SBOMs across every shipped product. Threat modelling: maintain a documented threat model that covers source, dependencies, build, signing, distribution, and runtime. Detection: run SCA, secret scanning, container scanning, and source code review against the components; map findings against CVE and EPSS feeds; ingest scanner output into a single findings record. Verification: enforce signed artefacts, signed commits, build provenance attestation (SLSA), and verified base images. Response: maintain a coordinated vulnerability disclosure process, publish VEX statements for known CVEs, hold a runbook for compromise scenarios, and keep audit-grade evidence available for regulators and customers. The programme is owned jointly: AppSec or product security runs detection and verification, GRC owns the audit and customer-facing evidence, and CISO owns the cross-team operating model.

How does SecPortal support a software supply chain security programme?

SecPortal holds the operating-side record a supply chain programme runs on. Code scanning (SAST and SCA) runs against repositories through OAuth-connected git providers and captures dependency and source findings into the findings record with CVSS scoring, ownership, and remediation history. Bulk finding import ingests output from external scanners (Snyk, Trivy, Grype, Semgrep, custom CI checks) so the platform stays the canonical record regardless of which scanner produced the finding. Authenticated and external scanning produces the runtime view that complements the static SBOM and SCA view. Findings management exports per-component remediation history with named owners and retest evidence so the team can answer the "is this CVE exploitable here, who owns it, when does it close" question from one record. Engagement management holds the third-party penetration test cycle, the secure-code review engagement, and the coordinated vulnerability disclosure engagement. Document management stores the threat model document, the SBOM exports, the VEX statements, the signing-key inventory, and the build-pipeline runbook with versioning. Compliance tracking maps findings into NIST SSDF, CISA SSDF Attestation, SLSA practices, NIS2, DORA, ISO/IEC 27001, SOC 2, and EU CRA. The activity log captures every state transition as the provenance trail that regulators and enterprise buyers review against.

← Back to Blog

Enterprise25 May 202622 min read

Software Supply Chain Security: A Practical Guide for Enterprises

Software supply chain security is now the load-bearing AppSec discipline for enterprise software vendors and the internal security teams that ship business-critical applications. A successful supply chain attack rarely needs a single vulnerability in your code; it needs a single weakness somewhere in the long chain of source, dependencies, builds, signatures, registries, and release channels that turns a developer commit into a binary running in production. This guide is written for the AppSec leads, product security engineers, vulnerability management owners, GRC teams, and CISOs who run the supply chain programme as one operating model rather than as a stack of one-off scanner outputs.

The discipline pulls together a threat model that covers every layer of the chain, the inventory that powers vulnerability matching (SBOM), the build-integrity model that lets downstream consumers verify what they install (SLSA, signed artefacts, attestation), the response model that reduces noise for downstream consumers and regulators (VEX), and the regulatory frame that turns the programme into a compliance obligation rather than a best-effort exercise (NIST SSDF, CISA Secure Software Development Attestation, EU Cyber Resilience Act, NIS2, DORA). Run well, the programme produces audit-grade evidence that satisfies regulators, enterprise procurement, and customer security questionnaires from the same underlying record the security team already operates against day to day.

What Software Supply Chain Security Actually Covers

The software supply chain is every input that goes into a product and every step that transforms those inputs into the artefact a customer installs. A working programme covers the entire chain rather than only the parts that historically had scanners pointed at them.

The layers, in the order an attacker typically reads them:

Source: the code your team writes, hosted in a version control system, with branch protection, code review, signed commits, and secret-scanning enabled.
Open-source dependencies: the third-party libraries pulled in directly and transitively from package registries, with pinned versions, lockfiles, and license and vulnerability scanning.
Commercial third-party components: proprietary libraries, SDKs, agents, and embedded systems that ship as part of the product, with supplier risk reviews and update channels.
Container base images and runtime: the base layers your application images inherit from, with pinned digests, vulnerability scanning, and a controlled registry.
Build pipelines: the CI/CD runners, build agents, secrets, environment variables, and pipeline definitions that take source plus dependencies and produce binaries.
Signing and provenance: the keys, certificates, and attestation metadata that prove an artefact came from your build system rather than from an attacker.
Registries and distribution: the package registries, container registries, update servers, and CDN endpoints that hold and serve the artefacts customers install.
Customer environment: the deployment, configuration, and runtime where the artefact runs, including the patch-update channel back to your team.

The discipline is layered because the controls per layer are different. Source review does not catch a compromised build agent. SCA does not catch a typosquatted package that has not yet been reported. SBOM does not catch a vulnerable container base layer unless the SBOM extends down into the base. Signed artefacts do not help if customers do not verify the signature. A programme that focuses on one layer and ignores the rest is the programme an attacker designs around.

The Supply Chain Threat Model

Software supply chain attacks cluster into a small number of patterns. The team that understands the patterns can design controls against the attacker behaviour rather than against a long list of unrelated tools. Pair this section with the broader threat modelling guide for the methodology underneath the patterns below.

Dependency confusion

An attacker publishes a package to a public registry with the same name as an internal private package. A misconfigured client resolves the public copy first and installs attacker code. Disclosed at scale in 2021 against major technology companies. Scope internal packages to a namespace, configure package managers to pull internal names only from the internal registry, reserve internal names on public registries as defensive placeholders, and pin with checksums.

Typosquatting

An attacker publishes a package whose name differs from a popular package by a single character or transposition (lodahs for lodash, reqests for requests). Developers install the typo and import attacker code. Defend with allowlists where feasible, with curated internal mirrors that proxy approved packages, and with linting that flags suspicious package names at install time.

Maintainer account takeover

An attacker compromises the maintainer account of a legitimate package and ships malicious code in a routine update. The package has hundreds of thousands of downloads and the malicious version installs everywhere. The 2018 event-stream compromise and the 2024 xz-utils backdoor follow this pattern. Defend with pinning, with verification of release signatures, with delayed adoption of new major versions, and with SCA tools that flag suspicious version jumps.

Build pipeline tampering

An attacker compromises CI runners, build agents, or build secrets to inject code at build time without changing source. The SolarWinds Orion compromise is the canonical reference. Defend with isolated, ephemeral runners, short-lived scoped secrets fetched from a vault, two-party review on pipeline definition changes, signed commits, signed artefacts, and SLSA Build Level 2 or 3 provenance.

Signed-artefact bypass

The publisher signs artefacts, but the consumer either does not verify the signature, verifies against a key the attacker has substituted, or accepts an expired or revoked certificate. The mitigation is consumer-side: enforce signature verification at install time, pin against the expected public key or Sigstore identity, and refuse unsigned artefacts in production deployment pipelines.

Update channel poisoning

The attacker compromises the delivery path between publisher and customer: package mirrors, CDN endpoints, update servers, or DNS resolution. Even a signed artefact loses value if the version the customer installs is not the version the publisher intended. Defend with TLS certificate pinning where feasible, with signed update manifests, with TUF-style metadata, and with mirror integrity checks.

Container base image poisoning

An attacker ships a tampered or vulnerable base layer that every downstream application image inherits. Defend with curated base images pulled from a controlled internal registry, with pinned digests rather than mutable tags, and with container scanning that surfaces vulnerable base layers at build time.

Source code review bypass

An attacker submits a pull request that looks innocuous but introduces a subtle vulnerability or backdoor. Insider variants are harder to detect. Defend with required code review by named reviewers, with branch protection that prevents review bypass, with mandatory two-party review on sensitive paths, and with secure code review checklists that the reviewers actually use.

Inventory: SBOM as the Foundation

A Software Bill of Materials is the structured inventory of every component that goes into a product. SBOMs are produced in SPDX or CycloneDX format and contain the component name, version, supplier, hash, and licence at minimum. Without an SBOM, the team cannot answer the question “is this CVE in our product” in less than a week. With one, the answer is a database query.

The detailed mechanics of generating, storing, and consuming SBOM (SPDX vs CycloneDX, NTIA minimum elements, ingestion patterns, build-time vs binary-time SBOM, and the interaction with vulnerability management) are covered in the dedicated SBOM guide for security programmes. The supply chain context here is narrower: the SBOM is one of several artefacts the programme produces, alongside signed builds, attestations, and VEX statements.

Practical principles when the SBOM is built for supply chain security rather than as a standalone artefact:

Generate the SBOM at build time, from the resolved dependency graph, not after the fact from a binary scan. Build-time SBOM is more complete.
Generate SBOMs for every shipped artefact, not only for the flagship product. Container images, agents, installers, and add-ons each need their own SBOM.
Extend the SBOM down into container base layers and operating-system packages. A SBOM that stops at the application boundary misses the largest CVE surface.
Sign the SBOM so consumers can verify it has not been tampered with.
Store every released SBOM alongside the release record so the historical inventory is queryable for incident response years after the release.
Pair each SBOM with a VEX statement so downstream consumers can filter the long tail of CVEs that match listed components but are not exploitable in product context.

Build Integrity: SLSA, Provenance, and Signing

SLSA (Supply-chain Levels for Software Artefacts) is the framework for build trustworthiness. SLSA defines progressive levels that raise the bar on how a downstream consumer can verify how an artefact was built and by whom. Most enterprise programmes target SLSA Build Level 2 or 3 as the operating standard.

The detailed mechanics of SLSA levels, provenance generation, in-toto attestation, and the verification model are covered in the dedicated SLSA framework explainer. The supply chain context here is operational: what changes day to day when the programme commits to a SLSA target.

SLSA Build Level 1

A documented build process. The team can describe how each artefact is built and what inputs went into it. The bar is low; the value is that the team has actually written the process down. Level 1 is rarely the target; it is the floor below which a programme cannot answer regulator questions.

SLSA Build Level 2

Source under version control. Hosted build service. Provenance is signed and generated by the build service rather than by the developer. Build Level 2 is the practical target for most enterprise programmes: it produces a cryptographically verifiable record of every build without requiring a hermetic build environment.

SLSA Build Level 3

Hardened, isolated builds. Non-falsifiable provenance generated by a verified build platform. Each build runs in an isolated environment so a single compromise does not contaminate other builds. Level 3 is the target for product teams that ship security-critical software (cryptography, infrastructure, regulated industries) or for vendors that face federal procurement requirements.

Operational changes when the team commits to SLSA Build Level 2 or 3:

Every build runs on a hosted, controlled CI service rather than on developer laptops. No more local-machine releases.
Build secrets fetch from a vault at runtime and are scoped to the specific build. Long-lived static credentials are removed from CI.
Every build produces a signed provenance artefact (typically an in-toto attestation) alongside the binary, recording the source commit, the builder identity, the build parameters, and the dependencies pulled.
Artefacts are signed (Sigstore cosign, Notary, GPG, or supplier-specific signing) and the verification key is published through a trustworthy channel.
Deployment systems verify both the artefact signature and the SLSA provenance before installing.
The signing key and provenance trust roots are documented in a key inventory and rotated on a defined schedule.

Detection: SCA, Secret Scanning, Container Scanning, Source Review

Detection is the layer that surfaces vulnerable components, leaked secrets, vulnerable container layers, and unsafe code patterns. The point of the detection layer is not to generate a long backlog; it is to produce findings the team can prioritise and remediate in time to keep the supply chain trustworthy.

The scanner mix per supply chain layer:

Source: SAST tools (Semgrep, CodeQL, custom rules) that surface unsafe code patterns and dataflow issues. Pair with secure code review checklists for the human review layer SAST does not cover.
Dependencies: SCA tools (Snyk, OSV-Scanner, Trivy, Grype, Dependabot, GitHub Advanced Security) that match the resolved dependency graph against CVE and EPSS feeds. Compare options in the SAST vs SCA code scanning explainer.
Secrets: secret-scanning tools (TruffleHog, Gitleaks, GitHub secret scanning, custom regex) that surface keys, tokens, and credentials accidentally committed to source. Pair with the secret scanning remediation workflow for the rotation and revocation discipline that turns a found secret into a closed finding.
Container images: image-scanning tools (Trivy, Grype, Clair, Docker Scout, registry- native scanners) that surface vulnerabilities in base layers and installed packages. Pair the scanner output with the container image vulnerability remediation workflow.
Runtime: authenticated and external scanners that surface vulnerabilities the static-analysis layer missed because they only manifest in a configured, running system.

Reachability analysis cuts SCA noise by separating CVEs that touch code your product actually executes from CVEs that match a listed component but sit in unreachable code. See the dedicated reachability analysis explainer for the methodology, the tooling options, and the implication for prioritisation.

Response: VEX, Coordinated Disclosure, and Customer Communication

A supply chain programme without a response model is incomplete. When a vulnerability lands in a component shipped in your product, three audiences expect a clear response: customers (does your product expose me to this), regulators (how fast can you confirm exploitability and notify), and the internal vulnerability management owner (do we have to remediate or accept the risk in context).

VEX (Vulnerability Exploitability eXchange)

VEX is the machine-readable statement a software publisher releases to say whether a known CVE in a component is exploitable in the specific product, with the status set to Affected, Not Affected, Fixed, or Under Investigation. The deeper mechanics are in the VEX guide. VEX cuts the CVE noise in customer security questionnaires and is increasingly expected by regulators.

Coordinated vulnerability disclosure

A documented intake path for external researchers and customers to report vulnerabilities, a triage process, a disclosure timeline aligned with ISO/IEC 29147 and 30111, and a published policy that sets expectations. The operating model is described in the vulnerability disclosure programme setup guide.

CISA KEV catalogue ingest

The CISA Known Exploited Vulnerabilities catalogue is the regulator-curated list of actively exploited CVEs with remediation deadlines. The supply chain programme ingests the catalogue daily and matches against the SBOM so any KEV that lands in your product surfaces with a hard deadline. The operating model is in the CISA KEV catalogue guide.

EPSS-based prioritisation

The Exploit Prediction Scoring System estimates the probability that a CVE will be exploited in the wild. EPSS plus CVSS plus reachability plus KEV is the practical prioritisation stack for triaging the long tail of component CVEs. See the EPSS explainer.

Customer communication

A defined channel for telling customers what they need to know when a supply chain CVE lands. Security advisories, customer-facing release notes, and the evidence room that exposes signed advisories, the affected SBOM, and the patched version reference. The operating workflow is in the customer security evidence room use case.

Regulatory Frame: SSDF, CRA, NIS2, DORA, and Federal Procurement

The supply chain programme is increasingly a compliance obligation rather than a best-effort exercise. The regulatory frame across major markets now requires a documented supply chain operating model, audit-grade evidence, and tight response timelines. The programme that operates these together produces compliance evidence as a by-product rather than as a separate effort.

NIST SSDF (SP 800-218)

The Secure Software Development Framework defines four practice groups: PO (organisation), PS (protect software), PW (produce well-secured software), and RV (respond to vulnerabilities). The full implementation guide is in the NIST SSDF implementation guide and the framework reference is at /frameworks/nist-ssdf.

CISA Secure Software Development Attestation

Federal software producers must attest that their development practices align with NIST SSDF when selling to US federal agencies. The attestation is a binding executive-signed document covering source control, build integrity, vulnerability response, and provenance. See the CISA SSDF attestation guide.

EU Cyber Resilience Act

The CRA imposes essential cybersecurity requirements on products with digital elements placed on the EU market. SBOM, vulnerability handling, support periods, coordinated disclosure, and 24-hour exploitation reporting are all in scope. See the EU CRA vulnerability handling guide and the framework reference at /frameworks/cyber-resilience-act.

NIS2 Directive

NIS2 expands the EU cybersecurity directive to a broader set of essential and important entities, with supply chain risk management as one of the named risk management measures. The supply chain programme has to evidence component inventory, vendor risk assessment, and supplier security practices.

DORA

The Digital Operational Resilience Act requires EU financial entities to manage ICT third-party risk, including the software supply chain. The implementation detail is in the DORA ICT third-party risk implementation guide.

SOC 2, ISO/IEC 27001, ISO/IEC 27036, NIST SP 800-161

The horizontal frameworks read supply chain controls into existing trust services criteria, ISMS controls, supplier relationship controls (ISO 27036), and the cybersecurity supply chain risk management framework (NIST SP 800-161). See the framework references at /frameworks/soc-2, /frameworks/iso-27001, and /frameworks/nist-sp-800-161.

Common Supply Chain Programme Failure Modes

Supply chain programmes fail in predictable places. The pattern is usually treating the programme as a tool deployment rather than as an operating model owned across AppSec, GRC, vulnerability management, and CISO.

SCA backlog with no prioritisation or exploitability filter

SCA produces 50,000 component CVEs in a quarter. The team has no way to separate the dozen that matter from the 49,988 that do not. The backlog grows linearly with releases and the team eventually stops reading the output. The fix is reachability, EPSS, KEV, and VEX layered on top of SCA so the queue reaches the named owner with the right priority. The discipline is in the dependency vulnerability triage workflow.

SBOM is generated but never consumed

The build produces a CycloneDX SBOM per release and uploads it somewhere. No downstream process matches the SBOM against CVE feeds, none against KEV, none into customer evidence. The SBOM is a compliance artefact rather than a live record. The fix is ingesting the SBOM into the vulnerability management record as the inventory the matching engine reads against.

Build runs on developer laptops or unmanaged CI

The team aspires to SLSA Level 2 but production releases still run from a senior engineer's machine or from a CI system that nobody owns. Provenance cannot be signed by an unverifiable identity. The fix is moving the release path onto a managed CI service with hosted, isolated runners and provenance attestation per build before claiming any SLSA level.

Signing happens, verification does not

The team signs artefacts but the deployment system does not verify the signature. A swapped artefact installs cleanly because nothing checks. The fix is enforcing signature verification at install time and breaking the deployment when verification fails rather than treating it as advisory.

Customer communication lags exploitation

A widely-deployed component CVE is exploited in the wild. Customers are asking whether your product is affected. The team has no published VEX statement, no advisory, no customer-facing evidence room, and no documented disclosure timeline. Support tickets pile up and the security team improvises responses one customer at a time. The fix is publishing VEX as a programme habit and standing up the evidence room before the next incident.

Container base layers ignored

The team scans application dependencies but uses a public latest-tagged base image pulled at every build. The OS-layer CVE surface is invisible. The fix is curated base images from a controlled internal registry, pinned digests, and container scanning that extends down into the base.

Programme owned by no one

AppSec owns SCA. The platform team owns CI. GRC owns the audit. The vulnerability management team owns the response. The CISO assumes someone has a plan. Nobody owns the cross-team operating model and gaps surface only during an incident or an audit. The fix is naming an owner for the supply chain programme with the authority to coordinate across teams and pulling the operating record into one place so the gaps are visible before they surface as incidents.

How SecPortal Supports a Software Supply Chain Programme

SecPortal is the operating-side record a supply chain programme runs on. It is not a replacement for SCA scanners, container scanners, or build systems; it is the place the findings, the evidence, the engagements, and the audit trail land so the programme stays coherent across the teams that own pieces of the chain.

The capabilities that map directly to supply chain workstreams:

Code scanning runs SAST and SCA against repositories connected through Git provider OAuth, with findings landing in the canonical findings record. Semgrep ships as part of the scanner image so source and dependency analysis run in the same pipeline.
Repository connections hold the OAuth connections to GitHub, GitLab, and Bitbucket so the scan target list stays current as the team adds and retires repositories.
Bulk finding import ingests output from external scanners (Snyk, Trivy, Grype, OSV-Scanner, custom CI checks) so the platform stays the canonical record regardless of which scanner produced the finding.
Findings management records each finding with CVSS scoring, the affected component, the named owner, the remediation history, and the retest evidence. The same record answers the supply chain CVE question, the customer security questionnaire, the audit evidence request, and the internal triage queue.
External scanning and authenticated scanning produce the runtime view that complements the static SBOM and SCA view so supply chain CVEs that only manifest in configured systems are caught.
Engagement management holds third-party penetration test cycles, secure-code review engagements, and coordinated vulnerability disclosure engagements as structured records with linked findings, evidence, and retest history.
Document management stores the threat model document, the SBOM exports, the VEX statements, the signing-key inventory, the build pipeline runbook, the customer-facing advisories, and the SSDF attestation artefacts as versioned records with effective dates.
Compliance tracking maps findings into NIST SSDF, CISA SSDF Attestation, SLSA practices, ISO/IEC 27001, SOC 2, NIS2, DORA, and the EU CRA so the cross-framework evidence pack is built once and projected per audit rather than rebuilt per cycle.
Encrypted credential storage holds the credentials that authenticated scanners use against the runtime environment, with AES-256-GCM encryption, named-owner access, and audit-logged retrieval.
The activity log captures every state transition on every engagement, finding, scan, document version, and team membership change with timestamp and user attribution. The CSV export is the provenance trail regulators and enterprise buyers review against.
MFA enforcement protects the workspace and the portal so the supply chain operating record itself meets the access-control evidence expectation auditors apply to the underlying systems.
AI report generation composes supply chain status summaries from the live record so the CISO update, the customer advisory, and the regulator notification read consistent with the underlying operating record.

The operational workflows that turn the capability mix into a programme:

Dependency vulnerability triage for the SCA-output-to-owned-finding pipeline that turns scanner noise into a prioritised queue.
Secret scanning remediation workflow for the leaked-credential rotation and revocation discipline.
Container image vulnerability remediation workflow for the base-image and image-layer CVE response model.
SBOM management and VEX publishing for the inventory plus exploitability statement discipline.
SDLC vulnerability handoff for the AppSec-to-engineering handoff that closes the finding rather than leaving it open in a queue.
Customer security evidence room for the downstream customer-facing release pipeline that exposes signed advisories and the patched-version reference.
Control mapping cross-framework crosswalks for the projection discipline that turns one supply chain control into multi- framework citations.

Who Runs the Programme Inside the Operator

A supply chain programme is not single-owner. The roles below collaborate around the same operating record. Naming the owner per workstream is what keeps the programme from stalling between the teams.

AppSec teams own the source-side controls (SAST, SCA, secret scanning, code review), the dependency triage queue, and the SDLC handoff.
Product security teams own the per-product threat model, the SBOM and VEX programme, customer advisories, and coordinated disclosure intake.
Vulnerability management teams own the prioritisation stack (CVSS, EPSS, KEV, reachability), the exception register, and the remediation tracking record.
Security engineering teams own the build pipeline hardening, signing infrastructure, provenance attestation, and SLSA-level uplift.
GRC and compliance teams own the SSDF attestation, the CRA evidence pack, the audit response, and the cross-framework mapping.
CISOs and security leaders own the cross-team operating model, the programme charter, the executive reporting, and the funding case for hardening below SLSA Level 2.
Internal security teams own the day-to-day operating record across products and the queue execution discipline that keeps the programme from drifting between assessments.
DevSecOps platform leads own the developer guardrails (pre-commit hooks, PR checks, lockfile policy, registry configuration) that catch supply chain risk before merge.

Practical Next Steps for the Programme Owner

Supply chain programmes mature in stages. The steps below describe a working sequence for the programme owner who has the authority to coordinate across AppSec, GRC, vulnerability management, and CISO.

Name the supply chain programme owner with cross-team authority. Without a named owner, the workstreams stay in separate silos and gaps surface during incidents.
Document the threat model across source, dependencies, build, signing, distribution, and runtime. Store the threat model as a versioned artefact and review it on a defined cadence.
Generate SBOMs at build time for every shipped artefact. Extend the SBOM into container base layers. Sign the SBOM. Store every released SBOM alongside the release record.
Stand up the dependency triage queue with CVSS, EPSS, KEV, and reachability layered on top of SCA output. Route every dependency CVE to a named owner with a deadline.
Move the release path onto a hosted, controlled CI service. Generate signed provenance per build. Target SLSA Build Level 2 as the baseline and Level 3 where the product profile justifies the cost.
Enforce signature verification at install time. Refuse unsigned artefacts in production deployment pipelines.
Publish VEX statements alongside SBOMs and customer-facing security advisories. Stand up the customer security evidence room as the canonical release point.
Document the coordinated vulnerability disclosure policy and the intake path. Maintain the disclosure timeline runbook aligned with ISO/IEC 29147 and 30111.
Map the programme into NIST SSDF, CISA SSDF Attestation, SLSA practices, ISO/IEC 27001 A.5 (supplier relationships) and A.8 (technology controls), SOC 2 CC9, NIS2 supply chain risk management, DORA ICT third-party risk, and the EU CRA. Build the evidence pack once and project it into each audit.
Operate the programme as an ongoing record, not as a quarterly project. The teams that operationalise the supply chain discipline pass audits and incidents from the same record they read against day to day.

Run Software Supply Chain Security as a Programme, Not as a Tool Stack

SecPortal holds the operating record a supply chain programme runs against: code scanning, repository connections, bulk finding import, findings management with CVSS and owner tracking, document management for threat models, SBOMs, VEX statements and advisories, compliance tracking across SSDF, CRA, NIS2, DORA, SOC 2, and ISO 27001, engagement management for third-party tests and disclosures, and the activity log as the provenance trail. The evidence pack you release to regulators, customers, and auditors stays consistent with what the team operates against day to day.

Start your free trial Explore SBOM and VEX workflow See pricing

Frequently Asked Questions

What is software supply chain security?

The discipline of protecting every input to a software product, every step that builds and packages it, and every artefact that ships to customers. The chain spans source code, third-party dependencies, container base images, build pipelines, secrets, signing and provenance metadata, registries, release channels, and the runtime environment. Supply chain security combines threat modelling, SBOM, SLSA, signing, VEX, vulnerability management, and audit-grade evidence into one operating model.

What are the main types of software supply chain attacks?

Dependency confusion, typosquatting, maintainer account takeover, build pipeline tampering, signed-artefact bypass, update channel poisoning, container base image poisoning, and source code review bypass. Each pattern has a different control surface. A programme that covers SCA alone leaves most of these gaps open.

How does SBOM fit into supply chain security?

The SBOM is the inventory of every component shipped in a product, in SPDX or CycloneDX format. It is the foundation for vulnerability matching, VEX publishing, customer assurance, and regulatory reporting (CRA, NIS2, federal procurement). An SBOM that is generated but never consumed by downstream processes is a compliance artefact rather than an operational tool.

What is SLSA?

SLSA (Supply-chain Levels for Software Artefacts) is a framework for build integrity with progressive levels. Level 1: documented build. Level 2: hosted build service with signed provenance. Level 3: hardened, isolated builds with non-falsifiable provenance. Most enterprise programmes target Build Level 2 or 3 as the operating standard.

What does NIST SSDF require?

NIST SP 800-218 defines four practice groups: prepare the organisation (PO), protect the software (PS), produce well-secured software (PW), and respond to vulnerabilities (RV). Load-bearing practices for supply chain security include code protection, release integrity verification, secure build configuration, and ongoing vulnerability identification. SSDF underpins the CISA Secure Software Development Attestation.

What does the EU CRA require?

The Cyber Resilience Act requires manufacturers of products with digital elements to document vulnerabilities and components (SBOM), apply regular security testing, provide updates for a support period, run a coordinated vulnerability disclosure policy, and report actively exploited vulnerabilities within 24 hours and severe incidents within 72 hours of becoming aware.

What is VEX?

VEX (Vulnerability Exploitability eXchange) is a machine-readable statement a publisher releases per CVE per product, with the status set to Affected, Not Affected, Fixed, or Under Investigation, plus a justification for Not Affected statuses. VEX filters the long tail of CVEs that match listed SBOM components but are not exploitable in product context, and is increasingly expected by regulators and enterprise procurement.

How are CI/CD pipeline attacks prevented?

Ephemeral, isolated runners. Short-lived scoped secrets fetched from a vault. Branch protection plus required code review on every merge. Signed commits and signed artefacts. Provenance attestation per build (SLSA Build Level 2 or 3). Two-party review on changes to pipeline definitions. Pinned dependency versions in lock files. Scoped registry credentials. Audit logs that capture every pipeline run with the triggering identity.

What is dependency confusion?

An attack where the attacker publishes a package to a public registry with the same name as an internal private package, and a misconfigured client resolves the public copy first. Prevention: scope internal packages to a private namespace, configure package managers to pull internal names only from the internal registry, reserve internal names on public registries, and pin with checksums.

What does an enterprise supply chain programme look like?

Five workstreams owned across teams. Inventory (SBOM generation and ingestion). Threat modelling (documented and reviewed). Detection (SCA, SAST, secrets, container, source review). Verification (signing, SLSA provenance, base-image control). Response (VEX, CISA KEV ingest, coordinated disclosure, customer advisories). AppSec or product security runs detection and verification. GRC owns audit and customer evidence. CISO owns the cross-team operating model.

How does SecPortal support a supply chain programme?

SecPortal holds the operating record the programme runs on: code scanning, repository connections, bulk finding import, findings management with CVSS and ownership, engagement management for third-party tests and disclosures, document management for threat models and advisories, compliance tracking across SSDF, CRA, NIS2, DORA, SOC 2, and ISO 27001, encrypted credential storage for authenticated scanners, MFA enforcement, the activity log as the provenance trail, and AI report generation that composes summaries from the live record.