Add Auditing and Analysis Capabilities ("does not apply" field to (product, vulnerability) pair)See original GitHub issue
A vulnerability in the component is not always applicable for every product using that component. For example, a vulnerability in OpenSSL TLS server code is not of interest for a product which does not run a TLS server (or has no networking at all), but uses OpenSSL.
For each vulnerability of a particular product, it would be useful to have an attribute
does not apply, which can be taken into account (or not) when showing totals. Each
does not apply could be accompanied with a user-supplied text field explaining why it is such.
- Created 6 years ago
- Comments:7 (6 by maintainers)
Top GitHub Comments
This ticket is complete.
Analysis decisions can be made on a per-project basis. This requires the VIEW_PORTFOLIO and VULNERABILITY_ANALYSIS permissions. If the user has these permissions while viewing a project, an ‘Audit’ tab will appear allowing for the analysis of findings.
Analysis decisions can also be made globally at the component level. This requires the PORTFOLIO_MANAGEMENT and VULNERABILITY_ANALYSIS permissions. If the user has these permissions while viewing a component, an optional button will be displayed allowing the user to enter audit mode while viewing the vulnerabilities for the component.
In both cases, metrics and vulnerabilities affecting components and projects take into consideration suppressed vulnerabilities. Vulnerabilities that are suppressed are not included in metrics and are hidden from view from users without the ability to make analysis decisions.
Also in both cases, comments and analysis decisions can be made, and the vulnerability can optionally be suppressed. Each action (analysis decision, suppression) creates a new comment in the audit trail providing a full history of the issue along with timestamps of when the action occurred.
I’ve made some minor modifications to the model for this ticket.
I’ve validated the model is sound and have a working REST resource that adds analysis decisions/comments along with retrieving the analysis trail. This will be checked in next week after the launch of v3. The only remaining items for this ticket are related to the UI. A metaphor for how the auditing workflow takes place in the UI still needs to be designed and implemented. I’m targeting this work for v3.1.0.
Also note, a new permission is being introduced in 3.1.0 called “VULNERABILITY_ANALYSIS”. Users that need to be able to audit must have this permission assigned to their user account or through team membership.