Introduction
As the pace of software development increases, there’s a real need for organizations and their security teams to ensure application security is embedded in all phases of the development and deployment life cycle, as well as in the cloud during operations.
The software development life cycle (SDLC) has moved to an agile methodology that prioritizes collaboration and frequent, small updates to application stacks. Organizations should define and publish standards for code quality and security, as well as application workload configuration, so that all teams have something to measure throughout the entire application life cycle. Ideally, cloud workloads should be as locked down as possible,
running a minimum of services, and configuration requirements should be revisited to help ensure resiliency of any cloud-based infrastructure.
In the spirit of increased collaboration, security teams should integrate with the developers who are promoting code to cloud-based applications. Security teams should impress upon development and operations that the series of tests and quality conditions they can apply to production code pushes will not slow down the development process. Security teams should work with quality assurance (QA) and development to define parameters and key qualifiers that must be met before any code can be promoted.
In addition, security teams will need to determine which operations tools can be integrated into the application pipeline and identify areas and controls that might need to be updated or adapted to work in a continuous integration and/or continuous deployment model. Protection for application workloads requires a dedicated commitment to security at many levels of any organization. A sound governance model that includes collaborative discussions about code quality, system builds, architecture and network controls, identity
and access management (IAM), and data security are all critically important to developing the standards for controls and security posture.
In this paper, we will describe how to build a successful security automation strategy, beginning with a discussion on visibility into application development into cloud production environments. Next, we dive into what it takes for security teams to gain continuous visibility throughout all phases of the DevOps pipeline. We also explain application visibility in runtime and conclude with a discussion of automation in DevSecOps.
Visibility into Application Development
Application visibility relies on tracking events and behaviors at scale as workloads communicate within the cloud environment as a whole, as well as tracking the local application logs on individual systems and containers. True application visibility often requires feeding events into event management and SIEM platforms, and such systems
have been well adapted for cloud environments, often via API integration. When using such platforms in the cloud, security teams need to enable logging and monitoring of code and system/container image repositories to help ensure that all access is tracked. Enabling AWS CloudTrail1 logs within Amazon Web Services (AWS) will enable analysts to collect and monitor all access to images and code, as well as changes or other interesting
events related to repositories.
Scanning code for vulnerabilities is another important task that should be wholly integrated into the DevOps pipeline. When code is checked into a repository, automated scans should be triggered that send development and security teams a report on vulnerabilities detected. Organizations should define application code security standards that outline the level of severity of vulnerabilities that is acceptable for continued build
and deployment, with the level dependent on the criticality of the applications and data involved (as well as application exposure). An example of a cloud-native code review and assessment service is Amazon CodeGuru. Amazon CodeGuru Reviewer Security Detectors can improve code security and resilience by identifying security vulnerabilities in the OWASP Top 102 and recommending best practices to remediate critical issues and bugs
during application development. During test and operations phases, Amazon CodeGuru Profiler monitors the runtime behavior of applications to detect anomalies as well as patterns of anomalous behavior. These capabilities provide significant visibility into both code development and application testing and operations.
Visibility into the DevOps Pipeline
Security teams should consider a number of different security controls and areas of emphasis to gain visibility into all phases of the DevOps pipeline. When integrating into a cloud-focused application development model, security teams should focus on the following:
• Code security—Ensure code is being scanned for vulnerabilities and monitor all code updates and changes, including details such who checked code in or out, and when.
• Build and packaging tools—Integrate monitoring for tools used to automate builds and packaging. These phases are optimal times to look for configuration errors and potential vulnerabilities in images planned for deployment.
• Orchestration platforms—For deployment and runtime maintenance, monitor and
carefully secure orchestration tools such as Kubernetes.
The key security focal areas for all phases of a DevSecOps pipeline are described in the
following sections.
Code/Development
Ideally, your organization follows secure coding practices. Security and development teams should:
• Discuss standards for languages and frameworks to make sure risk is acceptable
before deployment. This can be a tall order, because secure coding and development practices are still not commonplace.
• Evaluate static code analysis tools that can automatically scan code that is
checked in. Many leading solution providers offer highly automated scanning tools in AWS Marketplace. You can also take advantage of native tools such as Amazon CodeGuru.
• Ensure the code is secured within repositories. Define check-in and check-out procedures and define and enforce role-based least privilege access controls.
Cloud providers often have options for code storage and management that include authentication with strong identity management and robust logging/tracking of activity. AWS CodeCommit is a fully managed source control service that hosts secure Git-based repositories and encrypts all files in transit and at rest, integrates with AWS Identity and Access Management (IAM) for controlling privileges and access to code stores, and logs all activity in AWS CloudTrail. Additionally, AWS CodeCommit has a wide range of APIs that can enable automation and integration with third-party static code analysis tools for code analysis and review by security teams. Code can be automatically scanned upon check-in, and bug/vulnerability reports can be sent automatically to the appropriate teams.
Build and Packaging
Code and workload stacks for cloud applications should incorporate automated and intelligent security controls, including:
• Validated code
• An approved build architecture and controls
• Automated build testing for compiled code
Besides the aforementioned automation and security controls and processes, automated reporting that goes to the proper parties for review will ultimately contribute to a more effective vulnerability management program across the environment. Much as with the previous phase of development (coding), the build phase can often be securely implemented within cloud provider environments. AWS CodeBuild is a fully managed, continuous integration service that compiles source code, runs tests, and produces software packages that are ready to deploy. Managing encryption of build artifacts is critical, and AWS CodeBuild integrates with AWS Key Management Service (KMS). AWS CodeBuild also integrates with AWS IAM for control over privileges to builds and compiled code, and logs all activity in AWS CloudTrail.
Packaging is the phase of application development where the build is updated with additional software packages, whether open source or from in-house repositories. It’s important for development and security teams to audit open-source modules for flaws and to discuss methods to protect code repositories automatically. Specialized package vulnerability scanning services and tools can be easily integrated into build and packaging features to assess libraries, packages, and binaries in images for vulnerabilities and potential exposure. Native services, such as AWS Systems Manager, can also be used to manage package repositories and secure build images with up-to-date patches and libraries.
Testing
The testing phases of a deployment can usually be highly automated and carefully monitored. With regard to testing, the following are best practices:
• Use both static and dynamic tools depending on builds, and define security test cases ahead of time. This way, a spirit of collaboration and cooperation can aid teams in defining acceptable outcomes that meet policy.
• Automate all testing scenarios and tools, and teach developers/QA engineers to run them. Security teams should hand off tools to the application developers wherever possible and not insert themselves into testing processes. Ideally, security should only perform penetration tests and continuous monitoring activities regularly once policies and standards are defined.
Using build testing tools, such as Test Kitchen and Vagrant, can simplify internal policy validation, before they are pushed and in an ongoing fashion. Vulnerability scans, penetration tests, and routine checks can provide testing visibility and validate policies’ effectiveness by ensuring that only required network ports are open; that secrets such as credentials, encryption keys, and tokens are secured; and that privileges are assigned
properly in the application architecture.
All elements of a configuration standard or expected vulnerability posture should be continually validated and assessed using automated orchestration tools and platforms. Many third-party dynamic application scanning and pen testing service providers are fully integrated into the cloud. These tests can be run automatically upon build checkin or image update, or manually as needed, with fully automated reporting sent to the appropriate teams.