The Future of Security: Developer-First + Cloud Native

Snyk

By Simon Maple, Field CTO

Digital transformation is turning every company into a technology company. Enabled by cloud technology and DevOps practices, more companies are creating internal tools and external apps to vie for a competitive advantage. With this transformation, developer practices have shifted, putting them in control of not just their code, but also the cloud infrastructure it runs on. It’s time for security practices to also shift.

For security practices to stay ahead of bad actors, they need to evolve. Security needs to, 1) be baked into code from the start (dev-first) and, 2) account for all of the code, dependencies, and infrastructure that comes with cloud native applications. Here’s how we can do that.

1. Rethink security responsibility

   In a traditional security model, AppSec is responsible for identifying security vulnerabilities. Dev owns the code, but AppSec owns the tools, has the expertise, and finds the vulnerabilities. This siloing creates bottlenecks, increases developer remediation workload, and causes general friction between teams.

   We need to shift security earlier into the development process, making developers the first line of defense. By putting expertise and tooling in the hands of product developers, they can build security into the code (shift left) and decrease the workload on AppSec, freeing them up to work on higher level projects.

   Additionally, as security responsibility shifts towards developers, it needs to include more than just code and dependencies. It must also include the containers and infrastructure as code (IaC) that are the backbone of cloud native applications.

2. Rethink security tooling

   Traditional security tools (SCA, SAST, DAST, etc.) were created for security experts in AppsSec who can apply their own knowledge to prioritize fixes. This is a blocker of developer adoption. Developers need security tools that are more helpful, adding context, prioritization, and remediation advice, not just identifying vulnerabilities.

   Additionally, security tools need to fit seamlessly into the developer workflows. This includes all tools for writing, deploying, and delivering applications. For any tool to be adopted by a developer, it needs to:

   1. Have self-serve usage, including easy onboarding, intuitive workflows, and great documentation.
   2. Seamlessly integrate into IDEs, source code repositories, and CI/CD pipelines.
   3. Offer a rich API and automation-friendly client.
   4. Be adopted by the open source community (for credibility).

   Security tools need to meet the needs of development and security in order to drive a truly collaborative security effort of shared workflows and priorities.

3. Rethink security priorities

   In a cloud-based world, unpatched base images and misconfigurations in IaC are just as dangerous as code vulnerabilities. As such, all vulnerabilities need to be considered while securing an application.

   Whether done through tools (ideally) or processes, developers and security team members need to look at the entirety of a cloud native application’s security posture and do what’s right for themselves and their users.

Developer-first, cloud native security

Developers are leading the charge to the cloud, so it only makes sense that we empower them to build fast and stay secure.