Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
Add Auditing and Analysis Capabilities ("does not apply" field to (product, vulnerability) pair)
See original GitHub issueA 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.
Issue Analytics
- State:
- Created 6 years ago
- Comments:7 (6 by maintainers)
Top Results From Across the Web
Top Related Medium Post
Top Related StackOverflow Question
Troubleshoot Live Code
Top Related Reddit Thread
Top Related Hackernoon Post
Top Related Tweet
Top Related Dev.to Post
Top Related Hashnode Post
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.