Request: Add project sustainability fields to CycloneDX

[sjn]

Hei!

I just came across the following blog post by John Mark.

https://aint.johnmark.org/2024/01/07/the-open-source-supply-chain-was-always-broken/

There, he proposes something which I think is a brilliant idea:

Add a sustainability clause to your Software Bills of Materials (SBOM) requirements.

Has there been any discussions around this before?
How would one represent sustainability metadata (e.g. project status or a funding url) in a CycloneDX SBOM?

Personally, I think this type of information is extremely important for an Open Source component/project to pass on to it's users, and for many, it may be a question of life and death for the project. When the project bus-factor is too low for sustainable development, then both upstream developers and downstream users would benefit from this fact to be communicated.

Examples

In the CPAN ecosystem, we operate with a few special signals for this purpose (source: The PAUSE Operating Model; Field names are capitalized for emphasis):

• ADOPTME – The project is abandoned, or the owner has been confirmed to be unresponsive, so the project is now available for adoption (number of maintainers is 0)
• HANDOFF – The project owner is looking for someone to take over the project (number of maintainers is 1 and about to become 0)
• NEEDHELP – The project is understaffed, and requires additional co-maintainers for sustainable and continued development (number of maintainers is too low)
• NOXFER – The project is prevented from being transferred to new owners

In addition, authors may decide that an Open Source project is accepting donations, selling support, or is employing some other income model in order to either make continued development sustainable, or to run a for-profit business around the project. If this is the case, there would be need for an URL for users to use to learn more about these funding options.

• FUNDING_URL – A URL to a webpage describing how the user of a component may fund the continued development of the component.

And related to this, if the component author wishes to conform to EU regulations, there needs to be a way for this to be communicated

• CE_DECLARATION – A URL, linking to declaration of conformance to the EU Cyber Resilience Act, as required in CRA Annex II, point 6; and Chapter III, Article 28; and in Chapter II Article 13(20).
• CE_DOCUMENTATION – A URL linking to supporting information and instructions (CRA Annex II, point 8)
• CE_CONFORMITY_BODY – A URL pointing to the Conformity Assessment Body where this component has been registered (CRA Article 22(4) and Article 58(1))
• CE_SUPPORT_END_DATE – The date for when the support for the component expires (Annex II, point 7)

There might be more fields required (or useful).

Does this make any sense? :-)

[sjn]

BTW, the references (above) to the CRA may have changed since the 2023-12-20 draft.

They did change! I've updated the new articles and points to the 2024-03-12 version that was voted in by the EU parliament.

[stevespringett]

Dumb question... What does CE in CE_DECLARATION stand for?

[sjn]

Dumb question... What does CE in CE_DECLARATION stand for?

Not a dumb question! It stands for Conformité Européenne, and it's the EU's way of letting manufacturers of devices (and starting in 2024 with the Cyber Resilience Act, "products with digital elements") show that they are conforming to EU law.

The reason I've added it to the list above, is that with the Cyber Resilience Act, they requires a bunch of new fields to be communicated to downstream customers or users. These are laid out in Annex II if the CRA. (Link is to the latest version voted in by the parliament on March 12th 2024. Updates and changes may still be added.)

[sjn]

Note to posterity: CRA's Open Source Steward role will probably also need a couple of fields. At the moment, I'm thinking one field for specifying that the open source component is "intended for commercial use", and another one specifying which legal person is accepting the Steward's role.

[jkowalleck]

see also:

• Add externalReferences.type = funding #445

[mjherzog]

This is information that is more likely to apply to a project than a package or component so I am skeptical that it belongs inside an SBOM. And it seems a stretch to say that this would be a practical mechanism to " add a requirement that they [suppliers] contribute to the sustainability of the projects they build into their products."

[jkowalleck]

This is information that is more likely to apply to a project than a package or component

I guess I understand what you mean, but you are wrong.
My reality looks different:

Every month, some packages I use are no longer maintained. My package manager also tells me about these facts. Sometimes the unmaintained package have a note on them, which package to use instead, or whether this package wants to be adopted, which my package manager also tells me about.
Some packages are still maintained, but are looking for funding or additional maintainers - also a thing my package manager might tell me about.

So I completely see the information on a component-level.

I said, the package manager tells me about the mentioned facts. Thing is, I do not monitor these messages, as they run automated in CI/CD pipelines.
What I do monitor is the SBOM that such pipeline produces.

---

Besides all that, projects may work on several packages. And sometimes they have package-reboots which end up in a package being discontinued, and replaced by another one ... Meaning the project is healthy, but one package is dead.

---

PS:

I am skeptical that it belongs inside an SBOM

CycloneDX is a document standard for more than just SBOM.

[sjn]

(The following quote was an original message from @sjn. It was added back in here for context, as the original got deleted, as explained here and here.)

Hi folks. I know most of you have no idea who I am, so you are justified in being skeptical of the following. @sjn , on the other hand, knows me well, has done for a long time, and will probably vouch for me as a trustworthy source (for whatever that's worth).

I would recommend caution with the NOXFER. I want to be as delicate as I can here, but I know of at least one open-source project, used by tons of companies, that is very low-level and has an entire ecosystem built on top of it. The sole maintainer of the project has abandoned it, but requested NOXFER. They also refuse to allow anyone else to maintain the project and due to the size of the ecosystem, it is very, very difficult to replace the module. There are many open tickets against the project, for both bug fixes and enhancements. There are also many pull requests which have been ignored.

It's been a couple of years since the last release and the author has told me directly that if I continued to pursue supporting that module, they'd block me from all communication and that I need to "let sleeping [projects] lie." It's become a critical issue for some of my clients.

Maybe NOXFER is something that should be here because I can't say I know enough about the topic. For an individual company, if they have a restrictive license, I can understand the NOXFER, but for an open source project released under a liberal license, with a NOXFER applied to keep people hostage, that's bad.

@Ovid, thanks for dropping by! 😁

The reasons I chose to add NOXFER to the suggestions here, are..

1. This is a type of "project status" that actually exists and is in use. Though it isn't much in use, there are apparently situations that can happen where communicating this particular situation is both useful and necessary.
2. If a downstream business has a dependency that has been "taken hostage" in this way, this may prompt them to look for what options they have – forking it, code around the dependency, re-implement it, or even switch to another ecosystem if this makes economically sense.
3. Not communicating a situation like this poses also risks to the component's users, though I guess those are of a different kind? In any way, it's probably better to allow the user to decide how to respond to this situation, instead of the intervening communications channels making a decision on the matter, by preventing the communication of this event. 😅

[sjn]

A quick apropos: OWASP also has a project going on that they call "Common Lifecycle Enumeration", where they want to create an overview with a focus on "lifecycle events" instead of "project sustainability".

Not sure to what extent this project's goals overlap with their's, but maybe someone who has insider knowledge can share some thoughts? @stevespringett 😁

[Ovid]

@sjn Sorry for deleting my original comment and leaving your comment orphaned. I deleted it before I saw your response. I realized that this is almost certainly informational, and not binding, so it's a different kind of metadata so my concerns probably don't apply here. Carry on :)