Security8 min read

Software Composition Analysis

Dependency and third-party library security analysis - SBOM, CVE scanning, Snyk, Dependabot, and protection against supply chain attacks.

Ing. Gleb Kushnir, founder · Updated

What is Software Composition Analysis?

Software Composition Analysis (SCA) is an automated process for identifying and analyzing open-source components, libraries, and dependencies in your application. SCA tools detect known security vulnerabilities, license risks, and outdated dependency versions. According to the Black Duck OSSRA 2026 report, 98% of audited codebases contain open source.

98%
of codebases contain open source (OSSRA 2026)
87%
of codebases have at least one open-source vulnerability (OSSRA 2026)
1,180
open-source components in the average application (OSSRA 2026)

Why is SCA Critical?

Modern applications are built on dozens to hundreds of third-party libraries. Each dependency represents a potential security risk:

  • Known vulnerabilities (CVE): Publicly known security flaws in open-source libraries
  • Transitive dependencies: Dependencies of your dependencies that often go unnoticed
  • Outdated versions: Libraries that have not been updated and contain unpatched bugs
  • License risks: Conflicting or incompatible open-source component licenses
  • Supply chain attacks: Compromised libraries deliberately targeted by attackers

Notable Dependency Vulnerability Cases

  • Log4Shell (CVE-2021-44228): Critical RCE vulnerability in Apache Log4j 2 (CVSS 10.0), listed in the CISA KEV catalog as actively exploited
  • Heartbleed (CVE-2014-0160): OpenSSL 1.0.1 vulnerability allowing attackers to read server memory, including sensitive data
  • Struts 2 (CVE-2017-5638): RCE vulnerability that Equifax identified as the attack vector of its 2017 breach; according to the FTC, the breach affected approximately 147 million people
  • event-stream npm package: Supply chain attack in which the flatmap-stream dependency added to a popular library carried malicious code targeting the Copay bitcoin wallet (npm)

What Do SCA Tools Detect?

1. Security Vulnerabilities

SCA tools scan your dependencies against known vulnerability databases (CVE, NVD, GitHub Advisory Database, Snyk Vulnerability DB):

  • Identification of CVE numbers and their severity (Critical, High, Medium, Low)
  • Availability of fixes and recommended upgrade versions
  • Exploitability of the vulnerability (does an active exploit exist?)
  • CVSS score and attack vector descriptions

2. License Compliance

Analysis of open-source library licenses and detection of potential conflicts:

  • GPL, MIT, Apache, BSD, and other licenses
  • License compatibility with your project
  • Copyleft requirements and their implications
  • Commercial risks when using certain licenses

3. Outdated Dependencies

Identification of libraries that are outdated or no longer maintained:

  • Versions with available updates
  • End-of-life (EOL) libraries without support
  • Breaking changes when upgrading to newer versions

4. Software Bill of Materials (SBOM)

A complete inventory of all components in your application:

  • Direct dependencies (declared in package.json, pom.xml, etc.)
  • Transitive dependencies (dependencies of dependencies)
  • Version, license, and origin of each component
  • Dependency graphs and relationships between libraries

Popular SCA Tools

Cloud / Commercial

Snyk Open Source

One of the most popular cloud-based SCA tools with an extensive vulnerability database and easy CI/CD integration.

  • Automatic PRs with fixes
  • Vulnerability prioritization by exploitability
  • Support for npm, Maven, pip, RubyGems, NuGet
  • IDE integration (VS Code, IntelliJ)
  • Free plan with limits
Cloud / Commercial

Mend.io (formerly WhiteSource)

Enterprise-grade SCA solution focused on license compliance and comprehensive reporting.

  • Real-time alerting on new vulnerabilities
  • Advanced license analysis
  • Policy enforcement
  • Integration with Jira, ServiceNow
Open Source

OWASP Dependency-Check

Open-source tool from OWASP for detecting known vulnerabilities in project dependencies.

  • Full support for Java and .NET; other ecosystems (Node.js, Ruby, Python, Go) partial or via experimental analyzers
  • CLI, Maven, Gradle, Ant, and Jenkins plugins
  • Data from the NVD API; an NVD API key is needed for reasonable update speed (current version 13.0.0)
  • HTML, XML, JSON, SARIF, and other report formats
  • Completely free and open-source
