Exporting and sharing security reports

Problem to solve

Users are unable to effectively share the results of our security reports outside GitLab. They need to provide these reports to their managers, compliance teams, and sometimes their clients. They need a human readable format that can be printed or sent via email.

As part of this investigation, we should try to better understand where the biggest sources of demand for such reports might exist among our users. For instance, is this internal compliance teams requesting from DevOps, services businesses needing to satisfy clients?

Additional challenges:

Users can't have their own clients log in to their instance to look at their security dashboard
Published format needs to display consistently whether printed, emailed, online (e.g. PDF). Carefully consider if HTML is acceptable because saving HTML as PDF doesn't always work well, can be display inconsistencies. (Another tool (WebInspect) has an output file that was a PDF that could be shared and included what was scanned with detail)
Creating scripts and workarounds are possible but very manual, not efficient, and prone to errors

Intended users

Further details

User need the ability to have some configurability of report content. It should be easy to share these reports with internal groups or their clients.

Considerations for Reporting Features:

Report critical vulnerabilities to executive leadership team. Show which group/project (app) and also whether an issue was created, if it was dismissed (with comments), and if the MR was approved (by whom/when). Since the exec team is responsible for security issues, they want to see critical vulns.
Report vulns by developer and by class of vulnerability to identify knowledge gaps for targeted training.
Report by class of vuln to identify common problems and root cause.

Proposal

Add the ability to easily configure and export scanning reports that can be shared externally in a human readable format.

What the reports should have:

Some configuration to show varying levels of detail, able to choose which types of details to include/exclude
Include both an issue summary along with detail
Details and location of vulnerabilities so developers can easily trace them to resolve
~~Ability to dismiss false positives that are persistent, with the ability for reports to ignore false positives~~
Save as PDF and/or other common file formats for saving/archiving, emailing

To keep scope reasonable for a first pass, "configuration" can be limited to basic on/off or include/exclude features of the report. For instance, allow including or excluding individual scan types or toggle between showing all details of findings or just showing aggregate findings counts. Another good on/off filter is to include findings that were closed/dismissed as this will remove noise from non-vulnerabilities and any false positives.

Permissions and Security

TBD

Documentation

Testing

What does success look like, and how can we measure that?

We have at least one customer that can take our report export and use it to satisfy a request from an internal team or one of their clients.