Research: Dependency List (Bill Of Materials) - Minimal to Viable
👉 Survey results
What’s this issue all about?
Research is required to gain insight into what it would take for Dependency List to become a viable Software Bill of Materials (SBOM).
Who is the target user of the feature?
Compliance (the sbom itself)
AppSec / Dev secondarily (we surface risks and findings based on the identification of dependencies in the vuln list)
What questions are you trying to answer?
What would be required for users to meet SPDX SBOM needs using only GitLab?
Core questions - Survey
- Should we rename the Dependency List the SBOM?
- When do users want the SBOM generated and signed and included as part of the package? (Always? the default branch build only? protected branches only? specific tags only? aka - only prod and if prod how do they designate that? things in addition to prod, if yes what and why)
- What do people call introduced application dependencies?
- what do people call upstream dependencies?
- do people have different names for application software dependencies vs container dependencies?
- Add search to page - what types of searching do they want to do? (use wildcards? regex? >= ? CVE?) do they want to search license and dependency and container and version? what else do they want to search? can any of that be re-directed to the vuln list?
- How long do they expect the sbom artifact to live (ttl)
Distributions:
-
Social distribution -
In app distribution -
GL - internal distribution (ongoing)
Additional questions for UX
Additional questions - Design (Pajamas)
- How do we show All vs Application vs Container dependencies?
- How do we explain where the results came from (latest pipeline, default branch etc)
- How do we add the SPDX download in addition to the current json download?
- What kind of loading pattern can we use while generating the spdx download? can we just email them? (it could take a bit) do we need to yell at them not to navigate away?
- how do we do grouping by container?
- how do we do grouping by introduced dependency?
- is grouping by container and introduced comparable (same toggle/option)
- should grouping be on by default?
- how do we want to link out to the policy info and settings - should that still be a tab?
What hypotheses and/or assumptions do you have?
- Yes we should call it SBOM
- "Upstream dependencies"
- people want to search all the things and we'll have to force push them to the vuln list
What decisions will you make based on the research findings?
Prioritization and scope of the production effort to make Dependency List viable.
What's the latest milestone that the research will still be useful to you?
need finished by feb 2022
POST MVC - Break into new issue(s) ?
- how do we want to show policy violations? (license for now, dep also in future)
- if we added a way to group by introduced (accordion the upstreams, move the vulns to vuln list) what do we need to show on the list (summary / count, just there are issues?)
- what does linking to the vuln list from a specific dependency or container look like?
- How do we allow users to navigate to different levels? (project -> sub-group -> group -> workspace -> tag?)
- How do we add project information if you have navigated above project level (or show always)
Edited by Andy Volpe