Question: Custom Vulnerability Sources CSAF

[jurassicLizard]

What would you like to be added:
is there a way to incorporate custom vulnerability providers other than the public ones ? Is the application capable of accepting Datafeeds using standardized formats (like CSAF_VEX,) from other custom sources not in the grype db providers list ? For example Redhat Security Feeds use CSAF. Is there not a built in way of adding such "custom vulnerability sources" using the CSAF format without having to incorporate code modifications ? I havenot delved deep into the code and therefore I have very little information about whether this is possible without a hassle.

Why is this needed:
In some use cases it might be necessary to check against internal vulnerability sources that are not public. this would be similar to adding "custom vulnerabilities" in other tools.

Additional context:
N/A

[popey]

Hi @jurassicLizard - thanks for the question.

For the specific question of RHEL CSAF format support, I think perhaps issue 323 in vunnel may be what you're looking for?

Regarding the wider question, I don't think we can easily add a generic CSAF (or other) security feed without a bit of work in vunnel, grype-db and grype. We want to make this easier to contribute to, and may indeed focus some attention on that next year, once the Grype DB v6 schema work is complete.

But it would certainly be good to keep the conversation going, to know what expectations are, and use cases beyond the Red Hat feed. Thanks again!

[jurassicLizard]

Hi @popey . That repository is a bullseye. I have just started deploying anchore and thus have very little knowledge with its inner workings. Vunnel looks like the place where this would be more suitable specifically this : Adding a new provider - vunnel -.

I will certainly have much more questions and contributions will surely follow as I work more with this beautiful piece of software. My day job involves working heavily with vulnerabilities and SBOMs and I have been writing converters for all sorts of formats back and forth in this direction in the course of my day job so would also love to to make contributions to keep this awesome piece of software catering to even a larger audience.

CSAF was just one example. I chose it because it is one of those standards that many industries are working with nowadays. But there are also sources with -unfortunately- Restricted access like China's CNNVD that are going to be more relevant in the upcoming years and thus having some sort of templating in place where we can parse custom data-feeds would certainely turbocharge things.

Granted it is difficult to convert an -unknown- to something known. but usually the Vulnerability feeds all have similarities. The challenge is then to map or tailor the feed to some Standard that grype / vunnel understands. Kind of like Modding in Videogames where we use Lua Scripts to modify behaviour without touching the game engine itself or recompiling it. So I am glad this conversation is front and center in the coming year and I hope I can contribute something in this regard as I get to grips more with how these tools work.

[popey]

Thanks for the update and enthusiasm! Here are a few handy links that might be useful for a new person, such as yourself, in our community. 🙏

---

• Our open Community Meeting is every other Thursday via Zoom. Everyone welcome!
• We also Live Stream Open Source gardening on the Anchore YouTube Channel every Thursday.
• We welcome discussion on the Anchore Community Discourse
• Finally, follow GrypeProject on X, Grype on the Fediverse, and GrypeProject on BlueSky!

---

-- Alan Pope - Director, Developer Relations. Anchore

[wagoodman]

Is there not a built in way of adding such "custom vulnerability sources" using the CSAF format without having to incorporate code modifications?

With v5 adding any source tends to require making code changes in grype to leverage that data. Those spots tend to be:

• how we map packages/distros to DB "namespaces" https://github.com/anchore/grype/blob/main/grype/db/v5/namespace/index.go
• how we identify distros https://github.com/anchore/grype/blob/main/grype/distro/type.go#L62
• how we map package types to matchers to use for those kinds of packages, for example the custom RPM matcher https://github.com/anchore/grype/blob/main/grype/db/v5/matcher/rpm/matcher.go#L23

In v6 (which is landing in grype@main on the order of weeks if all goes according to plan) most of this will be data driven. Specifically:

• the concept of namespaces within the DB will be gone, instead joining against other lookup tables for related identities is required (e.g. join against OperatingSystems where name is "redhat" and major_version is 8)
• the vunnel provider lists the /etc/os-release ID and VERSION_ID that the data applies to, which is written into an OperatingSystems table.
• There is an OperatingSystemAliases table to resolve information from /etc/os-release for other distros that should match against another distros vulnerability data (e.g. use the rhel vulnerability data when scanning centos images)
• There is a still-in-flight Ecosystems/EcosystemAliases set of tables that might be added to facilitate the same data-driven approach to how grype resolves the correct ecosystem

All of this allows end users that are willing to build their own DB with grype-db to run their own vunnel providers and populate the DB to be able to match against new data sources.

I think the aspects that will always require a code change (for now) is selecting a specific matcher based off of some package criteria.

The most important part for a vunnel provider is to map the dataset into a way that grype already knows how to match on:

• by package name and ecosystem
• by CPE

As long as the new dataset can be transformed into one of these two ways then adding the new provider is the vast majority of the work (assuming we're talking about v6).

Question: primarily are you trying to alter existing rows in the DB or are you trying to add entirely different data sources to match against?

[jurassicLizard]

@wagoodman : Thank you for the detailed information.

My intention and use case is that I have thousands of cyclonedx 1.5 BOMs filled with CPE data, this CPE data is a mix of software and hardware component i.e. cpe:2.3:a cpe:2.3:o and cpe:2.3:h variants. That is not where my problem lies as grype recognizes my cpe entries in all my BOMs brilliantly even the custom CPE entries.

What i need is to just match against internal vulnerability databases (which are either pre-release or not yet available publicly but use a NIST like terminology for the API ) in addition to the public sources monitored and filtered by grype . So basically My dataset is CPE-driven but i just want to enrich the vulnerability sources with my own containing pre-publication vulnerabilities and other potential weaknesses that are still not in the public domain due to various reasons.

To answer your question directly without jumping around (just wanted to provide background). I want to add entirely different data sources (for Vulnerabilities not CPEs) to match against. And I am also willing to get my hands dirty to contribute publicly to this If assistance is required and it helps everybody.