Software supply chains, dependencies, SBOMs and code signing

Learn how software dependencies, bills of materials and code signatures help teams understand and reduce supply-chain risk.

A software supply chain is the network of people, organizations, tools, components and processes involved in producing, distributing and maintaining software. A security problem can enter through a dependency, build system, update channel or another part of this chain. Software supply-chain security addresses risks across these stages rather than assuming a finished package is trustworthy.

## What is a software dependency?

A dependency is another software component that a product relies on. For example, an application may use a library to parse dates; that library may in turn rely on other packages. Direct dependencies are declared or used by the product itself, while transitive dependencies are reached through another dependency. They may change when software is built or updated. Knowing the version and where a component is used helps teams investigate a relevant vulnerability, but a name alone is not enough to determine exposure.

## What is an SBOM?

A software bill of materials (SBOM) is a machine-readable inventory of software components, associated information and their relationships. It can include open-source and commercial components and may represent source, build or deployed software. Different generation methods can leave gaps: record the scope, version, time and known unknowns, and update the inventory as the product changes. [CISA describes SBOM scope and transparency](https://www.cisa.gov/sites/default/files/2024-10/SBOM%20Framing%20Software%20Component%20Transparency%202024.pdf).

For example, an SBOM can help a team find which product versions include a library after a vulnerability is disclosed. It does not itself say whether that vulnerability is exploitable in a particular deployment, prove the inventory is complete, or fix the issue. Combine component data with vendor advisories, deployment context and remediation decisions; see [CISA’s SBOM consumption guidance](https://www.cisa.gov/sites/default/files/2024-08/SECURING_THE_SOFTWARE_SUPPLY_CHAIN_RECOMMENDED_PRACTICES_FOR_SOFTWARE_BILL_OF_MATERIALS_CONSUMPTION-508.pdf). For identifiers and severity scores, see [our CVE, CVSS and CWE guide](https://blog.mithril.fund/cve-cvss-cwe-explained?lang=en).

## What is code signing?

Code signing applies a digital signature to software or an artifact. A verifier checks the signature against a public key and an appropriate trust policy to assess whether the artifact was altered and whether it was signed by an accepted signer. Certificates, key ownership, revocation and the verification policy matter. A valid signature does not establish that the signer is trustworthy in every context or that the code is free of vulnerabilities; a compromised signing key can be misused. [NIST’s code-signing guidance](https://csrc.nist.gov/pubs/cswp/5/security-considerations-for-code-signing/final) explains the security considerations.

## Practical steps

Keep an accurate inventory of components and direct and transitive dependencies, identify owners, monitor relevant advisories, and update or mitigate according to exposure and operational constraints. Protect build and signing systems, limit signing-key access, verify artifacts against the intended identity, and maintain a tested response and rollback process. Review provenance and changes throughout the lifecycle; no single control establishes that a product is safe. Sources reviewed on 2026-10-29.