The Linux Foundation Projects
Skip to main content
Category

News

OpenChain @ CISA – A Briefing for Our Colleagues

By News

In May, the OpenChain Project was invited to present the OpenChain Telco SBOM Guide at the Cybersecurity and Infrastructure Security Agency (CISA) SBOM Community Weekly Meeting. Jimmy Ahlberg (OpenChain Governing Board Chair + Ericsson) and Marc-Etienne Vargenau (OpenChain Telco Work Group Chair + Nokia) attended to share our work and goals.

The audience consisted of representatives from industry and government, and we had a lively discussion about how the OpenChain Telco SBOM Guide is designed to solve real-world challenges around SBOM quality.

We look forward to further collaboration with Allan Friedman and the rest of the team at CISA.

Be Part Of Our Work:

If you are interested in being part of our work around Software Bill of Materials, you are invited to join our work groups and study groups covering the topics.

and

A Closer Look at the OpenChain Telco SBOM Guide Schemas Contributed by ByteDance

By News

Getting to know our key contributor:

This key contributor of this work is David (Dongwei) Liu. David is a Research and Development (R&D) Engineer in ByteDance with a focus on Open Source and Software Supply Chain Security and Compliance. His personal interests include 3D Printing Technology (including the making 3D Printing Machines). He can be found on GitHub at https://github.com/ammend

Understanding the OpenChain Telco SBOM Guide:

The OpenChain Telco SBOM Guide Version 1.0 helps to define what is a quality SBOM in the context of practical use in the supply chain, and with awareness of requirements like the NTIA Minimum Elements For a Software Bill of Materials. This post is focused on Version 1.0 of that guide, though it should be noted that the OpenChain Telco SBOM Guidesion 1.1 was released recently.

Our discussion today:

This discussion is largely replicated from our GitHub and covers an implementation of JSON schemas for the OpenChain Telco SBOM Guide. The file openchain-telco-sbom-guide-1.0-schema.json is the JSON schema that can be applied to a project inside or between organizations. The examples shown below are designed to assist with comprehension of the underlying logic.

SPDX 2.2 and SPDX 2.3:

In the specification of OpenChain Telco SBOM Guide, we say ‘An OpenChain Telco SBOM Guide compatible document SHALL adhere to the version 2.2 of the SPDX Data Format as standardized in ISO/IEC 5962:2021, or to the version 2.3 of the standard’. By 2024-08-05, v2.2, v2.2.1, v2.2.2 and v2.3 have been released in github website. We choose v2.2.2 and v2.3 as origin json schema implementation.

The difference between SPDX 2.2 and SPDX 2.3 is that SPDX 2.3 requires less license info. For example, you can see concluded license field in SPDX 2.2 link and in SPDX 2.3 link.

In the directory internal, you can see four files about SPDX JSON schema.

The term ‘origin’ means that the file is copied from official GitHub website. The file spdx-v2.2.2-origin-schema.json comes from here. And the file spdx-v2.3-origin-schema.json comes from here. Also, the v2.2.2 specification can be found here and the v2.3 specification can be found here.

The term ‘fix’ means something has been fixed from the origin files. Why should we do it? There are three main reasons.

Firstly, doing a bugfix works. The SPDX github project link is rapidly developing. Unfortunately, official JSON schema implementations in the SPDX GitHub are not consistent with official SPDX specifications. To confirm this, a json_schema_compare.py script is developed. The comparison between SPDX v2.2.2 origin and the fixed one can be shown below:

internal $ python3 json_schema_compare.py -f spdx-v2.2.2-origin-schema.json spdx-v2.2.2-fix-schema.json 
{
    "field_mandatory_comparison": {
        "more_fields": [
            "doc(object)->snippets(array)->snippets_item(object)->name"
        ],
        "less_fields": [
            "doc(object)->documentNamespace",
            "doc(object)->creationInfo(object)->creators",
            "doc(object)->files(array)->files_item(object)->checksums",
            "doc(object)->files(array)->files_item(object)->licenseInfoInFiles",
            "doc(object)->snippets(array)->snippets_item(object)->ranges"
        ]
    },
    "field_existence_comparison": {}
}

In SPDX 2.2.2 specifications, name field in snippets in not mandatory, while in SPDX 2.2.2 json schema implementation is mandatory. And field documentNamespace, field checksums in files, field licenseInfoInFiles in files and field ranges in snippets is mandatory in SPDX 2.2.2 specifications, while not mandatory in JSON schema implementation. It is the same to SPDX 2.3 version. The bugfixes for SPDX have been pulled request to official GitHub project.

Secondly, it is impossible to reuse SPDX 2.2.2/2.3 JSON schema implementation in the OpenChain Telco SBOM Guide because declarations of "additionalProperties": false exist in it, which means you cannot extend any other field. So the fix one will omit this declaration to extend more fields.

Thirdly, arrange order of fields in implementation according to order of fields in official specifications to make implementation more human-readable. In origin json schema implementation of SPDX, orders of fields are in a messy.

Openchain Telco SBOM Guide JSON Schema:

SPDX 2.2 and SPDX 2.3 are not compatible!

internal $ python3 json_schema_compare.py -f spdx-v2.3-fix-schema.json spdx-v2.2.2-fix-schema.json 
{
    "field_mandatory_comparison": {
        "less_fields": [
            "doc(object)->files(array)->files_item(object)->copyrightText",
            "doc(object)->files(array)->files_item(object)->licenseConcluded",
            "doc(object)->files(array)->files_item(object)->licenseInfoInFiles",
            "doc(object)->packages(array)->packages_item(object)->copyrightText",
            "doc(object)->packages(array)->packages_item(object)->licenseConcluded",
            "doc(object)->packages(array)->packages_item(object)->licenseDeclared",
            "doc(object)->snippets(array)->snippets_item(object)->copyrightText",
            "doc(object)->snippets(array)->snippets_item(object)->licenseConcluded"
        ]
    },
    "field_existence_comparison": {
        "more_fields": [
            "doc(object)->packages(array)->packages_item(object)->builtDate(string)",
            "doc(object)->packages(array)->packages_item(object)->primaryPackagePurpose(string)",
            "doc(object)->packages(array)->packages_item(object)->releaseDate(string)",
            "doc(object)->packages(array)->packages_item(object)->validUntilDate(string)"
        ]
    }
}

SPDX 2.3 add four fields that are all not mandatory in comparison with SPDX 2.2 and require less license info mandatory fields. This means if it meets SPDX 2.2, it will meet SPDX 2.3. So we choose SPDX 2.3 as a base implementation of OpenChain Telco SBOM Guide. Then we add the MUST field in the OpenChain Telco SBOM Guide as shown below:

internal $ python3 json_schema_compare.py -f ../openchain-telco-sbom-guide-1.0-schema.json spdx-v2.3-fix-schema.jso
n
{
    "field_mandatory_comparison": {
        "more_fields": [
            "doc(object)->creationInfo(object)->comment",
            "doc(object)->packages(array)->packages_item(object)->copyrightText",
            "doc(object)->packages(array)->packages_item(object)->licenseConcluded",
            "doc(object)->packages(array)->packages_item(object)->licenseDeclared",
            "doc(object)->packages(array)->packages_item(object)->supplier",
            "doc(object)->packages(array)->packages_item(object)->versionInfo"
        ]
    },
    "field_existence_comparison": {}
}

