Add ability to disable specific analyzers

[adamcohen2]

As explained in this discussion, it's not currently possible to run Trivy >= 0.38.0 in an offline environment without pre-fetching the java-db.tar.gz file from ghcr.io/aquasecurity/trivy-java-db:1 which is 418MB.

This feature request is to add a --disable-jar-scan (or other appropriately named flag) to allow users to run Trivy in an offline environment without JAR scanning capabilities. Adding such a flag would avoid the requirement of fetching the 418MB java-db.tar.gz for those who don't need JAR scanning.

[candrews]

I think having the optional to disable jar scanning is great and should be added.

However, I think Trivy should caution users and make it very clear that using this option (should it be added) will result in Trivy being unable to discover and report against dependencies as one might expect.

For example, let there be an image containing log4j.jar and have Trivy scan it. Currently, Trivy will use the Java DB is discover that this jar is log4j-core 2.14.0 and therefore report the log4shell vulnerability. With this --disable-jar-scan argument, Trivy wouldn't know what log4j.jar is and therefore wouldn't report log4jshell resulting in a very important vulnerability being missed.

Airgapped environments are usually particularly sensitive to security, so it would be a shame to have users trying to meet that requirement accidentally cause Trivy's security scanning to significantly regress by use of this option.

[kangsumang]

Is the --disable-jar-scan flag available in the higher versions?

[adamcohen2]

Is the --disable-jar-scan flag available in the higher versions?

I don't see a disable-jar-scan flag in the trivy source, where is this flag defined?

[kangsumang]

Is the --disable-jar-scan flag available in the higher versions?

I don't see a disable-jar-scan flag in the trivy source, where is this flag defined?

Is there another way to skip jar scanning in trivy?

[adamcohen2]

Is the --disable-jar-scan flag available in the higher versions?

I don't see a disable-jar-scan flag in the trivy source, where is this flag defined?

Is there another way to skip jar scanning in trivy?

no, that's the point of this very feature request - to add a flag to disable jar scanning.

[knqyf263]

I think --disable-analyzer jar is better so that we can disable other analyzers in the same way. We have it internally. We can just export it.

[knqyf263]

I sorted out the proposed specification for enabling or disabling analyzers via CLI flags. Please feel free to leave comments. @aquasecurity/trivy

---

1. Command Overview

$ trivy <SUBCOMMAND> [OPTIONS...]

• <SUBCOMMAND>: A subcommand defined for different use cases. Each subcommand has its own default set of analyzers that are enabled by default as documented here.
• [OPTIONS...]: Additional options, including flags to enable or disable specific analyzers.

---

2. Default Behavior

• If the user does not specify any analyzer-related flags, all analyzers in the subcommand’s default set are enabled.
• For example, if the default set for trivy image is [foo, bar], then foo and bar are both enabled when no flags are provided.

---

3. Analyzer Flags Specification

3.1. --enable-analyzer <NAME>

• Function: Enables the analyzer specified by <NAME>.

• Multiple usage: Allowed. If you want to enable multiple analyzers, specify the flag repeatedly:

  $ trivy fs --enable-analyzer foo --enable-analyzer bar
  

  Or comma-separated

  $ trivy fs --enable-analyzer foo,bar
  

• Behavior:

  1. When the command is executed, the default set of analyzers for that subcommand is loaded first.
  2. If foo is not already in the default set, this flag adds foo to the active list of analyzers.
  3. If foo is already in the default set, specifying it again does not cause any issues (duplicate entries can be ignored internally).

3.2. --disable-analyzer <NAME>

• Function: Disables the analyzer specified by <NAME>.
• Multiple usage: Allowed. If you want to disable multiple analyzers, repeat the flag:

  $ trivy fs --disable-analyzer bar --disable-analyzer baz # or bar,baz
  

• Behavior:
  1. After the default set is loaded, <NAME> is removed from the final list of active analyzers.
  2. If <NAME> is not in the default set and has not been enabled by a prior flag, it is simply ignored.

3.3. Special Keyword --disable-analyzer all (Optional)

