Cloud Transformation
Modern AppSec for Modern Apps
There's a broad IT industry trend towards the cloud, with organizations being in various stages. The modern software stack includes cloud-native elements of the architecture.
CNFC defines cloud-natives as: "Technologies [that] empower organizations to build and run scalable applications in modern, dynamic environments such as public, private and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach"
AWS, Azure, and GCP dominate the market. Each offers similar functionality and SDKs for interacting with the cloud infrastructure components, along with a further level of abstraction with serverless functions. While cloud computing offloads many tasks to the cloud provider, the end user organization retains responsibility for securing the data that goes into the cloud. This affects AppSec in many ways. One of these is that there are specific AppSec requirements for apps running in the cloud.
What these are depends on how the application is architected. When putting an application in the cloud, the simplest approach would be to “lift-and-shift,” running on cloud infra. Few things change.
Another approach is to go “cloud-native,” leveraging cloud technology to the maximum extent possible. Then, many things change. This is a continuum, rather than a binary choice. Bigger organizations will have large application portfolios that are spread across this continuum.
In the cloud-native case, we have identified the following specific aspects of AppSec:
Use of Cloud SDKs Example: instead of using standard Java JDBC to connect to MySQL, you might use the AWS Java SDK to connect to S3. This has its own good and bad practices and risks. This is a huge area, given {cloud providers } x { services } x { SDK languages }. It’s challenging for AppSec tools, in particular SAST, to keep up with that.
Infrastructure as Code
- Not truly “AppSec.” Our point of view is that for static analysis, AppSec naturally extends to IaC because it’s also code analysis and is often in the same repos. There is also an aspect of dynamic testing: What is the actual configuration in the cloud (configuration drift/production monitoring)? This seems further away from AppSec.
- This space is still rapidly developing. There are cloud-vendor specific solutions (CloudFormation, ARM Templates), abstraction layers over the configuration (Ansible, Terraform), and abstraction through a container management layer (Kubernetes).
1
Cloud Secrets
- Cloud and IaC trend create the additional risk of storing hard-coded secrets. The impact of disclosure of a cloud secret can be huge.
- Opportunity: Many cloud/API secrets tend to have fixed formats and can be found using relatively simple analysis to find regexes. Multiple vendors have jumped into this space.
2
Cloud CI/CD
- Hosted DevOps systems (ADO, GitLab, GitHub, AWS CodeStar, etc.).
- Have their own (supply chain) risks, in particular injection in workflows.
3
Containers
Various approaches to assess security:
- Checking the creation process files (Dockerfile), close to AppSec.
- Image scanning, further away from AppSec.
4
Serverless/Function-as-a-Service
Cloud-specific deployment model where you simply deploy code without bothering about the appserver/container/VM (that’s all handled by the cloud provider). Not automatically recognized by any AppSec tool.
Looking at the consequences of these new aspects of AppSec:
- All of them place new demands on AppSec Tools
- Demarcation between AppSec and InfraSec is becoming blurry
- Many nice vendors are popping up that do one thing really well
- At the same time, organizations are concerned about tool sprawl and prefer consolidated solutions