FrameworkGuidesModulesRelease NotesAbout

Supply Chain Security for Pentesters: SBOMs and Code Signing Post-OWASP 2025

Understand how SBOMs and code signing reshape the pentester's approach to supply chain security, with practical assessment techniques and defensive recommendations for the post-OWASP 2025 landscape.

Supply Chain Security for Pentesters: SBOMs and Code Signing (Post-OWASP 2025)

The software supply chain became a first-class security concern after SolarWinds, Log4Shell, and the xz-utils backdoor. By 2025, OWASP had updated its guidance to reflect supply chain risks as a top priority, and regulatory frameworks (EU Cyber Resilience Act, US Executive Order 14028) began mandating Software Bills of Materials (SBOMs) and code signing practices. In 2026, these are not just compliance checkboxes — they are security controls that pentesters need to understand, test, and validate.

This article examines SBOMs and code signing from the pentester's perspective: what they actually protect against, how to assess their implementation, and where the common gaps are.

What Changed Recently

SBOM Maturity

SBOMs have evolved from a nice-to-have documentation practice to a regulatory requirement in multiple jurisdictions:

  • CycloneDX and SPDX are the two dominant formats, both with mature tooling for generation, validation, and consumption.
  • Automated SBOM generation is integrated into CI/CD pipelines. Tools like Syft, Trivy, and the OWASP Dependency-Track platform produce SBOMs automatically at build time.
  • SBOM consumption — vulnerability scanning against SBOMs is now standard. When a new CVE is published, organizations can query their SBOM database to determine exposure within hours.
  • Regulatory mandates — The EU CRA requires SBOMs for products sold in the EU. US federal contracts increasingly mandate SBOM delivery.

Code Signing Practices

Code signing practices tightened significantly in 2025–26:

  • Sigstore adoption — The Sigstore project (cosign, Rekor, Fulcio) provides keyless signing tied to identity, with a transparency log for audit. It is now the default signing mechanism for many open-source ecosystems.
  • Build provenance — SLSA (Supply-chain Levels for Software Artifacts) framework adoption increased. Build provenance attestations verify that an artifact was built by a specific CI/CD pipeline from a specific source commit.
  • Mandatory signing — Package registries (npm, PyPI, Docker Hub) increasingly require or incentivize package signing.

How SBOMs Work and Where They Fall Short

What SBOMs Do Well

An SBOM lists every component in a software artifact — direct dependencies, transitive dependencies, versions, and licenses. This enables:

  • Vulnerability tracking — Cross-reference the SBOM against CVE databases to identify known vulnerabilities.
  • License compliance — Verify that all components comply with organizational and legal requirements.
  • Incident response — When a new vulnerability is disclosed, quickly determine which systems are affected.

Where SBOMs Fall Short

  • Build-time vs runtime — An SBOM captures what was built, not necessarily what is running. Dynamic loading, plugins, and runtime dependency resolution can introduce components not listed in the SBOM.
  • Accuracy depends on tooling — SBOM generators vary in completeness. Some miss vendored dependencies, C/C++ libraries statically linked, or platform-specific components.
  • Consumption gap — Many organizations generate SBOMs but do not have mature processes for consuming and acting on them. An SBOM sitting in a repository is documentation, not security.
  • No integrity guarantee — An SBOM says what should be there, not that the actual artifact matches. Without integrity verification (signing, hash comparison), the SBOM is an assertion, not proof.

How Code Signing Works and Where It Falls Short

What Code Signing Does Well

Digital signatures on software artifacts provide:

  • Integrity — Verification that the artifact has not been modified since signing.
  • Attribution — Identification of who (or what build system) produced the artifact.
  • Trust chain — A chain from the artifact back to a trusted authority (CA or transparency log).

