Dependency Vulnerability Report Template

Overview

A Dependency Vulnerability Report Template captures security findings from software composition analysis (SCA) tools. It turns scan output into a useful document that developers, security engineers, and product owners can use to prioritize remediation.

When to Use

• After a scheduled SCA scan in CI/CD.
• When a new CVE is disclosed in a widely used library.
• Before a release or security audit.
• After adding a new dependency to a project.
• To report findings to a vulnerability management program.

Prerequisites

• A completed SCA scan from a tool such as Snyk, OWASP Dependency-Check, or GitHub Advanced Security.
• Access to the affected repository and dependency manifest.
• A vulnerability scoring framework, such as CVSS or your own risk matrix.
• A defined remediation SLA by severity.

Solution

Template

1. Finding Summary

Field	Description	Example
Report ID	Unique identifier	VULN-2026-0042
Date discovered	When the finding was identified	2026-06-27
Reporter	Person or tool that found it	Snyk bot / Security team
Project	Repository or service affected	payment-service
Environment	Where the dependency runs	Production, CI, Dev

2. Vulnerability Details

Field	Description	Example
CVE ID	Common Vulnerabilities and Exposures identifier	CVE-2026-12345
Severity	CVSS score or custom severity	High (8.1)
Affected package	Library and ecosystem	log4j-core (Maven)
Installed version	Current version in the project	2.14.0
Patched version	First fixed version	2.17.1
Attack vector	How the vulnerability can be exploited	Remote code execution via log message
Exploit availability	Is a public exploit known?	Public PoC available

3. Impact Assessment

Question	Answer
Is the vulnerable function reachable?	Yes, via request logging
Is the dependency exposed to the internet?	Yes, edge service
Does the dependency process untrusted input?	Yes, user-supplied content
Is a compensating control in place?	WAF blocks malicious patterns
Estimated business impact	Payment flow interruption

4. Remediation Plan

Step	Owner	Due Date	Status
Upgrade dependency to 2.17.1	Backend team	2026-07-01	Not started
Run regression tests in staging	QA team	2026-07-02	Not started
Deploy to production	DevOps	2026-07-03	Not started
Verify fix via re-scan	Security team	2026-07-05	Not started

5. Risk Acceptance

Field	Value
Can the risk be accepted?	No
Justification	Internet-facing RCE with public exploit
Risk owner	Engineering manager
Approval date	N/A
Review date	N/A

Explanation

The report connects the raw CVE data to the specific project, runtime context, and business impact. This prevents teams from treating every vulnerability the same way and helps prioritize those that are actually exploitable in production.

Variants

• Executive summary report: One-page version with only severity, count, and risk trend for leadership.
• CI/CD failure report: Captures why a pipeline was blocked and tracks unblocking steps.
• Open-source maintainer report: Formatted for upstream disclosure and CVE publication.
• Historical trend report: Aggregates findings across months to track security posture improvement.

What works

• Keep a single report per finding or per CVE/project pair to avoid duplicates.
• Always include exploitability analysis, not just CVSS score.
• Assign an owner and a due date before closing the report.
• Link to the SCA scan output, SBOM, and pull request for traceability.
• Re-scan after remediation to verify the fix.
• Review accepted risks quarterly.

Common Mistakes

• Remediating only by CVSS score without considering exploitability.
• Forgetting to test the upgraded dependency in a real workload.
• Closing reports before a re-scan confirms the fix.
• Missing transitive dependencies because the report only lists direct ones.
• Accepting risk without documenting the business justification.

Advanced Solutions

Automated SCA scan in GitHub Actions

Integrate Snyk and Trivy into a GitHub Actions workflow to scan dependencies on every PR:

name: Dependency Security Scan
on:
  pull_request:
    paths:
      - "package.json"
      - "package-lock.json"
      - "requirements.txt"
      - "pom.xml"
  schedule:
    - cron: "0 6 * * 1"  # Weekly Monday scan

