Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: add Bitnami as new provider #512

Open
wants to merge 5 commits into
base: main
Choose a base branch
from

Conversation

juan131
Copy link
Contributor

@juan131 juan131 commented Mar 12, 2024

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.

@willmurphyscode
Copy link
Contributor

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.

@juan131
Copy link
Contributor Author

juan131 commented May 23, 2024

@willmurphyscode I addressed all the linter warns reported by poetry run make lint-fix but the static analysis is failing and I'm not 100% sure the reason since it's complaining about pieces of code that are copy-pasted from other providers

@carrodher
Copy link

Hi @wagoodman @willmurphyscode, is there anything we can help with at this time?

@willmurphyscode
Copy link
Contributor

Hi @carrodher and @juan131! Thanks for the PR!

is there anything we can help with at this time?

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.

@juan131
Copy link
Contributor Author

juan131 commented Jul 15, 2024

Hi @willmurphyscode

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:

@willmurphyscode
Copy link
Contributor

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": {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@willmurphyscode
Copy link
Contributor

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!

@juan131
Copy link
Contributor Author

juan131 commented Jul 30, 2024

Hi @willmurphyscode

Thanks for looking into this.

the tools need detect the Bitnami packages and encode them in the SBOM

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 .spdx files included by Bitnami in the filesystem & recognize them. Maybe I'm missing sth.

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).

@willmurphyscode
Copy link
Contributor

@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.

@carrodher
Copy link

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Stalled
Development

Successfully merging this pull request may close these issues.

3 participants