SCA scanning

What happens in an SCA scan

1. Read the target. The scanner reads manifests and lockfiles such as package-lock.json, poetry.lock or Cargo.lock, or unpacks a container image.
2. Build the component list. It resolves what it found into names and versions, usually including transitive dependencies.
3. Match the data. Each component is looked up in sources such as the GitHub Advisory Database, OSV and the NVD, and its license is compared with your policy.
4. Report. Findings come out ranked by severity, usually with a fixed version. In CI, a policy can fail the job.

For the wider practice this belongs to, see what is software composition analysis.

Where to run SCA scans

One scan in one place leaves gaps. Each stage answers a different question, so most teams run more than one.

Where	What it answers	What it misses
Developer machine or IDE	Is this package safe to add?	Anything the developer does not run it on
Pull request	Does this change add a known risk?	New advisories for code that did not change
CI build	What does the release contain?	Whatever the scanner cannot see in the build
Container registry	What is in this image?	Compiled code and build tools that leave no trace
After release	Is what we shipped affected by something new?	Nothing, if the record of what shipped is complete

The last row is the one most programs skip. A new advisory affects a version you shipped months ago, and no pull request will trigger a scan for it.

How to read SCA scan results

A first scan of a real project often returns hundreds of findings. Work through them in this order:

1. Start with what is being exploited. A finding in CISA's KEV catalog beats a higher CVSS score with no known exploitation. See how to prioritize vulnerabilities.
2. Check that it applies. Dev-only dependencies do not ship. Some tools add reachability analysis to check whether the vulnerable code can be called at all.
3. Fix at the right level. For a transitive finding, the fix is usually in the package that pulls it in, which a dependency graph shows.
4. Record what you will not fix. A finding you decided to accept should say why, or the next person repeats the work. VEX is the standard way to record it.

Why a clean scan does not mean clean software

• It sees what is declared. A scanner reads the files in front of it, so a repository that commits no lockfile gives it little to work with, and code fetched by an install hook never appears.
• It sees what you pointed it at. The base image, build tools and GitHub Actions in your pipeline are separate from your application's manifest.
• It only knows what is published. A new malicious package has no advisory yet.
• The list is not the build. Builds resolve versions when they run, so what the scan read and what the release contains can differ.

These are limits of scanning itself, commercial or open source. CRACI has found vulnerable packages that Snyk and Aikido did not report, because the components were never in what they scanned.

Free and commercial scanners

Free options cover the basics well. Dependabot alerts come with GitHub, OWASP Dependency-Check and Trivy are open source, and Grype pairs with the Syft SBOM generator. Commercial tools add policy, prioritization, reachability and workflow across many teams. The best SCA tools compared covers 13 of them, and this guide shows why free generators disagree with each other.

SCA scanning and build-time recording

CRACI is not a scanner, and you do not have to give up yours. It is a GitHub Actions runner that records every package each job fetches, at every depth of the tree and including packages restored from CI caches, then keeps re-evaluating the SBOMs of what shipped as new vulnerabilities are published. Your scanner covers pull requests and developer machines. CRACI covers the build and everything after it. See where CRACI fits next to your SCA tools.

SCA scanning: frequently asked questions

What is an SCA scan?

An SCA scan reads a project's manifests, lockfiles or container image, works out which open source components it uses, and checks them against vulnerability and license data.

Is SCA the same as dependency scanning?

Nearly. Dependency scanning usually means checking dependencies for known vulnerabilities. SCA is the broader term and also covers licenses, outdated packages and producing an inventory such as an SBOM.

When should SCA scans run?

On pull requests, to stop new risks entering; in the CI build, to describe the release; and continuously after release, because new advisories affect software you already shipped.

How long does an SCA scan take?

Usually seconds to a few minutes, because it reads metadata rather than analyzing all of your code. That makes it practical to run on every pull request.

Why do SCA scanners report different results?

Each has its own rules for what to read, how to name components and which vulnerability data to use. The same commit can produce different component lists and different findings.

Does SCA scanning find malware?

Advisory matching finds malicious releases only once an advisory exists. Tools that analyze how packages behave can catch some sooner. A new malicious package has no advisory on the day it appears.