Cloud-native development has become the de facto way that companies make new apps due to its speed and cost savings. While it has opened up the world of Kubernetes, containers, and serverless to most organizations, they still need to grapple with certain complexities and security concerns that this style of development brings. 

Concerning the use of modern, cloud-native application services such as microservices, functions as a service, containers and container orchestration frameworks (Kubernetes), more than 80% of developers report that their organizations are in the process of implementing, in the process of piloting, or already using these services, according to the IDC report “PaaSView and the Developer 2021.“

This is only expected to grow, according to analysis from Gartner that found that the cloud platforms with the highest (over 20% of respondents) adoption plans in the next 12 months were cloud-managed Kubernetes and container platforms (CaaS) or aPaaS, citizen development platforms, and cloud-managed serverless function platforms (fPaaS/FaaS).

RELATED CONTENT:
How these vendors help companies with cloud-native security
A guide to cloud-native security tools

“Today, if I’m going to write a new kind of customer service portal. For an insurance company, the likelihood of that not being cloud native is very low. Because it is just more scalable and much easier to update and much more resilient,” said Rani Osnat, the VP of strategy and product marketing at Aqua Security. 

Cloud-native development changes the way that developers traditionally approached development with the use of CI/CD and more rapid methods of continuously updating software. 

This has presented some challenges since users don’t necessarily have advanced knowledge of where everything will run because it can run anywhere, according to Osnat. 

“You get this much more flexible environment to work in, but it also requires you to be a lot more cognizant in how you package code and deliver it compared with older kinds of waterfall SDLC or where it was a much slower process,” Osnat said. 

Because of the difficulty in setting up Kubernetes, few companies use the vanilla Kubernetes, instead opting for more managed options. One such option is a distribution of Kubernetes that has better defaults and is more suited to certain types of applications like K3s, the lightweight Kubernetes which is used a lot in IoT. The single-node Kubernetes can also be effectively used in development and testing, according to Osnat. 

Moving deeper are the cloud-managed offerings such as AKS, EKS, GKE, and others. 

“Those are basically set up for you in terms of the cluster. You don’t need to do much with configuring a master node,” Osnat said. “ A lot of the cloud developers will create on-prem versions of these. Amazon, for example, has EKS Anywhere, which is identical to EKS, but you can run it on-prem, or even another cloud if you want, at least in theory.”

Even further are the platforms like OpenShift, Tanzu, where they wrap Kubernetes with additional functionality with more opinionated or preset configurations and other capabilities around it such as identity access management, and better versioning and deployment controls, Osnat explained. 

Cloud native’s dependence on open-source requires extra security

Both the use of cloud-native development and open source is growing hand in hand, prompting companies to put up additional security measures to work with the much more open code. 

“Today, in a typical cloud-native application, you’ll see that 70-80% of the codebase is open source. So you could say the cloud-native applications have a lot of reusable code. And the issue that creates is that first of all, there’s a supply chain issue where you don’t govern all the code that comes in,” Osnat said. “And the second is known vulnerabilities. So open source has many more known vulnerabilities than custom code simply because it’s open.”

Contrast Security’s 2021 State of Open-source Security Report revealed that traditional software composition analysis (SCA) approaches attempt to analyze all of the open-source code contained in applications — which translates into a huge time and resource expenditure chasing vulnerabilities that pose no risk at all. Yet, for third-party code that is invoked, the risk is inherent: The average age of a library is 2.6 years old, and applications contain an average of 34 CVEs. 

While working with functions, it becomes more apparent that the traditional tools that are used for security won’t suffice, according to Blake Connell, the director of product marketing at Contrast Security. 

“With functions, because you’re just assembling these small bits of code, all those little small bits of code are entities in and of themselves. So the sort of exposure is broader for security issues. And then these permissions that are part of these functions are sort of set in kind of a default way,” Connell said. “Depending on how you assemble your application, you may want to tighten down the screws a bit more on those permissions. And that’s a common challenge with the functions serverless security angle, which is this notion of overly permissive functions.” 

Securing serverless architecture

Also important is securing serverless architecture since serverless computing is at the forefront of the cloud-native development trend, according to Connell. 

According to Contrast Security’s State of Serverless Application Security report, a big majority (71%) of organizations now have six or more development teams creating serverless applications. These findings are consistent with other research, such as New Relic’s Serverless Technology semiannual report, which shows a 206% increase in average weekly invocations of serverless applications from 2019 to 2020.

