Hi CDX team, We would like to register top-level namespaces for sonatype . It will be used by the Lift project and administered by Lift maintainer.
our public taxonomy link is here: https://help.sonatype.com/lift/open-source-vulnerability-analysis/dependency-view/cyclonedx-lift-namespace-taxonomy
Thank you for taking your time.

On behalf of IBM, I kindly request to reserve the namespace 'ibm' for use in IBM produced public SBOMs.

Namespace to be reserved

Planned usage

Currently, we plan to use this as an alias (short form) for our current URN (i.e., urn:ibm:names) to add/associate domain specific information such as:

• IBM product and deliverable IDs to component properties
• additional scan/internal tooling/classification information to component properties
• risk and confidence scoring information to component properties
• legal (usage, coverage) disclaimers to metadata properties for customers

Goal: Simplification

Reduction in length of property name value:

{
"name": "urn:ibm:names:identifier:product",
"value": "5737-I23"
} 

would be simplified to:

{
"name": "ibm:identifier:product",
"value": "5737-I23"
} 

Note It is my hope we support URN syntax as well (and update the ABNF for package names correspondingly). See issue: #9

@jkowalleck, hoping I can get your advice on this one.

For example, PRs for the gomod namespace should go to Go Maintainers team for review and merging.

Is that possible while limiting access to other areas of this repo?

And, to make it easier to define, should the existing file cdx/gomod.md be moved to a sub-directory? i.e. all Go related files go under the cdx/go directory or something like that?

I would like to request to add a new top-level appknox namespace: https://github.com/appknox/cyclonedx-property-taxonomy

@appknox is a mobile application security testing platform. We are currently working on features that will enable our clients to generate a CycloneDX SBOM reports. More about Appknox here: https://www.appknox.com/

I have created a new PR for the same: #38

Dear all,

in my role as Technical Manager at Accellence Technologies I would like to register a new top level namespace for our company.

Our software products are widely used as OEM components in industrial solutions, where we need to produce and/or consume CycloneDx SBOMs. To keep tracking through out the hole software distribution process and to fulfill the requirements by our customers, we are using several custom properties

Our taxonomy is public available. PR is up to opened.

Thanks to all the contributors for your effort to create the cdx specification. Great work!

Best Regards

Benjamin Lilienthal
Technical Manager

Accellence Technologies GmbH
Garbsener Landstr. 10
30419 Hannover, Germany

Managing Director: Dipl.-Inf. (FH) Frank Christ, Dr.-Ing. Heinz Stephanblome
Registered office of the company: Hannover, HRB 110799 Hannover

This issue is a request to add a new top-level property namespace of vulncheck. VulnCheck is in introducing support to ingest CycloneDX SBOMs for security analysis and then enrich them with results and other data. We currently have not settled on our taxonomy and so are just requesting the namespace to be reserved with plans to publish the documentation in the future.

If there is any additional information I may be able to provide, please just let me know. Thank you.

Andrew R. Reiter
[email protected]

Dear all,

in my role as Open Source Officer and Product Security Officer at Bosch Rexroth I would like to register a new top level namespace for Bosch Rexroth.

Namespace | Description | Administered By | Taxonomy

rexroth | Namespace for use by Bosch Rexroth | Bosch Rexroth | RESERVED

Before using the RESERVED namespace, I will document the taxonomy of the namespace and make publicly available.

Best Regards

Klaus Ziegler
Engineering Excellence - processes, methods, tools DC/ENE1

Tel. +49 9352 18-6225
Fax +49 711 811-5171669
Mobil +49 152 22615021
[email protected]
www.boschrexroth.com

Bosch Rexroth AG
Maria-Theresien-Straße 23
97816 Lohr am Main
GERMANY

Sitz: Stuttgart, Registergericht: Amtsgericht Stuttgart HRB 23192
Vorstand: Dr. Steffen Haack (Vorsitzender), Thomas Donato, Holger von Hebel, Reinhard Schäfer
Vorsitzender des Aufsichtsrats: Dr. Markus Forschner

Several teams across Siemens are working on tools that produce and/or consume CycloneDx SBOMs with some of these tools already seeing production use internally.

We are using custom properties as part of this effort and would like to register our own siemens namespace that we can group these under.

At present we cannot provide a publicly available taxonomy, but I will discuss making one available with the colleagues.

