CVE Scanners and Package Version

CVE Scanners and Package Version

[fabian.hanke]

[-- Attachment #1: Type: text/plain, Size: 1419 bytes --]

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

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

I hope this is the correct place to start a discussion (if not please point me to the correct place):

Does anyone else also have the same problem with false feedback from CVE scanners? How do you deal with it?

Best regards, Fabian Hanke

----------------------------------

Bosch Rexroth AG

Registered Office: Stuttgart, Registration Court: Amtsgericht Stuttgart HRB 23192 Executive Board: Dr. Steffen Haack (President), Roland Bittenauer, Thomas Fechner, Holger von Hebel, Reinhard Schäfer Chairman of the Supervisory Board: Dr. Markus Forschner

[-- Attachment #2: Type: text/html, Size: 1880 bytes --]

Re: [yocto] CVE Scanners and Package Version

[Richard Purdie]

On Sat, 2023-12-23 at 02:47 -0800, fabian.hanke via lists.yoctoproject.org wrote:
> 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).
> 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).

https://docs.yoctoproject.org/dev/dev-manual/vulnerabilities.html#vulnerability-check-at-build-time

The cve-check tooling can check which issues are present and which are
fixed in some way so that information is there.

>  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?

The data could also be written into our SPDX SBoM information, offhand
I'm not sure if it is already or not.

> I hope this is the correct place to start a discussion (if not please
> point me to the correct place):
> Does anyone else also have the same problem with false feedback from
> CVE scanners? How do you deal with it?

The project has been focused around the cve-check tooling and SPDX SBoM
generation. If you want to use that data we'd suggest you extract it
from those sources as the proejct iself doesn't want to try and
generate multiple different output formats.

Cheers,

Richard

Re: [yocto] CVE Scanners and Package Version

[Vincent Prince]

[-- Attachment #1: Type: text/plain, Size: 2863 bytes --]

Hello,

I don't know if it will help, in our company, we modified cve-check.bbclass
so it is linked to our JIRA.
At first build, it creates a ticket for every active CVE.
We analyse CVEs on JIRA and close tickets that are not relevant for our
product.
At next builds, modified cve-check.bbclass checks for each CVE if there is
a corresponding JIRA ticket, and whitelist CVE if status is closed.

Best regards,
Vincent

Le dim. 24 déc. 2023 à 10:24, Richard Purdie <
richard.purdie@linuxfoundation.org> a écrit :

> On Sat, 2023-12-23 at 02:47 -0800, fabian.hanke via lists.yoctoproject.org
> wrote:
> > 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).
> > 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).
>
>
> https://docs.yoctoproject.org/dev/dev-manual/vulnerabilities.html#vulnerability-check-at-build-time
>
> The cve-check tooling can check which issues are present and which are
> fixed in some way so that information is there.
>
> >  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?
>
> The data could also be written into our SPDX SBoM information, offhand
> I'm not sure if it is already or not.
>
> > I hope this is the correct place to start a discussion (if not please
> > point me to the correct place):
> > Does anyone else also have the same problem with false feedback from
> > CVE scanners? How do you deal with it?
>
> The project has been focused around the cve-check tooling and SPDX SBoM
> generation. If you want to use that data we'd suggest you extract it
> from those sources as the proejct iself doesn't want to try and
> generate multiple different output formats.
>
> Cheers,
>
> Richard
>
>
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#62032):
> https://lists.yoctoproject.org/g/yocto/message/62032
> Mute This Topic: https://lists.yoctoproject.org/mt/103332846/3616779
> Group Owner: yocto+owner@lists.yoctoproject.org
> Unsubscribe:
> https://lists.yoctoproject.org/g/yocto/leave/6692360/3616779/666645251/xyzzy
> [vincent.prince.fr@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>
>

[-- Attachment #2: Type: text/html, Size: 4131 bytes --]

Re: [yocto] CVE Scanners and Package Version

[Mikko Rapeli]

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

Note that SBOM is mostly used for documenting SW components and their licenses.
Obvious but needs to be made clear.

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

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. If management wants reports, generate
them from cve-check.bbclass output, but note that CVE database is a moving target too.

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.

Cheers,

-Mikko

Re: [yocto] CVE Scanners and Package Version

[adrian.freihofer]

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


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

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

Adrian

> 
> Cheers,
> 
> -Mikko
> 
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#62063):
> https://lists.yoctoproject.org/g/yocto/message/62063
> Mute This Topic: https://lists.yoctoproject.org/mt/103332846/4454582
> Group Owner: yocto+owner@lists.yoctoproject.org
> Unsubscribe:
> https://lists.yoctoproject.org/g/yocto/unsub [adrian.freihofer@gmail.com
> ]
> -=-=-=-=-=-=-=-=-=-=-=-
> 

Re: [yocto] CVE Scanners and Package Version

[Mikko Rapeli]

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

RE: [yocto] CVE Scanners and Package Version

[Hanke Fabian (DC/PAR)]

Hello and thank you for the feedback so far,

> The cve-check tooling can check which issues are present and which are fixed in some way so that information is there.

I guess our security department wants a standardized format for all product teams and not use individual tooling for each team (which can be very diverse in a big corp). They would like to quickly be able to answer which products are affected in case of another "log4j incident". It's not about reporting, but rather having a standardized format which can be processed automatically to deal with the ever increasing number of CVEs.

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

That is a good point. It also depends on the build configuration whether a component is affected or not. I brought this up as a concern to the security department. 

> Our experts have also opted for CycloneDX. Is your CycloneDX generator publicly available?

We are still implementing it internally, but started by adapting the following: https://github.com/bgnetworks/meta-dependencytrack

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

I also looked into this. The cycloneDX format supports pedigree information for each component, which can be used to add patch objects and link them to fixed CVE numbers (see https://cyclonedx.org/guides/sbom/OWASP_CycloneDX-SBOM-Guide-en.pdf on page 48 ff for an example). But this seem to be a lot of effort to implement and the CVE scanner must support this and the naming+version ambiguity still remains. 

Best regards, Fabian Hanke

Registered Office: Stuttgart, Registration Court: Amtsgericht Stuttgart HRB 23192
Executive Board: Dr. Steffen Haack (President), Roland Bittenauer, Thomas Fechner, Holger von Hebel, Reinhard Schäfer
Chairman of the Supervisory Board: Dr. Markus Forschner

Re: [yocto] CVE Scanners and Package Version

[Marta Rybczynska]

I will reply here to multiple issues raised in this thread.

On Tue, Jan 2, 2024 at 10:46 PM Adrian Freihofer
<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/.
>

SPDX3 addresses this in a similar way as CycloneDX does. There's also
the VEX way (like in OpenVEX) that is similar to both. The additional
information
that can/should be added is the "human" processing, for example stating
that in *this configuration* the issues does not apply because XYZ.
We have that partially in CVE_STATUS_*

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

As mentioned, the CVE information changes over time. The current SBOM
specs allow to include it, but then this will require a periodic refresh.
Personally I like more the approach of static SBOM plus a VEX-style file
with the CVE sitation assessment for a given date. This allows also a
possibility to have information WHO actually did that assessment.

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

It is likely that they will be in obligation to deliver that data in a
few years'
time frame.

>
> 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 kind of a work has been discussed already. If someone has funding
available to make it happen, I will be interested to know about it.

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

The way to indicate that a given modified version has a fix for an issue
is not toally solved today. Or, more precisely, it has multiple
possible solutions.

The discussion in this thread is in fact related to what we have in sessions
about SRTools. Would you be willing to join?

Kind regards,
Marta

Re: [yocto] CVE Scanners and Package Version

[adrian.freihofer]

Hi Marta
> 
> The discussion in this thread is in fact related to what we have in
> sessions
> about SRTools. Would you be willing to join?
> 
I remember that the meetings were announced via the mailing lists. But
I can no longer find them and they are not listed on
https://www.yoctoproject.org/community/get-involved/#virtual-meetings.
How can I participate?

Thank you.
Best regards,
Adrian


> Kind regards,
> Marta