Connell added that the typical company is protecting its serverless applications with a disconnected set of legacy tools that no longer work that well—even for applications on traditional infrastructure.

For serverless applications, these tools are even less effective. “No-edge blindness” resulting from functions that do not have a public-facing URL gives them poor visibility into serverless architectures. The abstraction of infrastructure, network, and servers proves confusing for traditional tools and contributes to a false-positive rate that can exceed 85%, Contrast Security found. Legacy tools simply lack the context to do adequate analysis. 

Serverless also presents its own challenges because it’s based on ephemeral things that can happen quickly, and then disappear. So all of these require a very different set of controls, according to Osnat. 

As a result, organizations need a good prioritization strategy to understand which vulnerabilities are affecting the environment, Osnat explained.  

“You might have vulnerabilities that rely on some network connection to be exploited. But if you’re running this in a purely internal and capsulated application, it’s less adverse than an open one that’s open to the internet,” Osnat said. 

The stack affects cloud-native security

The third factor that affects security in cloud native is the beginning of this new stack that applications are being run on. Companies are no longer relying on an underlying server or VM to do the isolation for them. Users are also running various types of workloads. For example, if they’re running containers on a container-as-a-service platform like AWS Fargate, or ACI on Azure, these are containers that run in a continued virtualized environment, and there is no underlying VM that one has access to. 

Organizations are giving developers more security responsibilities, however, there is a skill shortage in this area, and there are many more developers than security professionals. This has prompted companies to look towards more automated solutions that can augment the way developers handle security.

“We solve it by introducing a high degree of automation that enables developers to make security part of their daily work, but without expecting them or requiring them to change how they work or to become security experts. Nobody expects developers to become security experts and expects developers to set policies. The policy should be set by security. So what we do is we enable this solution that spans developers, DevOps, and security,” Osnat said. “Security has visibility into what’s going on and can prioritize issues for developers, and then have developers fix that in their code as far left as possible or as early as possible knowing full well that some things will not be fixed. We can say this needs to be remediated as soon as possible, you upgrade to this version, or you swap this package with this package or you change this configuration, and what cannot be remediated or can be maybe snoozed or remediated later, or you can have a mitigating control for it.”

While there is a lot that cloud providers are doing, there is also a big area of startup development of individual vendor providers of solutions that help address security concerns, according to Lara Greden, research director for IDC’s Platform-as-a-Service (PaaS) practice.

“It’s not that organizations with their software development teams are just only making use of what the major cloud providers are providing in terms of security,” said Greden. “They’re also adding these other services that their applications are calling on the back end for services.”

Another way to solve some of these security issues is through the notion of “deputizing” developers to be a part of the security effort. The days of developers flinging code over to security, having the security team running static scans, and creating a pile of potential vulnerabilities before shipping them back to developers just won’t fly in today’s cloud-native world, according to Contrast Security’s Connell. 

Now automation finds a vulnerability, perhaps an overly permissive function, and gets that information to a developer in their environment early. Then it provides sample code and the suggested remediation. Developers can then literally copy and paste code, or modify it slightly, and then just resubmit that function. And the solution scans again, and when everything is ok and it moves on, Connell explained. 

Cloud-native development is becoming more accessible and more expansive 

Whereas at first organizations were thinking in terms of using a private cloud for their applications by making use of technologies in their data centers, now it has increasingly moved towards computing at the edge, according to IDC’s Greden. 

“What we have today is edge compute, that is, in some cases, being provided by the cloud providers,” Greden said. “And that’s sent as a cloud service, but from edge locations. It’s also being accessed in terms of organizations owning their own mini data centers.”

Even though there is less investment now in on-premises types of data centers or location centers, the need for compute to be close to the application for things like latency reasons has not gone away. “Now, we’re able to apply cloud-native development to those types of locations,” Greden added. 

Also, now more people than ever before can make use of cloud-native development through citizen development and the use of low code. 

“It’s really more an era of augmented application development where developers, including full-stack developers, whether they’re junior or senior, are saying that the number one attribute of the tools they use is code abstraction, as represented by low code and no code,” Greden said. “We’ve gotten to the point where vendors are able to package certain components together, not have to rewrite code, and it really contributes to code simplicity and code elegance.”