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 anexceptions.yml
file with the following structure:
- 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:
2
Generate Conditional Exceptions
Create exceptions for packages without critical or high severity issues:
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.
--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 configuration2
Update Workflow
Update your GitHub Actions workflow to include the exceptions file:
With vet CLI
Pass an exceptions file as a global flag tovet
:
Exception Behavior
Matching Rules
Package Matching
Package Matching
- 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
Scope and Application
Scope and Application
- Exceptions are globally managed and shared across packages
- Exempted packages are ignored by all analyzers and reporters
- First match policy applies for exception matching
Expiration Handling
Expiration Handling
- 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:Conditional Exception Generation
Generate exceptions based on specific criteria:CI/CD Integration
GitHub Actions Example
Best Practices
Exception Hygiene
Exception Hygiene
- 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
Documentation
Documentation
- Maintain a change log for exceptions
- Link exceptions to tickets or remediation plans
- Include contact information for exception owners
Governance
Governance
- 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 manifests
- Permanent exceptions: All exceptions must have expiry dates
- Blanket exceptions: Avoid using
*
wildcards without specific justification