DevOps was pioneered by companies that, born in the digital age, have fewer regulatory requirements or crown jewels to protect than does the typical enterprise. As a result, the early days of DevOps relegated security testing to a post-release step that was often independent of the deployment pipeline.
As more established enterprises have adopted DevOps practices, though, the lack of security testing early in the development cycle has resulted in a bottleneck for deployment and higher development costs. Changing code after the fact to ensure compliance, or to eliminate a vulnerability after the software is scheduled to deploy, is painful for everyone.
This results in missed deadlines and affects future releases, while developers are sidelined from working on the next release because they're fixing problems in the current release.
The alternative is to simply drive through the security roadblock and deploy with known vulnerabilities or a policy violation, with a promise to patch or update in the next release. But this approach is becoming less common as the impact of security breaches due to application vulnerabilities has increased, and regulatory penalties have grown.
If we can't slow down deployments or release code with known vulnerabilities, then we need a third approach. Rather than look at security as a roadblock, it's time to invite the security practitioners to the party—as partners in accelerating business innovation—by implementing security testing at three key points in the software development lifecycle. Here's how to get started.
1. Start at the integrated development environment
Simply put, the earlier that the security defect is detected, the cheaper it is to fix. While there is value in training developers on secure ways to code, the speed of modern development—and human nature in general—mean that programming defects are almost always going to emerge.
One very important way to handle this is to give automated feedback to the developer via a plugin to the IDE that supports the languages that developers prefer. In fact, this is critical in a DevOps environment.
This capability is variably referred to as static code analysis, static program analysis, or static application security testing (SAST). "Static" refers to how the code is analyzed without executing the application.
Security cannot expect to dictate what tools developers use, whether that is a specific IDE, build tools, code repositories, bug tracking, or ticketing systems. And what is used today may not be preferred tomorrow.
But developers can work with tools that have an extensible API, so this should be a hard requirement for any security test tool you are considering. Additional considerations include a tool that is continuously updated with the latest vulnerability data, shows clear evidence of the defect with specific recommendations on how to fix it, and provides feedback in hours, not days.
The goals here are to make it as easy as possible for the developer so that there are minimal delays (constraints) on throughput, and for developers to be more supportive of security testing.
2. Verify in preproduction
While catching security defects early is ideal, configuration issues can expose vulnerabilities as well. So code needs to be tested in its running state, ideally in a preproduction or test environment before being moved into production.
This capability is commonly referred to as dynamic application security testing (DAST). It uses similar techniques to attack an application that a hacker would use, looking for cross-site scripting or SQL injection vulnerabilities, for example.
Again, the considerations of a DevOps environment must drive the requirements when choosing a DAST tool. Scans must be fast, and results must be provided in a format that integrates with other development tools to make it easy for developers to understand where to make changes.
Retests should be customizable to an entire website, just the vulnerabilities, or only a single vulnerability. They also require comparisons to perform a delta analysis so that a developer can easily confirm that a change has been effective in eliminating the vulnerability.
3. Protect web applications in production
While much of the emphasis in application security testing is on SAST and DAST, there is a third category that is often overlooked. Because of the pace of change and the evolving threat environment, there is risk that production code may remain vulnerable. There is also the lag time needed to make changes to production applications after vulnerabilities are detected, which demands compensating controls in the interim.
The capability needed to defend production applications is runtime application self-protection (RASP). This approach can detect attacks such as cross-site scripting or SQL injection in real time and take a prescribed action to stop the attack. It also can detect and block scanners looking for vulnerabilities, to slow and deter attackers.
RASP tools protect without having to rewrite code. Look for these features: the ability to instantly see exploits of production applications, continuous monitoring and protection abilities, and detailed, prioritized reports for developers to provide remediation and feedback about code improvement.
United is better
These three techniques existed before DevOps, but a key advantage of DevOps is how it pulls together what was once separate operations and development teams to deliver better code to the business, and to do so faster than before.
Inviting security to the party in 2019 means embedding these capabilities into the development pipeline, tool chain, and operational processes, rather than viewing security as an afterthought or as someone else's responsibility. This will help your organization avoid deployment delays, the cost of code changes, and the risk of a business-impacting security breach or regulatory fines.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
