Scan generic packages uploaded to the registry for known vulnerabilities

Note to wider-community, sales, support and customer success

As always we welcome contributions so feel free to ask questions the PM of Composition Analysis if you are unsure about what needs to be done here and want to contribute the fix yourself!

NOTE if you are a user who also would like to see this feature, please UPVOTE 👍 it and comment to help it get prioritized (So it’s raised as part of our sensing mechanisms. Comments ideally should include what you want, how it would help you, what your pain point/frustration is today, and anything else that can help us focus on solving the problem.

If you are a team member commenting on behalf of a user (not ideal, as you can only upvote once!) Please remember to upvote and include as much information (what they are trying to solve for, their setup) as possible in addition to a salesforce or zendesk link.

Release notes

You've been using the generic package repository to publish binaries to your project. These may be packages in a format that the registry does not yet support or any other type of files that you want bundled with your release.

Until recently, you've had no way of knowing if those generic packages had any known vulnerabilities. Moving forward any generic packages uploaded to the registry will now be scanned using GitLab's known CVE database and any vulnerabilities will be raised and ready for remediation.

Problem to solve

Generic packages uploaded to the GitLab registry are not currently scanned against the vulnerability database.

Proposal

Consider scanning packages uploaded using the generic package repository against the known CVE database.

Other considerations

To add DS support we need a way to match these packages with our vulnerability DB. This is usually done via a tuple of properties like package type, package name, package version. As far as I can see, the generic package registry will lack the package type information which might end up in matching accuracy issues.

We plan on adding support for type. This could allow us to match on that metadata.

• What other metadata would be useful?