Treat technology as the enabler, not a dictator of process
Published on January 16, 2024
Technology is like that shiny new toy you got for Christmas that everyone in the neighborhood wanted to play with. All too often, this posture can lead you down the wrong path by investing in a technology just because it's the greatest thing you saw or heard about at a conference without considering your business' best interests. The famous Norwegian historian, teacher, and political scientist Christian Lous Lange once said, "Technology is a useful servant, but a dangerous master." This is never truer than in DevSecOps. It’s important that you understand the "why" of a project, so that you can position yourself to objectively select the right tools and technologies to advance your DevSecOps journey and enable your people to successfully execute a proper DevSecOps process. That said, let me provide you with some considerations when investing in technologies for your DevSecOps journey.
When integrating security with the speed and scale of Agile and DevOps, investment in automation tools is imperative. While moving to automation requires a considerable policy, architectural, and cultural shift, it ensures that you adhere to DevSecOps best practices and confirm that your tools and processes are conducted in a consistent, repeatable, and reliable way. However, it is important to carefully investigate and consider which activities and processes can be completely automated and those that require some level of human intervention. For example, while you can fully automate static application security testing (SAST) tools into your continuous integration/continuous delivery (CI/CD) pipeline to identify source code vulnerabilities early in the development process. Nevertheless, other activities and processes such as penetration testing may require some manual effort to achieve the most value and benefit.
Integrating several automated layers of security scanning into your CI/CD pipeline is crucial for ensuring the wellbeing and quality of applications. First, you should automatically scan your source code repository at the code or application level using static application security testing (SAST) tools to identify vulnerabilities such as Structured Query Language (SQL) injections, cross-site scripting (XSS) vulnerabilities, buffer overflows, and integer overflows early in the development process. This form of "white box" testing is used to analyze plaintext source code and compare the results to a predetermined set of policies to determine if there are any matches for known security issues. By building SAST into your CI/CD process, you can potentially reduce costs by nearly 10 times in testing and approximately 100 times in production.
Second, integrate dynamic application security testing (DAST) tools to scan staging and production environments in an executing state. This form of automatic testing simulates malicious attacks and other external behaviors by searching for ways to exploit security vulnerabilities like SQL injection (SQLi), XSS attacks, and distributed denial of service (DDoS) attacks in your applications during runtime. Because DAST tests at the "black box" level and does not rely on source code, it can test any of your applications and find problems missed by other tests–such as authentication or server configuration issues—and ensure compliance and streamline regulatory reporting.
Lastly, as threat vectors and micro-perimeters expand with the advent of increasing container deployments, scanning containers to keep them running free from the ever-evolving catalogue of critical and high common vulnerabilities and exposures (CVEs) becomes vital. Scanning containers for vulnerabilities typically involves a security tool that analyzes a container image layer by layer to detect potential security issues. Most scanning solutions leverage a database of known CVEs so you can stay up to date as the security threat landscape evolves. You should also perform malware scanning on containers using static or dynamic analysis to detect malicious code or activity. These scans of a container image's contents identify known indicators of compromise, such as common malware signatures. While container scanning detects malicious code or activity already present in a container image, it cannot prevent malware injection into a container. Therefore, it is critical that you also employ security measures such as intrusion detection, prevention systems, and application firewalls to protect all your containerized applications.
The ability to recognize what patches have been deployed in your non-production and production environments is imperative; however, tracking these changes manually is difficult and prone to error. By implementing patch management at the CI/CD level, you can exploit its reliance on automation to quickly apply patches; this not only makes patch tracking and recording more efficient and reliable, but also allows you to become more aware of when and how they have affected these environments. This also enables you to determine risk exposure in near-real-time to rapidly fix security issues and decrease the scale of attacks while limiting the impact of downtime.
It imperative that you understand your security requirements early and continuously verify your coding standards against new security specifications. Security as code will help you define your cybersecurity policies and standards programmatically, so that they can routinely referenced in configuration scripts and compare security policies to prevent drift. This requires embedding regular security testing and vulnerability scanning early in your development cycle. This will allow you to reduce costs by responding more rapidly to changes and security needs and identifying vulnerabilities in the code and fixing them earlier in the development cycle. Furthermore, since complexity has increased the attack surface of modern applications, it's important that you employ rigid access control and policy management to set boundaries within the logic and flow of applications, limiting what a particular user can do.
In our three-part Agile series, we explored the ingredients of any organization's successful DevSecOps journey: people, process, and technology. All of these play an important role in ensuring your DevSecOps implementation succeeds in the following ways.