The difference between the OpenChain Telco SBOM Guide and SPDX 2.3 is shown below:

  • The field comment in field createInfo in declared as mandatory.
  • The field copyrightTextlicenseConcludedlicenseDeclaredsupplierversionInfo in field packages is declared as mandatory.
  • add descriptions into some fields json schema.
  • Revise $id and title.

The Full Schema:

A warning in advance that this is included for completeness, but you may wish to view it on GitHub.

Preformatted Text Below:

{
"$schema": "http://json-schema.org/draft-07/schema#",
"$id": "https://github.com/OpenChain-Project/Telco-WG",
"title": "Open Chain Telco Guide 1.0",
"type": "object",
"required": [
"spdxVersion",
"dataLicense",
"SPDXID",
"name",
"documentNamespace",
"creationInfo"
],
"properties": {
"spdxVersion": {
"description": "Provide a reference number that can be used to understand how to parse and interpret the rest of the file. It will enable both future changes to the specification and to support backward compatibility. The version number consists of a major and minor version indicator. The major field will be incremented when incompatible changes between versions are made (one or more sections are created, modified or deleted). The minor field will be incremented when backwards compatible changes are made.",
"type": "string"
},
"dataLicense": {
"description": "License expression for dataLicense. Compliance with the SPDX specification includes populating the SPDX fields therein with data related to such fields (\"SPDX-Metadata\"). The SPDX specification contains numerous fields where an SPDX document creator may provide relevant explanatory text in SPDX-Metadata. Without opining on the lawfulness of \"database rights\" (in jurisdictions where applicable), such explanatory text is copyrightable subject matter in most Berne Convention countries. By using the SPDX specification, or any portion hereof, you hereby agree that any copyright rights (as determined by your jurisdiction) in any SPDX-Metadata, including without limitation explanatory text, shall be subject to the terms of the Creative Commons CC0 1.0 Universal license. For SPDX-Metadata not containing any copyright rights, you hereby agree and acknowledge that the SPDX-Metadata is provided to you \"as-is\" and without any representations or warranties of any kind concerning the SPDX-Metadata, express, implied, statutory or otherwise, including without limitation warranties of title, merchantability, fitness for a particular purpose, non-infringement, or the absence of latent or other defects, accuracy, or the presence or absence of errors, whether or not discoverable, all to the greatest extent permissible under applicable law.",
"type": "string"
},
"SPDXID": {
"type": "string",
"description": "Uniquely identify any element in an SPDX document which may be referenced by other elements."
},
"name": {
"description": "Identify name of this SpdxElement.",
"type": "string"
},
"documentNamespace": {
"type": "string",
"description": "The URI provides an unambiguous mechanism for other SPDX documents to reference SPDX elements within this SPDX document."
},
"documentDescribes": {
"description": "Packages, files and/or Snippets described by this SPDX document",
"type": "array",
"items": {
"type": "string"
}
},
"externalDocumentRefs": {
"description": "Identify any external SPDX documents referenced within this SPDX document.",
"type": "array",
"items": {
"type": "object",
"required": [
"externalDocumentId",
"checksum",
"spdxDocument"
],
"properties": {
"externalDocumentId": {
"description": "externalDocumentId is a string containing letters, numbers, ., - and/or + which uniquely identifies an external document within this document.",
"type": "string"
},
"checksum": {
"type": "object",
"required": [
"algorithm",
"checksumValue"
],
"properties": {
"algorithm": {
"description": "Identifies the algorithm used to produce the subject Checksum. Currently, SHA-1 is the only supported algorithm. It is anticipated that other algorithms will be supported at a later time.",
"type": "string",
"enum": [
"SHA256",
"SHA1",
"SHA384",
"MD2",
"MD4",
"SHA512",
"MD6",
"MD5",
"SHA224"
]
},
"checksumValue": {
"description": "The checksumValue property provides a lower case hexidecimal encoded digest value produced using a specific algorithm.",
"type": "string"
}
},
"description": "A Checksum is value that allows the contents of a file to be authenticated. Even small changes to the content of the file will change its checksum. This class allows the results of a variety of checksum and cryptographic message digest algorithms to be represented."
},
"spdxDocument": {
"description": "SPDX ID for SpdxDocument. A propoerty containing an SPDX document.",
"type": "string"
}
},
"description": "Information about an external SPDX document reference including the checksum. This allows for verification of the external references."
}
},
"creationInfo": {
"type": "object",
"required": [
"creators",
"created",
"comment"
],
"properties": {
"licenseListVersion": {
"description": "An optional field for creators of the SPDX file to provide the version of the SPDX License List used when the SPDX file was created.",
"type": "string"
},
"creators": {
"description": "Identify who (or what, in the case of a tool) created the SPDX file. If the SPDX file was created by an individual, indicate the person's name. If the SPDX file was created on behalf of a company or organization, indicate the entity name. If the SPDX file was created using a software tool, indicate the name and version for that tool. If multiple participants or tools were involved, use multiple instances of this field. Person name or organization name may be designated as “anonymous” if appropriate.",
"type": "array",
"items": {
"description": "Identify who (or what, in the case of a tool) created the SPDX file. If the SPDX file was created by an individual, indicate the person's name. If the SPDX file was created on behalf of a company or organization, indicate the entity name. If the SPDX file was created using a software tool, indicate the name and version for that tool. If multiple participants or tools were involved, use multiple instances of this field. Person name or organization name may be designated as “anonymous” if appropriate.",
"type": "string"
},
"minItems": 2
},
"created": {
"description": "Identify when the SPDX file was originally created. The date is to be specified according to combined date and time in UTC format as specified in ISO 8601 standard. This field is distinct from the fields in section 8, which involves the addition of information during a subsequent review.",
"type": "string"
},
"comment": {
"type": "string",
"description": "Mandatory. MUST provide SBOM Type as defined by CISA in the field."
}
},
"description": "One instance is required for each SPDX file produced. It provides the necessary information for forward and backward compatibility for processing tools."
},
"comment": {
"type": "string",
"description": "an optional field for creators of the SPDX file content to provide comments to the consumers of the SPDX document."
},
"packages": {
"description": "Packages referenced in the SPDX document",
"type": "array",
"items": {
"type": "object",
"required": [
"name",
"SPDXID",
"versionInfo",
"downloadLocation",
"licenseConcluded",
"licenseDeclared",
"copyrightText",
"supplier"
],
"properties": {
"name": {
"description": "Identify name of this SpdxElement.",
"type": "string"
},
"SPDXID": {
"type": "string",
"description": "Uniquely identify any element in an SPDX document which may be referenced by other elements."
},
"versionInfo": {
"description": "Provides an indication of the version of the package that is described by this SpdxDocument. Telco Guide required mandatory.",
"type": "string"
},
"packageFileName": {
"description": "The base name of the package file name. For example, zlib-1.2.5.tar.gz.",
"type": "string"
},
"supplier": {
"description": "The name and, optionally, contact information of the person or organization who was the immediate supplier of this package to the recipient. The supplier may be different than originator when the software has been repackaged. Values of this property must conform to the agent and tool syntax.",
"type": "string"
},
"originator": {
"description": "The name and, optionally, contact information of the person or organization that originally created the package. Values of this property must conform to the agent and tool syntax.",
"type": "string"
},
"downloadLocation": {
"description": "The URI at which this package is available for download. Private (i.e., not publicly reachable) URIs are acceptable as values of this property. The values http://spdx.org/rdf/terms#none and http://spdx.org/rdf/terms#noassertion may be used to specify that the package is not downloadable or that no attempt was made to determine its download location, respectively.",
"type": "string"
},
"filesAnalyzed": {
"description": "Indicates whether the file content of this package has been available for or subjected to analysis when creating the SPDX document. If false indicates packages that represent metadata or URI references to a project, product, artifact, distribution or a component. If set to false, the package must not contain any files.",
"type": "boolean"
},
"packageVerificationCode": {
"type": "object",
"required": [
"packageVerificationCodeValue"
],
"properties": {
"packageVerificationCodeValue": {
"description": "The actual package verification code as a hex encoded value. Use sha1 algorithm",
"type": "string"
},
"packageVerificationCodeExcludedFiles": {
"description": "A file that was excluded when calculating the package verification code. This is usually a file containing SPDX data regarding the package. If a package contains more than one SPDX file all SPDX files must be excluded from the package verification code. If this is not done it would be impossible to correctly calculate the verification codes in both files.",
"type": "array",
"items": {
"description": "A file that was excluded when calculating the package verification code. This is usually a file containing SPDX data regarding the package. If a package contains more than one SPDX file all SPDX files must be excluded from the package verification code. If this is not done it would be impossible to correctly calculate the verification codes in both files.",
"type": "string"
}
}
},
"description": "A manifest based verification code (the algorithm is defined in section 4.7 of the full specification) of the SPDX Item. This allows consumers of this data and/or database to determine if an SPDX item they have in hand is identical to the SPDX item from which the data was produced. This algorithm works even if the SPDX document is included in the SPDX item."
},
"checksums": {
"description": "The checksum property provides a mechanism that can be used to verify that the contents of a File or Package have not changed.",
"type": "array",
"items": {
"type": "object",
"required": [
"algorithm",
"checksumValue"
],
"properties": {
"algorithm": {
"description": "Identifies the algorithm used to produce the subject Checksum. Currently, SHA-1 is the only supported algorithm. It is anticipated that other algorithms will be supported at a later time.",
"type": "string",
"enum": [
"SHA256",
"SHA1",
"SHA384",
"MD2",
"MD4",
"SHA512",
"MD6",
"MD5",
"SHA224"
]
},
"checksumValue": {
"description": "The checksumValue property provides a lower case hexidecimal encoded digest value produced using a specific algorithm.",
"type": "string"
}
},
"description": "A Checksum is value that allows the contents of a file to be authenticated. Even small changes to the content of the file will change its checksum. This class allows the results of a variety of checksum and cryptographic message digest algorithms to be represented."
}
},
"homepage": {
"type": "string"
},
"sourceInfo": {
"description": "Allows the producer(s) of the SPDX document to describe how the package was acquired and/or changed from the original source.",
"type": "string"
},
"licenseConcluded": {
"description": "Telco Guide required mandatory. License expression for licenseConcluded. See SPDX Annex D for the license expression syntax. The licensing that the preparer of this SPDX document has concluded, based on the evidence, actually applies to the SPDX Item.\n\nIf the licenseConcluded field is not present for an SPDX Item, it implies an equivalent meaning to NOASSERTION.",
"type": "string"
},
"licenseInfoFromFiles": {
"description": "The licensing information that was discovered directly within the package. There will be an instance of this property for each distinct value of alllicenseInfoInFile properties of all files contained in the package.",
"type": "array",
"items": {
"description": "License expression for licenseInfoFromFiles. The licensing information that was discovered directly within the package. There will be an instance of this property for each distinct value of alllicenseInfoInFile properties of all files contained in the package.",
"type": "string"
}
},
"licenseDeclared": {
"description": "Telco Guide required mandatory. License expression for licenseDeclared. See SPDX Annex D for the license expression syntax. The licensing that the creators of the software in the package, or the packager, have declared. Declarations by the original software creator should be preferred, if they exist.",
"type": "string"
},
"licenseComments": {
"description": "The licenseComments property allows the preparer of the SPDX document to describe why the licensing in spdx:licenseConcluded was chosen.",
"type": "string"
},
"copyrightText": {
"description": "Telco Guide required mandatory. The text of copyright declarations recited in the Package or File.",
"type": "string"
},
"summary": {
"description": "Provides a short description of the package.",
"type": "string"
},
"description": {
"description": "Provides a detailed description of the package.",
"type": "string"
},
"comment": {
"type": "string"
},
"externalRefs": {
"description": "An External Reference allows a Package to reference an external source of additional information, metadata, enumerations, asset identifiers, or downloadable content believed to be relevant to the Package. A package SHOULD be identified by a Package URL (PURL). The PURL SHOULD be put in ExternalRef field",
"type": "array",
"items": {
"type": "object",
"required": [
"referenceCategory",
"referenceType",
"referenceLocator"
],
"properties": {
"referenceCategory": {
"description": "Category for the external reference",
"type": "string",
"enum": [
"OTHER",
"SECURITY",
"PACKAGE_MANAGER"
]
},
"referenceType": {
"description": "Type of the external reference. These are definined in an appendix in the SPDX specification.",
"type": "string"
},
"referenceLocator": {
"description": "The unique string with no spaces necessary to access the package-specific information, metadata, or content within the target location. The format of the locator is subject to constraints defined by the <type>.",
"type": "string"
},
"comment": {
"type": "string"
}
},
"description": "An External Reference allows a Package to reference an external source of additional information, metadata, enumerations, asset identifiers, or downloadable content believed to be relevant to the Package."
}
},
"attributionTexts": {
"description": "This field provides a place for the SPDX data creator to record acknowledgements that may be required to be communicated in some contexts. This is not meant to include theactual complete license text (see licenseConculded and licenseDeclared), and may or may not include copyright notices (see also copyrightText). The SPDX data creator may use this field to record other acknowledgements, such as particular clauses from license texts, which may be necessary or desirable to reproduce.",
"type": "array",
"items": {
"description": "This field provides a place for the SPDX data creator to record acknowledgements that may be required to be communicated in some contexts. This is not meant to include theactual complete license text (see licenseConculded and licenseDeclared), and may or may not include copyright notices (see also copyrightText). The SPDX data creator may use this field to record other acknowledgements, such as particular clauses from license texts, which may be necessary or desirable to reproduce.",
"type": "string"
}
},
"primaryPackagePurpose": {
"description": "This field provides information about the primary purpose of the identified package. Package Purpose is intrinsic to how the package is being used rather than the content of the package.",
"type": "string",
"enum": [
"OTHER",
"INSTALL",
"ARCHIVE",
"FIRMWARE",
"APPLICATION",
"FRAMEWORK",
"LIBRARY",
"CONTAINER",
"SOURCE",
"DEVICE",
"OPERATING_SYSTEM",
"FILE"
]
},
"releaseDate": {
"description": "This field provides a place for recording the date the package was released.",
"type": "string"
},
"builtDate": {
"description": "This field provides a place for recording the actual date the package was built.",
"type": "string"
},
"validUntilDate": {
"description": "This field provides a place for recording the end of the support period for a package from the supplier.",
"type": "string"
},
"annotations": {
"description": "Provide additional information about an SpdxElement.",
"type": "array",
"items": {
"type": "object",
"required": [
"annotationDate",
"comment",
"annotator",
"annotationType"
],
"properties": {
"annotationDate": {
"description": "Identify when the comment was made. This is to be specified according to the combined date and time in the UTC format, as specified in the ISO 8601 standard.",
"type": "string"
},
"comment": {
"type": "string"
},
"annotator": {
"description": "This field identifies the person, organization or tool that has commented on a file, package, or the entire document.",
"type": "string"
},
"annotationType": {
"description": "Type of the annotation.",
"type": "string",
"enum": [
"OTHER",
"REVIEW"
]
}
},
"description": "An Annotation is a comment on an SpdxItem by an agent."
}
},
"hasFiles": {
"description": "Indicates that a particular file belongs to a package.",
"type": "array",
"items": {
"description": "SPDX ID for File. Indicates that a particular file belongs to a package.",
"type": "string"
}
}
}
}
},
"files": {
"description": "Files referenced in the SPDX document",
"type": "array",
"items": {
"type": "object",
"required": [
"fileName",
"SPDXID",
"checksums"
],
"properties": {
"fileName": {
"description": "The name of the file relative to the root of the package.",
"type": "string"
},
"SPDXID": {
"type": "string",
"description": "Uniquely identify any element in an SPDX document which may be referenced by other elements."
},
"fileTypes": {
"description": "The type of the file.",
"type": "array",
"items": {
"description": "The type of the file.",
"type": "string",
"enum": [
"OTHER",
"DOCUMENTATION",
"IMAGE",
"VIDEO",
"ARCHIVE",
"SPDX",
"APPLICATION",
"SOURCE",
"BINARY",
"TEXT",
"AUDIO"
]
}
},
"checksums": {
"description": "The checksum property provides a mechanism that can be used to verify that the contents of a File or Package have not changed.",
"type": "array",
"items": {
"type": "object",
"required": [
"algorithm",
"checksumValue"
],
"properties": {
"algorithm": {
"description": "Identifies the algorithm used to produce the subject Checksum. Currently, SHA-1 is the only supported algorithm. It is anticipated that other algorithms will be supported at a later time.",
"type": "string",
"enum": [
"SHA256",
"SHA1",
"SHA384",
"MD2",
"MD4",
"SHA512",
"MD6",
"MD5",
"SHA224"
]
},
"checksumValue": {
"description": "The checksumValue property provides a lower case hexidecimal encoded digest value produced using a specific algorithm.",
"type": "string"
}
},
"description": "A Checksum is value that allows the contents of a file to be authenticated. Even small changes to the content of the file will change its checksum. This class allows the results of a variety of checksum and cryptographic message digest algorithms to be represented."
},
"minItems": 1
},
"licenseConcluded": {
"description": "License expression for licenseConcluded. See SPDX Annex D for the license expression syntax. The licensing that the preparer of this SPDX document has concluded, based on the evidence, actually applies to the SPDX Item.\n\nIf the licenseConcluded field is not present for an SPDX Item, it implies an equivalent meaning to NOASSERTION.",
"type": "string"
},
"licenseInfoInFiles": {
"description": "Licensing information that was discovered directly in the subject file. This is also considered a declared license for the file.",
"type": "array",
"items": {
"description": "License expression for licenseInfoInFile. Licensing information that was discovered directly in the subject file. This is also considered a declared license for the file.",
"type": "string"
},
"minItems": 1
},
"licenseComments": {
"description": "The licenseComments property allows the preparer of the SPDX document to describe why the licensing in spdx:licenseConcluded was chosen.",
"type": "string"
},
"copyrightText": {
"description": "The text of copyright declarations recited in the Package or File.",
"type": "string"
},
"artifactOfs": {
"description": "Deprecated. Indicates the project in which the SpdxElement originated. Tools must preserve doap:homepage and doap:name properties and the URI (if one is known) of doap:Project resources that are values of this property. All other properties of doap:Projects are not directly supported by SPDX and may be dropped when translating to or from some SPDX formats.",
"type": "array",
"items": {
"type": "object",
"properties": {}
}
},
"comment": {
"description": "This field provides a place for the SPDX file creator to record any general comments about the file.",
"type": "string"
},
"noticeText": {
"description": "This field provides a place for the SPDX file creator to record potential legal notices found in the file. This may or may not include copyright statements.",
"type": "string"
},
"fileContributors": {
"description": "This field provides a place for the SPDX file creator to record file contributors. Contributors could include names of copyright holders and/or authors who may not be copyright holders yet contributed to the file content.",
"type": "array",
"items": {
"description": "This field provides a place for the SPDX file creator to record file contributors. Contributors could include names of copyright holders and/or authors who may not be copyright holders yet contributed to the file content.",
"type": "string"
}
},
"attributionTexts": {
"description": "This field provides a place for the SPDX data creator to record acknowledgements that may be required to be communicated in some contexts. This is not meant to include theactual complete license text (see licenseConculded and licenseDeclared), and may or may not include copyright notices (see also copyrightText). The SPDX data creator may use this field to record other acknowledgements, such as particular clauses from license texts, which may be necessary or desirable to reproduce.",
"type": "array",
"items": {
"description": "This field provides a place for the SPDX data creator to record acknowledgements that may be required to be communicated in some contexts. This is not meant to include theactual complete license text (see licenseConculded and licenseDeclared), and may or may not include copyright notices (see also copyrightText). The SPDX data creator may use this field to record other acknowledgements, such as particular clauses from license texts, which may be necessary or desirable to reproduce.",
"type": "string"
}
},
"fileDependencies": {
"description": "Deprecated. The field provides a place for the SPDX file creator to record a list of other files (referenceable within this SPDX file) which the file is a derivative of and/or depends on for the build",
"type": "array",
"items": {
"description": "SPDX ID for File",
"type": "string"
}
},
"annotations": {
"description": "Provide additional information about an SpdxElement.",
"type": "array",
"items": {
"type": "object",
"required": [
"annotationDate",
"comment",
"annotator",
"annotationType"
],
"properties": {
"annotator": {
"description": "This field identifies the person, organization or tool that has commented on a file, package, or the entire document.",
"type": "string"
},
"annotationDate": {
"description": "Identify when the comment was made. This is to be specified according to the combined date and time in the UTC format, as specified in the ISO 8601 standard.",
"type": "string"
},
"comment": {
"type": "string"
},
"annotationType": {
"description": "Type of the annotation.",
"type": "string",
"enum": [
"OTHER",
"REVIEW"
]
}
},
"description": "An Annotation is a comment on an SpdxItem by an agent."
}
}
}
}
},
"snippets": {
"description": "Snippets referenced in the SPDX document",
"type": "array",
"items": {
"type": "object",
"required": [
"SPDXID",
"snippetFromFile",
"ranges"
],
"properties": {
"SPDXID": {
"type": "string",
"description": "Uniquely identify any element in an SPDX document which may be referenced by other elements."
},
"snippetFromFile": {
"description": "SPDX ID for File. File containing the SPDX element (e.g. the file contaning a snippet).",
"type": "string"
},
"ranges": {
"description": "This field defines the byte range in the original host file (in X.2) that the snippet information applies to",
"minItems": 1,
"type": "array",
"items": {
"type": "object",
"properties": {
"endPointer": {
"type": "object",
"properties": {
"reference": {
"description": "SPDX ID for File",
"type": "string"
},
"offset": {
"type": "integer",
"description": "Byte offset in the file"
},
"lineNumber": {
"type": "integer",
"description": "line number offset in the file"
}
},
"required": [
"reference"
]
},
"startPointer": {
"type": "object",
"properties": {
"reference": {
"description": "SPDX ID for File",
"type": "string"
},
"offset": {
"type": "integer",
"description": "Byte offset in the file"
},
"lineNumber": {
"type": "integer",
"description": "line number offset in the file"
}
},
"required": [
"reference"
]
}
},
"required": [
"endPointer",
"startPointer"
],
"additionalProperties": false
}
},
"licenseConcluded": {
"description": "License expression for licenseConcluded. See SPDX Annex D for the license expression syntax. The licensing that the preparer of this SPDX document has concluded, based on the evidence, actually applies to the SPDX Item.\n\nIf the licenseConcluded field is not present for an SPDX Item, it implies an equivalent meaning to NOASSERTION.",
"type": "string"
},
"licenseInfoInSnippets": {
"description": "Licensing information that was discovered directly in the subject snippet. This is also considered a declared license for the snippet.",
"type": "array",
"items": {
"description": "License expression for licenseInfoInSnippet. Licensing information that was discovered directly in the subject snippet. This is also considered a declared license for the snippet.",
"type": "string"
}
},
"licenseComments": {
"description": "The licenseComments property allows the preparer of the SPDX document to describe why the licensing in spdx:licenseConcluded was chosen.",
"type": "string"
},
"copyrightText": {
"description": "The text of copyright declarations recited in the Package or File.",
"type": "string"
},
"comment": {
"type": "string"
},
"name": {
"description": "Identify name of this SpdxElement.",
"type": "string"
},
"attributionTexts": {
"description": "This field provides a place for the SPDX data creator to record acknowledgements that may be required to be communicated in some contexts. This is not meant to include theactual complete license text (see licenseConculded and licenseDeclared), and may or may not include copyright notices (see also copyrightText). The SPDX data creator may use this field to record other acknowledgements, such as particular clauses from license texts, which may be necessary or desirable to reproduce.",
"type": "array",
"items": {
"description": "This field provides a place for the SPDX data creator to record acknowledgements that may be required to be communicated in some contexts. This is not meant to include theactual complete license text (see licenseConculded and licenseDeclared), and may or may not include copyright notices (see also copyrightText). The SPDX data creator may use this field to record other acknowledgements, such as particular clauses from license texts, which may be necessary or desirable to reproduce.",
"type": "string"
}
},
"annotations": {
"description": "Provide additional information about an SpdxElement.",
"type": "array",
"items": {
"type": "object",
"required": [
"annotationDate",
"comment",
"annotator",
"annotationType"
],
"properties": {
"annotationDate": {
"description": "Identify when the comment was made. This is to be specified according to the combined date and time in the UTC format, as specified in the ISO 8601 standard.",
"type": "string"
},
"comment": {
"type": "string"
},
"annotator": {
"description": "This field identifies the person, organization or tool that has commented on a file, package, or the entire document.",
"type": "string"
},
"annotationType": {
"description": "Type of the annotation.",
"type": "string",
"enum": [
"OTHER",
"REVIEW"
]
}
},
"description": "An Annotation is a comment on an SpdxItem by an agent."
}
}
}
}
},
"hasExtractedLicensingInfos": {
"description": "Indicates that a particular ExtractedLicensingInfo was defined in the subject SpdxDocument.",
"type": "array",
"items": {
"type": "object",
"required": [
"licenseId",
"extractedText"
],
"properties": {
"licenseId": {
"description": "A human readable short form license identifier for a license. The license ID is iether on the standard license oist or the form \"LicenseRef-\"[idString] where [idString] is a unique string containing letters, numbers, \".\", \"-\" or \"+\".",
"type": "string"
},
"extractedText": {
"description": "Verbatim license or licensing notice text that was discovered.",
"type": "string"
},
"name": {
"description": "Identify name of this SpdxElement.",
"type": "string"
},
"seeAlsos": {
"type": "array",
"items": {
"type": "string"
}
},
"crossRefs": {
"description": "Cross Reference Detail for a license SeeAlso URL",
"type": "array",
"items": {
"type": "object",
"required": [
"url"
],
"properties": {
"isWayBackLink": {
"description": "True if the License SeeAlso URL points to a Wayback archive",
"type": "boolean"
},
"match": {
"description": "Status of a License List SeeAlso URL reference if it refers to a website that matches the license text.",
"type": "string"
},
"timestamp": {
"description": "Timestamp",
"type": "string"
},
"order": {
"description": "The ordinal order of this element within a list",
"type": "integer"
},
"url": {
"description": "URL Reference",
"type": "string"
},
"isLive": {
"description": "Indicate a URL is still a live accessible location on the public internet",
"type": "boolean"
},
"isValid": {
"description": "True if the URL is a valid well formed URL",
"type": "boolean"
}
},
"description": "Cross reference details for the a URL reference"
}
},
"comment": {
"type": "string"
}
},
"description": "An ExtractedLicensingInfo represents a license or licensing notice that was found in the package. Any license text that is recognized as a license may be represented as a License rather than an ExtractedLicensingInfo."
}
},
"relationships": {
"description": "Relationships referenced in the SPDX document",
"type": "array",
"items": {
"type": "object",
"required": [
"spdxElementId",
"relatedSpdxElement",
"relationshipType"
],
"properties": {
"spdxElementId": {
"type": "string",
"description": "Id to which the SPDX element is related"
},
"relationshipType": {
"description": "Describes the type of relationship between two SPDX elements.",
"type": "string",
"enum": [
"VARIANT_OF",
"COPY_OF",
"PATCH_FOR",
"TEST_DEPENDENCY_OF",
"CONTAINED_BY",
"DATA_FILE_OF",
"OPTIONAL_COMPONENT_OF",
"ANCESTOR_OF",
"GENERATES",
"CONTAINS",
"OPTIONAL_DEPENDENCY_OF",
"FILE_ADDED",
"DEV_DEPENDENCY_OF",
"DEPENDENCY_OF",
"BUILD_DEPENDENCY_OF",
"DESCRIBES",
"PREREQUISITE_FOR",
"HAS_PREREQUISITE",
"PROVIDED_DEPENDENCY_OF",
"DYNAMIC_LINK",
"DESCRIBED_BY",
"METAFILE_OF",
"DEPENDENCY_MANIFEST_OF",
"PATCH_APPLIED",
"RUNTIME_DEPENDENCY_OF",
"TEST_OF",
"TEST_TOOL_OF",
"DEPENDS_ON",
"FILE_MODIFIED",
"DISTRIBUTION_ARTIFACT",
"DOCUMENTATION_OF",
"GENERATED_FROM",
"STATIC_LINK",
"OTHER",
"BUILD_TOOL_OF",
"TEST_CASE_OF",
"PACKAGE_OF",
"DESCENDANT_OF",
"FILE_DELETED",
"EXPANDED_FROM_ARCHIVE",
"DEV_TOOL_OF",
"EXAMPLE_OF"
]
},
"relatedSpdxElement": {
"description": "SPDX ID for SpdxElement. A related SpdxElement.",
"type": "string"
},
"comment": {
"type": "string"
}
}
}
},
"annotations": {
"description": "Provide additional information about an SpdxElement.",
"type": "array",
"items": {
"type": "object",
"required": [
"annotationDate",
"comment",
"annotator",
"annotationType"
],
"properties": {
"annotator": {
"description": "This field identifies the person, organization or tool that has commented on a file, package, or the entire document.",
"type": "string"
},
"annotationDate": {
"description": "Identify when the comment was made. This is to be specified according to the combined date and time in the UTC format, as specified in the ISO 8601 standard.",
"type": "string"
},
"comment": {
"type": "string"
},
"annotationType": {
"description": "Type of the annotation.",
"type": "string",
"enum": [
"OTHER",
"REVIEW"
]
}
},
"description": "An Annotation is a comment on an SpdxItem by an agent."
}
},
"revieweds": {
"description": "Deprecated. Reviewed",
"type": "array",
"items": {
"type": "object",
"required": [
"reviewDate"
],
"properties": {
"reviewer": {
"description": "The name and, optionally, contact information of the person who performed the review. Values of this property must conform to the agent and tool syntax.",
"type": "string"
},
"reviewDate": {
"description": "The date and time at which the SpdxDocument was reviewed. This value must be in UTC and have 'Z' as its timezone indicator.",
"type": "string"
},
"comment": {
"type": "string"
}
}
}
}
}
}