GitHub Native

GitHub Dependabot

Native GitHub tool for automatic security updates of dependencies.

  • Automatic Pull Requests with fixes
  • Dependabot Security Alerts
  • Version updates for supported ecosystems
  • Included even in the GitHub Free plan (GitHub Pricing)
  • Integration with GitHub Security Advisory
CLI Tool

npm audit / yarn npm audit

Built-in tools in npm and Yarn for auditing Node.js dependencies. In Yarn 2+ the command is yarn npm audit.

  • Instant analysis of the dependency tree from the lockfile
  • Automatic fixes via npm audit fix
  • Severity levels (low, moderate, high, critical)
  • Data from the GitHub Advisory Database via the npm registry
Enterprise

JFrog Xray

Universal artifact analysis for comprehensive CI/CD pipeline security.

  • Scanning Docker images, Maven, npm, PyPI
  • Integration with JFrog Artifactory
  • Policy-based artifact blocking
  • Deep scan of binary artifacts

Practical Example: npm audit

The simplest way to get started with SCA in Node.js projects:

# Run dependency audit npm audit # Output shows found vulnerabilities: # 3 vulnerabilities (1 moderate, 2 high) # Automatically fix vulnerabilities npm audit fix # Generate a detailed report npm audit --json > audit-report.json # Audit production dependencies only npm audit --omit=dev # Set audit level in CI/CD npm audit --audit-level=high # If high or critical is found, the command exits with a non-zero code

Example npm audit output:

According to the npm documentation, --audit-level does not filter the report; it only changes the threshold at which the command fails.

# npm audit report minimatch <3.0.5 Severity: high minimatch ReDoS vulnerability - https://github.com/advisories/GHSA-f8q6-p94x-37v3 fix available via `npm audit fix` node_modules/minimatch 1 high severity vulnerability To address all issues, run: npm audit fix

SBOM - Software Bill of Materials

An SBOM is a formal list of all components, libraries, and modules in your software. It is like an "ingredients list" for your application.

Why is SBOM Important?

  • Transparency: Visibility into all components of your application
  • Rapid vulnerability response: Instant identification of whether you are affected (e.g., Log4Shell)
  • Compliance: Regulatory requirements, e.g., US Executive Order 14028 (SBOMs for federal suppliers) or the EU Cyber Resilience Act, whose reporting obligations apply from 11 September 2026 and main obligations from 11 December 2027
  • Supply chain security: Detection of unauthorized or malicious components
  • License audit: Overview of all licenses in use

SBOM Standards

  • SPDX (Software Package Data Exchange): ISO/IEC 5962:2021 standard; the current specification version is SPDX 3.0
  • CycloneDX: OWASP standard focused on security, since 2024 also Ecma standard ECMA-424 (the 2nd edition from December 2025 corresponds to CycloneDX 1.7)
  • SWID (Software Identification Tags): ISO/IEC 19770-2 standard

Generating SBOM with CycloneDX

# Install CycloneDX CLI for Node.js npm install -g @cyclonedx/cyclonedx-npm # Generate SBOM in CycloneDX format cyclonedx-npm --output-file sbom.json # The SBOM contains: # - All dependencies (direct and transitive) # - Versions and licenses # - Hashes (checksums) for integrity # - Package URL (purl) identifiers for vulnerability lookup # CI/CD integration cyclonedx-npm --output-file sbom.xml --output-format XML # Store the SBOM as an artifact for audit trail

Best Practice: SBOM with Every Release

Generate and store an SBOM with every production release. This enables retroactive analysis if a new vulnerability is discovered in a library you were using in the past.

Integrating SCA into a CI/CD Pipeline

SCA should be integrated into every phase of the development lifecycle:

1. Pre-commit / IDE Integration

  • Snyk extension for VS Code
  • Pre-commit hooks with dependency checks

2. CI/CD Pipeline (Continuous Integration)

