Security in the Container Registry

One of Snyk’s key principles is what we call "developer first". In our product vision, this means fitting into the developer’s existing workflow and tools with powerful product integrations, to make security ownership by developers as seamless as possible.

In other words, we want to provide the option to tackle security wherever the developers already are, for example:

• Within the IDE, for example with our IntelliJ plugin, launched in late 2018

• At the git level, where developers can open pull requests to fix current issues and prevent future ones

• At the build stage, which, as a gate, tends to be a more DevOps-y complement to git

• In PaaS and runtime, for example with ourPivotal droplet, buildpack and broker integrations

• Within project management and messaging tools such as JIRA, Slack and others

Container layers and hidden risk

Containers (to use the term broadly) have been one of the most meaningful movements in the IT industry, and they present new security challenges, both on the development and the operations side of the house. For example, in the 'old' world of servers and virtual machines, many corporate teams use a 'golden image' methodology to maintain Operations’ control over the base (OS and packages) layer of their applications; the way Docker images are built, distributed and used makes it unrealistic for any cloud-based team to work according to this methodology, since container images have many layers whose source or robustness is not necessarily clear.

Snyk’s container vulnerability management scans Docker images by inspecting the image for both OS packages and key binaries, cross-referencing this with our proprietary Vulnerability DB—in the end providing a view into both direct and indirect dependencies, hidden within the image's layers.In the below screenshot, we can see Snyk’s functionality going five layers deep to flag a high-severity issue:

Finding risks is just the first step: the next challenge is fixing them within the flow, which is why we’re offering remediation advice within the tool. Another important consideration is basing all this on the right information, minimizing false-positives, which Snyk’s industry-leading Vulnerability DB offers.

But a secure developer shouldn’t stop there. Another security challenge lies in the next step, as you ship a potentially compromised image up to your container registry — doing this manually and with close security scrutiny can be inefficient, and automating the step without the needed guardrails can make operational control and audit much more difficult. Snyk’s approach seeks to automate based on sound security practices, and can be demonstrated in the following example.

Hello-ACR-world

We builtthis demo app, to scan all Docker images that are shipped to the Azure Container Registry (ACR). Instead of slowing down the development cycle, we’re building the scan and remediation advice into the ACR Tasks flow in this case. We can see in the below .yaml file that between the standard ACR Tasks of BUILD and PUSH, we’ve added a script that scans for vulnerabilities at both the image and app (binaries) levels:

This is defined to fail PUSH if high-severity OS vulnerabilities, and/or medium-high-severity 'app' vulnerabilities, are found; once this happens, we fail the scan and can’t go on to PUSH. We can see the process in slightly more detail in this short video:

The takeaway

There is added security and compliance risk embedded in the container model, and we can use Snyk's container vulnerability management to find and fix direct and—more importantly in this case—indirect vulnerabilities in our container image. In addition, we can take additional steps to automate our DevOps by adding Snyk as a gate before an un-fixed image ships to our container registry. These steps, together with Snyk's capabilities in source control, CI/CD and PaaS, present a compelling end-to-end container use case.

Do let us know what container registries you already use, and what your automation looks like when it comes to balancing efficiency and security!