SCA

SCA scans your dependency manifests + lockfiles for known-vulnerable packages, and records each dependency’s license.

​

What it catches

• Known CVEs in direct + transitive dependencies — CVSS-scored, and enriched with EPSS exploit-probability and CISA KEV (“known exploited”) flags for prioritisation
• Fix availability — whether a patched version exists; findings with no upstream fix are flagged as such (and can be excluded with --sca-ignore-unfixed)
• Dependency licenses — each package’s detected license is recorded on the finding and in the generated SBOM (copyleft licenses such as GPL / AGPL / LGPL / MPL are surfaced)

​

Ecosystems supported

The scanner reads whatever manifests and lockfiles are present in the repo, and a committed lockfile (the truth about what actually gets installed) gives the most accurate result. When a project has a manifest but no lockfile, the platform scanner generates one by running the project’s own resolver (Gradle, npm, Poetry and so on), which downloads dependency metadata from the registries the project declares.

​

Private registries

The platform scanner has no credentials for your private package registries, such as AWS CodeArtifact, GitHub Packages, Artifactory or Nexus, so it can’t download dependencies that live there:

• Gradle: everything else still resolves and is listed. A private library whose version the build pins is listed too; the packages that only it brings in are missing. If the build can’t start without a private artifact, such as a version catalog or plugin loaded in settings.gradle, none of that build’s packages can be listed.
• Other ecosystems: if a lockfile can’t be generated, that project’s packages are missing.

The repository’s SBOM and Vulnerabilities tabs say what the latest scan couldn’t cover: which dependencies are missing and which registry refused them. To get the complete list, either:

• Commit your lockfiles. For Gradle, enable dependency locking and commit the gradle.lockfile files it writes.
• Scan in your CI pipeline with the TigerGate CLI (tigergate scan --type all --upload). The pipeline already has the registry credentials, so the SBOM it uploads is complete.

​

Vulnerability sources

SCA uses TigerGate’s dependency-vulnerability (SCA) engine. It matches your dependencies against a vulnerability database that aggregates:

1. NVD — National Vulnerability Database (CVSS scores)
2. GitHub Security Advisories — GHSA IDs, often published earlier than NVD
3. OS distribution advisories — Alpine, Debian, Ubuntu, RHEL, Amazon, SUSE, Wolfi, etc. (used for OS/container packages)

TigerGate then enriches each CVE with EPSS exploit-probability scores and CISA KEV status. Findings de-duplicate by CVE / GHSA ID.

​

Auto-fix suggestions

For most CVE findings, TigerGate suggests the smallest patched version above the installed one, preferring a stable release.

• “lodash@4.17.20 → 4.17.21 (patches CVE-2021-23337)”
• “ws@8.5.0 → 8.17.1 (patches CVE-2024-37890)”

To turn a finding into a ready-to-merge upgrade PR, use Auto-Fix from the finding’s detail view — it edits the manifest and opens the PR for you. Auto-Fix is available for repositories connected to TigerGate, not for findings uploaded from CI. When a CVE has no fixed version, no upgrade is suggested — wait for an upstream fix.

​

Dependency licenses

The scan resolves each dependency’s license — from the package’s own metadata and, offline, from any LICENSE/COPYING file in its source — and records it on the finding and in the generated SBOM. Copyleft licenses (GPL / AGPL / LGPL / MPL) are therefore visible across your dependency tree. Licenses that can’t be determined offline are shown as Unknown rather than guessed.

​

Suppressing false positives

A CVE that affects a code path you don’t use is a common false positive. Open the finding and, from the status dropdown, set its status to Accepted (or Won’t Fix / False Positive) — it drops off the open findings list.