[Buildroot] CycloneDX SBOM support

[Buildroot] CycloneDX SBOM support

[Robert Smigielski]

[-- Attachment #1.1: Type: text/plain, Size: 441 bytes --]

Announcing CycloneDX support for the embedded / IOT / MIOT world. Using
your Buildroot output, my project produces CycloneDX SBOM files for supply
chain management and vulnerability management. I am a long time Buildroot
user now in the device security space. Glad to provide CycloneDX SBOM
support for Buildroot users.

https://github.com/CycloneDX/cyclonedx-buildroot

https://pypi.org/project/CycloneDX-Buildroot/


-- 
Robert Smigielski

[-- Attachment #1.2: Type: text/html, Size: 974 bytes --]

[-- Attachment #2: Type: text/plain, Size: 150 bytes --]

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] CycloneDX SBOM support

[Peter Korsgaard]

>>>>> "Robert" == Robert Smigielski <ptdropper@gmail.com> writes:

Hi,

 > Announcing CycloneDX support for the embedded / IOT / MIOT world. Using
 > your Buildroot output, my project produces CycloneDX SBOM files for supply
 > chain management and vulnerability management. I am a long time Buildroot
 > user now in the device security space. Glad to provide CycloneDX SBOM
 > support for Buildroot users.

 > https://github.com/CycloneDX/cyclonedx-buildroot

 > https://pypi.org/project/CycloneDX-Buildroot/

Thanks! I think I have seen it earlier, where I noticed that it only
worked on the legal-info manifest - But we have quite a bit more
SBOM-related info in Buildroot nowadays visible in show-info. I see that
you are now also using this info for the CPE data, so that is good.

So what is the status of this project? Anything missing? Anything you
are missing from Buildroot? What (open source) tools can consume the
generated SBOMs and do something interesting with it?

-- 
Bye, Peter Korsgaard
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] CycloneDX SBOM support

[Michael Nosthoff via buildroot]

[-- Attachment #1.1: Type: text/plain, Size: 1864 bytes --]

Hi,

> On 28. Aug 2023, at 08:00, Peter Korsgaard <peter@korsgaard.com> wrote:
> 
>>>>>> "Robert" == Robert Smigielski <ptdropper@gmail.com> writes:
> 
> Hi,
> 
>> Announcing CycloneDX support for the embedded / IOT / MIOT world. Using
>> your Buildroot output, my project produces CycloneDX SBOM files for supply
>> chain management and vulnerability management. I am a long time Buildroot
>> user now in the device security space. Glad to provide CycloneDX SBOM
>> support for Buildroot users.
> 
>> https://github.com/CycloneDX/cyclonedx-buildroot
> 
>> https://pypi.org/project/CycloneDX-Buildroot/

I’m just returning from vacation so it will take some days but I will happily try this out.
I recently built my own show-info to cyclone-dx python script but from skimming through
your package this looks way better than mine.

So without further checking already: thanks for taking on this task!

> 
> Thanks! I think I have seen it earlier, where I noticed that it only
> worked on the legal-info manifest - But we have quite a bit more
> SBOM-related info in Buildroot nowadays visible in show-info. I see that
> you are now also using this info for the CPE data, so that is good.
> 
> So what is the status of this project? Anything missing? Anything you
> are missing from Buildroot? What (open source) tools can consume the
> generated SBOMs and do something interesting with it?

There are multiple tools which can work with the cyclone-dx format and from what
I’m reading this might become the “de-facto SBOM standard”.

What we are currently evaluating is Dependency Track (https://dependencytrack.org/).
It’s not perfect but it checks your SBOM frequently for new Issues and generates
management friendly Dashboard Views. In the end this is pretty new for most of us I guess.

Regards,
Michael



[-- Attachment #1.2: Type: text/html, Size: 2745 bytes --]

[-- Attachment #2: Type: text/plain, Size: 150 bytes --]

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] CycloneDX SBOM support

[Robert Smigielski]

[-- Attachment #1.1: Type: text/plain, Size: 2781 bytes --]

My focus is dependency track as the tool, I use to scan the software bill
of materials. I use it at work to check on the status of a variety of
projects. Historically, it supported only server and software as a service.
With the Buildroot interface you can also pull in data from your board
support packages. And that's exactly what I'm doing. I have added those
specific software bill of materials to my set of projects in dependency
track.

At this time I'm reading up on the difference between CPE and PURL. While
we have CPE information in their currently, it may be beneficial to have
PURL for some of the packages. I'm still new to the concept of what those
two formats provide. Your feedback is most welcome. Glad you are finding
this useful.

Robert Smigielski

On Mon, Aug 28, 2023, 7:38 AM Michael Nosthoff <buildroot@heine.tech> wrote:

> Hi,
>
> On 28. Aug 2023, at 08:00, Peter Korsgaard <peter@korsgaard.com> wrote:
>
> "Robert" == Robert Smigielski <ptdropper@gmail.com> writes:
>
>
> Hi,
>
> Announcing CycloneDX support for the embedded / IOT / MIOT world. Using
> your Buildroot output, my project produces CycloneDX SBOM files for supply
> chain management and vulnerability management. I am a long time Buildroot
> user now in the device security space. Glad to provide CycloneDX SBOM
> support for Buildroot users.
>
>
> https://github.com/CycloneDX/cyclonedx-buildroot
>
>
> https://pypi.org/project/CycloneDX-Buildroot/
>
>
> I’m just returning from vacation so it will take some days but I will
> happily try this out.
> I recently built my own show-info to cyclone-dx python script but from
> skimming through
> your package this looks way better than mine.
>
> So without further checking already: thanks for taking on this task!
>
>
> Thanks! I think I have seen it earlier, where I noticed that it only
> worked on the legal-info manifest - But we have quite a bit more
> SBOM-related info in Buildroot nowadays visible in show-info. I see that
> you are now also using this info for the CPE data, so that is good.
>
> So what is the status of this project? Anything missing? Anything you
> are missing from Buildroot? What (open source) tools can consume the
> generated SBOMs and do something interesting with it?
>
>
> There are multiple tools which can work with the cyclone-dx format and
> from what
> I’m reading this might become the “de-facto SBOM standard”.
>
> What we are currently evaluating is Dependency Track (
> https://dependencytrack.org/).
> It’s not perfect but it checks your SBOM frequently for new Issues and
> generates
> management friendly Dashboard Views. In the end this is pretty new for
> most of us I guess.
>
> Regards,
> Michael
>
>
>

[-- Attachment #1.2: Type: text/html, Size: 4115 bytes --]

[-- Attachment #2: Type: text/plain, Size: 150 bytes --]

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] CycloneDX SBOM support

[Peter Korsgaard]

>>>>> "Robert" == Robert Smigielski <ptdropper@gmail.com> writes:

Hi,

 > At this time I'm reading up on the difference between CPE and PURL. While
 > we have CPE information in their currently, it may be beneficial to have
 > PURL for some of the packages. I'm still new to the concept of what those
 > two formats provide. Your feedback is most welcome. Glad you are finding
 > this useful.

Conceptually they seem quite similar, with PURL being more generic, but
I fail to see how we could use PURLS in Buildroot, E.G. how to do the
equivalent of the CPE matching we use to figure out if the version of a
package in Buildroot is vulnerable to a specific CVE?

I gave your generateBuildrootSBOM.py script a quick try here, and
noticed a few things:

- The purl links seems wrong (missing slash between site and filename):
  "purl": "pkg:generic/busybox@1.36.1?download_url=https://www.busybox.net/downloadsbusybox-1.36.1.tar.bz2"

- The patches are not mentioned in the SBOM. Adding the show-info data
  does bring the CPE identifiers, but E.G. doesn't include _IGNORE_CVES
  data (that we use to signal that a vulnerability is either not
  applicable to Buildroot or fixed by a backported patch). I don't know
  much about cyclonedx, but judging from
  https://github.com/DependencyTrack/dependency-track/issues/919 it
  sounds like such info can be represented in the SBOM.

- Latest version in git is 1.0.4 (using an non-annotated tag, whereas
  1.0.3 was annotated), but on pypi there is (only) a 1.0.5, which seems
  to match the 1.0.4 sources. It is marked as needing python > 3.10, and
  doesn't pull in the dependencies, so it doesn't work very well

- The output filename is used as a prefix, with .json .one.xml and .xml
  variants. I understand why you do this, but it is a bit confusing
  still. Is there any real use of the non-JSON formats / available
  tooling to convert if needed?

Is there a specific reason why you are maintaining it separately from
Buildroot? Given the fairly tight link to the Buildroot details that
may change in the future (not to mention ease of use/discovery) it seems
to me to be something that would be interesting to ship together with
our other python based tooling inside Buildroot?

-- 
Bye, Peter Korsgaard
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] CycloneDX SBOM support

[Arnout Vandecappelle via buildroot]

On 28/08/2023 16:57, Peter Korsgaard wrote:
>>>>>> "Robert" == Robert Smigielski <ptdropper@gmail.com> writes:
> 
> Hi,
> 
>   > At this time I'm reading up on the difference between CPE and PURL. While
>   > we have CPE information in their currently, it may be beneficial to have
>   > PURL for some of the packages. I'm still new to the concept of what those
>   > two formats provide. Your feedback is most welcome. Glad you are finding
>   > this useful.

  I mentioned PURL vs CPE in my talk at ELC this year. You can look it up on 
youtube. It was near the end of the talk.


> Conceptually they seem quite similar, with PURL being more generic, but
> I fail to see how we could use PURLS in Buildroot, E.G. how to do the
> equivalent of the CPE matching we use to figure out if the version of a
> package in Buildroot is vulnerable to a specific CVE?

  I think Robert is not necessarily primarily concerned with finding 
vulnerabilities, but rather with constructing a meaningful and accurate SBoM 
(which is what dependencytrack does).

  That said, it you want to use PURLs for vulnerabilities, you have to use a 
vulnerability database that uses PURLs. To my knowledge, there is just one "open 
source" one: https://osv.dev. (There's also Sonatype which can be used gratis 
but is not free.) Since there are many, many CVEs that don't make it into OSV, 
using _only_ PURLs is certainly not enough. But we could combine the two.


  Another issue with PURLs is: which one do we use? PURLs are organised around 
ecosystems. For PyPI it's clear, but for your typical C library/application it's 
less so. E.g. openssl appears in the Debian, Alpine, AlmaLinux, RPM, RockyLinux 
ecosystems (and possibly more), each with a distinct PURL. We could start our 
own namespace, but that's kind of pointless unless we also issue advisories...


  There's by the way another issue (which also exists for the CPE-based 
approach): our "BoM" for the cargo and go packages is not correct: we vendor the 
dependencies, but they're not taken into account in the BoM. The tarball we put 
in legal-info does include the vendored dependencies, but they're not mentioned 
in the manifest, and we don't scan their vulnerabilities.

> I gave your generateBuildrootSBOM.py script a quick try here, and
> noticed a few things:
> 
> - The purl links seems wrong (missing slash between site and filename):
>    "purl": "pkg:generic/busybox@1.36.1?download_url=https://www.busybox.net/downloadsbusybox-1.36.1.tar.bz2"
> 
> - The patches are not mentioned in the SBOM. Adding the show-info data
>    does bring the CPE identifiers, but E.G. doesn't include _IGNORE_CVES
>    data (that we use to signal that a vulnerability is either not
>    applicable to Buildroot or fixed by a backported patch). I don't know
>    much about cyclonedx, but judging from
>    https://github.com/DependencyTrack/dependency-track/issues/919 it
>    sounds like such info can be represented in the SBOM.
> 
> - Latest version in git is 1.0.4 (using an non-annotated tag, whereas
>    1.0.3 was annotated), but on pypi there is (only) a 1.0.5, which seems
>    to match the 1.0.4 sources. It is marked as needing python > 3.10, and
>    doesn't pull in the dependencies, so it doesn't work very well
> 
> - The output filename is used as a prefix, with .json .one.xml and .xml
>    variants. I understand why you do this, but it is a bit confusing
>    still. Is there any real use of the non-JSON formats / available
>    tooling to convert if needed?
> 
> Is there a specific reason why you are maintaining it separately from
> Buildroot? Given the fairly tight link to the Buildroot details that
> may change in the future (not to mention ease of use/discovery) it seems
> to me to be something that would be interesting to ship together with
> our other python based tooling inside Buildroot?

  I absolutely agree with that statement!

  Regards,
  Arnout

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] CycloneDX SBOM support

[Peter Korsgaard]

>>>>> "Arnout" == Arnout Vandecappelle <arnout@mind.be> writes:

Hello,

 >  I mentioned PURL vs CPE in my talk at ELC this year. You can look it
 >  up on youtube. It was near the end of the talk.

OK, I'll have a look.


 >> Conceptually they seem quite similar, with PURL being more generic, but
 >> I fail to see how we could use PURLS in Buildroot, E.G. how to do the
 >> equivalent of the CPE matching we use to figure out if the version of a
 >> package in Buildroot is vulnerable to a specific CVE?

 >  I think Robert is not necessarily primarily concerned with finding
 >  vulnerabilities, but rather with constructing a meaningful and
 > accurate SBoM (which is what dependencytrack does).

True. The monitoring stuff seems quite interesting for vulnerabilities
though.


 >  That said, it you want to use PURLs for vulnerabilities, you have to
 >  use a vulnerability database that uses PURLs. To my knowledge, there
 > is just one "open source" one: https://osv.dev. (There's also Sonatype
 > which can be used gratis but is not free.) Since there are many, many
 > CVEs that don't make it into OSV, using _only_ PURLs is certainly not
 > enough. But we could combine the two.

OK. It doesn't sound like it will bring a lot of advantages for the
effort to maintain PURL identifiers :/


 >  Another issue with PURLs is: which one do we use? PURLs are organised
 >  around ecosystems. For PyPI it's clear, but for your typical C
 > library/application it's less so. E.g. openssl appears in the Debian,
 > Alpine, AlmaLinux, RPM, RockyLinux ecosystems (and possibly more),
 > each with a distinct PURL. We could start our own namespace, but
 > that's kind of pointless unless we also issue advisories...

I guess we should use the one matching where we get the source code from
(if any). The cyclonedx tool uses a "generic"
pkg:generic/$name?download_url=$site/$tarball, so we could default to
that and just use pypi/github/whatever for the special cases where there
is a more accurate one.


 >  There's by the way another issue (which also exists for the CPE-based
 >  approach): our "BoM" for the cargo and go packages is not correct: we
 > vendor the dependencies, but they're not taken into account in the
 > BoM. The tarball we put in legal-info does include the vendored
 > dependencies, but they're not mentioned in the manifest, and we don't
 > scan their vulnerabilities.

True. I am not sure of a good way how to fix that though. That shouldn't
stop us from generating a good SBOM for all the other packages.

-- 
Bye, Peter Korsgaard
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] CycloneDX SBOM support

