Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.
Sign upDraft vulnerability schema extension #19
Conversation
|
The vulnerability schema used by Dependency-Check is inadequate to represent vulnerabilities in a BOM. |
| </xs:element> | ||
| <xs:element name="detection" type="xs:string" minOccurs="0" maxOccurs="1"> | ||
| <xs:annotation> | ||
| <xs:documentation>The detection of the vulnerability</xs:documentation> |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
kakumara
Sep 5, 2019
Author
Contributor
This needs more clarification. What is detection?
This is used as an attribute to describe vulnerabilities in sonatype products. Removed it considering the generic nature of this schema. efa5e75
- Removed causes, detection sections
| </xs:sequence> | ||
| </xs:complexType> | ||
|
|
||
| <xs:element name="vulnerabilities"> |
This comment has been minimized.
This comment has been minimized.
stevespringett
Sep 5, 2019
Member
Is the intended use of the vulnerabilities node to reside inside each component?
<bom>
<components>
<component>
<dg:vulnerabilities>
<dg:vulnerability>
</dg:vulnerability>
</dg:vulnerabilities>
</component>
</components>
</bom>Whatever the intended location, guidance in the form of documentation would be necessary
This comment has been minimized.
This comment has been minimized.
ja98200wilcox
Sep 5, 2019
Is the intended use of the vulnerabilities node to reside inside each component?
That is the intended location to be inside a component element. Seems like a natural fit. Would you rather have it somewhere else?
This comment has been minimized.
This comment has been minimized.
stevespringett
Sep 5, 2019
Member
Makes perfect sense to me as well, but the element wasn't annotated with documentation that provided any guidance. So although I assumed this to be the case, the specification did not explicitly state that.
This comment has been minimized.
This comment has been minimized.
ja98200wilcox
Sep 5, 2019
guidance in the form of documentation would be necessary
Will add appropriate documentation elements that provide guidance
This is used by CVSS
This comment has been minimized.
This comment has been minimized.
ja98200wilcox
commented
Sep 9, 2019
|
@stevespringett How does the vulnerability schema get tied to the SBOM schema? The vulnerability schema documentation is the tie? |
This comment has been minimized.
This comment has been minimized.
|
@ja98200wilcox I would prefer this schema to be flexible enough to be used inside and outside a component. Look at externalResources as an example. It supports both a bom-level representation and inside the component as well. If the vulnerability schema is used outside of a component, it will need to use the The two use-cases that I see this schema being used for are:
|
This comment has been minimized.
This comment has been minimized.
ja98200wilcox
commented
Sep 9, 2019
I see the dependency-graph-1.0.xsd does that. Thank you. Didn't see that tie in before. |
This comment has been minimized.
This comment has been minimized.
ja98200wilcox
commented
Sep 11, 2019
Added bom-ref to vulnerability |
This comment has been minimized.
This comment has been minimized.
ja98200wilcox
commented
Sep 13, 2019
|
Hi @stevespringett, anything else you like changed? What are the next steps you like us to do? |
This comment has been minimized.
This comment has been minimized.
|
I will review this weekend and provide feedback. Once released, the extension will have a page similar to https://cyclonedx.org/ext/dependency-graph/ |
- Updated to use anyURI type for vuln URL
This comment has been minimized.
This comment has been minimized.
|
I think we're really close. I see a few minor issues when using the schema: <v:vulnerabilityScore>
<v:score>
<v:score>
<v:base>9.8</v:base>
<v:impact>5.9</v:impact>
<v:exploitability>3.0</v:exploitability>
</v:score>
<v:severity>Critical</v:severity>
<v:source>CVSSv3</v:source>
<v:vector>AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H</v:vector>
</v:score>
</v:vulnerabilityScore>The Inside Proposed changes: <v:ratings>
<v:rating>
<v:score>
<v:base>9.8</v:base>
<v:impact>5.9</v:impact>
<v:exploitability>3.0</v:exploitability>
</v:score>
<v:severity>Critical</v:severity>
<v:source>CVSSv3</v:source>
<v:vector>AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H</v:vector>
</v:rating>
</v:ratings>If you have a proposal other than 'ratings' that also works or is more descriptive of the nodes, please let me know. The final thing that needs correction is the score decimal restrictions. Currently, any decimal is allowed. So -999, 15.8, and 5.99999 are all allowed. This should be restricted to 0.0 - 10.0 and be limited to a single decimal point. |
This comment has been minimized.
This comment has been minimized.
|
One final point on the above. The |
- vulnerabilityScore --> rating - source --> method
This comment has been minimized.
This comment has been minimized.
Agree and makes sense. 44a9bfa |
This comment has been minimized.
This comment has been minimized.
Agree and makes sense. 44a9bfa |
This comment has been minimized.
This comment has been minimized.
ja98200wilcox
commented
Sep 18, 2019
Does Sonatype create this or @stevespringett? Also, I would like to thank you for reviewing our PR. |
This comment has been minimized.
This comment has been minimized.
This is something I’ll do and if you’d like the page to state something specific or if Sonatype would like to be ack on the page, let me know.
Of course. I think the only thing remaining is the decimal restrictions. Other than that, does the PR satisfy your original requirements? Any foreseeable changes or is this ready for release? |
This comment has been minimized.
This comment has been minimized.
|
This comment has been minimized.
This comment has been minimized.
|
How will the schema be licensed? CycloneDX itself is Apache 2.0. |
| </xs:documentation> | ||
| </xs:annotation> | ||
| </xs:enumeration> | ||
| <xs:enumeration value="PCI DSS"> |
This comment has been minimized.
This comment has been minimized.
stevespringett
Sep 19, 2019
Member
I looked at the PCI DSS doc and it doesn't specifically state a method for evaluating risk. Rather, it provides an example of how to do so. The only requirement appears to be that it's done. But I'm unclear if PCI DSS should actually be a valid risk rating method or not. Comments?
This comment has been minimized.
This comment has been minimized.
kakumara
Sep 20, 2019
Author
Contributor
I looked at the PCI DSS doc and it doesn't specifically state a method for evaluating risk. Rather, it provides an example of how to do so. The only requirement appears to be that it's done. But I'm unclear if PCI DSS should actually be a valid risk rating method or not. Comments?
Think you are right.
This comment has been minimized.
This comment has been minimized.
ja98200wilcox
commented
Sep 20, 2019
Let's use the same license you use for CycloneDX. |
44c3eca
into
CycloneDX:master
This comment has been minimized.
This comment has been minimized.
|
I'll add the license and publish this weekend. |
kakumara commentedSep 2, 2019
Adding a draft software vulnerability schema for discussion and getting feedback.
Note: the descriptions are not final and to be updated later on, upon structure finalization.
References: https://github.com/jeremylong/DependencyCheck/blob/master/core/src/main/resources/schema/dependency-check.2.2.xsd