Re: [ptxdist] SBOM support

[Michael Olbrich <m.olbrich@pengutronix.de>]

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 |