Case Study: Using the OpenChain Telco SBOM Guide in ByteDance

By News

This case study is split into the following parts:

  • About Our Author
  • Choosing the OpenChain Telco SBOM Guide
  • Structure Of This Case Study
  • Definitions / Specifications
  • Schema Considerations
  • Tooling for Implementation
  • A Practical Example
  • Conclusion and Future Work

About Our Author:

David (Dongwei) Liu is a Research and Development (R&D) Engineer in ByteDance with a focus on Open Source and Software Supply Chain Security and Compliance. His personal interests include 3D Printing Technology (including the making 3D Printing Machines). He can be found on GitHub at https://github.com/ammend

Mental Model Applied To This Case Study:

This is a case study explaining how to use the OpenChain Telco SBOM Guide to improve the quality of SBOMs in deployment. It is approached from the perspective of real-world use inside a company, and contains some technical descriptions to help with automation. The workflow described can be visualized in the following image:

Definitions / Specifications:

It is important to start with definitions around the topic of SBOMs. Having formal definitions, identifying types, and so on allows us to establish specifications for developing a solution.

Defining SBOM:

This case study is focused on Software Bill of Materials (SBOM). In this case study, we define an SBOM as a formal record that lists all the components, libraries, and subsystems that are included in a given software product or system. It provides transparency about what is “inside” a product and allows others to better understand its composition. Well-known SBOM formats include SPDX and CycloneDX.

