Cloud-native is a term so common in practice that by 2023, IDC predicts that over 500 million apps and services will be deployed using cloud-native approaches. In the last 12 months, organizations rapidly moved to remote working, so the spotlight has intensified around the cloud.
Today, the advantages of cloud-native applications in an AWS deployment, for example, are well understood. AWS delivers flexibility, scalability, usability, and so much more, but what is not so well understood is how software development efforts change in an AWS environment. The shift to cloud-native fundamentally changes the software development process, leading to accelerating the adoption of more DevOps practices and other strategies for rapidly delivering software, which is why AWS has become the default for many organizations' software development efforts. However, amid all the benefits of AWS, like iron-clad security of the cloud environment infrastructure, cloud-native development is a complex and intricate process that leads to new potential attack surfaces in custom and configured code. If customers don't fix these code vulnerabilities before reaching deployment in the cloud, it won't matter how secure AWS is. You'll still have attack vector exposure and be reliant on monitoring products that don't fix the root of your security risk exposure: vulnerable code.
The Difference Between Traditional AppSec and Cloud-Native Security
To properly secure their AWS environments, organizations must first understand the nuances between traditional and cloud-native application security. Generally, traditional AppSec is more contained; security teams understand, for example, that cybercriminals commonly go after databases, applications, and other controlled environments. With AWS, many more components and connections interact with one another behind the scenes to make all your applications and digital services work. While this intricacy makes for more dynamic applications, it also creates an exponentially larger attack surface for nefarious actors to target. Cybercriminals now seek to breach your AWS environment through its APIs, containers, Infrastructure as Code (IaC), microservices, and other building blocks. In fact, Gartner predicted that APIs would account for 90% of an application's attack surface by 2021. For security teams and software developers, this presents a challenge. Not only are they tasked with learning to quickly build applications in an AWS environment, but they must also evolve the way they test for security vulnerabilities that may occur in any of the incorporated cloud components. Given the complexities of this architecture, traditional security and testing methodologies aren't enough to address security holistically. Organizations must also ensure that security becomes an intrinsic and iterative process of improvement throughout the entire software development life cycle. This approach to security posture is where the combination of AWS and Checkmarx can improve application development security in the cloud. For example, by leveraging Checkmarx Application Security Testing solutions for AWS, organizations can perform static code, third-party code, Infrastructure-as-code, and open-source analysis within the secure confines of their AWS software development environments. With the right scanning solutions, organizations can solve many of the critical challenges they face.More Code to Worry About, but Easier to Audit
An AWS development environment requires a shift in DevSecOps approach because code is present in various places, running different parts of the infrastructure: Docker files, Kubernetes orchestration files, infrastructure files, and more. Organizations now need to evaluate configuration files as if they were application code, and configuration must be accurate to speak to one another for all the technology systems appropriately. Essentially, code is everywhere, making it easier to comb through with an automated security scanning solution. The good news is that turning the tools and techniques used in source code analysis to other components can help automate your security process.Infrastructure-as-Code (IaC)
Cloud-native development has fueled the rise in infrastructure-as-code (IaC). Infrastructure as code requires a new provisioning process and configuring an environment through code instead of manually setting up the hardware devices and systems. Infrastructure as code enables organizations to have a single holistic platform that handles all infrastructure components similarly. Instead of having one dedicated tool for network security provisioning, another for the operating system configuration, and yet another for application set-up security, developers benefit from component technologies that define code and deploy in a single, streamlined process that Checkmarx can quickly scan. However, with manual infrastructure, there were safeguards. With infrastructure-as-code, users can accidentally configure and build apps in an unsecured way. Infrastructure is now part of configuration files, which organizations can scan as a part of their overall codebase. AWS speeds up cloud provisioning with secure templates and building blocks like AWS CloudFormation, Terraform, and Lambda. For example, AWS CloudFormation gives organizations an easy way to model a collection of related AWS and third-party resources, provision them quickly and consistently, and manage them throughout their lifecycles by treating infrastructure as code. Likewise, AWS Lambda is a compute service that lets developers run code without provisioning or managing servers. Lambda runs code on a high-availability compute infrastructure, performing all the administration of the compute resources that enable developers to run code for virtually any type of application or backend service. However, with manual infrastructure, there were safeguards. Insecure configurations are harder to create interactively, as they generate warnings and security alerts from the AWS console. With infrastructure-as-code, users can accidentally configure and build apps in an insecure but valid way since organizations' infrastructure is now part of a set of configuration files. As long as the configuration is viable, it will be deployed, even if the results are less secure than intended.The Joint Security Agreement
It is important to note that with dispersed code comes dispersed security responsibilities. Organizations must now evaluate security in the code, infrastructure, third-party modules, and modules to which developers don't even have access. In this environment, security has become a joint responsibility and needs to be handled by developers, DevOps, and IT teams. With this co-ownership, it is easy for security to fall through the cracks —and one small mistake could give cybercriminals their next big opportunity. Again, this is where AWS and Checkmarx are very compelling together because, with its baked-in security, AWS secures the cloud itself, delivering all the secure templates and building blocks. In contrast, Checkmarx secures the cloud-native apps that organizations deploy.What is "Shift Center," and Why Should Security Teams Care?
When considering AppSec development approaches, there can be tension between the "shift left" movement and more traditional security tools that "shift right" to late-stage development or production. Shift-left often yields earlier results in the testing process, making remediation faster and less expensive, so it's typically the recommended approach. With a shift right stance, security testing and results arrive later in the SDLC, providing different security insights with the higher costs and more complex remediation. However, shift right also holds a lower percentage of false positives. The ideal approach is to embed automated security early and often throughout all stages of software development. This approach is a more integrated "shift center" process. Shift center produces relevant and accurate results so that developers don't suffer from security alert fatigue.Best Practices for Secure App Development on AWS
Finally, as more organizations continue to develop cloud-native applications to advance digital transformation efforts, here are four best practices to adopt:- Make testing intrinsic to the whole SDLC. Don't assume any portion of your codebase is intrinsically secure, whether proprietary or open source. Thoroughly evaluate every line of code from the onset of development to ensure that you address all vulnerabilities that will leave you exposed to risk. As you add new features and functionality to applications, ensure new code is as secure as all other software components.
- Test IaC. Just as you diligently test and secure applications, you must do the same with IaC by ensuring every component is secure. These components include third-party APIs, which are commonly used to build software but can introduce various vulnerabilities into the environment. Checkmarx KiCS can help you find security vulnerabilities, compliance issues, and infrastructure misconfigurations in your AWS Infrastructure-as-Code solutions.Learn more about how Checkmarx made KICS, our open source solution to keep infrastructure-a-code secure.
- Understand cloud-native AppSec requirements. Ultimately, wherever you write code, the challenges are the same. Yet, your attack surface is more significant in the cloud as cloud-native development introduces new locations, new outputs, and new types of code. Therefore, organizations need an AppSec toolkit that helps customers prepare a secure hand-off of code to deployment.
- Be ready to build in the cloud. Just as most organizations are shifting to AWS for their application runtime and services, many also choose to take advantage of AWS developer tools like AWS CodeBuild and CodePipeline to provide software build test and deployment services. Indeed, the appeal of limitless scale and pay-as-you-go is just as attractive for a software build function as for the resulting application, if not more so. Be sure your security tools are ready for this shift, too, and can deliver the code analysis you need, no matter where you code.
