Skip to content

Chapter 54 Quiz: SBOM Operations & Software Composition Analysis

Test your knowledge of Software Bill of Materials formats (SPDX vs CycloneDX), SBOM generation tools, dependency analysis, dependency confusion attacks, license compliance, vulnerability correlation, malicious package detection, SCA pipelines, VEX integration, and SBOM security architecture.

Questions

1. What is a Software Bill of Materials (SBOM), and why did Executive Order 14028 make it a federal requirement?

  • A) An SBOM is a vulnerability scan report
  • B) An SBOM is a machine-readable inventory of all software components, dependencies, and metadata in a product — EO 14028 mandated SBOMs for federal software procurement because supply chain attacks (SolarWinds, Log4Shell, Codecov) demonstrated that organizations cannot defend what they cannot see, and SBOMs provide the visibility needed to rapidly answer "are we affected?" when a new vulnerability is disclosed in any dependency
  • C) An SBOM only lists open-source components, not proprietary ones
  • D) EO 14028 only applies to defense contractors
Answer

B — An SBOM is a machine-readable inventory of all software components, dependencies, and metadata in a product

The NTIA minimum elements for SBOMs include: supplier name, component name, version, unique identifier, dependency relationships, author of SBOM data, and timestamp. EO 14028 (May 2021) was a direct response to the SolarWinds supply chain attack and requires SBOM delivery for all software sold to the federal government. The key insight is that SBOMs transform vulnerability response from "we need to manually check every application" to "query the SBOM database for any product containing the affected component" — reducing response time from days to minutes.

2. Compare SPDX and CycloneDX SBOM formats. What are the key differences in design philosophy and use cases?

  • A) They are identical formats with different names
  • B) SPDX (ISO/IEC 5962) was designed for license compliance and originated from the Linux Foundation — it excels at tracking copyright, licensing (SPDX license identifiers), and provenance. CycloneDX (OWASP) was designed for security and risk management — it excels at vulnerability tracking, VEX integration, and supply chain intelligence. SPDX supports more output formats (JSON, RDF, YAML, tag-value, XML) while CycloneDX is JSON/XML-focused. CycloneDX natively supports VEX documents within the SBOM; SPDX handles VEX through separate linkage
  • C) SPDX is deprecated in favor of CycloneDX
  • D) CycloneDX cannot represent license information
Answer

B — SPDX focuses on license compliance (ISO standard), CycloneDX focuses on security (OWASP standard)

Both formats are actively maintained and federally accepted. The choice depends on primary use case: if your organization's SBOM program is driven by legal/compliance (license auditing, IP protection), SPDX is the stronger choice. If driven by security operations (vulnerability management, supply chain risk), CycloneDX is optimized for that workflow with native VEX support, vulnerability references, and service component modeling. Many organizations generate both formats from the same source data. Tool support: Syft, Trivy, and cdxgen support both formats.

3. What is a dependency confusion attack, and why does it specifically exploit the relationship between internal and public package registries?

  • A) Dependency confusion is when developers install the wrong version of a package
  • B) Dependency confusion exploits how package managers resolve names when both internal and public registries exist — an attacker discovers internal package names (via leaked SBOMs, job postings, or error messages), registers identically-named packages on the public registry with higher version numbers, and when a developer's package manager falls back to the public registry (due to misconfiguration, missing scope, or registry ordering), it installs the attacker's malicious package because the public version number (99.0.0) is higher than the internal version (2.3.1)
  • C) Dependency confusion only affects Python packages
  • D) Using private registries eliminates the risk entirely
Answer

B — Dependency confusion exploits package manager resolution order between internal and public registries

This attack was publicly documented by Alex Birsan in 2021 and affects npm, PyPI, RubyGems, and NuGet. The attack surface exists whenever: (1) an organization uses internal packages AND public registry fallback, (2) internal package names are discoverable (leaked SBOMs are a goldmine), (3) package managers prefer higher versions from any registry. Mitigations: use scoped packages (@company/package-name), reserve names on public registries, configure registry priority explicitly, enforce lockfile-only installs (npm ci), and disable public registry fallback in CI/CD. SC-108 (Operation GHOST DEPENDENCY) demonstrates this attack in detail.

