In 2019, I wrote a post detailing the traits of DevSecOps—the practice can be defined as the process of security automation in which IT and security are more de-siloed. DevSecOps introduces a more intentional culture wherein security-by-design principles are baked into the software development process early on. All in all, the aim is to have security enable development, not stall IT and slow down the SDLC.
So, years later, how is DevSecOps doing? Has it achieved this ideal? Well, I recently met with Jeff Williams, CTO and co-founder of Contrast Security, for insights into the state of modern DevSecOps. According to Williams, most large companies still have real problems with application security and software dependency providence is constantly in question. We’ve recently seen this reality rear its ugly head amid exploits in frameworks like Log4j and Spring4Shell.
Large organizations are likely carrying tens of thousands of vulnerabilities in their backlog. Yet, as consumers, we happily trust software for our critical applications without knowing what lurks behind it. “The industry has a real transparency problem,” said Williams. And as applications are getting more interconnected, they are getting more complicated and they’re getting more critical, Williams added. “These three Cs—connected, complicated and critical—make security harder.” These conditions are culminating in what he called “a perfect storm.”
6 Ways DevSecOps Teams Should Respond
So, how should DevSecOps teams respond to the seemingly endless barrage of new vulnerabilities and attacks? Williams shared some general ways teams can increase their security posture.
1. Practice Security in Sunshine
It’s easy to point fingers when something goes wrong, especially if it’s a serious vulnerability or attack. Instead, Williams encouraged teams to practice what he calls “security in sunshine.” This is an attitude that gives more transparency to security issues internally. Embracing a culture of blameless retrospectives can ensure employees are comfortable bringing up issues within their team.
Security in sunshine can be adopted in an external-facing way as well. Williams likened it to how, in product manufacturing, it’s standard practice to share a bill of materials (BOM) with trade partners. We may see similar labeling standards emerge for software in the form of software bills of materials (SBOMs) so that external consumers are better aware of dependencies and potential threats, Williams suggested.
Cybersecurity awareness certainly takes a communal effort that requires transparent communication. We see this realized daily in bug bounty programs, CVE reports and fixes to open source software. Bringing potential threats into the light of day is necessary to squash vulnerabilities before they are exploited.
2. Translate High-level Requirements
Security guidelines issued by bodies such as NIST and ISO are essential to keep in mind. Implementing the concepts these guidelines recommend, such as the principle of least privilege, multifactor authentication and zero-trust architecture, are considered best practices by most security professionals. However, these high-level requirements don’t often translate down to the developer on the ground floor. “The developer needs those requirements translated down four levels to specific technologies they’re working with,” said Williams.
A programmer needs more realistic advice on how these guidelines affect, say, Spring Boot applications or how they should configure permissions in AWS. According to Williams, teams must interpret these abstract recommendations with more concrete annotations that meet the nuances of the technology stack they’re working in. The same process is required to help developers create projects compliant with data regulations, as it’s difficult to take this high-level advice into practice. Translating these requirements into more readable terms is an excellent way to de-silo security and development teams.
3. Shift Smart
In recent years, there’s been a lot of talk about shift left. The idea is that to reduce security threats later on, organizations need a tighter grasp on security earlier in the software development life cycle. Shifting security left is often enabled with tools that hold code accountable for potential threats using automated analysis.
However, Williams sees this as an area where organizations need to be careful. Not all security tools are developer-friendly and might introduce inefficiencies at scale. Instead of shifting left, he advocates for “shifting smart” to introduce security at junctures where it’s most efficient. “You don’t want to shift all security left—you want to shift right too,” explained Williams. “Spread it out over the whole life cycle.”
4. Avoid Added Steps
There’s more than one way to bake a cake. Similarly, there’s more than one way to cook up a great software application. As such, most organizations are dealing with multiple tools, making it harder to apply security consistently across all stacks.
Security should be catered to the specific tooling and processes being used, Williams explained. But that requires answer certain questions like where is a software development team in their journey? Are they waterfall or Agile? How does each CI/CD pipeline behave?
Obviously, there are many unique factors to consider. Ideally, tooling should be flexible enough to attach itself to existing infrastructure, Williams said, instead of adding additional steps to an already sprawling tooling ecosystem.
5. Take Security Seriously
And, of course, there’s the cultural element. “It’s 2022, and companies still don’t take security seriously—they need to change,” said Williams. “It doesn’t matter how they get there—that they get there matters most.”
Admittedly, cultural change is a slow evolution and the best way to advance will be to add practices and technologies progressively over time. Thus, Williams recommended iteratively inserting pieces, measuring outcomes and proving value along each step of the journey.
6. Update Outdated Tools
WhiteHat Security found the average time it took to fix critical vulnerabilities in the spring of 2021 was 205 days. But such a long timeline is at odds with the pace of new threats and the need to patch them quickly.
The industry is changing the way they do AppSec, said Williams. Traditional DevSecOps security tools, he said, such as static analysis tools, dynamic analysis tools and web application firewalls, are outdated and less accurate compared to newer technologies like interactive application security testing (IAST) and runtime application self protection (RASP). Accuracy, speed and scalability will be important characteristics for security automation tools that don’t require additional human intervention or produce too many false positives.
DevSecOps Is Still Maturing
A healthier DevSecOps practice aims to decrease the “vulnerability escape rate,” as Williams called it. Hopefully, by providing instant feedback on designs, engineers will learn not to repeat the same mistakes, thus decreasing the number of vulnerabilities they introduce.
In summary, DevSecOps is still maturing. Looking to the future, a stronger DevSecOps approach will require a more open attitude to mitigate threats. It also requires practical guidance as not all top-down guidelines translate well into the active development environment. Applications will require proper code hygiene, and the software supply chain itself must be protected, too, in addition to conducting active monitoring of production environments.
