DevSecOps Tools – 4 Key Controls and How to Implement Them

These days many development teams have moved to DevOps or are moving in that direction. But how do you implement traditional security controls in this new DevSecOps world?

A Note on Terminology:

• What is DevOps? DevOps refers to the integration of software Development and IT Operations.  
• What is DevSecOps? DevSecOps adds “security” into the phrase in order to drive home the idea that everyone, from development through operations, has a responsibility to uphold information security standards.)  

The reality is security can no longer be outsourced to a separate security team. Instead, the development or DevOps team—or even the entire business—should have access to the necessary tools to be self-sufficient in terms of implementing and verifying security.
Security can really become successful when it’s baked into a DevSecOps process. In this blog post, I’ll walk through four of the key application security controls and explain how traditional usages and approaches can be adapted for DevSecOps environments.

1. Static Analysis

Let’s start with static analysis, by which I mean automated and/or manual security code review. Traditionally, this was a heavyweight process that was conducted top-down and was performed every month or maybe weekly at most.
If you’re using automated analysis tools, these tend to deliver a large volume of output and a large number of false positives. This was OK in the traditional waterfall model because you had plenty of time (often 12 to 18 months) between release cycles to remove the false positives, go through the entire report and mitigate issues.
This approach obviously isn’t feasible in DevSecOps environments because release cycles are increasingly more frequent. But with a few new twists you can make static analysis at least as effective as before.

Implement a Bottom-Up Approach

The first twist is to move from a top-down to a bottom-up approach. That is, instead of running a scan against all classes of vulnerabilities (XSS, SQL injection, etc.) all at once, you identify one or a few specific classes of vulnerabilities that you care about the most—and just start with those. Once the results come back you can remove the false positives, complete the triaging and then next time add another class of vulnerabilities, and so on until you’re doing a full scan.
This approach supports the velocity needed for DevSecOps and makes it possible to run static code analysis on every code commit. It also demonstrates to the development team this approach can be helpful and effective in DevSecOps.

Improve Your Alerts

Another way to support code review in DevSecOps is to build proactive alerting into your process, so you know when a sensitive or rarely changed part of the code base (e.g., the role-based access control module, your custom encryption wrappers or maybe some code that dates back to the start of the project) has been modified.
This is a more DevSecOps-friendly alternative to blocking such changes pending signoff from different teams, as is typical in a waterfall model. With more frequent releases, you can’t wait for multiple signoffs before fixing the code in response to a customer complaint or a crash bug report. Properly configured alerts to your CTO, CISO, program manager and/or development manager can ensure the code base remains secure without bogging things down.

2. Dynamic Scanning

Traditionally, dynamic scanning has been used to make a baseline standard for discovering anomalies. Maybe you’d run a dynamic scan about once a year in the form of a penetration test. You’d almost certainly find vulnerabilities you needed to fix because you were testing so infrequently.
This was less of an issue with long release cycles. But it’s not adequate in DevSecOps environments where changes happen rapidly to continuously. Moreover, in the past few years application architectures and functionality have changed significantly: client-side functionality has expanded, there are single-page apps, and so on. Automated scanners can’t provide full coverage of application vulnerabilities when some of these new models are involved.
There are two key steps to adapting dynamic scanning scenarios to DevSecOps.

Implement and Enforce Security Policies

The first step is to ensure you have—and enforce—security policies your application must adhere to; e.g., TLS must be supported throughout the application, x-frame options are set to Deny for your application server, and so on. Then you can direct the scanner to pinpoint anywhere you are out of compliance with policy. You can make it part of your continuous integration process flow to continuously crawl for such findings.

Keep Found Vulnerabilities Out for Good 

Secondly, you need to ensure previously found vulnerabilities aren’t accidentally regressed back into the application. Say you previously found an XSS or injection vulnerability on a particular page or parameter. You can configure your scanner to test that parameter periodically. Besides identifying the vulnerability, this approach may highlight a problem with your process or your unit test cases.

3. Security Visibility 

By security visibility I mean the application logs, customer service reports, etc. that can contain data relevant to attacks or vulnerabilities. In the past, each such source of information was typically managed in isolation: customer complaints were routed to the customer service team, incident logs were routed to the infrastructure team, and so on.
But in DevSecOps, changes are happening too fast for silos to stand. The goal is to empower DevSecOps teams by giving access to security-relevant data from the application in real-time or on-demand to everyone who can contribute to addressing security vulnerabilities. The better visibility the team has across different data sources, the better they can decide how to tackle the situation, especially if it indicates a potential attack on the application.

4. Security Feedback

By security feedback I mean the (typically) annual penetration test, which is meant to offer feedback on how secure the application is. But how do you scope an annual pen test? Should it have a narrow focus and go in-depth? Or should the scope be more broad, which might make the testing too shallow?
In waterfall scenarios, pen testing once per year was OK because a new release only came out every 12-18 months, so vulnerabilities weren’t brought into production often. But pen testing just once annually is riskier in an agile/DevSecOps environment where you’re pushing a base through production every few weeks. Consider multiple penetration tests per year and possibly a change in scope or parameters of the test.

The Best DevSecOps Approach

In summary, these DevSecOps approaches can actually make your organization and its applications more secure than traditional methods. DevSecOps methods can detect attackers earlier in the attack chain, which may allow you to thwart their access to sensitive data.
DevSecOps methods also enable your team to continuously test and refine your vulnerability triage and response. As you’re getting continuous feedback from your pen test tools, you may be able to actually move faster than your attacker.
A final benefit of DevSecOps is the ability to continuously test and refine your incident response or security operations process. If you’re treating even simple, security-related bug reports as incidents, you can continuously improve your process by asking questions that you might not even think to ask in a traditional mode.
To brainstorm on how best to integrate security testing and verification into your development or DevOps lifecycle, including appropriate tooling and security frameworks, contact Pivot Point Security.