jobs:
  sca-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Run Snyk scan
        uses: snyk/actions/node@master
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
        with:
          args: --severity-threshold=high --json > snyk-results.json

      - name: Run Trivy filesystem scan
        run: |
          trivy fs --format json --output trivy-results.json .
          trivy fs --format table --exit-code 1 --severity HIGH,CRITICAL .

      - name: Generate vulnerability report
        run: |
          node -e "
            const snyk = require('./snyk-results.json');
            const trivy = require('./trivy-results.json');
            const findings = [
              ...snyk.vulnerabilities.map(v => ({
                source: 'snyk', cve: v.identifiers.CVE?.[0] || 'N/A',
                package: v.name, severity: v.severity,
                fixedVersion: v.fixInfo?.[0]?.version || 'N/A'
              })),
              ...trivy.Results.flatMap(r => r.Vulnerabilities || []).map(v => ({
                source: 'trivy', cve: v.VulnerabilityID,
                package: v.PkgName, severity: v.Severity,
                fixedVersion: v.FixedVersion || 'N/A'
              }))
            ];
            console.log('| Source | CVE | Package | Severity | Fixed Version |');
            console.log('|--------|-----|---------|----------|---------------|');
            findings.forEach(f => {
              console.log('| ' + f.source + ' | ' + f.cve + ' | ' + f.package + ' | ' + f.severity + ' | ' + f.fixedVersion + ' |');
            });
          " > vulnerability-report.md

      - name: Upload report as artifact
        uses: actions/upload-artifact@v4
        with:
          name: vulnerability-report
          path: vulnerability-report.md

SBOM generation with CycloneDX

Generate a Software Bill of Materials (SBOM) to track all dependencies including transitive ones:

#!/bin/bash
set -euo pipefail

# Generate SBOM for Node.js project
npx @cyclonedx/cyclonedx-npm --output-format json --output-file sbom.json

# Generate SBOM for Python project
pip install cyclonedx-bom
cyclonedx-py requirements.txt --format json --output - > sbom-python.json

# Enrich SBOM with vulnerability data using Trivy
trivy sbom --format json --output sbom-enriched.json sbom.json

# Extract vulnerable packages from enriched SBOM
jq '.Results[] | select(.Class=="sbom") | .Vulnerabilities[] | {
  cve: .VulnerabilityID,
  package: .PkgName,
  severity: .Severity,
  fixed_version: .FixedVersion
}' sbom-enriched.json

Transitive dependency analysis script

Identify which transitive dependencies introduce vulnerabilities in a Node.js project:

#!/bin/bash
set -euo pipefail

echo "=== Direct vs Transitive Vulnerable Dependencies ==="
echo ""

# Get all vulnerable packages
npm audit --json > audit-output.json 2>/dev/null || true

# Extract vulnerable packages and their dependency paths
jq -r '.vulnerabilities | to_entries[] | {
  package: .key,
  severity: .value.severity,
  is_direct: (.value.isDirect | tostring),
  via: (.value.via | map(.name // .source | tostring) | join(", ")),
  fixAvailable: (.value.fixAvailable | tostring)
}' audit-output.json

echo ""
echo "=== Transitive dependency chains ==="
# Show the full path from direct dependency to vulnerable transitive
npm ls --all --json 2>/dev/null | \
  jq -r '
    def walk_deps($name):
      .. | objects | select(.name == $name) | path;
    .vulnerabilities // {} | keys[] as $pkg |
    "Vulnerable: \($pkg)"
  ' audit-output.json 2>/dev/null || true

Additional Best Practices

• For a deeper guide, see Vulnerability Scan Report Template.

1. Use reachability analysis to reduce false positives. Tools like Snyk Code and OWASP Dep-Check can determine if the vulnerable function is actually called in your code. Suppress findings for unreachable code with documented justification:

# Snyk reachability analysis
snyk test --json --reachable-vulns | \
  jq '.vulnerabilities[] | {
    name: .name,
    reachable: .reachable,
    functions: .reachableFunctions
  }'

2. Set up automated PR comments for new vulnerabilities. Configure Dependabot or Snyk to comment on PRs that introduce vulnerable dependencies, blocking merge until reviewed:

# .github/dependabot.yml
version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    allow:
      - dependency-type: "all"
    labels:
      - "security"
      - "dependencies"
    open-pull-requests-limit: 10

Additional Common Mistakes

1. Ignoring dev dependencies in vulnerability scans. Dev dependencies can be exploited in CI environments or by malicious PRs. Scan all dependencies, not just production ones:

# Scan both production and dev dependencies
npm audit --production=false
snyk test --dev

2. Not tracking vulnerabilities in Docker base images. Application dependency scans miss OS-level packages in your container base image. Scan the image separately:

# Scan Docker image for OS-level vulnerabilities
trivy image --severity HIGH,CRITICAL myapp:latest
grype myapp:latest --fail-on high