Snyk in 30: Developer-first security democast

In our latest Snyk in 30 democast, I demonstrated working on an app, starting in an IDE and going all the way to the live app deployed in the cloud. Along the way, I showed how Snyk fits into the tools a real developer might use. Specifically, I focused on the practical aspects of implementing Snyk in a real-world development and cloud environment, answering questions like: 

• How do we make security as straightforward as possible for developers?

• How do we use Snyk tools in tandem, without causing redundant alerts and unnecessary noise?

• What does Snyk look like from both the developer and security team perspectives?

I’ll cover some of the main highlights from the presentation in this blog post, but if you want to skip straight to the video, you can do so here. 

Security must be developer-first

“Fish where the fish are,” is an old business saying that reminds us to go where our customers are. If you’re a security team helping developers find and fix issues, go where they are — in their tools and workflow. It’s also important to show them meaningful information to act upon. 

This is a unique challenge when working with modern apps. Often enough, every single part of an app is defined in code — its build and testing procedures, how it’s designed to run, and the infrastructure it requires. While this makes deployments faster, more repeatable, and more resilient, it also makes the software supply chains far more complex and fast-moving than in decades past. 

Put all of these factors together, and security teams face the significant challenge of finding a way to secure all these moving pieces that already-busy development teams will accept and implement. This is where the idea of developer-first security comes in. Rather than expecting developers to leave their daily workflows and environments, developer-first security tools focus on empowering them to fix security issues right where they are, throughout the code-to-cloud pipeline. “Fish where the fish are.” 

Here at Snyk, we’ve prioritized making our security tooling accessible and straightforward for development teams. We empower developers to find and fix security issues as they work within their projects — writing code and designing the app in the IDE, commiting the code and storing it in repos, merging changes into the main branch, and then on into the pipelines and to the cloud. Here’s what we covered about each of these steps during this Snyk democast: 

Securing code as it’s being developed

The most efficient and affordable place to find and fix a security problem is the moment it’s introduced. It’s easiest for developers to make a change while they’re actively coding and deciding which 3rd party packages to use. It’s all about guiding them to fix issues while the code is in front of them. 

I demonstrated how Snyk’s static application security testing (SAST) tool works within your IDEs, scanning code within seconds so developers can keep working quickly. It also syncs remediation guidance and information on each found vulnerability into the IDE so developers know how the security issue was introduced, how it flows through the code, and what to do to fix it.

Developer-first 3rd party dependency scanning

While we’re checking 1st party code, we can also secure the 3rd party dependencies. Snyk’s software composition analysis (SCA) tool builds a comprehensive graph of any third-party packages used within the app, along with their transitive dependencies. Then, it identifies which components are insecure. Whether it’s a package added by the developer, or a dependency of a dependency, Snyk shows the developer the correct place to make a change in order to fix the vulnerability. As they add packages, developers can also check an advisor score, which indicates factors that could make the package unsafe in the future, even if there are no vulnerabilities at present. We calculate this advisor score with factors such as the size of the component’s community and its popularity — which are great ways to predict if an open source package is a good fit for your app in the long run. 

In the democast, I focused mainly on the app code in the IDE.  Snyk can also run Kubernetes YAML, IaC configurations, and even container scans during real-time development, providing similar, developer-focused fix advice.

Automating security in the pipeline

Once code is done, it’s committed, pushed to repos, and ready to merge. Snyk integrates with code repositories such as Github, Gitlab, and Bitbucket. This not only provides another layer of security, but also monitors the code — even if it’s not being actively developed — and spots any new zero day vulnerabilities. Snyk also enables one of the most straightforward and actionable scans: the PR check. If a developer happens to save and commit an insecure component, our tools flag it at the pull request. We set these checks up automatically when a repo is integrated so the dev team doesn’t have to do anything. We also check the changes to the code to make sure no new vulnerabilities are being introduced. These built-in checks ensure that new changes aren’t creating new problems.

Integration with the repos means we can help fix issues quickly by creating PRs as well. We can fix a single vulnerability, many vulns at once, or upgrade outdated components with a fix PR. If teams are confident in the testing procedures, these fixes can be completely automated.

Container security and the noise problem

Containers are one of the most popular ways to package and run apps today. While containers are great for speed and avoiding the “works on my machine” problem, they do present a noise issue when it comes to security scans. “Fishing where the fish are” is great, but if you’re dropping a 200 pound boulder in the lake, you’re going to scare the fish away. Snyk takes care of this noise problem by running security checks for containers.

In the demo, I showed a typical container scan result for my app with 700+ vulnerabilities listed out as the result. Then, I demonstrated how Snyk suggests actions that a developer can take, without having to sort through all those vulns. First, I showed how to select a parent image (or base image) to build upon. We looked at how Snyk provides recommendations so that, as a dev, I can make one change to my Dockerfile to select a better parent image and clear up hundreds of issues. 

Then, we looked at another build process many companies use where a central team (platform or DevOps oriented) curates an internal set of “golden” base images they’d like developers to use. In the demo, we showed how Snyk can guide developers to use these golden images, and saw how they help developers focus on the vulnerabilities they might add to the container, versus noise from a parent image.

Developer-first deployment security

With our cloud infrastructure tooling, developers can be sure their cloud configurations are secure too. As mentioned, we can run these scans in the IDE. In the demo, I used the Snyk CLI to scan the Terraform config. Here again, IaC scans have a tendency to be noisy. When you solely scan the config file, you assume the worst case scenario and show every possible issue. However, if you combine the IaC scans with context from the live cloud environment, things change. In the demo, we looked at an app with an AWS S3 storage bucket. When I just scanned the IaC, I had 4 warnings about improper security settings for the S3 bucket. However, in my live cloud environment, I have a centrally-controlled policy that ignores those insecure settings, ensuring every S3 bucket is safe. In this case, Snyk combined the IaC scan with cloud context to get rid of any meaningless alerts and focus on more important misconfiguration issues. And because Snyk unites cloud and IaC, security teams only need to manage one unified policy engine to cover the entire deployment environment.

Snyk is built for security teams too!

Although I focused much of my time on the developer-first aspects of Snyk, this democast also covered how security teams use our tool. Snyk provides centralized visibility and reporting for all of these vulnerabilities — every app, every bit of code. Security teams can look at cloud or code issue details and drill down by compliance framework, environment, or specific issue. Then, they can save the most helpful report views and export or share them as links. 

Watch this Snyk in 30 democast to learn more

If you’d like to see these tools in action, check out the whole Snyk in 30 democast. And as a bonus to everything I mentioned above, attendees also asked several insightful questions during the Q&A portion of the presentation. During the last few minutes of the webcast, we had the opportunity to cover:

• Snyk’s internal security measures when working with customers’ code

• More info on our partnership for dynamic application security testing (DAST)

• More technical details on how we integrate with dev environments

If you’d like to learn more about our developer-first platform and dive deeper into this Q&A session, watch the presentation here.