Spurious warnings - unknown relationship type: evident-by form-lib=syft

[durera]

What happened:

[0000]  INFO syft version: 0.78.0
[0018]  INFO identified distro: Red Hat Enterprise Linux 8.7 (Ootpa)
[0018]  INFO cataloging image

...

[0000]  INFO grype version: 0.61.0
[0000]  INFO downloading new vulnerability DB
[0000]  WARN unknown relationship type: evident-by form-lib=syft
[0000]  WARN unknown relationship type: evident-by form-lib=syft
[0000]  WARN unknown relationship type: evident-by form-lib=syft
[0000]  WARN unknown relationship type: evident-by form-lib=syft
[0000]  WARN unknown relationship type: evident-by form-lib=syft
[0000]  WARN unknown relationship type: evident-by form-lib=syft
[0000]  WARN unknown relationship type: evident-by form-lib=syft
[0000]  WARN unknown relationship type: evident-by form-lib=syft
[0000]  WARN unknown relationship type: evident-by form-lib=syft
[0000]  WARN unknown relationship type: evident-by form-lib=syft
[0000]  WARN unknown relationship type: evident-by form-lib=syft
[0000]  WARN unknown relationship type: evident-by form-lib=syft

<That warning is repeated 500+ times>

[0004]  INFO downloaded new vulnerability DB version=5 built="2023-04-20 01:32:16 +0000 UTC"

What you expected to happen:
When we lock the versions to syft v0.76.0 and grype v0.60.0 (ie 3 weeks ago releases), it's back to normal expected behaviour. I'm not sure if this is the most recent version that isn't afflicted by this, but it's the one we settled on.

[0000]  INFO syft version: 0.76.0
[0000]  INFO new version of syft is available: 0.78.0 (current version is 0.76.0)
[0016]  INFO identified distro: Red Hat Enterprise Linux 8.7 (Ootpa)
[0016]  INFO cataloging image

...

[0000]  INFO grype version: 0.60.0
[0000]  INFO new version of grype is available: 0.61.0 (currently running: 0.60.0)
[0000]  INFO downloading new vulnerability DB
[0004]  INFO downloaded new vulnerability DB version=5 built="2023-04-20 01:32:16 +0000 UTC"

How to reproduce it (as minimally and precisely as possible):
Not sure, as I don't understand what the warning is warning me about to be honest, sorry.

Anything else we need to know?: I think the log extract covers it.

Environment:

• Output of grype version: syft 0.78.0 + grype 0.61.0
• OS (e.g: cat /etc/os-release or similar): Travis VM (Focal)

Operating System Details
Distributor ID:	Ubuntu
Description:	Ubuntu 20.04.5 LTS
Release:	20.04
Codename:	focal

[westonsteimel]

This is because there is a new relationship type in the latest released version of syft that the latest released version of grype doesn't understand yet. It should go away once the next version of grype is released since it is bumped to used syft v0.78.0. Basically the warning is meant to show that there is information being lost from the sbom since grype doesn't understand it yet.

[durera]

Thanks, is there an easy way to say "use the latest version of grype and the latest version of syft that it's compatible with" when we run the syft and grype installs? We have just been installing the latest of both and working on the assumption that the releases are co-ordinated and latest grype plays nice with latest syft.

[tgerla]

Hi @durera, today we don't have an easy way to download the exact Syft version that matches the Grype you're using. You can identify what version of Syft a particular Grype release is using by running grype version. As an aside, this particular warning message doesn't affect vulnerability matching and it can be safely ignored. We're going to reduce the log message priority so things like this won't spam you like this in the future.

@anchore/tools: let's discuss adding some automation to our release process to bump the main version of Syft in Grype before we cut Syft releases to try to keep them more in sync for cases like this.

[willmurphyscode]

We can put a more general warning initially: When syft starts parsing an SBOM, it can check the JSON schema version that is written in the SBOM, and log a warning if that version is later than the version of the parser that is running. I plan to make this as a separate PR after the one that deduplicates the particular log lines that are spammed here.