Thanks to the entire CycloneDx team for all the effort that goes into this specification, it's been a big help!

Related to: CycloneDX/specification#36

Request to register a TLN for hoppr. For use by the Lockheed Martin Hoppr project.

Public docs for taxonomy: https://gitlab.com/lmco/hoppr/hoppr/-/blob/main/docs/architecture/cdx_taxonomy.md

Thanks!

We request you to kindly reserve the namespace 'expliot' for EXPLIoT Framework.

Namespace to be reserved

About

EXPLIoT is an open source framework for security testing and exploiting IoT products.

Source

https://gitlab.com/expliot_framework/expliot

Documentation

https://expliot.readthedocs.io/en/latest/

CycloneDX EXPLIoT Taxanomy

https://gitlab.com/expliot_framework/expliot/-/blob/master/docs/compliance/cyclonedx.rst

Hi,
I'd like to request a new TLN: recon.
Recon is a general purpose recon toolkit, with the upcoming ability to generate content SBOMs proofs. The taxonomy is still WIP (but can be looked at in the original project).

Request namespace for KSOC Inc. ecosystem

Name: ksoc
Description: Namespace for use by KSOC Inc.
Administered By: KSOC
Taxonomy: https://github.com/ksoclabs/kbom/blob/main/docs/taxonomy.md

For now we would like to use ksoc:kbom namespace as this taxonomy is used by kbom tool, but in the future we would like to extend it and use more generic ksoc:

In #70, there is no allowance for a timestamp when cdx:reproducible is set to true. Instead, I think that it should be allowed if the time is reproducible (e.g., by using a date derived from the sources to indicate "last edit" or something like SOURCE_DATE_EPOCH to pin a time for tooling to use during a build.

The cdx namespace should include a property to hold the path of the file that produced the dependency.

Vendors have started included such a property in their namespaces; the lack of standardization around the storage of this information is creating a significant interoperability problem.

For example, GitLab uses gitlab:dependency_scanning:input_file:path.

If this property is standardized, other SBOM producing tools will be more likely to include this information, and SBOM consumers will more likely use it.

Please add the "scribe" namespace for use by Scribe Security.
Administered By: https://scribesecurity.com

This issue is a request to add a new top-level property namespace of finitestate. This namespace will be used to add custom properties containing values relevant to SBOMs produced by the Finite State firmware analysis platform.

For more company information, please see https://finitestate.io/

Thanks!

This is a request to add the top-level namespaceobserver used by SBOM Observer for metadata in exported SBOMs.

The initial taxonomy is available and in active use.

Will follow up this issue with a PR for the requested addition.

Please let me know if there is any additional information needed.

Regards,
Andreas Bielk / [email protected]

currently working on https://github.com/CycloneDX/cyclonedx-node-npm
and found that some properties/evidences are not possible to model in existing CDX spec, as they are specific to node/npm.

I would like to have an own namespace cdx:npm to make these properties part of generated CDX data.

We'd like a medical-aegis namespace reserved. The taxonomy is currently a work in progress. Thanks.

Description

I was hoping to get this package registered for the Grype project. I'll tag the maintainers to chime in here

The cdx:device:certifications has the following description:

cdx:device:certifications:<ISO-3166-1>	ISO-3166-1 alpha-2 country code of a certifying authority
cdx:device:certifications:<ISO-3166-1>:<AUTHORITY>	Abbreviation of the certifying authority (e.g. FCC, UL, and CE)
cdx:device:certifications:<ISO-3166-1>:<AUTHORITY>:id	Identifier for radio components.
cdx:device:certifications:<ISO-3166-1>:<AUTHORITY>:url	URL to certification details.

However, what's not very clear is if <ISO-3166-1> and <AUTHORITY> are part of the name or if the spec is saying those are just placeholders for the country code and certifying authority, in which case there are only 2 possible names (id and url) that certifications is describing.

So is it:

cdx:device:certifications:<ISO-3166-1> : US
cdx:device:certifications:<ISO-3166-1>:<AUTHORITY> : FCC
cdx:device:certifications:<ISO-3166-1>:<AUTHORITY>:id : 12345
cdx:device:certifications:<ISO-3166-1>:<AUTHORITY>:url : example.com

-OR-

cdx:device:certifications:US:FCC:id : 12345
cdx:device:certifications:US:FCC:url : example.com

Domain: https://www.interlynk.io/
Source: https://github.com/interlynk-io/
Contact: [email protected]