4. How does a VEX (Vulnerability Exploitability eXchange) document complement an SBOM in vulnerability management workflows?

  • A) VEX replaces the need for SBOMs
  • B) An SBOM tells you "this product CONTAINS vulnerable component X" but cannot answer "is the vulnerability actually EXPLOITABLE in this product?" — VEX provides exactly that answer with four status values: not_affected (component present but vulnerability not reachable via code path, configuration, or compensating control), affected (vulnerability is exploitable — remediation required), fixed (was affected, now remediated), under_investigation (assessment ongoing) — this prevents organizations from wasting resources patching vulnerabilities that exist in their SBOM but cannot be triggered
  • C) VEX documents are only used by government agencies
  • D) VEX status is embedded directly in CVE records
Answer

B — SBOM says "contains vulnerable component," VEX says "is it actually exploitable?"

The vulnerability noise problem is severe: a typical enterprise application might have 500+ transitive dependencies, of which 50+ have known CVEs. Without VEX, every consumer of the SBOM must independently assess exploitability — multiplying effort across the supply chain. With VEX, the software producer (who understands the code) issues a machine-readable statement: "CVE-2024-XXXXX exists in our bundled OpenSSL, but we never call the vulnerable function X509_verify(), so status=not_affected." CSAF (Common Security Advisory Framework) 2.0 is the primary format for distributing VEX data. Together: SBOM answers "what's inside?" and VEX answers "does it matter?"

5. What are transitive dependencies, and why do they represent the largest attack surface in modern software supply chains?

  • A) Transitive dependencies are optional development tools
  • B) Transitive dependencies are indirect dependencies — packages that your direct dependencies depend on, recursively — a typical Node.js application with 20 direct dependencies may have 500-1,500 transitive dependencies, most of which the developer has never reviewed, creating a massive attack surface because: any single compromised transitive dependency can inject malicious code into every application that depends on it, version ranges in lockfiles may auto-upgrade to compromised versions, and developers have no visibility into transitive dependency changes without SBOM tooling
  • C) Transitive dependencies are only found in Python projects
  • D) Lockfiles eliminate all transitive dependency risks
Answer

B — Transitive dependencies are indirect dependencies pulled in recursively by your direct dependencies

The "dependency tree" for a modern application is deep and wide. The event-stream incident (2018) demonstrated this: a malicious actor gained maintainership of a transitive dependency (flatmap-stream) used by event-stream, which was used by thousands of applications. The attacker injected cryptocurrency-stealing code that affected every downstream consumer. SBOM generation tools (Syft, Trivy) resolve the full dependency tree and list every transitive dependency with its version, license, and known vulnerabilities — making the invisible visible.

6. What is GPL contamination in the context of license compliance, and how can SBOM-based license analysis prevent it?

  • A) GPL contamination is a type of malware
  • B) GPL contamination occurs when a copyleft-licensed component (GPL, AGPL) is included in proprietary software — under copyleft terms, the entire derivative work may be required to be released under the same open-source license, potentially forcing disclosure of proprietary source code — SBOM-based license analysis automatically scans all components (including transitive dependencies) for copyleft licenses, flags risk before distribution, and enables legal review of license compatibility before the software ships
  • C) GPL only applies to Linux kernel code
  • D) Using MIT-licensed wrappers around GPL code eliminates the obligation
Answer

B — GPL contamination means copyleft license obligations propagating to proprietary code

AGPL is the most restrictive: even providing the software as a network service (SaaS) triggers the source code disclosure obligation. License compliance is especially dangerous with transitive dependencies: a developer adds a MIT-licensed utility, which depends on a GPL-licensed parser — the GPL obligation propagates through the dependency chain. SBOM tools generate license reports per component, enabling automated policy enforcement: "block build if any AGPL component is detected" or "flag GPL components for legal review." The SPDX license identifier system standardizes license detection across ecosystems.

7. An SCA (Software Composition Analysis) pipeline detects that a dependency has a known critical vulnerability (CVSS 9.8). What gating strategy should the CI/CD pipeline use?

  • A) Block all builds with any known vulnerability regardless of severity
  • B) Apply a risk-based gating strategy: Critical vulnerabilities (CVSS ≥ 9.0) with EPSS > 0.5 block the build immediately and require developer remediation. High vulnerabilities (CVSS 7.0-8.9) generate a warning and create a tracking ticket with a 7-day SLA. Medium/Low vulnerabilities are logged for batch review. All gates should support exception workflows — if the VEX status is not_affected, the vulnerability should not block the build even if CVSS is Critical, because the code path is not reachable
  • C) Only block if the vulnerability is listed in CISA KEV
  • D) SCA should only run weekly, not on every build
Answer

B — Risk-based gating with severity thresholds, EPSS probability, VEX status, and exception workflows

The key insight is that blocking ALL vulnerabilities causes "alert fatigue" and developers will work around the system. Blocking NONE leaves the organization exposed. The risk-based approach threads the needle: genuinely dangerous vulnerabilities (high CVSS + high EPSS + no VEX exemption) block immediately, while lower-risk issues are tracked without blocking developer velocity. VEX integration is critical — if the vendor has issued a VEX statement of not_affected, blocking on that CVE wastes engineering time. The CI/CD pipeline should query VEX feeds automatically and exempt vulnerabilities with not_affected or fixed status.

8. Describe the difference between SBOM generation at build time vs. at container image analysis time. Which is more accurate?

  • A) They produce identical results
  • B) Build-time SBOM generation (e.g., Syft analyzing package-lock.json during CI) captures the exact dependency tree as resolved by the package manager, including development dependencies. Container image analysis (e.g., Trivy scanning a Docker image) captures only the runtime components actually installed in the image, which may exclude dev dependencies but also reveals OS-level packages (glibc, openssl) and system libraries that build-time analysis misses — the most accurate approach is to generate BOTH and merge them, as build-time catches application dependencies precisely while image analysis catches the full runtime stack including OS packages
  • C) Container image analysis is always more accurate
  • D) Build-time analysis captures OS packages automatically
Answer

B — Build-time captures application dependencies precisely; image analysis captures the full runtime stack. Use both.

Build-time SBOM sees: npm packages, Python wheels, Go modules — with exact versions from lockfiles. It may include dev-only dependencies (test frameworks, linters) that aren't in production. Container image SBOM sees: everything installed in the image — application packages + OS packages (apt, apk) + system libraries. It misses build-time-only tools that were excluded from the image. The recommended approach: generate a build-time SBOM in CI, generate an image SBOM post-build, merge them with deduplication, and attach both as attestations (via Cosign/Sigstore) to the container image.

9. How can a published SBOM be weaponized by an attacker, and what mitigations balance transparency requirements with security?

  • A) SBOMs cannot be weaponized — they only contain component names
  • B) A published SBOM reveals internal package names (enabling dependency confusion), exact version numbers (enabling targeted exploits for known CVEs in those versions), dependency relationships (revealing the most impactful component to compromise), and technology stack details (guiding attack tool selection) — mitigations include: redacting internal package names (use hashed identifiers), publishing SBOMs only to authorized consumers (not public websites), reserving internal package names on public registries, implementing SBOM access controls with authentication, and using delayed publication (publish SBOM after patch availability, not before)
  • C) Only government-mandated SBOMs can be weaponized
  • D) Removing version numbers from SBOMs eliminates the risk
Answer

B — Published SBOMs reveal internal names, versions, and dependency relationships that enable targeted attacks

SC-108 (Operation GHOST DEPENDENCY) demonstrates exactly this scenario: attackers downloaded a publicly published SBOM, identified 8 internal package names, registered typosquatted versions on npm, and compromised 147 developer workstations via dependency confusion. The tension between transparency (EO 14028 mandates SBOMs) and security (SBOMs are attack intelligence) requires careful architectural decisions. Best practices: share SBOMs with customers via authenticated portals (not public URLs), redact or hash internal-only package names, reserve all internal package names on public registries preemptively, and implement SBOM distribution via CSAF trusted provider framework.

10. What is the SBOM maturity model, and what distinguishes a Level 1 organization from a Level 5 organization?

  • A) Maturity levels only measure SBOM format compliance
  • B) Level 1 (Ad Hoc): SBOMs generated manually on request, no automation, no policy, used only for compliance checkbox. Level 5 (Optimized): SBOMs generated automatically for every build in CI/CD, real-time vulnerability correlation with NVD/EPSS, automated VEX generation, SBOM diff monitoring between releases, license compliance gates in pipeline, SBOM distribution via CSAF trusted provider, full supply chain graph visibility across all products, and SBOM data feeding into risk quantification models — the difference is that Level 1 answers "what's in our software?" reactively while Level 5 answers "what changed, is it vulnerable, is it exploitable, and what's the business risk?" automatically and continuously
  • C) All organizations start at Level 3
  • D) Level 5 requires commercial SBOM tools; open-source tools can only reach Level 3