# GitHub Actions example name: Security Scan on: [push, pull_request] jobs: dependency-check: runs-on: ubuntu-latest steps: - uses: actions/checkout@v7 - name: Run npm audit run: npm audit --audit-level=high - name: Run Snyk uses: snyk/actions/node@master env: SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }} with: args: --severity-threshold=high - name: Generate SBOM run: | npm install -g @cyclonedx/cyclonedx-npm cyclonedx-npm --output-file sbom.json - name: Upload SBOM artifact uses: actions/upload-artifact@v7 with: name: sbom path: sbom.json

3. GitLab CI/CD Example

dependency_scanning: stage: test image: node:24 script: # npm audit - npm ci - npm audit --audit-level=moderate || true # CycloneDX SBOM for GitLab - npx @cyclonedx/cyclonedx-npm --output-file gl-sbom-npm.cdx.json # Snyk - npm install -g snyk - snyk auth $SNYK_TOKEN - snyk test --json > snyk-report.json artifacts: when: always reports: cyclonedx: gl-sbom-npm.cdx.json paths: - snyk-report.json owasp_dependency_check: stage: test image: name: owasp/dependency-check:13.0.0 entrypoint: [""] script: # Dependency-Check needs Java, so it runs in its own image; set NVD_API_KEY as a CI/CD variable - /usr/share/dependency-check/bin/dependency-check.sh --project "MyApp" --scan . --format HTML --format JSON --nvdApiKey "$NVD_API_KEY" artifacts: when: always paths: - dependency-check-report.html - dependency-check-report.json

4. Continuous Monitoring

  • Dependabot: Automatic PRs with security fixes
  • Snyk Monitor: Continuous monitoring of production dependencies
  • Scheduled scans: Weekly/daily rescans against new CVE databases

SCA Best Practices

Recommended Practices

  • Automate scanning: Every commit and PR should go through SCA checks
  • Set severity thresholds: Block builds with critical/high vulnerabilities
  • Use lockfiles: package-lock.json, yarn.lock, Pipfile.lock for reproducible builds
  • Update regularly: Do not wait for critical CVEs, update preventively
  • Minimize dependencies: Fewer dependencies = smaller attack surface
  • Verify integrity: Use checksums and signed packages
  • Monitor production: Runtime monitoring for supply chain attacks
  • Create SBOMs: For every release and retain the history
  • Vendor security: Check a library's security track record before adding it
  • Private registry: Consider an internal Artifactory/Nexus for artifact control

Common SCA Mistakes

  • Ignoring false positives: Over time you will lose trust in the tool
  • No remediation process: SCA without action is pointless
  • Scanning only production deps: DevDependencies can also contain vulnerabilities
  • Automatic updates without tests: Breaking changes can break your application
  • Forgetting transitive dependencies: According to OSSRA 2026, 64% of open-source components in a typical codebase are transitive

SCA and Other DevSecOps Tools

SCA is just one layer of security testing. For comprehensive security, combine it with:

Tool What It Tests When to Use
SCA Vulnerabilities in dependencies Every commit, before adding a new dependency
SAST Vulnerabilities in your own code During development, in CI/CD
DAST Runtime vulnerabilities in a running application Staging/QA environment before production
Container Scanning Vulnerabilities in base images and layers Before pushing to registry, at runtime
IaC Security Misconfigurations in Terraform/CloudFormation Before applying infrastructure changes

Sources

  1. Black Duck: 2026 Open Source Security and Risk Analysis (OSSRA) Report (March 2026)
  2. NIST NVD: CVE-2021-44228 (Log4Shell) (August 2026)
  3. Equifax: Equifax Releases Details on Cybersecurity Incident (September 2017)
  4. FTC: Equifax to Pay $575 Million as Part of Settlement (July 2019)
  5. npm Blog: Details about the event-stream incident (November 2018)
  6. npm Docs: npm audit (October 2026)
  7. OWASP Dependency-Check: Release 13.0.0 (August 2026)
  8. Ecma International: ECMA-424 CycloneDX Bill of Materials Specification (December 2025)
  9. SPDX: Overview (ISO/IEC 5962:2021) (October 2026)
  10. NIST: Software Security in Supply Chains: Software Bill of Materials (SBOM) (November 2024)
  11. European Commission: Cyber Resilience Act (October 2026)

More on this topic

Want this handled without building your own DevOps team?

Our four-person DevOps team runs your platform for a fixed monthly price.

Or write to info@devsecops.cz. We process your data under our privacy policy.