[ptxdist] SBOM support

[ptxdist] SBOM support

[Simon Falsig]

Hi,

I saw a post from 2021 to the mailing list on generating SBOMs from ptxdist.
Has there been any further work on this?

We've been looking at implementing this internally - plan would be to generate
the SBOM in CycloneDX format, and consume it with Dependency-Track 
(https://dependencytrack.org) for automatic vulnerability and license monitoring.

Looks like we're quite close to having a working setup, but it'd make a lot more
sense to have it upstreamed rather than as local patches, so would like to get a
bit of input on the approach, and see if we can make that happen :)

We've identified two main steps:
1. Generate the SBOM itself. A minimal version of this can be created from the
   output of the existing fast-bsp-report in 40 lines of Python, using the
   CycloneDX library.
   I'd assume that such a script would just go into the scripts folder in ptxdist?
   Is there a common way of tracking / documenting dependencies of such scripts?

2. To track vulnerabilities, it's necessary to track the Common Platform
   Enumeration (CPE) name of each package (from https://nvd.nist.gov/products/cpe).
   This will allow matching packages to CVEs.
   My suggestion would be to add a _CPE variable to each package (built from
   whatever other variables make sense, typically _VERSION). I managed to add this
   for the fast report (extracting it to pkg_cpe in rules/post/ptxd_make_world_common.make,
   and adding it to the report in scripts/lib/ptxd_make_world_report.sh), but I
   wouldn't be surprised if there are other places/report that need to track this
   also for consistency?
   Packages that specify _CPE would then have this included in their report, and
   there'd be no change for the packages that don't specify it.


I'd be happy to get a bit of initial feedback on the approach. I'll have a look
at putting up some initial patches in the coming days too.

Thanks in advance and best regards,
Simon

Re: [ptxdist] SBOM support

[Alexander Dahl]

Hello Simon,

Am Thu, Sep 07, 2023 at 03:03:47PM +0000 schrieb Simon Falsig:
> Hi,
> 
> I saw a post from 2021 to the mailing list on generating SBOMs from ptxdist.
> Has there been any further work on this?
> 
> We've been looking at implementing this internally - plan would be to generate
> the SBOM in CycloneDX format, and consume it with Dependency-Track 
> (https://dependencytrack.org) for automatic vulnerability and license monitoring.
> 
> Looks like we're quite close to having a working setup, but it'd make a lot more
> sense to have it upstreamed rather than as local patches, so would like to get a
> bit of input on the approach, and see if we can make that happen :)
> 
> We've identified two main steps:
> 1. Generate the SBOM itself. A minimal version of this can be created from the
>    output of the existing fast-bsp-report in 40 lines of Python, using the
>    CycloneDX library.
>    I'd assume that such a script would just go into the scripts folder in ptxdist?
>    Is there a common way of tracking / documenting dependencies of such scripts?
> 
> 2. To track vulnerabilities, it's necessary to track the Common Platform
>    Enumeration (CPE) name of each package (from https://nvd.nist.gov/products/cpe).
>    This will allow matching packages to CVEs.
>    My suggestion would be to add a _CPE variable to each package (built from
>    whatever other variables make sense, typically _VERSION). I managed to add this
>    for the fast report (extracting it to pkg_cpe in rules/post/ptxd_make_world_common.make,
>    and adding it to the report in scripts/lib/ptxd_make_world_report.sh), but I
>    wouldn't be surprised if there are other places/report that need to track this
>    also for consistency?
>    Packages that specify _CPE would then have this included in their report, and
>    there'd be no change for the packages that don't specify it.

As far as I know buildroot [1] already has support for this.  They
construct this from defaults and override it with several different
variables if defaults are not sufficient for a particular project:

<PKG>_CPE_ID_VENDOR
<PKG>_CPE_ID_VERSION
<PKG>_CPE_ID_UPDATE
<PKG>_CPE_ID_PRODUCT

And maybe more?  Some quirks handling like this is probably necessary
in ptxdist, too?

Greets
Alex

[1] https://buildroot.org/

> 
> 
> I'd be happy to get a bit of initial feedback on the approach. I'll have a look
> at putting up some initial patches in the coming days too.
> 
> Thanks in advance and best regards,
> Simon
> 

Re: [ptxdist] SBOM support

[Simon Falsig]

Hi Alex,

Thanks for your reply! I've never used Buildroot, so really good with some hints as to how
others solve this.

>>    My suggestion would be to add a _CPE variable to each package (built from
>>    whatever other variables make sense, typically _VERSION). I managed to add this
>>    for the fast report (extracting it to pkg_cpe in rules/post/ptxd_make_world_common.make,
>>    and adding it to the report in scripts/lib/ptxd_make_world_report.sh), but I
>>    wouldn't be surprised if there are other places/report that need to track this
>>    also for consistency?
>>    Packages that specify _CPE would then have this included in their report, and
>>    there'd be no change for the packages that don't specify it.
>
> As far as I know buildroot [1] already has support for this.  They construct this from
> defaults and override it with several different variables if defaults are not sufficient
> for a particular project:
>
> <PKG>_CPE_ID_VENDOR
> <PKG>_CPE_ID_VERSION
> <PKG>_CPE_ID_UPDATE
> <PKG>_CPE_ID_PRODUCT
>
> And maybe more?  Some quirks handling like this is probably necessary in ptxdist, too?
>
> Greets
> Alex

I see - Buildroot essentially automatically creates the CPE based on existing data in the
package, and that can then be overridden if needed. I guess the benefit is that this in
many cases works directly out of the box without any further configuration - but with the
risk that a wrong CPE is generated.
(From what I can see, ptxdist doesn't really provide any variable that can be extracted for
the VENDOR field though?)

Explicitly specifying the CPE in each package would lower the risk of getting wrong CPEs, as
you'd instead just not get a CPE for packages that don't specify it.

Personally, I'd probably lean towards the latter (rather no CVE than a wrong one) for our
usecase, but would be open to other ways if that can mean getting this upstreamed?

Thanks again!
Simon

Re: [ptxdist] SBOM support

[Michael Olbrich]

Hi,

On Fri, Sep 08, 2023 at 09:05:26AM +0000, Simon Falsig wrote:
> Thanks for your reply! I've never used Buildroot, so really good with some hints as to how
> others solve this.
> 
> >>    My suggestion would be to add a _CPE variable to each package (built from
> >>    whatever other variables make sense, typically _VERSION). I managed to add this
> >>    for the fast report (extracting it to pkg_cpe in rules/post/ptxd_make_world_common.make,
> >>    and adding it to the report in scripts/lib/ptxd_make_world_report.sh), but I
> >>    wouldn't be surprised if there are other places/report that need to track this
> >>    also for consistency?
> >>    Packages that specify _CPE would then have this included in their report, and
> >>    there'd be no change for the packages that don't specify it.
> >
> > As far as I know buildroot [1] already has support for this.  They construct this from
> > defaults and override it with several different variables if defaults are not sufficient
> > for a particular project:
> >
> > <PKG>_CPE_ID_VENDOR
> > <PKG>_CPE_ID_VERSION
> > <PKG>_CPE_ID_UPDATE
> > <PKG>_CPE_ID_PRODUCT
> >
> > And maybe more?  Some quirks handling like this is probably necessary in ptxdist, too?
> >
> > Greets
> > Alex
> 
> I see - Buildroot essentially automatically creates the CPE based on existing data in the
> package, and that can then be overridden if needed. I guess the benefit is that this in
> many cases works directly out of the box without any further configuration - but with the
> risk that a wrong CPE is generated.

What would be a wrong CPE? I know very little about this, but I assume,
that would be something like the wrong string for vendor/product, etc. We
need to use the same as everybody else, so matching is possible, right?

Are there any machine readable list we can use to validate this? That would
help with review and maintenance.

Anyways, the report should not included any automatically created CPE. It
should contain all the data to assemble those anyways, so it could be an
optional part of the SBOM creation.

> (From what I can see, ptxdist doesn't really provide any variable that can be extracted for
> the VENDOR field though?)

For open source projects, a vendor often makes very little sense. What is
used in such cases anyways?

> Explicitly specifying the CPE in each package would lower the risk of getting wrong CPEs, as
> you'd instead just not get a CPE for packages that don't specify it.

As I said, it could be optional. I don't know enough about this to decide
either way.

> Personally, I'd probably lean towards the latter (rather no CVE than a wrong one) for our
> usecase, but would be open to other ways if that can mean getting this upstreamed?

I think an option would be good to start with. That way we can see if
anything useful is created and you can disable it without any patches.

Michael

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: [ptxdist] SBOM support

[Simon Falsig]

Hi Michael,

> From: Michael Olbrich <m.olbrich@pengutronix.de>
> Sent: Friday, September 8, 2023 20:39
> 
> Hi,
> 
> On Fri, Sep 08, 2023 at 09:05:26AM +0000, Simon Falsig wrote:
> > Thanks for your reply! I've never used Buildroot, so really good with
> > some hints as to how others solve this.
> >
> > >>    My suggestion would be to add a _CPE variable to each package
> (built from
> > >>    whatever other variables make sense, typically _VERSION). I
> managed to add this
> > >>    for the fast report (extracting it to pkg_cpe in
> rules/post/ptxd_make_world_common.make,
> > >>    and adding it to the report in
> scripts/lib/ptxd_make_world_report.sh), but I
> > >>    wouldn't be surprised if there are other places/report that need
> to track this
> > >>    also for consistency?
> > >>    Packages that specify _CPE would then have this included in their
> report, and
> > >>    there'd be no change for the packages that don't specify it.
> > >
> > > As far as I know buildroot [1] already has support for this.  They
> > > construct this from defaults and override it with several different
> > > variables if defaults are not sufficient for a particular project:
> > >
> > > <PKG>_CPE_ID_VENDOR
> > > <PKG>_CPE_ID_VERSION
> > > <PKG>_CPE_ID_UPDATE
> > > <PKG>_CPE_ID_PRODUCT
> > >
> > > And maybe more?  Some quirks handling like this is probably necessary
> in ptxdist, too?
> > >
> > > Greets
> > > Alex
> >
> > I see - Buildroot essentially automatically creates the CPE based on
> > existing data in the package, and that can then be overridden if
> > needed. I guess the benefit is that this in many cases works directly
> > out of the box without any further configuration - but with the risk
> that a wrong CPE is generated.
> 
> What would be a wrong CPE? I know very little about this, but I assume,
> that would be something like the wrong string for vendor/product, etc. We
> need to use the same as everybody else, so matching is possible, right?

In our usecase, I guess mainly a false sense of security. You expect to get
notified of any CVEs issued for your deployed software, but if your SBOM
uses the wrong CPEs, they won't be correctly matched (by tools such as
dependency-track).
 
> Are there any machine readable list we can use to validate this? That
> would help with review and maintenance.

The current database can be downloaded from https://nvd.nist.gov/products/cpe
It's an 18 MB download, but unpacks to a 500+MB file, so not sure if it makes
sense to fully automate the validation. Adding a script that can download the
database and check any specified CPEs on demand should be doable though.

> Anyways, the report should not included any automatically created CPE. It
> should contain all the data to assemble those anyways, so it could be an
> optional part of the SBOM creation.
> 
> > (From what I can see, ptxdist doesn't really provide any variable that
> > can be extracted for the VENDOR field though?)
> 
> For open source projects, a vendor often makes very little sense. What is
> used in such cases anyways?

>From the packages I looked at, it's either $PACKAGE_project, just $PACKAGE,
or something else entirely. I'll send an RFC patch with examples in a bit.

> 
> > Explicitly specifying the CPE in each package would lower the risk of
> > getting wrong CPEs, as you'd instead just not get a CPE for packages
> that don't specify it.
> 
> As I said, it could be optional. I don't know enough about this to decide
> either way.
> 
> > Personally, I'd probably lean towards the latter (rather no CVE than a
> > wrong one) for our usecase, but would be open to other ways if that can
> mean getting this upstreamed?
> 
> I think an option would be good to start with. That way we can see if
> anything useful is created and you can disable it without any patches.
> 
> Michael
> 

Thanks for the input! I'll send an initial (very simple) implementation
along, and we can then take it from there...

 - Simon

Re: [ptxdist] SBOM support

[Michael Olbrich]

Hi,

On Thu, Sep 07, 2023 at 03:03:47PM +0000, Simon Falsig wrote:
> I saw a post from 2021 to the mailing list on generating SBOMs from ptxdist.
> Has there been any further work on this?

I've not worked on this and I'm not aware of any other efforts in this
direction.

> We've been looking at implementing this internally - plan would be to generate
> the SBOM in CycloneDX format, and consume it with Dependency-Track 
> (https://dependencytrack.org) for automatic vulnerability and license monitoring.
> 
> Looks like we're quite close to having a working setup, but it'd make a lot more
> sense to have it upstreamed rather than as local patches, so would like to get a
> bit of input on the approach, and see if we can make that happen :)

I know very little about this stuff, but I'm open to add support for this.
So please sent patches once they are ready.

> We've identified two main steps:
> 1. Generate the SBOM itself. A minimal version of this can be created from the
>    output of the existing fast-bsp-report in 40 lines of Python, using the
>    CycloneDX library.
>    I'd assume that such a script would just go into the scripts folder in ptxdist?

Yes, just put it in the scripts/ folder.

>    Is there a common way of tracking / documenting dependencies of such scripts?

You mean Python packages used by the script? Not directly. Is the SBOM
something that should be created for an image or for the BSP as a whole?

For the license stuff I have plans to created documents for images. Because
those are delivered to customers, so license compliance really needs to be
done for each image.

I'm not sure what makes sense. So you could either create a global option
and then generate the SBOM with each image. And then select
HOST_SYSTEM_PYTHON3_* in that option.
Or create an SBOM "image" for the whole BSP and select the options there.

> 2. To track vulnerabilities, it's necessary to track the Common Platform
>    Enumeration (CPE) name of each package (from https://nvd.nist.gov/products/cpe).
>    This will allow matching packages to CVEs.
>    My suggestion would be to add a _CPE variable to each package (built from
>    whatever other variables make sense, typically _VERSION).

Makes sense to me. From what I understand, the CPE is machine readable and
can be split into its components if needed, right?

>    I managed to add this
>    for the fast report (extracting it to pkg_cpe in rules/post/ptxd_make_world_common.make,
>    and adding it to the report in scripts/lib/ptxd_make_world_report.sh), but I
>    wouldn't be surprised if there are other places/report that need to track this
>    also for consistency?

Just the fast and full reports are enough. Anything else in that direction
is legacy anyways and should be replaced with stuff based on these reports
anyways.

>    Packages that specify _CPE would then have this included in their report, and
>    there'd be no change for the packages that don't specify it.
> 
> 
> I'd be happy to get a bit of initial feedback on the approach. I'll have a look
> at putting up some initial patches in the coming days too.

Michael

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: [ptxdist] SBOM support

[Gavin Schenk]

Hi,

> On Thu, Sep 07, 2023 at 03:03:47PM +0000, Simon Falsig wrote:
>> I saw a post from 2021 to the mailing list on generating SBOMs from ptxdist.
>> Has there been any further work on this?
>
> I've not worked on this and I'm not aware of any other efforts in this
> direction.
>
>> We've been looking at implementing this internally - plan would be to generate
>> the SBOM in CycloneDX format, and consume it with Dependency-Track 
>> (https://dependencytrack.org) for automatic vulnerability and license monitoring.
>> 
>> Looks like we're quite close to having a working setup, but it'd make a lot more
>> sense to have it upstreamed rather than as local patches, so would like to get a
>> bit of input on the approach, and see if we can make that happen :)

we have a similar task. There is a rudimentary prototype running on our
site. It uses licencse-complicance.yaml and a CPE-Dictionary from
https://nvd.nist.gov/products/cpe to generate a bom.json.  This bom.json
can than be feed into dependency tracker (We are using docker-compose
for demonstration).

<snip bom>
{
    "bomFormat": "CycloneDX",
    "specVersion": "1.4",
    "serialNumber": "urn:uuid:f20af5d1-0480-477d-8bea-8cbcf6d9268c",
    "components": [
        {
            "name": "attr",
            "version": "2.4.47",
            "cpe": "cpe:2.3:a:attr_project:attr:2.4.47:*:*:*:*:*:*:*",
            "licenses": [
                {
                    "license": {
                        "id": "GPL-2.0-only"
                    }
                },
                {
                    "license": {
                        "id": "LGPL-2.0-only"
                    }
                }
            ],
            "hashes": [
                {
                    "alg": "MD5",
                    "content": "84f58dec00b60f2dc8fd1c9709291cc7"
                }
            ]
        },
        ...
</snip>


> I know very little about this stuff, but I'm open to add support for this.
> So please sent patches once they are ready.
>
>> We've identified two main steps:
>> 1. Generate the SBOM itself. A minimal version of this can be created from the
>>    output of the existing fast-bsp-report in 40 lines of Python, using the
>>    CycloneDX library.
>>    I'd assume that such a script would just go into the scripts folder in ptxdist?
>
> Yes, just put it in the scripts/ folder.
>

Our script has 110 lines python. It patches some package names
that does not match with the db e.g.

expat -> libexpat
gdbserver -> gdb
kernel -> linux_kernel
libmod -> kmod
...

I am unsure, if this is too error prone. Adding CPE vars to the recepies,
where only the VERSION is variable, should be more robust.

>>    Is there a common way of tracking / documenting dependencies of such scripts?
>
> You mean Python packages used by the script? Not directly.

ptxdist-cyclonedx-bom master 
 ❯ cat requirements.txt 
pyyaml==6.0.0
lxml==4.9.2

> Is the SBOM something that should be created for an image or for the
> BSP as a whole?

It should be per image imho. Because depending on configuration, layers,
collectionconfig, content of images differs a lot. Starting from the
image, should generate data that is 100% consistent. Not much of a
difference to licence reports, I think.

> For the license stuff I have plans to created documents for images. Because
> those are delivered to customers, so license compliance really needs to be
> done for each image.

And this is the same for SBOMi, as mentioned before.

> I'm not sure what makes sense. So you could either create a global option
> and then generate the SBOM with each image. And then select
> HOST_SYSTEM_PYTHON3_* in that option.
> Or create an SBOM "image" for the whole BSP and select the options there.

One thing to keep in mind is that cyclonedx is one format, but not the
only one. Today it is one of the most common used. But there are
alternatives. So there might be other users who might need the sbom in
different formats. I wonder if it is easier to adapt to other formats
using the one, or other approach?


>> 2. To track vulnerabilities, it's necessary to track the Common Platform
>>    Enumeration (CPE) name of each package (from https://nvd.nist.gov/products/cpe).
>>    This will allow matching packages to CVEs.
>>    My suggestion would be to add a _CPE variable to each package (built from
>>    whatever other variables make sense, typically _VERSION).
>
> Makes sense to me. From what I understand, the CPE is machine readable and
> can be split into its components if needed, right?

I think it is. Here CPE number example for package expat:
"cpe:2.3:a:attr_project:attr:2.4.47:*:*:*:*:*:*:*"
                                ^- PTXCONF_EXPAT_VERSION

>>    I managed to add this
>>    for the fast report (extracting it to pkg_cpe in rules/post/ptxd_make_world_common.make,
>>    and adding it to the report in scripts/lib/ptxd_make_world_report.sh), but I
>>    wouldn't be surprised if there are other places/report that need to track this
>>    also for consistency?
>
> Just the fast and full reports are enough. Anything else in that direction
> is legacy anyways and should be replaced with stuff based on these reports
> anyways.
>
>>    Packages that specify _CPE would then have this included in their report, and
>>    there'd be no change for the packages that don't specify it.
>> 
>> 
>> I'd be happy to get a bit of initial feedback on the approach. I'll have a look
>> at putting up some initial patches in the coming days too.

I like it a lot. Need reviewers, testers, 1 mio Euro? We are willing to
contribute.

Regards
Gavin

Re: [ptxdist] SBOM support

[Christian Melki]

Shameless plug here.

We (t2data) have been developing devsecops tools for quite some time.
MAIA, our internally developed tool is capable of a lot of things.
Among them is various classifications of software with licenses, CPE,
CVE, CWE etc. Including availability of new versions etc.
Built in is also various other aspects of the development process,
beside SBOM handling.
I use MAIA to help me track my projects in ptxdist and managing change
notifications so I easier can maintain ptxdist stuff.

https://t2data.com/maia-software/

Regards,
Christian

On 9/11/23 15:11, Gavin Schenk wrote:
> Hi,
> 
>> On Thu, Sep 07, 2023 at 03:03:47PM +0000, Simon Falsig wrote:
>>> I saw a post from 2021 to the mailing list on generating SBOMs from ptxdist.
>>> Has there been any further work on this?
>>
>> I've not worked on this and I'm not aware of any other efforts in this
>> direction.
>>
>>> We've been looking at implementing this internally - plan would be to generate
>>> the SBOM in CycloneDX format, and consume it with Dependency-Track 
>>> (https://dependencytrack.org) for automatic vulnerability and license monitoring.
>>>
>>> Looks like we're quite close to having a working setup, but it'd make a lot more
>>> sense to have it upstreamed rather than as local patches, so would like to get a
>>> bit of input on the approach, and see if we can make that happen :)
> 
> we have a similar task. There is a rudimentary prototype running on our
> site. It uses licencse-complicance.yaml and a CPE-Dictionary from
> https://nvd.nist.gov/products/cpe to generate a bom.json.  This bom.json
> can than be feed into dependency tracker (We are using docker-compose
> for demonstration).
> 
> <snip bom>
> {
>     "bomFormat": "CycloneDX",
>     "specVersion": "1.4",
>     "serialNumber": "urn:uuid:f20af5d1-0480-477d-8bea-8cbcf6d9268c",
>     "components": [
>         {
>             "name": "attr",
>             "version": "2.4.47",
>             "cpe": "cpe:2.3:a:attr_project:attr:2.4.47:*:*:*:*:*:*:*",
>             "licenses": [
>                 {
>                     "license": {
>                         "id": "GPL-2.0-only"
>                     }
>                 },
>                 {
>                     "license": {
>                         "id": "LGPL-2.0-only"
>                     }
>                 }
>             ],
>             "hashes": [
>                 {
>                     "alg": "MD5",
>                     "content": "84f58dec00b60f2dc8fd1c9709291cc7"
>                 }
>             ]
>         },
>         ...
> </snip>
> 
> 
>> I know very little about this stuff, but I'm open to add support for this.
>> So please sent patches once they are ready.
>>
>>> We've identified two main steps:
>>> 1. Generate the SBOM itself. A minimal version of this can be created from the
>>>    output of the existing fast-bsp-report in 40 lines of Python, using the
>>>    CycloneDX library.
>>>    I'd assume that such a script would just go into the scripts folder in ptxdist?
>>
>> Yes, just put it in the scripts/ folder.
>>
> 
> Our script has 110 lines python. It patches some package names
> that does not match with the db e.g.
> 
> expat -> libexpat
> gdbserver -> gdb
> kernel -> linux_kernel
> libmod -> kmod
> ...
> 
> I am unsure, if this is too error prone. Adding CPE vars to the recepies,
> where only the VERSION is variable, should be more robust.
> 
>>>    Is there a common way of tracking / documenting dependencies of such scripts?
>>
>> You mean Python packages used by the script? Not directly.
> 
> ptxdist-cyclonedx-bom master 
>  ❯ cat requirements.txt 
> pyyaml==6.0.0
> lxml==4.9.2
> 
>> Is the SBOM something that should be created for an image or for the
>> BSP as a whole?
> 
> It should be per image imho. Because depending on configuration, layers,
> collectionconfig, content of images differs a lot. Starting from the
> image, should generate data that is 100% consistent. Not much of a
> difference to licence reports, I think.
> 
>> For the license stuff I have plans to created documents for images. Because
>> those are delivered to customers, so license compliance really needs to be
>> done for each image.
> 
> And this is the same for SBOMi, as mentioned before.
> 
>> I'm not sure what makes sense. So you could either create a global option
>> and then generate the SBOM with each image. And then select
>> HOST_SYSTEM_PYTHON3_* in that option.
>> Or create an SBOM "image" for the whole BSP and select the options there.
> 
> One thing to keep in mind is that cyclonedx is one format, but not the
> only one. Today it is one of the most common used. But there are
> alternatives. So there might be other users who might need the sbom in
> different formats. I wonder if it is easier to adapt to other formats
> using the one, or other approach?
> 
> 
>>> 2. To track vulnerabilities, it's necessary to track the Common Platform
>>>    Enumeration (CPE) name of each package (from https://nvd.nist.gov/products/cpe).
>>>    This will allow matching packages to CVEs.
>>>    My suggestion would be to add a _CPE variable to each package (built from
>>>    whatever other variables make sense, typically _VERSION).
>>
>> Makes sense to me. From what I understand, the CPE is machine readable and
>> can be split into its components if needed, right?
> 
> I think it is. Here CPE number example for package expat:
> "cpe:2.3:a:attr_project:attr:2.4.47:*:*:*:*:*:*:*"
>                                 ^- PTXCONF_EXPAT_VERSION
> 
>>>    I managed to add this
>>>    for the fast report (extracting it to pkg_cpe in rules/post/ptxd_make_world_common.make,
>>>    and adding it to the report in scripts/lib/ptxd_make_world_report.sh), but I
>>>    wouldn't be surprised if there are other places/report that need to track this
>>>    also for consistency?
>>
>> Just the fast and full reports are enough. Anything else in that direction
>> is legacy anyways and should be replaced with stuff based on these reports
>> anyways.
>>
>>>    Packages that specify _CPE would then have this included in their report, and
>>>    there'd be no change for the packages that don't specify it.
>>>
>>>
>>> I'd be happy to get a bit of initial feedback on the approach. I'll have a look
>>> at putting up some initial patches in the coming days too.
> 
> I like it a lot. Need reviewers, testers, 1 mio Euro? We are willing to
> contribute.
> 
> Regards
> Gavin
> 

Re: [ptxdist] SBOM support

[Simon Falsig]

Hi Gavin, Michael,

> From: Gavin Schenk <g.schenk@eckelmann.de>
> Sent: Monday, September 11, 2023 15:11
> Hi,
> 
> > On Thu, Sep 07, 2023 at 03:03:47PM +0000, Simon Falsig wrote:
> >> I saw a post from 2021 to the mailing list on generating SBOMs from
> ptxdist.
> >> Has there been any further work on this?
> >
> > I've not worked on this and I'm not aware of any other efforts in this
> > direction.
> >
> >> We've been looking at implementing this internally - plan would be to
> >> generate the SBOM in CycloneDX format, and consume it with
> >> Dependency-Track (https://dependencytrack.org) for automatic
> >> vulnerability and license monitoring.
> >>
> >> Looks like we're quite close to having a working setup, but it'd make
> >> a lot more sense to have it upstreamed rather than as local patches,
> >> so would like to get a bit of input on the approach, and see if we
> >> can make that happen :)
> 
> we have a similar task. There is a rudimentary prototype running on our
> site. It uses licencse-complicance.yaml and a CPE-Dictionary from
> https://nvd.nist.gov/products/cpe to generate a bom.json.  This bom.json
> can than be feed into dependency tracker (We are using docker-compose for
> demonstration).
> 
> <snip bom>
> {
>     "bomFormat": "CycloneDX",
>     "specVersion": "1.4",
>     "serialNumber": "urn:uuid:f20af5d1-0480-477d-8bea-8cbcf6d9268c",
>     "components": [
>         {
>             "name": "attr",
>             "version": "2.4.47",
>             "cpe": "cpe:2.3:a:attr_project:attr:2.4.47:*:*:*:*:*:*:*",
>             "licenses": [
>                 {
>                     "license": {
>                         "id": "GPL-2.0-only"
>                     }
>                 },
>                 {
>                     "license": {
>                         "id": "LGPL-2.0-only"
>                     }
>                 }
>             ],
>             "hashes": [
>                 {
>                     "alg": "MD5",
>                     "content": "84f58dec00b60f2dc8fd1c9709291cc7"
>                 }
>             ]
>         },
>         ...
> </snip>
>

That sounds exactly like what we're working on :) I like how it also splits
up the multi-licensed specifications into separate statements. How does that
show up in dependency-track? (I just know that SPDX expressions with e.g. 
AND and OR don't really work for setting up policies.)

> 
> > I know very little about this stuff, but I'm open to add support for
> this.
> > So please sent patches once they are ready.
> >
> >> We've identified two main steps:
> >> 1. Generate the SBOM itself. A minimal version of this can be created
> from the
> >>    output of the existing fast-bsp-report in 40 lines of Python, using
> the
> >>    CycloneDX library.
> >>    I'd assume that such a script would just go into the scripts folder
> in ptxdist?
> >
> > Yes, just put it in the scripts/ folder.
> >
> 
> Our script has 110 lines python. It patches some package names that does
> not match with the db e.g.
> 
> expat -> libexpat
> gdbserver -> gdb
> kernel -> linux_kernel
> libmod -> kmod
> ...
> 
> I am unsure, if this is too error prone. Adding CPE vars to the recepies,
> where only the VERSION is variable, should be more robust.
> 
> >>    Is there a common way of tracking / documenting dependencies of such
> scripts?
> >
> > You mean Python packages used by the script? Not directly.
> 
> ptxdist-cyclonedx-bom master
>  ❯ cat requirements.txt
> pyyaml==6.0.0
> lxml==4.9.2

Yes, essentially, our current implementation needs Python3 and the
cyclonedx-bom Python library. From what I understand, this could probably
be set up using pipenv or something similar? 

> 
> > Is the SBOM something that should be created for an image or for the
> > BSP as a whole?
> 
> It should be per image imho. Because depending on configuration, layers,
> collectionconfig, content of images differs a lot. Starting from the
> image, should generate data that is 100% consistent. Not much of a
> difference to licence reports, I think.

I'm not 100% confident in the ptxdist terminology relating to image or bsp
here, but the SBOM should ideally be created based on what ends up on a
target - so I guess that's the image?
My current solution just takes this from the $PACKAGES variable, but not
sure how that works with more advanced setups than ours. Initial patchset
coming in a bit, so happy to hear about how it can be improved.

> 
> > For the license stuff I have plans to created documents for images.
> > Because those are delivered to customers, so license compliance really
> > needs to be done for each image.
> 
> And this is the same for SBOMi, as mentioned before.
> 
> > I'm not sure what makes sense. So you could either create a global
> > option and then generate the SBOM with each image. And then select
> > HOST_SYSTEM_PYTHON3_* in that option.
> > Or create an SBOM "image" for the whole BSP and select the options
> there.
> 
> One thing to keep in mind is that cyclonedx is one format, but not the
> only one. Today it is one of the most common used. But there are
> alternatives. So there might be other users who might need the sbom in
> different formats. I wonder if it is easier to adapt to other formats
> using the one, or other approach?
>

I guess this could be handled with a configuration selecting the format
to use, and just some different implementations based on that?

> 
> >> 2. To track vulnerabilities, it's necessary to track the Common
> Platform
> >>    Enumeration (CPE) name of each package (from
> >>    https://nvd.nist.gov/products/cpe).
> >>    This will allow matching packages to CVEs.
> >>    My suggestion would be to add a _CPE variable to each package (built
> >>    from whatever other variables make sense, typically _VERSION).
> >
> > Makes sense to me. From what I understand, the CPE is machine readable
> > and can be split into its components if needed, right?
> 
> I think it is. Here CPE number example for package expat:
> "cpe:2.3:a:attr_project:attr:2.4.47:*:*:*:*:*:*:*"
>                                 ^- PTXCONF_EXPAT_VERSION
> 
> >>    I managed to add this
> >>    for the fast report (extracting it to pkg_cpe in
> >>    rules/post/ptxd_make_world_common.make, and adding it to the report
> >>    in scripts/lib/ptxd_make_world_report.sh), but I wouldn't be
> >>    surprised if there are other places/report that need to track this
> >>    also for consistency?
> >
> > Just the fast and full reports are enough. Anything else in that
> > direction is legacy anyways and should be replaced with stuff based on
> > these reports anyways.
> >
> >>    Packages that specify _CPE would then have this included in their
> >>    report, and there'd be no change for the packages that don't
> >>    specify it.
> >>
> >>
> >> I'd be happy to get a bit of initial feedback on the approach. I'll
> >> have a look at putting up some initial patches in the coming days too.
> 
> I like it a lot. Need reviewers, testers, 1 mio Euro? We are willing to
> contribute.
> 
> Regards
> Gavin

Thanks! Let's see what we can put together then - I'll send in a few simple
patches in a bit, assuming that I can make this git email sending work
again...

- Simon

Re: [ptxdist] SBOM support

[Simon Falsig]

Hi,

> I'd be happy to get a bit of initial feedback on the approach. I'll have a
> look at putting up some initial patches in the coming days too.
> 
> Thanks in advance and best regards,

Sorry for the silence around this, but I've been busy with other things in
the last months.

Finally managed to get something working, that integrates with the existing
host-system-python3 handling. I'll be sending some patches right after this.

Main open questions would be:
- Currently HOST_SYSTEM_PYTHON3 and (the new) HOST_SYSTEM_PYTHON3_CYCLONEDX
  packages need to be enabled manually through the "enable sbom report
  generation" option in PTXdist options. Not sure if that is the right place
  for it, or if there is a nicer way of handling it? (for instance, if it's
  not enabled, 'ptxdist sbom-report' will just fail with a not-so-helpful
  error message...)
- It looks a bit like a local venv is being set up (in sysroot-host), but
  I can't really figure out how to use it. A nice change could be to install
  whatever host-system packages are needed in that venv automatically? Right
  now the functionality requires users to manually install the required
  python library with pip.


Happy to hear of any input!
Thanks in advance,
Simon

Re: [ptxdist] SBOM support

[Simon Falsig]

> Hi,
> 
> > I'd be happy to get a bit of initial feedback on the approach. I'll
> > have a look at putting up some initial patches in the coming days too.
> >
> > Thanks in advance and best regards,
> 
> Sorry for the silence around this, but I've been busy with other things in
> the last months.
> 
> Finally managed to get something working, that integrates with the
> existing
> host-system-python3 handling. I'll be sending some patches right after
> this.
> 
> Main open questions would be:
> - Currently HOST_SYSTEM_PYTHON3 and (the new)
> HOST_SYSTEM_PYTHON3_CYCLONEDX
>   packages need to be enabled manually through the "enable sbom report
>   generation" option in PTXdist options. Not sure if that is the right
> place
>   for it, or if there is a nicer way of handling it? (for instance, if
> it's
>   not enabled, 'ptxdist sbom-report' will just fail with a not-so-helpful
>   error message...)
> - It looks a bit like a local venv is being set up (in sysroot-host), but
>   I can't really figure out how to use it. A nice change could be to
> install
>   whatever host-system packages are needed in that venv automatically?
> Right
>   now the functionality requires users to manually install the required
>   python library with pip.
> 
> 
> Happy to hear of any input!
> Thanks in advance,
> Simon
> 

Just bumping this in case it got lost over the last weeks. Would appreciate
any input, both on code and further process to move this ahead.
Thanks in advance!
Simon

Re: [ptxdist] SBOM support

[Michael Olbrich]

Hi,

On Mon, Feb 19, 2024 at 04:54:16PM +0000, Simon Falsig wrote:
> > I'd be happy to get a bit of initial feedback on the approach. I'll have a
> > look at putting up some initial patches in the coming days too.
> > 
> > Thanks in advance and best regards,
> 
> Sorry for the silence around this, but I've been busy with other things in
> the last months.

No problem. That's just the way it works. I've been looking into SBOMs as
well but my current focus is spdx.

> Finally managed to get something working, that integrates with the existing
> host-system-python3 handling. I'll be sending some patches right after this.
> 
> Main open questions would be:
> - Currently HOST_SYSTEM_PYTHON3 and (the new) HOST_SYSTEM_PYTHON3_CYCLONEDX
>   packages need to be enabled manually through the "enable sbom report
>   generation" option in PTXdist options. Not sure if that is the right place
>   for it, or if there is a nicer way of handling it? (for instance, if it's
>   not enabled, 'ptxdist sbom-report' will just fail with a not-so-helpful
>   error message...)

Hmm, maybe we can do something with a lazy package. That would require a
real package, that actually builds the stuff, but I prefer that anyways.
Otherwise we'll just add an option next to PROJECT_GENERATE_REPORTS that
selects this.
I'm not sure yet, let me worry about that part.

> - It looks a bit like a local venv is being set up (in sysroot-host), but
>   I can't really figure out how to use it. A nice change could be to install
>   whatever host-system packages are needed in that venv automatically? Right
>   now the functionality requires users to manually install the required
>   python library with pip.

So this stuff is not packaged anywhere and as far as I can tell it's not on
pypi either, so I really prefer to package this locally.

And yes, PTXdist now installs this stuff into a venv. Use host-meson as an
example. It is installed into the venv. You may not need all the
dependencies, it depends a bit on the package. The installation into the
venv should happen automatically.

I'll reply to the patches for more stuff.

Michael

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: [ptxdist] SBOM support

[Simon Falsig]

> From: Michael Olbrich <m.olbrich@pengutronix.de>
> Sent: Monday, March 4, 2024 17:09
> Hi,
> 
> On Mon, Feb 19, 2024 at 04:54:16PM +0000, Simon Falsig wrote:
> > > I'd be happy to get a bit of initial feedback on the approach. I'll
> > > have a look at putting up some initial patches in the coming days too.
> > >
> > > Thanks in advance and best regards,
> >
> > Sorry for the silence around this, but I've been busy with other
> > things in the last months.
> 
> No problem. That's just the way it works. I've been looking into SBOMs as
> well but my current focus is spdx.
> 
> > Finally managed to get something working, that integrates with the
> > existing
> > host-system-python3 handling. I'll be sending some patches right after
> this.
> >
> > Main open questions would be:
> > - Currently HOST_SYSTEM_PYTHON3 and (the new)
> HOST_SYSTEM_PYTHON3_CYCLONEDX
> >   packages need to be enabled manually through the "enable sbom report
> >   generation" option in PTXdist options. Not sure if that is the right
> place
> >   for it, or if there is a nicer way of handling it? (for instance, if
> it's
> >   not enabled, 'ptxdist sbom-report' will just fail with a not-so-
> helpful
> >   error message...)
> 
> Hmm, maybe we can do something with a lazy package. That would require a
> real package, that actually builds the stuff, but I prefer that anyways.
> Otherwise we'll just add an option next to PROJECT_GENERATE_REPORTS that
> selects this.
> I'm not sure yet, let me worry about that part.
> 
> > - It looks a bit like a local venv is being set up (in sysroot-host),
> but
> >   I can't really figure out how to use it. A nice change could be to
> install
> >   whatever host-system packages are needed in that venv automatically?
> Right
> >   now the functionality requires users to manually install the required
> >   python library with pip.
> 
> So this stuff is not packaged anywhere and as far as I can tell it's not
> on pypi either, so I really prefer to package this locally.
> 
> And yes, PTXdist now installs this stuff into a venv. Use host-meson as an
> example. It is installed into the venv. You may not need all the
> dependencies, it depends a bit on the package. The installation into the
> venv should happen automatically.
> 
> I'll reply to the patches for more stuff.
> 
> Michael
> 

Thanks for the detailed reply and review, Michael!

I've had a look at your comments, and agree that it overall makes good sense
to wait for your work, and then base the CycloneDX SBOM generation off of
that. While I feel rather comfortable *using* ptxdist (at least for my
previous and current usecases), I have very little insight into the internal
workings and structure of the project...

Maybe I'll find a bit of time to dive deeper into things before though, let's
see.

Thanks again, and have a good weekend!
Simon