Snyk’s Approach to Developer-First Cloud-Native Application Security

Security used to sit at the end of the development cycle. After the code was written, features merged, and infrastructure provisioned, security teams would then step in and review what was built. In a monolithic application world where we shipped software quarterly, this worked fine. In a cloud-native world where we ship software multiple times per day, this doesn’t scale very well.

Modern software delivery is all about continuous integration and continuous deployment pipelines, containerization, orchestration with tools like Kubernetes, and infrastructure as code. Deployment frequency is now measured in hours as opposed to weeks, and microservices architecture typically refers to dozens, if not hundreds, of services being developed independently. In this new world, older security models that revolve around security as a review/gating function just don’t work. That’s where the idea of developer-first security was born.

As opposed to security being at the end of the SDLC, this is about inserting security directly into the developer workflows through the IDEs, Pull Requests, and build pipelines, where security issues can be found and fixed immediately.

The open-source dependency problem

Modern software applications are typically built using open source components. Industry research shows that the vast majority of the code in commercial applications is from open source libraries, many of which have known vulnerabilities. Incidents that made the headlines include the Log4Shell vulnerability that spread to thousands of downstream applications in a matter of hours.

The problem is that while developers can download open source packages from a repository like npm, Maven, or PyPI in a matter of seconds, traditional security tools don’t find the vulnerabilities in those packages until the build is complete. At which point, the only option may be to scramble to patch the application or to delay the software release.

What Snyk does, however, is move that detection to the developer workflow. If you are writing your application in an IDE, Snyk will inform you about vulnerable open source packages in the application that you are building while you are coding. If you are sending a pull request, Snyk can be configured to find vulnerable packages and suggest upgrades as part of the PR process.

The key to the Snyk approach is that we are not sending a report of the vulnerabilities to the developer to fix later. Instead, we are giving the developer remediation advice, presented conveniently alongside the code. This reduces friction and significantly reduces the time and cost to fix issues before they propagate downstream. 

Container security in a continuous delivery world

Containers are now the default packaging for cloud-native applications, and while developers are getting good at building containerized applications, container images inherit vulnerabilities from their base layer, including operating systems and language runtimes. There have been repeated warnings from security teams for years that base images that are bloated or outdated remain a common source of exposure.

While the traditional approach to this problem involves periodically scanning the container registry for known vulnerabilities, with software being shipped daily or even multiple times a day, that approach doesn’t keep up with the pace of delivery. Developer-first security integrates container scanning directly into CI pipelines.

Infrastructure as code as a security surface

The term Cloud-native is as much about declarative infrastructure as it is about application code. Cloud storage buckets configured incorrectly, over-privileged access IAM roles, or simply “a database exposed to the world,” are all examples of security breaches that still top the list of root causes for cloud-based security incidents. Several high-profile breaches were caused by simple configuration errors and not sophisticated attacks.

When resources are defined in Terraform or CloudFormation templates, those risks originate in version control files. If the security review doesn’t happen until resources have been deployed, then they may already have exposed themselves. Snyk tackles this issue by adding the ability to scan infrastructure-as-code files.

When a pull request is made or a CI run is initiated, misconfigurations can be flagged before the resources have been deployed. Importantly, there are no changes in the feedback loop for the developers who continue to use the same code review workflow as they do for application changes.

Continuous feedback instead of compliance bottlenecks

The shift from periodic audits to continuous feedback loops is one of the biggest cultural shifts in DevSecOps. Several industry analysts have noted the benefits of embedding automatic checks throughout the pipeline. What you get is a preventive model that transforms security from a reactive auditing system to a preventive guardrail.

In a developer-first world, security signals appear at multiple stages. An IDE plugin will signal that a dependency being typed is vulnerable, a pull request will fail if vulnerable code is attempted to be merged, and A CI pipeline will automatically scan a container image or an IaC template. If something gets past one gate, there is still a good chance it will get caught at another.

This multi-stage feedback loop means that less and less emphasis is placed on manual review, and the time from vulnerability introduction to fix is as short as it can possibly be. This is where security moves from being a quality gate at the end of a pipeline to being a quality signal throughout.

Balancing velocity with risk reduction

While it is typically assumed that making security better will slow things down, what actually slows things down is having to remediate security issues after the fact.

If vulnerabilities are only discovered post-deployment, there is a scramble to patch them under pressure. Industry research has shown time and time again that delayed vulnerability management causes higher operational risks and makes your problems way more expensive to fix. In contrast, incremental fixes by developers as part of the development process ensure that changes are small, easier to test, and less likely to cause secondary issues.

The Snyk developer-first approach recognises this. By providing protection across open-source dependencies, container images, and infrastructure as code, and providing contextual feedback across the software development life-cycle, it aligns security with cloud-native velocity.

If you are shipping deployments all the time and your infrastructure is largely ephemeral, then security cannot be a gate at the end of a pipeline. It has to be collaborative, integrated, and automated.  The move to developer-first security is about recognising that the only place where you can enforce security at scale is where code is being written, not where it’s audited.