CycloneDX / CycloneDX/specification

Add way to indicate that a component is missing the cryptographic hash

Open
#262 6 comments 0 reactions 0 assignees View on GitHub
Dominant language
XSLT
Stars
547
Forks
93
Avg merge
7h 11m
Merged PRs (30d)
37

Description

**Motivation**

As a CycloneDX consumer, I would like the ability to validate whether all the components declared their expected cryptographic hash. In SLSA v0.1, for example, hashes are recommended for [hermetic builds](https://slsa.dev/spec/v0.1/requirements#hermetic) (all dependencies must be declared with [immutable references](https://slsa.dev/spec/v0.1/requirements#immutable-reference)).

CycloneDX components have the [hashes](https://cyclonedx.org/docs/1.4/json/#components_items_hashes) attribute. However, an empty `hashes` array does not necessarily mean that the component is missing a hash - perhaps the component cannot have, and does not need, a hash.

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 hash 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 cryptographic hashes, they instead rely on the git commit hash for integrity.

**Proposal**

Add a Component attribute which would let CycloneDX producers indicate that the hash is, in fact, missing. Or, to look at it the other way, indicate that empty `hashes` are OK.

For example:

```json
{
"hashes": [],
"missingHash": false
}
```

`missingHash` would be `true` if the component _can_ declare the expected hash but doesn't. For example, someone forgot to update `go.sum` after adding a dependency.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.