Added syft/grype plugin

[aenima-x]

@jbauernberger could you add an attachment of an example of a file? if you need feel free to change any sensitive data

and if you can an example of how you run the command, i will try to add support to use it from faraday-cli

[jbauernberger]

@aenima-x certainly :-)

grype-report-host-long.json.zip

please keep in mind that these things have been added manually using jq because they were not part of the original grype report (see my comment in the repo/grype/plugin.py):

{
  "hostname": "tinkerbell",
  "os": "Debian",
  "ip": "192.168.178.166",
...

thanks!

[jbauernberger]

the syft command generates the SBOM, e.g.: syft --output json --file syft-report.json dir:/usr/bin

the grype commands generates the vulns, e.g: cat syft-report.json |grype --output json --file grype-report.json

these could also be combined in a pipe:

syft --output json dir:/usr/bin | grype --output json --file grype-report.json

to add things like ip, hostname, os,

jq '. |= {"ip": "192.168.178.166", "os": "Debian", "hostname": "tinkershell"} + .' grype-report.json > grype-plugin-input.json

See my feature request here (hoping this can be part of the generated output so we can ditch jq): https://github.com/anchore/grype/issues/537

[aenima-x]

@jbauernberger ok know I see.

I can´t add a plugin of a tool that needs to be modified manually.

Lets wait to is if your issue in Grype gets resolved first, ok?

[aenima-x]

@jbauernberger with just ip is enough for us.

its the only required field of a host, but more info is always welcome

[aenima-x]

@jbauernberger do you know why the I have vulnerabilities with Negligible severity, but the related vulnerability has a higher severity?

[aenima-x]

I have made some modifications, can you check it out? try it as a custom plugin, I have also add support for command, you can try it like this

faraday-plugins process-command -cpf /path  "grype python:3.8-slim-buster"

grype.zip

[jbauernberger]

I did not notice until you just pointed it out. Is it a difference where GHSA is lower than the CVSS score from the CVE? See https://github.com/advisories/GHSA-896r-f27r-55mw -> here the GHSA is moderate while the CVE is critical

I'm not sure why this is actually.

[aenima-x]

I ended up using the severity in the relatedVulnerabilities

[jbauernberger]

probably safer yes. tracking this here because I'd be curious as to why https://github.community/t/why-is-the-severity-of-a-ghsa-lower-than-the-cve/217736

[aenima-x]

Well let me know if you like the changes, you can use it with faraday-cli also as a custom plugin

[jbauernberger]

it works when scanning a docker image. Nice!

Just to confirm, it no longer processes json from when grype is run with dir:/path ? (because userInput when run over a directory)

[aenima-x]

mmm sorry I dont understand.

How you run the tool?

[jbauernberger]

so this works:

faraday-plugins process-command -cpf ~/.faraday/custom_plugins "grype python:3.8-slim-buster"

also running grype --output json --file ~/python-slim-buster.json python:3.8-slim-buster can be imported into Faraday web:

However faraday-plugins process-command -cpf ~/.faraday/custom_plugins "grype dir:/usr/local/lib"

returns:

Traceback (most recent call last):
  File "/home/joachim/src/faraday_venv/bin/faraday-plugins", line 8, in <module>
    sys.exit(cli())
  File "/home/joachim/src/faraday_venv/lib/python3.9/site-packages/click/core.py", line 1128, in __call__
    return self.main(*args, **kwargs)
  File "/home/joachim/src/faraday_venv/lib/python3.9/site-packages/click/core.py", line 1053, in main
    rv = self.invoke(ctx)
  File "/home/joachim/src/faraday_venv/lib/python3.9/site-packages/click/core.py", line 1659, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/home/joachim/src/faraday_venv/lib/python3.9/site-packages/click/core.py", line 1395, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/home/joachim/src/faraday_venv/lib/python3.9/site-packages/click/core.py", line 754, in invoke
    return __callback(*args, **kwargs)
  File "/home/joachim/src/faraday_venv/lib/python3.9/site-packages/faraday_plugins/commands.py", line 142, in process_command
    plugin.processOutput(output_value)
  File "/home/joachim/src/faraday_venv/lib/python3.9/site-packages/faraday_plugins/plugins/plugin.py", line 304, in processOutput
    self._parse_filename(Path(self.get_custom_file_path()))
  File "/home/joachim/src/faraday_venv/lib/python3.9/site-packages/faraday_plugins/plugins/plugin.py", line 310, in _parse_filename
    self.parseOutputString(output.read())
  File "/home/joachim/.faraday/custom_plugins/grype/plugin.py", line 32, in parseOutputString
    host_id = self.createAndAddHost(grype_json["source"]["target"]["userInput"])
TypeError: string indices must be integers

same error when I try to upload a report into faraday web which was created with: grype --output json --file some-report.json dir:/usr/local/lib

[aenima-x]

ok the problem is the "dir:/usr/local/lib" the output is diferent.

Y will have to try all this variants

    grype docker:yourrepo/yourimage:tag          explicitly use the Docker daemon
    grype docker-archive:path/to/yourimage.tar   use a tarball from disk for archives created from "docker save"
    grype oci-archive:path/to/yourimage.tar      use a tarball from disk for OCI archives (from Podman or otherwise)
    grype oci-dir:path/to/yourimage              read directly from a path on disk for OCI layout directories (from Skopeo or otherwise)
    grype dir:path/to/yourproject                read directly from a path on disk (any directory)
    grype sbom:path/to/syft.json                 read Syft JSON from path on disk
    grype registry:yourrepo/yourimage:tag        pull image directly from a registry (no container runtime required)

[jbauernberger]

some output examples below :)