SBOM Type:

We found there are two different kinds of SBOM type. One is primary SBOM type, which means the SBOM is used for describing product purpose. Another is generative type, which means the generating period of the SBOM of the product.

Primary SBOM in SPDX:

Primary SBOM in CycloneDX:

Generative SBOMs according to CISA:

We record both of these types in our database.

SBOM Core Elements:

SPDX:

NTIA SBOM:

Choosing the OpenChain Telco SBOM Guide:

The OpenChain Telco SBOM Guide was developed for a considerable period through the OpenChain Telco Work Group before reaching 1.0 status in 2024. A few factors came into play when selecting the OpenChain Telco SBOM Guide version 1.0 as the basis of our work:

Perhaps most importantly, the structure of the OpenChain Telco SBOM Guide means there is no need for repeated SBOM information supplements from other participants in the supply chain.

Schema Considerations:

Requirement Levels:

We used IETF RFC 2119 as the basis of our definitions. The key words defined are “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL”.

A schema is a technology validator to verify output data in these terms. The influence of the data field can be shown below.

  • Field existence. This means there may be a field in target data.
  • Field mandatory. This means there must be a field in target data

OpenChain Telco SBOM Guide JSON Schema:

The JSON Schema Result:

Generating Process:

This works in progress. The process of generating JSON schema of the Guide from scratch can be shown below.