• Function: Using the special keyword all disables all currently active analyzers (i.e., everything in the default set plus any analyzers added so far).
• Use Case: You might want to disable all analyzers first and then selectively enable only certain ones:

  $ trivy analyze --disable-analyzer all --enable-analyzer foo --enable-analyzer bar
  

• Note: Even without this feature, a user can disable each analyzer individually. However, this flag can be more convenient depending on user needs.

---

4. Evaluation Order of Flags

The CLI determines the final list of analyzers in the following order:

1. Initial State: Load all analyzers in the default set for the selected subcommand.
2. --disable-analyzer <NAME>: Apply these flags, removing the specified analyzers from the list.
3. --enable-analyzer <NAME>: Apply these flags, adding the specified analyzers to the list.

---

5. Examples by Use Case

5.1. Use the Default Analyzers Only

# Use all default analyzers
$ trivy fs .

5.2. Add an Analyzer to the Default Set

# Enable analyzer 'x' in addition to the defaults
$ trivy fs --enable-analyzer x .

5.3. Disable Some of the Default Analyzers

# Disable analyzers 'y' and 'z' from the default set
$ trivy fs --disable-analyzer y --disable-analyzer z .

5.4. Disable All and Then Enable Specific Analyzers (Using all)

# Disable all default analyzers, then enable only 'foo' and 'bar'
$ trivy fs --disable-analyzer all --enable-analyzer foo --enable-analyzer bar .

---

6. Edge Cases and Additional Considerations

1. Disabling Non-Existent Analyzers

   • For example, if a user runs trivy fs --disable-analyzer unknown but unknown is neither in the default set nor previously enabled, the behavior can be:
     • Ignore it
     • Show a warning
     • Treat it as an error
   • Typically, showing a warning or ignoring it is considered more user-friendly.

2. Conflict between Disable and Enable

   • If the same analyzer name is specified in both --disable-analyzer and --enable-analyzer, the final state for that analyzer should be enabled (i.e., “enable” wins).
   • More aligned with --disable-analyzer all.

3. Unknown Analyzer Name in --enable-analyzer <NAME>

   • If <NAME> does not exist, decide how to handle it:
     • Show a warning or error and stop execution (to catch typos early).
   • Typically, generating an error is the most user-friendly approach, as it highlights mistakes immediately.

4. Empty Final Analyzer Set

   • If the user ends up disabling all analyzers (using all or otherwise), and none are re-enabled, it may not make sense for the tool to run.
   • We can allow it, or we can show a warning/error in this scenario.

5. Listing Default Analyzers for Each Subcommand

   • Optionally, provide a --list-analyzers flag to show all available analyzers.
   • Still discussing here

---

7. Summary of the Specification

1. Default Set

   • Each subcommand (e.g., image, fs) has its own default set of analyzers.

2. Analyzer Modification Flags

   • --enable-analyzer <NAME>: Enable one or more analyzers (can be specified multiple times).
   • --disable-analyzer <NAME>: Disable one or more analyzers (can be specified multiple times).
   • --disable-analyzer all: Disable all analyzers at once.

3. Final Analyzer Set Determination

   1. Load the default set for the subcommand.
   2. Apply all --disable-analyzer flags.
   3. Apply all --enable-analyzer flags.

4. Usage Examples

   • Default only: trivy fs .
   • Partially add: trivy fs --enable-analyzer x .
   • Partially disable: trivy fs --disable-analyzer y .
   • Disable everything, then selectively enable: trivy fs --disable-analyzer all --enable-analyzer x,y .

5. Error Handling / Warnings

   • Decide how to handle unknown or duplicate analyzers. Typically, “unknown analyzer = error” is recommended.

6. Advantages

   • Easy to use defaults when no flags are specified.
   • Flexible; allows partial modifications rather than full overrides.
   • --disable-analyzer all makes it easy to reconfigure the set of analyzers drastically.

[itaysk]

sounds good, I would add the effective analyzers to as a log/debug message. Also, I don't believe we document the default analyzers set right now, so we should

[nikpivkin]

It looks great! And it's easily solved with sets.

How will this be resolved with the misconfig-scanners and image-config-scanners flags? Will they be prioritized and/or declared deprecated?

[DmitriyLewen]

Sounds great and justified. This functionality has been coming for a long time.

Another point that needs to be worked out (I think it will be enough to write about it in the docs) is "paired" analyzers (e.g., Ubuntu and ESM, dpkg and Copyright). It will be necessary to write that one may not work without the second.

[knqyf263]

--misconfig-scanners

Currently, there are two approaches in my mind

1. Alias to --enable-analyzer and --disable-analyzer
   For example, using --misconfig-scanners cloudformation would effectively be an alias for disabling a set of analyzers and enabling the terraform analyzer (== --disable-analyzer azure-arm,dockerfile,helm,kubernetes,terraform,terraformplan-json,terraformplan-snapshot --enable-analyzer terraform). This approach would allow mixing flags—so specifying something like --misconfig-scanners cloudformation --enable-analyzer terraform would also be acceptable.

2. Deprecation:
   Alternatively, we could deprecate --misconfig-scanners and encourage users to transition fully to using --enable-analyzer and --disable-analyzer.

@simar7 @nikpivkin What do you think?

A similar alias concept could apply to flags like --pkg-types, which define a set of analyzers.

--scanners and --image-config-scanners

Now, for --image-config-scanners (and similarly for --scanners), the same discussion applies. Internally, the --scanners flag is used to specify a set of analyzers. For instance, --scanners misconfig is effectively the same as running --disable-analyzer all --enable-analyzer azure-arm,cloudformation,dockerfile,helm,kubernetes,terraform,terraformplan-json,terraformplan-snapshot.

However, if we treat it purely as an alias, there are challenges in ensuring consistency between scanners and analyzers. Since several parts of the codebase check if a particular scanner is enabled (example), it becomes difficult to maintain alignment with analyzers. Therefore, the preferred approach is to prioritize the scanner flag. This means that an error should be raised if there’s an attempt to enable an analyzer that does not belong to the subset defined by the scanner flag. For example:

• --scanners vuln --disable-analyzer npm would be allowed.
• But --scanners misconfig --enable-analyzer npm (or --scanners vuln --enable-analyzer terraform) would trigger an error, because the specified analyzer does not belong to the scanner’s group.

While this approach might make the implementation a bit more complex, it is considered cleaner than allowing analyzers that are inconsistent with the defined scanner subset.

Please feel free to provide any feedback if anything has been overlooked.

[simar7]

--misconfig-scanners

Currently, there are two approaches in my mind

1. Alias to --enable-analyzer and --disable-analyzer For example, using --misconfig-scanners cloudformation would effectively be an alias for disabling a set of analyzers and enabling the terraform analyzer (== --disable-analyzer azure-arm,dockerfile,helm,kubernetes,terraform,terraformplan-json,terraformplan-snapshot --enable-analyzer terraform). This approach would allow mixing flags—so specifying something like --misconfig-scanners cloudformation --enable-analyzer terraform would also be acceptable.
2. Deprecation: Alternatively, we could deprecate --misconfig-scanners and encourage users to transition fully to using --enable-analyzer and --disable-analyzer.

@simar7 @nikpivkin What do you think?

I think we can deprecate --misconfig-scanners. As for our usual deprecation process:

1. We alias first (for a few releases) & show deprecation notice in logs.
2. Announce on GitHub about the deprecation as a discussion
3. Eventually remove the flag.

A similar alias concept could apply to flags like --pkg-types, which define a set of analyzers.

--scanners and --image-config-scanners

Now, for --image-config-scanners (and similarly for --scanners), the same discussion applies. Internally, the --scanners flag is used to specify a set of analyzers. For instance, --scanners misconfig is effectively the same as running --disable-analyzer all --enable-analyzer azure-arm,cloudformation,dockerfile,helm,kubernetes,terraform,terraformplan-json,terraformplan-snapshot.

However, if we treat it purely as an alias, there are challenges in ensuring consistency between scanners and analyzers. Since several parts of the codebase check if a particular scanner is enabled (example), it becomes difficult to maintain alignment with analyzers. Therefore, the preferred approach is to prioritize the scanner flag. This means that an error should be raised if there’s an attempt to enable an analyzer that does not belong to the subset defined by the scanner flag. For example:

