How to cyber security: Minimize risk and testing time with Intelligent Orchestration
Integrating AST tools into your CI/CD pipeline shouldn’t compromise your development velocity. Learn how Intelligent Orchestration can help.
Sometimes it feels like software development is at the crux of the collision between an unstoppable force and an immovable object.
- Everyone wants software to be done faster, with more features.
- Everyone knows that security has to be part of every development phase.
Automation and integration
The answer to putting security in every phase of development is partly process and partly automating and integrating security testing into the build and test phases of development.
The first attempt at creating application security (let’s call it AST 1.0) was a too-little/too-late effort. Security teams ran tests when an application was almost finished. The development team looked for approval from the security team, and then got aggravated and confused when the security team produced findings and wasn’t able to explain them in terms developers would understand. The security team was run ragged trying to serve the testing needs of all application teams, and then got frustrated when application teams were slow to adopt recommendations, or ignored findings outright in meeting release schedules.
AST 2.0 is a more integrated, collaborative approach. Instead of waiting until the end of the development cycle to do security testing, application teams are now including security testing as part of the implement and test phases. This is called shifting left.
In theory, this works great. Every time your developers push code into the source repository, you can kick off security testing, such as static application security testing (SAST) and software composition analysis (SCA). Every time you run functional tests, you can include interactive application security testing (IAST), fuzzing, and dynamic application security testing (DAST).
Add common sense with Intelligent Orchestration
In practice, automated testing can be too much of a good thing.
If a developer changes the README file, you don’t want to rerun any of the security testing because nothing will have changed. If a developer changes a pom.xml or some other dependency list, you don’t need to run SAST again, although you will want updated results from SCA.
Furthermore, different kinds of applications have different purposes, rely on different kinds of data, and have different risks. They need to be tested differently.
It’s not enough to apply SAST and SCA to everything and call it a day. For example, IAST makes sense for web applications, APIs, and tracking information across microservices but not for client applications. What you really need is a comprehensive portfolio of tools, so you can apply an appropriate policy to each one, based on topology, technology, and usage.
In short, a little bit of common sense really benefits security testing automation. We packaged this common sense approach into a solution we call Intelligent Orchestration. Instead of a one-size-fits-none approach, Intelligent Orchestration runs the right tests, at the right time, on the right artifacts.
Integrated results for continuous improvement
One of the hallmarks of DevSecOps is the idea of continuous improvement, in which the development team gets timely feedback about their work. This enables them to fix problems quickly, but it also provides a way to scrutinize the process itself and make optimizations. Timely feedback about security issues, along with focused training material, helps developers build their knowledge and avoid making the same mistake more than once or twice, which in turn means they have more time to focus on features and functionality.
Security testing doesn’t do any good by itself; you have to do something with the results. In a streamlined DevSecOps approach, results are integrated to the issue tracker that developers are already using. This has several important consequences.
First, developers don’t have to adjust their workflow to “do security.” Security issues show up in the issue tracker in the same way as functionality bugs, enhancement requests, and other issues. This erases the common perception that “security is slowing us down.” When security is a first-class citizen in the issue tracker, it’s just part of the process, exactly as it should be.
Second, the issue tracker can be used to track progress on security issues. Metrics about the number of security issues addressed and in what time can be used to assess the risk posture of an application and help inform risk decisions. Alternatively, security metrics from the issue tracker can be used to provide assurance to customers about the risk posture of an application.
Finally, development teams can make smart choices about how security testing results are integrated with issue tracking, especially when getting started. An initial glut of security findings can seem overwhelming. Many teams adopt a “don’t make it worse” policy in which a baseline set of results is obtained when a tool is first adopted, and thereafter, any additional findings are put into the issue tracker and addressed as usual. Meanwhile, a separate plan for working through the baseline findings is initiated.
Policy as code with Intelligent Orchestration
One other area where Intelligent Orchestration really shines is policy. Policy describes the world you want to see: when to run specific security tools, what settings to use for the security tools, and what kinds of results are acceptable.
If you automate and integrate security tools one at a time into your development process, you won’t have an easy way to understand the overall policy for your application. Decisions about tool settings, test frequency, and results will be spread across a handful of tools and integration scripts.
Intelligent Orchestration gathers policy in one place and stores it as code, i.e., in a machine-readable format. This gives you a deterministic, unambiguous expression of policy that can be applied to your application. Adjustments to policy, and consequently the application’s risk profile, can be done in a way that’s transparent and trackable.
AST 2.0 is here
Intelligent Orchestration is a natural evolution of the automation and integration of security tools in the software development life cycle. Yes, security tools should be automated in the implementation and test phases of the development life cycle. Yes, the results of security testing should be integrated into the issue tracker and other systems that the development team is already using.
Intelligent Orchestration builds on this foundation by applying common sense about when tests need to be run and codifying application security policy. It runs the right tests at the right time to ensure that you get the application security posture you want.
Interested in learning more about Intelligent Orchestration?