Why is there a schema fixing stage for SPDX?

We discovered that the official JSON schema implementations in SPDX GitHub were not consistent with the official SPDX specifications. We submitted Pull Requests to the official SPDX GitHub project that have been adopted as a fix for the 2.3.1 milestone. See https://github.com/spdx/spdx-spec/pull/1020 and https://github.com/spdx/spdx-spec/pull/1021.

In a situation where such bugs exist, doing a fix is both an effective method of implementing a solution, and providing a case study to address a broken feature or add functionality.

In our case, we focused on arranging the order of fields in implementation according to the order of fields in official specifications to make things more human-readable. In the original JSON schema implementation of SPDX the orders of fields was inconsistent.

Differences between the OpenChain Telco SBOM Guide 1.0 and SPDX 2.3:

The differences we identified between Open Chain Telco SBOM Guide and SPDX 2.3 are:

  • For the OpenChain Telco SBOM Guide, the field comment in field createInfo is declared as mandatory;
  • The field copyrightText, licenseConcluded, licenseDeclared, supplier, versionInfo in field packages are declared as mandatory;
  • It adds descriptions into some fields json schema;
  • And it has a revised $id and title.

This is illustrated below:

Plain Text
internal $ python3 json_schema_compare.py -f ../openchain-telco-sbom-guide-1.0-schema.json spdx-v2.3-fix-schema.jso
n
{
    "field_mandatory_comparison": {
        "more_fields": [
            "doc(object)->creationInfo(object)->comment",
            "doc(object)->packages(array)->packages_item(object)->copyrightText",
            "doc(object)->packages(array)->packages_item(object)->licenseConcluded",
            "doc(object)->packages(array)->packages_item(object)->licenseDeclared",
            "doc(object)->packages(array)->packages_item(object)->supplier",
            "doc(object)->packages(array)->packages_item(object)->versionInfo"
        ]
    },
    "field_existence_comparison": {}
}

Tooling for Implementation:

Introduction:

An SBOM tool enables automatic generation of SBOM records. Specifically, they tend to:

  • Scan local files to generate basic SBOM information like hash, version, package dependencies and relationships
  • Then cross-check with trusted external component license and security sources.
  • With a focus on package license info and package security info

Many opensource tools do the first job, such as syft and cycloneDX CLI. Some examples can be found at this link: https://spdx.dev/use/tools/open-source-tools/

OpenChain Telco SBOM Guide Tool:

We have extended the Syft tool to support OpenChain Telco SBOM Guide. Syft is a CLI tool and library for generating a Software Bill of Materials from container images and filesystems. Our contribution can be found here: https://github.com/ammend/syft.

To run Syft for the OpenChain Telco SBOM Guide the following command is used:

SQL
./syft scan golang_example -o octsg-json@1.0 --file golang_example.sbom.json

“octsg-json” is abbreviation of OpenChain Telco SBOM Guide JSON Schema

A Practical Example:

Context:

We develop customized tools in ByteDance to collect dependencies of different kinds of artifacts. Below we will present an example using Golang. All of the example code is maintained at: https://github.com/ammend/openchain-telco-guide-examples

Golang Example:

Our SBOM example was created in a project called golang_example:

Our example used a web framework called gin and provided the analyzed SBOM result as shown below. In the code we only ask to import 1 third-party dependency, yet in total we import 19 dependencies. This is why code review and clear processes are important.

