Skip to content

Add Dependency Scanning (security findings status) information to the Dependency List View

Quick links for easy access:

Problem to solve

The Dependency List shows all the dependencies in a project.

One of the relevant information people are interested in for this view is the security status for each dependency. In this way, they can easily check (and prove to Compliance) that the app doesn't contain any insecure component.

We already have Dependency Scanning results available. We should link this information in the Dependency List view.

This is different from the Security Dashboard because here we have a dependency-centric view, listing both vulnerable and safe components. The Security Dashboard is vulnerability-centric and shows only vulnerable ones.

Target audience

  • Delaney, Development Team Lead

  • Sam, Security Analyst

Proposal

Add a new column to the Dependency List with the security status for each given dependency, if available.

The status could have three values:

  1. green: the dependency scanning job run, and no vulnerability was detected
  2. red: the dependency scanning job run, and a vulnerability was detected
  3. unknown: the dependency scanning didn't run, or results are not available

Users can click on the status and see more details about that.

Experience:

Vulns detected:

List: All Tab List: vuln tab
all-tab vulnerable-tab
Interaction:
  • When the user clicks on the controller, the list below the component will expand down to make way for the associated vulnerability sub-list.
  • When the user selects a vulnerability, the vulnerability modal will appear with all the same information and actions we have available today.
  • When the user takes action on an open controller, the list will collapse and the component's vulnerability sub-list will no longer be visible.

Action Area:

Screen_Shot_2019-06-14_at_8.54.24_AM

Rules:
  • Default sort order is by component name even if vulns are detected.
  • List remains at 20 components per page.
  • There is no limit (based on experience design) to how many components can have their vulnerability sub-list open at one time. If there is a technical limitation then let me know and we can discuss.
    • IF a component has a lot (20+) associated vulns, the interaction remains the same and the vuln sub-list extends the height of the page to accommodate the vulnerabilities. Again, unless there is a technical limitation, then let's discuss.
Sort behaviour:
  • A new sorting option has been added. Users can now sort by Severity which will order the list by components with the highest severity detected for an associated vulnerability. Dismissed vulnerabilities should not be considered when sorting by severity.
  • Sorting as well as pagination are distinct and preserved to each tab.

Screen_Shot_2019-06-14_at_8.52.08_AM

No vulns detected:

List with no vulns
no-vulns
Interaction:
  • IF no vulns are present we will show a 0 in the vulnerability tab label and make the tab inactive. The user can only access this tab if there are components with vulnerabilities.

Specification

👉 Design specifications

Permissions and Security

Permissions to see security status should be consistent with permissions of the same information in the merge request widget.

Documentation

We need to document which information is available and explain the possible values.
We can also crosslink this from the Dependency Scanning documentation.

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

The number of page views for the Dependency List (should be already implemented).

Implementation plan

Edited by Tetiana Chupryna