Make CBOM output conform to the CycloneDX 1.6 schema - #2
Merged
Conversation
Validated against the official bom-1.6.schema.json, the emitted CBOM failed on
three counts, so no document this tool produced passed the CycloneDX CLI.
serialNumber was built with time.Now().Format("20060102-150405-000000000").
That is a timestamp, not a UUID, and it does not match the required
urn:uuid pattern. Replaced with a random RFC 4122 version 4 UUID.
algorithmToPrimitive returned "hybrid" for hybrid constructions and
"key-agreement" for key agreement. Neither is a member of the spec's closed
primitive enum, and one non-member value invalidates the whole document.
CycloneDX spells these "combiner" and "key-agree". The hybrid case now also
precedes the post-quantum cases so a hybrid ML-KEM construction is reported as
the combiner it is rather than as a plain KEM.
categoryToAssetType matched lowercase category names that no pattern actually
uses. The real categories are "Secret Detection" and "Certificate", so every
finding fell through to the default and was emitted as an algorithm. A detected
private key became assetType "algorithm" named "Private Key Header", which is
the incomplete key material representation described in the report. Key material
is now emitted as related-crypto-material carrying its material type and size.
Evidence locations were absolute paths, embedding the scanning machine's
directory layout and username into an artifact meant to be committed and shared,
and making identical scans differ between machines. They are now relative to the
scan root, falling back to the original path when no relative path exists.
Two existing tests asserted the invalid values ("key-agreement" and key mapping
to certificate) and were updated, since they locked in output the spec rejects.
Fixes #1
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #1.
@ShivCod was right on both points. Validated against the official
bom-1.6.schema.json, the CBOM this tool emitted failed on three counts, so nodocument it produced would pass the CycloneDX CLI.
Before
After
Schema mapping deficiencies (your point 2)
serialNumberwastime.Now().Format("20060102-150405-000000000"). That is atimestamp, not a UUID. Now a random RFC 4122 version 4 UUID.
primitivereturned"hybrid"and"key-agreement", neither of which is inthe spec enum. CycloneDX spells these
combinerandkey-agree. A singlenon-member value invalidates the entire document, which is why this affected
every scan rather than only hybrid ones.
ML-KEM construction reports as the combiner it is instead of a plain
kem.Incomplete key material representation (your point 1)
categoryToAssetTypematched lowercase category names that no pattern actuallyuses. The real categories are
"Secret Detection"and"Certificate", so everyfinding fell through to the default and was emitted as an algorithm. Your
-----BEGIN RSA PRIVATE KEY-----became:{ "name": "Private Key Header", "cryptoProperties": { "assetType": "algorithm" } }losing the fact that it was key material at all. Now:
{ "name": "Private Key Header", "cryptoProperties": { "assetType": "related-crypto-material", "relatedCryptoMaterialProperties": { "type": "private-key" } } }Certificates and CSRs were affected by the same case-matching bug and are now
classified correctly too.
Also fixed
Evidence locations were absolute paths, embedding the scanning machine's
directory layout and username into an artifact meant to be committed and shared
with auditors, and making identical scans of the same source differ between
machines and CI runners. They are now relative to the scan root.
Testing
New tests assert the serial number pattern and uniqueness, every emitted
primitiveandassetTypeagainst the spec enums, key material classification,and path relativization.
Two existing tests asserted the invalid values (
"key-agreement", andkeymapping to
certificate) and were updated. They were encoding output the specrejects, and a key is not a certificate.