Support passing lock files from build job to Dependency Scanning job
Release notes
Dependency Scanning can scan lock files created by user-defined build jobs.
Problem to solve
As a developer who wants to scan a project that has a dependency file but no lock file, I want to be able to generate the lock file in a custom build job, and pass it to the Dependency Scanning job(s) as a CI artifact. For example, I can set up a NuGet project so that Dependency Scanning scans the package.lock.json lock file my build job creates, and don't have to keep that file in the project repository.
Please note that keeping lock files in the git repo is considered to be a best practice, but they are cases where users can't do it or don't want to do it.
Intended users
User experience goal
Proposal
Document how to pass lock files from user-defined build jobs to Dependency Scanning jobs, and remove any blockers, or any problems making the setup complicated.
The job definitions of the Dependency Scanning jobs need to be updated so that the scan is performed even when the supported lock files aren't in the git repo. A solution is to make the rules:exist respond to the dependency files that come along with the supported lock files.
Further details
Right now the dependency_scanning job (base definition for all Dependency Scanning jobs) has no dependencies. To work around this, user need to explicitly override the job dependencies, and put the name of their build job. This is addressed #249569 (closed)
Right now the UI always link to the dependency file where the vulnerability was found, and even if this file doesn't belong to the git repo. This is addressed by #201857.
Implementation plan
-
update Dependency Scanning documentation to describe the method for generating a lockfile that can be detected -
update Dependency Scanning CI template to change the rules:existparameter of the scanning jobs so that they match dependency files corresponding to the lock files (e.g. addGemfilewhereGemfile.lockis expected (see https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Security/Dependency-Scanning.gitlab-ci.yml#L49)) -
update QA, and make sure this setup is covered by all compatible test projects by adding something like a build-FREEZEbranch invoking a build before Dependency Scanning and having an expected report similar to the test's master branch
Permissions and Security
No change
Documentation
To be documented in Dependency Scanning docs.
See Pre-compilation section of SAST documentation.
Availability & Testing
The scenario where lock files are passed to Dependency Scanning (DS) as a job artifact needs to be tested as part of QA.
We might have to introduce new branches to the existing test projects used for DS QA, but ideally we would reuse existing ones. For instance, we could have a job that remove the lock file from the repo, and expose it as a job artifact. This would ensure reproducible results.
What does success look like, and how can we measure that?
Users can easily scan lock files created by build jobs they've defined.
What is the type of buyer?
Is this a cross-stage feature?
No