Synopsys sponsored this post.
Modern cloud native applications brought a major paradigm shift to application deployment. Centered around infrastructure-as-a-service (IaaS), cloud native applications introduced technologies such as serverless architecture, containers and infrastructure-as-code (IaC) to mainstream application development and the developer desktop.
A modern application stack includes four main elements interacting with each other: application code; open source libraries and frameworks; containers to pack everything together; and infrastructure to deploy the application. The infrastructure can be defined as code using modern IaC concepts and tools such as AWS CloudFormation, Terraform, etc. The open source libraries, frameworks, and other resources can be included in a container image. It’s also possible to containerize application code using Docker, for example, and to orchestrate the container pods using Kubernetes to launch the applications. Application development agility and deployment scalability further improve by decoupling various parts of applications into a microservices architecture and connecting them through API gateways. In addition to enabling you to scale individual components or services, this type of architecture also allows you to deploy applications rapidly and manage the entire application stack, including infrastructure configurations and version updates, in a CI/CD pipeline.
This improves developer productivity and provides much greater visibility into the infrastructure. However, it also increases the chances of introducing security issues into the application stack. One of the advantages of managing the entire application stack, including application and infrastructure code, via the DevOps process in a CI/CD pipeline is that you can embed automated security testing in the pipeline for the entire application stack. Embedding security testing into the DevOps process (DevSecOps) improves developer productivity by making it easier to find and fix security issues early in the software development life cycle (SDLC) without disrupting the workflow. It also ensures that security best practices are followed and enforced.
Security Best Practices for a Modern App Stack
There are a plethora of research studies (this one, for example) that suggest automated security testing solutions help ensure a successful DevSecOps process by identifying actionable security issues quickly and providing remediation guidance to fix them. These testing solutions help identify security issues not only in the application code but in the entire application stack, from known vulnerabilities in the open source code to security issues in containers and infrastructure configurations. Such practices may employ static application security testing (SAST), software composition analysis (SCA), IaC scanning capabilities and the like to help developers find and fix these security issues early in the life cycle.
Security Testing Early in the Life Cycle
The question is, where in the developer’s workflow is it best to identify security issues and get them fixed before they reach production?
The two best places to provide developers with early feedback are:
- In their IDE, as they are writing the code. Analysis and feedback need to be fast and provide actionable remediation advice.
- In the CI/CD pipeline, either by enforcing policies as a quality gate or providing continuous feedback. Code reviews are already happening when a developer submits a merge request. Providing additional feedback from automated security testing tools quickly will help the developer fix them right away.
There’s a catch, though. Traditional security testing solutions like static analysis tools that perform deep analysis may take a long time and are more suited for running deep scans later in the SDLC, such as on a nightly basis. These solutions may not be ideal for developers to find and fix issues early and quickly. Developers do not want, and will not accept, friction added into their development pipelines. Friction can be in the form of false positives or long scan times that don’t conform to time constraints typical of that phase of the software development pipeline. Thus, security scans at this stage need to be fast, and the results need to be actionable, so developers can efficiently fix any potential security issues.
Let’s look at a few examples of how the right tools could help developers find and fix security issues early in the software development life cycle.
Finding and Fixing Issues in the IDE
Figure 1 shows a very simple code snippet, written in an AWS CloudFormation template and in JSON format that creates an AWS workspace and sets the volume encryption of workspaces off. This is an obvious flaw that may lead to a security issue in the defined infrastructure configurations.
An easy fix would be to set the RootVolumeEncryptionEnabled and UserVolumeEncryptionEnabled variables to true. This might seem easy to take care of, but such mistakes are common and frequently happen either by accident or because of carelessness. In fact, sometimes these flaws are discovered only after they have been exploited and resulted in financial and public relations damage to the organization.
An IaC scanning tool that plugs into the IDE, as a linter does, would flag potential security issues as the code is written and provide remediation advice to change those variables to true.
Figure 2 shows how Rapid Scan SAST by Synopsys identifies this issue in the Code SightTM IDE plugin for Visual Studio Code IDE. This code example is from the open source and vulnerable-by-design KaiMonkey project, and Rapid Scan flags the publicly accessible database instance being deployed. The tool highlights the line number where the issue is found and provides an inline description and remediation advice to quickly fix such issues.
Similarly, a static analysis tool for application code would flag vulnerabilities and provide fix recommendations to help developers fix those issues before pushing their code into the development or main branch.
Early Feedback in the CI/CD Pipeline
Whatever CI system you’re using (Jenkins, GitHub, GitLab, etc.), providing immediate feedback for actionable defects during each commit helps developers fix the defects quickly. Figure 3 below shows the same defect displayed in Figure 2, but in a GitHub Security dashboard after Rapid Scan was run through a GitHub Action during the build. At this stage, you can provide feedback by finding the issues and also enforce policies by failing the build if a specific type, severity level or business-critical vulnerability is found.
Rapid Scan SAST can currently be used via the command-line interface or integrated into a CI pipeline, and it will be available for IDE use cases via the Code Sight IDE plugin later this month.
Find more information on Rapid Scan SAST here.
The New Stack is a wholly owned subsidiary of Insight Partners. TNS owner Insight Partners is an investor in the following companies: Docker.
Featured image via Pixabay.