• --scanners vuln --disable-analyzer npm would be allowed.
• But --scanners misconfig --enable-analyzer npm (or --scanners vuln --enable-analyzer terraform) would trigger an error, because the specified analyzer does not belong to the scanner’s group.

While this approach might make the implementation a bit more complex, it is considered cleaner than allowing analyzers that are inconsistent with the defined scanner subset.

Please feel free to provide any feedback if anything has been overlooked.

Can we simply use --enable-analyzer and --disable-analyzer and use the union of these two sets to determine what scanners we need to enable? I think it should suffice. If it does, I don't see much point in keeping --scanners and --image-config-scanners WDYT?

[wyardley]

I like --enable-foo and --disable-foo, but could also consider --enable-foo and --no-enable-foo, which is also a pretty common pattern for CLI flags.

[DmitriyLewen]

Can we simply use --enable-analyzer and --disable-analyzer and use the union of these two sets to determine what scanners we need to enable?

what if we add groups for --enable-analyzer and --disable-analyzer? As we added auto to severity-source. and "scanners" will be an alias for there groups.

I'll give an example: "--scanners misconfig --enable-analyzer npm" seems acceptable to me. But you're right - it can confuse some users. but we can do something like "--enable-analyzer misconfig --enable-analyzer npm"

but for this solution we'll need to think about how to change the current logic for scanners (because part of the logic is tied to which scanner is enabled)

[knqyf263]

Can we simply use --enable-analyzer and --disable-analyzer and use the union of these two sets to determine what scanners we need to enable? I think it should suffice. If it does, I don't see much point in keeping --scanners and --image-config-scanners WDYT?

Does this mean that --scanners will be deprecated? Or does it simply mean that using --enable-analyzer and --scanners together will result in an error? Or perhaps, when both are specified, the scanners will be automatically determined based on the enabled analyzers?

In my opinion, most users will find the --scanners flag sufficient and easy to understand. The --enable-analyzer flag is unnecessary for most users and is intended for those who need more specific customizations. Therefore, I would like to keep --scanners.

Automatically enabling the misconfig scanner when running --scanners vuln --enable-analyzer terraform could be a good idea.

[DmitriyLewen]

Does this mean that --scanners will be deprecated? Or does it simply mean that using --enable-analyzer and --scanners together will result in an error?

I also think that we need to keep the "scanners" flag I was thinking about the equivalent - e.g. --scanners vuln == --enabled-analyzers vuln.

[simar7]

Automatically enabling the misconfig scanner when running --scanners vuln --enable-analyzer terraform could be a good idea.

Actually now that you point it out, I think this may introduce an element of surprise for users as they've only specified --scanners=vuln but the misconfig scanner was also turned on because of passing in --enable-analyzer=terraform.

Based on that I agree we should keep --scanners. We can drop --misconfig-scanners and --image-config-scanners.

So finally we would have:

--scanners: vuln,misconfig,secret,license

--enable/disable-analyzers: <many options>

This could work but a small concern I have is how many possible choices the --enable/disable-analyzer= flag could have. As you mentioned we could have a --list-analyzers help flag that could print a table like the following:

Scanner	Analyzer
misconfig	terraform
misconfig	cloudformation
vuln	npm
secret	aws
secret	gitlab

As for usage, we could keep it simple prioritize --scanners= first. So in the case when a scanner is not specified but an analyzer that uses that particular scanner is specified, we simply ignore that scanner. An example of this could be the one we previously discussed (--scanners vuln --enable-analyzer terraform ).

A possible user improvement to the above could be that we log a WARN message for the use to know that we will not be running that analyzer unless they pass in the corresponding scanner to go along with it.

[DmitriyLewen]

I think this may introduce an element of surprise for users as they've only specified --scanners=vuln but the misconfig scanner was also turned on because of passing in --enable-analyzer=terraform.

but to me it seems logical. this is the case when you want to analyze vulnerabilities in dir/repo, and you also know that you have terraform config and you also need to check it.

but I don't like the mandatory inclusion of the scanner. In fact, now enabling scanner means enabling set of analyzers. If we ask user to enable the scanner in addition to enabled analyzer, this can be confusing (the user will wonder which analyzers are actually enabled)