Permits-portal CI must record which components shipped in each build for later vulnerability response. What should the pipeline generate?
Select an answer to reveal the explanation.
Short Explanation
An SBOM is the packing list for the software crate—when a library goes bad, you know which builds carried it. Passwords in logs or IDE screenshots are not that inventory.
Full Explanation
Permits-portal CI must record which components shipped in each build for later vulnerability response by generating a software bill of materials (SBOM) for each build. An SBOM inventories libraries, packages, and versions included in the artifact so that when a CVE drops, responders can query which permits-portal builds are affected. Emitting SBOMs in the pipeline makes that inventory routine rather than forensic guesswork after an incident.
A plaintext copy of all production database passwords in the job log fails by concept: that is a secret leak, not a component inventory. A single undocumented zip with no component inventory fails because the archive does not tell you what libraries shipped. A screenshot of the IDE with no machine-readable dependency list fails automation and searchability for vulnerability response.
Exam caveat: SBOM formats (SPDX, CycloneDX, etc.) may vary; exams care that CI generates a usable component bill of materials, not that you memorize one schema. SBOMs complement but do not replace patching and registry controls.
Operational check: add an SBOM generation step to the permits-portal pipeline, store SBOMs alongside artifacts, index them for CVE queries, forbid password logging, and rehearse a vulnerability drill that identifies affected builds from the SBOM within a defined municipal SLA.