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 / 10
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 / 10
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 / 10
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 / 10
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."
6 / 10
Alex (Lead Security Engineer) posted this to the team Slack channel: 'Just a heads-up – we're seeing an uptick in reports of vulnerabilities related to outdated Node.js dependencies. Let's ensure everyone's using tools like Snyk to proactively scan our projects and maintain a consistent Software Bill of Materials.' Which of the following best describes SBOM as used in this context?
The question uses a realistic Slack scenario. An SBOM (Software Bill of Materials) isn't just about performance or deployment; it's specifically a list of *all* components in a software project, including dependencies and their versions – crucial for identifying vulnerable packages. Option A is incorrect because an SBOM doesn't measure server performance. Option B describes automated deployment tools.
7 / 10
Sarah, a Code Reviewer, added this comment to a pull request for a new microservice: 'This service uses the `lodash` library. Ensure you've included its SHA-256 digest in your build process and that it's pinned to prevent future vulnerabilities caused by updates.' What is SHA-256 digest referring to here?
The comment highlights the importance of pinning dependencies. The SHA-256 digest is a cryptographic hash – a unique fingerprint – of the `lodash` library's content. This ensures that if the package changes (even unintentionally), the digest will be different, alerting the team to a potential vulnerability or unauthorized modification. Option A is incorrect as it describes a code integrity check.
8 / 10
Ben (Platform Engineer) is preparing a presentation on container image security. He states: 'To maintain consistent and verifiable builds, we're mandating the use of SHA-256 digests for all production container images. This means every image will be identified by its unique hash value instead of just a tag.' What's the primary benefit of using SHA-256 digests in this scenario?
The core benefit is immutability. By using SHA-256 digests instead of tags, the platform can guarantee that the deployed image remains exactly as it was built – preventing unintended modifications during updates or deployments. Option B describes a feature of immutable infrastructure, not the digest itself. Option C and D are related benefits but aren't the primary reason for using digests.
9 / 10
Chloe (DevSecOps Engineer) is explaining SLSA levels to a new team member. She says: 'SLSA stands for Supply-chain Levels for Software Artifacts. Each level represents a different stage in the software development lifecycle, with increasing security controls.' Which of the following best describes what Level 2 in the SLSA framework might focus on?
Level 2 of SLSA primarily focuses on *reproducible builds*. This involves scripting the build process to ensure it's automated, verifiable, and resistant to tampering. This is a critical step in preventing supply chain attacks where malicious code could be injected into the build. Options A, C & D are more related to later levels of SLSA.
10 / 10
David (Security Analyst) is investigating a potential supply chain compromise. He discovers that an internal package used by several microservices has a vulnerable dependency – `openssl`. The vulnerability was not present in the public registry, but was included in a custom build. What attack type does this scenario primarily illustrate?
Dependency confusion is a classic supply chain attack. It occurs when attackers upload a package with the same name as an internal one, but without publishing it publicly. This trick can lead developers to unknowingly use the malicious package, introducing vulnerabilities into their systems. Option A and B describe different types of web application attacks. Option D relates to service disruption.
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 10 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 10 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.