Over the past few years, DevSecOps has become a buzzword in application security. You may understand the concept — security is integrated into your continuous integration/continuous delivery pipeline to find and fix vulnerabilities earlier in the software development lifecycle — but how do you actually implement DevSecOps?
One of the keys to successful DevSecOps implementation is the adoption of automation and a tech stack that facilitates security testing throughout the CI/CD pipeline. Here are some of the types of application security tools you can utilize to improve your DevSecOps:
Runtime Application Self-Protection (RASP)
RASP tools run within the application itself to block exploitation of vulnerabilities as the application is running. Unlike protections such as WAFs or VPNs, RASP tools are designed to be used by the developers to provide insight into ways to improve their app to prevent further attacks. It serves as an additional line of defense in case issues sneak past the development and security teams during the rapid development cycle.
Software Composition Analysis (SCA)
Today’s applications are increasingly reliant on open-source code libraries. While this has facilitated rapid release, it also poses a considerable security risk. Open-source code is maintained by a third-party that may not be using the same standards of security you hold your developers to, if they maintain the library at all. Open source also introduces opportunity for outdated libraries with known vulnerabilities and no developed patch. Software Composition Analysis (SCA) tools are used to map dependencies in your code and identify known vulnerabilities. Utilizing these tools during development can help developers identify components that need to be updated or replaced before production or areas where additional controls may be necessary to offset risk. SCA tools can also assist in the creation of a software bill of materials (SBOM) which documents the dependencies and associated vulnerabilities in an application. As industry reliance on open-source code increases, having a software bill of materials has become critical. Maintaining an SBOM will help you more successfully leverage many of the other tool types on this list. When selecting an SCA tool, make sure that it supports the SBOM formats that you are using such as CycloneDX and SPDX.
Static Application Security Testing (SAST)
SAST tools are essential for the DevSecOps process as they can be used early in the development process to scan static code without requiring code to be run. Risk thresholds can be set so that a build will fail, or a component will not be approved to move forward, if there are too many unaddressed vulnerabilities. These tools can integrate with the interactive development environment (IDE) to provide real-time suggestions while you code and can take you directly to the offending code when a vulnerability is detected.
Dynamic Application Security Testing (DAST)
The disadvantage of SAST tools is that they may not catch vulnerabilities that are only evident at runtime, which is where DAST tools come in. DAST tools work from the perspective of the attacker, simulating common attack vectors. These tools can be automated and used in the testing environment to catch runtime issues before production.
Interactive Application Security Testing (IAST)
Interactive Application Security Testing (IAST) tests your application for vulnerabilities while in use, either by an automated or human tester. It essentially combines SAST and DAST to give the benefit of access to all of the code, with the additional context of runtime information, to reduce the number of false positives. It can identify a vulnerability while the code is being executed and locate the place in the code where that vulnerability is located. IAST does, however, require building test suites and may slow down your CI/CD pipeline.
Container Security Tools
Containers, units of software with all of the code and dependencies needed to run the application, regardless of computing environment, have allowed companies the workload portability necessary for rapid development across hybrid environments, but because container images are frequently pulled from public repositories, they pose a security risk if not adequately tested. A study by Prevasio found that 51% of the 4 million Docker Hub images analyzed had exploitable vulnerabilities. Therefore, it is best practice to incorporate image scanning into every stage of the CI/CD pipeline, ideally starting as early in the development cycle as possible. You can then use admission controllers to ensure that container images with known fixable vulnerabilities above a certain severity will not be pushed to the production-accessible container registry until they are scanned, and a security validation decision is made. You can also use a policy engine in combination with the admission controller to make the decision in the cluster, as opposed to in the image scanner, so that cluster information can also be used, increasing the context on which to make the decision.
Infrastructure Automation Tools
DevSecOps only works if it is efficient and consistent, which requires automation. You want tools that will be able to automate tasks such as infrastructure as code deployments and remediation of detected vulnerabilities, as well as configuration issues. Tools such as Cloud Workload Protection Platforms would fall into this category. Infrastructure as code can also be extended to policy as code where automated tools apply your policies to ensure compliance.
Threat Modeling Tools
Threat modeling is the process of sitting down to review the architecture and design of an application and defining the ways in which a likely attacker would attempt to exploit vulnerabilities to compromise that design. This is traditionally a manual process as it involves brainstorming and meetings with various stakeholders. You don’t want to remove that human element, but there are some ways to make it more efficient and better suited for DevSecOps. One of those is simply shifting threat modeling all the way left, so those meetings take place before code is written. This way, code is not being rewritten to accommodate threat models but is instead built from the beginning with that threat model in mind. There are also tools that can help automate parts of the threat modeling process. For example, tools can help create data flow diagrams or automate the generation of the list of threats that are out there based on information about the systems.
Logging, Monitoring & Alerting Tools
Even if you deploy security checks throughout the development process, what was safe when approved may later become a source of risk as new vulnerabilities are discovered and configurations are changed. Monitoring and logging tools can be integrated into your pipeline to help you identify and fix errors as they occur. These tools will keep a centralized log record so you can determine baseline application behavior and identify anomalies.
Not sure which tools you need? RH-ISAC members have access to a community of cybersecurity professionals who can provide advice through posts on the Member Exchange discussion forum. You can also benefit from benchmarking surveys, such as the recent Tools & Technologies Report, which provides an overview of the popular types of tools members are using. Not an RH-ISAC member? Learn more about how being a part of the RH-ISAC’s member community can benefit you.
