Small teams need SCA to be cheap in attention. Scan on every pull request, keep lockfiles committed, fix known exploited issues first, and ignore the rest until you have time. Here are ten short answers to the questions that come up most.
What is SCA?
Software composition analysis finds the open source packages in your code, including indirect ones, and checks them against known vulnerabilities and licenses.
What should I scan?
Every repository that ships to production, plus any that build container images. Start with the ones that are internet facing.
Do I need a lockfile?
Yes, and commit it. The npm documentation describes the lockfile as the exact tree generated, and says it is meant to be committed. Without one, the scan and your build may resolve different versions.
When should the scan run?
On each pull request, and on a schedule against what is already deployed. New advisories arrive after you ship.
What do I fix first?
Start with anything on CISA's Known Exploited Vulnerabilities catalog that is deployed and exposed. Then look at findings with a high exploit probability. See EPSS, KEV, and CVSS.
How do I cut noise?
Use reachability where available, and filter to new findings on pull requests. Do not fail builds on old issues.
Do I need an SBOM?
If a customer asks, yes. It is also handy internally. Generate it in CI. See SBOM generator vs SCA scanner.
How much time should this take?
Aim for under an hour a week once set up. If it takes more, your thresholds are too loose or your tool is too noisy.
Should I auto merge dependency updates?
Be careful. Automatic updates are useful for patch versions with good test coverage. Keep a human on major version changes.
What can I skip?
Skip complex scoring models, a dozen dashboards, and policy for situations you do not yet have. Start with: scan on pull requests, fix known exploited issues, rescan weekly.
Where to start today
Run one scan on your most important repository, read the top ten findings, and fix the one that is both reachable and on the exploited list, if any.
Safeguard offers a free scan at https://gold.safeguard.sh/scan, and its dependency scanning includes reachability analysis.
A one week starter plan
On day one, run a scan on your most important repository. On day two, confirm lockfiles are committed. On day three, add a scan to pull requests that reports only new findings. On day four, decide who triages. On day five, fix one reachable finding and note how long it took. After that week you have a working loop, and you can improve each part when it actually hurts, not before.
Quick check
Is a free tool good enough to start?
Yes for a baseline. Switch when triage or reporting time becomes the bottleneck. See open source or commercial SCA.
Sources
Last reviewed: 19 October 2026.
