What is SCA and how to check dependencies for known risks

Hook

SCA answers a very practical question: which third-party components are inside our project, and which known risks are attached to them?

It is not a magic “make secure” button. It is a dependency radar. It shows where libraries, packages, or container layers have known issues so the team can make a sane decision: update, replace, accept the risk, or investigate deeper.

Problem / Context

A modern application is almost always a mix of first-party code and many third-party components. In Node.js that means npm or pnpm packages. In Python it means PyPI. In backend and infrastructure stacks it can also mean container images, system packages, Terraform modules, GitHub Actions, and many smaller parts.

Teams often see only direct dependencies in package.json. The real production artifact also contains transitive dependencies. That is where CVEs, old versions, and license surprises often appear.

SCA takes a dependency inventory and compares it with vulnerability databases, advisory feeds, policy rules, and license data. The output is a list of findings, not absolute truth. After that, the team still needs triage.

Why It Matters

Without SCA, dependency risk is discovered by accident: from news, from a customer, after an incident, or during a manual pre-release review. That is slow and stressful.

With SCA, risks become visible earlier:

• a pull request adds a vulnerable dependency;
• Dependabot or Renovate opens an update;
• a release scan finds a critical CVE in a container image;
• the security team sees which findings repeat;
• the team can connect SBOM data with real triage.

There is a trap, though. If SCA shouts about every CVE, people quickly stop listening. A good process separates “critical and reachable” from “listed in a database but not actually used in our product”.

The Mental Model

Think of SCA as a product contents check before shipping. First you need to know what is in the box. Then you check whether those parts have known problems. Then you decide what to do.

The practical flow:

1. lockfile or artifact provides the component list;
2. SBOM makes the list portable and tied to a release;
3. SCA compares components with advisory databases;
4. triage considers severity, exploitability, and reachability;
5. dependency update or mitigation enters the normal workflow.

Important detail: SCA should scan what actually reaches production. Source tree scanning is useful, but if production is a container image, scan the image too.

How To Do It

1. Start with the right source

For Node.js, the minimum is scanning the lockfile:

npm audit --production
pnpm audit --prod

For container-based deployment, add an image scanner such as Trivy or another tool that can see OS packages and application dependencies. If you already have an SBOM, use it as stable input for security review.

2. Add SCA to CI/CD

The first level is a pull request check:

name: dependency-scan
on: [pull_request]
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 24
      - run: npm ci
      - run: npm audit --production --audit-level=high

This is not a perfect enterprise setup, but it catches obvious high-risk changes. Later you can add GitHub dependency review, GitLab dependency scanning, Snyk, Trivy, osv-scanner, or another tool that fits your stack.

3. Do not confuse severity with action

Severity matters, but it does not answer every question. During triage, check:

• whether the component exists in production;
• whether it is direct or transitive;
• whether the vulnerable function is used;
• whether an exploit exists;
• whether a fixed version exists;
• whether a temporary mitigation exists;
• whether the update breaks compatibility.

A critical reachable vulnerability in a production dependency is a blocker candidate. A medium finding in a dev-only package may go to backlog. The key is to make this a rule, not a Friday-evening mood.

4. Set up update workflow

SCA without an update workflow quickly becomes a red list. You need:

• automated dependency pull requests;
• a triage owner;
• an emergency update rule;
• a backlog for non-blocking findings;
• periodic review of exceptions;
• connection with SBOM for release evidence.

5. Document exceptions

Sometimes a finding really does not affect the product. For example, the vulnerable part of a library is not packaged into production, or the code path is unreachable. Accepting that can be fine, but not silently.

For an exception, record the CVE, component, version, reason for accepting the risk, owner, and review date. An exception without a review date almost always becomes debt.

Common Mistakes

• scanning only direct dependencies;
• ignoring the container image;
• blocking every finding without triage;
• blocking nothing because “SCA is noisy”;
• failing to update the lockfile after a dependency update;
• keeping suppressions without owners;
• confusing a dev-only package with a production dependency;
• thinking SCA replaces code review or threat modeling.

Conclusion / Action Plan

SCA makes dependency risk visible. But it becomes useful only when scans are connected to the real artifact, triage rules are clear, and dependency updates are not a heroic manual process.

Start small:

1. identify what actually reaches production;
2. run SCA on the lockfile and container image;
3. add a PR check for high and critical findings;
4. set up dependency update pull requests;
5. keep a backlog for non-blocking risks;
6. document exceptions with a review date;
7. connect SCA with SBOM for release evidence.

Official sources:

• https://owasp.org/www-community/Component_Analysis
• https://owasp.org/www-project-dependency-check/
• https://docs.github.com/en/code-security/dependabot/dependabot-alerts/about-dependabot-alerts
• https://docs.gitlab.com/user/application_security/dependency_scanning/
• https://www.cisa.gov/sbom