β Vet - Exceptions Management
Any security scanning tool may produce
- False positive
- Issues that are acceptable for a period of time
- Issues that are ignored permanently
To support exceptions, we introduce the exception model defined in exception spec
Use-caseβ
As a user of vet
tool, I want to add all existing packages or package versions as exceptions
to make the scanner and filter analyses to ignore them while reporting issues so that I can deploy vet
as a security guardrail to prevent introducing new packages with security issues
This workflow will allow users to
- Accept the current issues as backlog to be mitigated over time
- Deploy
vet
as a security gate in CI to prevent introducing new issues
Security Risksβ
Exceptions management should handle the potential security risk of ignoring a package and its future issues. To mitigate this risk, we will ensure that issues can be ignored till an acceptable time window and not permanently.
Workflowβ
Generate Exceptions Fileβ
- Run a scan and dump raw data to a directory
vet scan -D /path/to/repo --json-dump-dir /path/to/dump
- Use
vet query
to generate exceptions for all existing packages
vet query --from /path/to/dump \
--exceptions-generate /path/to/exceptions.yml \
--exceptions-filter 'true' \ # Optional filter for packages to add
--exceptions-till '2023-12-12'
--exceptions-till
is parsed as YYYY-mm-dd
and will generate a timestamp of 00:00:00
in UTC timezone for the date in RFC3339 format
Customize Exceptions Fileβ
The generated exceptions file will add all packages, matching optional filter, into the exceptions.yml
file. This file should be reviewed and customised as required before using it.
Use Exceptions to Ignore Specific Packagesβ
An exceptions file can be passed as a global flag to vet
. It will be used for various commands such as scan
or query
.
./vet --exceptions /path/to/exceptions.yml scan -D /path/to/repo
Do not pass this flag while generating exceptions list in query workflow to avoid incorrect exception list generation
Behaviorβ
- All exceptions rules are applied only on a
Package
- All comparisons will be case-insensitive except version
- Only
version
can have a value of*
matching any version - Exceptions are globally managed and will be shared across packages
- Exempted packages will be ignored by all analysers and reporters
- First match policy for exceptions matching
Anti-patterns that will NOT be implemented
- Exceptions will not be implemented for manifests because they will cause false negatives
- Exceptions will not be created without an expiry to avoid future false negatives on the package