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.
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.
- add variables to control the repo url and git ref name
- clone the advisory db from the given repo url and ref
- Does this have to be added to a release post?
Permissions and Security
- 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
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-auditproject auto-publishes tagged images under a consistent schedule into container registry.