Back to Blog

Securing your Software Dependencies with Rego's Policy as Code

Securing your Software Dependencies with Rego's Policy as Code

In our previous post Intro to Open Policy Agent for Policy as Code with Rego we introduce the very basic fundamentals of Open Policy Agent and Rego. Rego is a declarative language designed for policy evaluation and is the language we use at Hextrap for writing custom package firewall policies.

We support lots of different options for securing dependencies with our firewalls including typosquat detection, soak-time, unmaintained package detection, allow lists, deny lists, etc. However, these don't always fit the needs of every software or security team.


Custom Policies

Custom Rego policies allow for much greater control over allowing or denying packages based on package metadata such as license, release date, version, security score, dependency count, SLSA provenance, and popularity, to name a few.

These custom policies can be used in conjunction with existing firewall settings (i.e. enable typosquatting protection and your custom policy) or act independently with other protections turned off.

For example, your team may decide to only allow MIT licensed dependencies with a policy like so:


package hextrap.firewall

import rego.v1

default allow := false

# Allow if MIT licensed
allow if {
    input.package.license in {"MIT"}
}

# Allow not MIT licensed, only if it's our own
allow if {
    startswith(input.package.name, "our-org-")
}

Because multiple rules are implicitly OR'd together, this will block any packages that don't start with "our-org" or aren't MIT licensed.


Security

There are cases where security teams want extremely strict controls around what dependencies are downloaded into CI/CD platforms, and while there's certainly plenty of options for running your own package repositories, these can be unwieldy to manage and expensive.

Hextrap package firewalls can be a more attractive and lightweight approach while still achieving the desired effect. SLSA provenance is a good example of this -- many teams with strict security oversight desire to only use software packages that have SLSA provenance to prove their build process is tamper-free. While it's still up to the CI/CD tooling to retrieve the actual provenance, a custom policy and quickly block any packages that simply don't have it:


package hextrap.firewall

import rego.v1

default allow := false

# Allow only if dependencies have SLSA provenance
allow if {
    input.deps.has_salsa_provenance == true
}


Additional Signals

While we currently have around 20 different attributes that can be used to craft custom policies, we're routinely adding additional signals when the right data is available. If there's valuable information you think we're missing, let us know!

Protect Your Supply Chain

Add a security firewall to your package manager and CI/CD pipelines.

Get Started Free