Examples in this article are illustrative, not customer case studies. Product availability and coverage are described on the linked capability pages.
SAST, SCA and secrets scanning inspect different parts of the same repository. SAST analyses the code your team wrote for flaws such as injection, SCA checks the open-source packages you depend on against known vulnerabilities and licences, and secrets scanning looks for credentials committed to code or history. You need all three, because each misses what the others find.
Teams buying their first application security tooling often ask which of the three to start with, as if they were alternatives. They are not. This post sets out what each technique inspects, what it reliably misses, where it belongs in the pipeline and who should own its findings.
The worked example is a single pull request to an order-tracking service. The change adds a search endpoint that builds a database query from a request parameter, bumps an HTTP client library to a version with a published advisory, and includes a test fixture with a real cloud access key that a developer pasted while debugging.
SAST finds flaws in the code you wrote
Static application security testing analyses first-party source code without running it. Modern SAST traces untrusted input from a source, such as a request parameter, through the program to a sensitive sink, such as a database query, and reports a finding when no sanitiser sits in between. That is how it catches the search endpoint’s injection, a weakness MITRE catalogues as CWE-89.
SAST coverage of dependencies varies by engine and available source, and it does not know which advisories have been published against them. It also works on code shape rather than secret values, so a pasted key in a fixture is invisible to it unless a rule happens to match. How taint tracking works, and where it struggles, is covered in SAST taint analysis explained.
SCA finds known risk in the code you imported
Software composition analysis identifies the open-source packages in your manifests, lockfiles and built artefacts, including transitive dependencies, and matches each against vulnerability advisories and licence data. It catches the HTTP client bump because the new version appears in a published advisory, which no amount of reading your own code would reveal. The OWASP Top 10 treats this class of supply-chain and vulnerable-component risk as a category of its own.
SCA knows nothing about how you call a library unless it adds reachability analysis. A vulnerable function you never invoke and one called from a public handler look the same in a plain SCA report. It also cannot judge your own code, so the injection in the search endpoint passes straight through. The relationship between SCA and the inventory it reads from is explained in SCA vs SBOM.
Secrets scanning finds credentials that should never be in code
Secrets scanning searches files and commit history for credentials: cloud access keys, API tokens, private keys and database connection strings, matched by known formats and entropy. It catches the pasted cloud key in the fixture, which is a hard-coded credential in MITRE’s terms (CWE-798) and potentially urgent because a valid key may be usable by someone who obtains it, subject to its permissions and restrictions.
Secrets scanning does not find logic flaws or vulnerable packages. Its distinctive problem is time: deleting the key in the next commit leaves it in history, and the only real fix is rotation, as set out in leaked secret response.
SAST vs SCA vs secrets scanning at a glance
| Aspect | SAST | SCA | Secrets scanning |
|---|---|---|---|
| Inspects | First-party source code | Third-party packages | Files and git history |
| Finds | Injection, unsafe APIs, logic flaws | Known CVEs, licence issues | Keys, tokens, passwords |
| Misses | Dependency advisories, secrets | Your own code’s flaws | Code and dependency flaws |
| Main noise source | Unreachable or sanitised paths | Unused vulnerable functions | Test values and false matches |
| Fix | Change the code | Upgrade or replace the package | Rotate, then remove |
| Typical owner | Service team | Service team or platform team | Credential owner |
Run all three at pull request time, then correlate
All three belong on the pull request, where the change is small and the author still has context. Secrets scanning should also run on full history and on built images, because credentials leak through paths a diff never shows. SCA should run again when new advisories are published, because the code did not change but your knowledge did.
The harder problem is what happens afterwards. Three scanners on the order-tracking pull request produce three findings in three formats, ranked on three scales. The useful question is which matters most for this service, and that needs the findings joined: the injection matters more if the endpoint is public, and the library advisory matters more if the vulnerable function is reachable.
Key takeaways
- Run SAST, SCA and secrets scanning together on every pull request, because none of them covers the others’ ground.
- Scan full git history and built images for secrets, not only the diff.
- Re-run SCA matching when new advisories land, since dependency risk changes without code changes.
- Rank the combined results by reachability and exposure rather than by each scanner’s own severity.
How SecurityVault approaches this
SecurityVault selects supported code, dependency and secrets scanners for a repository and brings their results into a shared workflow. These remain distinct detection techniques with different coverage limits. Available source and deployment context helps route findings and set priorities, while configured gate policy determines which findings block a release.
A useful demonstration starts with three separate issues in a test repository: a code weakness, a vulnerable dependency and a non-production credential fixture. Review which scanner produced each observation and what evidence supports it. Check that a shared service context does not merge unrelated issues into one finding. Then inspect the configured release outcome for each case. This helps developers and security reviewers understand how complementary checks work together, which gaps remain and why the response to a leaked credential differs from the response to a package advisory.
Explore Available capabilities or talk to our team about an evaluation with your engineering, security and compliance stakeholders.