In Trivy 0.74, which checks does `trivy image` or `trivy fs` run by default, and how does `--scanners` change them?

## The four scanners Trivy is one binary with several **scanners**, each looking for a different kind of issue. In 0.74 the `--scanners` flag accepts four values on the artefact subcommands: | Value | Finds | On by default for image / fs / repo / rootfs / vm | |---|---|---| | `vuln` | known vulnerabilities in OS and language packages | yes | | `secret` | credentials and keys in file contents | yes | | `misconfig` | misconfigurations in IaC and Dockerfiles | no | | `license` | package and file licenses | no | So a bare `trivy image registry.example.com/shop/api:1.4` or `trivy fs .` looks for vulnerabilities **and** exposed secrets, and nothing else. ## Defaults that differ by subcommand The default is set per subcommand, not globally: - **`trivy k8s`** accepts `vuln`, `misconfig`, `secret` and `rbac`, and turns all four on by default, because a cluster scan is expected to check manifests and role bindings as well as images. - **`trivy sbom`** accepts only `vuln` and `license` and defaults to `vuln`: an SBOM lists components, not file contents, so there is nothing for a secret scanner to read. - **`trivy config`** is the misconfiguration-only subcommand; its rules belong to the misconfiguration topic. ## The flag replaces the list `--scanners` takes a comma-separated list, and whatever you pass becomes the whole list. A common surprise: 1. A team wants misconfiguration checks on its source tree and adds `--scanners misconfig`. 2. The pipeline goes quiet about vulnerabilities, because `vuln` and `secret` were dropped from the list. 3. The fix is to spell out every scanner wanted: `--scanners vuln,secret,misconfig`. The same holds in `trivy.yaml`, where the setting is `scan.scanners`. ## Image configuration is a separate switch `trivy image` can also inspect the image's **configuration** (its environment variables and build history) rather than the files in its layers. That is controlled by `--image-config-scanners`, whose allowed values are `misconfig` and `secret`, and it is off by default. A secret passed as a build-time environment variable is therefore not found by the default run, even though secret scanning of layer files is on. ## Narrowing a scan without losing it - `--pkg-types` (default `os,library`) restricts which **packages** the vulnerability scanner considers; `--scanners` restricts which **kinds of issue** are looked for. They are different axes. - Secret scanning reads file contents across the whole target, so it often dominates the run time on large images. Trivy logs a hint to try `--scanners vuln` if scanning is slow; take that trade only when another control covers secrets. - On a host, `trivy rootfs --pkg-types os --scanners vuln /` skips the full file traversal. ## Defaults at a glance | Subcommand | Allowed `--scanners` values | Default | |---|---|---| | `image`, `fs`, `repo`, `rootfs`, `vm` | `vuln`, `misconfig`, `secret`, `license` | `vuln,secret` | | `k8s` | `vuln`, `misconfig`, `secret`, `rbac` | all four | | `sbom` | `vuln`, `license` | `vuln` | ## Checking what actually ran The first lines of a run say which scanners are active: Trivy logs an INFO line such as `Vulnerability scanning is enabled` or `Secret scanning is enabled` for each one switched on. When a pipeline's report looks thin, read those lines before blaming the database or the image: - no vulnerability line means `vuln` was dropped from the list; - no secret line means someone took the speed trade described above; - a misconfiguration line with no vulnerability line beside it is the replacement surprise in action. A JSON report reflects the same choice: findings from a scanner that did not run are simply absent, which reads exactly like a clean result unless you check the flags. ## Where the detail lives What each scanner matches against, how misconfiguration and secret rules are written, and how license results are categorised are each their own topic. The operator's question here is narrower and comes up in every first pipeline review: what does this command check when nobody passed a flag, and did the flag someone added quietly switch something off?