[Robert Smigielski]

[-- Attachment #1.1: Type: text/plain, Size: 3642 bytes --]

>
> noticed a few things:
>
> - The purl links seems wrong (missing slash between site and filename):
>   "purl": "pkg:generic/busybox@1.36.1?download_url=
> https://www.busybox.net/downloadsbusybox-1.36.1.tar.bz2"
>

Yes this is a defect. I will create an issue, easy to correct. Thanks.
https://github.com/CycloneDX/cyclonedx-buildroot/issues/21



>
> - The patches are not mentioned in the SBOM. Adding the show-info data
>   does bring the CPE identifiers, but E.G. doesn't include _IGNORE_CVES
>   data (that we use to signal that a vulnerability is either not
>   applicable to Buildroot or fixed by a backported patch). I don't know
>   much about cyclonedx, but judging from
>   https://github.com/DependencyTrack/dependency-track/issues/919 it
>   sounds like such info can be represented in the SBOM.
>

That is a possible feature of CycloneDX I need to explore. I am
learning about the details of the spec as well. I will check on this.


>
> - Latest version in git is 1.0.4 (using an non-annotated tag, whereas
>   1.0.3 was annotated), but on pypi there is (only) a 1.0.5, which seems
>   to match the 1.0.4 sources. It is marked as needing python > 3.10, and
>   doesn't pull in the dependencies, so it doesn't work very well
>

I was hoping that everyone would ignore the third digit version error I
introduced accidentally. The only way to get the proper license into pypi
was for me to push up a 1.0.5 with the corrected open source license name.
I had a typo in the license name. It matches 1.0.4 functionally.
I am not an expert on python dependencies. My use of python since the late
1990's showed me many problems in the python dependency Hell. I am under
the impression that the set of python files I pushed to pypi are designed
to take into account the necessary dependencies as a result of the file
called "requirements.txt". I will have to check on this.


>
> - The output filename is used as a prefix, with .json .one.xml and .xml
>   variants. I understand why you do this, but it is a bit confusing
>   still. Is there any real use of the non-JSON formats / available
>   tooling to convert if needed?
>
>
I should have edited the process to remove the file <something>.one.xml
rather than keep it. It will be deleted. The CycloneDX tooling for python
can produce a JSON and an XML file, that is the reason for the two file
formats. Use them as you like.
https://github.com/CycloneDX/cyclonedx-buildroot/issues/20


> Is there a specific reason why you are maintaining it separately from
> Buildroot?
>

Yes, I took over the existing non functional CycloneDX-Buildroot project
that was in place. It was not operational. I needed the solution. I
followed the classic open source project philosophy - "scratch my own itch"
and made it work. I am involved in the security space and for several years
I asked both the Buildroot and CycloneDX communities if/when Buildroot
would be supported AS A PACKAGE MANAGER - that's one of the features. Well
CycloneDX team members showed me the project and asked if I wanted to do
it. So here I am (in Pennsylvania USA).


> Given the fairly tight link to the Buildroot details that

may change in the future (not to mention ease of use/discovery) it seems
> to me to be something that would be interesting to ship together with
> our other python based tooling inside Buildroot?
>

Feel free! I would be thrilled to have the close linkage of the projects. I
have been a Buildroot user for over 10 years on many projects. I still
support a board support package using ancient Buildroot for Linux 2.6.34.X
series boards (ugh!!!). So I am happy to share.

-- 
Robert Smigielski

[-- Attachment #1.2: Type: text/html, Size: 5635 bytes --]

[-- Attachment #2: Type: text/plain, Size: 150 bytes --]

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] CycloneDX SBOM support

[Robert Smigielski]

[-- Attachment #1.1: Type: text/plain, Size: 2064 bytes --]

>
>
>
>  >  I think Robert is not necessarily primarily concerned with finding
>  >  vulnerabilities, but rather with constructing a meaningful and
>  > accurate SBoM (which is what dependencytrack does).
>
> True. The monitoring stuff seems quite interesting for vulnerabilities
> though.
>

Yes I am concerned with creating a valid CycloneDX official SBOM for use in
other projects as an input. For example take the output file
<product>.json as input to Dependency Track. It does work. That is exactly
what I need for my daily work.


> OK. It doesn't sound like it will bring a lot of advantages for the
> effort to maintain PURL identifiers :/
>

From my view point - if Buildroot supports PURL I will add that data to my
project. If not, that is okay.

>
>  > each with a distinct PURL. We could start our own namespace, but
>  > that's kind of pointless unless we also issue advisories...
>

Yes, Buildroot could consider itself a package manager, because it does
that. That idea is a possibility.


> I guess we should use the one matching where we get the source code from
> (if any). The cyclonedx tool uses a "generic"
> pkg:generic/$name?download_url=$site/$tarball, so we could default to
> that and just use pypi/github/whatever for the special cases where there
> is a more accurate one
>

Yes, the tool I wrote uses the "generic"  package. There is a place
holder out there in PURL for Buildroot if you want to go that way in the
future.

 >  There's by the way another issue (which also exists for the CPE-based
>  >  approach): our "BoM" for the cargo and go packages is not correct: we
>  > vendor the dependencies, but they're not taken into account in the
>  > BoM. The tarball we put in legal-info does include the vendored
>  > dependencies, but they're not mentioned in the manifest, and we don't
>  > scan their vulnerabilities.
>

If data is not in the legal-info, then no problem, the CycloneDX-Buildroot
project will not see it.  Note that CycloneDX has support for cargo and for
go already. Maybe that can help.

-- 
Robert Smigielski

[-- Attachment #1.2: Type: text/html, Size: 3301 bytes --]

[-- Attachment #2: Type: text/plain, Size: 150 bytes --]

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] CycloneDX SBOM support

[Arnout Vandecappelle via buildroot]

On 29/08/2023 01:19, Robert Smigielski wrote:
> 
> 
>       >  I think Robert is not necessarily primarily concerned with finding
>       >  vulnerabilities, but rather with constructing a meaningful and
>       > accurate SBoM (which is what dependencytrack does).
> 
>     True. The monitoring stuff seems quite interesting for vulnerabilities
>     though.
> 
> 
> Yes I am concerned with creating a valid CycloneDX official SBOM for use in 
> other projects as an input. For example take the output file <product>.json as 
> input to Dependency Track. It does work. That is exactly what I need for my 
> daily work.
> 
>     OK. It doesn't sound like it will bring a lot of advantages for the
>     effort to maintain PURL identifiers :/

  From a pure vulnerabilities tracking point of view, it may seem it doesn't. 
However, I expect that there are vulnerabilities that are tracked in OSV for 
ecosystems like PyPI, Go, and crates.io, which don't have a corresponding CVE or 
where the CPE information is inaccurate/incorrect. And I'm very sure that there 
are vulnerabilities that are found by OSS-Fuzz which don't get a CVE (I think 
OSS-Fuzz never creates CVEs themselves, they expect the package maintainers to 
do that). Of course, the question is how valuable those OSS-Fuzz vulnerability 
reports are: they just have a reproducer, no analysis of the risk or impact.

  Anyway: creating a purl based on the PyPI, Go and crates.io ecosystems based 
on the information already in Buildroot should be rather trivial, and it has value.


>  From my view point - if Buildroot supports PURL I will add that data to my 
> project. If not, that is okay.
> 
> 
>       > each with a distinct PURL. We could start our own namespace, but
>       > that's kind of pointless unless we also issue advisories...
> 
> 
> Yes, Buildroot could consider itself a package manager, because it does that. 
> That idea is a possibility.

  IMHO, though, the idea that a package manager creates a namespace is not very 
valuable. It should be up to the actual package maintainers to decide which 
ecosystem they belong to.



>     I guess we should use the one matching where we get the source code from
>     (if any). The cyclonedx tool uses a "generic"
>     pkg:generic/$name?download_url=$site/$tarball, so we could default to
>     that and just use pypi/github/whatever for the special cases where there
>     is a more accurate one

  Exactly.

> Yes, the tool I wrote uses the "generic"  package. There is a place holder out 
> there in PURL for Buildroot if you want to go that way in the future.

  As I wrote above: I don't think that generic placeholder is very valuable. 
Although, it does give you a unified URI scheme that points you to the exact 
source and version that was used. But because it's not a unique identifier, i.e. 
there are many different PURIs that point to exactly the same source. E.g. for 
github automatically generated tarballs, there's a bit of freedom in how you 
construct the tarball name and we actually make use of that freedom. This means 
that you cannot compare generic PURIs from different sources and expect them to 
have a meaningful match. So it's no use for vulnerability tracking.

  BTW, is this "generic" namespace something official or something you invented?


>       >  There's by the way another issue (which also exists for the CPE-based
>       >  approach): our "BoM" for the cargo and go packages is not correct: we
>       > vendor the dependencies, but they're not taken into account in the
>       > BoM. The tarball we put in legal-info does include the vendored
>       > dependencies, but they're not mentioned in the manifest, and we don't
>       > scan their vulnerabilities.
> 
> 
> If data is not in the legal-info, then no problem, the CycloneDX-Buildroot 
> project will not see it.  Note that CycloneDX has support for cargo and for go 
> already. Maybe that can help.

  I don't think there's a tool that you can feed the CycloneDX SBoM and that 
will add all the missing go/crates dependencies to it. There are tools that do 
this based on the source, though.

  However, it's not _that_ difficult to get this information from within 
buildroot. When we do the vendoring in the download step, we can ask the 
download tool (cargo / go mod) to also create a manifest of the vendored 
dependencies. In fact, I think they do that automatically. So it's "just" a 
matter of parsing this manifest and including it in the SBoM.


  Regards,
  Arnout


_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] CycloneDX SBOM support