Package level:

File Level:

Relationship Level:

Conclusion and Future Work:

Questions for the future include:

  1. How to build a trusted source or upstream
  2. How to address situations of NOASSERTION when it comes to licenses, as outputs from Syft are not sufficient to cover this use case
  3. How to build a trusted source codebase from commercial or community tools
  4. How to improve the use of SBOM and potentially the scope of their use
  5. How to refine the type of declaration used for external commercial purposes
  6. How to refine governance for internal development
  7. How to create effective upstream contribution workflows

If you want to know more, we can talk to each other via GitHub or through the OpenChain China Work Group WeChat Group.

Note: ByteDance activity extends beyond being a user of the Telco SBOM Guide. David (Dongwei) Liu has also contributed a schema for the Telco SBOM Guide 1.0 which is merged into the official OpenChain Telco Work Group GitHub.

From BOSCH: OpenChain & Friends: Stuttgart Success, Eastern Europe Expansion

By News

On the 7th to 9th of April 2025, OpenChain and The FOSS-LÄND Community collaborated with many industry peers to bring together thought-leaders in open source business management in Stuttgart.

A key collaborator and host in this process was Bosch, and their open source team has just published a blog post recapping the event, lessons learned and more:

One very exciting thing highlighted by Bosch:

Energized by the discussions at the OpenChain & Friends event in Stuttgart, we’re excited to share an initiative brewing in the OpenChain community: Vladimir Slavov from Bosch Digital and Ivo Emanuilov, are establishing an OpenChain regional working group for the eastern part of Europe. With several years of experience navigating the open-source software landscape, both recognized the crucial role eastern Europe plays in the global open-source ecosystem and the increasing importance of secure and compliant software supply chains. This initiative aims to build a vibrant local community dedicated to promoting and driving the adoption of key open-source standards like ISO/IEC 5230 (open-source license compliance) and ISO/IEC 18974 (open-source security assurance). 

This nascent working group is currently gathering momentum and seeking enthusiastic participants. Are you based in Eastern Europe and interested in contributing to a stronger, more secure open-source ecosystem? Connect with Vladimir on LinkedIn to learn more and get involved!

And of course, a big thanks to all our other friends!

OpenChain and Friends: Stuttgart – Follow-Up Webinar Series

By News

On the 7th to 9th of April 2025, OpenChain and The FOSS-LÄND Community collaborated with many industry peers to bring together thought-leaders in open source business management in Stuttgart. Now we are working with our speakers to share some of the knowledge even further!

Starting in May, and continuing into Q3, we will hold a series of special webinars that showcase key talks from the event. These webinars will also provide a new opportunity for attendees to ask questions.

Here are the webinars confirmed so far:

= 1 = 

First Steps With ORT: An EEF Experience –  Kiko Fernández
2025-05-27 @ 10:00 CEST

= 2 =

AboutCode – Practical Compliance in One Stack – Licensing, Vulnerabilities, and More – Philippe Ombredanne 
2025-06-10 @ 09:00 CEST

= 3 =

