DevSecOps and Container Security Take Center Stage at Black Hat 2022

Attacks targeting software vulnerabilities continue to grow, from Solar Winds to Log4j and beyond. One result is a growing consensus that software supply chain security is becoming a practice that must be embedded in development as part of the CI/CD process, thus giving birth to the role of DevSecOps. John Amaral, CEO of Slim.AI, shares key takeaways from Black Hat 2022 and looks at the trends to prepare for.

At Black Hat 2022, this rise of the developer voice and the role DevSecOps plays in software supply chain security was a dominant theme, discussed from the keynote stage, at vendor booths, and in the “hallway track” of casual conversations. Needless to say, software supply chain security and the developer’s role therein have been elevated to the list of top concerns among enterprise CTOs and CISOs, as they seek strategies and solutions to secure their software.

This year’s event was the first time we’ve seen so many attendees with the title DevSecOps. In many of my conversations with CSOs or VPs of security, the topic of finding and hiring DevSecOps professionals was mentioned as an essential strategic priority. These C- and VP-level leaders either had the headcount for this role or were actively getting a headcount to bring someone into that position.

Proactive Security

There is an undeniable shift left in security strategy. Enterprises and service providers are actively in the process of moving security from the realm of monitoring for security incidents and responding when an attack happens to build security into the software development pipeline so that, to the extent possible, vulnerability-free software is being shipped.

Interestingly, there was an awareness among attendees that automation is the only way this can be sustainably accomplished. Developers, more and more, are being asked to take on things that they were never trained for, and security is no exception. To achieve security, code must be shipped free of known exploits, and the only way to make that happen is by automating the process.

At one session I participated in, a study was presented in which researchers at the University of Calgary, New York University and others looked at the code generated by GitHub’s AI-assisted code generator, Copilot. Researchers examined these code snippets for vulnerabilities and found that, depending on the language used, up to 40% of the code delivered by the system is vulnerable. Clearly, it’s up to the developer to find those vulnerabilities, and automation is the only way to achieve this goal at scale.

Seen More: Rethinking DevSecOps To Meet Today’s Dynamic Threat Landscape

Emerging Topics to Follow

CISOs and VPs of Security were looking for solutions to deliver that automation, especially for the growing portion of their software portfolios built with containers, using technologies like Docker and Kubernetes. The focus of many conversations was achieving the goal of shipping software quickly while assuring its security.

Let’s look at some of those topics that were hot at Black Hat.

SBOMs

An SBOM (software bill of materials) is a nested inventory or list of ingredients that make up software components, according toOpens a new window the Cybersecurity and Infrastructure Security Administration, or CISA. President Biden’s May 12, 2021, Executive OrderOpens a new window mandates that software vendors to the federal government must deliver an SBOM for each software product they deliver to the agency they’re selling to. Other governments, from Europe to the Asia Pacific, are heading down the same path as the U.S. Currently, there are two widely accepted SBOM standards: the Cloud Native Computing Foundation–supported SPDX and OWASP’s CycloneDX. A common standard for SBOMs will be needed, and we’ll need to see more tools that make SBOMs actionable rather than just a point-in-time recording of a container’s contents. 

Code signing 

Code signing was another topic of discussion among CISOs. It’s a method for embedding an immutable identity of a developer into a code package. Why is this useful? Well, cryptographic proof of a code author’s identity is a great way to validate that a piece of code has not been altered since the moment that author “signed” it. The goal here is to give code consumers a strong, encrypted identity so we can confidently audit who changed what and when. This is not a new concept, but projects like Sigstore and the startup supporting it, Chainguard, are advancing the technology. An alternative approach, Notary v2Opens a new window , has support from Microsoft and Docker but is still in the design phase.

Container slimming

An interesting development being discussed at Black Hat was container slimming. This technology involves removing those components that are useful in development from containers but only bloating the attack surface in production. DockerSlim was an early open-source project in this space. At its core, slimming is about identifying what’s in your containers and removing what’s not needed before production, and startups like mine, Slim.AI, are building additional capabilities with that core functionality. 

Vulnerability information sharing

Sharing means finding efficient, automated ways to share information about what’s in the software between the makers and consumers of code. Surprisingly, the means to do that remain somewhat primitive. Black Hat attendees talked with us at length about their challenges in building sharing into their software delivery pipelines. It’s a challenge we’re taking on at Slim.AI and one that government agencies such as CISA and industry organizations like the OpenSSF are facilitating. 

Looking Ahead to the Next Black Hat

By the time we arrive at Black Hat 2023, there will be advancements in each of these areas. Open source projects, commercial offerings built atop them, and proprietary approaches will join the first movers in this space. With any luck, the industry will have early standards and best practices in place to guide decisions and process design by then.

Without too much imagination, one can see a near future in which developers and engineering teams can easily access an inventory of their containers and contents. With any luck, the tools available by then will allow entire teams to access vulnerability scan data and communicate only the relevant and critical exploits discovered to the relevant code authors. And with a bit of luck, those capabilities may be integrated into existing CI/CD pipelines with a robust API vocabulary.

We’re all aware of the importance of understanding, documenting and managing our software supply chains. Engineers are working to improve security processes, and they’re having conversations and building the tools developers need to reduce software vulnerabilities before they make it to production. Those minds were keen to find solutions at Black Hat. This search for ways to reduce risk by building better software will likely consume a big part of the conversation at security events going forward if Black Hat 2022 was any indication.

What were your thoughts on Black Hat 2022? Share with us on FacebookOpens a new window , TwitterOpens a new window , and LinkedInOpens a new window . We’d love to know!

More on DevSecOps: 

• Security and Speed, Two Opposing Priorities Can Co-Exist in DevOps
• DevSecOps: 5 Reasons to Integrate Security Into the Application Development Lifecycle
• Using a Least Privilege Framework to Boost DevSecOps