Learn the vocabulary of scanning a project's dependency tree for a known vulnerability.
0 / 5 completed
1 / 5
At standup, a dev mentions scanning the project's full dependency tree to identify every open-source library in use and flag one with a known published vulnerability. What is this practice called?
Software composition analysis, or SCA, scans a project's full dependency tree to identify every open-source library actually in use, including an indirect, transitive dependency, and flags one with a known published vulnerability. Manually reading every dependency's source code doesn't scale to a modern project's often deep and wide dependency tree. Automated SCA scanning is what makes it practical to keep track of vulnerability exposure across a large, evolving set of third-party code.
2 / 5
During a design review, the team wants the scan to flag a vulnerability specifically in a transitive dependency, one pulled in indirectly by a direct dependency, not just in a package listed directly in the project's manifest. Which capability supports this?
Full dependency tree resolution scans every transitive dependency, one pulled in indirectly through a direct dependency, not just the packages a project's manifest lists directly. Scanning only the directly listed packages misses a vulnerability buried several layers deep, which is often where a real-world exposure actually lives. This full-tree resolution is essential since most of a modern project's total dependency count typically comes from transitive dependencies, not direct ones.
3 / 5
In a code review, a dev notices the scan report includes each flagged vulnerability's known exploitability and whether the vulnerable code path is actually reachable from the application's own code. What does this represent?
Reachability analysis checks whether the vulnerable code path in a flagged dependency is actually reachable from the application's own code, helping the team prioritize a genuinely exploitable vulnerability over one that exists in a library but is never actually exercised in this specific project. Treating every flagged vulnerability as equally urgent wastes limited remediation effort on a low-risk finding. This prioritization is what makes SCA's often large volume of findings actually actionable.
4 / 5
An incident report shows a known-vulnerable transitive dependency sat unpatched in production for months because the SCA scan only ran manually, and no one had triggered it since the last release. What practice would prevent this?
Running the SCA scan automatically on a recurring schedule and on every dependency change catches a newly disclosed vulnerability in an existing dependency, since a vulnerability can be published well after that dependency was first added. Relying on a scan that only runs when manually triggered leaves a long gap where a new vulnerability goes completely unnoticed. This automated, recurring scanning is what keeps a project's vulnerability picture actually current rather than a stale snapshot from its last release.
5 / 5
During a PR review, a teammate asks why the team runs automated SCA scans instead of just trusting that a well-known open-source library is safe to use without checking. What is the reasoning?
A well-known library can still have a new vulnerability disclosed at any time after a project first adopted it, and that exposure can also hide several layers deep in a transitive dependency no one is directly watching. An automated scan catches this across the full dependency tree on an ongoing basis. The tradeoff is the need to triage a real volume of findings, prioritizing an actually reachable, exploitable vulnerability over a low-risk one.