-
Notifications
You must be signed in to change notification settings - Fork 8
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 ProductVulnerabilityAnalysis model implementation #98 #187
Conversation
Signed-off-by: tdruez <[email protected]>
Signed-off-by: tdruez <[email protected]>
Signed-off-by: tdruez <[email protected]>
Signed-off-by: tdruez <[email protected]>
Signed-off-by: tdruez <[email protected]>
@DennisClark current prototype implementation introduces a new column in the Product Vulnerabilities tab: "Exploitability analysis". Few notes:
TODO:
|
@tdruez I took this feature for a test drive in Staging Starship. This all looks very good so far and I see that you have aligned the various dropdown values with the CycloneDX spec, which makes sense. My only concern is that we may want to make the "state" field relate to an editable table in DejaCode, especially since the state values for CycloneDX are not the same as the CISA values, and I am not certain what they are in SPDX. Please see my discussion of "Vulnerability Status" in the document here https://docs.google.com/document/d/1SRAkvoIj18quuRSap1r8-R6TMHAVPRPi/edit#heading=h.ll22skp48ksm At this point, I think it's OK to use what you have as you continue to develop this feature, but we will be dealing with the competing standards at some point and need to reconcile them as best we can. I hope that "state" is the only one that might need to be a code table. |
Something that needs more discussion indeed, although I'm not sure an editable table (like free form entries) would help to generate any CDX, SPDX, or CISA document. An alternative could be to only allow the statuses (from your document) and internally map those with their equivalent in each output system. |
Re: "An alternative could be to only allow the statuses (from your document) and internally map those with their equivalent in each output system", good idea, thanks. |
Signed-off-by: tdruez <[email protected]>
Signed-off-by: tdruez <[email protected]>
Signed-off-by: tdruez <[email protected]>
Signed-off-by: tdruez <[email protected]>
Signed-off-by: tdruez <[email protected]>
@DennisClark Recent changes to review:
|
@tdruez The latest implementation looks good in Staging Starship. I have one potential suggestion (not urgent) which would be to support filtering by a blank/null exploitability state, so that I can quickly reduce the list to the vulnerabilities that i have not analyzed yet. |
Signed-off-by: tdruez <[email protected]>
Signed-off-by: tdruez <[email protected]>
Signed-off-by: tdruez <[email protected]>
Signed-off-by: tdruez <[email protected]>
Signed-off-by: tdruez <[email protected]>
Signed-off-by: tdruez <[email protected]>
Signed-off-by: tdruez <[email protected]>
Signed-off-by: tdruez <[email protected]>
Signed-off-by: tdruez <[email protected]>
@DennisClark Progress to review:
|
@tdruez a quick walk-thru in Staging Starship looks really good. The ability to filter by (No values) is especially nice. No problems found at this point. |
Very nice! |
Signed-off-by: tdruez <[email protected]>
Signed-off-by: tdruez <[email protected]>
Signed-off-by: tdruez <[email protected]>
Signed-off-by: tdruez <[email protected]>
Signed-off-by: tdruez <[email protected]>
Signed-off-by: tdruez <[email protected]>
Signed-off-by: tdruez <[email protected]>
Signed-off-by: tdruez <[email protected]>
Signed-off-by: tdruez <[email protected]>
Signed-off-by: tdruez <[email protected]>
Signed-off-by: tdruez <[email protected]>
Signed-off-by: tdruez <[email protected]>
Signed-off-by: tdruez <[email protected]>
Signed-off-by: tdruez <[email protected]>
Signed-off-by: tdruez <[email protected]>
This current prototype implementation introduces:
vulnerabilty_id
).