Answer

B — Level 1 is reactive manual compliance; Level 5 is automated continuous supply chain intelligence

The maturity progression: Level 1 (Ad Hoc) → Level 2 (Managed: automated generation, basic vulnerability scanning) → Level 3 (Defined: CI/CD integration, license gating, VEX consumption) → Level 4 (Measured: SBOM diff monitoring, supply chain risk scoring, vendor SBOM requirements) → Level 5 (Optimized: full automation, predictive risk, cross-product dependency graph, SBOM-driven procurement decisions). Each level builds on the previous. Open-source tools (Syft, Trivy, Grype, cdxgen) can achieve Level 4+; commercial tools add enterprise features like multi-product dashboards and vendor management but are not required for technical maturity.

11. What is Sigstore/Cosign, and how does it provide supply chain integrity for container images and SBOMs?

  • A) Sigstore is a vulnerability scanner
  • B) Sigstore is a suite of open-source tools for software supply chain integrity — Cosign signs container images and artifacts (including SBOMs) with cryptographic signatures, Rekor provides a tamper-evident transparency log recording all signing events, and Fulcio issues short-lived certificates tied to OIDC identities (GitHub, Google) — this enables verifiable provenance: consumers can cryptographically verify that an image was built by a specific CI pipeline, signed by a specific identity, and the attached SBOM was generated at build time and hasn't been tampered with
  • C) Sigstore only works with Docker Hub
  • D) Cosign requires managing long-lived signing keys
Answer

B — Sigstore provides cryptographic signing, transparency logging, and identity-based attestation for supply chain artifacts

The keyless signing model is revolutionary: instead of managing PGP keys or certificates, Cosign uses Fulcio to issue ephemeral certificates tied to the developer's OIDC identity (e.g., their GitHub account). The signing event is recorded in Rekor (an immutable append-only log). This means: (1) the SBOM attached to a container image is cryptographically bound to it, (2) any modification to the SBOM after signing is detectable, (3) the signing identity is verifiable ("this was signed by the GitHub Actions workflow in repo X"), (4) the transparency log provides a public audit trail. cosign verify-attestation in the deployment pipeline ensures only properly signed images with valid SBOMs are deployed.

12. A developer adds a new npm package to the project. The SBOM diff between the current and previous build reveals 47 new transitive dependencies. What should the SCA pipeline do?

  • A) Automatically approve — developers choose their own dependencies
  • B) Flag for security review: (1) scan all 47 new transitive dependencies for known vulnerabilities, (2) check licenses of all 47 against the approved license list, (3) verify package provenance (maintainer history, download counts, age of package), (4) check for typosquatting indicators (name similarity to popular packages, recent creation date, single maintainer), (5) compare against known malicious package databases (Socket.dev, Phylum, Snyk), (6) if all checks pass, approve with a note in the PR — if any flag triggers, block merge until human review
  • C) Block the merge — 47 new dependencies is always excessive
  • D) Only check the direct dependency, not the transitive ones
Answer

B — Flag for security review with automated checks for vulnerabilities, licenses, provenance, and typosquatting

47 new transitive dependencies from a single direct dependency is common in the npm ecosystem (adding react pulls in 30+ transitive deps). The number alone isn't the concern — the QUALITY and SAFETY of those dependencies is. Automated checks should evaluate: vulnerability status (are any already in NVD/CISA KEV?), license compatibility (any copyleft in a proprietary project?), maintainer reputation (new maintainer took over 2 days ago?), naming (does lod-ash look like a typosquat of lodash?), and behavior (does the postinstall script make network calls?). Tools like Socket.dev provide real-time analysis of package behavior, complementing traditional SCA vulnerability scanning.

13. How does SBOM diff monitoring between releases improve supply chain security posture?

  • A) SBOM diffs only show version number changes
  • B) SBOM diff monitoring compares the component inventory between consecutive releases and alerts on: new components added (potential supply chain expansion), components removed (potential feature regression), version changes (upgrades that may introduce new vulnerabilities OR fix existing ones), license changes (a previously MIT-licensed dependency switching to AGPL), maintainer changes (detected via package metadata — a new maintainer could indicate a takeover), and hash changes without version bumps (potential tampering) — this provides continuous assurance that the software supply chain hasn't been manipulated between releases
  • C) SBOM diffs only work with CycloneDX format
  • D) Weekly SBOM diffing is sufficient for security monitoring
