Debricked launches automation engine

Development organizations are decentralized in their nature. Decisions on how to solve problems are made by individual developers on a daily basis, including the decision to import new dependencies.

This is both healthy and necessary in order to develop functionality at scale and with speed, however, it presents a challenge; how can we make sure that the decentralized decisions of individuals does not introduce third party risk in the form of vulnerable, or non-compliant, dependencies?

In essence, this is what the Automation Engine aims to solve. By creating rules using the Automation Engine, you can define what risks you accept or not, and how strictly you want to enforce the rules.

Two types of rules

You can create two basic types of rules; rules that notify and rules that enforce. Rules that notify work by notifying a defined set of users that a rule has been breached, either via email or by printing a warning in your pipeline.

This is useful for rules addressing risks that, while important, are not important enough to prevent pushing or merging code.

Rules that enforce are more strict. They work by failing a pipeline if a rule is breached, thereby preventing the code from being pushed or merged. These rules are useful for blocking risks that are deemed unacceptable to enter your codebase.

In addition to the two main types of rules, you can also set up rules to automate setting review statuses in Debricked, by marking vulnerabilities as vulnerable or unaffected based on some condition.

How rules are created

The Automation Engine has a flexible “if-this-then-that” type rule builder that allows you to create a multitude of different rules. Construct your rule by filling out the fields, adding AND or OR conditions to create more complex rules.

Once you save the rule, it is automatically applied to the repo it was created for. See our documentation for more details.

Example rule

One of the more frequently requested rules, that can be created with the Automation Engine, is to block new dependencies containing vulnerabilities from entering your codebase.

Such a rule will fail the pipeline if a commit with a new dependency, affected by a vulnerability, is pushed – while not failing if existing dependencies are vulnerable.

Applying this rule allows you to “put a plug” on the inflow of vulnerable dependencies while taking your time to get rid of existing vulnerabilities in an organized manner.

Here’s how to build such a rule: 

When a commit triggers the rule the pipeline fails:

Due to the flexibility of the system, there are more possible rules than can be accounted for. Try some out! Not yet a Debricked user? Start a free account here!

What’s next?

Creating rules with licenses, open source health metrics and more detailed vulnerability data as inputs – with Slack and custom integrations through an API endpoint as outputs are just some examples of future development.

The Automation Engine is still in its early phases. Over time it will develop into a fully fledged system to build your automated Open Source Management processes.

Exciting times ahead! 🙂