Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for Package URLs and OmniBOR Artifact IDs in the CVE Record Format. #391

Open
wants to merge 1 commit into
base: develop
Choose a base branch
from

Conversation

alilleybrinker
Copy link

@alilleybrinker alilleybrinker commented Mar 13, 2025

This adds support for Package URLs and OmniBOR Artifact IDs to be embedded in CVE records by introducing a new "applicability" structure for both CNAs and ADPs. This "applicability" structure is intended to replace usage of the existing "cpeApplicability" structure added recently for CPE support. It extends the prior schema of "cpeApplicability" in a backwards-compatible way, defining new "purl_match" and "omnibor_match" structures alongside the existing "match" now renamed "cpe_match".

The prior "cpeApplicability" structure remains entirely supported, though CNAs and any future ADPs enriching with software ID information should be encouraged to use the more expressive new "applicability" structure instead, and use of both at the same time should be treated as an error to avoid ambiguity.

This also opens the possibility of introducing more software identification schemes in the future by adding new "_match" variants within the "applicability" structure.

EDIT: This previously included two commits, the first of which was a formatting of the record format JSON file by a JSON auto-formatter. This commit has been removed, and the diff is now clean and only shows the relevant semantic changes.

Copy link
Author

@alilleybrinker alilleybrinker left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably ought to bump the version number of the schema itself prior to merging this PR. Right now that would be 5.1.2 under SchemaVer (though we use . separators not - separators as SchemaVer defines).

@alilleybrinker
Copy link
Author

alilleybrinker commented Mar 13, 2025

Feedback from QWG meeting:

  • Constrain the purl schema to explicitly disallow version information.
    • Would this demand vendoring the purl spec?
  • How to handle the purl generic type?
    • Also a complexity with the go type, where the purl spec doesn't match Go's expressiveness (purl is case-insensitive while Go is case-sensitive)
  • Did we consider limiting number of identifiers?
    • No, we didn't
    • There may be a need to consider how to deal with the "lots of identifiers" case.
    • CVE records do have an existing size limit.
  • How does this relate to the affected block, which also encodes version information?

@alilleybrinker alilleybrinker changed the base branch from main to develop March 13, 2025 21:32
@alilleybrinker
Copy link
Author

alilleybrinker commented Mar 13, 2025

The PR has been updated to point at develop instead of main. I'll be rebasing it to both remove the formatting and fix the merge conflict that has arisen.

EDIT: The rebase is done. No fixes from the feedback have yet been incorporated, but the diff should now show the correct information and there's only one commit.

This adds support for Package URLs and OmniBOR Artifact IDs to be
embedded in CVE records by introducing a new "applicability" structure
for both CNAs and ADPs. This "applicability" structure is intended to
replace usage of the existing "cpeApplicability" structure added recently
for CPE support. It extends the prior schema of "cpeApplicability" in a
backwards-compatible way, defining new "purl_match" and "omnibor_match"
structures alongside the existing "match" now renamed "cpe_match".

The prior "cpeApplicability" structure remains entirely supported, though
CNAs and any future ADPs enriching with software ID information should be
encouraged to use the more expressive new "applicability" structure instead,
and use of both at the same time should be treated as an error to avoid
ambiguity.

This also opens the possibility of introducing more software identification
schemes in the future by adding new "<schema>_match" variants within the
"applicability" structure.

Signed-off-by: Andrew Lilley Brinker <alilleybrinker@gmail.com>
@alilleybrinker alilleybrinker force-pushed the alilleybrinker/software-id branch from 509c24c to 751f6c8 Compare March 13, 2025 22:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant