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 - ecosystem : pypi expires : "2025-05-10T00:00:00Z" id : 01JKMC07KASSGYH1PHQY09QNZ3 name : 'pillow' version : '12.1.0'
The expires field is mandatory and must be in RFC3339 format
The id field must be unique and can be any unique string format
Allowed Ecosystems We currnetly allow these ecosystems: The comparison is case-insensitive , so PyPi, pypi, PyPI are all valid.
For update list, please check vet source code
EcosystemMaven = "Maven" EcosystemRubyGems = "RubyGems" EcosystemGo = "Go" EcosystemNpm = "npm" EcosystemPyPI = "PyPI" EcosystemCargo = "Cargo" EcosystemNuGet = "NuGet" EcosystemPackagist = "Packagist" EcosystemHex = "Hex" EcosystemPub = "Pub" EcosystemCyDxSBOM = "CycloneDxSbom" // These are not real ecosystems. They are containers EcosystemSpdxSBOM = "SpdxSbom" // These are not real ecosystems. They are containers EcosystemGitHubActions = "GitHubActions" EcosystemTerraform = "Terraform" EcosystemTerraformModule = "TerraformModule" EcosystemTerraformProvider = "TerraformProvider" EcosystemVSCodeExtensions = "VSCodeExtensions" EcosystemOpenVSXExtensions = "OpenVSXExtensions" EcosystemHomebrew = "Homebrew"
Automated Generation with vet Generate exceptions automatically based on filter criteria:
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
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'
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:
Create Exceptions File
Create .github/vet/exceptions.yml in your repository with your exceptions configuration
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
All exceptions rules are applied only at the package level
Comparisons are case-insensitive except for version
Version field can use * to match any version
Exceptions are globally managed and shared across packages
Exempted packages are ignored by all analyzers and reporters
First match policy applies for exception matching
Expired exceptions are automatically ignored
No exceptions can be created without an expiry date
System validates expiry dates during processing
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 : '*' # 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'
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
Set reasonable expiration dates (3-6 months maximum)
Include detailed reasons for each exception
Review exceptions monthly for relevance
Remove exceptions when issues are resolved
Maintain a change log for exceptions
Link exceptions to tickets or remediation plans
Include contact information for exception owners
Require approval for production exceptions
Implement automated expiry notifications
Regular security review of all active exceptions
Anti-Patterns to Avoid The following patterns will NOT be implemented to prevent security risks:
Manifest-level exceptions : Would cause false negatives across entire manifestsPermanent exceptions : All exceptions must have expiry datesBlanket exceptions : Avoid using * wildcards without specific justification 
