Determine ISBOM manifest file structure
Proposal
Following on from the Manifest file format discussion in Create plan for ISBOM rollout, we need to determine the exact structure for this file.
For example, the following structure was discussed here:
{
"version": "0.0.1",
"contents": [
{
"sbom": {
"path": "cyclonedx-ruby-bundler.json",
"sha256": "d0dec51ee8a7ba8181a9913a694943f38cb0dc21b2971f25c9fcdeaed826b58d",
"source": "git"
},
"build_file": {
"path": "ruby-project/Gemfile",
"sha256": "b8bb034f9b63bd0254fbc7c157cae746c75853f4643d6cea844dc48ddb57f522",
"source": "git"
},
"lock_file": {
"path": "ruby-project/Gemfile.lock",
"sha256": "e8d8f69393a36afb774a6fd8a2a82e0ca56f7284b2c66fe3a8890e1d05ed05bd",
"source": "git"
},
"package_manager": {
"name": "bundler",
"type": "gem",
"version": "3.2.20"
}
}
]
}
As was using a files
array with a type
for each file:
{
"version": "0.0.1",
"contents": [
{
"project": {
"name": "root"
},
"files": [
{
"type": "sbom",
"path": "cyclonedx-sbt.json"
},
{
"type": "build_file",
"path": "build.gradle"
}
]
},
{
"project": {
"name": "proj1"
},
"files": [
{
"type": "sbom",
"path": "proj1/cyclonedx-sbt.json"
},
{
"type": "build_file",
"path": "build.gradle"
}
]
},
{
"project": {
"name": "proj2"
},
"files": [
{
"type": "sbom",
"path": "proj2/cyclonedx-sbt.json"
},
{
"type": "build_file",
"path": "build.gradle"
}
]
}
]
}
The purpose of this issue is to figure out the exact file format of the manifest file, taking into account the following:
- It should allow us to efficiently retrieve the data we want. For example, we may want the frontend to be able to display all files with package type
gem
- the manifest file should make it easy for us to fetch this data. - It needs to be compressed.
- It needs to properly handle subprojects that don't have their own build/lock files, and instead inherit one of these files from a parent project.
- It must provide links between the vulnerabilities in the
gl-dependency-scanning-report.json
file and the dependencies in the CycloneDX report. Each component in the CycloneDX report will have apurl
or "package URL", which is a URL string used to identify and locate a software package. We need to investigate whether this purl is sufficient to provide a link between vulnerabilities and dependencies.
/cc @NicoleSchwartz @gonzoyumo @fcatteau
🤖
Auto-Summary Discoto Usage
Points
Discussion points are declared by headings, list items, and single lines that start with the text (case-insensitive)
point:
. For example, the following are all valid points:
#### POINT: This is a point
* point: This is a point
+ Point: This is a point
- pOINT: This is a point
point: This is a **point**
Note that any markdown used in the point text will also be propagated into the topic summaries.
Topics
Topics can be stand-alone and contained within an issuable (epic, issue, MR), or can be inline.
Inline topics are defined by creating a new thread (discussion) where the first line of the first comment is a heading that starts with (case-insensitive)
topic:
. For example, the following are all valid topics:
# Topic: Inline discussion topic 1
## TOPIC: **{+A Green, bolded topic+}**
### tOpIc: Another topic
Quick Actions
Action Description /discuss sub-topic TITLE
Create an issue for a sub-topic. Does not work in epics /discuss link ISSUABLE-LINK
Link an issuable as a child of this discussion
Last updated by this job
Discoto Settings
---
summary:
max_items: -1
sort_by: created
sort_direction: ascending
See the settings schema for details.