Rename trivy config to trivy iac for clarity

[knqyf263]

Description

This issue proposes renaming trivy config to trivy iac. Initially, when trivy config was added, we anticipated scanning Wordpress configuration files and detecting configuration errors in Nginx and Ruby on Rails. This led to the belief that the term 'IaC scanning' might become confusing in the near future. However, the current situation has evolved differently: scanning for Wordpress has been exclusively added to the commercial version, and there are no immediate plans to extend support beyond Infrastructure as Code (IaC).

Given this development, the name trivy iac more accurately reflects the tool's current functionality and focus. To ensure backward compatibility and minimize disruption for existing users, the trivy config command will remain functional. It will not be prominently featured in the documentation to encourage the transition to the new trivy iac terminology but will still be available for use.

Reference

#5558

[knqyf263]

@simar7 @itaysk @DmitriyLewen @nikpivkin If we all agree on that, I'll add it to the v0.48.0 milestone and update it quickly.

[itaysk]

you raise an interesting point. my motivation to suggest the change was to disambiguate from configuring trivy, and to connect with a common term that most users are familiar with. you bring another argument, that makes sense now but I'm not sure that scanning application configuration is out of scope for Trivy. It might be that we'll add for example nginx or postgresql or wordpress configuration scanning sometime. But in my opinion even if we do that it's still ok to call it IaC scanning. So bottom line is I support this change, but wanted to just make this clarification.

[knqyf263]

It might be that we'll add for example nginx or postgresql or wordpress configuration scanning sometime.

Given the plan, I'm not sure if we want to call it IaC. People don't think they can scan Nginx with trivy iac.

I have some more ideas, but none of them look good. Please let me sort them out, andg I'd like to hear your thoughts.

1. "trivy config": Technically correct in its broad applicability to scanning various configuration files, but could be confused with a command for configuring Trivy itself.

2. "trivy iac": Currently accurate for Infrastructure as Code scanning, but expanding to middleware and applications in the future may render the term "IaC" inappropriate and potentially confusing.

3. "trivy config-file": More explicitly indicates the scanning of configuration files, but the naming might be slightly verbose.

4. "trivy infra": Could be used for a slightly broader range than IaC, yet it risks ambiguity when specifically referring to scanning configuration files.

5. Removing "trivy config": trivy repo --scanners misconfiguration could be a more versatile and less ambiguous choice, suitable for various types of configuration files, thus eliminating the need for the potentially confusing "trivy config".

[DmitriyLewen]

"trivy config-file": More explicitly indicates the scanning of configuration files, but the naming might be slightly verbose.

I'm not sure about this. We have the --config-policy flag. The user might think that this is the path to the configuration file (that was my first thought when I read this name).

rename to "trivy iac" or "trivy infra"

I think it makes sense if we don't add middleware or application support.
Otherwise we will return to this discussion.

Removing "trivy config"

We already have 2 options for scanning misocnfigurations:

• trivy fs --scanners misonfig
• trivy config

I was already wondering why we have two different ways to scan for misconfigurations.
So I think removing 1 way won't be problem.
This will also help with support of code (we will not need to track of config command)

[simar7]

Removing "trivy config"

I kinda like the simplicity of trivy <X>. It instills the belief that "Trivy can scan X".

It might be that we'll add for example nginx or postgresql or wordpress configuration scanning sometime.

Given this I also agree trivy iac might not be the right choice. If so is the case, why not just stick with trivy misconfig?

[knqyf263]

As I described here, we separately define target and scanner now, and the subcommand currently corresponds to targets (there are some exceptions like trivy server, though). trivy TARGET --scanners SCANNER means Trivy scans TARGET for SCANNER, like trivy image --scanners vuln represents Trivy scans container images for vulnerabilities.

Similarly,

• trivy config --scanners misconfig: Trivy scans config files for misconfiguration.
• trivy iac --scanners misconfig: Trivy scans IaC files for misconfiguration.

Therefore, trivy misconfig doesn't fit.

• trivy misconfig (--scanners misconfig): Trivy scans misconfiguration (for misconfiguration).

[raypettersen]

How about expanding config to something like this.
trivy --config terraform
trivy --config nginx

I'm personally not a fan of wildcards and generic terms like "iac".

[knqyf263]

Trivy currently has --misconfig-scanners. trivy --config terraform should be trivy --misconfig-scanners terraform iac ofr something like that.
#4901