Configure SCA for Vulnerability and License Compliance

This is a Software Composition Analysis (SCA) configuration skill for setting up dependency-vulnerability scanning and license-compliance enforcement across a tech stack, covering tool selection (Snyk, WhiteSource/Mend, Black Duck, FOSSA, GitHub Dependency Scanning), detection coverage (manifest-file analysis, lock-file scanning, binary analysis, container-image scanning), and policy definition (vulnerability-severity thresholds that block builds on Critical/High findings, approved and restricted license lists, dependency-age and maintenance-status checks, and known-malicious-package detection). A representative CI integration runs Snyk and FOSSA together in one pipeline:

name: SCA Security Scan
on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  sca-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      
      # Snyk vulnerability scanning
      - name: Run Snyk to check for vulnerabilities
        uses: snyk/actions/node@master
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
        with:
          args: --severity-threshold=high --fail-on=upgradable
      
      # FOSSA license compliance
      - name: FOSSA Scan
        uses: fossas/fossa-action@main
        with:
          api-key: ${{ secrets.FOSSA_API_KEY }}
          container: fossa/fossa:latest

Use this skill when configuring SCA tooling for a specific language ecosystem - it gives concrete per-language configuration patterns: a .snyk policy file for Node.js/JavaScript, an OWASP dependency-check-maven plugin block for Java/Maven (failing the build at CVSS 7), and a safety policy file for Python, with a documented pattern for temporarily ignoring a specific CVE with a reason and an expiry date. It also covers container scanning via a multi-stage Dockerfile that runs Trivy against dependencies before the runtime image is built, and SBOM generation and validation with syft and grype. It is not a one-time scan - the skill assumes continuous monitoring with webhooks for new vulnerabilities and license changes, so it isn't suited for a single ad hoc scan without an ongoing policy and remediation process behind it.

Inputs are the project's manifests, lock files, container images, and defined policies - severity thresholds, approved and prohibited license lists, custom vulnerability-database mirrors. Outputs are CI pipeline configurations (GitHub Actions and GitLab CI both shown), language-specific policy files, an SBOM in SPDX or CycloneDX format, and a metrics set tracking vulnerability trends (critical-count over time, mean-time-to-remediation, introduction rate), license-compliance violations, and dependency-health indicators such as percentage outdated and update frequency. A sample license policy approves MIT, Apache-2.0, BSD-3-Clause, and ISC, allows GPL-3.0 conditionally for development tools only, and prohibits AGPL-3.0, GPL-2.0, and LGPL-3.0.

Covers Snyk, WhiteSource/Mend, Black Duck, FOSSA, GitHub Dependency Scanning, OWASP Dependency-Check, safety (Python), Trivy (container scanning), syft/grype (SBOM generation and validation), Gemnasium (GitLab CI), and custom NVD-mirror or internal vulnerability-feed integration.

Security and platform engineering teams configuring dependency and license scanning across a multi-language stack, who need concrete per-language policy files, CI pipeline blocks, and SBOM and metrics setup rather than a generic "add a scanner" instruction.