The city library catalog release must keep an inventory of shipped components with each versioned artifact. What practice meets that need?

Retaining a software bill of materials (SBOM) with each versioned release artifact preserves a durable, machine-readable inventory of shipped components for vulnerability response, license review, and audit. City library catalog releases should attach and keep that SBOM alongside the versioned artifact so operators can answer which library release carried a vulnerable dependency without reconstructing the build from memory. The correct practice works because catalog software is a composition of transitive packages; when a CVE lands against a library the city ships, the SBOM is the packing list that maps artifact version to component versions quickly enough for municipal patch SLAs.

Discarding all dependency lists after the build to save registry space fails because storage savings are trivial next to the cost of blind incident response—without retained inventories you cannot prove what shipped. Publishing only a marketing PDF with no machine-readable component inventory fails conceptually: PDFs are not queryable by vulnerability tooling and omit the structured package identifiers scanners and auditors expect. Storing production database dumps next to the release instead of component metadata fails because database contents are operational data, not a software component inventory, and they introduce privacy and retention risk unrelated to SBOM goals.

Exam caveat: an SBOM is only as trustworthy as the build that produced it—generate it in CI from the resolved dependency graph for that artifact, and sign or checksum it with the release. Operational check: for a catalog release, confirm the registry or artifact store holds both the versioned package and its SBOM, run a sample CVE lookup against the SBOM, and verify retention policy keeps SBOMs for as long as the corresponding release remains supported in the library environment.