It’s called DevSecOps, but that doesn’t mean security has to divide the development and operations processes. Instead, it can be the glue that brings them together, enabling organizations to more confidently release higher quality software with fewer vulnerabilities.
Maybe you’re misreading the vibes
The relationship between developers and security researchers is often tense. (To put it mildly.) It’s much easier to write software if you don’t have to worry about someone looking for logic bugs, memory safety issues and other quirks that don’t inhibit the program’s functionality but could end up making it front-page news if someone finds a way to exploit them en masse. Or at least that’s how some developers view bugs disclosed by their security-minded counterparts.
But most security researchers aren’t looking for vulnerabilities in popular software because they have a grudge against the people who programmed it. Instead, they’re looking to improve the quality of the software, and mitigate the risks it might pose to the people who use it. They aren’t looking to obstruct the development process; they’re looking to improve it. Or, if the process itself doesn’t improve, at least the people using the software can be aware of its flaws.
This is why U.S. Cybersecurity and Infrastructure Security Agency director Jen Easterly said at Black Hat 2024 that cybersecurity is a “software quality problem.” Was that comment just supposed to be a dunk on the companies producing buggy software? Probably not. Instead, it was a call for organizations to improve the quality of the programs they produce, which will naturally lead to software with fewer vulnerabilities just waiting to be exploited.
A rising tide raises all boats
Here are some of the ways security-focused testing can improve overall software quality:
- Source code review: Security researchers can analyze a program’s source code to find the logic bugs, memory safety issues and other causes of vulnerabilities. But that doesn’t mean the benefits of reviewing that source code are limited to improved security. Other issues can also be discovered, intentionally or not, via this process.
- Continuous testing: Part of the problem with incorporating the “sec” in DevSecOps is the idea that looking for security flaws in the software will delay its release, which runs contrary to the entire DevOps philosophy. But which sounds more frustrating, delaying a public release by a few days to address known vulnerabilities, or having to rush out a series of bug fixes after the fact when those vulns are discovered in the release build?
- Software Bill of Materials: It’s easy to lose track of the dependencies pulled into your organization’s software. Security researchers are uneasy about that because they’re worried about libraries and packages introducing vulnerabilities, being backdoored, etc. But enumerating these dependencies can also help developers figure out what they need to add, update or even remove from their programs to improve its quality.
Better reporting for fast-moving teams
A study conducted by ESG on behalf of Synack found that 66% of organizations said penetration testing reports were difficult to operationalize within ticketing systems, incident response playbooks and other security operations processes; 60% said it is hard to test frequently enough to keep pace with updates to the software in question; and 47% said testing teams were unlikely to have the breadth of skill required to fully assess modern apps, which can be considerably more complex than the software of yesteryear.
These are valid concerns—especially when organizations think about a traditional penetration test conducted by two researchers with two laptops over the course of two weeks. But Penetration Testing as a Service (PTaaS) offerings like the Synack platform can address all of those concerns. We ensure reports maintain the signal-to-noise ratio developers need to figure out what problems need to be addressed first, offer continuous testing that can in fact keep up with app updates and recruit elite researchers from around the world to the Synack Red Team, which gives us access to a wide breadth of skillsets.
A crucial part of proactive security
Security has often been treated as a reactive practice—organizations update their software when security researchers disclose vulnerabilities, look to improve their network security when they fall victim to ransomware and vow to take security more seriously when their share prices take a dip because they fell victim to, or were the cause of, a particularly noteworthy hack.
This approach is outdated. Organizations need to be proactive about securing themselves and their customers. Continuous penetration testing can help with the former; embracing DevSecOps can help with the latter. In both cases, security needs to stop being an afterthought.
