Hei!

I'm not often here, but Tux was kind enough to notify me. :-)

It's true there's not much happening on CPAN regarding SBOMs. Ovid quickly put together the initial bits of a CycloneDX parser last year, but no-one has volunteered to pick it up and take it further yet.

I've been focusing on figuring out the actual ecosystem consequences of the EU Cyber Resilience Act, and while there's still a bunch of work left, it's starting to look pretty decent. I've even put together a reading list ; and a glossary – to help me (and anyone else who cares) get an overview of the landscape.

If anyone would like to help make something happen in this regard, I'm happy to share all I know! Please reach out ASAP, as there is a LOT that needs to be in place quite soon, if this isn't going to become a massive headache.

I'll also be in Vienna for the Open Source Summit Europe in a few weeks, and at the London Perl Workshop in October where I'll share some of the ongoings.

Please reach out if you'd like to meet up and chat! :)

With that said, CPANSec has waaay to few people volunteering, so if this topic is near to your heart, please volunteer! You can find all you need on the CPANSec website: https://security.metacpan.org/

— Salve J. Nilsen

Thank you, especially for the links. I've taken a short look at the glossary and the supply-chain documents:

• the CPANSec Glossary of Terms
• the Roles and metadata in open source supply-chains document
• the CPANSec Reading List

The reading list will take much more time to peruse, however. The link to the mailing list for the CPANSec group does not seem available and active.

Whatever the origins of the Cyber Security Act (CRA) in the EU etc, and other maneuvers elsewhere, the SBOM requirement does seem to have become a potential barrier against free and open source software which the various communities will have to learn to navigate, probably as communities rather than as individuals since the specification seems complicated for now.

I've taken a quick look at Ovid's parser for version 1.5 of the CycloneDX SBOM specification which you linked to above, and at the CPAN Security Group page also linked above. (Both of those are, strangely, still using GitHub in 2024.)

What means are there to generate an SBOM for a Perl module currently? To that end, what example SBOM files are available to test against Ovid's CycloneDX SBOM reader? Based on reading valid.t there and on CycloneDX/bom-examples (very strangely still on GitHub in 2024), I can kind of guess about writing an SBOM by hand.

Please join the CPANSec group with your knowledge and motivation :)

There will be a BOF in the London Perl and Raku Workshop where this will be one of the points on the agenda. All that are interested are welcome to join!


Enjoy, Have FUN! H.Merijn

The reading list will take much more time to peruse, however. The link to the mailing list for the CPANSec group does not seem available and active.

The address works fine, but we didn't link to it (you know, email harvesters are still a thing).

Whatever the origins of the Cyber Security Act (CRA) in the EU etc, and other maneuvers elsewhere, the SBOM requirement does seem to have become a potential barrier against free and open source software which the various communities will have to learn to navigate, probably as communities rather than as individuals since the specification seems complicated for now.

The SBOM requirements are certainly a speed-bump and an annoyance – given the fact that most FOSS work is done on a volunteer basis. I wouldn't call it a blocker though. My hope is that the Roles and metadata in open source supply-chains document eventually can help these communities navigate this new landscape.

What means are there to generate an SBOM for a Perl module currently?

AFAIK, there are no options currently for doing this automatically. Furthermore, if this is going to work without too much hassle for the majority of maintainers, any proposed solutions will probably have to be able to be integrated into the current toolchain without much more effort than upgrading a bunch of it. This is still a bit in the future, given that so few are volunteering their time to make this happen (or not sharing any work with the community, fwiw).

To that end, what example SBOM files are available to test against Ovid's CycloneDX SBOM reader?

The CycloneDX spec repo has a test suite that could be integrated into Ovid's work, if someone wants to give it a try (I'll probably do it eventually, though)

• Metacpan can show you the dependency tree for every module.
• Parsing for XS modules should reveal associated C libraries too.
• The METAs and READMEs of a distribution should list third party dependencies.
• The cpantesters matrix should not only prove all of this, but also reveal OS version problems

I didn't dig deep into the WP article and didn't listen to Salve's talk (again²), but this should produce a good reliably founded document for your SBOM.

I'd be interested to know on which grounds this would not meet your army's requirements.¹

After all these documents are mostly written by bureaucrats and BA bachelors who measure software quality by the size and design of accompanying PDFs

Update

¹) actually the article says

• The directive gives the Army 90 days to develop implementation guidance for SBOMs, including sample language for requiring them in contracts

... so it's still vaporware 🤷🏻‍♂️

I wouldn't be surprised if someone charged with "implementing guidance" started googling now and stumbled over this post 🤔

²) I was in the audience, but don't remember much.

But the article you linked to seems to be centered around guaranteeing the supply.

These are two very different beasts, the one centers around getting software running the other one around hardening the dependency chain against manipulation.

Could you please elaborate where your focus is?

Could you please elaborate where your focus is?

LanX accurately identified my post as a general question. In that context I am more interested in the ongoing ability for US federal departments and agencies to continue their ability to use Perl and CPAN. These kind of regulations have a tendency to spread throughout whole administrations over time. So it is a question of maintaining supply. But, I have no dog in this fight, at least not directly.