核心是看SPDX框架逻辑
以反例说明当前标准需求的最小项不足以满足某些安全威胁事件的追踪或审计等。
由于很多工具无法产生现有要求规定的必须项，可能存在某些更好的字段去描述可追踪可审计信息或另外的表征->综合出类似supplier这样的字段。
理想情况下SBOM所有信息均可生成，设计track方法证明SBOM标准的正确性，
依据供应链常规的track方法？
标准->工具gap，分析必须字段，大量的项目是否能够正确提取这些要求的字段。
作为sbom工具，我们识别漏洞的逻辑是，组件名与版本，是否需要考虑各种论文中提到的奇怪情况，例如包改名、改版本号、供应链投毒攻击等，现有工具无法抵抗这类攻击、标准中无相应处置手段（❓❗）
1. 基本结构
目标；减少对开源软件包分析活动的重复与冗余，促进信息分享
Scope：交换元数据信息的统一结构
1.1 结构：
- Section
- field、file infomation、license info、snippet information
- package info、relationship、注释
- 审阅人员的review信息
- 文档创建信息
- SPDX格式
- package/sub-package
1.2 基本内容组成：
- Shall be in a human readable form.
- Shall be in a syntax that a software tool can read and write.
- Shall be suitable to be checked for syntactic correctness automatically, independent of how it was generated (human or tool).
- The SPDX document character set shall support UTF-8 encoding.
- Written in YAML, JSON, RDF, tag:value, .xls, XML
- Interoperability between all the supported file formats shall be preserved. SPDX defines how to validate a document in each supported format, and how to translate a valid document without loss to each other supported format.
- Tags and format properties are case sensitive.
2. 格式要求
Package information section
- a tarball, zip file or other archive
- a directory or sub-directory
- a separately distributed piece of software which another Package or File uses or depends upon (e.g., a Python package, a Go module, …)
- a container image, and/or each image layer within a container image
- a collection of one or more sub-packages
- a Git repository snapshot from a particular point in time
- Sub-packages shall not be nested inside a package information section, but shall be separate and shall use a relationship to clarify.
Note that some of these could be represented in SPDX as a file as well.
File information section
Snippet information section
关联到文件的代码片段
Other licensing information detected section
Relationships between SPDX elements information section
Packages, files, and snippets are all considered to be SPDX elements, and relationships can be made explicit between these SPDX elements by using the fields in this section.
3. 内容要求
3.1 Document Creation Infomation
-
SPDX version
-
Data license
-
SPDX identifier
-
Document name
-
SPDX document namespace
-
External document references
-
License list version（选择了SPDX官网的许可证列表可以填）
-
Creator、Created、Creator Comment
-
Document Comment
3.2 Package Information
-
Package Name、Version、File Name、Supplier（名字/一些可获取到的联系/身份信息）、Home Page、Package download location、Source information（分析得到的备注源信息）、【Release Date、Build Date、Valid Until Date】（
YYYY-MM-DDThh:mm:ssZ）、Package SPDX identifier -
Package Originator（针对同一软件的不同发行商情况，如Ubuntu-apt中的Docker，Supplier可能识别为Ubuntu，但软件包发起人是Docker开发组织）
-
Files analyzed（该字段为false代表当前包信息由元数据或URL引用分析得到，这类包不得包含任何文件）
-
Package verification code（对文件内容应用 SHA1 算法，并以小写的十六进制数字返回结果）
-
Package checksum（独立字段，要求SBOM不在包内时使用）
-
Concluded license（已明确识别出的许可证）、All licenses information from files（文件中找到的全部许可证）、Declared license（由包开发者给出的许可证）、Comments on license
-
Copyright text（确定包的版权所有者，以及存在的任何日期）
-
Package summary description（由文档创建者给出，不一定从包代码解析得到）、Package detailed description（可从源代码提取）、Package Comment
-
Externel reference（外部引用允许包引用其他信息、元数据、枚举、资产标识符或被认为与包相关的可下载内容的外部源）、External reference comment
-
Package attribution text（用于在包级别记录在某些情况下可能需要传达的确认）
-
Primary Package Purpose（是选项形式，可为以下选项：
APPLICATION|FRAMEWORK|LIBRARY|CONTAINER|OPERATING-SYSTEM|DEVICE|FIRMWARE|SOURCE|ARCHIVE|FILE|INSTALL|OTHER）
3.3 File Information
- File Name（完整路径与文件名）、File SPDX identifier、 File checksum、File comment、File contributor（通常在在版权所有者信息中给出或工具可分析commit获得）
- File Type：（One of:
SOURCE|BINARY|ARCHIVE|APPLICATION|AUDIO|IMAGE|TEXT|VIDEO|DOCUMENTATION|SPDX|OTHER） - Concluded license、License information in file（在当前文件头中可能识别到的许可证）、Comments on license、Copyright text
- File notice（记录一些声明信息，不一定是许可证或版权）
- File attribution text（用于在文件级别记录在某些情况下可能需要传达的确认）例如：
|
|
3.4 Snippet information
- Snippet SPDX identifier、Snippet name
- Snippet from file SPDX identifier（唯一标识与此代码段关联的 SPDX 文档中的文件）
- Snippet byte range、Snippet line range
- Snippet concluded license、License information in snippet
- Snippet comments on license、Snippet copyright text、Snippet comment、Snippet attribution text
3.5 Other licensing information detected
- License identifier（这里的other是相对于license-list）
- Extracted text、License name、License comment
- License cross reference（可以用url链接的形式给出不在license-list中的license）
3.6 Relationships between SPDX elements information
Relationship comment。
3.7 Annotations information
- Annotator、Annotation date（
YYYY-MM-DDThh:mm:ssZ）、Annotation type（REVIEW|OTHER）、SPDX identifier reference
另附支持的关系选项如下：
| Relationship | Description | Example |
|---|---|---|
| DESCRIBES | Is to be used when SPDXRef-DOCUMENT describes SPDXRef-A. | An SPDX document WildFly.spdx describes package ‘WildFly’. Note this is a logical relationship to help organize related items within an SPDX document that is mandatory if more than one package or set of files (not in a package) is present. |
| DESCRIBED_BY | Is to be used when SPDXRef-A is described by SPDXREF-Document. | The package ‘WildFly’ is described by SPDX document WildFly.spdx. |
| CONTAINS | Is to be used when SPDXRef-A contains SPDXRef-B. | An ARCHIVE file bar.tgz contains a SOURCE file foo.c. |
| CONTAINED_BY | Is to be used when SPDXRef-A is contained by SPDXRef-B. | A SOURCE file foo.c is contained by ARCHIVE file bar.tgz |
| DEPENDS_ON | Is to be used when SPDXRef-A depends on SPDXRef-B. | Package A depends on the presence of package B in order to build and run |
| DEPENDENCY_OF | Is to be used when SPDXRef-A is dependency of SPDXRef-B. | A is explicitly stated as a dependency of B in a machine-readable file. Use when a package manager does not define scopes. |
| DEPENDENCY_MANIFEST_OF | Is to be used when SPDXRef-A is a manifest file that lists a set of dependencies for SPDXRef-B. | A file package.json is the dependency manifest of a package foo. Note that only one manifest should be used to define the same dependency graph. |
| BUILD_DEPENDENCY_OF | Is to be used when SPDXRef-A is a build dependency of SPDXRef-B. | A is in the compile scope of B in a Maven project. |
| DEV_DEPENDENCY_OF | Is to be used when SPDXRef-A is a development dependency of SPDXRef-B. | A is in the devDependencies scope of B in a Maven project. |
| OPTIONAL_DEPENDENCY_OF | Is to be used when SPDXRef-A is an optional dependency of SPDXRef-B. | Use when building the code will proceed even if a dependency cannot be found, fails to install, or is only installed on a specific platform. For example, A is in the optionalDependencies scope of npm project B. |
| PROVIDED_DEPENDENCY_OF | Is to be used when SPDXRef-A is a to be provided dependency of SPDXRef-B. | A is in the provided scope of B in a Maven project, indicating that the project expects it to be provided, for instance, by the container or JDK. |
| TEST_DEPENDENCY_OF | Is to be used when SPDXRef-A is a test dependency of SPDXRef-B. | A is in the test scope of B in a Maven project. |
| RUNTIME_DEPENDENCY_OF | Is to be used when SPDXRef-A is a dependency required for the execution of SPDXRef-B. | A is in the runtime scope of B in a Maven project. |
| EXAMPLE_OF | Is to be used when SPDXRef-A is an example of SPDXRef-B. | The file or snippet that illustrates how to use an application or library. |
| GENERATES | Is to be used when SPDXRef-A generates SPDXRef-B. | A SOURCE file makefile.mk generates a BINARY file a.out |
| GENERATED_FROM | Is to be used when SPDXRef-A was generated from SPDXRef-B. | A BINARY file a.out has been generated from a SOURCE file makefile.mk. A BINARY file foolib.a is generated from a SOURCE file bar.c. |
| ANCESTOR_OF | Is to be used when SPDXRef-A is an ancestor (same lineage but pre-dates) SPDXRef-B. | A SOURCE file makefile.mk is a version of the original ancestor SOURCE file ‘makefile2.mk’ |
| DESCENDANT_OF | Is to be used when SPDXRef-A is a descendant of (same lineage but postdates) SPDXRef-B. | A SOURCE file makefile2.mk is a descendant of the original SOURCE file ‘makefile.mk’ |
| VARIANT_OF | Is to be used when SPDXRef-A is a variant of (same lineage but not clear which came first) SPDXRef-B. | A SOURCE file makefile2.mk is a variant of SOURCE file makefile.mk if they differ by some edit, but there is no way to tell which came first (no reliable date information). |
| DISTRIBUTION_ARTIFACT | Is to be used when distributing SPDXRef-A requires that SPDXRef-B also be distributed. | A BINARY file foo.o requires that the ARCHIVE file bar-sources.tgz be made available on distribution. |
| PATCH_FOR | Is to be used when SPDXRef-A is a patch file for (to be applied to) SPDXRef-B. | A SOURCE file foo.diff is a patch file for SOURCE file foo.c. |
| PATCH_APPLIED | Is to be used when SPDXRef-A is a patch file that has been applied to SPDXRef-B. | A SOURCE file foo.diff is a patch file that has been applied to SOURCE file ‘foo-patched.c’. |
| COPY_OF | Is to be used when SPDXRef-A is an exact copy of SPDXRef-B. | A BINARY file alib.a is an exact copy of BINARY file a2lib.a. |
| FILE_ADDED | Is to be used when SPDXRef-A is a file that was added to SPDXRef-B. | A SOURCE file foo.c has been added to package ARCHIVE bar.tgz. |
| FILE_DELETED | Is to be used when SPDXRef-A is a file that was deleted from SPDXRef-B. | A SOURCE file foo.diff has been deleted from package ARCHIVE bar.tgz. |
| FILE_MODIFIED | Is to be used when SPDXRef-A is a file that was modified from SPDXRef-B. | A SOURCE file foo.c has been modified from SOURCE file foo.orig.c. |
| EXPANDED_FROM_ARCHIVE | Is to be used when SPDXRef-A is expanded from the archive SPDXRef-B. | A SOURCE file foo.c, has been expanded from the archive ARCHIVE file xyz.tgz. |
| DYNAMIC_LINK | Is to be used when SPDXRef-A dynamically links to SPDXRef-B. | An APPLICATION file ‘myapp’ dynamically links to BINARY file zlib.so. |
| STATIC_LINK | Is to be used when SPDXRef-A statically links to SPDXRef-B. | An APPLICATION file ‘myapp’ statically links to BINARY zlib.a. |
| DATA_FILE_OF | Is to be used when SPDXRef-A is a data file used in SPDXRef-B. | An IMAGE file ‘kitty.jpg’ is a data file of an APPLICATION ‘hellokitty’. |
| TEST_CASE_OF | Is to be used when SPDXRef-A is a test case used in testing SPDXRef-B. | A SOURCE file testMyCode.java is a unit test file used to test an APPLICATION MyPackage. |
| BUILD_TOOL_OF | Is to be used when SPDXRef-A is used to build SPDXRef-B. | A SOURCE file makefile.mk is used to build an APPLICATION ‘zlib’. |
| DEV_TOOL_OF | Is to be used when SPDXRef-A is used as a development tool for SPDXRef-B. | Any tool used for development such as a code debugger. |
| TEST_OF | Is to be used when SPDXRef-A is used for testing SPDXRef-B. | Generic relationship for cases where it’s clear that something is used for testing but unclear whether it’s TEST_CASE_OF or TEST_TOOL_OF. |
| TEST_TOOL_OF | Is to be used when SPDXRef-A is used as a test tool for SPDXRef-B. | Any tool used to test the code such as ESlint. |
| DOCUMENTATION_OF | Is to be used when SPDXRef-A provides documentation of SPDXRef-B. | A DOCUMENTATION file readme.txt documents the APPLICATION ‘zlib’. |
| OPTIONAL_COMPONENT_OF | Is to be used when SPDXRef-A is an optional component of SPDXRef-B. | A SOURCE file fool.c (which is in the contributors directory) may or may not be included in the build of APPLICATION ‘atthebar’. |
| METAFILE_OF | Is to be used when SPDXRef-A is a metafile of SPDXRef-B. | A SOURCE file pom.xml is a metafile of the APPLICATION ‘Apache Xerces’. |
| PACKAGE_OF | Is to be used when SPDXRef-A is used as a package as part of SPDXRef-B. | A Linux distribution contains an APPLICATION package gawk as part of the distribution MyLinuxDistro. |
| AMENDS | Is to be used when (current) SPDXRef-DOCUMENT amends the SPDX information in SPDXRef-B. | (Current) SPDX document A version 2 contains a correction to a previous version of the SPDX document A version 1. Note the reserved identifier SPDXRef-DOCUMENT for the current document is required. |
| PREREQUISITE_FOR | Is to be used when SPDXRef-A is a prerequisite for SPDXRef-B. | A library bar.dll is a prerequisite or dependency for APPLICATION foo.exe |
| HAS_PREREQUISITE | Is to be used when SPDXRef-A has as a prerequisite SPDXRef-B. | An APPLICATION foo.exe has prerequisite or dependency on bar.dll |
| REQUIREMENT_DESCRIPTION_FOR | Is to be used when SPDXRef-A describes, illustrates, or specifies a requirement statement for SPDXRef-B. | A PDF document that describes a list of disallowed licences to inherit in certain build-subtrees. |
| SPECIFICATION_FOR | Is to be used when SPDXRef-A describes, illustrates, or defines a design specification for SPDXRef-B. | A UML diagram illustrating a directed requirement graph for a discernible set of software components in a software package. |
| OTHER | Is to be used for a relationship which has not been defined in the formal SPDX specification. A description of the relationship should be included in the Relationship comments field. |