OCI: Add support for dependencies
This ticket is to enhance cdxgen to populate the dependencies array for OCI components.
This will help with visualizing the Dependency Graph within Dependency Track
I've investigated this locally.
At a high level it appears to involve:
- updating createContainerSpecLikeBom to concatenate and maintain bom dependencies
- massage the bom dependency refs to match the component bom-refs (currently they have different patterns)
- bomJson.dependencies ref values are in the format
pkg:oci/image@sha256:digest - components purl and bom-ref are in the format
pkg:oci/image@version?
- bomJson.dependencies ref values are in the format
@setchy, is it getting lost somewhere? This line must retain the dependencies list per image from the plugin.
https://github.com/CycloneDX/cdxgen/blob/master/binary.js#L618
Correct.
I think this is the missing line which appears in many other places for other languages/package managers.
But when added, it then exposed the discrepancy between the dependency ref and the component bom-ref values, which ultimately gets logged as a WARNING: Invalid ref in dependencies
To use an example...
Dockerfile
FROM node:18.0.0
bom component
"components": [
{
"group": "",
"name": "node",
"version": "18.0.0",
"purl": "pkg:oci/[email protected]?",
"type": "library",
"bom-ref": "pkg:oci/[email protected]?",
"properties": [
{
"name": "SrcFile",
"value": "/Users/Documents/cdxgen-dockerfile-demo/Dockerfile"
},
{
"name": "oci:SrcImage",
"value": "node:18.0.0"
}
]
},
...
]
bom dependencies
"dependencies": [
{
"ref": "pkg:oci/node@sha256:e5b7b349d517159246070bf14242027a9e220ffa8bd98a67ba1495d969c06c01",
"dependsOn": []
}
]
cdxgen cli output
===== WARNINGS =====
[
'Invalid ref in dependencies pkg:oci/node@sha256:e5b7b349d517159246070bf14242027a9e220ffa8bd98a67ba1495d969c06c01'
]
Would you happen to have an example of how you would like the tree to look like?
Update my post above with an example of the different refs being generated
@setchy, how about we add a fake dependency between [email protected] and node@sha256. sha256 scheme is more precise, and the same version tag could technically point to different sha based on architecture. Also, shall we remove the question mark by setting qualifiers to undefined?