cve-bin-tool icon indicating copy to clipboard operation
cve-bin-tool copied to clipboard

Feature request: improve yocto scanning support

Open terriko opened this issue 2 years ago • 10 comments

Yocto already has tooling to help with licensing management and I think can generate SBOMs that we can scan. But I think there's some opportunity for us to more gracefully handle backported patches. In my experience, backported CVE fixes for yocto recipes usually came in the form of patches with the CVE number directly in the filename. I'm hoping that's a common convention that we could leverage. There's probably other "rough spots" where we could improve our ability to integrate with their tools.

I haven't done any research on what would need to be done here yet so this issue is pretty vague at the moment. If anyone's interested in this support and/or has time to do some research, this issue is open for discussion and refinement of the idea.

terriko avatar Aug 31 '22 19:08 terriko

Flagging this with a gsoc tag so I can find it later when we're trying to put together project ideas.

terriko avatar Sep 27 '22 23:09 terriko

@terriko From a qucik look, Yocto appears to generate SBOMs at the FILE level and not the PACKAGE level which is what cve-bin-tool needs. The Yocto SBOMS are providing the set of source files which have been used in the build (which is clearly useful) but not details of the built system.

anthonyharrison avatar Oct 24 '22 11:10 anthonyharrison

interesting! I believe package-level data should be possible but I don't know if it's easy to do without tweaking. Even with file-level data I think we could have some fun experimenting with this and with the patch file data. If anyone's seriously interested in this I'll see if I can find some yocto experts to weigh in on the best approaches and tooling to use.

terriko avatar Oct 25 '22 23:10 terriko

(I definitely know where to ask, but I'd rather wait to nerd snipe my yocto colleagues until after hacktoberfest and the 3.2 release unless someone's really interested sooner.)

terriko avatar Oct 25 '22 23:10 terriko

Sorry, this is a bit out of scope of this issue but for your information, buildroot also generates SBOM in a manifest file. buildroot is also saving at package level the CVEs that should be ignored (e.g. CVE-2021-3981 in grub2). This information is not in the manifest file, as it was initially built for licensing purpose, but it could easily be added.

So, another GSoC idea could be to add support for parsing buildroot SBOM.

ffontaine avatar Oct 26 '22 07:10 ffontaine

@ffontaine This is interesting. Is there an example of an SBOM produced by buildroot to have a look at?

anthonyharrison avatar Oct 26 '22 09:10 anthonyharrison

Sure, here is an example of the existing manifest file: manifest.csv that is made by running make legal-info

ffontaine avatar Oct 26 '22 10:10 ffontaine

@ffontaine Excellent. It looks like it would be relatively easy to generate a SBOM file in either SPDX or CycloneDX formats from this maninfext file and then it could be handled by cve-bin-tool as a standard SBOM file.

anthonyharrison avatar Oct 26 '22 10:10 anthonyharrison

@terriko I want to work on this issue please assign this to me

lavi20 avatar Feb 24 '24 06:02 lavi20

@lavi20 sure, feel free to work on it. Be warned that you'll likely have to learn a lot about yocto and it may not be particularly obvious what the right design choices are, so if you're coming here because you're looking for an easy gsoc commit you may get stuck on this one. If you don't get anything useful within, say, a week or so, feel free to abandon it and try something easier and no one will count it against you!

terriko avatar Feb 27 '24 18:02 terriko