Cloud-native has evolved from a marketing term into a highly desirable and useful architecture choice, yielding significant benefits for designing, building, and deploying applications. But security is too often overlooked. Advantages of cloud-native applications include increased flexibility and scalability, ease of management, faster time to market, and lower cost requirements. Because of this, it's easy to see why shifting software development efforts to the cloud has become the default for many organizations. However, amid all the benefits that cloud-native applications bring to the table comes an intricate and layered attack surface that is still widely misunderstood and under-secured. Containers, APIs, infrastructure as code (IaC), microservices, and other cloud-based components all comprise a large portion of these cloud-hosted apps. A 2020 report from the Cloud Native Computing Foundation noted that 92% of surveyed organizations used containers in production, up from 84% the previous year. Given the complexities of such an advanced architecture, traditional testing methodologies simply aren't enough to address security holistically for cloud-native applications. While adopting new technologies like cloud-native is essential, organizations must ensure application security is brought along every step of the way. Here's where to start.

Traditional app sec vs. cloud-native security

To properly secure cloud-native apps, you must first understand the nuances between traditional and cloud-native app sec. Generally, traditional app sec is more contained; security teams understand, for example, that cyber criminals generally go after databases, applications, and other controlled environments. With cloud-native, there are many more components and connections interacting and "speaking" to one another behind the scenes to make it all work. And while this makes for more dynamic applications, it also creates an exponentially larger attack surface for nefarious actors to target. For example, cyber criminals can now try to gain access into Amazon Web Services (AWS), Kubernetes, or Docker environments. And if at first they don't succeed, they can move onto other interconnected technologies, such as APIs or other building blocks of the infrastructure. For security teams and software developers, this presents a massive challenge. Not only are they now tasked with learning to build applications in a completely new environment—at a record pace—but they must also evolve the way they test for security vulnerabilities that may occur in any of the incorporated cloud components.

Top challenges in securing cloud architectures

In the past, it was common for security to lag behind the technology itself, but it's critical, given the intricacies, for organizations to prioritize security in the build phase of cloud-native apps. Here are some of the challenges in doing so.

Code is everywhere

In the past, security teams could scan their code using an application security testing tools in a fairly simple, intuitive manner. Cloud-native applications require a shift in approach. With cloud-native applications, pieces of code are present in several places and run different parts of the infrastructure: Docker files, Kubernetes orchestration files, AWS/Google Cloud Platform/Azure infrastructure files, and more. This means we now have configuration files that need to be evaluated, and configuration must be accurate in order for all the technology systems to appropriately speak to one another. Essentially, code is everything, and everything is code in these applications.

Infrastructure-as-code risks and rewards

With the rise in cloud-native comes a rise in IaC, or the process of provisioning and configuring an environment through code instead of manually setting up the required devices and systems. Once code parameters are defined, developers run scripts, and the IaC platform builds the cloud infrastructure automatically. When establishing IaC, an organization's infrastructure is now part of a set of configuration files, which all need to be scanned as part of the overall code. This is a challenging task for any security testing solution and will present one of the biggest obstacles to date in application security: making the connection between code, infrastructure, and configurations. Despite its challenges, IaC as part of cloud-native infrastructure is a major opportunity to finally have a single holistic platform that handles all layers similarly. Instead of having one dedicated tool for network security, another for the operating system, and yet another for application security, developers and organizations alike can now benefit from all of these technologies being coded and scanned in a single, streamlined process.

Security is now on devs, DevOps, IT, and more

With dispersed code come dispersed security responsibilities. Security must now be evaluated in the code, infrastructure, third-party modules, and modules developers don't even have access to. Security needs to not only be handled by developers, but also by DevOps and IT teams. With this complex, but necessary, shared ownership, it's easy for security to fall through the cracks, which creates significant room for error—and one small mistake could give cyber criminals their next big opportunity.

Tension between 'shift left' and 'shift right'

There's always been tension between two approaches in app sec: "shift left" (moving it up in the development lifecycle) versus "shift right." With cloud-native complexities, this only increases, with each approach bringing its unique set of pros and cons. Shift left often yields earlier results in the testing process, so it's typically the recommended approach. Often, a shift-left approach to security testing leads to cheaper and faster remediation cycles. With shift right, results arrive later in the security testing process. The benefits of this approach include a lower percentage of false positives and specific results that are actionable. The ideal approach is embedding security throughout all stages of software development in an automated manner. However, with tensions between both sides only increasing in cloud-native testing environments, this presents another challenge for developers, security teams, and organizations at large.

Best practices in securing cloud-native

As more organizations continue to develop cloud-native applications to advance digital transformation efforts, there are a few best practices to help overcome some of the challenges facing developers and businesses at large. These include the following.

Test code from the first line that is written

Don't assume any portion of your codebase is intrinsically secure. Whether proprietary or open source, every line must be thoroughly inspected from the onset of development to ensure that any and all vulnerabilities are addressed. And when new features and functionalities are added to the application, these introduced code blocks must be given the same time and attention as all other pieces in the bigger software puzzle.

Test the IaC

This has a major influence on the security of applications. Just as you take careful, thorough steps to testing and securing applications, the same must be done when it comes to IaC.

Ensure every component is secured

This includes third-party components such as APIs, which are a very common approach to building software, but one that can introduce a variety of vulnerabilities into the environment. At the end of the day, they must be tested as well to avoid using vulnerable components.

Understand the risks

Cloud-native is the future; undoubtedly, it is here to stay. In addition to adopting the technology at an accelerated pace, organizations must also factor in the proper application security testing practices needed to ensure security isn't seen as another added layer of complexity but rather an essential step in software development. With greater awareness of the challenges of cloud-native and greater adoption of best practices to overcome these roadblocks, organizations can reap the full benefits of the technology without sacrificing security. This article was originally published on TechBeacon.com