Re: [yocto] CVE Scanners and Package Version

[Mikko Rapeli <mikko.rapeli@linaro.org>]

Hi,

On Tue, Jan 02, 2024 at 10:46:21PM +0100, adrian.freihofer@gmail.com wrote:
> On Tue, 2024-01-02 at 09:24 +0200, Mikko Rapeli wrote:
> > Hi,
> > 
> > On Sat, Dec 23, 2023 at 02:47:36AM -0800, fabian.hanke via
> > lists.yoctoproject.org wrote:
> > > Hello Yocto community,
> > > 
> > > we must provide a SBOM for our Yocto based product which will then
> > > be used for (internal) CVE scanning by the security department.
> > > Generating the base document in cycloneDX format is fairly easy
> > > (thanks to the nature of Yocto).
> 
> Our experts have also opted for CycloneDX. Is your CycloneDX generator
> publicly available? 
> > 
> > Note that SBOM is mostly used for documenting SW components and their
> > licenses.
> > Obvious but needs to be made clear.
> 
> I don't think that's true.
> A SBOM should probably also list the CVE patches and provide
> information about fixed CVEs.
> I'm not sure about SPDX, but CycloneDX also addresses this use case:
> https://cyclonedx.org/capabilities/vex/.

That's good, but implementation is then missing. The CVE variables are not
exported currently. I worked around this by exporting all the recipe CVE
variables into buildhistory so also non-cve-check builds would export the data
without any links to CVE database, though this was rejected here in upstream.

> > > But we do not know how to include information about CVE patches for
> > > each package in the document. Not providing these, will cause a lot
> > > of “false” feedback on CVEs for specific versions which are already
> > > patched (but version number did not change).
> Yes, that's a real issue.
> > > This problem was also mentioned a few days ago in the presentation
> > > from David Reyna: https://youtu.be/PegU1G1bA80?t=1127. I like the
> > > proposed solution of adding a vendor specific string to the package
> > > version. But I'm still wondering: How would the CVE scanner vendor
> > > know which CVEs are included in a yocto specific version and which
> > > are not?
> If the SBOM contains the information from CVE_STATUS_* variables and
> the CVE scanner has access to the NIST database it should theoretically
> work.

Additionally something must make sure that the SW product names will match CVE
database, possinly many to many mapping, and the same for SW component version
numbers so that they can be compared against info in the CVE database. But just
exporting the CVE variables into build output would be a good idea to start with.

> > If the intention is to know CVE paching and analysis status of a
> > product, then I'd use
> > the yocto upstream tooling for this, cve-check.bbclass. SBOM and SPDX
> > are tempting but not actually
> > useful for CVE patching and analysis work, except when they show that
> > a lot of old open source
> > SW components are embedded into various binaries.
> This works well from a developer's point of view, but not from an end
> customer's or penetration tester's point of view. Many companies sell
> products with a pre-installed Yocto-based firmware, but do not provide
> the layers and bitbake with the firmware.

A customer or pentester should have a look at source code, SRC_URI to see
if certain patches have been applied. These should be available even if
yocto build system is not. And then there are the binaries and actually
exploiting the holes in there.

> > The work needed to push CVE data into SPDX and SBOM is not worth it
> > and it's better to put
> > the saved effort into fixing the actual CVEs.
> Fixing the CVEs is one thing. But depending on the use case, it is also
> important to be able to document this.
> >  If management wants reports, generate
> > them from cve-check.bbclass output, but note that CVE database is a
> > moving target too.
> Adding information about open CVEs to the SBOM would be a moving target
> and therefore a bad idea. But that was probably not the intention here.
> 
> Much more reasonable is to provide a static SBOM which provides
> information about:
> - Installed packages and versions
> - CVE related patches for the packages
> - Additional information from CVE_STATUS_* variables (These use cases
> were also the motivation for adding this additional information)
>
> Such a SBOM would enable a user or a pen-tester to use a tool which
> generates a CVE report from the SBOM and the current data from e.g. the
> NIST database. This tool can run at any time and could be a generic
> SBOM tool which is independent from Yocto. The NIST DB is dynamic, but
> publicly available. The SBOM is static and provided with each firmware
> release.

This is true. Patches welcome.

> > 
> > AFAIK, and I'd be happy to be proven wrong, SPDX and SBOM don't help
> > matching SW component names
> > and version strings so that comparison against CVE database
> > information works. Only license names
> > are standardized.
> 
> I'm not sure what the current status is. But even if it's not
> completely solved today, that doesn't mean it can't or shouldn't be
> solved. The specifications are also open source.

True, patches are welcome. But it's also a good idea to do CVE analysis of the wider
yocto layer ecosystem outside of well managed poky. A lot of the basic things like
CVE name mappings to NVD CPE and version number details are broken there, and of course
updates and patches to issues are missing, and maintainers have limited resources...

Cheers,

-Mikko