Allow air-gapped bundle-audit users reliable control of the internal advisory DB
Problem to solve
12.6 added an airgapped bundler-audit analyzer (see this issue). This update allowed customers to prevent bundle-audit from making network calls to update its internal advisory db when scanning ruby projects. The internal advisory db uses ruby-advisory-db.
The airgapped bundler-audit update removed live updates from the scanner phase and instead initiated vulnerability db updates during the docker image build phase. This means that users running in airgapped mode will not get an updated DB until bundler-audit is rebuilt (e.g. when publishing a new version).
There needs be a way for customers to easily specify (and work with) an up-to-date version of bundler-audit's advisory db.
Intended users
Further details
Proposal
Regularly build a new docker image of bundler-audit tagged with the current build date (e.g. bundler-audit:2019-12-01) allowing customers a direct way to subscribe to a known bundler-audit vulnerability db version.
Allow the user to specify a url to a fork of the ruby-advisory-db. In this way users will be able to keep the internal bundler-audit db at their desired state of liveness.
Implementation plan
Backend
-
add variables to control the repo url and git ref name -
clone the advisory db from the given repo url and ref
Product Management - @NicoleSchwartz
- Not part of release post, wait until epic complete
Permissions and Security
Documentation
-
Add an entry to explain this capability and point to the image list in https://docs.gitlab.com/ee/user/application_security/dependency_scanning/index.html
Testing
-
Create a ruby-advisory-dbwith fake advisories and a job pointing to this db - the expectation should match the advisories in this db.
What does success look like, and how can we measure that?
-
bundler-auditdoes not issue a network call when auto-update is turned off and the remote advisory url matches what is already in the image