Read Syft configuration from Grype

[willyw0nka]

What would you like to be added:
Ability to read syft.yaml config file when running grype.

Why is this needed:
When scanning a directory or docker image grype uses syft to generate the sbom that will be analyzed. There are situations where syft configuration is required (anchore/syft#2266 (comment)). In these instances, it's not possible to solely run grype to generate the sbom and then identify vulnerabilities within it.

Additional context:
The current workaround is

syft . -o json | grype

[willmurphyscode]

Hi @willyw0nka! Thanks for the request.

Do you have a specific example of syft <whatever> -o json | grype doing the wrong thing, or particular config you wish was available?

Not every option in the syft config is applicable to grype. For example, syft and grype have a different set of output options, grype has configs for ignoring vulns but syft doesn't have those. Syft has config options to, for example, make network calls that download licensing information for some packages, but this information would just be thrown away during a grype scan. There might be options we can duplicate from Syft to Grype, or maybe make Grype parse a subset of Syft config, but it won't work to just point Grype at a whole Syft config without some real thought, which is why I ask which particular things are not working or configs seem to be missing.

[willyw0nka]

Hi @willmurphyscode 👋, thanks for the reply.

Asuming that ~/.config/syft/config.yaml contains the following:

java:
    use-network: true

Let's scan an example project

git clone https://github.com/idealo/spring-endpoint-exporter.git
grype spring-endpoint-exporter

The shown output is the following

 ✔ Vulnerability DB                [no update available]  
 ✔ Indexed file system                                                                                                                                                                   spring-endpoint-exporter
 ✔ Cataloged contents                                                                                                                            9552afa469acfc6021761747ae604a09890febf735b3b74a06161652d89815ca
   ├── ✔ Packages                        [23 packages]  
   └── ✔ Executables                     [0 executables]  
 ✔ Scanned for vulnerabilities     [1 vulnerability matches]  
   ├── by severity: 1 critical, 0 high, 0 medium, 0 low, 0 negligible
   └── by status:   1 fixed, 0 not-fixed, 0 ignored 
[0000]  WARN no explicit name and version provided for directory source, deriving artifact ID from the given path (which is not ideal)
NAME                     INSTALLED  FIXED-IN  TYPE          VULNERABILITY        SEVERITY 
spring-boot-starter-web             2.5.12    java-archive  GHSA-36p3-wjmg-h94x  Critical

This project appears to have a critical vulnerability 😱. The reason for this is that the spring-boot-starter-web version could not be read from pom.xml.

Let's try now to scan the same project using syft first and passing the generated SBOM to grype.

syft spring-endpoint-exporter -o json | grype

Which generates the following output

 ✔ Indexed file system                                                                                                                                                                   spring-endpoint-exporter
 ✔ Cataloged contents                                                                                                                            9552afa469acfc6021761747ae604a09890febf735b3b74a06161652d89815ca
   ├── ✔ Packages                        [23 packages]  
   └── ✔ Executables                     [0 executables]  
[0000]  WARN no explicit name and version provided for directory source, deriving artifact ID from the given path (which is not ideal)
No vulnerabilities found

Yay! No vulnerabilities found! 😄

So the enhanhement request is the following: could grype read grype config and syft config? Does this make sense?

[tgerla]

Hey @willyw0nka, thanks much for the details. We're discussing this as a team and we've learned a couple of things: we're concerned that parsing syft config by default would confuse users and cause unintended changes in behavior, but we're open to adding an option to allow grype to call syft with config parsing enabled.

Possible options:

• add a --use-my-syft-config option to turn on syft config parsing
• add a --use-this-syft-config-file to parse a specific file
• add some sort of syft config top-level section to grype configuration
• keep existing behavior: do nothing and ask people to run syft | grype

Dev note: maintenance-wise, the solution should think through minimizing changes that have to be duplicated between Syft and Grype together. One complication: if Syft config is newer than the version of Syft included in Grype, problems could occur.

[willyw0nka]

Thank you for the feedback! After considering the current situation and potential solutions, I believe sticking to the --use-this-syft-config-file option is the best course of action. This option offers the most self-descriptive behavior and minimizes potential confusion.

While it is true that this implementation could lead to issues if the syft version is newer than grype, it remains (in my opinion) the easiest option to utilize as an user.