Request: Add project sustainability fields to CycloneDX

sjn commented 6 months ago

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 commented 6 months ago

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 commented 6 months ago

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

sjn commented 6 months ago

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 commented 5 months ago

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 commented 5 months ago

mjherzog commented 5 months ago

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 commented 5 months ago

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 commented 5 months ago

(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! :grin:

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

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.
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.
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. :sweat_smile:

sjn commented 5 months ago

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 :grin:

Ovid commented 5 months ago

@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 :)

jkowalleck commented 5 months ago

@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 :)

I've added your original post as a block quote in the beginning of https://github.com/CycloneDX/specification/issues/400#issuecomment-2081548042 This was done as a moderation task, to keep track of the conversation and contexts.

ljharb commented 4 months ago

I was asked to share this here: npm's package.json already has a funding field that it'd be convenient for SBOMs to adopt, and the node package maintenance working group has a "support" standard you may find interesting https://github.com/pkgjs/support

sjn commented 4 months ago

@ljharb, thanks! Lots of good ideas to adopt from the schema!

ljharb commented 4 months ago

If it's possible to adopt these standards wholesale, that would be a huge win for interop.

stevespringett commented 4 months ago

Slack channel here: https://cyclonedx.slack.com/archives/C072WMNML75 Invite: https://cyclonedx.org/slack/invite

Workgroup will be kicking of in a few weeks.

christophergates commented 4 months ago

This is a great suggestion as it aligns with the FDA's requirements for "additional" SBOM info, beyond the NTIA, minimum elements. Per the FDA:
In addition to the minimum elements identified by NTIA, for each software component contained within the SBOM, manufacturers should include in the premarket submission:

The software level of support provided through monitoring and maintenance from the software component manufacturer (e.g., the software is actively maintained, no longer maintained, abandoned); and
The software component’s end-of-support date.

jkowalleck commented 4 months ago

Since the nature of sustainability data being dynamic, I wonder if there is a document standard for this. Similar to RFC 9116. If so, we could simply link to it via ExternalReference...

ljharb commented 4 months ago

@jkowalleck https://github.com/pkgjs/support accounts for that by allowing a URL that can be updated out of band :-)

eddie-knight commented 4 months ago

Agreed with @jkowalleck that the mutable / time-sensitive self-reported data points aren't a good fit for SBOMs, and adding values for that will have foreseeable unintended consequences.

If there is a shared hunger on this topic, we should direct the energy to a more appropriate place.

Within the CNCF community, we've aimed to bridge this gap by using and contributing to the emerging Security Insights Specification.

jkowalleck commented 3 months ago

see also: #472

sjn commented 3 months ago

Since the nature of sustainability data being dynamic, [...]

@jkowalleck, Could you expand on this point? What do you mean?

jkowalleck commented 3 months ago

Since the nature of sustainability data being dynamic, [...]

@jkowalleck, Could you expand on this point? What do you mean?

The data might be valid at the time of writing, but may change at any time. It is a snapshot, isn't it? I mean, projects have a life cycle, they are not static.

sjn commented 3 months ago

The data might be valid at the time of writing, but may change at any time. It is a snapshot, isn't it? I mean, projects have a life cycle, they are not static.

If we can think of any project sustainability metadata that can be "quickly" fixed, then I guess they may have a "change at any time" quality to them?

My experience is that when projects tend to signal they need help, it's usually either a lengthy process around this (e.g. for gathering sustainable funding, or when searching and vetting for co-maintainers)...

What type of project metadata are you thinking of, when you say that these may change at any time?

ljharb commented 3 months ago

Almost anything about project support can change in an instant - all it would take is a change of life circumstances (lost a job, medical emergency, a death) or a change of maintainer (a new maintainer shows up who is willing to offer stronger support guarantees, or a maintainer leaves and the remaining maintainers are only willing to offer weaker guarantees).

A package publish shouldn't be needed to update any aspect of a support policy.

sjn commented 3 months ago

I think that making a minor/patch release of a component with just metadata updates sounds like a completely reasonable thing to do. Please note that I'm talking about the support an open source project needs (which is different from the support a project may provide).

Furthermore, having project sustainability metadata closely (and authoritatively) connected to the output of the project just seems sensible to me. Put the metadata inside the published zip file together with the rest of the component code or artifacts!

I get it that some some projects out there wish to refrain from publishing "tiny" updates, but strictly speaking, how the project leaders decide to run their own projects sounds like their own business. I'm looking for ways to communicate upstream signals about sustainability to anyone downstream who cares about these projects, and if we insist that this type of metadata is to be kept separately, I'm afraid they won't be used at all, let alone read.

I'm also assuming we're talking about the "Source SBOMs" (ref) that upstream authors ("Maintainer" in the graph below) could be creating before publishing to some Open Source ecosystem (in the graph: "Language Ecosystem" or "Package Ecosystem" and their downstream consumers).

In my mind, an OSS supply-chain may be simplified to something like this:

