Software Supply Chain Security Language Exercises

An SBOM (Software Bill of Materials) is a formal, machine-readable inventory of all components, libraries, and dependencies included in a software product, along with their versions and licensing information. Engineers describe it as: "the SBOM gives us full visibility into our dependency tree so we can quickly identify which products are affected when a new CVE is disclosed" or "we generate an SBOM as part of every CI build and attach it to the release artifact." Common formats are SPDX and CycloneDX.

SLSA (Supply-chain Levels for Software Artifacts, pronounced "salsa") is a security framework that defines four levels of increasing supply chain integrity guarantees. You might explain it as: "SLSA is a maturity model for build security — at Level 1 you have documented build processes, at Level 2 your build is hosted on a tamper-resistant platform, at Level 3 builds are isolated and the provenance is non-falsifiable." The framework's core output is a provenance attestation that links a build artifact to its source code and build process.

Key terms include CVE (Common Vulnerabilities and Exposures) identifier, CVSS score (Common Vulnerability Scoring System, rated 0–10), affected version range, patched version, and exploitability. In a security briefing you would say "a critical CVE with a CVSS score of 9.8 was disclosed in log4j — our SBOM analysis shows 12 services depend on affected versions; we are triaging by exploitability and applying patches starting with customer-facing services."

Artifact signing uses cryptographic signatures to verify that a build artifact (container image, binary, or package) was produced by a trusted source and has not been tampered with. Common phrasing: "we sign all container images using Sigstore/Cosign before pushing to the registry — downstream consumers can verify the signature against our public key" or "artifact signing closes the gap between the source code we audited and the binary that gets deployed."

A transitive dependency is a package that your code does not directly depend on but is pulled in by one of your direct dependencies. The risk communication might be: "we don't directly depend on the vulnerable library, but it is a transitive dependency of our ORM — we need to update the ORM to a version that has remediated the issue, or override the transitive dependency explicitly." Tools like dependency-check and Dependabot surface these automatically.

Typosquatting is a social-engineering attack where a malicious package is published under a name that closely resembles a popular legitimate package (e.g., "requets" instead of "requests"). In security reviews you would say "we enforce a package allowlist in our build pipeline to prevent typosquatting attacks" or "our dependency scanning policy flags any newly introduced package that was not previously in our approved inventory for manual review before it can be merged."

Dependency pinning means locking a dependency to a specific version (or commit hash) rather than a version range, ensuring reproducible builds. The trade-off is discussed as: "pinning gives us build reproducibility and prevents unexpected breaking changes, but it means we must proactively update pins to receive security patches — an unpinned range would pick them up automatically but risks unintended upgrades." A common middle ground is using a lock file (package-lock.json, Pipfile.lock) combined with automated dependency update tooling.

A supply chain attack compromises a trusted component or build process to deliver malicious code to downstream consumers. High-profile examples include the SolarWinds and XZ Utils incidents. Engineers frame it as: "the attacker didn't target our system directly — they compromised an upstream build pipeline and injected malicious code into a library we trusted" or "our SLSA Level 3 controls were designed specifically to make this class of build-time attack detectable."

Provenance is a signed, verifiable statement that describes how and where a software artifact was built — linking it to source code, builder identity, build parameters, and inputs. You would say "our build platform generates a SLSA provenance attestation for every artifact — it records the exact commit SHA, builder version, and build environment so any consumer can independently verify the artifact's origin" or "we use in-toto attestations to create a full chain of custody from source to deployment."

Vulnerability management in supply chain security covers the continuous process of discovering, prioritising, remediating, and verifying vulnerabilities in dependencies. Reporting language: "our mean time to remediate critical CVEs is currently 4 days, against an SLA of 7 days," "we have 3 open high-severity findings with accepted risk and documented compensating controls," and "the weekly dependency scan found 2 new medium-severity vulnerabilities — both have available patches and are scheduled for the next release." Metrics like MTTR, open finding age, and fix rate are standard KPIs.