Git Product home page Git Product logo

cyclonedx-property-taxonomy's Introduction

CycloneDX Property Taxonomy

shield_license shield_website shield_slack shield_groups shield_twitter-follow

This is the official CycloneDX property namespace and name taxonomy.

Introduction

With the v1.3 release of the CycloneDX specification, custom properties have been added.

Although the specification doesn't impose restrictions on the property names used, standardization can assist tool implementers and BOM consumers.

The authoritative source of official namespaces and property names is this repository.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119.

Namespace Syntax

Namespaces are hierarchical and delimited with a :.

As such, : MUST NOT be used in property namespaces and names except as a delimiter.

The only characters that SHALL be used in official property namespaces and names are alphanumerical characters, "-", "_" and " " from the US ASCII character set.

Namespaces SHOULD be lower case. Base property names MAY use upper case.

Examples

internal:information_security_classification
internal:team_responsible

ABNF for Official CycloneDX Property Names

property-name = 1*(namespace ":") name

namespace     = 1*namechar

name          = 1*namechar

namechar      = ALPHA / DIGIT / "-" / "_" / " "

ABNF syntax as per RFC5234: Augmented BNF for Syntax Specifications: ABNF.

Registered Top Level Namespaces

Regardless of other licensing attributes in this repository or document,
the following table (called "registry") is marked with CC0 1.0

Namespace Description Administered By Taxonomy
cdx Namespace for official CycloneDX namespaces and properties. Unofficial namespaces and properties MUST NOT be used under the cdx namespace. CycloneDX Core Working Group cdx taxonomy
internal Namespace for internal use only. BOMs shared with 3rd parties SHOULD NOT include properties in this namespace. N/A N/A
urn Namespace blocked to prevent confusions with Uniform Resource Name N/A N/A
aboutcode Namespace for use by AboutCode projects. nexB AboutCode taxonomy
accellence Namespace for use by Accellence Technologies. AccellenceTechnologies Accellence taxonomy
amazon Namespace for use by Amazon. Amazon RESERVED
appknox Namespace for use by Appknox Platform. Appknox Appknox taxonomy
aquasecurity Namespace for use by Aqua Security. Aqua Security RESERVED
boschrexroth Namespace for use by Bosch Rexroth. Bosch Rexroth AG Bosch Rexroth taxonomy
bytetrail Namespace for use by ByteTrail. ByteTrail RESERVED
codenotary Namespace for use by Codenotary platform. Codenotary Codenotary taxonomy
dependency-track Namespace for use by the Dependency-Track project. Dependency-Track Maintainers RESERVED
expliot Namespace for use by EXPLIoT. EXPLIoT EXPLIoT taxonomy
finitestate Namespace for the use by Finite State. Finite State finitestate taxonomy
fortify Namespace for use by Fortify. Micro Focus RESERVED
gitlab Namespace for use by GitLab. GitLab GitLab taxonomy
grype Namespace for use by the Grype project. Grype Maintainers RESERVED
hoppr Namespace for the use by the Hoppr project. Lockheed Martin Hoppr Taxonomy Documentation
ibm Namespace for use by IBM. IBM RESERVED
interlynk Namespace for use by Interlynk. Interlynk Interlynk taxonomy
ksoc Namespace for use by KSOC. KSOC KSOC taxonomy
medical-aegis Namespace for use by Medical Aegis. Medical Aegis RESERVED
observer Namespace for use by SBOM Observer. Bitfront SBOM Observer Taxonomy
recon Namespace for use by the Recon Project. Recon Project RESERVED
scribe Namespace for use by Scribe Security Scribe Security RESERVED
servicenow Namespace for use by ServiceNow. ServiceNow RESERVED
siemens Namespace for use by Siemens. Siemens Siemens taxonomy
snyk Namespace for use by Snyk. Snyk Snyk Taxonomy Documentation
sonatype Namespace for use by Sonatype Sonatype Sonatype Taxonomy Documentation
spack Namespace for use by the Spack package manager. Spack Maintainers Spack SBOM Project
stackable Namespace for use by Stackable Stackable RESERVED
syft Namespace for use by the Syft project. Syft Maintainers RESERVED
tern Namespace for use by the Tern project. Tern Maintainers RESERVED
veracode Namespace for use by Veracode. Veracode Veracode taxonomy

Registering New Top Level Namespaces

It is RECOMMENDED that anyone creating custom properties outside of the internal namespace SHOULD register a new top level namespace.

The process for registering a new top level namespace is to create a new issue requesting it.

Namespaces are initially registered as RESERVED.

Before using your RESERVED namespace, documentation for the taxonomy of the namespace SHOULD be publicly available. Failure to do so MAY result in the namespace reservation being revoked.

An example is the cdx taxonomy.

cyclonedx-property-taxonomy's People

Contributors

accellence avatar b-grooters-byte avatar camillem avatar coderpatros avatar ds-ak avatar fgreinacher avatar ilans avatar jcburgo avatar jhlmco avatar jhoward-lm avatar jkowalleck avatar lfrancke avatar lmco-ek avatar mateuszdyminski avatar mcombuechen avatar msymons avatar nscuro avatar samj1912 avatar spessartziegler avatar stevespringett avatar surendrapathak avatar t-graf avatar thiago-gitlab avatar wallrat avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

cyclonedx-property-taxonomy's Issues

Request for new top-level namespace for Fortify

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.

Finite State Namespace

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!

Clarify `cdx:device:certifications` namespace

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

[PROPOSAL] Generic namespace for describing `OCI` images and layers

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

Registering a new top level namespace for Bosch Rexroth.

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

ByteTrail Namespace

Request namespace for ByteTrail Fusion ecosystem

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

Request for new top-level namespace registration `vulncheck`

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]

Namespace for EXPLIoT Framework

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

Namespace to be reserved

Namespace Description Administered By Taxonomy
expliot Namespace for use by EXPLIoT EXPLIoT EXPLIoT Taxonomy

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

Request for new top level namespace `siemens`

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!

Request reserved namespace prefix "ibm"

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

Namespace to be reserved

Namespace Description URN equivalent
ibm Namespace for use in IBM SBOM's within property name field values urn:ibm:names

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

Add property to store the group of a dependency managed by Poetry

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

Namespace Description
cdx:poetry:package Namespace for package specific properties.

cdx:poetry:package Namespace Taxonomy

Property Description
cdx:poetry:package:category The group of dependencies to which the package belongs, as described in https://python-poetry.org/docs/managing-dependencies/#dependency-groups.

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

[PROPOSAL] Namespace syntax should support standardized URN syntax for direct usage

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:

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.

rust-related sub-namespaces under `cdx`

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.

Add country of origin to HBOM spec

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:

Example:

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

request for top-level namespace: recon

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).

register Grype namespace

Description

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

grype Namespace for use by the Grype project. Grype Maintainers Grype Project

[PROPOSAL] `cdx` namespace property to indicate a missing checksum

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"

Allow timestamps in reproducible-marked SBOMs

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.

Request for new top-level namespace registration 'accellence'

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

Request for new top-level namespace `snyk`

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.

[CHORE] Use CODEOWNERS to delegate namespace authority

@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?

[PROPOSAL] general purpose `kubernetes` taxonomy KBOM

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.

[PROPOSAL] Standardized `cdx` namespace property for source file

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.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.