Set supplier instead of author to Conan

[fschoenm]

We would like to use Conan's SBOM generation in our organization but there are still a few obstacles. For one, our organization requires the supplier to be set (while the author is optional).

This seems to match the description about "minimum elements" in https://www.ntia.doc.gov/files/ntia/publications/sbom_minimum_elements_report.pdf, which requires the "Supplier Name" for components and the "Author of SBOM Data". I believe the interpretation in the original PR (#80) was mistaken.

From the CycloneDX spec:

• component.supplier: The organization that supplied the component. The supplier may often be the manufacturer, but may also be a distributor or repackager.
• component.author: The person(s) or organization(s) that authored the component.

In our interpretation, the author is the developer of the component, while the supplier is Conan/Conan Center in this case. (There's a separate field for the author(s) of the SBOM itself.) Both fields are optional from a spec point of view, which is why I set the author to None.

Please let me know what you think in case you disagree.

cc/ @danimtb

[CLAassistant]

All committers have signed the CLA.

[dkoerner-festo]

Hello @fschoenm,

setting the supplier to Conan would not be correct for company internal packages.

Do you know https://github.com/Festo-se/cyclonedx-editor-validator ? We use this tool to "fix" the SBOM to our needs. Maybe this would also solve your problem.

[fschoenm]

@dkoerner-festo That's true. But what would be your proposal? Setting the supplier is mandatory in our organization and (apparently) also for the US government, while the author is an optional field and additionally set to a misleading value by the current implementation.

[memsharded]

Just as an extra hint, this is an extension command. It is not built-in, and it is designed so users can fork it, customize it to their needs and conan config install or conan config install-pkg it, and use it from their fork. This "conan-extensions" repo doesn't aim to be the unique and canonical way of doing things, but serving as a base to users to have their own customized variations.

[fschoenm]

@memsharded I'm aware of that but keeping our own version as close as possible to the "source" version here makes integrating upstream changes much easier.

Not sure why no one is commenting on the intent of this PR though. Shouldn't this extension at least meet the requirements of the linked PDF, or do you have a different goal in mind?

[dkoerner-festo]

@dkoerner-festo That's true. But what would be your proposal? Setting the supplier is mandatory in our organization and (apparently) also for the US government, while the author is an optional field and additionally set to a misleading value by the current implementation.

I'm not a SBOM expert, but as far as I know, setting the author also fulfills the NTIA requirements.
If required, I would use the "amend" feature of the cyclonedx-editor-validator to set the supplier (e.g. based on the author?).

[dkoerner-festo]

@fschoenm And we also have our own version of the extension ;)

[fschoenm]

setting the supplier to Conan would not be correct for company internal packages.

@dkoerner-festo I could use the extension_properties attribute to manually set a different supplier in the conanfile:

    def create_component(node) -> Component:
        extension_properties = getattr(node.conanfile, "extension_properties", {})
        purl = package_url(node)
        component = Component(
            type=package_type_to_component_type(node.conanfile.package_type),
            name=node.name or f'UNKNOWN.{id(node)}',
            author=node.conanfile.author if node.conanfile.author else None,
            supplier=OrganizationalEntity(name=extension_properties["supplier"] if "supplier" in extension_properties else "Conan"),
            version=node.conanfile.version,
            licenses=licenses(node.conanfile.license),
            bom_ref=purl.to_string() if purl else None,
            purl=purl,
            description=node.conanfile.description
        )
        if node.conanfile.homepage:
            component.external_references.add(ExternalReference(
                type=ExternalReferenceType.WEBSITE,
                url=XsUri(node.conanfile.homepage),
            ))
        return component

Then it would be possible to set it like this in a conanfile:

def ConanPkg(ConanFile):
    extension_properties = {"supplier": "Company Inc."}

[memsharded]

component.supplier: The organization that supplied the component. The supplier may often be the manufacturer, but may also be a distributor or repackager.

The truth is that the large majority of users don't use packages from ConanCenter directly in production, but they build their own binaries from source, due to compliance, regulatory or other industry constraints. We are happy with this, and we even created the local-recipes-index to further simplify this flow. That means that the component, understood as the package binary included in the SBOM, was not supplied by ConanCenter in the majority of cases. And I don't think Conan makes sense as a supplier of packages in any case, that would be just the technology used to create the packages, not the package supplier.

[fschoenm]

That means that the component, understood as the package binary included in the SBOM, was not supplied by ConanCenter in the majority of cases. And I don't think Conan makes sense as a supplier of packages in any case, that would be just the technology used to create the packages, not the package supplier.

@memsharded Wouldn't it make even less sense to set "Conan" as the author of a component then?

[memsharded]

@memsharded Wouldn't it make even less sense to set "Conan" as the author of a component then?

Yes, I think you are right, but I am not SBOM expert, so probably contributor @hedtke and cyclonedx @jkowalleck could give some advice here.

[jkowalleck]

[...] which requires the "Supplier Name" for components and the "Author of SBOM Data"

"Author of SBOM Data" could be done in either one of those:

• $.metadata.authors -- since CycloneDX 1.6
• $.metadata.manufacturer -- since CycloneDX 1.6

