RFD: Support for Package URLs #407
Conversation
This adds an RFD describing a design for adding support for more software identifier types to the CVE Record Format, including a deep dive on the thinking behind the design. Signed-off-by: Andrew Lilley Brinker <abrinker@mitre.org>
alilleybrinker
force-pushed
the
alilleybrinker/software-id-rfd
branch
from
d61f397 to
c1b0d8e
Compare
|
First comment reserved for open questions (will be edited)
Issues considered resolve are marked with a checkmark. If you believe an issue is not resolved, please raise it in a comment below. |
alilleybrinker
changed the title
The `affected` array is an array containing `product` objects, which must at minimum include an "identifier" (which may be a composite identifier composed of multiple fields) along with a set of version bounds or a default status. Products may also specify an assortment of additional fields which further constrain the applicability of the CVE to its intended target hardware or software. Previously, the set of identifiers available were: - A `vendor` and `product` - A `collectionURL` and `packageName` This commit adds support for a new identifier, called `packageURL`, which uses the purl (Package URL) specification. The contents of the commit add this as a new field on the `product` type, with a description and examples, and also update the data constraints on the `product` type, both to make `packageURL` an option to fulfill the identifier requirement already in place on the type, and to ensure that the new `packageURL` field is not mixed with the existing `collectionURL` or `packageName` fields, as they are redundant with `packageURL` and including both increases the possibility of data inconsistency within a single CVE record. This inclusion of a new `packageURL` type which can be used instead of the existing pair of `collectionURL` and `packageName` would require consumers of CVE records to update their logic both to accept the new field, and to use it in places where they may today use the pair of `collectionURL` and `packageName`. This commit does not include a regular expression to parse Package URLs specifically. Rather, it reuses the existing `uriType` schema. So we can be sure after validating CVE records against this updated record format that the `packageURL` field is a URL, but not that it is a valid Package URL per the Package URL specification. It would be the responsibility of CVE Services to further validate the field to ensure values match the Package URL specification. We do not perform this validation in-schema due to the complexity of expressing the validation in the form of a regular expression. This work is submitted as an alternative formulation of the design proposed in the draft RFD on software identifiers [1], and as an alternative to the existing proposals for making the `cpeApplicability` structure generic [2] (instead of it being CPE-specific) and enhancing this new generic applicability structure with support for Package URLs [3]. If this change is accepted, then [2] and [3] should not be accepted. [1]: CVEProject#407 [2]: CVEProject#391 [3]: CVEProject#397 Signed-off-by: Andrew Lilley Brinker <abrinker@mitre.org>
The `affected` array is an array containing `product` objects, which must at minimum include an "identifier" (which may be a composite identifier composed of multiple fields) along with a set of version bounds or a default status. Products may also specify an assortment of additional fields which further constrain the applicability of the CVE to its intended target hardware or software. Previously, the set of identifiers available were: - A `vendor` and `product` - A `collectionURL` and `packageName` This commit adds support for a new pair of fields to support using OmniBOR Artifact IDs as identifiers in the `affected` array: - `artifactID`: The OmniBOR Artifact ID for an artifact. - `artifactType`: An enum indicating whether the `artifactID` is for an artifact to search in a file system for, or whether it's a build input to search against OmniBOR Input Manifests. The commit also adds data constraints to ensure this new identifier pair is not used alongside fields that don't make sense to use with OmniBOR, including the other identifier schemes, further decomposition information like `programFiles` or `programRoutines`, and version information. This work is submitted as an alternative formulation of the design proposed in the draft RFD on software identifiers [1], and as an alternative to the existing proposals for making the `cpeApplicability` structure generic [2] (instead of it being CPE-specific) and enhancing this new generic applicability structure with support for OmniBOR Artifact IDs [3]. If this change is accepted, then [2] and [3] should not be accepted. [1]: CVEProject#407 [2]: CVEProject#391 [3]: CVEProject#396 Signed-off-by: Andrew Lilley Brinker <abrinker@mitre.org>
|
Having both of these approaches open may not have been the best idea (for me anyway 😄 ). I've added my comment about how to encode version ranges in the other PR though I suspect that would also be relevant here as well. I will also be totally honest that I have not dug into Omnibor yet and I've been stuck in a loop where a QWG meeting happens and Omnibor is mentioned, I think So, with that personal failing out of the way I'll continue to be self centered and pose the question; would it make sense to drop both purl and omnibor from this RFD and discuss the idea of how we should consider software identifiers more generally? I've been waffling on the idea of proposing a set of what I'll call With respect to this RFD as is; I am onboard with the general direction of it. I think I understand the synonym problem to be one that is more operational than schema design and I would suggest that allowing for more methods to capture affected product information may enable/embolden more CNAs to publish affected product information period. In my opinion an indicator of success could be a rise in the proportion of CVEs published with valid affected product information populated. This could also be broken out per id (and for the structure itself) to indicate success for each. On the |
|
@darakian, for reading up on OmniBOR, the project website has a more accessible introduction to how the identifiers work: https://omnibor.io/docs/artifact-ids/ As for the question of whether to split this RFD into parts: one advancing a general set of provisions for how new software IDs should be incorporated, and then others advancing specific software IDs to incorporate. My team is open to doing that, but didn't as the initial ask because we were concerned it would be too granular for the QWG. In particular, we felt that offering concrete examples with real-world identifiers helps crystallize understanding of the trade-offs of any particular design in a way that a purely abstract proposal can't. For the success metric question, I agree there's value in assessing adopting via a statistical analysis of uptake of the new fields or general enrichment of identity information in CVE records, though we didn't choose that as the go-to metric because we wanted to leave room to also consider adoption by CVE consumers, which is fuzzier to measure and thus easier to ignore when assessing success. That said, I'd love to see the kind of analysis you mention done after maybe six months post-adoption. Finally, on the related issues, these are more listed to identify problems we are explicitly not solving in the RFD but which the QWG could take up and pursue outside of the RFD. I agree that there's interest and a need to advance some form of improvement to CPE, likely via federation, to let it scale beyond the limits of NIST's resources; we just don't solve that question here. |
|
@darakian we could amend the RFD text to include a clear subsection which describes that the design proposed here for adding Package URLs and OmniBOR Artifact Identifiers is intended as a template for addition of any future identifier types, which may help satisfy the desire for a clear reference-point on how to add those types in future proposals, without needing to split the RFD into multiple separate documents. |
Thank you, thank you!
Ya, that's totally fair. I was very much waffling back and forth on if to raise the issue or not.
That could work for sure. 👍 |
This rewrites the core content of the RFD to base the proposed new fields on the `affected` array instead of basing them on the `cpeApplicability` object as the prior version of the RFD did. The motivation and outcomes are generally unchanged, but the specifics of the proposed edits are now different. Signed-off-by: Andrew Lilley Brinker <abrinker@mitre.org>
|
@darakian, thanks! I've amended the RFD to be based on the |
|
Finally getting a moment to read through this and realized that this may not have been covered in discussions yet... If the intent is to create more generic places for various identifiers, it would make sense that part of this proposal should include deprecating the existing I recognize that this would create two locations for CPE related data due to the current support for |
|
@Chris-Turner-NIST I agree that it would be good both to eventually deprecate the
All this to say, I fully endorse improving and simplifying handling of CPEs in the record format, and my personal preference is to do exactly what you propose. I just think it would make the most sense in a follow-up RFD. |
|
@Chris-Turner-NIST, I've opened an Issue recommending the creation of an RFD for improving CPE handling, based on your comment here. Happy for any additional input you may have on that! #421 |
Co-authored-by: Andrew Pollock <andrewpollock@users.noreply.github.com>
|
Note Final Comment PeriodA Final Comment Period (FCP) has been called for this proposal. This is a final opportunity to raise new concerns with the proposal. The FCP will close at 2pm PDT / 5pm EDT July 3rd, at the end of the Quality Working Group Meeting. |
|
Note Final Comment Period Has ClosedThe Final Comment Period (FCP) for this proposal has closed, and the proposal has been accepted by the QWG. Per the RFD process rules, it will now advance to the CVE Board for consideration. The Board will make the final determination as to whether to adopt or reject the proposal. |
|
After deliberation with the CVE Board, we've decided to split this RFD into two parts: one for Package URLs and one for OmniBOR Artifact IDs. The plan will be to likely proceed forward with the Package URL RFD, while continuing to work on improvements to the OmniBOR Artifact ID RFD. For the OmniBOR Artifact ID RFD, the design will be revisited, with an eye toward handling fine-grained identifiers like OmniBOR Artifact IDs in a distinct manner from the way course-grained identifiers are used in CVE Records today. |
Per discussion in the QWG, this amends the RFD to clarify that the new identifier fields being proposed are not able to fulfill the "identifier-like" requirement in the `product` object inside the `affected` array. While this may be changed in the future, for today it is the easiest path forward for CVE data consumers, who could adopt the new fields if _desirable_ but would not be obligated to do so. Signed-off-by: Andrew Lilley Brinker <alilleybrinker@gmail.com>
alilleybrinker
force-pushed
the
alilleybrinker/software-id-rfd
branch
from
09511d5 to
625cef0
Compare
|
Gah, seems I errored in my commit-making and rebased the last commit before the new one I just added. To be clear: that commit has not been edited, this only adds a new commit which splits out the OmniBOR parts of the original RFD. This RFD is now solely about Package URLs; a separate PR will be opened for OmniBOR. |
Since this RFD is now Package URL specific, this renames the RFD file to reflect the new title. Signed-off-by: Andrew Lilley Brinker <abrinker@mitre.org>
|
From today's QWG discussion: there was consensus on the value of pursuing a validation library for CVE records, given that with the introduction of Package URLs it will no longer be sufficient to check that CVE Records pass JSON schema validation. This would need to be a discussion with the AWG, which @ccoffin has taken an action to start. |
|
@alilleybrinker re:
See the work we are doing to bring open source validation at package-url/purl-spec#296 repasted here for reference:
Originally posted by @pombredanne in package-url/purl-spec#296 (reply in thread) |
|
@alilleybrinker tell me if I can join a future QWG call to present the gist of the work |
I'd certainly be interested to hear about it. CCing @ccoffin, one of the QWG Co-Chairs, who maintains the agendas. |
|
My team has drafted some initial guidance for CNAs and CVE Consumers, respectively, trying to answer key questions for how to use the new field: https://gist.github.com/alilleybrinker/5c38a0e176482f475b809b17156d5a5f As the QWG/Board get into prepping for this to be released in (presumably) 5.2.0 of the Record Format, this could be a useful starting point for materials to share with stakeholders about the change. |
Hi Phillipe! It would be great to hear from you regarding the new work! Our normal meeting time is 3-4 PM EST, but i think last time we setup a 10-11 AM EST slot that was more compatible with your time zone. Let me know what you prefer. Chris |
|
@ccoffin either time works for me. Next week is busy as I will be at https://osseu2025.sched.com but your regular time can work even then. |
|
@pombredanne OK sounds good! Shall we go ahead and plan for you to present in the regularly scheduled QWG meeting on Aug 28? |
Signed-off-by: Andrew Lilley Brinker <abrinker@mitre.org>
|
@ccoffin Looking forward to the discussion today! |
This adds an RFD describing a design for adding support for Package URLs to the CVE Record Format, including a deep dive on the thinking behind the design.
This RFD previously covered both Package URLs and OmniBOR Artifact IDs. After feedback from the CVE Board, that has been reduced in scope to only cover Package URLs. Another PR will be opened to cover the OmniBOR proposal.