SCA and Open-Source Risk
What this domain tests
How CxSCA identifies open-source risk, what its scores mean, and how to remediate a dependency problem without breaking the build - plus how SCA evidence complements SAST evidence.
What SCA analyzes
SCA works from dependency evidence: manifest and lock files (npm, Maven, Gradle, NuGet, pip and similar) and, where source is unavailable, binary artifacts. It resolves the dependency tree, including transitive dependencies, matches components against vulnerability data (CVE/NVD-based), and adds license risk. Because it analyzes packages rather than code, SCA cannot see whether vulnerable code is actually reachable - that is where SAST correlation helps.
Reading the risk
Risk combines the vulnerability's severity (CVSS-style), exploitability, whether a fix exists, and the dependency's position in the tree. Best Fix Location identifies the dependency you should upgrade to remove the most risk with the least change - frequently a parent library rather than the vulnerable leaf. License findings are separate from security findings and follow policy, not CVSS.
Remediation
Upgrade the direct dependency, override the version of a transitive one where the build tool allows, or remove the package if it is unused. Prefer the smallest safe upgrade; then re-scan to confirm the vulnerable version is gone from the resolved tree. Where SAST and SCA are correlated, an "exploitable path" tells you that application code actually calls the vulnerable library function, which should outrank a package that is present but unreachable.
Worked example
A high-severity CVE appears in log4j-core, pulled in transitively through a logging starter. You cannot upgrade log4j-core directly because it is not a declared dependency, so the fix location is the starter (or a version override in the build file). Reasoning: upgrading the starter resolves the tree; adding a direct dependency on a patched log4j-core also works but must be checked against the starter's expected version range. Then confirm the dependency report no longer lists the vulnerable version.
Traps that cost marks
- Reporting a transitive finding as unfixable; the fix belongs one level up.
- Counting test/dev-scope dependencies as production risk without checking scope.
- Treating a high CVSS score as automatically exploitable in your application.
- Scanning without a lock file and trusting an approximate resolved tree.
- Confusing license findings with security findings in reports.