SnykCon recap: Automation for better compliance and faster feedback loops

Automation is a key component of DevSecOps because it increases efficiency. Automating work in your software development lifecycle helps you integrate multiple tools into your workflow. It also lets developers, maintainers, and security champions focus on coming up with creative solutions for tough problems, rather than spending time on tedious manual tasks.

Two of the presentations at SnykCon 2021 focused on automation. Sam Hodgkinson and Ben Davies from Citrix detailed how they used automation to streamline the open source license approval process. Bain’s David Wiggs took us on a deep dive into using automation to enable pipelines as a service,  explaining how his team integrated security into their CI/CD pipeline. Both sessions highlighted using automation to strengthen a development workflow.

Automating open source license approvals

Many people know about open source software, but not as many know about open source licensing. Open source code is written by developers and is freely available for public use. Open source _licenses_distinguish how and when you can use an open source package. Automation can detect and analyze open source licenses in your code. This alerts you to the licensing restrictions that apply to open source packages so you can compare them against your internal legal policies to ensure that your code is good to go.

The challenge they faced

The engineers at Citrix wanted a way to discover all of the open source licenses within a project while supporting the many package managers and languages used across the organization. They also wanted to gate CI/CD builds based on license compliance, and to collaborate with their legal team to create more clearly-defined policies for everyone.

Sam and Ben started looking at Snyk’s platform for help. They felt strongly about creating a seamless, human-focused workflow that wouldn’t create pain points for engineers (or for their legal team) — and they liked the simplified user interactions they were able to build with Snyk’s tools.

Next, they investigated bringing the whole legal framework policy process into an automated API, with an eye on making their solution extensible for future needs.

Using Snyk output, Sam and Ben were able to make policy decisions with their policy API and give user-friendly feedback for developers to make decisions around policies that were approved or denied.

The solution they built

They created a CI/CD pipeline, starting with source code which goes right through the Snyk CLI. Snyk analyzes the source code and returns license information. That information passes through a license gate that decides whether to “fail” a part of the code based on license usage. Code that passes through the license gate is sent to a policy API, which responds with yes or no. (The policies come from the Citrix legal team.) This process is totally automated in 90% of their cases. Other cases may generate a ticket for manual review by someone on the legal team. But that review isn’t lost; it feeds back into the policy API for approval, and the developer can continue working.

Citrix produced a custom policy engine based on a complex legal framework. Snyk helped their team overcome technical barriers to fully automate the process, enabling security through the CI/CD pipeline. They also decreased their time to resolution. With an automated process, most policy decisions happen in seconds. Sam and Ben now turn on their Snyk tools as part of their build config, and the technology takes care of itself.

Closing the feedback loop

Introducing security into a software development pipeline isn’t a new idea. But people often focus on the mechanics of a pipeline, rather than how the pipeline itself gets used. David Wiggs from Bain asked: are developers using the software development pipeline you’re providing, and are they getting what they need from it? Think of security tools and testing tools as _products_that developers use. So if your pipeline is a product – are your users (your developers) successful with it?

Three pillars for automation

The “pipeline as a service” model starts with a working repository. Next, you might introduce a “custom action” repository that defines where pipelines are sourcing steps from. Then you might have a repository for tools; an API wrapper, repository tool, or any tool-specific automation.

These first three pillars minimize the number of places where changes are made and tracked. When users suggest ways to improve your process, you can make those changes in one place instead of repeating them in multiple locations.

Invoking the workflow

This layout sets you up for the following steps:

1. The pipeline workflow is triggered (think of this as a pipeline “executing'').The custom action repository is checked out.

2. The action.yml file checks out a security tool-specific repository.

3. Tool-specific scripts are executed. This way, feature requests or updates are made in one central place, and everyone consuming a custom action inherits the change.

Let’s look at this same pipeline architecture from the bottom up, starting with the security tool repository. This repository can contain scripts that define multiple functions. For example, you could call a PowerShell script that uses the Snyk API to see if a given repository is on the Snyk platform; if not, it imports that repository. At this point, a few scripts are being run and the rest of the architecture is allowing those scripts to be inherited for a given working repository.

Now let’s go up one layer. The custom action repository checks out the security tools repository and executes a security-specific script. With composite actions, you can orchestrate multiple commands as a single step. This creates a layer of abstraction that simplifies the user experience but also lets you call multiple scripts and introduce dependencies.

This is happening inside the action.yml file, which lets you establish versions without necessarily having to introduce changes into multiple working repositories.

At the top layer, you allow a working repository to see the GitHub custom action. As the workflow at the working repository initializes, it checks out the custom actions repository and brings its contents into the runtime. You’ll do a nested checkout again, which lets you leverage the action.yml file and scripts that live in the tool repository – all in the runtime of the working repository.

From a user perspective, you’ve introduced multiple custom scripts, but in a “native” way. You’ve infused security, using Snyk tools, into the pipeline by using GitHub actions. If GitHub actions can integrate security tools into a pipeline, developers don’t have to leave their familiar working space (GitHub) to get security information around their development process. You’ve created a faster feedback loop “under the hood” without asking developers to make changes in multiple places.

Exploring automation for better workflows

Automation can provide efficiency across your organization. These presentations describe two examples of using automation to your advantage, but there are many more. Snyk’s platform provides many tools for incorporating automation into your workflows – and incorporating security standards seamlessly throughout your development process.