Answer

B — SBOM diff monitoring detects supply chain changes between releases across multiple dimensions

The most dangerous supply chain attacks involve subtle changes: a legitimate package is taken over by a new maintainer who injects malicious code in a minor version bump. Without SBOM diff monitoring, this change is invisible — the CI/CD pipeline still passes because the vulnerability hasn't been reported to NVD yet. SBOM diffing catches it: "component X changed from version 2.3.1 to 2.3.2 with a new maintainer and a modified postinstall script." This is a behavioral signal, not a vulnerability signal — and it's exactly the kind of change that traditional SCA misses. Diffing should run on every build, not weekly, because attackers time their attacks between scan windows.

14. What detection query would identify potential dependency confusion attacks in your environment?

  • A) Monitor npm audit output only
  • B) Monitor DNS and network traffic from developer workstations for indicators of malicious postinstall scripts: unusual DNS TXT queries with base64-encoded subdomains (data exfiltration), outbound HTTP/S connections to unfamiliar domains from node/python processes during package installation, unexpected child processes spawned by npm/pip/gem during install, and file access to sensitive paths (~/.ssh/, ~/.aws/, .env files) by package manager child processes — additionally, monitor the package registry for resolution mismatches: packages resolved from the public registry that match internal naming patterns
  • C) Check package.json for typos manually
  • D) Only scan production servers, not developer workstations
Answer

B — Monitor DNS, network, process, and file access patterns during package installation

Dependency confusion attacks execute during npm install (via postinstall scripts), not during runtime. Detection must focus on the BUILD environment and developer workstations: (1) DNS exfiltration — base64-encoded TXT queries to unknown domains from node.exe are a strong signal, (2) network — outbound connections from package manager child processes to external IPs, (3) process tree — npm install spawning curl, wget, or reverse shell processes, (4) file access — package install scripts reading SSH keys, .env files, or git credentials. SC-108 demonstrates all of these detection patterns with KQL and SPL queries.

15. Your organization is starting an SBOM program from scratch. Design the first 90 days.

  • A) Start by purchasing an enterprise SBOM platform
  • B) Days 1-30: Inventory and tooling — select SBOM format (CycloneDX for security focus), deploy generation tools (Syft for containers, cdxgen for applications) in ONE pilot CI/CD pipeline, generate first SBOMs, validate accuracy against manual dependency audit. Days 31-60: Vulnerability correlation — integrate Grype or Trivy for SBOM-based vulnerability scanning, configure severity-based CI/CD gating (block Critical + High EPSS), establish exception workflow, begin consuming vendor VEX feeds. Days 61-90: Operationalize — expand SBOM generation to all pipelines, implement license compliance scanning, begin SBOM diff monitoring between releases, reserve internal package names on public registries, create SBOM policy document, brief leadership on supply chain visibility improvements with metrics
  • C) Focus exclusively on license compliance for the first 90 days
  • D) Generate SBOMs for all products simultaneously from day 1
Answer

B — Phased 90-day rollout: pilot → vulnerability correlation → operationalize

The pilot-first approach is critical: starting with one pipeline builds expertise, reveals integration issues, and produces quick wins to demonstrate value. Common mistakes: (1) generating SBOMs for everything at once (creates overwhelming noise without processes to handle it), (2) focusing only on license compliance (misses the security value proposition), (3) skipping the exception workflow (developers will bypass broken CI/CD gates). The 90-day plan produces measurable outcomes: "we can now answer 'are we affected by CVE-X?' in 5 minutes instead of 3 days" — this is the metric that justifies expanding the program.

Scoring Guide

Score Assessment Recommended Action
13-15 (87-100%) Excellent — Strong mastery of SBOM operations Proceed to advanced supply chain scenarios (SC-108)
10-12 (67-86%) Good — Solid understanding with some gaps Review SBOM format comparison, VEX integration, and dependency confusion
7-9 (47-66%) Developing — Key concepts need reinforcement Re-read Chapter 54 sections 54.2, 54.4, 54.7, 54.10
Below 7 (<47%) Needs Review — Revisit prerequisites Review Chapter 24 then re-read Chapter 54

Study Recommendations