Both, authors and manufacturer, are legal entities. Not tools nor machines.
So the author of your SBOM might be yourself. The manufacturer might be your organization.

Tools used for generating the SBOM go to $.metadata.tools.
This is where Conan itself and the plugin should be listed, and the CycloneDX python library also.

"Supplier Name" for components would be

• $.components[].supplier

Please be aware, that a component's supplier is a legal entity. The only one who is able to tell who that supplier is, is the one who is supplied by them - which is you, @fschoenm.

---

@fschoenm, please be aware, that SBOM generators are just one part of the tooling you may use for legally binding SBOM generation. They help you to gather some facts and evidences. They are not intended to provide a ready-to-use all-purpose SBOM.
You may want to enrich/alter/reduce a tool-generated SBOM for the actual real-world needs you are facing.

[fschoenm]

@jkowalleck I'm aware of these facts but they're not particularly helpful in determining the outcome of this PR, so I have some questions:

• Do you agree or disagree, that "Conan" is the correct author of subcomponents as has been added to the extension in [fix] sbom: Add Conan as default component author #82?
• Do you agree or disagree that "Conan" is the supplier of Conan packages from Conan Center and/or the conan-center-index?

[jkowalleck]

* Do you agree or disagree, that "Conan" is the correct author of subcomponents as has been added to the extension in [[fix] sbom: Add Conan as default component author #82](https://github.com/conan-io/conan-extensions/pull/82)?

Disagree. conan is a tool, not a legal entity.
as stated above.

* Do you agree or disagree that "Conan" is the supplier of Conan packages from Conan Center and/or the conan-center-index?

Disagree. conan is a tool, not a legal entity.
as stated above.

again: YOU or YOUR ORGANIZATION are the author/manufacturer of the SBOM, some tool you use in the process.
again: a package registry or tool or service can not be a supplier.

[fschoenm]

@jkowalleck Nothing in this whole PR is about $.metadata.authors but about $.components[].author (and $.components[].supplier and their difference). I don't know if you're misunderstanding me on purpose but it makes this whole discussion leading nowhere.

[jkowalleck]

@jkowalleck Nothing in this whole PR is about $.metadata.authors but about $.components[].author (and $.components[].supplier and their difference). I don't know if you're misunderstanding me on purpose but it makes this whole discussion leading nowhere.

you must be joking, right?

it was you how told that they were looking for a solution for "Author of SBOM Data" according to NTIA compliance. and the answer is: $.metadata.authors etc.

I am not here for your wrong implementation, but to teach you SBOM in general :-)

[jkowalleck]

this was wrong in the first place: "Conan" is a tool, not a legal entity, and may not be an author nor supplier.

[fschoenm]

@jkowalleck

it was you how told that they were looking for a solution for "Author of SBOM Data" according to NTIA compliance.

I did not. This whole PR is about how to set supplier and author of components.

[hedtke]

I am on sick leave. Will be able to look into it in some weeks

[dkoerner-festo]

In my opinion, the extension should not add any data that is not directly derived from the package metadata. The current solution of setting the author to Conan is not correct.

We also have our own fork of the extension. We set the copyright for our own packages, but that's not a generic solution either.

I like @fschoenm idea of setting some fields based on extension_properties.

@memsharded how about adding the commonly used SBOM fields as Conan package metadata? (e.g. copyright, supplier)

[memsharded]

@memsharded how about adding the commonly used SBOM fields as Conan package metadata? (e.g. copyright, supplier)

This seems it could be a down the rabbit hole issue, with more and more requests to further add a new field of the many that can be found in https://cyclonedx.org/capabilities/sbom.

And adding fields in conanfile.py that are of no use to Conan itself doesn't make much sense.

Then I would advice to probably use the generic conan_data structure, that is loaded from conandata.yml (which might further help in automation), and users can define there an sbom entry with as many different values as necessary. And this extension can read and use them.

[shoeffner]

The specs state that manufacturer could be used when using automated processes:

Manufacturer is common in BOMs created through automated processes.

So when conan generates a BOM, it should probably set $.metadata.manufacturer to my org, but when we do manual changes (e.g., adding some vulnerability audit trail) we should add the individuals (or the org as a legal entity?) as $.metadata.authors, do I understand that correctly?

Please be aware, that a component's supplier is a legal entity. The only one who is able to tell who that supplier is, is the one who is supplied by them - which is you

So assuming I would create a some application and included this very extension in it. Who would be the supplier for this extension? I always understood it that I/my Org is the supplier when we deliver it to customers. Or would @memsharded be the supplier without knowing that he supplied me?

Additionally, as I pointed out in #146, I am unsure conan's definition of "author" does match the SBOM definition, I think they do not match. In conan, "author" is the recipe author or maintainer (see https://docs.conan.io/1/reference/conanfile/attributes.html#author and https://docs.conan.io/2/reference/conanfile/attributes.html#author), not necessarily the author of what we package with that recipe. In SBOM the metadata.author would be the SBOM author, and $.component.author the author of what we package, not the recipe – unless it's the conanfile.py we package.