Motivation

As a CycloneDX consumer, I would like the ability to validate whether all the components declared their expected cryptographic checksum. In SLSA v0.1, for example, checksums are recommended for hermetic builds (all dependencies must be declared with immutable references).

CycloneDX components have the hashes attribute. However, an empty hashes array does not necessarily mean that the component is missing a checksum - perhaps the component cannot have, and does not need, a checksum.

For example:

A Go project can be split into multiple modules which can depend on each other. Such a dependency is expressed via local replacements: replace my.org/my-project/api => ./api. A locally replaced module will not have a checksum in go.sum, nor should it need one (it is version-controlled along with the module which depends on it).

Many package managers allow the user to depend directly on a git repository. Such dependencies also do not have checksums, they instead rely on the commit hash for integrity.

Proposal

Would you be open to adding a cdx namespace for security considerations such as this one?

Perhaps a cdx:security:missing-checksum "boolean" property? Semantics would be along the lines of: "true if the component could have declared the expected cryptographic checksum but didn't"

Hi,
(this is a followup to CycloneDX/cyclonedx-python#374 (comment))

It is common for dependency managers to implement a concept of categories corresponding to the different scenarios in which each dependency should be used. This information can be useful, for instance in a legal compliance analysis context.
Npm, for instance, has two categories: dependencies and Devdependencies, and those are already taken into account by CycloneDX:
in is currently implemented with the property cdx:npm:package:development.

For Poetry, it could be like the following: https://github.com/camillem/cyclonedx-property-taxonomy/blob/main/cdx/poetry.md

cdx:poetry Namespace Taxonomy

cdx:poetry:package Namespace Taxonomy

The property is named category and not group in order to be consistent with the content of the poetry.lock files.

At a later stage, it may be relevant to have a cross-package manager property of this kind.

Thanks,
Camille

Fortify has introduced support to produce and import CycloneDX SBOMs, and CycloneDX will feature as our primary/preferred SBOM standard moving forward. We anticipate future enhancements to our output SBOMs that may have Fortify-specific properties and would like to request a reserved 'fortify' namespace in preparation for future development.

Request namespace for ByteTrail Fusion ecosystem

Name: bytetrail
Description: Namespace for use by ByteTrail
Administered By: ByteTrail

I am requesting registration of a new top level namespace,

Namespace: aboutcode
Description: Namespace for use by AboutCode.org projects, including scancode-toolkit.
Administered by: nexB
Taxonomy: https://github.com/nexB/aboutcode-cyclonedx-taxonomy

We believe that the properties defined for this namespace are valuable for both the generation and consumption of CycloneDX-formatted SBOMs.

Hi,

I would like to reserve new namespace: codenotary

Codenotary provides SBOM and software supply chain software like Trustcenter, and we use CycloneDX among other formats for SBOMs creation and analysis.

It is a common practice to construct namespaces using URNs to describe resources (e.g., tag or classify resources such as components, tools, and the like). It is designed to avoid collisions and also be used to construct URIs and URLs which are also common means to encode a plurality of identifiers.

See:

• https://en.wikipedia.org/wiki/Uniform_Resource_Identifier

Some examples lifted from linked wikipedia document include:

urn:isan:0000-0000-2CEA-0000-1-0000-0000-Y // Book ID
urn:microsoft:adfs:claimsxray           // MS federated ID
urn:epc:id:gdti:0614141.12345.400  // Global Doc ID

as you can see, namespaces are constructed an urn:<org>:<domain>:<subdomain>:<...>:<value> manner; this should be allowed by syntax.

This issue requests that the syntax for CDX namespace should support URN syntax. My primary concern is that its allowed character set (pattern) would not be rejected. From current syntax, multiple ":" colon chars. are strictly disallowed.

Hoping we allow direct transfer of widely adopting URNs into properties within CDX as many companies use them in some form for federated identity and or taxonomy classification systems.

Ideally, if you indeed want simplicity, an aliasing methodology can be used (e.g., as in many schema strategies) to define a local document use of, for example:

• alias: xyz:
• full urn urn:http://company.xyz.com

Additionally, it should be noted that URNs are designed not to require registration as designers would construct them using unique pathing; as managing a global registration system can become untenable. Registration of values or IDs should be managed by the namespace owners.

GitLab is working on creating a component inventory that is powered by CycloneDX SBoMs, which you can read more about at Ingest SBoM Reports. We'd like to register a new namespace to support this and any other integrations which we may build with CycloneDX.

You can find our taxonomy at https://gitlab.com/gitlab-org/security-products/gitlab-cyclonedx-property-taxonomy.

Thank you for all your work on CycloneDX!

Hi,

This is a proposal to add a new Namespace for Maven under cdx namespace.
For example something like cdx:maven similar to npm.

With this a property to specify the scope of the dependency scope. i.e https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#dependency-scope
which can be repreented as cdx:maven:package:scope

At Snyk we use CycloneDX documents internally and are also looking to make CycloneDX documents part of our user-facing services. To improve the quality of our documents and to give them more value for our users, we would like to introduce a snyk namespace for custom, proprietary properties.

We would like to record information in properties which don't have a place elsewhere.

For that we'd like to request a namespace under cdx.

Our idea is to have two namespaces: rustc (or rust?) and cargo.

@Shnatsel:

So that concepts that exist on the rustc level could still be encoded regardless of the build system. There are use cases for rustc without cargo , usually when embedding in a mixed-language project. Bazel and Meson are commonly used in this case instead of cargo.

Once a decision has been reached we're happy to provide the proper PR for this issue.
One namespace would probably be empty at this moment but the other one (rust) will include the target architecture which e.g. Go already does as well using the property name cdx:gomod:build:env:GOARCH. For rust it would probably be called rustc:target or similar.

Information about the images and their layers via properties is useful while generating SBoM for oci images. Trivy uses the following names.

• aquasecurity:trivy:LayerDigest
• aquasecurity:trivy:LayerDiffID
• aquasecurity:trivy:ImageID

Syft uses the following

• syft:location:0:layerID
• syft:location:1:layerID

Instead of requesting another one for cdxgen and other orgs, could we come up with something generic using "org.opencontainers" etc? Example:

• org.opencontainers.image.layer.digest
• org.opencontainers.image.layer.id
• org.opencontainers.image.id

We're working on mapping Kubernetes clusters composition as BOM (aka "KBOM"). For that, we want to use properties to designate cluster components roles, and attributes that are meaningful to understanding the cluster composition.
For example, here's a snippet from generated KBOM that describes a Kubernetes API Server component:

{
      "bom-ref": "e86fd8d5-c302-4c44-b1b2-833b97540f13",
      "type": "application",
      "name": "kube-apiserver-kind-control-plane",
      "properties": [
        {
          "name": "aquasecurity:trivy:SchemaVersion",
          "value": "0"
        },
        {
          "name": "aquasecurity:trivy:k8s:controlplane_components",
          "value": "apiserver"
        }
      ]
}

We're proposing to register a kubernetes namespace for the Kubernetes-specific metadata.
As for usage, for now, we are following the Kubernetes taxonomy as defined here: https://kubernetes.io/docs/concepts/overview/components/
Which means we will add:

1. kubernetes:controlplane_component
2. kubernetes:node_component
3. kubernetes:addon

If this is acceptable, I'll create a PR with the namespace reservation and initial documentation.

This issue is a request to add a new top-level property namespace of veracode. This namespace will be used to add custom properties containing values relevant to SBOMs produced by the Veracode's analysis platform.

For more company information, please see https://github.com/veracode/cyclonedx-property-taxonomy.

Thanks!

Motivation

We have a number of customers that want HBOM like data from us (i.e. a list of components), but they want to also know the country of origin of the component and currently the CDX HBOM does not appear to provide this information.

Proposal

Here's what I have in mind:

• Add an optional property to the component with a "name" of "cdx:device:countryOfOrigin" (at least that's what it would be in SPDX JSON format).
• What constitutes the country of origin is defined in International Certificate of Origin Guidelines: Facilitating trade through global origin procedures provided by the International Chamber of Commerce. This is commonly used in international trade to provide a Certificate of Origin for an item.
• The country of origin would be noted in the corresponding "value" field using ISO-3166-1 alpha-2.

Example:

{
// ...
"properties": [
        {
          "name": "cdx:device:countryOfOrigin",
          "value": "TW"
        },
        // ...
],
}

We would like to request a new Top Level Namespace:

Namespace: amazon
Description: Namespace for use by Amazon.
Administered By: Amazon
Taxonomy: RESERVED (Work in Progress)