feat: add Bitnami as new provider #512
Conversation
Signed-off-by: juan131 <[email protected]>
|
Hi @juan131, sorry that this has sat for a while. I'll see about getting some of this static analysis and unit tests passing today and see if some of us can take a look soon at getting this reviewed and merged. |
Signed-off-by: juan131 <[email protected]>
Signed-off-by: juan131 <[email protected]>
Signed-off-by: juan131 <[email protected]>
|
@willmurphyscode I addressed all the linter warns reported by |
|
Hi @wagoodman @willmurphyscode, is there anything we can help with at this time? |
|
Hi @carrodher and @juan131! Thanks for the PR!
Do you have an image or Dockerfile that you'd expect to exhibit vulnerabilities pulled in from this feed? The best end-to-end test here would be to find/make an image that has vulnerabilities reported by the new feed, and then bake a new grype database from this branch and make sure that when grype uses the new database, it finds the new vulnerability. We are happy to do some of the boring stuff (like making linters pass) but it would be super helpful if you all could find/make an image or Dockerfile for us to use in an end-to-end test. |
|
Every Bitnami container image contains one or multiple SPDX files containing the containers BOM. The vulnerabilities associated to the packages listed on these SPDX files can be found in the Bitnami Vulnerability Database. This is explained in the link below: |
|
After going some more looking, it seems like this is blocked on getting anchore/grype-db#217 merged, and adding a transformer for the new OSV schema. (Without that work, we can't make a grype database that includes the Bitnami data, so we can't run an end-to-end test, so we can't know that this PR is really working.) After that, we can build a test image to add end to end tests to this PR, clean up linting, and then get this merged. I'm going to take a look at anchore/grype-db#217 first. |
| link = vuln_entry["references"][0] | ||
|
|
||
| return vuln_id, { | ||
| "Vulnerability": { |
There was a problem hiding this comment.
I think we want the second return value here to conform to the OSV schema.
I'm simplifying a bit, but second element of the returned tuple will be JSON-serialized and eventually picked up by the anchore/grype-db#217 (and some follow up work) and transformed into the Grype-specific vulnerability schema that Grype matches on.
This dict seems to imitate the shape of some dictionaries returned by other parsers, which looks right, but in this case I think we want a real OSV record.
I'm going to try to do some refactoring to make it more obvious what things parser.get() should return.
|
So I was wrong about anchore/grype-db#217 being the first step. I think the first step is really anchore/syft#3065. In other words, the tools need detect the Bitnami packages and encode them in the SBOM in a consistent way before we can match vulnerabilities against them. I'm sorry to hold this up further, but I think the right next step is to figure out answer to the couple of design questions raised in anchore/syft#3065. Thanks for your patience! |
|
Thanks for looking into this.
Why is this step required? I mean, Bitnami is already doing this job and ensuring every package is properly described in the SPDX files. AFAIK, the tools should only have capabilities to detect the Regarding the concern you mentioned at anchore/syft#3065 about duplicates, a mechanism to detect and remove them should be included (e.g. based on the pURL). |
|
@juan131 the reason for the Syft change is that, by default, the SBOM cataloger is off (that is, Syft doesn't incorporate SBOMs it finds in images into the SBOM it produces by default. It used to, but we found this confused people). But I think when we're scanning a Bitnami image, we want to respect the SPDX SBOM we find and raise up those packages. We can discuss details over at anchore/syft#3065. |
|
Hi @willmurphyscode, I hope you’re doing well! We wanted to check in on the status of our recent contributions. We have some open PRs, and we’re unsure about the current progress or the next steps. Could you kindly provide an update? It would help us plan our work and understand how we can continue contributing effectively. Here are a couple of the open PRs for reference: We appreciate any details you can share. Thanks in advance for your help! |
Summary
As described at anchore/grype#1609, Bitnami is providing vulnerability matching data for their containers via the Bitnami Vulnerability Database repository.
This PR follows up #447 adding support for this new provider. This database is imported by cloning the Bitnami Vulnerability Database repository and loading/normalizing all the data from it.