stateDiagram-v2
    direction TB

    state "🟥🟨🟦 Maintainer" as environment_maintainer
    state "🟨 Contributor" as environment_contributor
    state "🟩 Collaboration Ecosystem" as ecosystem_repo
    state "🟨🟩 Language Ecosystem" as ecosystem_lang
    state "🟨🟩 Package Ecosystem" as ecosystem_package
    state "🟥🟨 Integrator" as environment_integrator
    state "🟦 Production" as environment_prod

    [*]                      --> environment_maintainer
    ecosystem_repo           --> environment_maintainer
    ecosystem_repo           --> environment_contributor
    ecosystem_repo           --> ecosystem_lang
    environment_maintainer   --> ecosystem_repo
    environment_maintainer   --> ecosystem_lang
    environment_contributor  --> ecosystem_repo
    ecosystem_lang           --> ecosystem_lang
    ecosystem_lang           --> ecosystem_package
    ecosystem_repo           --> ecosystem_package
    ecosystem_package        --> ecosystem_package
    ecosystem_repo           --> environment_integrator
    ecosystem_lang           --> environment_integrator
    ecosystem_package        --> environment_integrator
    environment_integrator   --> environment_prod
    environment_prod         --> [*]

    %% Copyright © 2024 Salve J. Nilsen <sjn@oslo.pm>
    %% Some rights reserved. Licensed CC-BY-SA-4.0

Where these above colors describe different metadata activities some roles may have within the supply-chain. Some of these are 🆕 introductions, needed to live up to obligations in the EU Cyber Resilience Act.

🟥 Author (Authoritative) – Creates, defines, signs metadata — Authoritative roles make sure the metadata and related artifacts they are the author of, Exist.
🟨 Author (Non-authoritative) – Assembles, updates, refines, maintains, attests, annotates metadata — Non-authoritative roles make sure the metadata and related artifacts they process, are Updated and Correct.
🟩 Distributor – Distributes, curates, indexes metadata — Distributing roles make sure the metadata and related artifacts they have, are made Available to others.
🟦 Consumer – Consumes, aggregates, verifies, validates, surveys, analyzes or reports metadata — Consuming roles makes sure the metadata and related artifacts they consume, are Complete, Compliant and Used.
🟪 Censor – Censors, redacts, deletes, anonymizes metadata — Censoring roles make sure that certain metadata about related artifacts are Prevented from being shared with others.

[!Note] Source and supporting docs for this graph can be found on the CPANSec docs page, though this particular one is from an branch that hasn't been merged at the time of this writing, and the "OSS Steward" and "Manufacturer" roles are relevant when taking the EU Cyber Resilience Act into account. Any corrections and comments to this graph is very welcome in it's issue tracker! :grin:

(edit 2024-08-20: updated diagram to simplified version w/o CRA roles)

ljharb commented 3 months ago

Things in a package artifact are immutable, and since a support policy is not immutable, and may change on already published versions, it simply doesn't make sense to me to associate its content with a package artifact. The node package management working group's support standard accounts for this by allowing the package to document a URL, at which JSON support policy data may be found.

I'm not clear on what you mean by "what support a project needs" - do you mean like funding?

sjn commented 3 months ago

I'm not clear on what you mean by "what support a project needs" - do you mean like funding?

Yes, among other things. I gave a couple examples in the OP, but here are a few more in addition to the ones above:

ACTIVE – The project is maintained (default state)
- (number of maintainers is higher than 0)
- (number of maintainers does not need to change)
NEEDHELP – The project is understaffed, and requires additional co-maintainers for sustainable and continued development
- (number of maintainers is higher than 0)
- (number of maintainers is too low)
HANDOFF – The project maintainer is looking for someone to take over the project as a new maintainer
- (number of maintainers is 1)
- (number of maintainers is about to reduce to 0)
ADOPTME – The project is abandoned, or the project maintainer has been confirmed beyond reasonable doubt to be unresponsive, and therefore the project is made available for adoption
- The project needs a new maintainer
- (number of maintainers is 0)
- (number of maintainers is too low)
NOXFER – The project is prevented from being transferred to new maintainers
- The project has been prevented from being adopted, but may still be forked
- (number of maintainers is not relevant)
CUSTODY – This project is under custodianship
- The project is deemed as important for the ecosystem, and needs a trusted maintainer
- (number of maintainers is 0)
DONE – The project is considered "Done", and while it is maintained, no further development is needed or expected
- (number of maintainers is 1 or higher)
- (number of maintainers does not need to change)
DEPRECATED – The project maintainer recommends that this project is not to be used
- (number of maintainers is 0)
- (number of maintainers does not need to change)
UNMAINTAINED – This project is not actively maintained
- Response time expectations should be none
- (number of maintainers is 1 or higher)
- (number of maintainers does not need to change)
CASUAL – This project is only maintained on a casual basis
- Response time expectations should be low
- (number of maintainers is 1 or higher)
- (number of maintainers does not need to change)
NEEDFUNDING – This project needs funding
- Workload is unsustainable with only a volunteer-level commitment
- (number of maintainers is 1 or higher)
- (number of maintainers does not need to change)
NEEDSUPPORT – This project needs non-funding support
- Project growth and sustainability is hindered by lack of non-code contributions
- Examples: Branding development; Code security audit; Event organizing; Documentation writing
- (number of maintainers is 1 or higher)
- (number of maintainers does not need to change)

(work-in-progress source; 2024-07-03: the text above has been updated to the most recent version)

sjn commented 1 month ago

Just for anyone reading this;

The working group for OSS Sustainability will be kicking off on Thursday August 22nd from 11:00am - 12:00pm U.S. Central (4:00pm - 5:00pm UTC).

:point_up: This was a message sent by @stevespringett on the OWASP CycloneDX Slack #workstream-oss-sustainability channel.

Want to join? Here's the invite link.

CycloneDX / specification

Request: Add project sustainability fields to CycloneDX #400

Examples