Progressive organizations are betting that continuous testing — as a part of DevSecOps — is the answer to proactively mitigate against new threats. Continuous testing enables security teams to keep pace with development and IT operations teams, and to deliver deep integration and automation of security tooling. These requirements have led to increased interest in emerging techniques that prioritize automation, accuracy, and simplicity.
The first problem is that the traditional way of team software development, the Waterfall approach, is linear, and that’s not the way the world works today. Speed and scale always include complexity, and complexity can’t be supported with linear processes. There needs to be a feedback loop, and with waterfall, there’s little ability to iterate the software once it’s begun the development process.
Second, how do you operate the software? How you build the software affects how it operates in the real world. So, there needs to be continuous feedback between the developer and the operator. This is how you get DevOps, which is literally a combination of Development and IT Operations.
Third, how are you going to maintain the software? It can’t just exist, there needs to be a feedback loop to the beginning, to the planning phase, which includes security. This is how you get to Agile methodology, which is continuous and iterative, and DevSecOps, which includes security.
DevOps is complementary with Agile. It is designed with the aim of shortening the systems development life cycle.
As mentioned, Agile is a more iterative development model than Waterfall. While there is also an end goal with Agile, the process is revisited and adjusted along the way. This allows developers to respond to design changes and security feedback as they are coding. And this process keeps repeating until it is done.
DevOps is complementary with Agile. It is designed with the aim of shortening the systems development life cycle. It is designed to provide continuous delivery of high software quality so that there is no interruption in service. Think of how many times online services like Facebook are updated in the background with minimal disruption to the user.
Faster, better software development is one thing. Providing security at scale is another.
DevSecOps, then, is the expansion of DevOps that includes security professionals as well. The idea is for everyone to be looking at the code together, rather than in silos. This will produce the most robust and resilient software with the least amount of time and cost.
DevSecOps is not new. It actually started in 1976 with a paper at an IEEE conference at a time when waterfall was the current software development method and agile was not yet widely used. Forty years ago, the world was less dependent on software. Today, the demand for agile, up-to-date software through continuous integration has caused the industry to take a second look at DevSecOps.
How can you make it so security is seen as a value and not as a cost? There’s already an example. Cryptography is a necessary foundation for successful e-commerce. Without it, users wouldn’t feel safe putting their banking and credit card information on the internet. So organizations put SSL and TLS in their applications, their services, and their browsers. It has created an online economy the size of the GDP of Spain. It has given rise to successful organizations such as Amazon.
Instead, organizations, in order to stay ahead, be innovative, yet they should also think like an attacker. They need to know the offense in order to implement defense. This is where fuzz testing plays a vital role in DevSecOps.
Fuzz testing, or fuzzing, is a dynamic application security testing (DAST) technique for negative testing. Fuzzing aims to detect known, unknown, and zero-day vulnerabilities. Fuzzers send malformed inputs to targets. Their objective is to trigger bad behaviors, such as crashes, infinite loops, and/or memory leaks. These anomalous behaviors are often a sign of an underlying vulnerability.
Fuzzing helps organizations verify that the application works as expected, even in unexpected situations. This is key as ecosystems get complex. It’s not just about people mistreating applications, it’s also about how an application will react if an integrated app misbehaves. In other words, if a system connected to your app acts up, can the app still function? Or will it crash? And if it crashes, does that allow for malicious code to run instead?
At a high level, fuzzing provides predictability. If testing is done continuously during the development cycle, this decreases time to market and should reduce the costs associated with the application over its lifetime. There will be a lower number of in-field issues when properly tested first.