-
-
Notifications
You must be signed in to change notification settings - Fork 56
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
Added vulnerabilities as part of core spec #91
Conversation
… Based on work by @garethr.
Pinging @ddillard, @garethr, @wagoodman, @luhring, @planetlevel. Your feedback on this (draft) PR is much appreciated. Once the details are flushed out, I'll update the PR to include XML and Protobuf schema support as well. |
Also pinging @brianf, @ahoog42, @llamahunter Your feedback on this (draft) PR is much appreciated. Once the details are flushed out, I'll update the PR to include XML and Protobuf schema support as well. |
Also it should be noted that when you review this PR, look at it from two perspectives:
Both use cases will be possible which is exciting. For external use, since every component or service can have a reference to its own BOM, it would be possible to either:
Also note that I mentioned components or services. So also look at this PR from the perspective of:
In the future, we may want to add support for vulnerabilities from SAST and IAST/RASP tools, but that will require support for the different types of analyzers (e.g. semantic, control flow, data flow, etc) as well as the ability to support call graphs (including source and sinks). Or we could simply integrate more closely with SARIF. So although this PR will not address SAST today, please keep in mind that it's not off the table for a future version of the spec. |
I looked through the spec but apologies if I missed it, is it possible to include mitigating information about the included vulns? eg "this thing has an old commons-collection cve but it only applies to unsafe deserialization and either this app doesn't have any serialization, or it's already whitelisted and so this can't be exploited here". |
Absolutely. The spec proposes to include the following analysis states:
In addition, both In the event a library was 'fixed'. This is already supported by the 'pedigree' capabilities implemented v1.2 of the spec where users can specify the commit and diffs along with the issues (defects, enhancements, security) that they've resolved in their custom version of a library. |
What exactly does "exploitable" mean? Does it mean that it's directly exploitable or both directly and indirectly exploitable? An example might help: suppose I have an XML parser vuln, but I authenticate the sender of the XML and it's trusted so that vulnerability should not be directly exploitable. However, suppose there's another vulnerability (perhaps one that I'm currently unaware of) and an attacker was able to bypass or otherwise subvert that authentication, and the attacker could then gain some additional privilege or knowledge by then exploiting the parser vuln. Would the parser vuln be considered exploitable? |
@ddillard I think what you'll find is that organizations will say they're The organization receiving the BOM will have an opportunity to either accept that analysis or push back on it. But to your point, it might be worth expanding on what For example:
Thoughts? |
Yes, not every user is equally affected by a common single vulnerability. I believe some alignment with this vulnerability disclosure guide might help: https://github.com/ossf/oss-vulnerability-guide/blob/main/guide.md |
Thanks for looping me in @VinodAnandan ! Would it be possible to align this more with the OSSF OSV vulnerability schema: https://ossf.github.io/osv-schema/ (which has already been adopted by several vulnerability DBs) to enable easier interop? There seems to be a number of overlapping fields. In particular, OSV's "affected" field lets us be a bit more descriptive about describing version/commit ranges (and this aligns well with the corresponding field in the CVE 5.0 schema which adapted the OSV format). |
Hi @oliverchang Is the I think the version and range options are likely easily supportable and I think they would make good additions. I'll add them to the proposal. It looks like the rest of the OSV spec is already covered by this proposal, so should be easy interop. |
No, it is not a required field. In cases where there is no PURL/package it can be left out.
Thank you!
Agreed :) |
…comment) Signed-off-by: Steve Springett <steve@springett.us>
I'm masahiro331. May I join this discussion? The recommendation component describes how to fix or work around a vulnerability, but it does not mechanically determine whether a patch will be provided in the first place. |
@masahiro331 Software patches can refer to different things depending on if you're a developer or operator of software. The term 'patch' is already used in CycloneDX to describe code modifications made to a component. When you refer to 'patches' are you referring to the availability of unaffected (safe) versions? If so, would you recommend this be a boolean field, or an array or range of alternative versions? |
@stevespringett I referring to the availability of unaffected (safe) versions.
I think the modification state and the modified versions need to be defined separately. I think enum is better for the modification state, not bool.
The other states are possible, but they are considered to be a combination of the vulnerability impact. At the very least, it would be better if the modified version is listed in the recommendation and can be parsed mechanically if possible. (This is a very difficult problem, so I don't think it is essential.) The unaffected(safe) version is described in the recommendation, so it is not a problem. |
Good. I'll add support for that.
I'm a little confused on the word I think 'wont fix' and 'not fixed' would possibly be good additions to the vulnerability analysis section, likely in relation to impact. |
"description": "Textual representation of the severity of the vulnerability adopted by the risk analysis method. If an other risk analysis method is used other than whats defined in scoreSourceType, the user is expected to translate appropriately to match with an element value below.", | ||
"enum": [ | ||
"critical", | ||
"high", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this a generic rating of this vulnerability, like the CVSS score? Or is the scoring intended to be specific to the particular application that this component is part of? If the latter, then the description could be updated to emphasize that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Multiple ratings can be specified, including those from the NVD and for the creators or operators of the application that component is a part of. OWASP Risk Rating is also supported here.
I'm confused. Why couldn't we represent vulnerabilities from SAST and IAST tools in the BOM? I wasn't thinking that the BOM would have all the details from a DAST/SAST/IAST tool... certainly not a fulll SARIF file... just the high level details. We don't have any of that kind of detail for vulnerabilities in OSS components. Can you explain the thinking here a bit more? |
Well, you can. My thought process was more around WHY. So if a vulnerable function/method is not called, being able to communicate the technical details of why a vulnerable function/method is not reachable is information that SAST or IAST tools would know, but would be really difficult to communicate in an SBOM. That's what I meant by that statement. Of course, IAST can communicate if something is or is not vulnerable. I think we need to figure out the right level of detail without over engineering. |
One approach may be to do something like: "affects": [
{
"ref": "pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.9.9",
"versions": [
{
"version": "2.9.0",
"versionType": "semver",
"lessThanOrEqual": "2.9.4",
"status": "affected"
}
],
"constraints": [
"appliesTo": [
{
"route": ["acme-x", "component-a", "component-b", "component-c"],
"status": "affected"
},
{
"route": ["acme-x", "component-d", "component-b", "component-c"],
"status": "not_affected"
},
{
"route": ["acme-x", "component-e", "component-c"],
"status": "not_affected"
},
{
"route": ["acme-x", "component-c"],
"status": "affected"
}
]
]
}
] If this is valuable information to represent, we could certainly do that. My only issue with this is that its too high level and focuses on the component, not the call graph. For example, There may be multiple paths through Representing the source and sink in a call stack would be highly valuable in that case, but would require us to integrate with SARIF. |
@coderpatros, @DarthHater, any feedback on #91 (comment)? |
Per CycloneDX Core meeting - make 'response' as shown here an array. |
Signed-off-by: Steve Springett <steve@springett.us>
…array of organizations and individuals. Signed-off-by: Steve Springett <steve@springett.us>
Migrate version range syntax to Package URL version range syntax (vers) Currently, this PR is based on CVE 5.0 schema, which has a number of problems including an undefined way to specify version range type. |
…ge URL version range syntax, which is compatible with CVE 5.0 and OSV syntax. Signed-off-by: Steve Springett <steve@springett.us>
Signed-off-by: Steve Springett <steve@springett.us>
Signed-off-by: Steve Springett <steve@springett.us>
…SON schema. Signed-off-by: Steve Springett <steve@springett.us>
Signed-off-by: Steve Springett <steve@springett.us>
Signed-off-by: Steve Springett <steve@springett.us>
Signed-off-by: Steve Springett <steve@springett.us>
…TY_RESPONSE_NULL to default Signed-off-by: Steve Springett <steve@springett.us>
Signed-off-by: Steve Springett <steve@springett.us>
This PR is based on work from #44 but without the limitations of the existing vulnerability extension. This implements #38.
Major changes from the vulnerability extension include: