Many argue that application security should be the responsibility of a security team. However, while security professionals can contribute, developers are usually the only ones with the technical ability to fix software security vulnerabilities. The same goes for software compliance. When it comes down to it, only developers are equipped to build applications in compliance with specific software standards.
Considering the tight deadlines for development teams, giving them additional duties can present challenges. To help developers deliver secure applications without slowing them down, many teams have adopted DevSecOps—which encourages integrating automated security testing into the DevOps workflows for every release.
DevSecOps helps teams deliver more secure software faster, but what about more compliant software? Many teams trying to achieve software compliance encounter similar challenges as those trying to achieve software security. Luckily for them, they can use similar strategies.
What Does DevSecOps Do?
The fast, iterative software release cycles supported by DevOps workflows present hurdles for software security.
In traditional approaches to securing software, testing occurs toward the end of the software development life cycle (SDLC), after an application’s construction. As a result, most (if not all) of the application is tested at once, and a long, daunting list of security issues is sent back to developers.
However, many teams find this methodology incompatible with DevOps. Development teams don’t have the time—not to mention the budget—to stop whatever they’re doing to sort through a massive spreadsheet of issues.
To solve this problem, organizations can implement DevSecOps by integrating security testing into the shorter, higher-frequency feedback loops of fast DevOps release cycles. Rather than running one big test after developers finish building an application, DevSecOps calls for automated security testing performed early and often. By helping developers check in more secure code, DevSecOps helps reduce the volume of issues QA must identify and send back to them.
If development teams can integrate security testing into DevOps workflows, why not compliance testing?
How to Apply DevSecOps Practices to Software Compliance
While testing for security usually requires a different analysis than testing for compliance, development teams practicing DevSecOps can use a similar approach to compliance testing.
Like traditional application security testing, compliance testing typically happens in the QA environment. A very rough application development and testing workflow looks something like this:
- Developers write the code for an application.
- QA tests the code while developers move on to another project.
- QA sends a list of compliance violations back to developers, requiring them to pause their current work to fix those problems.
There is nothing technically wrong with this compliance testing strategy. However, this approach is frustrating for developers and costly if the list of issues is especially long. To resolve more compliance issues before an application is complete, teams can implement practices inspired by DevSecOps to help developers commit compliant code earlier in the SDLC.
One of these strategies is to integrate automated compliance testing into DevOps release cycles. By testing the application in increments rather than all at once, teams can reduce the number of compliance violations per testing cycle. While it obviously requires higher-frequency testing throughout the SDLC, this approach has proven to be faster than waiting to find issues in QA.
Another approach is to create a sandbox environment in the integrated development environment (IDE) where developers can run tests themselves. Testing their own code as they write it equips developers to check in cleaner, more compliant code, so compliance violations are less likely to show up in QA—or worse, production. This approach has the added benefit of familiarizing developers with code that leads to compliance violations.
These strategies for identifying and resolving compliance violations are not meant to replace QA testing. However, by integrating compliance testing into multiple stages in the SDLC, teams will see fewer issues in feedback loops between QA and development—which better supports DevOps workflows.
What Does This Look Like in the Real World?
As with security testing, integrating compliance testing into DevOps release cycles requires new technologies and workflows, each with a different learning curve.
Regarding technology, static analysis is growing as a popular option to help development teams build compliant applications. Coverage varies between static analysis tools, but in general, the technology can find issues in code quality standards, such as MISRA and CERT C/C++, as well as security standards, such as OWASP Top 10 and PCI DSS.
The static analysis tool or any other technology that teams choose to address, software compliance plays an important role in the workflows they adopt. As discussed earlier, those hoping to keep issues out of QA will want to find solutions that can:
- Integrate into the quick feedback loops between testing and development.
- Scan code in the IDE as developers write it.
Creating a more continuous cadence of feedback between testing and development could represent a significant shift in a developer’s day-to-day.
While “DevCompOps” doesn’t quite have the same ring, development teams in regulated industries will find cost-cutting benefits by integrating compliance testing into DevOps release cycles.
