Graph SBOM Ontology and Lifecycle

[sjn]

To get an idea of what an SBOM means in the CPAN ecosystem, put together a flowchart graph to illustrate the most important steps involved in the evolution of an SBOM document.

[sjn]

Ongoing work is happening in the sjn/supplychain-graph-1 branch

[sjn]

Oof, it seems NIST has published something on this topic: https://www.cisa.gov/sites/default/files/2023-04/sbom-types-document-508c.pdf

They don't take package ecosystems into account at all, apparently?

Same, when looking through some slides from an SBOM workshop at NIST, they also seem to have a lacking idea of what/who's involved in a supply-chain: https://docs.google.com/presentation/d/1OSNYKfSX0sj0ywE3t9_WPYAaCMJnV1ZUztAZwJXmZVI/edit#slide=id.g24f12fef34e_0_10 (…and later slides)

[garu]

Seems to me the NIST documents simply specify different kinds of SBOM that could be implemented throughout the chain.

My understanding is that:

• tools such as Module::Build, Dist::Zilla etc would be of the "Build" type;
• PAUSE/MetaCPAN could analyze released distributions and associate a SBOM of the "Analyzed" type;
• CPAN clients like cpanm/cpm/cpan (or even a completely standalone tool of our own making) could implement one of the "Deployed" type.
• We could potentially even look at runtime caging tools like carton to generate SBOMs of the "Runtime" type.

[sjn]

Hm. I'm unsure. If we assume the following graph is a reasonable simplification of the supply-chain (taking into account the "OSS Steward" role)...

stateDiagram-v2
    direction TB

    state "🟥🟨🟦 Maintainer Environment" as environment_maintainer
    state "🟩 Collaboration Ecosystem" as ecosystem_repo
    state "🟨🟩 Language Ecosystem" as ecosystem_lang
    state "🟨🟩 Package Ecosystem" as ecosystem_package
    state "🟥 Attestation Authority 🆕" as authority_attestation
    state "🟥🟨🟩🟦 OSS Steward 🆕" as ecosystem_steward
    state "🟥🟨 Integrator Environment" as environment_integrator
    state "🟥🟨🟦🟪 Manufacturer Environment 🆕" as environment_manufacturer
    state "🟦 Production Environment" as environment_prod
    state "🟦 Auditor 🆕" as authority_auditor

    [*]                      --> environment_maintainer
    ecosystem_repo           --> environment_maintainer
    environment_maintainer   --> ecosystem_repo
    environment_maintainer   --> ecosystem_lang
    ecosystem_lang           --> ecosystem_lang
    ecosystem_repo           --> ecosystem_lang
    ecosystem_lang           --> ecosystem_package
    ecosystem_repo           --> ecosystem_package
    ecosystem_package        --> ecosystem_package
    ecosystem_package        --> ecosystem_steward
    ecosystem_lang           --> ecosystem_steward
    authority_attestation    --> ecosystem_steward
    ecosystem_repo           --> environment_integrator
    ecosystem_lang           --> environment_integrator
    ecosystem_package        --> environment_integrator
    ecosystem_steward        --> environment_manufacturer
    environment_integrator   --> environment_prod
    environment_manufacturer --> environment_prod
    environment_prod         --> authority_auditor
    environment_manufacturer --> authority_auditor
    authority_auditor        --> [*]

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

Loading

(source)

I'm thinking the following would make sense:

Maintainer Environment = "Source SBOM"

• This is what's included in the tarball before publishing.
• Any tooling that is involved in creating this tarball may be involved in the creation of this SBOM.

Language Ecosystem = "Source SBOM"

• No changes made to what the Maintainer has published, except possibly for updates to the SBOM metadata (e.g. correcting download location, or updating sustainability metadata).
• This is where PAUSE/MetaCPAN does their thing.

Package Ecosystem = "Build SBOM"

• When creating a system package from a CPAN dist, a build and installation step is executed, meaning dependencies have to be resolved and ensured they are present.
• This is where any tooling involved in creating packages is involved.
• This could include cpan.pm &c., dh-make-perl or anything else that produces a dpkg, rpm or other system package.

Integrator or Manufacturer Environment = "Build SBOM" or "Deployed SBOM"

• Same as in the Package ecosystem, the build and installation steps are executed, though now with a wider range of dependencies resolved (e.g. service and out-of-ecosystem dependencies), in addition to other dependencies supplied by the deployment environment.
• So I think both "Build" and "Deployed" may be involved, depending on circumstances. E.g. if one deploys to a container, then the base image has "Deployed" metadata associated with it, and may get any Manufacturer's application metadata added on top.

Production Environment = "Deployed SBOM" or "Runtime SBOM"

• No building should happen here, so it should all be deployed. Runtime execution environments may be involved, but unsure what this would entail in the CPAN space. Maybe Linux::Landlock? :-)
• Though there may be exceptions - for example with dynamic updates of plugins or UI components from third parties (ouch!)

Other SBOM types

• The "Analyzed" seems to me is only useful for the situations where upstream metadata isn't available, and must therefore be inferred from what's available inside the execution environment.
• "Design" SBOMs don't seem to be relevant for what we're doing here? Unsure why they're mentioned. Maybe a system/component Owner supplies some basic metadata about ownership-related things (License, company website, etc.)