Changing Security Tool Requirements in the New DevSecOps World

Changing Security Tool Requirements in the New DevSecOps World

Security has "shifted left," moving from the final stages of the software development life cycle (SDLC) to a tightly integrated process that's baked in from the beginning. In the old days, security took a backseat to other application development tasks. Scanning tools such as SAST (static analysis security testing) and DAST (dynamic analysis security testing) took a long time and typically ran separately from the continuous integration and continuous delivery (CI/CD) pipelines. Security threats were discovered late in the process, and the main way of fixing them was to apply patches. Automation, integrations, APIs, and other modern security tool capabilities weren't part of the equation.

Then DevSecOps emerged.

DevSecOps integrates security into all stages of the SDLC, making security everyone's responsibility along the entire pipeline. Automation is crucial so that security can keep up with the pace of code development, especially in organizations where developers push multiple times per day. By finding threats and bugs earlier, DevSecOps reduces their cost and development impact. In the world of DevSecOps, security tools are integrated with multiple systems, such as Slack and Jira, helping track and communicate flaws as they are discovered and fixed.

Here are just a few of the big changes that have come to the tools.

The Customer

In the past, security tools catered to the IT Security team, which was solely responsible for identifying security bugs. Security would then work directly with Engineering on fixes.

Today, the developers themselves are the users. The Security team provides administrative support, but the security tools must be easy and transparent enough to integrate with Engineering processes. If it's too difficult or time-consuming to run a scan, there's a good chance some of your developers won't take the trouble. It's important for security tools to provide results without pushing engineers out of their tools and workflow.

Speed

It used to be no big deal for scans to take hours. A series of DAST scans could even take days. That kind of delay is no longer practical.

Modern SAST tools must work as part of an engineer's normal workflow, scanning code as it's written and providing immediate feedback. A scan that takes longer than a minute or two would be disruptive, and in the aggregate—ten minutes here, ten minutes there—can add up to a huge productivity loss. As DevSecOps becomes more firmly cemented in the CI/CD pipeline, speed will become more and more important.

Integrations

In the old days, it was acceptable for tools to live in silos. Other than single sign-on, every tool was independent and separate.

Tools integration is no longer a luxury. Making security a priority at every phase of development requires watching for incidents, changes, and new vulnerabilities in real time. Security tools that integrate with communications platforms such as Slack and PagerDuty help engineers conduct urgent conversations about issues as they are discovered. Jira integration makes it easier to track fixes and changes. Github and other SCM integrations help automate finding vulnerabilities in your code as well as in libraries and other dependencies.

Accuracy

Before DevSecOps, the Security team would run their tools at the end of the development process and triage the results before working with Engineering on fixes. This meant that Engineering didn't have to deal with many results that weren't useful.

Now that engineers are direct customers of security scanning tools, it's important for the results to be accurate. False positives generate noise that make it more difficult to focus on real problems. If a scanning tool is leaving useless comments on pull requests or showing spurious results in the build system, it can cause fatigue in the Engineering team: they'll simply stop responding to the notifications. It's critical for the tools to report vulnerabilities with over 90% accuracy, even if it means leaving a few undetected. Once your team has identified a false positive, the tool must provide a way to flag it so that it doesn't get reported again.

Delivery of Results

The Security team used to be responsible for filtering, processing, and delivering security scan results to the engineers.

Today, Engineering expects the tools themselves to file tickets. At the very least, engineers want to be able to see results and make necessary changes through the UI. The principles of DevSecOps include transparency and a hands-on approach so that engineers catch vulnerabilities early, rather than finding problems at the last minute. It's important for modern security tools to provide results as close as possible to the engineering workflow so that developers can take action with as little wasted effort as possible.

Extensibility

In the old days, a tool was a tool. The idea that every tool would have an API and provide webhooks would have seemed excessive, at the very least.

These days, it is hard to imagine using a security product that doesn't provide these capabilities. One of the most important characteristics of DevSecOps is automation, which is necessary to keep up with the pace of code delivery. Modern security tools must provide extensibility and the ability to automate tasks through comprehensive APIs and notification frameworks.

Conclusion

As security has shifted from a specialty to a shared responsibility, traditional security tools are being replaced with more capable solutions. Scanning and analysis tools are faster and more tightly integrated with the developer process, catering to their new customer: the busy engineer. As workflows and pipelines become more sophisticated, security tools are becoming integrated and extensible. Fast, accurate results are delivered automatically exactly when and where they're needed: that is, starting as early in the development process as possible.

Yash is a Senior Security Manager at Twilio, previously at Box. He has worked in security for over half a decade in a variety of roles – everything from consulting to enterprise product security teams. He takes pleasure in containerizing and automating all things, sharing knowledge at conferences, and hiking. Yash can be reached at ykosaraju [at] twilio.com.