SAST vs DAST vs SCA (and the SBOM)

Key: C

1. AStatic analysis reviews code or configuration without running the system, the opposite of what is suggested.
2. BFunctional testing checks that features work as specified, not that the running system is free of vulnerabilities.
3. CCorrect: Testing a system while it runs is dynamic analysis, which finds issues that only appear at runtime.
4. DPenetration testing attacks a running system too, but it's a broader, goal-driven exercise to exploit weaknesses, not the general type of runtime analysis described.

Key: C

1. AA weekly manual NVD check is slow, misses components you don't know you have and doesn't scale.
2. BVendor notifications are often late, and open-source components may have no vendor to tell you at all.
3. CCorrect: SCA automatically inventories third-party and open-source components, including transitive ones, and matches them to known vulnerabilities, which also feeds the SBOM.
4. DBanning all third-party components is unrealistic for modern software and would stop development.

Key: A

1. ACorrect: The Auth Service depends indirectly (through auth-kit) on token-parse 2.2.0, which has known exploits, so it carries hidden risk from a transitive dependency.
2. BThere is no Load Balancer in the SBOM excerpt, so there is no evidence of a vulnerable sub-component for it.
3. CThe Payment Gateway's transitive dependency (cookie-kit) shows no known exploits in the excerpt.
4. DThe Billing Service's transitive dependency (redirect-follow) shows no known exploits in the excerpt.

Key: D

1. AAuthFramework is a direct dependency with no CVE; it only pulls in the vulnerable code further down.
2. BSessionManager has no CVE itself; it's the link that brings in the vulnerable library.
3. CReportingModule and its PDFGenerator package show no CVE and sit on a separate branch of the tree.
4. DCorrect: CryptoLib-v1 is the transitive package that carries the CVE, so it's the root cause reaching WebPortalApp through AuthFramework → SessionManager.

Key: B

1. AHost scanners don't scan supplier code repositories at all, so privileges there aren't why they missed the flaw.
2. BCorrect: Host scanners mostly read installed package inventories and miss libraries bundled deep inside compiled code, so they effectively see only the top layer of dependencies; SCA and an SBOM expose the nested components.
3. CIgnoring scripting languages wouldn't explain missing a flaw embedded in a compiled microservice.
4. DHost-based vulnerability scanners check hosts for vulnerabilities; tracking CI server misconfigurations isn't what they focus on.

Key: B

1. AWaiting for a CVSS score leaves a declared weakness unaddressed, and many weaknesses never get a CVE before they are exploited.
2. BCorrect: CWE-79 means the component has a cross-site scripting weakness, so mitigate injection paths now (output encoding, input validation, CSP) without waiting for a CVE.
3. CNo CVE doesn't mean secure, and the SBOM explicitly declares an XSS weakness.
4. DAn SBOM lists components and their properties; it can't include exploitation timelines, which don't exist ahead of time.

Key: B

1. ARelying on penetration tests after deployment finds flaws late, when they cost the most to fix, and doesn't enforce anything in the pipeline.
2. BCorrect: Failing the build only on high and critical CWEs stops the serious flaws early, and peer review of security-relevant changes adds a check without blocking routine work.
3. CSAST only on release branches and weekly emails finds issues late and enforces nothing, so the same weaknesses keep returning.
4. DMaking security triage every CWE before any merge creates a bottleneck that kills developer velocity.