A security architect briefs an engineering team: "After the SolarWinds and Log4Shell incidents, every organisation needs an SBOM — a Software Bill of Materials. An SBOM lists every component in your software: direct dependencies, transitive dependencies, their versions, licenses, and known vulnerabilities. If a new CVE drops, you can query your SBOM to find every service that uses the affected package." What is an SBOM and why is it important for supply chain security?
SBOM (Software Bill of Materials): a machine-readable inventory of every component in a software product. Analogous to a food ingredient list. SBOM formats: SPDX (Software Package Data Exchange) — Linux Foundation standard; used widely in open source. CycloneDX — OWASP standard; popular for DevSecOps tooling. SBOM vocabulary: Direct dependency — a library your code explicitly imports. Transitive dependency — a library your dependency depends on (you don't import it directly, but it's in your supply chain). License expression — SPDX-format license identifier, e.g., Apache-2.0, MIT, GPL-3.0-only. Known vulnerability — a CVE (Common Vulnerabilities and Exposures) entry in NVD or OSV. With an SBOM, security teams can run: "show me all services using log4j <2.17" immediately after a CVE is published. Use cases: incident response, license compliance, export control. In the US, SBOM is now required for software sold to the federal government (Executive Order 14028). In conversation: "We generate an SBOM at build time and store it in our artifact registry alongside the image — so we always know exactly what's in every release."
2 / 5
A DevSecOps engineer presents SLSA levels to the team: "SLSA — pronounced 'salsa' — stands for Supply-chain Levels for Software Artifacts. It's a security framework with four levels. Level 1: the build process is scripted and generates provenance. Level 2: the build uses a hosted CI service and provenance is signed. Level 3: builds are hermetic — no network access, fully isolated. Level 4: two-person review and reproducible builds." What is provenance in the context of SLSA?
Provenance: verifiable metadata describing the build process for an artifact. Answers: "who built it, from what source, using what build system, at what time?" SLSA vocabulary: SLSA Level 1 — build is scripted (e.g., Makefile, GitHub Actions workflow); provenance document is generated. SLSA Level 2 — build uses a hosted CI/CD service; provenance is signed by the build service. SLSA Level 3 — hermetic build (no network access during build; fully reproducible inputs); provenance is non-falsifiable. SLSA Level 4 — two-person review of all changes; reproducible builds (same inputs = identical output bit-for-bit). Hermetic build — a build that has no external network access; all inputs are declared and pinned. Reproducible build — given the same inputs, the build always produces byte-identical outputs. Attestation — a signed statement about an artifact (e.g., "this image passed these security scans"). In conversation: "We're targeting SLSA Level 2 this quarter — that means signed provenance from GitHub Actions for every release artifact."
3 / 5
A security engineer introduces Sigstore to the team: "Sigstore is a free, open-source project for signing and verifying software artifacts. We use cosign to sign our container images. The signature goes to Rekor — a public, append-only transparency log. Fulcio issues short-lived signing certificates tied to your GitHub identity — so we can do keyless signing without managing long-lived private keys." What problem does keyless signing solve in software supply chain security?
Keyless signing: a Sigstore approach where short-lived signing certificates are issued at signing time (tied to an OIDC identity like a GitHub Actions workflow), used to sign the artifact, and immediately discarded. No long-lived private key to manage, rotate, or worry about being stolen. Sigstore components: cosign — CLI tool for signing and verifying container images and other artifacts. Rekor — an append-only, tamper-evident transparency log. Every signature is recorded publicly; anyone can verify. Fulcio — a certificate authority that issues short-lived code-signing certificates based on OIDC identity (GitHub, Google, Microsoft). sigstore/policy-controller — Kubernetes admission controller that enforces cosign signature requirements before allowing images to run. Artifact security vocabulary: Artifact digest — SHA-256 hash of a container image or build artifact; used for pinning. Example: `sha256:a1b2c3...` Image tag — mutable pointer (e.g., `v1.2.3`); can be moved. Image digest — immutable. Always pin to digest in production. In conversation: "After Log4Shell, we pinned all dependencies to their SHA-256 digest and started signing releases with cosign — so we can prove the image wasn't tampered with."
4 / 5
A security team lead explains an attack scenario: "Dependency confusion is a supply chain attack. Internal packages have names that aren't published to the public registry. The attacker publishes a malicious package with the same name to PyPI or npm with a higher version number. Package managers that check public registries first will download the attacker's package instead of the internal one — without any warning." What is dependency confusion and how is it prevented?
Dependency confusion (also: namespace confusion): a supply chain attack published by Alex Birsan in 2021. The attacker registers a public package matching a private internal package name at a higher version. Package managers that search public registries first silently install the attacker's package. Prevention: Package scoping — prefix internal packages with a company scope (e.g., `@mycompany/internal-lib` on npm). Private registry configuration — configure package managers to use internal registry for all company-scoped packages. Registry pinning — lock all packages to exact versions + checksums (lock files). Checksum verification — pip, npm, and cargo support `--require-hashes`. Supply chain attack taxonomy: Typosquatting — malicious package with a name similar to a popular one (e.g., `reqeusts` instead of `requests`). Compromised maintainer — attacker takes over a legitimate maintainer account and pushes malicious updates. Build tampering — modifying the build pipeline to inject malicious code at compile time (like SolarWinds). CVE — Common Vulnerabilities and Exposures; CVSS score (0–10) rates severity. In conversation: "We now scope all internal npm packages under @company/ and have a Nexus proxy that refuses to resolve unscoped packages from the public registry."
5 / 5
A platform engineer enforces supply chain policies: "We're requiring all production container images to be pinned to their SHA-256 digest — not just a tag. Tags are mutable: v1.0.0 can be overwritten. The digest is immutable — it's the cryptographic hash of the image content. We're also requiring cosign verification in our admission controller: no unsigned images run in the cluster." Why is pinning to a digest more secure than pinning to a tag?
Image tag: a human-readable, mutable pointer (e.g., `nginx:1.25`, `myapp:v2.0.1`). The registry owner can push a new image with the same tag. Image digest: a SHA-256 hash of the image manifest — cryptographically tied to exact content. Cannot be changed without changing the digest. Format: `myapp@sha256:a1b2...` Container image security vocabulary: Image signing — attaching a cryptographic signature to an image digest proving who built it. Admission controller — a Kubernetes component that intercepts API requests. Used to enforce: "only signed images from our registry." OCI (Open Container Initiative) — the standard for container image format and distribution. Signatures are stored as OCI artifacts in the same registry. Immutable tags — a registry policy preventing overwriting of published tags (e.g., ECR immutable tags). SBOM attestation — a signed SBOM attached to an image via cosign. Vulnerability scanning — tools like Trivy, Grype, or Snyk scan images against CVE databases. In conversation: "Our GitOps repo references images by digest — if the digest doesn't match what Cosign signed, the admission controller rejects the pod."
These modules build the same on-the-job skills as Software Supply Chain Security Vocabulary
— work through them together for a fuller vocabulary set.
Container Security— useful for Container & supply-chain security (Cybersecurity)
Frequently Asked Questions
What does the "Software Supply Chain Security Vocabulary" vocabulary exercise cover?
This exercise tests real IT vocabulary related to software supply chain security vocabulary through 5 multiple-choice questions, each built from realistic workplace sentences rather than abstract definitions.
Is this vocabulary exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is completely free — no account, sign-up, or payment required.
How many questions does this exercise have?
This exercise has 5 questions. Each one shows a real-world sentence or scenario with multiple-choice options and an explanation once you answer.
What happens after I answer a question?
You'll see immediate feedback showing whether your answer was correct, along with a short explanation of why — then a button to move to the next question, and a full results screen at the end.
Can I retry the exercise if I get questions wrong?
Yes. Once you reach the results screen, click "Try again" to reset your answers and go through the exercise from the start as many times as you like.
Do I need to create an account to take this exercise?
No account is needed. Your answers are scored in your browser during the session — nothing is saved to a server, so you can jump straight in.
Is my progress saved if I leave the page?
No — progress within an exercise resets if you navigate away or reload. Each exercise is short enough to complete in a few minutes in one sitting.
Are these vocabulary exercises connected to other topics?
Yes — this module shares real-world context with 1 other vocabulary module. See "Related vocabulary" below to keep building a connected skill set.
How is this different from reading a glossary or blog article?
Exercises like this one are active recall drills — you have to choose the correct term or phrasing yourself, which builds retention faster than passively reading a definition.
Where can I find more vocabulary exercises?
Browse the full Vocabulary exercises hub for hundreds of modules covering Agile, DevOps, security, databases, architecture, and more — organised by IT role and skill.