A cloud native approach to infrastructure and application development enables simplification and speed. Many of the traditional tasks involved in managing and deploying server architecture are removed, and high levels of automation deployed, making use of software-driven infrastructure models. Applications can be deployed at scale, be resilient and secure, while also allowing continuous integration technologies to accelerate development and deployment. Cloud approaches are set to dominate the future, most authorities agree: according to Deloitte, for example, global cloud spending will grow seven times faster than overall IT spending until at least 2025.

The considerable use of automation in cloud native application – automated testing, automated deployment and automated infrastructure scaling – enables a much faster pace. Indeed, many of the larger enterprises in the space make thousands of deployments a day. But this model makes fundamental changes to previous ideas around operations and security – since what used to be considered separately as infrastructure is now a part of the application.

A new security approach 

New tools and a new approach to the security model are required to cope with these changes, completely redefining notions of application security and operations. Legacy security tools and processes were designed for a traditional software hosting infrastructure, and don't have the feature set required to cope with modern cloud applications. 

One reason is that many of the technologies common to the modern cloud software stack simply didn't exist when some common security tools were first created — and the scope of those technologies exceeds what was formerly available. For example, the modern DevOps toolset may well include infrastructure-as-code (IaC) tools like Terraform and Ansible. These tools can provision large amounts of infrastructure with relative ease, so it's essential they are secured. However, since they typically employ a domain-specific language with unique characteristics and functionality, traditional testing using tools like static analysis is difficult and may be ineffective. Checking IaC code and its configuration requires best practices and new tools at the cutting-edge of software and infrastructure engineering.

But IaC tools represent just one of the many challenges in securing cloud native applications. Concepts and approaches that were historically the domain of IT/Operational security have become part of the application security model, and thus the work of securing cloud native applications must start with the developers that build the applications, rather than sitting solely with IT/Ops security teams.

Test from the start

Cloud native application security demands a holistic approach, embedded throughout the software development life cycle, with vulnerabilities identified and remediated throughout the cycle, from the first line of code to the live production environment. 

As soon as application and infrastructure coding begins, so must testing that code, as part of this secure software development life cycle. As we've discussed, a traditional, single-pronged approach to this testing is no longer enough: static application testing, dynamic application testing, interactive application security testing and mobile application security testing are just some of the many tests needed for cloud native application code.

Of course, to reasonably be expected to share these responsibilities, without compromising their agility, developers need to be empowered by a security platform that works alongside them, one that is seamlessly integrated within existing, efficient workflows to provide insights and actionable guidance. At Snyk, for example, we surface information directly into IDEs, such as those in the Eclipse and JetBrains product families, as well as enabling local testing through CLI tools. 

Full cycle security

In addition to covering the local developer environment, the cloud native security toolset needs to be embedded into each stage of the software lifecycle. 

Source code management systems need to be covered by a modern, cloud native security system in a developer-friendly manner. Integration with GitHub and Bitbucket should be possible, for example — and the platform shouldn't just scan the code in a repository, but also surface vulnerabilities using the repository's own security features so that workflows are not interrupted. 

Second, modern cloud native applications are likely to make use of containers to further increase development speed and automate workflows, as well as to create some vendor-neutrality. Much of what typically ships in a container is open source: these components are predominantly Linux-based and used to run applications created using open-source languages and frameworks. But the Linux vulnerability space is complex, with around 50 times more vulnerabilities reported than in open-source frameworks. That's coupled with the fact that developers aren't typically operating system maintainers, and aren't hoping to become them. So these container images, created through Docker and similar tools, and other derived artefacts, require monitoring for both existing and emerging vulnerabilities, and this monitoring should not just detect problems, but also provide remediation advice. Snyk Container is an ideal tool for this purpose. 

Finally, the need for cloud native security management persists into live production environments, too. Historically, on-premises infrastructure often depended on the notion of a logical network perimeter, which kept internal resources safe from unauthorised traffic and thus commonly allowed for more lax security controls inside that perimeter. In cloud native, the idea of a perimeter is unhelpful. Almost any resource hosted by most cloud providers can be made publicly accessible with a few lines of configuration or a UI revision. And data that notionally sits on the same logical domain may, in fact, cross several networks and physical locations when it is used. 

Thus, a 'zero trust' model needs to be applied to cloud-based components and services, since all of these are a potential target for compromise. Regardless of network location, authentication needs to occur between all the nodes and resources in a cloud native system. This model is, once again, quite different from traditional notions and requires a toolset created for the cloud era.

While the specifics of cloud computing are constantly changing, its essential characteristics are in place and here to stay. The speed, scalability and other opportunities are undeniable. But enterprises are misguided if they simply port existing infrastructure and procedures into the cloud. They will miss out on some of the key advantages offered by cloud native applications – and very critically, they carry over outdated security models and tools. As applications are rebuilt and optimised for cloud conditions, so too must security procedures, approaches and toolsets.