A municipal fee calculator ships with dozens of open-source packages. Which control specifically finds known-vulnerable third-party components?
Select an answer to reveal the explanation.
Short Explanation
Your fee calculator might be mostly other people's code glued together. SCA is the ingredients check that spots known-bad libraries before they bill the wrong citizen—or worse. Open-source speed is fine; blind trust is not.
Full Explanation
Software composition analysis (SCA) inventories direct and transitive open-source dependencies and matches them to known vulnerability databases and sometimes license obligations. A municipal fee calculator that ships dozens of packages inherits risk from each component; SCA specifically surfaces known-vulnerable third-party libraries so the city can upgrade, replace, or accept risk with eyes open before billing logic reaches residents.
Load testing the home page with synthetic browsers measures performance and capacity, not whether a dependency has a published CVE. Performance green lights do not equal composition safety.
Redesigning the civic logo for accessibility contrast is a UX/accessibility task unrelated to detecting vulnerable packages.
Disabling HTTPS to simplify packet capture during demos weakens transport security and does nothing to identify bad libraries; it increases exposure while demos run.
Exam caveat: SCA targets third-party component risk; SAST targets first-party code patterns; DAST targets runtime behavior—keep the methods distinct on the exam. Operational check: generate SBOMs, fail CI on critical dependency CVEs for fee and payment-adjacent services, pin versions, monitor transitive graphs, and assign owners for upgrade SLAs on civic calculators and related apps.