Echoing Dickens, for many in software security, it is the best of times and it is the worst of times. Every day brings literal front page news about software compromises resulting in massive data leaks. Meanwhile, the use of cloud-native technologies has meant that the variety and complexity of the software being deployed has outstripped the ability of traditional security processes and tools to protect their organizations. Security is no longer an afterthought of the IT department but a board-level issue that can cost people their jobs when failures happen.

The security domain is finding answers to these challenges with new practices like DevSecOps and “Shift Left” strategies. These responses address the challenges in the security domain in a similar way to how software developers addressed their velocity and scale issues: by focusing on people and processes. As a cultural practice, DevSecOps is about breaking down barriers between developers, product security, and operations teams so security becomes a shared responsibility and is factored into all parts of the software lifecycle. Meanwhile, Shift Left is a posture that believes better security outcomes are achieved by being proactive in the development phase and enforcing best practices as early as possible.

While recognizing that the ultimate challenges are often cultural and social, software tools and products can help drive change. But for the owner of the security budget, evaluating tools can be difficult, especially where traditionally the security team has only been called in post-hoc to the development of software or the operation of the platform.

What follows are five key new areas to consider when looking at tools for DevSecOps.

Process Flexibility

Not only are we in the early days of perfecting new security processes but many companies are still adjusting to using CI/CD tools or GitOps-based workflows. It is a safe bet to say that every year, there is some change to how your company does software development as you learn what does and doesn’t work for you. When choosing a security tool, it should have the flexibility to integrate with whatever tools you use to drive automation and be able to work in multiple stages of the software development lifecycle. Look for products with full API coverage and an automation-centric architecture. The GUI is important but it should only be something you interact with for ad-hoc or post-hoc reasons. It’s more important that you can push information into the system and get data out using a variety of tools or custom scripts.

Signal to Noise

The ultimate goal is to avoid slowing down development velocity while ensuring developers take responsibility for security. This means they can’t be distracted with excessive data or false positive security alerts. Every security tool can generate a long list of issues for almost every software library or container and indeed this has been one of the calling cards of more traditional legacy tools: the more results, the better. You should verify that there is a way to separate the signal from the noise and that developers can get immediate and useful information to help them resolve issues or make updates as efficiently as possible. Following on from process flexibility, you also need to ensure that that information can get to the developers as part of their normal workflow; security issues are just another type of bug and creating separate security-specific workflows will add friction.

Software Bill of Materials (SBOM)

Supply chain security has become a top issue as a result of the increasing use of open source components and the well-publicized compromises found in various projects. With developers now making the decision about what code to use or re-use and releases often happening multiple times a day, periodic audits don’t work anymore. A Shift Left approach requires that a complete inventory of every piece of code has to be maintained in real-time. This allows ongoing scanning to be performed so the impact of CVEs can be assessed instantly and doesn’t require a crawl of deployed applications.

Data-driven Anomaly Detection

When it comes to runtime, the environment has changed to zero-trust models and immutability as a line of defense but the security techniques are the same: look for anomalies and alert. Agent-based approaches make much less sense in the cloud where containers may not even make running them possible. This is pushing detection to a data-based approach where algorithms can spot anomalies more effectively than admins looking for odd peaks or troughs in telemetry data. As algorithms are only as effective as the data they are applied, tools that collect data from both the platform and the application layer are critical.

Policy as Code

For many, a security policy is captured in Word documents and applied variably with product security teams acting as enforcers through spot checks and annoying requests for reports. DevSecOps evangelizes for repeatability, velocity and automation so in other words: no spreadsheets! It’s critical that policy can be codified and enforced consistently throughout the SDLC in a way that evolves as the threats change. Modern security products treat policy as something akin to another QA test that has to be passed. In this way, policy becomes just another software artifact to be developed, versioned and shipped. Out of the box policies can help you create a solid baseline but flexible policy options are critical for any organization that wants to manage the trade-off between shipping velocity and good-enough security.

Many of the traditional criteria still apply when choosing a security product: choose a vendor that understands your challenges; look for platform agnosticism and avoid lock-in; and select usability over complexity. But understanding that new challenges require new approaches will help you navigate a growing and complex ecosystem.