[Peter Korsgaard]

>>>>> "Robert" == Robert Smigielski <ptdropper@gmail.com> writes:

Hi,

 > Yes I am concerned with creating a valid CycloneDX official SBOM for use in
 > other projects as an input. For example take the output file
 > <product>.json as input to Dependency Track. It does work. That is exactly
 > what I need for my daily work.

And a generally useful thing!


 > If data is not in the legal-info, then no problem, the CycloneDX-Buildroot
 > project will not see it.

Longer term I think that is a problem (which you now also see with the
missing CPE identifiers). The legal-info format is very simple/old, so it
misses a number of things present in show-info that could be interesting
for a SBOM.

-- 
Bye, Peter Korsgaard
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] CycloneDX SBOM support

[Robert Smigielski]

[-- Attachment #1.1: Type: text/plain, Size: 1567 bytes --]

Found the PURL types at this github repository, it mentions that
"buildroot" is in the list of "other candidate types to define"
https://github.com/package-url/purl-spec/blob/master/PURL-TYPES.rst

That is why I am using the "generic" PURL "type" because it is flexible and
clearly is generic. I am reading up on the data in this github repo to
learn more about purl. It will take some time. But maybe this is the info
for what Buildroot needs. My limited research on PURL vs CPE says CPE is
for big projects like operating systems. PURL can just work for a package
at a version in a location.


OK. It doesn't sound like it will bring a lot of advantages for the
>> effort to maintain PURL identifiers :/
>>
>
> From my view point - if Buildroot supports PURL I will add that data to my
> project. If not, that is okay.
>
>>
>>  > each with a distinct PURL. We could start our own namespace, but
>>  > that's kind of pointless unless we also issue advisories...
>>
>
> Yes, Buildroot could consider itself a package manager, because it does
> that. That idea is a possibility.
>
>
>> I guess we should use the one matching where we get the source code from
>> (if any). The cyclonedx tool uses a "generic"
>> pkg:generic/$name?download_url=$site/$tarball, so we could default to
>> that and just use pypi/github/whatever for the special cases where there
>> is a more accurate one
>>
>
> Yes, the tool I wrote uses the "generic"  package. There is a place
> holder out there in PURL for Buildroot if you want to go that way in the
> future.
>
> --
Robert Smigielski

[-- Attachment #1.2: Type: text/html, Size: 2725 bytes --]

[-- Attachment #2: Type: text/plain, Size: 150 bytes --]

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] CycloneDX SBOM support

[Robert Smigielski]

[-- Attachment #1.1: Type: text/plain, Size: 3301 bytes --]

Based on the intent of CPE (
https://owasp.org/www-community/Component_Analysis)
"Historically, known vulnerabilities referred to entries (CVEs) in the
National Vulnerability Database (NVD). The NVD describes (via CPE) three
types of components: Applications (includes libraries and frameworks),
Operating Systems and Hardware"

- Additionally -

"Centralized databases such as the CPE Product Dictionary maintained by
NIST adds additional fragmentation as the CPE vendor and product names
often do not reflect reality." I know for certain that the NVD has errors
that are not managed.

- Finally -

The Package URL specification provides a decentralized and uniform way to
represent components.

    scheme:type/namespace/name@version?qualifiers#subpath

PURL seems to be the right long term mechanism to identify a specific
software component by using a URL, a package name, and a package version.
Personally I find the PURL data from Buildroot to be an excellent way to
know exactly what component is in use in a product SBOM.
As an example for a PURL in an actual product I am working on, the
following entry is in the CycloneDX-Buildroot SBOM output JSON file:
   "purl": "pkg:generic/dbus@1.12.24?download_url=
https://dbus.freedesktop.org/releases/dbus/dbus-1.12.24.tar.gz"
Works beautifully for this open source project "dbus" that is out on the
internet from the freedesktop.org provider/supplier/manufacturer (select
your favorite english word to represent where dbus comes from).

On Tue, Aug 29, 2023 at 9:38 AM Robert Smigielski <ptdropper@gmail.com>
wrote:

> Found the PURL types at this github repository, it mentions that
> "buildroot" is in the list of "other candidate types to define"
> https://github.com/package-url/purl-spec/blob/master/PURL-TYPES.rst
>
> That is why I am using the "generic" PURL "type" because it is flexible
> and clearly is generic. I am reading up on the data in this github repo to
> learn more about purl. It will take some time. But maybe this is the info
> for what Buildroot needs. My limited research on PURL vs CPE says CPE is
> for big projects like operating systems. PURL can just work for a package
> at a version in a location.
>
>
> OK. It doesn't sound like it will bring a lot of advantages for the
>>> effort to maintain PURL identifiers :/
>>>
>>
>> From my view point - if Buildroot supports PURL I will add that data to
>> my project. If not, that is okay.
>>
>>>
>>>  > each with a distinct PURL. We could start our own namespace, but
>>>  > that's kind of pointless unless we also issue advisories...
>>>
>>
>> Yes, Buildroot could consider itself a package manager, because it does
>> that. That idea is a possibility.
>>
>>
>>> I guess we should use the one matching where we get the source code from
>>> (if any). The cyclonedx tool uses a "generic"
>>> pkg:generic/$name?download_url=$site/$tarball, so we could default to
>>> that and just use pypi/github/whatever for the special cases where there
>>> is a more accurate one
>>>
>>
>> Yes, the tool I wrote uses the "generic"  package. There is a place
>> holder out there in PURL for Buildroot if you want to go that way in the
>> future.
>>
>> --
> Robert Smigielski
>


-- 
Robert Smigielski

[-- Attachment #1.2: Type: text/html, Size: 5280 bytes --]

[-- Attachment #2: Type: text/plain, Size: 150 bytes --]

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot