Any security scanning tool may produce false positives, issues that are acceptable for a period of time, or issues that need to be temporarily ignored. vet supports adding packages to an exceptions list, excluding them from scan results and reports.

Package exceptions must be handled with care. Any package added to the exceptions list will not be scanned and reported, including any future issues that may arise. To mitigate this risk, all exceptions must have an expiration date and cannot be permanent.

Exception Use Cases

False Positives

Suppress known false positive vulnerability reports

Accepted Risk

Temporarily accept specific risks during remediation planning

Legacy Dependencies

Provide time-bound exceptions for legacy systems being migrated

Testing Dependencies

Exclude test-only dependencies from production security policies

Generating Exceptions List

Manual Creation

Create an exceptions.yml file with the following structure:

description: Exceptions File for vet
exceptions:
  - ecosystem: npm
    expires: "2025-05-10T00:00:00Z"
    id: 01JKMC07KAGJYEDZX1XPAC3SKP
    name: '@babel/plugin-transform-function-name'
    version: 7.18.9
    reason: "False positive - CVE doesn't apply to our usage"

  - ecosystem: npm
    expires: "2025-05-10T00:00:00Z"
    id: 01JKMC07KASSGYH1PHQY09QNZ3
    name: '@babel/plugin-proposal-object-rest-spread'
    version: 7.12.1
    reason: "Legacy dependency being replaced in Q2 2025"
  • The expires field is mandatory and must be in RFC3339 format
  • The id field must be unique and can be any unique string format
  • Adding a reason field is recommended for documentation

Automated Generation with vet

Generate exceptions automatically based on filter criteria:

1

Scan and Dump Data

Run a scan and dump raw data to a temporary directory:

vet scan -D /path/to/repo --json-dump-dir /path/to/dump
2

Generate Conditional Exceptions

Create exceptions for packages without critical or high severity issues:

vet query --from /path/to/dump \
    --exceptions-generate /path/to/exceptions.yml \
    --exceptions-filter '!vulns.critical.exists(p, true) && !vulns.high.exists(p, true)' \
    --exceptions-till '2025-05-01'
3

Review and Refine

Review the generated exceptions file and remove unnecessary entries

Generate Exceptions for All Packages

Adding all packages to exceptions is not recommended. Only do this for specific use cases like baseline establishment.

vet query --from /path/to/dump \
    --exceptions-generate /path/to/exceptions.yml \
    --exceptions-filter 'true' \
    --exceptions-till '2025-12-12'

--exceptions-till is parsed as YYYY-mm-dd and generates a timestamp of 00:00:00 UTC for the specified date in RFC3339 format.

Using Exceptions

With vet-action (GitHub Actions)

vet-action supports custom exceptions configuration:

1

Create Exceptions File

Create .github/vet/exceptions.yml in your repository with your exceptions configuration

2

Update Workflow

Update your GitHub Actions workflow to include the exceptions file:

- name: Vet Scan
  uses: safedep/vet-action@v1
  with:
    exception-file: .github/vet/exceptions.yml

With vet CLI

Pass an exceptions file as a global flag to vet:

vet --exceptions /path/to/exceptions.yml scan -D /path/to/repo

Exception Behavior

Matching Rules

Advanced Exception Patterns

Environment-Specific Exceptions

Create different exception files for different environments:

# exceptions-dev.yml
description: Development environment exceptions
exceptions:
  - ecosystem: npm
    expires: "2025-12-31T00:00:00Z"
    id: dev-001
    name: 'webpack-dev-server'
    version: '*'
    reason: "Development dependency with known issues"

# exceptions-prod.yml
description: Production environment exceptions
exceptions:
  - ecosystem: npm
    expires: "2025-03-01T00:00:00Z"
    id: prod-001
    name: 'legacy-auth-lib'
    version: '1.2.3'
    reason: "Critical dependency being replaced in Q1"

Conditional Exception Generation

Generate exceptions based on specific criteria:

# Only low and medium severity issues
vet query --from /path/to/dump \
    --exceptions-generate exceptions-low-medium.yml \
    --exceptions-filter 'vulns.critical.size() == 0 && vulns.high.size() == 0' \
    --exceptions-till '2025-06-01'

# Packages with good maintenance scores
vet query --from /path/to/dump \
    --exceptions-generate exceptions-maintained.yml \
    --exceptions-filter 'scorecard.scores.Maintained > 7' \
    --exceptions-till '2025-08-01'

CI/CD Integration

GitHub Actions Example

name: Security Scan with Exceptions
on: [push, pull_request]

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

      - name: Run security scan
        uses: safedep/vet-action@v1
        with:
          exception-file: '.github/vet/exceptions.yml'

      - name: Check for expired exceptions
        run: |
          # Custom script to check for exceptions expiring soon
          python scripts/check-exception-expiry.py .github/vet/exceptions.yml

Best Practices

Anti-Patterns to Avoid

The following patterns will NOT be implemented to prevent security risks:

  • Manifest-level exceptions: Would cause false negatives across entire manifests
  • Permanent exceptions: All exceptions must have expiry dates
  • Blanket exceptions: Avoid using * wildcards without specific justification

Any security scanning tool may produce false positives, issues that are acceptable for a period of time, or issues that need to be temporarily ignored. vet supports adding packages to an exceptions list, excluding them from scan results and reports.

Package exceptions must be handled with care. Any package added to the exceptions list will not be scanned and reported, including any future issues that may arise. To mitigate this risk, all exceptions must have an expiration date and cannot be permanent.

Exception Use Cases

False Positives

Suppress known false positive vulnerability reports

Accepted Risk

Temporarily accept specific risks during remediation planning

Legacy Dependencies

Provide time-bound exceptions for legacy systems being migrated

Testing Dependencies

Exclude test-only dependencies from production security policies

Generating Exceptions List

Manual Creation

Create an exceptions.yml file with the following structure:

description: Exceptions File for vet
exceptions:
  - ecosystem: npm
    expires: "2025-05-10T00:00:00Z"
    id: 01JKMC07KAGJYEDZX1XPAC3SKP
    name: '@babel/plugin-transform-function-name'
    version: 7.18.9
    reason: "False positive - CVE doesn't apply to our usage"

  - ecosystem: npm
    expires: "2025-05-10T00:00:00Z"
    id: 01JKMC07KASSGYH1PHQY09QNZ3
    name: '@babel/plugin-proposal-object-rest-spread'
    version: 7.12.1
    reason: "Legacy dependency being replaced in Q2 2025"
  • The expires field is mandatory and must be in RFC3339 format
  • The id field must be unique and can be any unique string format
  • Adding a reason field is recommended for documentation

Automated Generation with vet

Generate exceptions automatically based on filter criteria:

1

Scan and Dump Data

Run a scan and dump raw data to a temporary directory:

vet scan -D /path/to/repo --json-dump-dir /path/to/dump
2

Generate Conditional Exceptions

Create exceptions for packages without critical or high severity issues:

vet query --from /path/to/dump \
    --exceptions-generate /path/to/exceptions.yml \
    --exceptions-filter '!vulns.critical.exists(p, true) && !vulns.high.exists(p, true)' \
    --exceptions-till '2025-05-01'
3

Review and Refine

Review the generated exceptions file and remove unnecessary entries

Generate Exceptions for All Packages

Adding all packages to exceptions is not recommended. Only do this for specific use cases like baseline establishment.

vet query --from /path/to/dump \
    --exceptions-generate /path/to/exceptions.yml \
    --exceptions-filter 'true' \
    --exceptions-till '2025-12-12'

--exceptions-till is parsed as YYYY-mm-dd and generates a timestamp of 00:00:00 UTC for the specified date in RFC3339 format.

Using Exceptions

With vet-action (GitHub Actions)

vet-action supports custom exceptions configuration:

1

Create Exceptions File

Create .github/vet/exceptions.yml in your repository with your exceptions configuration

2

Update Workflow

Update your GitHub Actions workflow to include the exceptions file:

- name: Vet Scan
  uses: safedep/vet-action@v1
  with:
    exception-file: .github/vet/exceptions.yml

With vet CLI

Pass an exceptions file as a global flag to vet:

vet --exceptions /path/to/exceptions.yml scan -D /path/to/repo

Exception Behavior

Matching Rules

Advanced Exception Patterns

Environment-Specific Exceptions

Create different exception files for different environments:

# exceptions-dev.yml
description: Development environment exceptions
exceptions:
  - ecosystem: npm
    expires: "2025-12-31T00:00:00Z"
    id: dev-001
    name: 'webpack-dev-server'
    version: '*'
    reason: "Development dependency with known issues"

# exceptions-prod.yml
description: Production environment exceptions
exceptions:
  - ecosystem: npm
    expires: "2025-03-01T00:00:00Z"
    id: prod-001
    name: 'legacy-auth-lib'
    version: '1.2.3'
    reason: "Critical dependency being replaced in Q1"

Conditional Exception Generation

Generate exceptions based on specific criteria:

# Only low and medium severity issues
vet query --from /path/to/dump \
    --exceptions-generate exceptions-low-medium.yml \
    --exceptions-filter 'vulns.critical.size() == 0 && vulns.high.size() == 0' \
    --exceptions-till '2025-06-01'

# Packages with good maintenance scores
vet query --from /path/to/dump \
    --exceptions-generate exceptions-maintained.yml \
    --exceptions-filter 'scorecard.scores.Maintained > 7' \
    --exceptions-till '2025-08-01'

CI/CD Integration

GitHub Actions Example

name: Security Scan with Exceptions
on: [push, pull_request]

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

      - name: Run security scan
        uses: safedep/vet-action@v1
        with:
          exception-file: '.github/vet/exceptions.yml'

      - name: Check for expired exceptions
        run: |
          # Custom script to check for exceptions expiring soon
          python scripts/check-exception-expiry.py .github/vet/exceptions.yml

Best Practices

Anti-Patterns to Avoid

The following patterns will NOT be implemented to prevent security risks:

  • Manifest-level exceptions: Would cause false negatives across entire manifests
  • Permanent exceptions: All exceptions must have expiry dates
  • Blanket exceptions: Avoid using * wildcards without specific justification