Generate an SBOM and answer the question it exists for

short · 50 min · Objective 2.4

Task

Produce a software bill of materials for an application, then answer the only question that matters on the morning of a major disclosure: are we affected, and where. Then find the limits of your own SBOM.

Steps

  1. Take a small application with a dependency manifest -- any language with a lock file will do -- and install its dependencies.
  2. Count the direct dependencies from the manifest. Then count the total resolved packages from the lock file. Write both numbers down; the ratio is usually startling and is the point of the first section of the lesson.
  3. Generate an SBOM in a standard format and confirm it lists the resolved set rather than only the direct one.
  4. Simulate the disclosure. Pick one transitive dependency at random and answer, from the SBOM alone and timed: do we use it, at what version, in which applications, and is that version in the affected range?
  5. Now find the limits. Add a vendored library by copying source into the tree, and a statically linked binary. Regenerate the SBOM and check whether either appears.
  6. Finally, ask the reachability question for one finding: is the vulnerable function actually called from your code, or is the package present and unused?

Verify

jq '.components | length' /tmp/sbom.json
jq -r '.components[].name' /tmp/sbom.json | sort -u | wc -l
jq -r '.components[].name' /tmp/sbom.json | grep -c "the-vendored-library"
grep -rc "the-vendored-library" ./vendor/ | head -1

The component count against your manifest's direct count is the transitive multiplier. The last two are the limit: the vendored library is present in the source tree and absent from the SBOM, so a query that answers "are we affected" correctly for packaged dependencies answers it wrongly for this one -- silently, and in the direction of false reassurance.

Notes

Time step 4. The difference between an organisation that answers in an hour and one that takes a week is entirely this artefact, and it is a preparation decision made long before the disclosure.

The vendored-library gap is why an SBOM is a strong tool and not a complete one. Record it as a known limitation rather than discovering it during an incident.

This is an independent study companion for CompTIA CySA+ CS0-004 and is not produced by or endorsed by CompTIA.