Where Code Signing Falls Short

  • Signs intent, not quality — A signed artifact is verified to be from a specific publisher. It says nothing about whether that artifact contains vulnerabilities, malware, or backdoors. Signed malware is well-documented (as discussed in the earlier article on root CA abuse).
  • Key management complexity — Private key protection is critical and difficult. Compromised signing keys undermine the entire model.
  • Revocation is slow — Certificate and signature revocation mechanisms (CRLs, OCSP) have latency. A compromised signing key can be used to sign malicious artifacts before revocation propagates.
  • Trust-on-first-use (TOFU) — For many ecosystems, the first time you install a package, you implicitly trust whatever key signed it. There is no independent verification that the key belongs to who you think it does.

The Pentester's Assessment Approach

SBOM Assessment

  1. Verify SBOM exists and is current — Does the organization generate SBOMs for its software? Are they generated automatically at build time or manually?
  2. Check completeness — Compare the SBOM against actual dependencies. Look for vendored code, statically linked libraries, and runtime-loaded components that are missing.
  3. Test the consumption pipeline — When a test CVE is "disclosed" (simulated), how quickly can the organization determine which systems are affected? Measure the time from disclosure to identification.
  4. Verify SBOM integrity — Is the SBOM itself signed? Can it be tampered with? If someone modifies the SBOM to remove a vulnerable component, would anyone notice?
  5. Assess scope gaps — Does the SBOM cover only first-party code, or does it include infrastructure, containers, and firmware? Most SBOMs are scoped too narrowly.

Code Signing Assessment

  1. Key management audit — Where are signing keys stored? Are they in HSMs? Who has access? What is the rotation schedule?
  2. Verification enforcement — Does the deployment pipeline actually verify signatures before deployment? Many organizations sign artifacts but do not enforce verification.
  3. Revocation testing — If you revoke a test certificate, how quickly do systems stop accepting artifacts signed with that certificate?
  4. Build provenance validation — If SLSA provenance attestations are used, verify that the provenance chain is intact from source to deployment.
  5. Compromise simulation — If a signing key were compromised, what is the blast radius? What is the response plan?

Common Detection Blind Spots

  1. SBOM without action — Generating SBOMs satisfies compliance requirements but provides no security value without a vulnerability management process that consumes them.
  2. Signing without verification — Many organizations sign their artifacts but do not enforce signature verification at deployment time. The signature is cosmetic.
  3. Transitive dependency blindness — SBOMs that only list direct dependencies miss the transitive dependency tree, which is where most supply chain vulnerabilities live (Log4Shell was a transitive dependency for most affected applications).
  4. No build environment security — SBOMs and signing assume the build environment is trustworthy. If the CI/CD pipeline is compromised, both the SBOM and the signature will reflect the compromised build.

Practical Hardening and Monitoring Guidance

For Development and Security Teams

  • Automate SBOM generation — Integrate SBOM generation into CI/CD as a mandatory build step. Use standard formats (CycloneDX or SPDX) for interoperability.
  • Implement continuous SBOM monitoring — Use tools like Dependency-Track to continuously scan SBOMs against vulnerability databases. Alert on new CVEs that match components in your SBOMs.
  • Enforce code signing and verification — Sign all artifacts and verify signatures at every deployment boundary. Use Sigstore for open-source and HSM-backed keys for commercial software.
  • Secure the build pipeline — Harden CI/CD runners, enforce least-privilege access, and implement build provenance using SLSA.
  • Practice supply chain incident response — Tabletop exercises for "a dependency is compromised" scenarios validate your organization's response capability.

Lab Testing Context

In the Veil Framework lab context, supply chain security concepts apply to how payloads are built, distributed, and verified. Understanding code signing helps defenders recognize when BYOVD attacks exploit legitimately signed but vulnerable drivers, and SBOM concepts inform the detection of compromised dependencies in build pipelines.

For related security assessment approaches, see the Veil command-line usage reference and the guides section for structured testing workflows.

Related Reading

An SBOM tells you what you built. A signature tells you who built it. Neither tells you it is safe. Supply chain security is the combination of visibility, integrity, and continuous validation — and pentesters are uniquely positioned to test whether those layers actually hold up.