grype docker:yourrepo/yourimage:tag          explicitly use the Docker daemon

docker-grype.json.zip

grype docker-archive:path/to/yourimage.tar   use a tarball from disk for archives created from "docker save"

grype-docker-archive.json.zip

grype oci-archive:path/to/yourimage.tar      use a tarball from disk for OCI archives (from Podman or otherwise)

grype-oci-archive.json.zip

grype oci-dir:path/to/yourimage              read directly from a path on disk for OCI layout directories (from Skopeo or otherwise)

grype-oci-dir.json.zip

grype dir:path/to/yourproject                read directly from a path on disk (any directory)

The dir:/foo we've already tested :)

grype sbom:path/to/syft.json                 read Syft JSON from path on disk

The sbom:/foo format is same as what we already had, it's just a quicker way of processing the grype output if the SBOM has already been created (using syft). Nothing new here :)

grype registry:yourrepo/yourimage:tag        pull image directly from a registry (no container runtime required)

grype-docker-registry.json.zip

[aenima-x]

@jbauernberger why do you say we already tested " grype dir:path/to/yourproject"?? I dont have that json

[aenima-x]

Can you try it now?

grype.zip

[jbauernberger]

thanks will test it. :)

my comment about dir:/path "already being tested" referred to the initial plugin implementation where we used the same json input which was only taking directory into account (no container images, etc).

grype-report-host-long.json.zip

[aenima-x]

ah ok, great

[aenima-x]

sorry I miss that json file Here is a new version grype.zip

[jbauernberger]

perfect! your last version works with all the input json files (including when grype is called with dir:/path)

[aenima-x]

ok one last thing, do you think the data I'am getting from the files is ok or you think there is something missing?

[jbauernberger]

I think it's complete.

The only thing that I can think of which we could consider eventually is that once grype team implements adding arbitrary key/values into syft, then we could map the real ip and hostname respectively. But that's really just icing on the cake.

[aenima-x]

That thing I still dont understand. I dont know the app but what would be the point of that?

If you analyze an image there is no ip, I think it cant analyze a running container but in that case it the ip is the internal ip of the container I dont the the point.

Cant you explain it more?

[jbauernberger]

I think you're on point when it is containers or container images. Here there is no ip and the relevant key is actually the image.

But a user is running grype only generates reports on bare-metal grype dir:/path/to/foo then it currently maps it to a path as the key (e.g. /usr/lib etc.

This contradicts the current UI which has in the top heading "Hosts". I don't think it's an issue really except that there is a path column available:

Not a big deal though.

What would be interesting is if grype could process more than one thing at the time. Currently I can't give it docker images and different directories all in one call, generating one report. E.g. show me all vulns in /usr/bin:/usr/local/bin:/usr/lib:/usr/local/lib and also vulns from all docker images on the disk (and output one single report for all of them).

[aenima-x]

Ok that is a "limitation" of our model. A host can be anything but the UI show host and ip.

Ok, so I will release it like this for now

[jbauernberger]

yes I think it's no issue really.

much appreciate your help on all of this and truly fantastic to have this available as a core plugin in such a short period of time. you rock! thanks so much!!