Downloaded file name is `javadb.tar.gz` rather than `db.tar.gz`.
Also `--skip-update` is deprecated in favor of `--skip-db-update` and `--skip-java-db-update`.
* adding a fix for update-cache that was not applied on AWS scans.
* removing unneeded code
---------
Co-authored-by: Gio Rodriguez <giovanni.rodriguez@aquasec.com>
* Add test for filter with both duplicates and different package paths
* Add package path in key of uniqVulns map
* Add package path to the sorting logic
This commit bumps the go-dep-parser version. This revents Trivy from detecting vulnerabilities in Poetry dev-dependency, so the document is also updated.
Co-authored-by: DmitriyLewen <dmitriy.lewen@smartforce.io>
For images with single layer, the layer key was directly being used as merged cache key.
This was posing an issue of data override and any other image having the same layer could get incorrect data.
So, fixed:
1. Even for 1 layer - merged layer key hash will be calculated
2. We will not go with assumption that merged data will have only 1 pkgInfo
3. We are setting a SchemaVersion in blob being generated in ToBlobInfo
YAML files can also have the `.yml` file extension. So the helm config should take that into account.
Signed-off-by: Juan Antonio Osorio <juan.osoriorobles@eu.equinix.com>
While analyzing failure of the report schema validation i found URL looks like that: `https://ubuntu.com/security/notices/USN-5051-4 (regression only in trusty/esm)`. This causing gitlab to mark report as invalid. Patch provided just using first word of the url word.
* chore: add integration label and merge security label
* use the kind/security label for vulnerabilities
Co-authored-by: knqyf263 <knqyf263@gmail.com>
* fix: support for helm chart *.tar.gz
- add test to validate
Signed-off-by: Owen Rumney <owen.rumney@aquasec.com>
* fix: adding missing test tar
Signed-off-by: Owen Rumney <owen.rumney@aquasec.com>
* feat: adding helm support
- adding tests for helm analyzer
- add test for non helm tarball
- adding in-memory filesystem for helm
- handle multiple charts at a time
- check the size is smaller than arbitrary size of 200MB if a tarball
* fix(secrets): added '/' for file paths derived from image
* refactor(secrets): used input.Dir to find image scan
* test(secrets): added path to image-config.yaml
This is being mitigated in defsec as well to prevent results with no
filename getting through to fanal
Signed-off-by: Owen Rumney <owen.rumney@aquasec.com>
- rework some of the iac tests to be more flexible to change
- update the scanner to use the moved parser
- everything is now in defsec now for CF parsing, scanning and testing
* feature(iac): Add location and resource to Results
- add the iac resource and line in file information for tfsec and cfsec
- update the version of tfsec and cfsec
* Made below changes
1. To avoid confusion, changed the layer(blobinfo) size to uncompressed size
2. Added v1.configfile as return type of inspect method
Co-authored-by: Teppei Fukuda <knqyf263@gmail.com>
* Capture license information for apk packages
* changed order or license info in package struct
* Remove space replacement with comma for license info
* feat: Support Google artifact registry
This commit adds the capability to scan images from Google artifact
registry(GAR). GAR domains were earlier rejected by Trivy e.g.
europe-west3-docker.pkg.dev etc. With this change, we will treat domain
ending with 'docker.pkg.dev' as GAR domain and use gcloud sdk to fetch
credentials from provided file or credstore.
* refactor: rename GCR to Registry
Co-authored-by: knqyf263 <knqyf263@gmail.com>
* Add uncompressed layer size
This commit will help in getting uncompressed layer sizes. Can sum up these layer sizes to get the actual image size
* Removed unnecessary exception
* refactor
Co-authored-by: knqyf263 <knqyf263@gmail.com>
* feat(GoBinary) support gobinary and add test
* update(modules) update go-dep-parser
* test(gobinary) update test
* fix(library): return nil with empty result
* test(library): add tests
* refactor: group imports
* chore: update .gitignore
* Update README.md
* refactor(gobinary): update an error
* chore(ci): bunp up Go to 1.16
Co-authored-by: knqyf263 <knqyf263@gmail.com>
* feat(config): support HCL1 files
* feat(config): support HCL2 files
* feat(hcl): add Version()
* feat(config): support HCL files
- combine HCL2.0 and HCL1.0 parsing, checking for conformation to HCL2.0
spec first
- checks for HCL1.0 conformation if content does not comply with HCL2.0
spec
- parsing returns an error only if file content does not
comply with BOTH HCL2.0 and HCL1.0
* add Type() test
Co-authored-by: knqyf263 <knqyf263@gmail.com>
* feat(config): support Dockerfile
* update namings and add Type() test
* only accepts dockerfile as ext/base name
* simplify dockerfile check
* add test case
* feat(cache): support Redis
* chore(mod): update
* feat(main): support Redis
* test: update error messages according to different errors on GitHub Actions
* feat(redis): add prefix
* fix an error
Co-authored-by: Daniel Pacak <pacak.daniel@gmail.com>
* fix an error
Co-authored-by: Daniel Pacak <pacak.daniel@gmail.com>
* fix(main): defer close
* test(redis): fix error messages
* test(redis): count current connections
Co-authored-by: Daniel Pacak <pacak.daniel@gmail.com>
* test(redis): use structs instead of string literals
Co-authored-by: Daniel Pacak <pacak.daniel@gmail.com>
Condition:- Specify an image name and tag ":" separated.
If correct image name and tag is specified ":" separated, image with given tag will be return otherwise first one will be return
* fix: Due read after write consistency in S3 missingLayers called the actual object that created cache 403 response
This change creating index file for each object so missingLayers will not hit object that not exist.
* fix comments error description
Co-authored-by: oranmoshai <oran.moshai@aquasec.com>
* test(integration): move to the test directory
* chore: update fixtures path
* test: put common test images under the test directory
* chore(Makefile): rename
* feat: support local filesystem and remote git repository [PART 1] (fanal#109)
* feat(walker): add tar/fs walker
* fs_test: Add test names
Signed-off-by: Simarpreet Singh <simar@linux.com>
* walk_test: Add Test_isIgnored
Signed-off-by: Simarpreet Singh <simar@linux.com>
* feat: support local filesystem and remote git repository [PART 2] (fanal#110)
* refactor(analyzer): merge OSAnalyzer, PkgAnalyze, LibAnalyzer into
Analyzer
* test: comment out temporarily
* fix(amazon): check the length
* fix(analyzer): make AnalysisResult a reference
* library/analyzer: Refactor library analyzer code.
Signed-off-by: Simarpreet Singh <simar@linux.com>
* feat: support local filesystem and remote git repository [PART 3] (fanal#111)
* refactor(image): move directory
* feat(applier): add applier
* fix(apk): replace extractor with applier
* test: comment out temporarily
* feat: support local filesystem and remote git repository [PART 4] (fanal#112)
* feat(artifact): add image, local and remote artifact
* image_test: Rename test field to use new convention
Signed-off-by: Simarpreet Singh <simar@linux.com>
* image_test: Add a test for put artifact failure
Signed-off-by: Simarpreet Singh <simar@linux.com>
* refactor(remote): remove unnecessary files for unit test
* feat: support local filesystem and remote git repository [PART 5] (fanal#113)
* test(integration): fix tests
* feat: support local filesystem and remote git repository [PART 6] (fanal#114)
* feat(main): add sub commands
* refactor(types): remove unused type
* chore(mod): update
* test(artifact): add mock
* fix(analyzer): redhat must be replaced with oracle
* fix(analyzer): debian must be replaced with ubuntu
* fix(fs): display dir when hostname is empty
Co-authored-by: Simarpreet Singh <simar@linux.com>
Co-authored-by: Simarpreet Singh <simar@linux.com>
* fix: make AnalysisResult a reference
Co-authored-by: Simarpreet Singh <simar@linux.com>
* refactor(walker): fix comment
Co-authored-by: Simarpreet Singh <simar@linux.com>
Co-authored-by: Simarpreet Singh <simar@linux.com>
Co-authored-by: Simarpreet Singh <simar@linux.com>
* Add S3 support for layer caching this will allow to save image results on managed persistent object store
* Working on PR comments
Co-authored-by: oranmoshai <oran.moshai@aquasec.com>
* analyzer: Send back package and apps info for unknown OS if found.
We should send back package and apps info if found even
in the case of an unknown OS. Example Dockerfile:
```
$ cat Dockerfile
FROM hello-world
ADD https://raw.githubusercontent.com/aquasecurity/trivy-ci-test/master/Cargo.lock .
```
Should say ErrUnknownOS but still scan the Cargo vulns.
Signed-off-by: Simarpreet Singh <simar@linux.com>
* fix(analyzer): send back package and apps info even if there is no package found
* fix(main): handle specific errors
Co-authored-by: knqyf263 <knqyf263@gmail.com>
* feat(image): support OCI Image Format
* refactor: rename NewDockerArchiveImage to NewArchiveImage
* test: rename TestNewDockerArchiveImage to TestNewArchiveImage
* fix: introduce go-multierror
* image: add more sad paths for tryOCI func
Signed-off-by: Simarpreet Singh <simar@linux.com>
* test(image): add more test case
Co-authored-by: Simarpreet Singh <simar@linux.com>
* feat(extractor): switch to layer ID of origin layer
* integration: update golden file for vuln-image
This file was updated during a COVID-19 crisis.
Signed-off-by: Simarpreet Singh <simar@linux.com>
* test(docker): sort applications
* test(docker): fix order
Co-authored-by: Simarpreet Singh <simar@linux.com>
* analyzer: Include layerID as part of LayerInfo
Signed-off-by: Simarpreet Singh <simar@linux.com>
* Add LayerID to Package struct
Signed-off-by: Simarpreet Singh <simar@linux.com>
* analyzer: Remove ID from returned layerInfo
Signed-off-by: Simarpreet Singh <simar@linux.com>
* analyzer: Handle missing layer.ID from cached layer
Signed-off-by: Simarpreet Singh <simar@linux.com>
* extractor/docker: Cleanup logic to avoid extra slice usage
Signed-off-by: Simarpreet Singh <simar@linux.com>
* integration: Fix golden files to include LayerID
Signed-off-by: Simarpreet Singh <simar@linux.com>
* analyzer: Remove condition for adding layer.ID
Signed-off-by: Simarpreet Singh <simar@linux.com>
* types: Introduce types.LibraryInfo
Signed-off-by: Simarpreet Singh <simar@linux.com>
* docker: Add LayerID to each LibraryInfo
Signed-off-by: Simarpreet Singh <simar@linux.com>
* .github/bench: Bump up docker version
Signed-off-by: Simarpreet Singh <simar@linux.com>
* intergration/perf: Remove other OSes for the timebeing.
Looks like Github CI is running out of space while running
other tests. Until we find a better solution we need to comment
out bigger OSes.
Signed-off-by: Simarpreet Singh <simar@linux.com>
* fix(image): call Close() via cleanup funcion
* refactor(type): add omitempty
* analyzer: Change to types.LibraryInfo in analzyer.go
Signed-off-by: Simarpreet Singh <simar@linux.com>
* wip: add CleanupDockerExtractorFn for cleanup
Signed-off-by: Simarpreet Singh <simar@linux.com>
* refactor(analyzer): remove un-needed function
* test(cache): comment in
* Revert "wip: add CleanupDockerExtractorFn for cleanup"
This reverts commit dabfae104bf6d63492823c6c3eb94175d26eabad.
* Revert ".github/bench: Bump up docker version"
This reverts commit b982c46861e1cc0851d53621c0e68ac40918d755.
* refactor(analyzer): sort imports
* test(cache): remove debug code
* test(cache): format
* chore(image): remove debug code
Co-authored-by: Teppei Fukuda <knqyf263@gmail.com>
* integration: Add a test to use fanal as a library
Signed-off-by: Simarpreet Singh <simar@linux.com>
* integration: Table driven library_tests
Signed-off-by: Simarpreet Singh <simar@linux.com>
* integration: Add even more OSes to the docker mode test
Signed-off-by: Simarpreet Singh <simar@linux.com>
* library_test: run tests in parallel
Signed-off-by: Simarpreet Singh <simar@linux.com>
* .git: Update gitignore with trivy images dir
Signed-off-by: Simarpreet Singh <simar@linux.com>
* library_test: add golden files for packages
Signed-off-by: Simarpreet Singh <simar@linux.com>
* library_test: Run all tests in parallel
Signed-off-by: Simarpreet Singh <simar@linux.com>
* library_test: Refactor check logic to run twice.
Once for no cache, once with cache.
Signed-off-by: Simarpreet Singh <simar@linux.com>
* library_test: Fix cache invocation
Signed-off-by: Simarpreet Singh <simar@linux.com>
* integration: Add a more comprehensive image for library_test
Signed-off-by: Simarpreet Singh <simar@linux.com>
* library_test: Introduce anon struct type
Signed-off-by: Simarpreet Singh <simar@linux.com>
* travis: add make test-integration
Signed-off-by: Simarpreet Singh <simar@linux.com>
* travis: Upgrade docker version
Signed-off-by: Simarpreet Singh <simar@linux.com>
* change mod genuinetools/reg to vanilla
Instead of using tomoyamachi's fork we can now use the vanilla upstream
package genuinetools/reg. This package gets better maintenance.
Also introducing new checksums for reg's children/dependecies.
Signed-off-by: Jakub Bielecki <jakub.bielecki@codilime.com>
* go mod tidy
Workaround for a deficient Ping implementation of reg package.
Ping fails on docker registries that return http 401
Authentication Required when requesting general /v2 url, but
happily allow unauthenticated pull of a specific image.
Closesaquasecurity/trivyfanal#229
Signed-off-by: Jakub Bielecki <jakub.bielecki@codilime.com>
* extract all files in target require filedirs
* use separator to string
* change dpkg file match algorithm
* use filepath.Clean
* add test for target dir files
- Adds a new analyzer error for "no packages detected"
- Package analyzers now return the common "no packages detected" error
- Returned errors from the package analyzers are checked against the
common "no packages detected" errors and filters those out. Other
errors will now be passed back to the user for debugging.
* fix genuinetools/reg module version
* merge ubuntu analyzer into debianbase analyzer
* add os analyzer tests
* add redhat base test
* add redhatbase test file
* use AnalyzeOsError
* add gitignore empty folder
* change variable name in test codes
* skip coverage check on forked project
Trivy (`tri`pronounced like **tri**gger, `vy` pronounced like en**vy**) is a comprehensive security scanner. It is reliable, fast, extremely easy to use, and it works wherever you need it.
Trivy ([pronunciation][pronunciation]) is a comprehensive and versatile security scanner.
Trivy has *scanners* that look for security issues, and *targets* where it can find those issues.
Trivy has different *scanners* that look for different security issues, and different *targets* where it can find those issues.
Targets (what Trivy can scan):
Targets:
- Container Image
- Filesystem
- Git repository (remote)
-Kubernetes cluster or resource
- Git Repository (remote)
-Virtual Machine Image
- Kubernetes
- AWS
Scanners (what Trivy can find there):
Scanners:
- OS packages and software dependencies in use (SBOM)
- Known vulnerabilities (CVEs)
- IaC misconfigurations
- IaC issues and misconfigurations
- Sensitive information and secrets
- Software licenses
Much more scanners and targets are coming up. Missing something? Let us know!
Read more in the [Trivy Documentation][docs]
To learn more, go to the [Trivy homepage][homepage] for feature highlights, or to the [Documentation site][docs] for detailed information.
## Quick Start
### Get Trivy
Get Trivy by your favorite installation method. See [installation] section in the documentation for details. For example:
Trivy is available in most common distribution channels. The full list of installation options is available in the [Installation] page. Here are a few popular examples:
-`apt-get install trivy`
-`yum install trivy`
-`brew install aquasecurity/trivy/trivy`
-`brew install trivy`
-`docker run aquasec/trivy`
- Download binary from https://github.com/aquasecurity/trivy/releases/latest/
- Download binary from <https://github.com/aquasecurity/trivy/releases/latest/>
- See [Installation] for more
Trivy is integrated with many popular platforms and applications. The complete list of integrations is available in the [Ecosystem] page. Here are a few popular examples:
There are canary builds ([Docker Hub](https://hub.docker.com/r/aquasec/trivy/tags?page=1&name=canary), [GitHub](https://github.com/aquasecurity/trivy/pkgs/container/trivy/75776514?tag=canary), [ECR](https://gallery.ecr.aws/aquasecurity/trivy#canary) images and [binaries](https://github.com/aquasecurity/trivy/actions/workflows/canary.yaml)) as generated every push to main branch.
Please be aware: canary builds might have critical bugs, it's not recommended for use in production.
Find out more in the [Trivy Documentation][docs] - [Getting Started][getting-started]
## FAQ
### How to pronounce the name "Trivy"?
## Highlights
- Comprehensive vulnerability detection
- OS packages (Alpine Linux, Red Hat Universal Base Image, Red Hat Enterprise Linux, CentOS, AlmaLinux, Rocky Linux, CBL-Mariner, Oracle Linux, Debian, Ubuntu, Amazon Linux, openSUSE Leap, SUSE Enterprise Linux, Photon OS and Distroless)
This directory contains media assets, such as the Trivy logo.
Assets under this directory are provided under the Creative Commons - BY 4.0 License. For more details, see here: <https://creativecommons.org/licenses/by/4.0/>
@@ -9,11 +9,66 @@ Thank you for taking interest in contributing to Trivy!
1. Your PR is more likely to be accepted if it includes tests (We have not historically been very strict about tests, but we would like to improve this!).
1. If your PR affects the user experience in some way, please update the README.md and the CLI help accordingly.
### Title
## Development
Install the necessary tools for development by following their respective installation instructions.
- [Go](https://go.dev/doc/install)
- [Mage](https://magefile.org/)
### Build
After making changes to the Go source code, build the project with the following command:
```shell
$ mage build
$ ./trivy -h
```
### Lint
You must pass the linter checks:
```shell
$ mage lint
```
Additionally, you need to have run `go mod tidy`, so execute the following command as well:
```shell
$ mage tidy
```
### Unit tests
Your PR must pass all the unit tests. You can test it as below.
```
$ mage test:unit
```
### Integration tests
Your PR must pass all the integration tests. You can test it as below.
```
$ mage test:integration
```
### Documentation
If you update CLI flags, you need to generate the CLI references.
The test will fail if they are not up-to-date.
```shell
$ mage docs:generate
```
You can build the documents as below and view it at http://localhost:8000.
```
$ mage docs:serve
```
## Title
It is not that strict, but we use the title conventions in this repository.
Each commit message doesn't have to follow the conventions as long as it is clear and descriptive since it will be squashed and merged.
#### Format of the title
### Format of the title
```
<type>(<scope>): <subject>
@@ -42,6 +97,7 @@ checks:
- vuln
- misconf
- secret
- license
mode:
@@ -49,7 +105,10 @@ mode:
- fs
- repo
- sbom
- k8s
- server
- aws
- vm
os:
@@ -76,6 +135,8 @@ language:
- dotnet
- java
- go
- elixir
- dart
vuln:
@@ -101,6 +162,12 @@ cli:
- cli
- flag
SBOM:
- cyclonedx
- spdx
- purl
others:
- helm
@@ -110,7 +177,7 @@ others:
The `<scope>` can be empty (e.g. if the change is a global or difficult to assign to a single component), in which case the parentheses are omitted.
#### Example titles
### Example titles
```
feat(alma): add support for AlmaLinux
@@ -131,34 +198,15 @@ chore(deps): bump go.uber.org/zap from 1.19.1 to 1.20.0
**NOTE**: please do not use `chore(deps): update fanal` and something like that if you add new features or fix bugs in Trivy-related projects.
The PR title should describe what the PR adds or fixes even though it just updates the dependency in Trivy.
### Unit tests
Your PR must pass all the unit tests. You can test it as below.
## Commits
```
$ make test
```
### Integration tests
Your PR must pass all the integration tests. You can test it as below.
```
$ make test-integration
```
### Documentation
You can build the documents as below and view it at http://localhost:8000.
```
$ make mkdocs-serve
```
## Understand where your pull request belongs
Trivy is composed of several repositories that work together:
- [Trivy](https://github.com/aquasecurity/trivy) is the client-side, user-facing, command line tool.
- [vuln-list](https://github.com/aquasecurity/vuln-list) is a vulnerabilities database, aggregated from different sources, and normalized for easy consumption. Think of this as the "server" side of the trivy command line tool. **There should be no pull requests to this repo**
- [vuln-list](https://github.com/aquasecurity/vuln-list) is a vulnerability database, aggregated from different sources, and normalized for easy consumption. Think of this as the "server" side of the trivy command line tool. **There should be no pull requests to this repo**
- [vuln-list-update](https://github.com/aquasecurity/vuln-list-update) is the code that maintains the vuln-list database.
- [trivy-db](https://github.com/aquasecurity/trivy-db) maintains the vulnerability database pulled by Trivy CLI.
- [fanal](https://github.com/aquasecurity/fanal) is a library for extracting system information from containers. It is being used by Trivy to find testable subjects in the container image.
- [go-dep-parser](https://github.com/aquasecurity/go-dep-parser) is a library for parsing lock files such as package-lock.json and Gemfile.lock.
The open source community has been hard at work developing new tools for Trivy. You can check out some of them here.
Have you created a tool that’s not listed? Add the name and description of your integration and open a pull request in the GitHub repository to get your change merged.
| [Continuous Vulnerability Testing with Trivy][semaphore-tutorial] | Tutorial on scanning code, containers, infrastructure, and Kubernetes with Semaphore CI/CD. |
| [Trivy Vulnerability Explorer][explorer] | Explore trivy vulnerability reports in your browser and create .trivyignore files interactively. Can be integrated in your CI/CD tooling with deep links. |
You have to know where to put the DB files. The following command shows the default cache directory.
```
$ ssh user@host
$ trivy -h | grep cache
--cache-dir value cache directory (default: "/home/myuser/.cache/trivy") [$TRIVY_CACHE_DIR]
```
=== "Vulnerability db"
Put the DB file in the cache directory + `/db`.
```
$ mkdir -p /home/myuser/.cache/trivy/db
$ cd /home/myuser/.cache/trivy/db
$ tar xvf /path/to/db.tar.gz -C /home/myuser/.cache/trivy/db
x trivy.db
x metadata.json
$ rm /path/to/db.tar.gz
```
Put the DB file in the cache directory + `/db`.
=== "Java index db[^1]"
Put the DB file in the cache directory + `/java-db`.
```
$ mkdir -p /home/myuser/.cache/trivy/java-db
$ cd /home/myuser/.cache/trivy/java-db
$ tar xvf /path/to/javadb.tar.gz -C /home/myuser/.cache/trivy/java-db
x trivy-java.db
x metadata.json
$ rm /path/to/javadb.tar.gz
```
In an air-gapped environment it is your responsibility to update the Trivy databases on a regular basis, so that the scanner can detect recently-identified vulnerabilities.
### Run Trivy with the specific flags.
In an air-gapped environment, you have to specify `--skip-db-update` and `--skip-java-db-update`[^1] so that Trivy doesn't attempt to download the latest database files.
In addition, if you want to scan `pom.xml` dependencies, you need to specify `--offline-scan` since Trivy tries to issue API requests for scanning Java applications by default.
```
$ mkdir -p /home/myuser/.cache/trivy/db
$ cd /home/myuser/.cache/trivy/db
$ tar xvf /path/to/db.tar.gz -C /home/myuser/.cache/trivy/db
x trivy.db
x metadata.json
$ rm /path/to/db.tar.gz
```
In an air-gapped environment it is your responsibility to update the Trivy database on a regular basis, so that the scanner can detect recently-identified vulnerabilities.
### Run Trivy with --skip-update and --offline-scan option
In an air-gapped environment, specify `--skip-update` so that Trivy doesn't attempt to download the latest database file.
In addition, if you want to scan Java dependencies such as JAR and pom.xml, you need to specify `--offline-scan` since Trivy tries to issue API requests for scanning Java applications by default.
2022-09-16T17:37:13.258+0900 INFO Vulnerability scanning is enabled
2022-09-16T17:37:13.258+0900 INFO Secret scanning is enabled
2022-09-16T17:37:13.258+0900 INFO If your scanning is slow, please try '--scanners vuln' to disable secret scanning
2022-09-16T17:37:13.258+0900 INFO Please see also https://aquasecurity.github.io/trivy/dev/docs/secret/scanning/#recommendation for faster secret detection
2022-09-16T17:37:14.827+0900 INFO Detected SBOM format: cyclonedx-json
2022-09-16T17:37:14.901+0900 INFO Found SBOM (cyclonedx) attestation in Rekor
2022-09-16T17:37:14.903+0900 INFO Detected OS: alpine
2022-09-16T17:37:14.903+0900 INFO Detecting Alpine vulnerabilities...
2022-09-16T17:37:14.907+0900 INFO Number of language-specific files: 0
2022-09-16T17:37:14.908+0900 WARN This OS version is no longer supported by the distribution: alpine 3.7.3
2022-09-16T17:37:14.908+0900 WARN The vulnerability detection may be insufficient because security updates are not provided
[Cosign](https://github.com/sigstore/cosign) supports generating and verifying [in-toto attestations](https://github.com/in-toto/attestation). This tool enables you to sign and verify SBOM attestation.
And, Trivy can take an SBOM attestation as input and scan for vulnerabilities
!!! note
In the following examples, the `cosign` command will write an attestation to a target OCI registry, so you must have permission to write.
If you want to avoid writing an OCI registry and only want to see an attestation, add the `--no-upload` option to the `cosign` command.
## Sign with a local key pair
Cosign can generate key pairs and use them for signing and verification. After you run the following command, you will get a public and private key pair. Read more about [how to generate key pairs](https://docs.sigstore.dev/cosign/key-generation).
```bash
$ cosign generate-key-pair
```
In the following example, Trivy generates an SBOM in the CycloneDX format, and then Cosign attaches an attestation of the SBOM to a container image with a local key pair.
```bash
# The cyclonedx type is supported in Cosign v1.10.0 or later.
Trivy can take an SBOM attestation as input and scan for vulnerabilities. Currently, Trivy supports CycloneDX-type attestation.
In the following example, Cosign can get an CycloneDX-type attestation and trivy scan it.
You must create CycloneDX-type attestation before trying the example.
To learn more about how to create an CycloneDX-Type attestation and attach it to an image, see the [Sign with a local key pair](#sign-with-a-local-key-pair) section.
"Description":"libfetch before 2021-07-26, as used in apk-tools, xbps, and other products, mishandles numeric strings for the FTP and HTTP protocols. The FTP passive mode implementation allows an out-of-bounds read because strtol is used to parse the relevant numbers into address bytes. It does not check if the line ends prematurely. If it does, the for-loop condition checks for the '\\0' terminator one byte too late.",
[Cosign](https://github.com/sigstore/cosign) supports generating and verifying [in-toto attestations](https://github.com/in-toto/attestation). This tool enables you to sign and verify Cosign vulnerability attestation.
!!! note
In the following examples, the `cosign` command will write an attestation to a target OCI registry, so you must have permission to write.
If you want to avoid writing an OCI registry and only want to see an attestation, add the `--no-upload` option to the `cosign` command.
### Sign with a local key pair
Cosign can generate key pairs and use them for signing and verification. After you run the following command, you will get a public and private key pair. Read more about [how to generate key pairs](https://docs.sigstore.dev/cosign/key-generation).
```bash
$ cosign generate-key-pair
```
In the following example, Trivy generates a cosign vulnerability scan record, and then Cosign attaches an attestation of it to a container image with a local key pair.
This feature might change without preserving backwards compatibility.
Trivy’s compliance flag lets you curate a specific set of checks into a report. In a typical Trivy scan, there are hundreds of different checks for many different components and configurations, but sometimes you already know which specific checks you are interested in. Often this would be an industry accepted set of checks such as CIS, or some vendor specific guideline, or your own organization policy that you want to comply with. These are all possible using the flexible compliance infrastructure that's built into Trivy. Compliance reports are defined as simple YAML documents that select checks to include in the report.
## Usage
Compliance report is currently supported in the following targets (trivy sub-commands):
-`trivy image`
-`trivy aws`
-`trivy k8s`
Add the `--compliance` flag to the command line, and set it's value to desired report.
For example: `trivy k8s cluster --compliance k8s-nsa` (see below for built-in and custom reports)
### Options
The following flags are compatible with `--compliance` flag and allows customizing it's output:
You can create your own custom compliance report. A compliance report is a simple YAML document in the following format:
```yaml
spec:
id:"k8s-myreport"# report unique identifier. this should not container spaces.
title:"My custom Kubernetes report"# report title. Any one-line title.
description:"Describe your report"# description of the report. Any text.
relatedResources :
- https://some.url# useful references. URLs only.
version:"1.0"# spec version (string)
controls:
- name:"Non-root containers"# Name for the control (appears in the report as is). Any one-line name.
description:'Check that container is not running as root'# Description (appears in the report as is). Any text.
id:"1.0"# control identifier (string)
checks:# list of existing Trivy checks that define the control
- id:AVD-KSV-0012# check ID. Must start with `AVD-` or `CVE-`
severity:"MEDIUM"# Severity for the control (note that checks severity isn't used)
- name:"Immutable container file systems"
description:'Check that container root file system is immutable'
id:"1.1"
checks:
- id:AVD-KSV-0014
severity:"LOW"
```
The check id field (`controls[].checks[].id`) is referring to existing check by it's "AVD ID". This AVD ID is easily located in the check's source code metadata header, or by browsing [Aqua vulnerability DB](https://avd.aquasec.com/), specifically in the [Misconfigurations](https://avd.aquasec.com/misconfig/) and [Vulnerabilities](https://avd.aquasec.com/nvd) sections.
Once you have a compliance spec, you can select it by file path: `trivy --compliance @</path/to/compliance.yaml>` (note the `@` indicating file path instead of report id).
In this section you can find the complete reference documentation for all of the different features and settings that Trivy has to offer.
- [Vulnerabilities][vuln]
- [Misconfigurations][misconf]
Trivy can scan four different artifacts:
- [Container Images][container]
- [Filesystem][filesystem] and [Rootfs][rootfs]
- [Git Repositories][repo]
- [Kubernetes][kubernetes]
Trivy can be run in two different modes:
- [Standalone][standalone]
- [Client/Server][client-server]
Trivy can be run as a Kubernetes Operator:
- [Kubernetes Operator][kubernetesoperator]
It is designed to be used in CI. Before pushing to a container registry or deploying your application, you can scan your local container image and other artifacts easily.
See [Integrations][integrations] for details.
## Features
- Comprehensive vulnerability detection
- [OS packages][os] (Alpine, Red Hat Universal Base Image, Red Hat Enterprise Linux, CentOS, AlmaLinux, Rocky Linux, CBL-Mariner, Oracle Linux, Debian, Ubuntu, Amazon Linux, openSUSE Leap, SUSE Enterprise Linux, Photon OS and Distroless)
- A wide variety of [built-in policies][builtin] are provided **out of the box**:
- Kubernetes
- Docker
- Terraform
- more coming soon
- Support custom policies
- Simple
- Specify only an image name, a directory containing IaC configs, or an artifact name
- See [Quick Start][quickstart]
- Fast
- The first scan will finish within 10 seconds (depending on your network). Consequent scans will finish in single seconds.
- Unlike other scanners that take long to fetch vulnerability information (~10 minutes) on the first run, and encourage you to maintain a durable vulnerability database, Trivy is stateless and requires no maintenance or preparation.
- Easy installation
-`apt-get install`, `yum install` and `brew install` is possible (See [Installation][installation])
- **No pre-requisites** such as installation of DB, libraries, etc.
- High accuracy
- **Especially Alpine Linux and RHEL/CentOS**
- Other OSes are also high
- DevSecOps
- **Suitable for CI** such as Travis CI, CircleCI, Jenkins, GitLab CI, etc.
- See [CI Example][integrations]
- Support multiple formats
- container image
- A local image in Docker Engine which is running as a daemon
- A local image in [Podman][podman] (>=2.0) which is exposing a socket
- A remote image in Docker Registry such as Docker Hub, ECR, GCR and ACR
- A tar archive stored in the `docker save` / `podman save` formatted file
- An image directory compliant with [OCI Image Format][oci]
- local filesystem and rootfs
- remote git repository
- [SBOM][sbom] (Software Bill of Materials) support
- CycloneDX
- SPDX
Please see [LICENSE][license] for Trivy licensing information.
In the following example using the template `asff.tpl`, [ASFF](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-findings-format.html) file can be generated.
| [CPU not limited] | Enforcing CPU limits prevents DoS via resource exhaustion. | Workload |
| [CPU requests not specified] | When containers have resource requests specified, the scheduler can make better decisions about which nodes to place pods on, and how to deal with resource contention. | Workload |
| [SYS_ADMIN capability added] | SYS_ADMIN gives the processes running inside the container privileges that are equivalent to root. | Workload |
| [Default capabilities not dropped] | The container should drop all default capabilities and add only those that are needed for its execution. | Workload |
| [Root file system is not read-only] | An immutable root file system prevents applications from writing to their local disk. This can limit intrusions, as attackers will not be able to tamper with the file system or write foreign executables to disk. | Workload |
| [Memory not limited] | Enforcing memory limits prevents DoS via resource exhaustion. | Workload |
| [Memory requests not specified] | When containers have memory requests specified, the scheduler can make better decisions about which nodes to place pods on, and how to deal with resource contention. | Workload |
| [hostPath volume mounted with docker.sock] | Mounting docker.sock from the host can give the container full root access to the host. | Workload |
| [Runs with low group ID] | Force the container to run with group ID > 10000 to avoid conflicts with the host’s user table. | Workload |
| [Runs with low user ID] | Force the container to run with user ID > 10000 to avoid conflicts with the host’s user table. | Workload |
| [Tiller Is Deployed] | Check if Helm Tiller component is deployed. | Workload |
| [Image tag ':latest' used] | It is best to avoid using the ':latest' image tag when deploying containers in production. Doing so makes it hard to track which version of the image is running, and hard to roll back the version. | Workload |
| [Unused capabilities should be dropped (drop any)] | Security best practices require containers to run with minimal required capabilities. | Workload |
| [hostAliases is set] | Managing /etc/hosts aliases can prevent the container engine from modifying the file after a pod’s containers have already been started. | Workload |
| [User Pods should not be placed in kube-system namespace] | ensure that User pods are not placed in kube-system namespace | Workload |
| [Protecting Pod service account tokens] | ensure that Pod specifications disable the secret token being mounted by setting automountServiceAccountToken: false | Workload |
| [Selector usage in network policies] | ensure that network policies selectors are applied to pods or namespaces to restricted ingress and egress traffic within the pod network | NetworkPolicy |
| [limit range usage] | ensure limit range policy has configure in order to limit resource usage for namespaces or nodes | LimitRange |
| [resource quota usage] | ensure resource quota policy has configure in order to limit aggregate resource usage within namespace | ResourceQuota |
| [All container images must start with the *.azurecr.io domain] | Containers should only use images from trusted registries. | Workload |
| [All container images must start with a GCR domain] | Containers should only use images from trusted GCR registries. | Workload |
| [Access to host IPC namespace] | Sharing the host’s IPC namespace allows container processes to communicate with processes on the host. | Workload |
| [Access to host network] | Sharing the host’s network namespace permits processes in the pod to communicate with processes bound to the host’s loopback adapter. | Workload |
| [Access to host PID] | Sharing the host’s PID namespace allows visibility on host processes, potentially leaking information such as environment variables and configuration. | Workload |
| [Privileged container] | Privileged containers share namespaces with the host system and do not offer any security. They should be used exclusively for system containers that require high privileges. | Workload |
| [Non-default capabilities added] | Adding NET_RAW or capabilities beyond the default set must be disallowed. | Workload |
| [hostPath volumes mounted] | HostPath volumes must be forbidden. | Workload |
| [Access to host ports] | HostPorts should be disallowed, or at minimum restricted to a known list. | Workload |
| [Default AppArmor profile not set] | A program inside the container can bypass AppArmor protection policies. | Workload |
| [SELinux custom options set] | Setting a custom SELinux user or role option should be forbidden. | Workload |
| [Non-default /proc masks set] | The default /proc masks are set up to reduce attack surface, and should be required. | Workload |
| [Unsafe sysctl options set] | Sysctls can disable security mechanisms or affect all containers on a host, and should be disallowed except for an allowed 'safe' subset. A sysctl is considered safe if it is namespaced in the container or the Pod, and it is isolated from other Pods or processes on the same Node. | Workload |
| [Non-ephemeral volume types used] | In addition to restricting HostPath volumes, usage of non-ephemeral volume types should be limited to those defined through PersistentVolumes. | Workload |
| [Process can elevate its own privileges] | A program inside the container can elevate its own privileges and run as root, which might give the program control over the container and node. | Workload |
| [Runs as root user] | 'runAsNonRoot' forces the running image to run as a non-root user to ensure least privileges. | Workload |
| [A root primary or supplementary GID set] | Containers should be forbidden from running with a root primary or supplementary GID. | Workload |
| [Default Seccomp profile not set] | The RuntimeDefault seccomp profile must be required, or allow specific additional profiles. | Workload |
[CPU not limited]: https://avd.aquasec.com/misconfig/kubernetes/ksv011/
[CPU requests not specified]: https://avd.aquasec.com/misconfig/kubernetes/ksv015/
As your organization deploys containerized workloads in Kubernetes environments, you will be faced with many
configuration choices related to images, containers, control plane, and data plane. Setting these configurations
improperly creates a high-impact security and compliance risk. DevOps, and platform owners need the ability to
continuously assess build artifacts, workloads, and infrastructure against configuration hardening standards to
remediate any violations.
trivy-operator configuration audit capabilities are purpose-built for Kubernetes environments. In particular, trivy
Operator continuously checks images, workloads, and Kubernetes infrastructure components against common configurations
security standards and generates detailed assessment reports, which are then stored in the default Kubernetes database.
Kubernetes applications and other core configuration objects, such as Ingress, NetworkPolicy and ResourceQuota resources, are evaluated against [Built-in Policies].
Additionally, application and infrastructure owners can integrate these reports into incident response workflows for
You can configure Trivy-Operator to control it's behavior and adapt it to your needs. Aspects of the operator machinery are configured using environment variables on the operator Pod, while aspects of the scanning behavior are controlled by ConfigMaps and Secrets.
# Operator Configuration
| NAME| DEFAULT| DESCRIPTION|
|---|---|---|
| `OPERATOR_NAMESPACE`| N/A| See [Install modes](#install-modes)|
| `OPERATOR_TARGET_NAMESPACES`| N/A| See [Install modes](#install-modes)|
| `OPERATOR_EXCLUDE_NAMESPACES`| N/A| A comma separated list of namespaces (or glob patterns) to be excluded from scanning in all namespaces [Install mode](#install-modes).|
| `OPERATOR_SERVICE_ACCOUNT`| `trivy-operator`| The name of the service account assigned to the operator's pod|
| `OPERATOR_LOG_DEV_MODE`| `false`| The flag to use (or not use) development mode (more human-readable output, extra stack traces and logging information, etc).|
| `OPERATOR_SCAN_JOB_TIMEOUT`| `5m`| The length of time to wait before giving up on a scan job|
| `OPERATOR_CONCURRENT_SCAN_JOBS_LIMIT`| `10`| The maximum number of scan jobs create by the operator|
| `OPERATOR_SCAN_JOB_RETRY_AFTER`| `30s`| The duration to wait before retrying a failed scan job|
| `OPERATOR_BATCH_DELETE_LIMIT`| `10`| The maximum number of config audit reports deleted by the operator when the plugin's config has changed.|
| `OPERATOR_BATCH_DELETE_DELAY`| `10s`| The duration to wait before deleting another batch of config audit reports.|
| `OPERATOR_METRICS_BIND_ADDRESS`| `:8080`| The TCP address to bind to for serving [Prometheus][prometheus] metrics. It can be set to `0` to disable the metrics serving.|
| `OPERATOR_HEALTH_PROBE_BIND_ADDRESS`| `:9090`| The TCP address to bind to for serving health probes, i.e. `/healthz/` and `/readyz/` endpoints.|
| `OPERATOR_VULNERABILITY_SCANNER_ENABLED`| `true`| The flag to enable vulnerability scanner|
| `OPERATOR_CONFIG_AUDIT_SCANNER_ENABLED`| `false`| The flag to enable configuration audit scanner|
| `OPERATOR_CONFIG_AUDIT_SCANNER_SCAN_ONLY_CURRENT_REVISIONS`| `false`| The flag to enable config audit scanner to only scan the current revision of a deployment|
| `OPERATOR_CONFIG_AUDIT_SCANNER_BUILTIN`| `true`| The flag to enable built-in configuration audit scanner|
| `OPERATOR_VULNERABILITY_SCANNER_SCAN_ONLY_CURRENT_REVISIONS`| `false`| The flag to enable vulnerability scanner to only scan the current revision of a deployment|
| `OPERATOR_VULNERABILITY_SCANNER_REPORT_TTL`| `""`| The flag to set how long a vulnerability report should exist. When a old report is deleted a new one will be created by the controller. It can be set to `""` to disabled the TTL for vulnerability scanner. |
| `OPERATOR_LEADER_ELECTION_ENABLED`| `false`| The flag to enable operator replica leader election|
| `OPERATOR_LEADER_ELECTION_ID`| `trivy-operator-lock`| The name of the resource lock for leader election|
The values of the `OPERATOR_NAMESPACE` and `OPERATOR_TARGET_NAMESPACES` determine the install mode, which in turn determines the multitenancy support of the operator.
| OwnNamespace| `operators`| `operators`| The operator can be configured to watch events in the namespace it is deployed in. |
| SingleNamespace| `operators`| `foo`| The operator can be configured to watch for events in a single namespace that the operator is not deployed in. |
| MultiNamespace| `operators`| `foo,bar,baz`| The operator can be configured to watch for events in more than one namespace. |
| AllNamespaces| `operators`| (blank string)| The operator can be configured to watch for events in all namespaces.|
## Example - configure namespaces to scan
To change the target namespace from all namespaces to the `default` namespace edit the `trivy-operator` Deployment and change the value of the `OPERATOR_TARGET_NAMESPACES` environment variable from the blank string (`""`) to the `default` value.
# Scanning configuration
| CONFIGMAP KEY| DEFAULT| DESCRIPTION|
|---|---|---|
| `vulnerabilityReports.scanner`| `Trivy`| The name of the plugin that generates vulnerability reports. Either `Trivy` or `Aqua`.|
| `vulnerabilityReports.scanJobsInSameNamespace` | `"false"`| Whether to run vulnerability scan jobs in same namespace of workload. Set `"true"` to enable.|
| `scanJob.tolerations`| N/A| JSON representation of the [tolerations] to be applied to the scanner pods so that they can run on nodes with matching taints. Example: `'[{"key":"key1", "operator":"Equal", "value":"value1", "effect":"NoSchedule"}]'`|
| `scanJob.annotations`| N/A| One-line comma-separated representation of the annotations which the user wants the scanner pods to be annotated with. Example: `foo=bar,env=stage` will annotate the scanner pods with the annotations `foo: bar` and `env: stage` |
| `scanJob.templateLabel`| N/A| One-line comma-separated representation of the template labels which the user wants the scanner pods to be labeled with. Example: `foo=bar,env=stage` will labeled the scanner pods with the labels `foo: bar` and `env: stage`|
## Example - patch ConfigMap
By default Trivy displays vulnerabilities with all severity levels (`UNKNOWN`, `LOW`, `MEDIUM`, `HIGH`, `CRITICAL`). To display only `HIGH` and `CRITICAL` vulnerabilities by patching the `trivy.severity` value in the `trivy-operator-trivy-config` ConfigMap:
```bash
kubectl patch cm trivy-operator-trivy-config -n trivy-operator \
--type merge \
-p "$(cat <<EOF
{
"data": {
"trivy.severity": "HIGH,CRITICAL"
}
}
EOF
)"
```
## Example - patch Secret
To set the GitHub token used by Trivy scanner add the `trivy.githubToken` value to the `trivy-operator-trivy-config` Secret:
You need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your
cluster. If you do not already have a cluster, you can create one by installing [minikube], [kind] or [microk8s], or you can use the following [Kubernetes playground].
You also need the Trivy-Operator to be installed in the `trivy-system` namespace, e.g. with
[kubectl](./installation/kubectl.md) or [Helm](./installation/helm.md). Let's also assume that the operator is
configured to discover built-in Kubernetes resources in all namespaces, except `kube-system` and `trivy-system`.
## Workloads Scanning
Let's create the `nginx` Deployment that we know is vulnerable:
Trivy has a native [Kubernetes Operator](operator) which continuously scans your Kubernetes cluster for security issues, and generates security reports as Kubernetes [Custom Resources](crd). It does it by watching Kubernetes for state changes and automatically triggering scans in response to changes, for example initiating a vulnerability scan when a new Pod is created.
> Trivy Operator is based on existing Aqua OSS project - [Starboard], and shares some of the design, principles and code with it. Existing content that relates to Starboard Operator might also be relevant for Trivy Operator. To learn more about the transition from Starboard from Trivy, see the [announcement discussion](starboard-announcement).
[Helm], which is a popular package manager for Kubernetes, allows installing applications from parameterized
YAML manifests called Helm [charts].
The Helm chart is available on GitHub in [https://github.com/aquasecurity/trivy-operator](https://github.com/aquasecurity/trivy-operator) under `/deploy/helm` and is also hosted in a Chart repository for your convenience under [https://aquasecurity.github.io/helm-charts/](https://aquasecurity.github.io/helm-charts/).
## Example - Chart repository
This will install the operator in the `trivy-system` namespace and configure it to scan all namespaces, except `kube-system` and `trivy-system`:
```bash
helm repo add aqua https://aquasecurity.github.io/helm-charts/
helm repo update
helm install trivy-operator aqua/trivy-operator \
--namespace trivy-system \
--create-namespace \
--set="trivy.ignoreUnfixed=true"\
--version {{ var.operator_version }}
```
## Example - Download the chart
This will install the operator in the `trivy-system` namespace and configure it to scan all namespaces, except `kube-system` and `trivy-system`:
Kubernetes Yaml deployment files are available on GitHub in [https://github.com/aquasecurity/trivy-operator](https://github.com/aquasecurity/trivy-operator) under `/deploy/static`.
## Example - Deploy from GitHub
This will install the operator in the `trivy-system` namespace and configure it to scan all namespaces, except `kube-system` and `trivy-system`:
You can configure Trivy-Operator to control it's behavior and adapt it to your needs. Aspects of the operator machinery are configured using environment variables on the operator Pod, while aspects of the scanning behavior are controlled by ConfigMaps and Secrets.
To learn more, please refer to the [Configuration](config) documentation.
## Uninstall
!!! danger
Uninstalling the operator and deleting custom resource definitions will also delete all generated security reports.
You can uninstall the operator with the following command:
The Trivy Operator installs several Kubernetes resources into your Kubernetes cluster.
Here are the common steps to check whether the operator is running correctly and to troubleshoot common issues.
So in addition to this section, you might want to check [issues](https://github.com/aquasecurity/trivy/issues), [discussion forum](https://github.com/aquasecurity/trivy/discussions), or [Slack](https://slack.aquasec.com) to see if someone from the community had similar problems before.
Also note that Trivy Operator is based on existing Aqua OSS project - [Starboard], and shares some of the design, principles and code with it. Existing content that relates to Starboard Operator might also be relevant for Trivy Operator, and Starboard's [issues](https://github.com/aquasecurity/starboard/issues), [discussion forum](https://github.com/aquasecurity/starboard/discussions), or [Slack](https://slack.aquasec.com) might also be interesting to check.
In some cases you might want to refer to [Starboard's Design documents](https://aquasecurity.github.io/starboard/latest/design/)
## Installation
Make sure that the latest version of the Trivy Operator is installed. For this, have a look at the installation [options.](./installation/helm.md)
For instance, if your are using the Helm deployment, you need to check the Helm Chart version deployed to your cluster. You can check the Helm Chart version with the following command:
```
helm list -n trivy-operator
```
## Operator Pod Not Running
The Trivy Operator will run a pod inside your cluster. If you have followed the installation guide, you will have installed the Operator to the `trivy-system`.
Make sure that the pod is in the `Running` status:
If the pod is in `Failed`, `Pending`, or `Unknown` check the events and the logs of the pod.
First, check the events, since they might be more descriptive of the problem. However, if the events do not give a clear reason why the pod cannot spin up, then you want to check the logs, which provide more detail.
If your pod is not running, try to look for errors as they can give an indication on the problem.
If there are too many logs messages, try deleting the Trivy pod and observe its behavior upon restarting. A new pod should spin up automatically after deleting the failed pod.
## ImagePullBackOff or ErrImagePull
Check the status of the Trivy Operator pod running inside of your Kubernetes cluster. If the Status is ImagePullBackOff or ErrImagePull, it means that the Operator either
* tries to access the wrong image
* cannot pull the image from the registry
Make sure that you are providing the right resources upon installing the Trivy Operator.
## CrashLoopBackOff
If your pod is in `CrashLoopBackOff`, it is likely the case that the pod cannot be scheduled on the Kubernetes node that it is trying to schedule on.
In this case, you want to investigate further whether there is an issue with the node. It could for instance be the case that the node does not have sufficient resources.
## Reconciliation Error
It could happen that the pod appears to be running normally but does not reconcile the resources inside of your Kubernetes cluster.
If this is the case, the Trivy Operator likely does not have the right configurations to access your resource.
## Operator does not Create VulnerabilityReports
VulnerabilityReports are owned and controlled by the immediate Kubernetes workload. Every VulnerabilityReport of a pod is thus, linked to a [ReplicaSet.](./index.md) In case the Trivy Operator does not create a VulnerabilityReport for your workloads, it could be that it is not monitoring the namespace that your workloads are running on.
An easy way to check this is by looking for the `ClusterRoleBinding` for the Trivy Operator:
```
kubectl get ClusterRoleBinding | grep "trivy-operator"
```
Alternatively, you could use the `kubectl-who-can` [plugin by Aqua](https://github.com/aquasecurity/kubectl-who-can):
```console
$ kubectl who-can list vulnerabilityreports
No subjects found with permissions to list vulnerabilityreports assigned through RoleBindings
system:kube-controller-manager system:kube-controller-manager User
```
If the `ClusterRoleBinding` does not exist, Trivy currently cannot monitor any namespace outside of the `trivy-system` namespace.
For instance, if you are using the [Helm Chart](./installation/helm.md), you want to make sure to set the `targetNamespace` to the namespace that you want the Operator to monitor.
You can connect Trivy to an external Trivy server by changing the default `trivy.mode` from
[`Standalone`][trivy-standalone] to [`ClientServer`][trivy-clientserver] and specifying `trivy.serverURL`.
```bash
kubectl patch cm trivy-operator-trivy-config -n trivy-operator \
--type merge \
-p "$(cat <<EOF
{
"data": {
"trivy.mode": "ClientServer",
"trivy.serverURL": "<TRIVY_SERVER_URL>"
}
}
EOF
)"
```
The Trivy server could be your own deployment, or it could be an external service. See [Trivy server][trivy-clientserver] documentation for more information.
If the server requires access token and/or custom HTTP authentication headers, you may add `trivy.serverToken` and `trivy.serverCustomHeaders` properties to the Trivy Operator secret.
| `trivy.dbRepository`| `ghcr.io/aquasecurity/trivy-db`| External OCI Registry to download the vulnerability database|
| `trivy.mode`| `Standalone`| Trivy client mode. Either `Standalone` or `ClientServer`. Depending on the active mode other settings might be applicable or required. |
| `trivy.severity`| `UNKNOWN,LOW,MEDIUM,HIGH,CRITICAL` | A comma separated list of severity levels reported by Trivy|
| `trivy.ignoreUnfixed`| N/A| Whether to show only fixed vulnerabilities in vulnerabilities reported by Trivy. Set to `"true"` to enable it.|
| `trivy.skipFiles`| N/A| A comma separated list of file paths for Trivy to skip traversal.|
| `trivy.skipDirs`| N/A| A comma separated list of directories for Trivy to skip traversal.|
| `trivy.ignoreFile`| N/A| It specifies the `.trivyignore` file which contains a list of vulnerability IDs to be ignored from vulnerabilities reported by Trivy.|
| `trivy.timeout`| `5m0s`| The duration to wait for scan completion|
| `trivy.serverURL`| N/A| The endpoint URL of the Trivy server. Required in `ClientServer` mode.|
| `trivy.serverTokenHeader`| `Trivy-Token`| The name of the HTTP header to send the authentication token to Trivy server. Only application in `ClientServer` mode when `trivy.serverToken` is specified.|
| `trivy.serverInsecure`| N/A| The Flag to enable insecure connection to the Trivy server.|
| `trivy.insecureRegistry.<id>`| N/A| The registry to which insecure connections are allowed. There can be multiple registries with different registry `<id>`.|
| `trivy.nonSslRegistry.<id>`| N/A| A registry without SSL. There can be multiple registries with different registry `<id>`.|
| `trivy.registry.mirror.<registry>` | N/A| Mirror for the registry `<registry>`, e.g. `trivy.registry.mirror.index.docker.io: mirror.io` would use `mirror.io` to get images originated from `index.docker.io` |
| `trivy.httpProxy`| N/A| The HTTP proxy used by Trivy to download the vulnerabilities database from GitHub.|
| `trivy.httpsProxy`| N/A| The HTTPS proxy used by Trivy to download the vulnerabilities database from GitHub.|
| `trivy.noProxy`| N/A| A comma separated list of IPs and domain names that are not subject to proxy settings.|
| `trivy.resources.requests.cpu`| `100m`| The minimum amount of CPU required to run Trivy scanner pod.|
| `trivy.resources.requests.memory`| `100M`| The minimum amount of memory required to run Trivy scanner pod.|
| `trivy.resources.limits.cpu`| `500m`| The maximum amount of CPU allowed to run Trivy scanner pod.|
| `trivy.resources.limits.memory`| `500M`| The maximum amount of memory allowed to run Trivy scanner pod.|
| SECRET KEY| DESCRIPTION|
|---|---|
| `trivy.githubToken`| The GitHub access token used by Trivy to download the vulnerabilities database from GitHub. Only applicable in `Standalone` mode. |
| `trivy.serverToken`| The token to authenticate Trivy client with Trivy server. Only applicable in `ClientServer` mode.|
| `trivy.serverCustomHeaders`| A comma separated list of custom HTTP headers sent by Trivy client to Trivy server. Only applicable in `ClientServer` mode.|
Trivy scans any container image for license files and offers an opinionated view on the risk associated with the license.
License are classified using the [Google License Classification][google-license-classification] -
- Forbidden
- Restricted
- Reciprocal
- Notice
- Permissive
- Unencumbered
- Unknown
!!! tip
Licenses that Trivy fails to recognize are classified as UNKNOWN.
As those licenses may be in violation, it is recommended to check those unknown licenses as well.
By default, Trivy scans licenses for packages installed by `apk`, `apt-get`, `dnf`, `npm`, `pip`, `gem`, etc.
To enable extended license scanning, you can use `--license-full`.
In addition to package licenses, Trivy scans source code files, Markdown documents, text files and `LICENSE` documents to identify license usage within the image or filesystem.
!!! note
The full license scanning is expensive. It takes a while.
Currently, the standard license scanning doesn't support filesystem and repository scanning.
@@ -36,27 +36,23 @@ A single package must contain only one policy.
!!!example
``` rego
# METADATA
# title: Deployment not allowed
# description: Deployments are not allowed because of some reasons.
# schemas:
# - input: schema["kubernetes"]
# custom:
# id: ID001
# severity: LOW
# input:
# selector:
# - type: kubernetes
package user.kubernetes.ID001
import lib.result
__rego_metadata__ := {
"id": "ID001",
"title": "Deployment not allowed",
"severity": "LOW",
"description": "Deployments are not allowed because of some reasons.",
}
__rego_input__ := {
"selector": [
{"type": "kubernetes"},
],
}
deny[res] {
input.kind == "Deployment"
msg := sprintf("Found deployment '%s' but deployments are not allowed", [input.metadata.name])
res := result.new(msg, input)
res := result.new(msg, input.kind)
}
```
@@ -65,6 +61,10 @@ If you add a new custom policy, it must be defined under a new package like `use
### Policy structure
`# METADATA` (optional)
: - SHOULD be defined for clarity since these values will be displayed in the scan results
- `custom.input` SHOULD be set to indicate the input type the policy should be applied to. See [list of available types](https://github.com/aquasecurity/defsec/blob/418759b4dc97af25f30f32e0bd365be7984003a1/pkg/types/sources.go)
`package` (required)
: - MUST follow the Rego's [specification][package]
- MUST be unique per policy
@@ -72,15 +72,6 @@ If you add a new custom policy, it must be defined under a new package like `use
- MAY include the group name such as `kubernetes` for clarity
- Group name has no effect on policy evaluation
`import data.lib.result` (optional)
: - MAY be defined if you would like to embellish your result(s) with line numbers and code highlighting
`__rego_metadata__` (optional)
: - SHOULD be defined for clarity since these values will be displayed in the scan results
`__rego_input__` (optional)
: - MAY be defined when you want to specify input format
`deny` (required)
: - SHOULD be `deny` or start with `deny_`
- Although `warn`, `warn_*`, `violation`, `violation_` also work for compatibility, `deny` is recommended as severity can be defined in `__rego_metadata__`.
@@ -112,28 +103,38 @@ Any package prefixes such as `main` and `user` are allowed.
### Metadata
Metadata helps enrich Trivy's scan results with useful information.
The annotation format is described in the [OPA documentation](https://www.openpolicyagent.org/docs/latest/annotations/).
Trivy supports extra fields in the `custom` section as described below.
!!!example
``` rego
__rego_metadata__ := {
"id": "ID001",
"title": "Deployment not allowed",
"severity": "LOW",
"description": "Deployments are not allowed because of some reasons.",
For more details on how to define schemas within Rego policies, please see the [OPA guide](https://www.openpolicyagent.org/docs/latest/schemas/#schema-annotations) that describes it in more detail.
There are a number of options for overriding values in Helm charts. When override values are passed to the Helm scanner, the values will be used during the Manifest rendering process and will become part of the scanned artifact.
@@ -11,17 +11,24 @@ Those policies are managed under [defsec repository][defsec].
| Dockerfile, Containerfile | [defsec][docker] |
| Terraform | [defsec][defsec] |
| CloudFormation | [defsec][defsec] |
| Azure ARM Template | [defsec][defsec] |
| Helm Chart | [defsec][kubernetes] |
| RBAC | [defsec][rbac] |
For suggestions or issues regarding policy content, please open an issue under the [defsec][defsec] repository.
Helm Chart scanning will resolve the chart to Kubernetes manifests then run the [kubernetes][kubernetes] checks.
Ansible scanning is coming soon.
## Policy Distribution
defsec policies are distributed as an OPA bundle on [GitHub Container Registry][ghcr] (GHCR).
When misconfiguration detection is enabled, Trivy pulls the OPA bundle from GHCR as an OCI artifact and stores it in the cache.
Those policies are then loaded into Trivy OPA engine and used for detecting misconfigurations.
If Trivy is unable to pull down newer policies, it will use the embedded set of policies as a fallback. This is also the case in air-gap environments where `--skip-policy-update` might be passed.
## Update Interval
Trivy checks for updates to OPA bundle on GHCR every 24 hours and pulls it if there are any updates.
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.