Establishing trusted and consistent open source management across the supply chain with the OpenChain ISO standards​ – Shane Coughlan 
2025-06-18 @ 17:30 JST (part of the OpenChain Monthly Specification and Education Call (Europe / Asia)

= 4 =

Project OCCTET.eu – the why, what and how – Andreas Kotulla and Martin von Willebrand
2025-07-01 @ 09:00 CEST

= 5 = 

How we are doing compliance at CARIAD with ORT – Helio Chissini de Castro 
2025-07-03 @ 09:00 CEST

And … Special Thanks to All Our Collaborators From Stuttgart!

Famisanar EPS Announces an ISO/IEC 5230 Conformant Program

By Featured, News

Famisanar EPS was formed as a strategic alliance between Cafam and Colsubsidio to contribute to improving the health of Colombians in 1995. They currently have 2,277 collaborators and are present in 139 municipalities of 16 departments. They have a total of 58 Administrative and User Service Offices nationwide.

“The OpenChain Project, and the standards we maintain, are a contribution to the health and trustability of the software supply chain,” says Shane Coughlan, OpenChain General Manager. “We are delighted to see that our work is supporting the medical industry in Colombia, and we hope their activity in this space inspires others. The OpenChain community is always ready to help organizations from any geography, and in any industry, make use of our standards and guides to improve open source process management.”

OpenAnolis Announces Adoption of ISO/IEC 5230

By Featured, News

OpenAnolis announced that it has met the OpenChain ISO/IEC 5230 standard. The OpenAnolis community is a non-profit open source community formed by enterprises, institutions, universities, scientific research institutions, non-profit organizations, individuals, etc. on the basis of voluntariness, equality, openness, and collaboration.

The OpenAnolis community has always attached great importance to the construction of security and compliance capabilities. In terms of infrastructure, R&D processes and tools, the community has made comprehensive and in-depth investments, including the construction of software supply chain security infrastructure, support for SBOM lists, and the construction of license compliance systems. These capabilities provide solid security guarantees for the community’s open source activities, ensuring that they are carried out smoothly in a safe and compliant environment.

Ma Tao, Chairman of OpenAnolis, said: “We are pleased to announce the OpenChain ISO/IEC 5230 certification. Open source has always been the source of innovation for the OpenAnolis Community. The OpenAnolis Community will firmly embrace open source, contribute to open source, and contribute to the field of operating systems in the AI ​​era. This certification is a very important milestone in the construction of OpenAnolis’s open source compliance capabilities, and it is also a new starting point. The OpenAnolis Community will continue to invest and improve in the direction of security compliance to ensure the community’s security compliance level.”

Liu Dapeng, head of the OpenAnolis Community Standardization SIG, said that the OpenAnolis Community’s OpenChain ISO/IEC 5230 certification is of great significance to the development of the community. Standards and community open source complement each other, promote and enhance each other, and play an important role in building an open, interoperable, prosperous and innovative technology ecosystem. In the future, the Standardization SIG will continue to work with community ecosystem partners to jointly formulate the engineering standards of the OpenAnolis Community and ensure that community products meet relevant standard requirements.

About OpenAnolis

Founded in September 2020, OpenAnolis is an international open-source community and innovation platform for operating systems. It is committed to building a Linux open-source distribution and open-source innovation technology through open community cooperation. Its goal is to promote the prosperity and development of software, hardware, and application ecology, and jointly create new sources and infrastructure for digital development.

The community council consists of 24 leading enterprises from around the world, including Alibaba Cloud, Uniontech, Loongson, Arm, Intel, and more. Nearly 600 partners have participated in ecological co-construction, achieving full coverage of mainstream chip collaborative research and development mechanisms, mainstream middleware/databases, and mainstream OEM manufacturers. Over 100 products have successfully adopted the OpenAnolis operating system (Anolis OS). Currently, OpenAnolis has served over 800,000 users.

OpenAnolis has established about 60 SIG working groups, with an average monthly contribution of 5,000 PR. It has achieved technological innovation in core areas such as chips, kernel, compiler, security, virtualization, and cloud-native, consistently ranking at the top of the Linux community rankings. The community has released several community versions, including Anolis LoongArch GA, Anolis OS 7.9, 8.4, 8.6, and more.

About the OpenChain Project

The OpenChain Project has an extensive global community of over 1,000 companies collaborating to make the supply chain quicker, more effective and more efficient. It maintains OpenChain ISO/IEC 5230, the international standard for open source license compliance programs and OpenChain ISO/IEC 18974, the industry standard for open source security assurance programs.

About The Linux Foundation

The Linux Foundation is the world’s leading home for collaboration on open source software, hardware, standards, and data. Linux Foundation projects are critical to the world’s infrastructure, including Linux, Kubernetes, Node.js, ONAP, PyTorch, RISC-V, SPDX, OpenChain, and more. The Linux Foundation focuses on leveraging best practices and addressing the needs of contributors, users, and solution providers to create sustainable models for open collaboration. For more information, please visit us at linuxfoundation.org.

龙蜥社区(OpenAnolis)宣布符合OpenChain ISO/IEC 5230 标准

By News

龙蜥社区(OpenAnolis)宣布符合OpenChain ISO/IEC 5230 标准,龙蜥社区是由企事业单位、 高等院校、科研单位、非营利性组织、个人等按照自愿、平等、开放、协作的基础上组成的非营利性开源社区。

龙蜥社区始终高度重视安全合规能力的建设。在基础设施、研发流程和工具等方面,社区进行了全面且深入的投入,包括软件供应链安全基础设施的建设、SBOM清单的支持以及许可证合规体系的构建等。这些能力为社区的开源活动提供了坚实的安全保障,确保其在安全、合规的环境中顺利开展。

龙蜥社区理事长马涛说:“我们很高兴宣布获得 OpenChain ISO/IEC 5230 认证。开源一直是龙蜥社区创新的源泉。龙蜥社区将会坚定地拥抱开源,贡献开源,为 AI 时代的操作系统领域贡献龙蜥力量。这次认证通过是龙蜥在开源合规能力建设上的一个非常重要的里程碑,也是一个新的起点。龙蜥社区会持续在安全合规方向进行投入和提升,保证社区的安全合规水平。”

龙蜥社区标准化 SIG 负责人刘大鹏表示,龙蜥社区获得OpenChain5230认证,对社区的发展具有重要意义,标准和社区开源形成互补,互相促进和增强,共同为构建开放、互通、繁荣、创新的技术生态发挥重要作用。未来标准化 SIG 将继续联合社区生态伙伴共同制定龙蜥社区的工程标准,并确保社区产品符合相关标准要求。

关于OpenAnolis(龙蜥社区):

龙蜥社区成立于 2020 年 9 月,立足云计算打造数字创新基石,聚拢产业生态力量,共创数字化发展开源新基建。汇聚企事业单位、高等院校、科研单位、个人开发者等多元角色,作为面向国际的 Linux 服务器操作系统开源根社区及创新平台,龙蜥社区持续推动软、硬件及应用生态繁荣发展。

请访问https://openanolis.cn/?lang=en了解更多信息

关于OpenChain项目:

OpenChain项目拥有由1000多家公司组成的广泛全球社区,合作使供应链更快、更有效、更高效。它维护开源许可证合规程序的国际标准OpenChain ISO/IEC 5230和开源安全保证程序的行业标准OpenChain ISO/IEC 18974。

关于Linux基金会:

Linux基金会是世界领先的开源软件、硬件、标准和数据协作之家。Linux基金会项目对世界基础设施至关重要,包括Linux、Kubernetes、Node.js、ONAP、PyTorch、RISC-V、SPDX、OpenChain等。Linux基金会专注于利用最佳实践,并满足贡献者、用户和解决方案提供商的需求,为开放协作创建可持续的模式。如需更多信息,请访问linuxfoundation.org

Socionext Announces Recertification of OpenChain ISO/IEC 5230

By Featured, News

Socionext, a semiconductor and System on a Chip (SOC) company based in Japan, has completed recertification of OpenChain ISO/IEC 5230. This is an important part of the 18 month review cycle required by the specification to ensure processes are current.

“ISO standard periodic recertification is a critical building block in creating trust,” says Shane Coughlan, OpenChain General Manager. “As companies evolve and markets change, it is important to use clear, unambiguous processes like those outlined in OpenChain ISO/IEC 5230, the International Standard for open source license compliance. This is key to managing the open source software supply chain, and Socionext has long been a leader in this area.”

About Socionext Inc.

Socionext Inc., a leading global System-on-Chip (SoC) supplier, is a pioneer of the ‘Solution SoC’ business model. This innovative approach encompasses Socionext’s ‘Entire Design’ capabilities and offering of ‘Complete Service’. As a trusted silicon partner, Socionext fuels global innovation, providing superior features, performance, and quality that set its customers’ products and services apart in diverse domains ranging from automotive and data centers to networking, smart devices, and industrial equipment.

Socionext Inc., based in Yokohama, operates offices across Japan, Asia, the United States, and Europe for development and sales. For more information, visit https://www.socionext.com/en/.

About the OpenChain Project

The OpenChain Project has an extensive global community of over 1,000 companies collaborating to make the supply chain quicker, more effective and more efficient. It maintains OpenChain ISO/IEC 5230, the international standard for open source license compliance programs and OpenChain ISO/IEC 18974, the industry standard for open source security assurance programs.

About The Linux Foundation

The Linux Foundation is the world’s leading home for collaboration on open source software, hardware, standards, and data. Linux Foundation projects are critical to the world’s infrastructure, including Linux, Kubernetes, Node.js, ONAP, PyTorch, RISC-V, SPDX, OpenChain, and more. The Linux Foundation focuses on leveraging best practices and addressing the needs of contributors, users, and solution providers to create sustainable models for open collaboration. For more information, please visit us at linuxfoundation.org.

AbacatePay Announces an ISO/IEC 5230 Conformant Program

By Featured, News

AbacatePay is a developer-friendly payment gateway designed to simplify payment processing. Built by developers for developers, it offers:

  • Simple, intention-based API endpoints
  • Idempotent operations for reliable transactions
  • Consistent JSON request/response formats
  • Native SDK support
  • Easy dev mode integration
  • PIX payment support
  • Streamlined client and billing management

Learn More On Their Website: