Use OSSF to prevent risky artifacts from being downloaded

Context

The majority of software projects today rely on packages and container images that are publically available at sites like DockerHub, Maven Central, and npmjs.com. Using these artifacts is useful and helps make teams more efficient.

But it also introduces risk. Some artifacts contain malicious code and when downloaded can introduce security vulnerabilities to your SLDC.

While it's true many issues can be discovered with things like dependency scanning and container scanning, it would be better if these artifacts were never downloaded.

GitLab offers a Dependency Proxy that proxies and caches artifacts from upstream (potentially public) repositories. At the time of writing this, Docker Hub is supported for container images and we are adding support for Java packages via &3610 (closed).

GitLab also supports security policies which allow you to require that security scans (and their configuration) run in all of your projects.

Problem to solve

  • As a Security lead, I need a method to identify suspicious packages that are being downloaded by developers, so that I can create awareness of the problem and work towards a solution.
    • One idea we've had is to add an allow/deny list for artifact name/versions. But this introduces a new set of problems like "who maintains that" and that it's really just a reactive solution.
  • As a Security lead, I need to put policies in place that prevent suspicious artifacts from being downloaded using the GitLab Dependency Proxy, so that I can help prevent future security incidents at my organization.

Proposal

Consider integrating with OpenSSF Scorecard to help security engineers to identify suspicious packages. Scorecard is an automated tool that assesses a number of important heuristics ("checks") associated with software security and assigns each check a score of 0-10. You can use these scores to understand specific areas to improve in order to strengthen the security posture of your project. You can also assess the risks that dependencies introduce, and make informed decisions about accepting these risks, evaluating alternative solutions, or working with the maintainers to make improvements.

As an MVC, the GitLab Dependency Proxy when proxying/caching an artifact score that artifact and return the score via the logs. This would allow users to collect this information and build a plan to remediate the issue.

Longer-term, what will be really useful is to allow security engineers to create policies that will block those artifacts from being downloaded without approval from a project Owner.

Why OSSF, why now?

We recently began to build the MVC of Maven dependency proxy (&3610 - closed). As I've been talking to customers about it, I've been hearing more and more questions about how we will prevent risky packages from being downloaded.

Our first thought was to add an allow/deny list. But after speaking with several customers, it's evident that this would not be very useful, since it would mainly be reactive and introduce operational overhead.

There are also some challenges with how to actually filter artifacts when proxying them. From a technical perspective, checking for known vulnerabilities might be too slow.

But with the OSSF Scorecard, we can add an easy to use rating system that, although not perfect, does give security engineers some sense of the risks associated with a given artifact and they can build policies to determine how to proceed.