Make Gemnasium report path to vulnerable dependency when graph available
Problem to solve
In order to support dependency paths, and before extending the lock file parser the gemnasium analyzer provides, we must define the interface these parsers must implement to return a graph, and make Gemnasium extracts dependency paths from this graph.
Proposal
- Gemnasium provides an interface lock file parser implement when they're able to turn a file into a dependency graph.
- When generating a Dependency Scanning, Gemnasium reports a dependency path for any vulnerable dependency, if dependency graph information is available.
Implementation plan
-
update the common library gitlab-org/security-products/analyzers/common!116 (merged) - add new Go structs that correspond to the new JSON fields added to the Dependency Scanning report schema
- release new version
-
update gemnasium, and release a new version gitlab-org/security-products/analyzers/gemnasium!100 (merged) - introduce a new Go interface lock file parsers will implement, if they're able to build a dependency graph
- update to the new version of the
common
library, so that the new JSON fields can be added to the security report - change the convert package to add dependency paths to vulnerable dependency, when the lock file parser allows for it; it reports one single path even there are multiple paths; update unit tests
Permissions and Security
N/A
Documentation
N/A
Availability & Testing
Only tested via unit tests, until one of the lock file parsers supports dependency graph parsing. See #229473 (closed) for instance.
What does success look like, and how can we measure that?
When a lock file parsers supports dependency graph parsing/building, the Dependency Scanning report generated by Gemnasium adds dependency paths to vulnerable dependencies.
What is the type of buyer?
Links / references
Edited by Fabien Catteau