To run your first software composition analysis (SCA) scan, pick one project, make sure its dependency files are in the folder, run a scanner on it, and read the list of packages with known flaws. Then fix the few that matter most. You can finish a first pass in under an hour.
TL;DR
- SCA looks at the open source packages your app uses and checks them against lists of known security problems.
- Start with one project, not your whole company.
- A first report is usually long. That is normal. Sort it, do not panic.
- Fix by upgrading to a patched version, one small batch at a time.
- Scan again after each batch, and keep scanning on a schedule.
What is SCA, in plain words?
Definition: Software composition analysis (SCA) is the practice of listing the open source packages inside your software and checking each one against databases of known vulnerabilities. A vulnerability is a flaw that an attacker could use to cause harm.
Think of the label on a food package. The label lists ingredients. If a supplier later announces that one ingredient was contaminated, you can check the label and know whether your product is affected. SCA reads the "ingredient list" of your app and compares it to the public recall notices.
Your app probably has far more ingredients than you chose yourself. When you add one package, it often brings along others it needs. Those are called dependencies, and the ones brought in indirectly are called transitive dependencies. If these terms are new, the posts on what a dependency is and on direct versus transitive dependencies explain them. For the formal definition, see define SCA.
The reason this matters is simple. The OWASP Top 10, a widely used list of web application risks, says you are likely vulnerable if you do not know the versions of all components you use, including nested dependencies. It also says you are at risk if you do not scan for vulnerabilities regularly. SCA is the tool for both jobs.
What do I need before I start?
You need very little. Gather these four things.
| What | Why it helps | Example |
|---|---|---|
| One project to scan | Keeps the first run small and easy to read | Your main web app |
| The dependency files | They list what the project uses | A manifest file and a lockfile |
| Read access to the folder | The scanner has to see those files | Your own laptop checkout |
| A rough owner for the project | Someone has to act on the results | The tech lead of that app |
A manifest is a file where you list the packages you want. A lockfile is a file that records the exact versions that were actually installed. The lockfile matters because it shows the full tree, including the indirect packages. The npm documentation describes its lockfile as describing the exact tree that was generated, so later installs get identical trees. It also says npm needs a lockfile or shrinkwrap file to run its audit command by default. Without one, the results may differ every run because the tree gets rebuilt each time.
If you want to go deeper on lockfiles, see best practices for npm lockfile security.
How do I run the scan? A numbered walkthrough
Here is a simple path that works for most teams.
- Choose the project. Pick one app that real customers use. Do not pick a toy project, because you will learn less.
- Check the files are present. Open the project folder and confirm you can see the manifest and the lockfile. If the lockfile is missing, generate it with your package manager first.
- Run a scanner. If your project uses npm, the simplest built-in check is below. The npm docs say this command sends a description of your dependencies to your registry and asks for a report of known vulnerabilities.
- Save the output. Copy the report to a file. You will compare against it later.
- Count and sort. Count findings by severity (critical, high, medium, low). Then sort within each group by whether a fixed version exists.
- Pick a first batch. Choose the findings that have a fix and sit in packages your app actually runs in production.
- Upgrade and test. Change the versions, run your tests, and ship the change like any other.
- Scan again. The count should drop. If it did not, read the next section.
npm audit
The same npm page notes that by default the command exits with a failure code if any vulnerability is found. In automated builds you can set a minimum level, which changes only the failure threshold and does not filter the report. That is handy later. For your very first run, just read the whole report.
If your project is not in the npm world, other package managers have their own checks, and there are standalone tools. The OSV project, for example, describes itself as an aggregator of vulnerability databases and offers a first-party scanner called OSV-Scanner. You can read more in what is OSV.
How do I read the results without getting overwhelmed?
A first report often has dozens or hundreds of rows. Do not try to fix all of them in one sitting. Look at four columns.
| Column | What it tells you | What to do with it |
|---|---|---|
| Package and version | What you run today | Confirm it is really in your app |
| Severity | How bad the flaw can be in general | Use it to sort, not to decide alone |
| Fixed version | The first version with the repair | If present, you have an easy path |
| Path | Which package pulled this one in | Tells you what to upgrade |
Severity scores come from a scoring system called CVSS. They describe how serious a flaw is in general, not how risky it is for your app. The post on CVSS, EPSS and KEV explains the difference. The Cybersecurity and Infrastructure Security Agency (CISA) keeps a public catalog of vulnerabilities known to be exploited in the wild, and says organizations should use it as an input to their prioritization. A flaw on that list deserves a closer look even if its score looks middling.
Also remember that a package can be present but never used by your code. Whether the vulnerable part can actually run is a separate question called reachability. See the reachability analysis FAQ for that.
A worked example with invented numbers
The numbers below are made up to show the method. They are not from a real project.
Imagine a small web app. Your first scan reports 60 findings.
- 4 critical, 12 high, 30 medium, 14 low.
- 41 of the 60 have a fixed version.
- 9 of the 60 are in packages used only for testing, not in the shipped app.
Here is a sensible plan.
- Set aside the 9 test only findings for later. They are real, but they do not run in production.
- Among the remaining 51, keep the ones with a fixed version. Say that leaves 34.
- Take the critical and high ones first. Say 11 of the 34 are critical or high.
- Upgrade those 11 in one or two small pull requests. Run your tests.
- Scan again. If your list drops from 60 to about 45, you removed a real chunk of risk in an afternoon.
You did not reach zero, and you do not need to. You made a ranked list, fixed the top of it, and wrote down what is left. That is a healthy first scan.
What usually goes wrong on a first scan?
- The lockfile is missing. The scanner then guesses, and results change between runs.
- You scanned only direct packages. Most of the risk hides in indirect ones.
- You tried to fix everything at once. Big batches break things and teams stop trusting the process.
- No one owns the results. A report with no owner gets ignored.
- You scanned once and stopped. New flaws are published every day, so a clean report today can have new findings next week.
On the last point: the OWASP guidance says organizations need an ongoing plan for monitoring, triaging, and applying updates for the lifetime of the application. A first scan is the start of that plan, not the end.
Try it yourself
The demo below walks through a dependency inventory in a sample workspace. Click through the steps and watch how direct and indirect components are listed in one place, because that list is what every scan builds on.
Click through it at your own pace, or open it full screen.
Quick check
Do I need to share my source code to run an SCA scan?
Often not. SCA mainly reads the dependency files, such as the manifest and lockfile, not your own business logic. Some tools read only those files. Check how any tool you try handles access before you give it more than it needs.
How long should a first scan take?
The scan itself usually takes minutes. Reading the report and picking a first batch to fix is the longer part. Plan for under an hour of focused time for a first pass on one project.
Should I fix every finding the scan shows?
No. Sort by severity, whether a fix exists, and whether the package runs in production. Fix the top of the list first, record what you chose to leave, and revisit it on a schedule.
Is one clean scan proof that my app is safe?
No. A scan is a snapshot. New vulnerabilities are published all the time, and SCA only knows about flaws that have been reported. Rescan on a schedule and whenever dependencies change.
How can Safeguard help with this?
Safeguard offers SBOM and dependency scanning, which builds the component list described above and checks it against known vulnerabilities. Reachability analysis helps you see which findings sit in code that your app can actually call. If you want automatic fixes, Safeguard can open fix pull requests. That capability is off by default, and every category starts on Manual, so a person approves changes.
You can try a scan for free at gold.safeguard.sh/scan. The Safeguard CLI, version 1.4.0 at the time of writing, installs with a curl command on macOS and Linux and a PowerShell installer on Windows, per the download page. It can also write code, for example to draft a dependency upgrade that you then review like any other change.
Sources
- OWASP Top 10 2021, A06 Vulnerable and Outdated Components (source text on GitHub)
- npm Docs: npm audit
- npm Docs: package-lock.json
- OSV documentation
- CISA Known Exploited Vulnerabilities Catalog
- Safeguard download page
Last reviewed: 19 October 2026.
