Simon Roe, product manager at Outpost24, outlines key steps to get integration into the DevOps toolchain right
Today organisations add new applications into their networks at a rapid pace, where speed is key. DevOps teams are expected to deliver the goods to ever diminishing deadlines to meet market demand and keep prices down.
YOU MAY ALSO LIKE:
However, this speed unfortunately means that many applications are added to the network, with known security vulnerabilities or that haven’t been properly tested for bugs. Applications that move through the delivery chain with security issues in place risk becoming an overriding technical debt that must be paid, with interest added at every stage of the process, when that code goes into production.
As a result, experts are recommending organisations deploy a ‘shift left’ approach to security.
Shifting left essentially puts the thinking about security all the way to the start of the development process, so that applications that are brought into the enterprise are much more secure. It means that two traditionally siloed teams – DevOps and SecOps collaborate to build secure applications, starting at the very beginning of the development process.
A shift left mantra resonates with anyone who takes security seriously for a number of very good reasons, not least because by including developers in the security responsibility loop as early in the development process as possible it removes the overheads of traditional siloed thinking. This is proactive thinking in action, rather than an inefficient and costly reactive approach to security where code is created by the developers, then added into the network and security is deployed on at the very last stage.
One of the biggest challenges that many organisations believe they will face when moving to a shift left approach is developer buy-in.
However, this actually isn’t the case. No developer wants to build and release insecure applications and many will agree that if there is a better way to approach things so that security risks are reduced, it should definitely be considered. Especially if this can be done in a way that developers are left feeling empowered and responsible for testing, rather than being burdened with yet another task to shoehorn into an already tight schedule.
However, organisations must remember that developers aren’t security people, so security testing needs to be adapted to fit seamlessly into the continuous integration/continuous delivery toolchain, not the other way around.
Shifting left is all about embedding the security testing team into the development team and by so doing empowering developers to be testers and testers to be developers. Doing so successfully creates a culture of prevention rather than one of detection, and in turn makes the whole lifecycle more secure, more efficient and cheaper as there should be far fewer late-stage revisions required.
Automating and integrating security into the development cycle
What are we looking for when we talk about integration into the DevOps toolchain? Here are some key considerations to get it right:
1. Deployment options: Often, onsite DAST (dynamic application security testing) scanners focus on single application at a time, and doing so in a methodological way that can also lead to slow scanning times. SaaS on the other hand, whilst it can be limited to internet facing application testing – can produce quicker scanning of multiple applications.
2. Time to scan: If our sprints are weekly, do we have the time to wait even a whole business day before we see results being fed back? Application security testing tools need to be equally agile – able to scan quickly and still produce meaningful findings.
3. Quality over quantity: An oft raised criticism of application security scanners is the sheer volume of items found. This can drive a zero vulnerability before release mentality leading to significant slowdowns. The testing tool should provide comprehensive, actionable findings that allow developers to fix known vulnerabilities without being flooded by these subjective hardening findings that could be argued as false positives.
4. Open API + automation = faster innovation: Irrespective of deployment, having an open API provides a means for organisations to start a manual integration into the DevOps tool chain. Pulling data out of the scanner and into familiar tools like Jenkins, Bamboo and Jira gives developers more control without the need to learn new tools. Finally, by automating security testing in the CI/CD pipelines, it can help increase workflow efficiencies and reduce time to market by decreasing friction between DevOps and SecOps.
It is also important to remember when an organisation decide to shift its DevSecOps to the left, it is not some kind of silver bullet, a panacea for all the application security risk that exists out there. What it can do, however, is to promote collaboration across teams throughout the process, breaking down siloed environment and ensure everybody feels responsible for the security of the application.