SCA software: what it checks, the main tools, and how to act on the results
Short answer
SCA software (software composition analysis) lists every open-source and third-party package your application uses, including the packages those packages pull in, and checks each one against databases of known vulnerabilities and licence terms. It tells you which components carry a known security flaw, which version fixes it, and which licences could create legal obligations.
This page explains what SCA checks and how it works, how it differs from SAST and DAST, the main commercial and open-source SCA tools, and the part most vendor pages skip: turning a long scan report into a short list of fixes. We run SCA on client projects ourselves, so the comparison is written from the user's side of these tools.
What SCA software checks
Most modern applications are built largely from open-source packages. Your team writes the business logic; frameworks, parsers, HTTP clients, date libraries and hundreds of smaller packages do the rest. SCA looks at that borrowed part. A good tool covers five things.
- An inventory of components. Every package and version in the build, usually exported as an SBOM (software bill of materials) in a standard format such as CycloneDX or SPDX.
- Known vulnerabilities. Each component is matched against public databases such as the National Vulnerability Database, the OSV database and the GitHub Advisory Database, with a severity score and the first version that fixes the flaw.
- Transitive dependencies. The packages your packages depend on. This is where most findings come from, because nobody on your team chose them directly.
- Licences. Which licence each component carries and whether any conflict with how you ship your product, for example a copyleft licence in software you distribute.
- Package health. Components that are abandoned, years out of date, or look like a lookalike of a popular package, which is a common way malicious code gets into a build.
How an SCA scan works, step by step
- Read the manifests and lockfiles. package-lock.json or yarn.lock for JavaScript, requirements.txt or poetry.lock for Python, pom.xml for Java, go.sum for Go, and so on. The lockfile matters: it records the exact versions that were installed, while the manifest often only records a range.
- Look inside built artefacts. Better tools also scan container images and compiled binaries, because what ships is not always what the manifest says.
- Build the inventory. Direct and transitive packages, with versions, written out as an SBOM.
- Match against vulnerability and licence data. Each package and version is checked against the databases above.
- Report. A list of findings with severity, the affected package, the path that pulls it in, and the version that fixes it.
Step 1 has a practical consequence. SCA needs the source repository, or at least the lockfiles and images, so it cannot be done from outside the product. When we start with a new client, we test the running application from outside first, and add SCA and static code analysis once the NDA is signed and repository access is granted.
SCA vs SAST vs DAST
The three are complementary. Each one looks at a part of the risk the others cannot see.
| SCA | SAST | DAST | |
|---|---|---|---|
| Looks at | Third-party and open-source packages | Your own source code | The running application |
| Finds | Known vulnerabilities and licence issues in components | Coding flaws such as injection or unsafe data handling | Problems an attacker can reach from outside |
| Needs | Repository, lockfiles or images | Repository | A URL and test accounts |
| Misses | Flaws in your own code | Configuration and runtime issues | Code paths it cannot reach |
| Best run | On every build and on a schedule | On every pull request | Before releases and on a schedule |
SCA also needs a schedule, not only a build trigger. New vulnerabilities are published every day for packages you shipped months ago, so a component that was clean at release can be flagged next week without any change on your side. Our guide to DAST vs SAST covers the other two in more depth.
The main SCA tools
The tools below are the ones buyers most often compare. The descriptions summarise what each is generally chosen for.
| Tool | Type | Usually chosen for |
|---|---|---|
| Snyk Open Source | Commercial, free tier | Developer workflow: scans in the IDE, pull requests and CI, with fix suggestions |
| Black Duck | Commercial | Large organisations with strict licence and governance requirements |
| Mend | Commercial | Automated dependency updates and remediation at scale |
| Sonatype | Commercial | Controlling which components may enter the build at all |
| FOSSA | Commercial | Licence compliance and open-source policy |
| GitHub Dependabot | Free on GitHub | Alerts and update pull requests for repositories hosted on GitHub |
| OWASP Dependency-Check and Dependency-Track | Free, open source | A no-cost scanner, and a platform that tracks SBOMs across many projects |
| Trivy | Free, open source | Scanning source, container images and file systems with one tool |
| Syft and Grype | Free, open source | Syft builds the SBOM; Grype checks it for vulnerabilities |
| OSV-Scanner, npm audit, pip-audit | Free, open source | Fast checks for a single ecosystem or against the OSV database |
For most teams the honest answer is that the tool matters less than what happens after the scan. A free scanner whose findings get triaged every week protects you better than an enterprise licence whose dashboard nobody opens.
Why the scan is the easy part
The first SCA report on an established codebase is usually long, and most teams react in one of two ways: try to fix everything, or decide the tool is noisy and stop reading it. Both waste the scan. What works is triage, finding by finding:
- Is the vulnerable code reachable? A critical flaw in a function your application never calls is a lower priority than a medium one in your login path. Some tools check reachability automatically; otherwise an engineer has to look.
- Does it ship? Packages used only by the test suite or the build tooling carry less risk than packages that run in production.
- Is there a fixed version, and what breaks if you upgrade? A patch release is usually safe; a major version jump needs testing like any other change.
- Is it exploitable from where your users are? A flaw that needs local access matters less on a public web service than one reachable over the network.
- Is the licence finding real? Licence results often need a person to check how the component is actually used and distributed.
The output should be a short, ranked list with an owner and a date for each item, filed in the tracker your developers already use. Everything else is recorded as accepted or deferred, with a reason, so the next scan does not raise the same questions again.
How BetterQA runs SCA
SCA is one part of our Security Toolkit, which runs 15 open-source scanners plus 20 checks we wrote, correlated in one pass. For dependencies it uses Trivy to scan source and container images, Syft to produce the SBOM, and pip-audit for Python projects. The same run includes static analysis of your own code and, when we have a test environment, dynamic testing of the running application, so a vulnerable package can be judged together with whether your code actually exposes it.
A security engineer then reviews every finding before it reaches you. You get the ranked list described above, the SBOM, and the reasoning behind each accepted risk, delivered in your own Jira or Azure DevOps. If you only need a one-off assessment before a release or an audit, that is a common way to start; if you want it on every build, we set it up in your CI.
See our security testing service for the full scope, including penetration testing.
Frequently asked questions
Want your dependencies checked by people, not only a scanner?
We run SCA together with static and dynamic testing, review every finding, and hand you a short, ranked list in your own tracker, plus the SBOM.
Book a call Security testing serviceNeed help with software testing?
BetterQA provides independent QA services across manual testing, automation, security audits, and performance testing. ISO 27001, 9001, 14001 and 13485 certified.