Secure development: Part 4 — SCA: dependency checking

Most of the code in a modern application was not written by you. The framework, the database driver, libraries for logging, JSON parsing and image processing — all of this is third-party open source code, and each of these libraries brings in several more. A vulnerability in any of them becomes a vulnerability in your application. Checking this part of the project is the job of SCA.

What is SCA

SCA (Software Composition Analysis) — tools that produce a complete list of a project’s dependencies and check it against databases of known vulnerabilities. Many of them also check library licenses.

The main difficulty is transitive dependencies. By adding one package to the project, for example requests in Python or express in Node.js, you also get all the packages that it depends on. An SCA scanner reads manifests and lock files (package-lock.json, poetry.lock, go.sum, pom.xml) and builds the entire tree, not just the packages you explicitly listed.

How serious this can be was shown by the Log4Shell vulnerability in the Java Log4j library in December 2021. It was enough to pass a specially crafted string to a place that would be logged to execute code on the server. Many companies spent weeks figuring out which projects even used that library. If the dependency list for each project had been at hand, the answer would have taken minutes.

Tools

Trivy is a good first choice: one tool for code, images and SBOM. Grype and OSV-Scanner are useful as a second opinion because vulnerability databases differ slightly between scanners.

Scanning a project

Trivy is installed from your package manager or as a binary from the releases page. To scan a project directory:

trivy fs --scanners vuln .

In the report for each finding the library, the vulnerability identifier (for example, CVE), the severity level, the installed version and the version in which the vulnerability is fixed are shown.

Check licenses:

trivy fs --scanners license .

The same checks with other scanners:

grype dir:.
osv-scanner scan source -r .

SBOM: list of components

SBOM (Software Bill of Materials) — a machine-readable list of all the components of an application. It is created at each build and stored with the release. When a new vulnerability appears, it is enough to check the saved SBOMs rather than rebuilding projects.

trivy fs --format cyclonedx --output sbom.json .
trivy sbom sbom.json

The first command creates an SBOM in CycloneDX format, the second checks it for vulnerabilities. SPDX format is also supported.

SCA in CI

Checks should run automatically. Example GitHub Actions job that fails the build on critical vulnerabilities:

name: sca
on: [pull_request]

jobs:
  trivy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Install Trivy
        run: curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh | sh -s -- -b /usr/local/bin
      - name: Scan dependencies
        run: trivy fs --scanners vuln --severity HIGH,CRITICAL --exit-code 1 .

--exit-code 1 makes findings a build failure, --severity limits checks to serious levels so the CI doesn’t stop over every minor issue.

What to do with the results

On the first run against a real project you may find hundreds of findings. That’s normal.

1. Start with HIGH and CRITICAL, especially in libraries that handle input: web frameworks, file parsing, serialization.
2. Check whether the vulnerable code is actually used. A vulnerability in a function the application does not call is less urgent. But don’t postpone such updates forever.
3. Update in small steps. A major upgrade can break the application, so run tests after each update.
4. If there is no fix, record a deliberate exception with a review date: Trivy supports a .trivyignore file for this.

Automatic updates are handled by Dependabot or Renovate: the bot opens a pull request with the new version, and you just wait for the tests and merge it. Renovate is more configurable and works not only with GitHub but also with GitLab, including self-hosted instances.

Lock files

A lock file pins the exact versions of all dependencies, including transitive ones. Without it, two builds of the same code can end up with different library versions, and a version that nobody tested can get into production.

• Keep the lock file in the repository.
• In CI, install dependencies strictly according to it: npm ci, poetry install, pip install --require-hashes -r requirements.txt.
• Update the lock file deliberately, as a separate change that goes through the same checks.

Dependency licenses

SCA scanners also warn about licenses. Copyleft licenses (GPL, AGPL) may require you to disclose source code, but obligations depend on how you distribute the product. A program you distribute to customers and a service that runs only on your servers are different cases, and AGPL also applies to network use. It’s better to agree on a list of allowed licenses with legal counsel once and check it automatically.

Key takeaways

• Every new dependency is another supplier of code. Don’t add a library for the sake of a five-line feature.
• Scan regularly, not only at build time: new vulnerabilities in older versions are found every day.
• Keep lock files and SBOMs — then the question “where do we have that library” can be answered in minutes.