Feature: Improve bzlmod metadata.json model with minimal information for compliance/security
- Dominant language
- Java
- Stars
- 25.8k
- Forks
- 4.6k
- Avg merge
- 2d 20h
- Merged PRs (30d)
- 72
Description
Current metadata.json model has limited information, enough to provide data for project itself, but can be extended to provide better assessment to compliance and scanning tools.
Information, like license, description, upstream source and cpe string would be the minimal necessary for current existing tooling like [Ort](https://github.com/oss-review-toolkit/ort) or [Scancode](https://github.com/nexB/scancode-toolkit) have minimal details to process.
There's a reason to include such information as become the normative to be required instead be optional, for generating legal documentation ( i.e. [SPDX](https://spdx.org) )
An example of possible layout desirable on metadata.json ( using zlib bazel registry as example )
```json
{
"homepage": "https://zlib.net",
"maintainers": [
{
"email": "bazel-dev@googlegroups.com",
"name": "The Bazel Team"
}
"description": "lib is designed to be a free, general-purpose, legally unencumbered -- that is, not covered by any patents -- lossless data-compression library..."
"license": "ZLib"
],
"versions": [
{
"version": "1.2.11",
"source_url": "https://zlib.net/zlib-1.2.11.tar.gz",
"cpeId": "cpe:2.3:a:gnu:zlib:1.2.11:*:*:*:*:*:*:*"
},
],
"yanked_versions": {}
}
```
So, brief explanation behind new elements:
- **description** - This is the most descriptive field, but is expected as some of the minimal metadata requirements
- **license** - This is a mandatory field that is a point of origin of scanning, considered *declared* license. This leads to end on cross licensing comparison against the the *concluded* licenses. Example of reference of OSS licenses can be found here: [SPDX License Database](https://spdx.org/licenses/)
- **source_upstream** - Normally the source used in build can be stored in a different origin than upstream origin, Most of the times companies or individuals decide to have a local copy of the source in case of limited access to external network. So the correct separation on _/source.json_ and the upstream source would becomes valid. As a reference, the used code and the referenced code are detected in and considered normal in compliance automation processes.
- **cpeid** - This is one of the most necessary fields, as without it, no CVE securtiy scanning tool can easily detect software version and release to check against vulnerability. For reference about CPE strings: [CPE Mitre](https://cpe.mitre.org/specification/)
As the build info is stated on _\/source.json_, the **cpeid** can then be used to create the company variant later, but without it, there's no reference to create similar one.
Contributor guide
Research direction
Start with the metadata.json model and the /source.json layout described in the issue. Compare the proposed description, license, source_upstream, and cpeid fields with the current bzlmod metadata and determine their required or optional semantics. Done means the model supports the minimal compliance and security metadata described, with clear handling for versions and upstream sources.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java, json
- Domain
- build-system
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 42/100