RSA Takeaways

Me and Jacob - Certified Sales Wiz at Opus

A coworker told me “RSA is a marketing conference” and they couldn’t be more correct. I spent most of the time running from coffee shop to coffee shop, because most of my favorite vendors didn’t think spending the hundreds of thousands of dollars on a show floor booth was worth the price (I think they were probably correct). Overall, it was a wonderful place to see some of my favorite vendor friends in person, but a terrible place to try and learn anything technical. Below are some of my major takeaways.

Table of Contents

• Word on the Street

  • ASPM is Hard to Sell

  • Runtime is Heating Up

  • People are Discontent with Current Tools

  • Stay out of Wiz’s Way

• The Latest Buzzwords

  • AI

  • Risk Reduction

• Other Updates

Word on the Street

Some recurring conversations I had with vendors and practitioners.

ASPM is Hard to Sell

Confusion around ASPM remains high across all fronts. From talking to practitioners and vendors, there seem to be two main problems:

First, vendors are clashing that don’t even really compete - because everyone just markets as “application security.” The market is under educated about ASPM from the perspective of what the 8 types of scanners are and why someone would want them. When it can be challenging to understand even one of these scanners at a time, it makes sense that the market needs to better know what scanners are out there and why they matter. I heard from multiple vendors of companies churning between products that do radically different things, as security teams are unclear about what they’re even looking for.

Second, many security teams have still not learned how applications work and are deployed in containerized environments. Many teams are still drowning in CSPM and vulnerability alerts, and haven’t even begun to tear up their application for vulnerabilities from third party libraries. Because of this, a lot of purchasing power remains in the hands of developers or SRE teams who will pursue solutions out of their own desire for security even when they’re not being given requirements.

Runtime is Heating Up

I’ll have a full post on this soon

While shift left practices are critical for maintaining security, it’s abundantly clear that the marketing push into shift left as a cure-all has lost steam. More security teams are realizing that their patching velocity is not fast enough to keep them secure, and they need better mitigations in place to protect their runtime assets.

Despite the need for runtime, there remains a lot of market education on the different approaches that are out there, and to be frank, why CrowdStrike is really outdated for modern application workloads. In general, “CNAPP” is coming across as a solved arena, and targets are shifting from Palo to CrowdStrike.

People are Discontent with Current Tools

For most of the startups, catching churn on point solutions from “platform vendors” is where the “right now” money is. People seem largely discontent with the first to market solutions - from SCA to SAST and everything in between - and are looking for rip and replace at a discount.

This is where it’s a tough market for visionary companies versus point solutions. The market has clear demand for “better SCA/SAST/DAST/Container” scanning as a single checkbox, but has been slow to realize the value of consolidating all of those things into one place.

Stay out of Wiz’s Way

Wiz remains on the forefront of every conversation - whether it’s discussing why they won the market, whether a security team should switch to them, or what they’re going to do with their billion dollars. Here are some good theories:

1. The market size for ASPM and code security more broadly is too small for a giant investment there, the real target is CrowdStrike and runtime.

2. It’s all vanity money because they want to be the largest tech IPO in history.

3. The Wiz runtime agent is actually really good, but perception remains that it’s something they don’t do

Either way, almost every conversation with vendors revolves around if they should compliment Wiz versus take them on directly. For most vendors, it’s being sure they could replace, but being happy to compliment. At the end of the day, in my opinion, Wiz’s strength is asset management and vulnerability scanning at runtime, so basically anything else can be seen as complimentary depending on if it’s an important enough problem.

The Latest Buzzwords

AI

That’s about 1/5 of the vendors having this in their description

While the general sentiment that AI is overblown in marketing remains true, the real blame lies at the feet of product leaders. While everyone certainly slapped AI in their posters, there was little clarity on the show floor about how AI was being used to substantially improve security, or how vendors were helping to secure LLM usage.

Honestly, last year everyone’s CEO told their product team “make it AI” and now marketing teams have nothing substantial to make campaigns around besides “look, it’s AI!” AI in general is certainly a hype cycle fad; however, some vendors are continuing to work with it both to secure it, and to improve security.

Risk Reduction

Now that everyone wants to be an ambiguous platform with a terrible solution to every use case, there was a hefty dose of vague pitches from vendors. If you look at any booth, it was impossible to tell what they did from the high level pitches. Everyone was simply a way to “get visibility into and reduce your risks.”

Other Updates

No update to the List this week with travel. This is a little personal bloggy - but my flight from Charlotte to Raleigh on Thursday night was cancelled so I ended Ubering back for 3 hours at 12am with 3 strangers which was making the best of a weird situation!

Also, I know several people I’ve done calls or podcasts with are familiar with our little dog Amy. We unfortunately had to have her put down this weekend which has been really hard for us - she was with us for 14 wonderful years and will be greatly missed.

Amy - 2010-2024

The best part of working on Latio is getting to see the amazing innovation across emerging security products. I was excited to see that this year I agree with most of the RSA Innovation Sandbox choices. I wanted to take this week to highlight some of their amazing work and innovation. If you miss the innovation sandbox, make sure you check these guys out anyways!

Table of Contents

• Identity Innovation

• Data Data Data

• The Rad Ones

• Latio List v1.13

Identity Innovation

Identity continues to be a tough nut to crack for startups. Despite being a glaring need for most companies, identity products are tough to sell because they’re often hard to integrate and don’t have clear categories to solve overarching problems. Aembit and P0 are both doing some amazing things in this category, and they’re great choices for this innovation.

Aembit

Aembit logo

What’s the Problem? Because applications ultimately need decrypted credentials, machine to machine authentication is one of the hardest challenges in security. As an example, just yesterday this question came up in the Kubernetes subreddit asking about delivering secrets to apps in Kubernetes. Existing solutions all have various security issues.

What they do: Aembit provides the most secure way I've seen of delivering machine to machines credentials to your workloads. They uniquely validate asset identity via contextual properties and integrations, and then inject the approved credentials into the workload. Put simply, Aembit securely delivers secrets to workloads.

What makes them unique: Aembit has two core technologies that make them really unique to me. First, they have contextual access controls for granting secrets to apps. Traditionally, secrets are only verified via basic RBAC or server roles, if at all, before being passed onto workloads. Aembit instead allows the creation of access conditions, such as the machine existing in Wiz, before the secret is granted.

Secondly, Aembit has put a huge amount of work into the secret delivery mechanism itself, even offering proxies for JWT authentication so that services are never even aware of the secret itself.

Why wouldn’t you use them? Secrets are super challenging and super nerdy. At the end of the day, everyone probably should use something like this, but the implementation requires a lot of careful thinking.

P0 Security

P0 Security Logo

What’s the Problem? Managing user access to resources in a cloud environment is a complicated nightmare. Not only is there cloud API access, but more importantly, there’s access to the underlying workloads themselves. At this point, there are a few different offerings out there for Just in Time (JIT) cloud access roles that help to solve this for the Cloud API. P0 is one of only two companies I’m aware of (Apono is the other one) that extend this beyond the cloud API layer down to the workloads themselves.

What they do: P0 creates comprehensive Just in Time (JIT) access roles across cloud API’s and workloads, allowing an extremely high level of both accessibility and security by spinning up short lived roles as needed to resources. I really think this will be the future of cloud access.

What makes them unique: While many companies at this point offer JIT role creation for cloud, P0 extends far beyond this by offering it for Kubernetes, Postgres, Snowflake, and others. This allows both a better request access workflow, and expands it into workloads themselves.

Why wouldn’t you use them? JIT access is still challenging conceptually, and many companies aren’t quite ready for it yet. However, I think this is a far better approach than endlessly chasing down least privileged policies.

Data Data Data

Despite the plethora of “DSPM” and acquisitions, data security, discovery, and tagging remain giant challenges for organizations. I’ve seen numerous data tagging project start, but rarely are they finished and well maintained.

Harmonic

Harmonic Logo

What’s the Problem? Most of the fright around AI adoption has to do with data storage, manipulation, and ultimately leakage. Data tagging has been a huge challenge for orgs, and the rapid adoption of LLMs has made that worse.

What they do: Like most of the other LLM security vendors, Harmonic helps gain visibility into LLM workflows and usage.

What makes them unique: Harmonic differs with their focus on using LLMs to help detect and map the flow of sensitive data. The team at Harmonic has a rich history in scanning the dark web for sensitive data, and they’re aiming to maximize the power of LLMs to bring this same approach to LLM security.

Why wouldn’t you use them? LLM security is still very new and developing very quickly. As of my last evaluation, there were some vendors with more support than them, but this field is changing so fast that might already be outdated!

Antimatter

Antimatter Logo

What’s the Problem? Everyone wants to do contextual data protection, but it is an incredible pain to anonymize and tag data in a way that it can still be used later. Often it requires either third party services or complex workflows.

What they do: Antimatter allows you to create encrypted chunks of your data along with metadata, enabling advanced control use cases, such as policies for reading or writing data, audit access logs, or protecting LLM RAG use cases.

What makes them unique: Antimatter manages to bridge the gap between traditional privacy APIs and local data cleanup services. Their approach of including metadata directly allows you to create highly tuned policies around how and by whom that data can get read or write

Why wouldn’t you use them? This stuff is super nerdy. While Antimatter makes it more approachable than some alternatives, it’s still tough to implement.

The Rad Ones

My favorite companies are those that are born out of community efforts that care about tackling important challenges in the ecosystem. Kubernetes security and vulnerability streams are two of those challenges.

Rad Security

Rad Security Logo

What’s the Problem? Kubernetes security is really hard and requires correlating a lot of logs across configuration and runtime environments. Furthermore, vendors need to be able to quickly adapt to an ever changing community.

What they do: Rad has combined just about every feature you could want in a solution highly focused on Kubernetes security. They provide everything from the posture scanning to runtime detection based on standardized baseline, even combining those features together to maximize their value.

What makes them unique: Rad is unique for combining runtime with configuration scanning and baselining, and their commitment to the Kubernetes security community. Their team has rich backgrounds across application security organizations, and while individual aspects of their tool may exist in other platforms on paper, their depth and breadth far exceeds larger CNAPP platforms.

Why wouldn’t you use them? I’ve gotten to the point where I highly recommend a specialized Kubernetes runtime solutions like Rad, ARMO, Upwind, Sweet and Oligo - each offers a unique flavor of solution to Kubernetes security that should be layered in with your CNAPP. That being said, many companies might feel they’re covered by their CNAPP provider (Most of the time, I don’t think so).

VulnCheck

VulnCheck Logo

What’s the Problem? The NVD is an essential part of the entire cybersecurity ecosystem that operates without enough funding, support, or good enough data. There is a desperate need for better upstream vulnerability data.

What they do: VulnCheck offers enriched vulnerability feeds that primarily increases the depth of exploit and PoC data. This is the key data that’s most needed in prioritization and remediation efforts.

What makes them unique: VulnCheck is born out of providing a necessary service to the community, providing hands on exploit data to better assess the severity of vulnerabilities.

Why wouldn’t you use them? Because VulnCheck doesn’t directly offer their own scanning, they’re the kind of service most companies will hope their upstream scanner is using to enrich their data, rather than using directly.

Latio List v1.13

• Added Bedrock Systems to Boundary Breakers and Container Runtime - an extremely nerdy level of security by providing a hypervisor for linux workloads

• Added Approov to Mobile - a runtime oriented approach to validating the security of an app before fetching sensitive data -

• Added Sternum to Container runtime - another nerdy level of container security, but focused on memory exploits and expanding into other CWEs

• Added Oligo to container vulnerability because somehow I only had them under container runtime and SCA before

Platforms vs. Point Solutions

Founded Dates of CNAPP Providers

One recurring discussion in cybersecurity is the relative value of platforms versus point solutions. Conveniently enough, every platform provider thinks platforms are what the people really want; conversely, every point solution thinks platforms are an awful value proposition.

The truth lays somewhere in the middle: customers need their security challenges solved, and if a single solution solves multiple problems, it’s going to be an easy win. However, Lacework’s huge devaluation and sale to Wiz demonstrates that just “being a platform” with a large set of features isn’t the same thing as solving customer problems.

On paper, Lacework had substantially more features than Wiz. They support all the same scanning, plus some, and have had agent based runtime detection for a much longer time. However, all of these features were built around a UX that people didn’t want, namely the idea that every finding should turn into an alert; and over time customers didn’t want more alerts, they wanted less of them. Customer’s don’t go on the market looking acquire sets of features, they go looking to solve problems.

Table of Contents

• How CNAPP Evaluations Happen

• The State of Platforms

  • Platforms outside of CNAPP

How CNAPP Evaluations Happen

When I’ve ran CNAPP evaluations, it’s always been in the context of solving specific difficulties our security team was running into. Once I was focused very much on vulnerability management, another I was focused specifically on Kubernetes security, and in another was looking primarily for cloud visibility.

Each time I’ve run a CNAPP evaluation, I’ve selected a different tool, because different businesses have different challenges. This goes against wisdom in other categories - typically users who get used to a particular software will become advocates as they go from job to job. Someone who likes Slack more than Teams for communications isn’t going to magically change their mind because they’re at a different company. Same with something like comparing SIEMs like Splunk and SumoLogic. CNAPP differs as a category because it’s simply too many use cases squeezed into a single tool.

As an example, if you need cloud visibility and container detection response, Sysdig is the easiest recommendation you can possibly make. The other providers certainly have added enough that they can say they “do Kubernetes protection,” but not nearly enough that they’re at all competitive with Sysdig on it. The discussion really becomes if the CSPM visibility aspects of Sysdig make up for any deficiencies against Kubernetes focused solutions like Armo, Rad, and Upwind.

Conversely, if your main issue is vulnerability scanning production workloads of mixed container and host environments, Wiz and Orca quickly become the most flexible options. Even though most tools now “support” agentless scanning, the level of maturity here is wildly different. The problem was never the feature of agentless scanning itself, it was the ease of doing vulnerability and asset management - one piece of which was agentless scanning.

CNAPP has a unique challenge: their customers are all coming to them to solve radically different problems. Ironically, none of their problems are, “I really need a CNAPP!” Shoving more and more things into a single tool doesn’t solve a single customer problem. The goal is not to build a feature for every deal you ever lost; rather its figuring out if someone benefits from having these set of features in the same place?

It’s obvious to me how CNAPP got here: the starting point was, “everything you need to secure the cloud.” But with hindsight, we can see more clearly that the cloud is just a datacenter with an API, and it’s really been about visibility and protection for the workloads all along.

The State of Platforms

I’ve also noticed that each of these tools really remain competitive only in what they started as. Sysdig started as a container visibility and monitoring solution, Lacework started as a cloud baselining solution, Aqua as a container security solution, Orca as agentless visibility, Prisma as Cloud API scanning and container security duct taped together, and Wiz as agentless infrastructure security. None of these tools have managed to meaningfully overtake a competitor in what they started as: Aqua still has the container vulnerability scanner that powers half the other ones, Sysdig still has the best container runtime security, etc.

The problem these platforms face is that their valuations are all artificially inflated: they’ve been funded as though they all provide the same service, when in reality they’re all pretty different. Wiz’s hyper growth is about their ability to provide cloud asset management and vulnerability scanning in the easiest way possible - a nearly universally needed functionality. Yet everyone has fundraised as though they’re doing the exact same thing. Now everyone “sort of” offers agentless scanning, API access to data, Data scanning, IAM management - they’re chasing each other into irrelevancy.

Unfortunately, these companies have mostly used their additional funding to desperately try and offer the features of their competitors, instead of doubling down into their use case. And it’s hard to blame them, because they fundraised off of the “CNAPP market” as a whole, they’re stuck trying to play feature catch up. The most successful CNAPPs will be those who kept modest valuations and have continued to build to their use cases.

Platforms outside of CNAPP

How does this relate to other platform approaches, like ASPM? Unlike CNAPP, I think all of the ASPM features we’re currently seeing bundled actually make sense to be there - which is why CSPM existing in Ox and Aikido tells me a lot about how they understand the goals. Adding CSPM to ASPM makes no sense from a marketing perspective - most people buying ASPM will already have a CNAPP, and the ASPM version of CSPM will not be as good. Furthermore, none of these companies are trying to fundraise off of the “cloud security” market as a whole.

Instead, these ASPM providers include CSPM scanning because it provides developers some much needed context about the deployed state of their application, and gives essential information to fix terraform related alerts. This is why CSPM makes sense as part of ASPM, but not vice versa - solving the customer problem of “I have too many scanners and can’t fix anything” requires cloud context, but solving the problem of “cloud visibility” doesn’t require code scanning.

This is why I love seeing developments like Rad and Armo creating endpoint agents, they’ve recognized that even though these features will be hard to market against CNAPP, they’re essential to solving the customer problem. Products that solve real customer problems will always overcome the marketing difficulty perceived competitive differences.

At the end of the day, we should only reward platforms if they’re solving multiple customer problems in the same place. Of course they will all say they do this, but the reality of a PoC often quickly unveils the reality.

The Heart of Reachability

A while ago, I wrote an article called “5 types of reachability analysis” with Endor Labs. In that article, I talked about the 5 types of reachability, which I summarized as:

• Function-level reachability

• Package baselining

• Internet reachability

• Dependency-level reachability

• Package used in image

At the heart of these types of reachability analysis is a simple goal: determining the likelihood that you’re actually vulnerable to something. Function level reachability says, “hey, you’re calling the function from the CVE, there’s a pretty high chance you’re vulnerable.” Package baselining says, “you’re calling this vulnerable function at the runtime.” Internet reachability says, “this function (or package) is accessible via the API.” Dependency level reachability let’s you know that the package containing the vulnerability is imported. Package used in image tells you that the package is indeed installed (yes this offers the least value!)

In this article, I’ll address why reachability has become the flavor of the moment, where it’s helpful, and why it’s not the complete solution.

Table of Contents

• Why is this so prevalent?

  • It’s easy marketing

  • It’s the problem of the moment

  • It’s the intuitive solution

• Is Reachability Helpful or Hurtful?

  • Helpful: The lack of true positives is a real prob …

  • Helpful: Context

  • Hurtful: Reachability has a false negative problem

  • Hurtful: Reachability has a data problem

• Reachability isn’t the end goal, it’s patching

• Latio List v1.12

Why is this so prevalent?

It’s easy marketing

Reachability is super complicated - I gave 5 definitions in that article, but since then I’ve even come across 2 additional types thanks to Backlash. Namely, SAST reachability analysis, and Phantom Package reachability. Backslash ties SAST findings back to the internet, and finds used libraries that aren’t directly called out in the package.json.

The only 7-layered evaluation an AppSec team is doing during a sales process is of the 7-layer nachos the sales team bought them at the conference. This confusion is helpful for marketing teams, because it’s so easy to honestly say “we do reachability!” and “we do it in a way that’s better than they do!”

It’s essentially the CNAPP problem - pick a very specific slice of the pie, and then pitch that in sales and marketing as some massive differentiator, when whether it is or not is really ambiguous. For example, function level reachability is lightyears more valuable than detecting only if the package installed, but that looks very similar to runtime detection from a high level. Only by diving deeply into the difference can teams sort through the noise.

It’s the problem of the moment

If AppSec has a rallying cry, it’s this:

The main problem with SCA tools is that I legitimately don’t know if I’ve ever seen a true positive. CVEs are scored on a worse case basis, and CVEs often use software in weird ways, leading to a huge number of high severity false positives. Any product that can make the numbers go down instead of endlessly up is what people are looking for.

It’s the intuitive solution

This video lays out the problem with the latest 10/10 Rust CVE - no one uses Rust like this, but if they did, yes it would be critical. Reachability promises to address this issue: you don’t even use that function from Rust, so you’re not vulnerable. Below is the typical AppSec workflow:

Now that our CVE discovery scanners have gotten pretty good, vendors are moving on to the next question, “how can we help teams determine if they’re actually vulnerable and if they need to patch?”

Is Reachability Helpful or Hurtful?

Helpful: The lack of true positives is a real problem

When you setup a tool, it shouldn’t take years before you see a true positive come out of it. Especially with zero day threats, it’s extremely helpful to know right away if you’re vulnerable or not.

Helpful: Context

A lot of vendors are focusing on one or two types of reachability, but some, like Ox, combine multiple of them to create a more holistic view of the application, and bring together multiple forms of reachability analysis. Not only is it more information to help prioritize, it’s also helpful to know where to go to fix things.

Hurtful: Reachability has a false negative problem

While it’s awesome to tune out stuff, there are a lot of edge cases in CVEs that will eventually come back around, where you might still be vulnerable to something pretty critical, even if it doesn’t show up as a “reachable function.” Sometimes, tools don’t have access to the full context of the application, and might think a data flow isn’t happening, but it’s really happening upstream in another project. As a note, this is only a risk to the vendors not really dedicating the effort to reachability it needs; most of the ones focusing on it are very aware of trying not to do this.

Hurtful: Reachability has a data problem

Oftentimes CVEs don’t include the vulnerable function data. Many vendors have gotten around this in interesting ways, such as looking at the linked git commits and what they fixed, or creating their own internal databases. However, it can be really unclear how reliable a vendor’s conception of reachability is in terms of dependencies on well written CVE descriptions. This is incredibly difficult for teams to evaluate without creating specialized environments thoroughly testing multiple CVEs.

Reachability isn’t the end goal, it’s patching

Recently while recording a podcast with Opus, an analogy struck that I was really helped by. When patch Tuesday rolled around for Windows machines, no one took the time to analyze their impact, or if the vulnerabilities were true positives or not. Instead, they just patched them.

In AppSec, because there’s not a single vendor, we’ve allowed the difficulty of patching to flip the way we think of vulnerabilities, and this has been to our detriment. Instead of, “are we vulnerable?” our first thought needs to be “can we patch this?”

Rebuilding an image or patching a patch version is not always less time than doing reachability analysis. Sometimes, patching is a major project that requires insight like that offered by Code Fixers to create patches for you. However, tools should help people identify that level of effort before focusing on the “are we really vulnerable?” question.

Reachability is still helpful - a lot of times patches aren’t available, or would require an unrealistic lift, in which case you’d do reachability analysis. It’s just not the outcome of first importance.

See more in the Video with Backlash: https://youtu.be/ViZpLKfLtJA

Latio List v1.12

• Added Leen to Boundary Breakers - a unified API for vulnerability data

• Added Tracebit to Boundary Breakers - Honeypot infrastructure for your cloud

• Added Turbot to Cloud Identity, Secret Scanning, IaC, and CSPM - guard rails and enforcement on top of querying cloud data

• Added Cremit to Secrets Scanning - Secrets scanning + real time monitoring

• Added Pillar to LLM - Library based application detection and protection

• Added OpenRefactory to SAST - focusing on building an amazing SAST engine above all else

This graph, it’s provocative

WTF is ASPM was easy to write because it was what I had hoped Snyk would become when they branched out of SCA with Snyk SAST back in 2020 - the all in one configuration scanner. Finally, I’d be able to throw my Cloud Security Posture Management (CSPM) tool into the dustbin of history. Early CSPM triggered thousands of alerts for the most obscure or mundane of misconfigurations, and modern CSPM is not much better.

Cloud Native Application Protection Platform (CNAPP) was an acronym bestowed upon us from on high to try and make sense of disparate cloud functionalities getting wrapped into single platforms. Gartner defines CNAPP as:

This definition directly explains the problem with CNAPP, its goal is to consolidate rather than solve a customer problem. Consolidation was driven by an arbitrary “platform play” to try and increase revenues, not out of a customer need. For comparison, ASPM is solving a problem, “I have too many vulnerabilities from too many scanners;” conversely, CNAPP solves the vendor’s problem, “People seem to be buying this thing, so let’s do that too.”

Since trying to define ASPM, I’ve been asked this follow-up question most frequently: “WTF is CNAPP?” On the one hand, this question is urgent because it’s the bigger market - all of the biggest cloud security companies have invested in this acronym because the projected market cap exceeds 20 billion dollars. On the other hand, “WTF is CNAPP?” is hard to answer because, unlike CSPM, CNAPP was created primarily for vendors and not for customers. At the heart of CNAPP lies an unverified assumption: that having everything in the same place provides security value.

In this article, we’ll briefly cover a history of the term CNAPP, where it seems to be going, and where I’d like it to go.

Table of Contents

• CNAPP v1: CSPM + CWPP = CNAPP

• CNAPP v2

  • Will it Work?

• CNAPP v3 - Death to CNAPP!

  • Configuration Scanning vs? Runtime Protection

  • Building for End Users or Building for Use Cases?

  • It’s all about the use case

• Core Questions and Conclusions:

  • How to Choose a CNAPP

• Latio List v1.11

CNAPP v1: CSPM + CWPP = CNAPP

More than anything, Palo Alto’s brilliant acquisition of Redlock (CSPM) and Twistlock (CWPP), set the stage for CNAPP. Slapping these two tools together and wrapping them with duct tape allowed Palo to say they had something beyond CSPM - they weren’t just scanning cloud APIs for misconfigurations, but also providing runtime defense and vulnerability scanning of the workloads. As an aside, for the remainder of the article I may use CWPP and EDR interchangeably, as CWPP was just EDR that worked in container contexts.

From there, the arms race was on. This is why CNAPP is defined more for vendors than for customers: it’s a collection of almost random capabilities, with no clear way that they benefit each other besides all being “in the cloud.” The image below shows the number of legitimate point solutions that are swallowed up by CNAPP vendors because they happen to get the same logs; however, having access to the same logs is not the same thing as building for a customer use case.

CNAPP v1 in all its messy glory

At the end of CNAPP v1, CNAPP included:

• CWPP (Linux/Container EDR) - Some kind of visibility into workloads for detection and response

• CSPM - Scanning Cloud APIs for misconfigurations (including identity, CIEM) and getting logs back for changes

• Vulnerability Scanning - Checking images and hosts for CVEs

• DSPM - Some kind of visibility inside databases

The above diagram also illustrates why everybody is a CNAPP, and nobody is a CNAPP. Vendors can arbitrarily choose any bespoke functionality in the shaded box and argue that “that tool isn’t a real CNAPP, they don’t even do {functionality} well.” Or, “you need to buy our CNAPP, because we offer {functionality}.”

When it came to early CNAPP adoption, I cared about CWPP because I cared about Kubernetes Runtime security, that’s why I always loved Sysdig the most. Those that loved open source loved Aqua. Those that loved CSPM loved Wiz. Those that already had contracts with Palo love Prisma (😉). Those with a CDR bent loved Lacework.

Mapping CNAPP v1 by Ease of Use and Fullness of Response Capabilities - a diagram truly everyone can complain about.

Until recently, I thought Wiz was so far ahead because ease of use trumped every other factor; however, I think it’s actually that Wiz stumbled upon an overlap of CNAPP functionality that had the largest use case. It benefits customers to have asset management and vulnerability scanning in the same place, because you need to scan every asset for vulnerabilities. Additionally, doing so agentless-ly remains pivotal because agent maintenance sucks in non-container environments. Providing these common functionalities without an agent made it too good to ignore.

As CNAPP expands outside of CSPM and Vulnerability Scanning, the bundling makes less sense. Is there a benefit to having the same tool that knows where my database is tell me the risks with table permissions and sensitive data? Is there a benefit to combining my container vulnerability scanner with my container runtime protection? Do I want an agent doing vulnerability scanning to also do runtime defense?

CNAPP v1 Categories

Since Wiz found the right functionality overlap, namely asset management + vulnerability scanning, the race has been on to slap more buzzwords together to try and differentiate.

Unfortunately for customers and vendors alike, the state of the market has become, “is our {functionality} better enough than {CNAPP_Vendor} to justify owning it separately?” This is unfortunate because the better question would be, “does this tool help us protect what matters to us?” The more we think in terms of categories instead of use cases, the further away we get from meaningful improvements.

CNAPP v2

Again, more to drive revenues than solve problems, CNAPP providers are expanding into application security. Below is what they’d love to have us conceive of as the future of CNAPP, rolling ASPM in as just another use case.

CNAPP v2 is the inclusion of ASPM

Once again, CNAPP providers are ingesting more data and figuring out the use cases later. Assuming there’s value in having ASPM in the same place as DSPM, CSPM, CWPP, Vulnerability Management, etc. This is why it’s so hard to answer the question I get all the time, “do you think it’s harder to shift left or shift right?” The real question is, “why do I want to do that at all?”

The proposed benefit of including ASPM into the fold is the “code to cloud” picture of an application; however, being able to provide a picture of an application is not by itself a value proposition. This is why a lot of examples are - “look, you can map all of your vulnerabilities to the cloud for full application context allowing you to…prioritize!” Companies have expanded into so many bespoke scanning capabilities that they need to start selling solutions to the problems they’ve created!

Will it Work?

As an engineer, rolling ASPM into CNAPP sounds like a diabolical plan to make my day to day life more miserable as yet another half baked scanner enters the fold. However, from an investor perspective, there are very solid business reasons to try and keep the consolidation play going.

All this to say that I’m not a fan of rolling ASPM into CNAPP for the same reasons I’m not a fan of CNAPP as a concept in the first place - it’s a consolidation play for revenue more than a product plan to help human beings do their jobs better and with more joy. The pros are all business, the cons are all day to day life for engineers.

CNAPP v3 - Death to CNAPP!

Instead of chasing acronyms, let’s take a step back and ask “what should CNAPP be?”

First, the Gartner definition will never be meaningful, because there will never be an all in one total security vendor. Instead, the largest vendors in the space will be those that address the most total common use cases in the easiest way. The future of CNAPP ought to be use cases, not acronyms.

Second, ASPM and CSPM are unique in that they’re fundamentally configuration scanning tools, which is why I think they will continue to unify into SPM at some point. It’s the CWPP aspect of CNAPP that makes it more unique; however, I maintain that these tools being in the same place only provide accidental value. That is, companies tend to stumble into the benefits of combining data.

Third, we should begin viewing CNAPP as a combination of separate use cases more than a single tool. Customers should evaluate CNAPP platforms on their ability to meet use cases against smaller companies, rather than evaluating them one on one against each other.

Configuration Scanning vs? Runtime Protection

Arguing that CWPP and CSPM/ASPM being united doesn’t provide real value requires a little more nuance - many configuration scanners are being amplified by endpoint context, and vice versa; however, they serve different purposes. Even those like Oligo and ARMO who best bolster configuration scanning with runtime context, while also offering runtime protection, have to recognize that those capabilities are really two separate products.

Here’s an example, if there was value in these tools being in the same place, the XZ backdoor was a perfect opportunity to showcase it: Detecting the CVE (vulnerable version) at runtime required layers of visibility, and detecting the exploit itself at runtime required advanced EDR. But notice even Oligo’s positioning in their detection article:

Startups like Oligo and Armo (and others) are providing both configuration scanning and runtime protection, but not because these tools directly complement each other in any way for the end user, instead, it’s because they’re building around use cases! The original goal of CNAPP built SPM and EDR together because the use case was “protecting the cloud,” Armo and Oligo do it because they’re trying to secure specific technologies from end to end.

To further elaborate, CVE detection is fundamentally proactive and targeted at developers to fix potential exploits. Runtime context helps in confirming the validity of those exploits. Conversely, runtime detection and response is reactive and targeted at operations teams to respond to actual exploits. Configuration context helps in confirming the responsible team and sometimes at delivering a fix.

In this way, configuration scanners having access to runtime data make fixing better, and runtime detectors having access to configuration scanners make detection better. However, having both outcomes, remediation and response, in the same place, provides zero intrinsic value unless tied to a more specific use case. Such use cases include “complete Kubernetes protection” and “complete API protection” - eventually “complete application protection” will require RASP’s revival.

Building for End Users or Building for Use Cases?

From a market analysis perspective, this revelation, that the closer one gets to a use case, the more the line between configuration and runtime scanning blurs, has been extremely helpful to me. The most outcome built companies - like Oligo and Deepfactor for open source security, Armo and Rad for Kubernetes Security, Impart and Levo for API Security - have built products that span runtime and configuration scanning, because they’ve attacked use cases rather than acronyms. It also explains why I tend to rank these companies so highly - I love the act of actually securing things more than the act of “helping improve the life of users.” Not that these things aren’t related, just in terms of my personal preference.

Conversely, tools that focus on their target end user, like Endor and Arnica for open source (developers), Gem and Sysdig for runtime (SOCs), have tended to commit very hard to either configuration scanning or runtime protection, rarely both. I believe this even helps to explain why Snyk oscillated for so long on adding runtime scanning into the fold - it fit the use case but not the end user.

Returning then to “WTF is CNAPP,” here are two ways I see this playing out:

Splitting Features by End User

The first is to split features by end users, or even groups of ends users. I think it’s feasible to build for two of these at the same time, but not all three. Product organizations will not and should not, fundamentally align to security as its chief goal. This is why there’s tension between combining these different use cases into the same platform - they’re attempting to combine different end users into the same dashboards and tools.

Splitting Features by Outcomes

I think splitting features by outcomes is the better solution, and one that means we kill CNAPP as an acronym. No one goes to buy a tool to “protect every theoretical application configuration across every possible environment.” Instead, people look for the tool that will best protect their environment. In the future, I won’t evaluate CNAPPs against CNAPPs, but instead use cases against use cases.

It’s all about the use case

Focusing on use cases means that the big CNAPP providers like Wiz, Orca, Lacework, Prisma, Sysdig, etc. get evaluated on their ability to provide end to end protection for a specific use case, and then weighed on how many other applicable use cases they cover. This is why I truly don’t have a “favorite CNAPP” - I have legitimately recommended each of them to different security teams. From an investment perspective, this is a math equation of (Average Joy of Using an Applicable Feature) x (Market Size of Applicable Use Cases) they cover.

The below graph maps this out from a “likelihood to win the market” perspective rather than any particular customer useable graph. Customers don’t look for CNAPP, instead, for example, Sysdig, Wiz, and Lacework should be evaluated against other tools for specific outcomes - such as Kubernetes, Cloud Configuration, and Linux Host Vulnerability scanning - and then the fact that they each do all three is weighed against using point solutions. For customers, the question is just “by using this platform instead of a point solution, am I giving up a feature that makes a material difference?” Oftentimes, the answer is yes, oftentimes, the answer is no.

Mapping CNAPP from a “who wins the market” perspective, not from a buyer perspective. Keep in mind average satisfaction is just my personal one!😊 

An interesting application of this approach is that ASPM should eventually build runtime protection - but I think the strategy here should be an imported library-esque RASP, akin to DataDog, rather than eBPF agent, although either would technically work. However, the tension will always be that you’re building for different end users, so this shouldn’t be a priority item. Delight your end users (developers, developers, developers!) first, then build the additional use cases.

Core Questions and Conclusions:

1. If you’re a startup, assume that CNAPP is coming to try and eat your lunch. CNAPP has the ruthless goal of shoving every security tool together, whether it makes sense or not.

2. If you’re a startup, the key question is, “what makes our technology so good at a use case that you would buy us on top of a CNAPP?” Some Examples I love:

   • Kubernetes Protection and Container Runtime

   • Runtime SCA insights

   • API Security

   • Supply Chain Security (Container Vulnerability and SCA, specifically malware protection)

   • Application Protection (ASPM)

3. If you’re a startup, start focusing exclusively on use cases and outcomes instead of features like “reachability” that amount to checkboxes anyone can add to their platform. For example, the goal isn’t reachability - it’s 98% vulnerability noise reduction.

4. Bespoke scanners will be commoditized only because they run into a feature check box competition with upstream platforms. If you’re building a really good one of these scanners, you need to focus on the outcome that differentiates you from what a CNAPP can provide.

5. Why did the GRC Automation market escape the battle with CNAPP? Both tools have access to the same data, but those like Vanta and Drata built around a use case to the point where they’re not even seen as competitive platforms even though they have a ton of overlap.

6. If you’re a CNAPP vendor, get out of the acronyms arms race - it’s a losing battle. Wiz won CNAPP v1 not because they have the most acronyms (they still don’t), they won because they combined the two people wanted combined: asset management and CSPM. This is why I also love Sysdig - the use case is cloud runtime protection, not “look how many acronyms we have.”

7. If you’re a CNAPP vendor, delight your end user, then build the extra use cases for other customers. The alternative is a platform everyone hates, or, a recipe for churn.

8. Is there an answer to the question, “what’s the best way to protect your cloud?” Would anyone have asked the question, “do you have a datacenter security platform?”

9. If you’re looking for a CNAPP tool, define your use case before you talk to vendors. Don’t let them guide you with their RFP that, shockingly, they’ll be really good at!

How to Choose a CNAPP

1. Know your general architecture and highlight important functionalities. Ask questions like:

   1. What technologies are at the core of our infrastructure?

   2. How do our services get exposed to the internet?

   3. Where do services get configured?

2. Experiment with Open Source tools first to get an idea of the scope and implementation challenges that will come up

3. Assume you’re going to get more findings than you can fix, and select tools in light of that

4. Don’t purchase a tool before you fix an alert that comes out of it

5. Stay focused on the use case rather than the features list

Latio List v1.11

• Added Seedata to Boundary Breakers - Honeypots as a service is dope and underrated

• Added SecOps Solution to Remediation Platforms - Network based vuln scanning and patching. It's not the cleanest fit but I don't have a separate category for general vuln scanning

• Added Infield to Code Fixers - Great team offering SaaS and services for painful version upgrades

• Added Sonrai to Cloud Identity - Probably the fastest way to get your cloud 80% more secure than it was before by focusing on boundaries instead of least privileged

• Added Push Security to Corporate Identity - Browser plugin for detecting unsafe SaaS use/risk from employees

CVE-2024-3094, Open Source Security, and VulnCon - Is there any hope?

I’ve never been so sure that vulnerabilities are both critical, and don’t matter at all. This last week was VulnCon in my very own Raleigh, NC. Overall, the main benefit was seeing just how human our vulnerability systems are; immediately after it was over, the latest CVE shows just how true that is. This week, we’ll cover a bit from the conference, and the wild ride that was CVE-2024-3094 - and how it shows that vulnerability management has never been more and less important than it is now.

Table of Contents

• CVE-2024-3094

  • CVEs Don’t Matter

  • CVEs Are Critical

  • How do we Fix This? (It’s not ASPM)

• VulnCon Summary

• Latio Updates:

 CVE-2024-3094

The latest CVE, identified by an engineer at Microsoft and reported through RedHat, puts on full display the strengths and weaknesses of our CVE ecosystem. First, I put together a brief summary here of how to check if you’re vulnerable. Long story short, this CVE has all of the open source drama and intrigue you’d expect, while displaying how short we fall, despite the countless “supply chain security” vendors that are out there.

CVEs Don’t Matter

1. Most vulnerabilities that get published are along the lines of “if you’re using this particular function from this library in this particular way that no one really does, you can do something you’re not supposed to.” Almost every named major vulnerability is critical because it changes from “no one uses this like this” to “everyone uses this package like this.” Vulnerabilities like this one were mission critical because it was an active malware pushed upstream by a maintainer who had spent years slowly taking it over. This wasn’t a vulnerability as much as it was malware from upstream.

2. This excellent timeline shows how these catastrophic attempts are led by human problems. Our entire software industry is being help up by single open source maintainers who get no credit, money, or recognition for their critical services. This shouldn’t be thought of as much as an isolated vulnerability as much as the tip of the supply chain iceberg.

3. We still don’t know the full nature of the actual exploit. It’s clear that the exploit was compiled from test code when distributed via RHEL and Ubuntu distros, but it’s unclear if that’s the only places the attack would run from and even the full nature of what the attack was doing besides allowing takeovers of SSH connections. If you wanna really get nerdy with it, this is the article.

4. The scariest part of all is that the discovery was so much by chance. Andres Freund at Microsoft was running benchmarks on a beta version of Ubuntu and discovered the high utilization of resources from sshd processes. Luckily for everyone, he dug in deep to try and figure out what was causing the issue.

From all of these points, this wasn’t a vulnerability as much as malware, it could be considered a type of social engineering, it’s not consistent in the exploit, and the CVE ecosystem played no role in its discovery.

CVEs Are Critical

1. Without a clear vulnerability disclosure program, there would be no way for this vulnerability to be responsibly disclosed and patched. For every vulnerability like this one that gets a lot of buzz, there are vulnerabilities that go unnoticed that can potentially cause catastrophic harm to systems.

2. Once the hype of patching is over, NIST and CISA will be the two agencies most likely to actually figure out what the nature of the attack was and what can be done about it.

3. Although the authoritative source at NIST wasn’t the first website that went live, it’s absolutely critical that it exists. The vendor blogs are all just SEO traps for marketing dollars, there needs to be someone with a long term legitimate interest in keeping research up to date.

The problem demonstrated exactly why timely and accessible systems need to exist for large scale responses to zero days.

How do we Fix This? (It’s not ASPM)

The vulnerability problem requires more innovation than another vendor making Jira tickets for patches faster. Here are the areas of innovation I think are actually helping:

I’d highly suggest reading this

1. To be frank, open source funding is a joke. I’d highly suggest learning about how open source projects are (not) funded. Companies are making billions of dollars in profits off of open source projects, but only 304 million is given across 32 foundations (2022).

2. The only provider I see having a realistic chance of fixing this is Tidelift. Companies have a real security interest in supporting the open source that they take for granted, and the Tidelift subscription model is the most realistic cost/benefit.

3. Approaches to security that go beyond CVEs - this vulnerability should make us think, “what if the exploit didn’t cause performance issues that would’ve been noticed?” And, “how many exploits like this are undetected?” This is why I talk to so much about the value of runtime protection like Sysdig, Oligo, and Rad that stand a chance at detecting this as a zero day (there are others as well).

4. Shifting detection priorities to upstream - which I talked about a lot in this post.

5. The convergence of SCA and container vulnerability scanning - with this vulnerability, only container scanners caught it unless your SCA scanner did something funky with it. More and more I think the container should be the source of truth and just backport the SCA functionality like scanning static files.

In sum, it’s time to recognize that vulnerability programs do not adequately address the problem of application security. We need to really widen our approach to include supply chain more broadly, as well as runtime protection.

VulnCon Summary

VulnCon met at an interesting time - the NVD is changing to a consortium, they’re underfunded, and there’s a backlog of processing vulnerabilities. Ultimately, it was great to meet with people from larger hardware providers down to smaller software ones - it helps paint a picture of different size companies approach vulnerability management. While vulnerabilities are a false positive headache for small SaaS company, for a massive hardware provider they’re absolutely critical problems to address before they ship to government critical entities.

Here are 4 small take aways from the conference:

1. There are two different levels of seriousness for vulnerabilities

Everyone would do well to acknowledge the dichotomy that exists for addressing vulnerabilities. Most vulnerabilities in most contexts are false positives, therefore, it’s only natural that smaller companies would hate dealing with them. They slow down innovation for very little benefit, and these companies have no financial incentive to take them more seriously. While it would be nice to talk about having everyone provide public SBOMs with clear VEX statements per CVE, these smaller companies are just praying no one starts asking for them; and they’re right to do so, because SBOMs are a false positive hellscape for most providers.

Conversely, massive companies, especially those that provide software that runs on endpoints or hardware, need to take vulnerability management much more seriously. In these contexts, attacks like buffer overflows are a lot more applicable, and you have a lot less ability to provide runtime defenses alongside your infrastructure.

At the end of the day - a company is only going to take vulnerability management as seriously as they have to. What that means in the simplest way is that someone is either asking for your SBOM and reading it, or they’re asking for your SBOM to file it away in the trash can.

2. There are amazing global efforts to get vulnerability management more online

As an American, I really take the NVD infrastructure for granted. There were a few different talks from agencies like ENISA and APCERT that are doing everything they can to get vulnerability disclosure and coordination programs up and running in Europe and Asia Pacific. These agencies will be critical as other regions continue creating more and more software (not that they aren’t already, but that the amount will continue to increase, and vulnerabilities alongside it).

3. SBOMs are a Necessary Evil That Need to Evolve

Everyone agrees that SBOMs suck to manage and are full of false positives, yet everyone agrees that they’re necessary tool for building trust between vendors. At the end of the day, I think SBOMs are very much a problem in flight - ultimately they will matter in some standardized form that everyone is okay with, but for now they’re still not super useful. Until we know what we want to see from an SBOM (the answer can’t be 0 vulnerabilities), its usefulness won’t be apparent.

4. More Needs to be Done Upstream

Everyone thinks the work of vulnerability management is critical, but no one wants to pay for it. Vulnerability management is a problem because companies use so much open source software. Correction, vulnerability management is a problem because companies don’t want to pay for open source software - they use it to make massive profits, but have the expectation of never giving back. This to me is the core problem we’re talking about - no one wants to foot the bill to support open source projects. Tidelift is the only vendor approaching the vulnerability management problem at it’s upstream source, while others offer small donation kickbacks to the various foundations that are occasionally able to help.

Latio Updates:

1. Added VulnCheck to boundary breakers - Excellent threat feed like enrichment of vulnerability exploit data

2. Added REVEALD to Remediation Platforms - Not the cleanest fit, but trying to avoid creating a CTEM category. REVEALD places vulnerabilities in their context helping determine blast radius.

3. Added Aikido to some categories I didn’t have them in - hard to keep track of all the scanners when you’re 9-in-1

4. Added Intigriti to Pen Testing - bug bounty but better

5. Added EdgeScan to DAST - lots of pentesty services

If you want a guaranteed winner LinkedIn post, here’s a free template:

“Companies are not taking LLM security seriously enough, researchers got {Popular LLM} to reveal {Nothing That Sensitive}.

The security industry can be really susceptible to VC trends, because for every “mind blowing new technology” comes along with it “how can we securely use mind blowing technology?” We’ve already seen millions in funding for LLM Security startups, LLM security courses, and LLM security newsletters. My position is that

LLM Security is both scarier and not as scary as you think

LLM Security fits two use cases which we’ll cover in this article:

1. Leaking Company Data into a ChatBot

2. Using or building an LLM API in your application

   Table of Contents

   • LLM Security is both scarier and not as scary as y …

     • ChatBots

       • Potential Security Issues

       • Market Solutions

     • Your Own Apps

       • LLM as ChatBot

       • Where’s the Risk?

   • Latio Updates:

ChatBots

Unfortunately, this use case has garnered the most attention out of the gate. My guess is that it’s been successful because it’s the easiest to sell, the easiest to make, and has the most fear/uncertainty/doubt (FUD) around it. Let’s figure out if this fear is warranted by starting with a diagram:

Potential Security Issues

There are three potential security issues, none of which really have to do with LLM itself.

1. The provider is training on your data, and you don’t trust them to anonymize it or make it inaccessible later

2. Third party websites could hide misleading content on their pages when the LLM looks up their information

3. Uploaded data used as part of a plugin contains misleading or malicious information

There are generally two buckets of potential security issues then, one, sensitive information shows up in a future model or dataset, or two, users are mislead by information that the LLM looks up. Either way, neither of these should be massive concerns for most businesses.

To the first, that the provider is potentially training on your data, here are what the most popular providers say they do with your data:

1. OpenAI stores your data unless you opt out. Paid business plans are automatically opted out.

2. Gemini stores your data for up to three years unless you opt out

3. The nature of HuggingFace Spaces opens up your data to a potentially wider audience

4. GitHub stores your data unless you opt out

While there some potential concern here, I think it’s mostly unfounded. First, it’s extremely unlikely that any sensitive data used in a prompt would ever find it’s way out on the other side of an LLM once it’s trained. Second, and more importantly, most providers offer an opt out for data storage.

The second and third concerns, that data retrieved by LLM’s could contain malicious instructions, have more to do with user training than anything. Anyone can upload plugins, and any data used in plugins should be treated as public. Furthermore, LLM’s hallucinate and aren’t always correct. In my mind, neither of these things are massive security concerns, more just general user awareness. Unless you plan on protecting users from misinformation on the internet, there’s not much to be done here.

Market Solutions

We need to acknowledge that these use cases are just specialized data loss prevention (DLP) and stop treating it like a unique use case. This is also the product that most security vendors started with because the use case is very simple: a browser plugin you deploy across your endpoints to monitors what data your users are putting into LLMs.

I like the way Prompt Security splits these in half - I’m suggesting the IT integrations are just DLP

First, you should care as much about this as your company cares about DLP in general. If you don’t already watch for more common issues like employees sharing documents publicly, or using websites like pastebin, there’s no reason to treat this any differently. If anything, it’s less severe because with those websites you can actively share data, but with LLMs you’re only worried about the third parties being trusted with it directly.

Second, I would not buy a specialized solution for this. Existing DLP providers like Nightfall or Cyberhaven were able to quickly pivot into this space and offer it as the one slice of holistic solutions it was meant to be. My personal feelings on DLP is that it’s a risk where the control is the threat of legal action more than any technological solution.

Real or FUD rating? FUD.

Your Own Apps

As I see it, there are two general implementations of LLMs into internal applications:

1. LLMs as ChatBot

2. LLMs with RAG

The first has zero security concern, the second has massive security concerns.

LLM as ChatBot

Architecture Diagram from GitHub

Most current applications are using this architecture, where some UI exists for asking questions, the user’s question is sent to either an open source or third party model for an answer.

GitHub’s example architecture adds an additional layer, that most larger companies are doing, where they lookup additional helpful information to contextualize the query, and apply a filter to remove sensitive information before it’s sent to the LLM.

This might be controversial, but I still see very little risk to this configuration. Say the worst case scenario, a user enters a prompt “My social security number is this, store this somewhere and do everything you can to share it with an attacker.” Even if you do zero filtering, the LLM is only going to reply with some variation of “That was a weird question, I can’t help with that.”

The introduction of an LLM cache does introduce this concern however, because the LLM is fetching other similar responses for a faster response time. Once persistence is introduced to the LLM application, there begins to be possible exploits, such as a user prompting an application with instructions for creating and saving a malicious script. If a cache is involved, there needs to be something to validate that the script isn’t shared to another user.

Where’s the Risk?

Ironically, the LLM itself is the least risky piece of any LLM architecture. Like with most appsec challenges, the risk is in the inputs and outputs. The two key questions are:

1. What information are you supplementing the user’s request with?

2. How are you surfacing the response to the user?

With that in mind, here’s the FUD:

1. Unless you’re augmenting user requests with non-public data or using an LLM cache, you probably don’t need an inbound data filter. In this case, the user is just interacting directly with an LLM with no sensitive data in it, therefore, it’s hard to see what an inbound filter would be necessary.

2. Unless you’re directly running LLM outputs as commands, you don’t need special output sanitization checks besides normal JS escaping to avoid XSS attacks.

To the first point, the only reason I can see for an inbound filter is if you want to protect users from posting something public like “reflect my social security number in this public forum” and then it posting, which users could just do anyways if they really wanted to.

To the second, if your LLM is trained on public data, and you’re not adding private context to it in any way, there’s nothing non-public that’s going to get returned to the user.

Here’s the real risk:

If you do use non-public data or an LLM Cache, you absolutely need to do both input and output validation to try and validate that nothing sensitive is getting out. In general, I think too many tools are focusing on filtering malicious inputs, and not enough tools are focusing on filtering the outputs.

Here are some open source and closed source options:

Open Source

1. LLMGuard and Vigil provide input and output scanners.

2. Plexsiglass, Garak, and LLMFuzzer allow you to assess LLMs vulnerability to surfacing unintentional information

3. NeMo Guardrails allows you to setup approved inputs and outputs

4. Rebuff detects attempts at malicious queries

5. HeimdaLLM makes sure LLM’s don’t generate bad SQL

6. ChainGuard from Lakera protects against malicious inputs

Paid

1. Prompt Security and Lakera have SDKs for input and output sanitization

2. WhyLabs and Apex are both taking a more monitoring centric approach that also allows for security outcomes

3. Many paid cloud security offerings detect AI usage in your environment, such as Lasso and Harmonic, but providing SDKs are much more rare.

Latio Updates:

v1.8 is live, small update this week!

• Added Myrror to SCA and Boundary Breakers - Standard SCA stuff, but with the very unique ability to tie binaries back to their source code for validation of packages.

• Added Nullify to code-fixers - AI tooling that begins breaking more out of the SAST use case.

This week I met with Kodem. Kodem has entered into the narrow but exciting world of granular runtime vulnerability detection alongside Oligo, offering a function level view of dependencies based on eBPF logs. A lot of the content here is also covered in the latest YouTube video.

This led to me ask a question I’ve had for a while:

Do you need Container Vulnerability Scanning and SCA Scanning?

(A lot of this is also covered in the latest YouTube video)

Table of Contents

• Do you need Container Vulnerability Scanning and S …

  • JavaScript Detection Example

  • Python Dependency Example

• Results:

• Why it matters

• Other Updates

Something that’s nagged at me for a while is that container vulnerability scanning has always had some degree of SCA detection. Aqua, Prisma, Wiz, Sysdig etc. can all detect things like java binaries and some of their dependencies; however, this functionality has always felt limited and very language specific - but I’ve never fully tested if that feeling is justified.

Oligo and Kodem have forced me to revisit this, as both tools fully embrace that at the container level, when combined with execution data, you really have the ability to get all of the third party dependencies, and even what functions are called. Let’s test this with some examples.

JavaScript Detection Example

In my insecure-app repo, I added a create-react-app (JavaScript) that’s also built by a docker container. A Snyk CLI test reveals vulnerabilities:

These packages need updating:

Snyk confirms that we should do some updates:

Issues to fix by upgrading:

  Upgrade react@15.4.2 to react@16.5.0 to fix
  ✗ Information Exposure [Medium Severity][https://security.snyk.io/vuln/SNYK-JS-NODEFETCH-2342118] in node-fetch@1.7.3
    introduced by react@15.4.2 > fbjs@0.8.18 > isomorphic-fetch@2.2.1 > node-fetch@1.7.3 and 1 other path(s)
  ✗ Denial of Service [Medium Severity][https://security.snyk.io/vuln/SNYK-JS-NODEFETCH-674311] in node-fetch@1.7.3
    introduced by react@15.4.2 > fbjs@0.8.18 > isomorphic-fetch@2.2.1 > node-fetch@1.7.3 and 1 other path(s)

  Upgrade react-admin@3.19.10 to react-admin@3.19.12 to fix
  ✗ Cross-site Scripting (XSS) [Medium Severity][https://security.snyk.io/vuln/SNYK-JS-REACTADMIN-3319447] in react-admin@3.19.10
    introduced by react-admin@3.19.10

  Upgrade react-dom@15.4.2 to react-dom@16.5.0 to fix
  ✗ Information Exposure [Medium Severity][https://security.snyk.io/vuln/SNYK-JS-NODEFETCH-2342118] in node-fetch@1.7.3
    introduced by react@15.4.2 > fbjs@0.8.18 > isomorphic-fetch@2.2.1 > node-fetch@1.7.3 and 1 other path(s)
  ✗ Denial of Service [Medium Severity][https://security.snyk.io/vuln/SNYK-JS-NODEFETCH-674311] in node-fetch@1.7.3
    introduced by react@15.4.2 > fbjs@0.8.18 > isomorphic-fetch@2.2.1 > node-fetch@1.7.3 and 1 other path(s)

Let’s focus on CVE-2023-25572 and CVE-2020-15168, the first is a vulnerability with react-admin@3.19.10 that allows cross site scripting, the second is a transitive vulnerability from node-fetch, which comes in via react > fbjs > isomorphic-fetch > node-fetch.

Now I run the docker build and scan it with Trivy, and the vulnerabilities show here as well:

│ react-admin (package.json)│ CVE-2023-25572 │ MEDIUM   │      │ 3.19.10│ 3.19.12, 4.7.6│
| node-fetch (package.json) | CVE-2020-15168 │ LOW │ 2.6.1, 3.0.0-beta.9                  

Let’s see if this holds true for a Python example:

Python Dependency Example

Dependency:

Snyk finds CVE-2018-18074, as well as transitive dependencies in urllib such as CVE-2019-11236:

  Upgrade requests@2.19.1 to requests@2.31.0 to fix
  ✗ Information Exposure [Medium Severity][https://security.snyk.io/vuln/SNYK-PYTHON-REQUESTS-5595532] in requests@2.19.1
    introduced by requests@2.19.1
  ✗ Information Exposure [Critical Severity][https://security.snyk.io/vuln/SNYK-PYTHON-REQUESTS-72435] in requests@2.19.1
    introduced by requests@2.19.1

  Pin urllib3@1.23 to urllib3@1.26.18 to fix
  ✗ Regular Expression Denial of Service (ReDoS) [Medium Severity][https://security.snyk.io/vuln/SNYK-PYTHON-URLLIB3-1533435] in urllib3@1.23
    introduced by requests@2.19.1 > urllib3@1.23
  ✗ Information Exposure Through Sent Data [Medium Severity][https://security.snyk.io/vuln/SNYK-PYTHON-URLLIB3-5926907] in urllib3@1.23
    introduced by requests@2.19.1 > urllib3@1.23
  ✗ Information Exposure Through Sent Data [Medium Severity][https://security.snyk.io/vuln/SNYK-PYTHON-URLLIB3-6002459] in urllib3@1.23
    introduced by requests@2.19.1 > urllib3@1.23
  ✗ HTTP Header Injection [High Severity][https://security.snyk.io/vuln/SNYK-PYTHON-URLLIB3-1014645] in urllib3@1.23
    introduced by requests@2.19.1 > urllib3@1.23
  ✗ CRLF injection [High Severity][https://security.snyk.io/vuln/SNYK-PYTHON-URLLIB3-174323] in urllib3@1.23
    introduced by requests@2.19.1 > urllib3@1.23
  ✗ Improper Certificate Validation [High Severity][https://security.snyk.io/vuln/SNYK-PYTHON-URLLIB3-174464] in urllib3@1.23
    introduced by requests@2.19.1 > urllib3@1.23
  ✗ Information Exposure Through Sent Data [High Severity][https://security.snyk.io/vuln/SNYK-PYTHON-URLLIB3-5969479] in urllib3@1.23
    introduced by requests@2.19.1 > urllib3@1.23

Interestingly enough, when I first ran Trivy, I realized I hadn’t updated my Dockerfile correctly because the CVE wasn’t there - I was overwriting the version specified in my requirements.txt. Once I corrected that issue however, Trivy finds both vulnerabilities.

│CVE-2019-11236 │1.24.3|
│ CVE-2018-18074 │ HIGH     │ fixed  │ 2.19.1   

Results:

SCA and Container scanning both found all vulnerabilities and provided fix versions. Your mileage will likely vary depending on language support.

The key question: if you have container vulnerability scanning, do you need SCA scanning? No, but you might want it because:

1. Docker images are not always built as part of PRs before they’re merged to master.

2. Docker images often include vulnerabilities developers can’t do anything about, such as upstream APT vulnerabilities

3. SCA can be implemented into repos without a CLI in pipeline, or waiting for the image to exist in container registries

In sum, SCA really provides value because it has a flexible implementation, not because it’s telling you something you couldn’t find via containers.

Why it matters

This brings us to Kodem (as an example, also a reminder, this isn’t sponsored) - they’ve recognized the future convergence of this space and are unifying SCA and Container scanning in order to give people the best of both worlds. Here’s a few things that matter about getting SCA and Container scanning in the same place.

Kodem Dashboard

1. Runtime insights with function level support provides the single greatest false positive remediation potential - you’re only seeing things that are actually called and running, across OS and package vulnerabilities.

2. Sometimes you’re going to want to show developers their results via SCA that runs before container builds, or use it in pipeline to fail builds, but for real visibility and remediation prioritization workflows, you need to be able to check both boxes.

3. Creating the code to cloud picture, as well as providing meaningful remediation guidance requires both SCA and container scanning to be running.

4. Most ASPM type scanners treat Container and SCA scanning as separate products, meaning they run their container scanning (usually Trivy) in OS only mode to avoid the duplicate issues confusion. But this creates a different kind of confusion: getting different results depending on when the scan is run (pre-compiled, post-compiled, and on image).

Next generation tools like Kodem are benefitting from not segmenting their SCA and container scanning into separate tools, but allowing them to complement one another for full visibility and fixability potential.

So, do you need Container Vuln Scanning and SCA?

1. If you’re just checking the box of vulnerability scanning to say you do it, container scanning is all you need

2. If you want to give developer’s the best experience, SCA scanning is a better approach

3. In the near future, there won’t be a difference!

Other Updates

Latio List 1.8

• Added Kodem to SCA and updated container vulnerability description - Kodem has really expanded their runtime insights to be a competitor in the Oligo and Deepfactor space

• Updated Backslash's descriptions to better describe what makes their SCA and SAST unique

• Added Apona to SCA, SAST, and DAST

• Added Apono to Cloud Identity - creating JIT workflows to workloads and cloud providers

• Added Aembit to Cloud Identity - the most secure way I've seen for injecting machine to machine auth credentials

• Added Snyk to ASPM - To be frank, what Snyk's done with this module doesn't make a lot of sense

This is not a post meant to bash CVEs, especially with the recent drama around the issues at the NVD. Instead, I’m arguing that CVEs are the baseline for supply chain security, not the end goal.

Table of Contents

• Are CVE's really the best we can do?

  • Why SCA Scanners Built Upon CVEs

  • What Outcome are we looking for?

  • What are some different approaches?

  • Predictions on the future

• Latio Updates:

This week I planned on further exploring API security or CNAPP, but I find myself returning to SCA after meeting with two vendors, Phylum and Tidelift. Phylum raised a $15 million series A in 2022, and Tidelift a $27 million series C (later expanded to 33.5) at around the same time. After meeting with these companies, I was wondering two things:

1. Why have I come across neither company before in researching application security tools?

2. Should supply chain security mean more than CVE scanning and remediation workflows?

Phylum shared some data with me that led me to question my sanity, having spent so much of my career on CVE mitigation:

• Only 18% of malware detections in open source libraries received a CVE or known vulnerability in a third party database.

• 82% of packages never enter a known vulnerability database (e.g., NVD, Snyk, GHSA, etc.).

• For packages that did get a known vulnerability/CVE, it took nearly two days to do so.

• For packages that were removed, it took on average 31 hours to be taken down; max took 369 hours.

• Roughly 18% of malware packages are still available in open source registries.

These stats led me to ask:

Are CVE's really the best we can do?

At this point, we’re all familiar with some of the problems of CVEs. Here’s some great stats from Qualys if you’re curious. These problems are:

1. They are reactive instead of proactive detection mechanisms

2. There is a substantial increase year over year

3. Only a small percentage are exploitable

4. Scoring fails to reflect the reality of user’s environments

And yet, my day to day is filled with tools who fundamentally exist to prioritize, evaluate, and detect the presence of these CVEs in your environment. Surely we can do better? Are there any proactive solutions to securing open source software?

Why SCA Scanners Built Upon CVEs

Even looking at the Wikipedia for SCA, security is tied to CVEs, “Security: risks of vulnerabilities in components - Common Vulnerabilities & Exposures (or CVEs).” Snyk Advisor, one of the better open databases for the health of open source packages, seems to determine the health of a repo by looking at the general interaction with the repo against the number of CVEs that get discovered in it.

In order to answer why SCA scanners build on CVEs, we could ask a simpler question, why does Snyk’s scanner not support failing builds if their own advisor health check is below a certain threshold? Why do security teams not value the health of a package, but are willing to stop pipelines if a CVE exists against it?

This bias towards CVEs over health reveals that security teams are narrowly focused on one thing: the probability of getting exploited. Security teams assume that CVE’s provide a database of exploits, letting them know exactly when there’s a threat to their app. As anyone who works in security will tell you, most CVE exploits only occur very specific circumstances. Step one to exploit CVEs is too often, “be administrator on the container.”

I’ve come to believe that the general health of a public repository offers a more holistic understanding of the security threat of using a package than CVEs. CVEs still definitely matter, and are of course an indicator of issues; however, what really matters is how likely a CVE is to be fixed, or even identified in the first place! The 3 star 1 maintainer open source repository powering your frontend is unlikely to get a CVE published against it, but very likely to be vulnerable in some way. 

Here’s an example: one of the war-room exercises from my career was discovering that a library we used for authentication had 5 stars and 1 maintainer out of Poland. In the event that that maintainer was phished, malware could easily be added upstream, pulled in automatically, and from top to bottom everything from customers data to intellectual property would be breached. The problem? None of our SCA scanners would detect this. This forces us to ask:

What Outcome are we looking for?

Theoretically, we’re buying SCA scanners for a few reasons:

1. Compliance dictates we look for CVEs in our packages

2. Compliance wants SBOMs so no one can read them

3. We want to fix exploitable vulnerabilities in third party code that could negatively impact our business

It seems to me that number 3 has led us to miss the mark on evaluating SCA scanners, because we’re including the idea of a “vulnerability” in our assessment criteria. Instead, if we tried “we want to prevent our being exploited by third party code,” we end up prioritizing real security instead of the CVE shakedown.

If you want to prevent being exploited by third party code, then your approach to SCA scanning broadens to being less focused on CVEs, and more towards remediating actual risk. Instead of asking, “how can we stop vulnerabilities?” we need to ask, “how do we stop supply chain attacks?”

What are some different approaches?

Phylum sits neatly in what I’m calling malware focused SCA scanners. Alongside them are Socket and Xygeni. These are tools that primarily focus on looking for actual attacks in your supply chain ecosystem, as opposed to just scanning for CVEs. I hope tools like this can gain adoption, but they face two challenges:

First, many people aren’t aware that there are more valuable results you can get from this approach than by hunting CVEs. Second, the current industry trend is towards ASPM platforms, not best in class point solutions. Xygeni is the only tool I see trying to compete on both fronts - all in one scanning alongside the upstream malware scanning.

Tidelift fits into the “let’s actually fix this crap” category, but with the uniquely ethical approach of helping open source maintainers get paid to deal with it. I would put them alongside Moderne, Grit, and Seal - different technological approaches to the same outcome: actually fixing upstream vulnerabilities.

Oligo and Deepfactor offer a third solution - watching packages at runtime to see if something fishy is going on.

Companies that don’t rely fundamentally on CVE scanning

As I see it, here are the pros and cons for each approach at the moment:

1. When I meet with malware scanner vendors, they’ve made an obvious investment into real security and detection engineering. However, they tend to not have a great user experience (UX) for the CVE based workflows, and generally lack the bells and whistles of the traditional SCA leaders to deal with CVEs. They also have the unfortunate sales disadvantage of not being very shiny - you’re probably not using any active malware packages, but you definitely want their tool if you are!

2. The fixers don’t already have allocated budget to their category, and really require a healthy Dev/Sec relationship to operationalize. You’d think you’re buying a scanner in order to fix the results - but orgs tend never to get to that part, so these tools are unfortunately swimming upstream in getting adoption…for now.

3. Runtime scanners require instrumentation that can be tough to get organizational buy in to implement. It’s a unique solution in that it’s the only thing that could actually stop a zero day with no intervention. The question comes down to if orgs care enough about that to implement an agent.

Predictions on the future

First, CVE scanning can’t, won’t, and shouldn’t go away. CVEs form a bedrock of security by providing common disclosures for exploitable issues. Remediating CVEs absolutely has general value for making you more secure; even if that’s a 1 to 1,000 real fix to false positive ratio. Any product in this category needs CVE scanning as its base.

Second, the future of this space is ASPM and all in one scanning. As valuable as a real security approach to SCA scanning is, the reality is that it’s not enough to sell. I can’t convince CISOs that the pay off to this issue is comparable to the overall value of combining SCA, SAST, IaC, CSPM, SDLC, and Container tools in a single place.

Third, each of these tools is pushing against the tendency to look for biggest impact lowest cost to implement solution. They require the user to understand the up front problem with traditional scanners, and to be committed to actually improving security instead of mindlessly checking the compliance box year over year. Unfortunately, this is a tough sell.

There are a lot of market challenges to selling these platforms; however, if I was an existing ASPM platform, I’d rush to buy or invest in one of these differentiators. In a world where the scanning has become commoditized, any of these three approaches offers real differentiation from the competition. If I was choosing between ASPM providers that all check the same boxes, upstream malware detection would 100% move the needle on going with that vendor. Similarly, if I was in an environment where a zero day supply chain threat would cripple the business, I would absolutely invest in one of these tools.

Short of that, there are opportunities to wrap all of these tools in a “Code Fixer” type of solutions. All of these tools recognize the problem: fixing open source problems is harder than scanning CVE databases. There are two options: either the company is going to offer the patch for you, or they’re going to make it easier to do it yourself. All of these companies have a genuine desire to make open source better, and if enterprises aren’t going to actually pay for any of the code they’re stealing, they could at least use something like Tidelift to make their own lives easier.

Back to the original question: Should supply chain security mean more than CVE scanning and workflows? Absolutely, I’d call it Beyond CVE™ SCA scanning. CVE’s are the floor, not the ceiling.

Latio Updates:

• Added Akto to API security and DAST - Open Source next gen DAST

• Added Tidelift to SCA and Boundary Breakers - Working with open source maintainers to uplift repo health and security

• Added Devici to Boundary Breakers - Threat Modelling collaboration platform

• Added InstaSecure to Cloud Identity - Very unique approach to securing identities by focusing on permissions boundaries rather than endless least privilege tweaking

• Added Phylum to SCA - Great upstream malware detection

• New YouTube video!

Every week I have formal and informal conversations with a lot of vendors. I often have much more to say about them than what fits in my weekly update posts. In order to better talk about some of the trends that I see on a weekly basis, this weekly newsletter will present an unsponsored look at a product from a state of the market perspective. Due to time constraints - this isn’t a full review of the product itself as much as their positioning in the marketplace.

Table of Contents

• Innovation in a Crowded Market - The State of SCA

  • This week, I met with Socket Security.

  • Conclusion

  • Other Updates

Innovation in a Crowded Market - The State of SCA

(Ox also does some stuff that could be considered runtime reachability, but that would make the diagram look weird. Also, Backslash doesn’t do an agent, but does look at runtime deployment context, which doesn’t make them a 1:1 competitor with Oligo and Deepfactor)

To be frank, I often wonder how companies are still get funding to only do SCA scanning. The market is deeply saturated at this point, and while there’s still room for innovation, it’s easy to get buried as “just another open source scanner.” SCA stands for “Software Composition Analysis”, and is the older term for “here’s all the vulnerabilities with your open source packages.” I like it more than general ones like “Supply Chain Security” because there’s a lot more to supply chain security than checking open source versions for vulnerabilities. On the one hand, it’s become trendy to say “SCA scanning is commoditized" because there are so many good open source options available - from Dependency Check to SemGrep. On the other hand, the core problem with these tools is the number of false positives they create compared to how difficult it is to fix them.

I see innovation happening in this category in two opposite directions: one side cares about making the findings more security related and precise. These tools focus on reachability (Endor Labs, Backslash, and SemGrep), malware (Xygeni and Socket), and runtime detection (Oligo and Deepfactor). The other side focuses on improving the fixing process through workflows (Remediation Platforms), fixing it for you (Grit and Seal), and the details of the git workflow for developers (Arnica).

This week, I met with Socket Security.

I wanted to spotlight them because they’re at a lot of these cross-sections. Again, this isn’t sponsored and they don’t know I’m doing this. Socket has the same tradeoffs of many platforms: it’s a good scanner, but the language support is pretty limited (it’s very JS focused, but also supports Python and Go). They’ve created the standard dev PR workflow, but they don’t do reachability analysis. Most interesting to me, they look for malware rather than only CVE’s in the open source packages, although they do detect both. I’m only aware of Xygeni also taking this approach, which I find a lot more focused on actual security than the CVE flooding of most tools.

Some of the Socket Threat Feeds

Tools like Socket really force the customer to ask: why am I looking for an SCA tool? If you’re looking at supply chain security as stopping malware zero days, you’re really limited in your number of options, but Xygeni and Socket both look great. If you don’t go with tools like them that are surfacing zero days directly in product and automated, you’re trusting that the provider you’re using will either detect the zero day on their own, or that the CVE will be published quickly.

While looking for malware as opposed to CVEs is a great approach, this malware workflow doesn’t apply to 95%+ of the typical day to day operation of an SCA scanner - you’re unlikely to ever even see it, so it’s hard to quantify the value of it. Instead, for compliance and less clearly demarked security reasons, most companies are stuck in the sludge of CVEs.

The day-to-day workflow of most SCA scanners is CVE remediation and patching, so should you buy a tool more primarily aimed at that? The trade-off there is that you’re often spinning your wheels and not increasing the actual security posture of your app by that much. Most of these findings are false positives that are only exploitable under specific circumstances, meaning that in theory the malware detection is a more robust approach to take for stopping likely attacks. While in depth reachability analysis is one approach, it’s never going to solve the fundamental problem of having more CVEs than time.

In terms of features, Socket has the one filter you need more than anything: Transitive vs. Direct dependencies. In the below example (from LAST), Google auth gets imported as a result of importing the google-generativeai package. Too many scanners out there would flag me about every vulnerability to exist in google-auth, even though I don’t actually use it here. However, most leading tools in the market now have this basic functionality. The bigger players in this space are more robustly filterable and combine with reachability analysis. The question isn’t just do I import google-auth, it’s if I actually use it anywhere?

Direct vs. Transitive Dependency

I can also appreciate that they have most of the noise generating rules turned off by default. It points to how they’re trying to fix one of the two main problems in this space - finding attacks rather than noise.

Whether a tool like this would interest you or not comes down to how long you can afford to miss a zero day supply chain attack. The bigger providers are doing some of this, but it’s all behind the scenes and you’d have to trust that they’re racing to make a big “Snyk detected a zero day” kind of announcement. I think most companies are okay with that delay, but some will benefit from having detection happen as soon as possible.

A critical caveat here is that while these scanning type of tools can detect zero days better than their alternatives, if you don’t have runtime protection it still requires alerting and patching to fix it after the fact. That’s why for this kind of outcome, I think the runtime approach of DeepFactor and Oligo is more promising if stopping an open source zero day is absolutely mission critical. That’s why Oligo is still my top choice for this category, if you can afford to get an agent deployed.

Oligo, DeepFactor, and Seal are the only vendors I’d feel comfortable saying could (theoretically) stop a zero day open source exploit without you needing to do anything. There are other cool runtime options out there that aren’t focused on this area that might also catch it, but they’re not as explicitly focused on this problem. To be clear, I’m not saying that I think these three vendors are always the best under even most circumstances, only that if stopping a zero day with no intervention is mission critical, they’re the only options.

Conclusion

For all the noise SCA tools generate, most have a fundamental flaw in that they’re lagging indicators of attacks due to their reliance on the CVE ecosystem. Even if many vendors have their own research teams that would theoretically detect some of these exploits, only Xygeni and Socket have uncovered the benefits of putting this directly into the product.

Assessing the time it would take for a vendor to react to a zero day is an almost impossible task, so what’s hard about this pitch is that it relies almost entirely on trust. Do you trust that your existing vendor would publish a zero day response as fast as the automatic detection of a product like Socket?

Other Updates

Latio List v1.6 changes with thoughts are below:

• Added Legit Security to Container Vulnerability, IaC, SCA, Secret Scanning, and SAST

  • Legit is in an interesting place because they went hard into ASPM early on, so focused entirely on SDLC security and pipeline coverage from other tools. They’ve quietly been building out their own versions of these category specific scanners so they can supplement any existing tooling. I take it as validation that my thoughts on ASPM being “buy this tool to secure your application configurations” is correct.

• Added Staris to Pentesting, Code Fixers, SAST, and DAST

  • Staris was the other company I was going to spotlight this week. They’ve built a more robust implementation of LLMs for security than the SAST only providers by wrapping it in the context of pentesting services and having it generate exploits.

• Added MindPoint Group to MDR and Pentest

  • It’s hard to assess service providers in just a call or two, but it sounds like MindPoint tackles more robust projects than most MSSPs by even helping with Terraform and Active Directory rebuild type of projects. They also do auditing, pentesting, SOC, and the more standard suite of MSSP services.

• Added Socket to SCA

As always, you can view the updates at https://list.latio.tech/!

Disclaimer: Gartner has decided to call these vulnerability management platforms ASPM, which you can read my opinion on over here. I call them what they are - remediation platforms, or with even less marketing pizazz, vulnerability management platforms. Why? Because they help manage vulnerabilities and get them fixed. Let’s not make this more confusing than it has to be.

Remediation platforms are the hottest new tool on the block. From Dazz to Opus, and dozens more, the problem has been made crystal clear: there are too many vulns and not enough time.

In this article we’ll do a little bit of an overview of the state of the space, and then cover a critical differentiator emerging in the market.

Table of Contents

• Overview

  • First, remediation platforms.

  • Second, data platforms.

  • Third, workflow builders.

• Emerging Market

Overview

The critical problem with the remediation space in that every pitch sounds exactly the same: we take all of your vulnerabilities, identify the best people to get the tickets, and create workflows to manage it. The problem? That doesn’t actually fix a single finding.

These tools ought to be completely measured on their ability to make fixing vulnerabilities take less time; instead many of them have fallen into the trap of making the prettiest workflow management software they possibly can. At a high level, there are three major buckets of tools:

1. Remediation Helpers

2. Data first platforms

3. Workflow builders

First, remediation platforms.

These are the hottest tools in the market, and the ones that stand out the most to me are Dazz, DevOcean, Silk, and Opus. This bucket of tools are focused on tying together the code to cloud picture for companies. The need is driven by appsec providers being too slow into cloud, and vice versa. None of the legacy code scanners tie the picture together with the elegance of newer ASPMs like Ox or Cycode.

The benefit of these tools is that they give developers almost the amount of context they need to fix something by showing exactly where the vulnerability is getting introduced. They help security teams:

1. Speak developer-ese by showing the application context

2. Point to the right solution at the right place - such as fixing a Dockerfile or a package.json

3. They add a unique value beyond the individual point scanners by showing how dependencies relate to one another

The drawbacks of these tools and what to look for during an assessment are:

1. Testing on your specific environment. This stuff is easy to demo, difficult to execute with accuracy in a customer environment

2. The right context sometimes doesn’t actually make fixing things any faster

3. Since they’re trying to surface the automation, they can sometimes be missing critical data fields from their integrations

Second, data platforms.

This second class of tooling is a great fit for enterprises, because they’re less opinionated about your data and workflows. I put Avalor, Phoenix, and Armorcode in this category. I think of it this way: remediation platforms were created with developers first in mind, while data platforms were created with enterprise security teams first in mind.

I love the elegance of the remediation platform demos; however, FedRAMP has made me painfully aware of the data driven nuance required of many compliance frameworks at an enterprise scale. I absolutely had more fun prioritizing based on asset criticality and dependency trees, but that doesn’t fly in these bigger environments where more complexity is needed.

The benefit of these tools is that they just work. You know it’s going to do the thing you need. The drawback is that you know it’s not going to work auto-magically, and fill you with that new product smell we love so much. It’s going to be a platform for managing work, not a platform to make it go away.

Third, workflow builders.

This class of remediation tools is built first and foremost around the immediate problem: “AHHHH THERE’S SO MANY TICKETS PLEASE HELP ME GET THESE TO THE RIGHT PEOPLE!” To be clear, most platforms sort of does this, but Seemplicity has been the most focused on it. The pros and cons of this category seem pretty obvious, the pro is that workflows are critical to the process, the con is that there’s a lot of data stitching that’s just as important as the workflows.

Emerging Market

As cool as all this stuff is, there’s a new kid on the block, Powered by AI™ (but interestingly enough, not as much as you’d think). I’m launching this on Latio under the Emerging Tools category as “Code Fixers.” These approach the same problem as remediation platforms: there’s too many vulnerabilities and fixing them is too hard, but their approach is driven by creating the code fixes as merge requests for you. The examples in this category are Mobb, Pixee, and Corgea.

At the moment, these platforms are pretty early and limited because they only help with SAST findings, such as: “hey you didn’t parameterize this query, here’s a PR where we did that for you.” That issue really hurts their large market potential compared to the other providers; however, it’s easy to see how this becomes the future of the industry: providing the exact fixes instead of just helping manage tickets around them.

Other examples I’d put in this general category of novel approaches to vulnerability management are Seal Security, Rapidfort, and Chainguard. These providers all similarly focus on remediating vulnerabilities for you instead of just kicking and screaming about how many of them there are - but they’ve done so outside of SAST. If Seal, Chainguard, and Mobb all teamed up, theoretically you’d have auto-remediation for SCA, Container, and SAST findings - which is getting close to the promised land.

I think remediation platforms (or ASPM providers more broadly) would benefit from acquiring some of these GenAI fueled startups, but that’s not before some more years of duking it out first. In sum, this is definitely the market where the rocket fuel is strapped at the moment, but vendors are painfully in need of differentiators to stand out from the noise. And, as I wrote in the ASPM post, I think the real long term winner is the all in one scanning tool; why buy a workflow for your scanner instead of a scanner with a workflow?

Every ASPM provider provides some combination of the above capabilities. 

Application Security Posture Management (ASPM) is the latest Gartner fueled buzzword to take over cybersecurity, but no one knows exactly what it is. On the one hand, it’s a fancy name for vulnerability management: helping ingest and prioritize vulnerabilities from third party tools. On the other hand, it’s a one stop shop for code scanning. In this article I argue that the only meaningful ASPM is an all in one application security scanning tool.

Table of Contents

• Why would you want an ASPM?

• Why Disagree with Gartner?

  • CSPM and ASPM, towards an SPM

• Defining The Perfect ASPM

  • Some Examples

  • Musings About the Future

Why would you want an ASPM?

DevSecOps is the only way to ship products quickly while staying secure and compliant. If you care about protecting customer data, and the consumer trust (revenue) tied to that, you need to scan your application for misconfigurations.

I have the benefit of being new to application security: I’m not used to long scan times, grumpy security buzzkills, and quarterly patch cycles. Instead, I have the expectation of scanning in the pipeline with immediate results. These results should provide clear guidance on how to fix things, and be developer friendly. Too many application security professionals are reduced to being project managers without any authority, as they spend their days assigning tickets to different development teams praying that a developer fixes something.

As DevSecOps toolings took over the market, it became apparent that there are too many point solutions.

At a high level, these are the major categories of scanning possibilities:

1. SDLC (Scanning your Git settings for things like protected branches and CI settings)

2. SCA (Open Source Dependencies)

3. SAST (Scanning the code for exploitation vulnerabilities)

4. IaC (Scanning at least Terraform, but also K8s deployments)

5. Container scanning (Dockerfiles and runtime)

6. Secret Scanning

7. DAST (Scanning the running code)

8. CSPM (Scanning the Cloud environment)

While excellent point solutions exist in each of these categories, businesses can’t manage twice the number of tools as they have security personnel, each of which are triggering thousands of findings when they’re deployed. For very large enterprises, where most application security happens, they have thousands of repos that need all of these tools orchestrated, some open source and some paid.

Vulnerability overload is why the Application Security Orchestration and Correlation (ASOC) category was created - to help you manage all these tools across all of your code base. While a rather meaningless category name (why is this different from Vulnerability Management?), at least ASOC made sense for what it was; ASPM however, is a different beast.

Ox.Security has a great visualization of code to cloud scanning

Why Disagree with Gartner?

ASOC tools were an attempt to provide correlation between all of your tools into a single dashboard; however, Snyk exploded in growth because they solved tool sprawl by providing all of the tools themselves. Snyk was the first major provider I was aware of who could offer SCA, SAST, IaC, and Container all in a single platform - and that proved to be exponentially more valuable than buying four separate tools, and then a fifth to orchestrate everything. First, Snyk’s partnership with StackHawk showed that they understood the problem of 8 in 1 security scanning and sought to fill the gaps with third parties. With Snyk Cloud, I was optimistic they’d be expanding from providing 4/8 categories of scanning to all 8; however, Snyk has since totally stalled out, creating a big market opportunity for churn.

Many other providers have built scattered offerings to fill the Snyk sized hole in my heart, by combining open source offerings, with the ability to ingest from other scanners.

Gartner reacted to all these tools by creating ASPM and defining it as:

Unfortunately, due to this category existing formerly as ASOC, they’ve missed what’s really happening: the total consolidation of scanning tools into a single platform. ASPM only needs to exist because you’re using so many different tools, which is a problem fundamentally unique to the largest enterprises - where there are so many old bespoke tools floating around that visibility matters to this extent. The vast majority of companies just look at all this complexity and think to themselves, “just give me the thing I need to scan all this crap with.” The answer to that problem is the tool that should win this market.

I don’t know a single security professional who wouldn’t be happy to drop all their old tools for a single better one if they didn’t sacrifice useful features in the process.

CSPM and ASPM, towards an SPM

An analogy to Wiz and CSPM is appropriate. The early cloud days were filled with the same complexity that ASPM now finds itself: there were many security point solutions for on premise environments that attempted to shift to the cloud. Would Wiz have risen to lead CSPM if they were simply a “risk management” tool that ingested findings from elsewhere and helped you prioritize? No. Wiz won the market by providing unique, all in one insights across cloud applications. To this day, they’re handily the most holistic provider because they didn’t stop themselves with superficial cloud API scanning and consolidating via partnerships; instead they pushed snapshot scanning to its limits. 

In my mind, there’s no reason to treat ASPM separately than CSPM - CSPM gives businesses all in one visibility and alerting across their cloud, ASPM should do the same with your code. The elephant in the room is that these things are converging, and CSPM is a feature of ASPM - because businesses have realized that their cloud security is fundamentally about their product security. This is why the race is on between CNAPP shifting left, and ASPM shifting right - who’s going to be the first to provide the all in one scanning solution, the Security Posture Management (SPM) solution?

Defining The Perfect ASPM

When defining categories, I’m helped by having a minimal definition next to a complete definition. The market is new enough that the “fullness of ASPM” (if you know Plato, we could say the form of ASPM rather than its shadows) does not exist yet, but several companies are working on it. 

Here’s what the complete ASPM would offer:

1. Tells the story of how your code reaches production

   1. This person pushed this code to be compiled into this binary with these libraries onto this docker image deployed in this cluster on this cloud.

   2. These vulnerabilities would be fixed by changing this line of code

2. 8 in 1 scanning coverage - SDLC, SCA, SAST, IaC, Container Scanning, Secret Scanning, DAST, CSPM

   1. Bespoke best in class features wherever possible (reachability, auto-fixes, base image detection, pre-commit hooks), open source as a backup.

   2. “Pipeline Less” (i.e. no Docker image) > Run it in your own pipeline.

   3. Whether your solution is proprietary or not doesn’t matter as much as the results.

3. Rich workflow building, offering complete flexibility alongside strong predefined workflows that are easy to apply

   1. If a new vuln shows up, slack the developer, they can choose to create a ticket or fix it now, security can ping them again if not resolved within 30 days

   2. Too many tools just offer flexibility, but miss suggested workflows that are perfect for 90% of use cases. Users aren’t primarily looking for a workflow GUI, they’re looking for a sensible outcome.

4. Integrates with other tools and provides unique value on top of the third party scanner data

   1. Pulls in vulnerabilities from other platforms, but enriches the findings with greater application context.

   2. Really a feature just for enterprises, because over time you replace their old tools with your own

5. Is fix oriented

   1. Tells teams exactly what lines of code to change, how to fix them, and the number of vulnerabilities that would be remediated if that change was applied.

Here’s what I’m proposing as the definition of ASPM:

Defining the Minimum ASPM

Here’s the minimal required to be listed in the ASPM category:

1. At least 2/8 of the scanners provided directly by you

   1. The heart of ASPM is showing cross scanning value. You can’t show cross tool value if you only provide one kind of scanning

   2. Open source tools are fine

   3. If you don’t do this, you’re a vulnerability management provider, there’s no reason to call it anything else

2. The ability to integrate into at least SCA & SAST

3. The ability to create some kind of workflow

Some Examples

1. The most common combination is SCA, SAST, and Secrets: Oxeye, Arnica, Semgrep, and Cycode all provide these. This is the most common combination of tools because there are strong open source options. Evaluation is tricky because each of these providers provide these functions with drastically different levels of maturity.

2. Everyone has a niche, to name a few: Oxeye and Apiiro are really good at runtime context, Arnica is really good at native workflows and user context, Cycode is really good at querying your pipeline, Legit Security is really good at SDLC coverage.

3. Ox gets me the most excited, not because any particular one of their tools works exceptionally well, but because they’re the only ASPM I see that I could truly say “throw everything else out and just use this.”

Musings About the Future

1. Vulnerability management tools aren’t bad. Just because it’s not as exciting or “revolutionary” as an all in one ASPM tool doesn’t mean it’s not going to make a ton of money solving the problems of here and now. If the mainframe is still around, so will Checkmarx and Fortify in 20 years - and you’re going to want those vulns to go somewhere else.

2. Who will win the race for complete coverage? The runtime providers shifting left or the code scanners shifting right? On the one hand, it’s easier for code scanning tools to add runtime context than for runtime tools to add code context. On the other hand, the runtime providers have more money and motivation. With the death of Snyk Cloud, I don’t see many ASPM providers racing for runtime.

3. Developer adoption remains the goal - I don’t see developers installing a Crowdstrike plugin anytime soon

4. The most exciting acquisition is Wiz’s acquisition of Raftt, because Raftt wasn’t a security tool. This promises the ability to offer something devs actually want.

5. Every ASPM vendor I’ve met with has something unique about their platform, I wouldn’t be surprised to see some consolidation so they can have larger shared offerings.

6. Aikido targeting startups is brilliant, because most AppSec startups are too focused on enterprise and new sales will show more value than the integration use case.

7. An inconvenient hole in all of this are host based vulnerabilities. While we’d all like to pretend that we live in a container native world, Linux hosts are relegated to legacy providers - but most large enterprises still have them around.

8. I have a lingering thought that if runtime protection gets good enough, do you even really need an ASPM? This is why Oligo, Contrast, Sysdig, and Deepfactor are cool.

The future of ASPM is the most exciting place in security because it’s showing a glimpse of a future where all vulnerabilities are discovered and remediated in one place.

As a reminder, nothing in this newsletter is sponsored, made with AI, or generating any revenue for me! If you’d like to help out, subscribe to the newsletter, and let these companies know if you found them because of me. If you’re interested in help with tool selection, contact me at james@latio.tech

Kubernetes Security Scanning…and more?

Kubernetes security and visibility lie at the heart of most cloud security startup innovations. Because the field is so complex and growing by the day, it’s easy to lose track of who’s really doing what, and which products merely exist as checkboxes versus providing real value.

This week, we dive deep on ARMO, one of the original companies in the space who has invested deeply into open source tooling, with their cloud platform layered on top. In this deep dive, we take a look at Armo’s history, platform, ideal use cases, pros, and cons.

History

ARMO was founded in Israel in 2019. Their first public seed round was $3.5 million in 2021, led by Pitango VC, followed by a $30 million series A in 2022 led by Tiger Global Management. They have 40 employees, and have a deep commitment to open source kubernetes security. The first commit to their public repository, Kubescape, was in 2021 and Kubescape has accrued nearly 9,000 stars on GitHub.

I was first exposed to Kubescape in the early days of exploring Kubernetes security. Their quick and lightweight scanner was an easy way for security engineers, who usually don’t have much Kubernetes experience, to begin wrapping their heads around what sort of cluster misconfigurations can exist and begin conversations with their DevOps teams about how to fix them.

Due to their open source nature and lightweight scanning options, ARMO has always done a great job at living at the intersection of security and DevOps. In my experience as a security engineer, the hardest part of Cloud Security is getting this conversation started, and ARMO has always provided a great gateway to that conversation.

Platform

The ARMO Platform has evolved into three distinct sections: compliance/vulnerability scanning the cluster itself, surfacing vulnerabilities in the images running inside the cluster, and visualizing kubernetes roles & service accounts.

Compliance Scanning

The heart of ARMO’s platform is their compliance scanning, which has the best rules I’ve seen for scanning for cluster misconfigurations. They do an excellent job of balancing being quick to deploy with providing deeper analysis than most tools by really breaking apart all of the resources that exist inside the cluster.

As far as rules go, they attempt to map k8s controls across compliance frameworks like CIS benchmarks, MITRE, and NSA controls alongside their own best practices to provide meaningful insights to DevOps and Security practitioners alike. This creates reasons for DevOps teams to investigate the platform themselves, rather than being solely a security tool. An example of this crossover is alerting on lack of memory and CPU limits, alongside over provisioned Kubernetes service accounts.

This data exists within the open source tool, but the extra insight granted by the platform comes in the form of fix analysis, highlighting changes in the yaml that must take place.

While their categorization of alerts is good, they suffer from typical issues in this space when it comes to medium and low alerts. For example, you definitely should implement kubernetes network policies for security, but resolving this one medium alert could easily take an entire quarter to implement properly for larger organizations. Their docs provide a ton of value in giving explanations for their rules, but lack larger scale guidance for security teams trying to figure out how to gauge the necessity of dropping a giant project in DevOps laps. In other words, don’t expect the platform to fix things for you without doing some project work yourself, although the platform helps by providing fixes inline to the yamls.

Image Vulnerability Scanning

ARMO’s evolution into Image scanning is newer, and its current state would serve a better “check the box” functionality than anything actionable; however, they currently provide and are continuing to develop a few areas that help the feature stand out from other providers.

Let’s start with what they do well: categorizing CVEs based on the context of the running cluster. Negligible, fixable, and RCE (remote code execution) are all critical contexts for navigating the CVE ocean that tools like this tend to uncover. The ARMO platform does a good job surfacing the vulnerabilities that are truly fixable and the most likely to get you into trouble. Like some other tools in this space, they show you the libraries that are actually running in order to help you prioritize as well.

With those positives listed, there are many areas of growth for this feature, which many larger vendors like Prisma Cloud or Sysdig are not themselves immune to:

1. There is no base image detection to tell you if the vulnerabilities are coming from your base image or something your adding to your Dockerfile - and this functionality wouldn’t exist in pipeline to tell you exactly where a vuln is coming from.

2. There is nothing showing the layers of the Docker image to see where your vulnerability is getting introduced

3. There is no guidance on how to actually go about remediating, such as installing custom packages versus just running an apt upgrade

4. Alerts exist for tools that you really can do nothing about, such as the AWS kube-system images

5. The workflow management is very basic, offering an easy ignore and exports to Jira

All in all, this is a great expansion into this category from ARMO, but can’t compete on its own against better dedicated providers; however, the state of this category from the larger CNAPP providers is also lacking. This is why Remediation Platforms have been created. In short, not the best for large scale remediation across all your images, but great at providing a hit list of the vulns that are the most likely to get you in troble.

RBAC Visualizer

More providers in this space are realizing the complexity of Kubernetes authorization and identity management. Between OIDC plugins, AWS plugins, SA accounts and permissions, and more, there are usually a ton of identities in kubernetes spaces that go overlooked.

Providing visualization and a query mechanism are great first steps in this area, but require the user to know what they’re looking for. For example, querying for SA accounts with create role permissions returned blank, but SA with * returned the role I was looking for.

The true frontier of this technology is mapping alerts and priorities based on these queries and the context in which they’re running. An SA account with admin permissions attached to a pod for example is a large security issue, whereas the kubelet being able to access nodes is irrelevant. These are all features their team showed me are being worked on, and I’m excited about the future of the platform here.

Ideal Use Cases

1. A security team getting started with Kubernetes security.

This use case follows the ideal flow for Armo - a security team can easily clone and run kubescape, and begin conversations with their DevOps team around findings. Assuming positive results, they can then investigate the paid platform and using this to fill the kubernetes visibility gap.

2. A DevOps team looking to shore up their security posture

Many startups are plagued by sudden compliance and security concerns, and the Armo platform provides a great on ramp for them dipping their feet into security. DevOps teams I’ve worked with care about security, but don’t know how to prioritize or get started, and ARMO is great for diving in.

3. A larger org with legacy tooling looking to shore up kubernetes security

Big players like CrowdStrike, Splunk, and IBM have provided tools to security teams that have been slow to surface evolving kubernetes guidelines for teams. For companies that are already heavily invested into these larger runtime providers, a provider like Armo can fill a more specific gap than something like Wiz or Sysdig which are covering much larger areas.

Pros:

1. Fast to deploy

2. Open source foundation

3. Narrow use case executed very well

4. DevOps and Security friendly

5. Actionable compliance scanning

6. Pricing is fair compared to more holistic providers

Cons:

1. Image scanning is not as actionable as it needs to be

2. Can generate noise at medium and below alerts

3. Functionality is mimicked elsewhere in similar providers

The Future of Armo

Like other providers in this space, the future of Armo is heavily reliant on how their kubernetes protection differentiates from consolidation providers. With eBPF exploding, there is also a question of if configuration scanning alone is enough without additional runtime protection against an actual exploit.

Because of their investment into open source technology, the future is bright for ARMO as more orgs adopt kubernetes and look to get a handle on their security - there simply is not a better tool than kubescape to get started securing your cluster. It remains to be seen if configuration scanning alone will provide enough value to organizations to not be consolidated into larger platforms. As their image scanning and RBAC visualization improve, they can remain a leader in the kubernetes configuration/vulnerability category, but would need large platform investments to get more into the runtime space.

At the end of the day, kubescape is the best open source configuration scanner out there - so there will always be a market for their growing future. There’s no other platform I’d use to get started securing my clusters.

See the video below for more thoughts and testing of different scanners:

Latio’s OWASP Conference Vendor Awards

The Global OWASP Conference in Washington DC was a ton of fun, getting to hear from many in the industry facing the same application security challenges as one another. The major theme was that AppSec is for everyone - everything from better products to LLMs is allowing smaller teams to have larger impacts on security beyond traditional enterprises. While the industry, as a whole, still seemed largely enterprise driven, there was a real desire for openness and sharing knowledge with newer teams.

I met with about 40 vendors over the course of 1.5 days, and here are some of my thoughts.

Disclaimer: The opinions expressed in this review are my own and based on my personal experiences and observations. I have made every effort to ensure the accuracy of the information provided, but I cannot guarantee its accuracy or completeness. The information is presented without warranty, and I encourage readers to conduct their own research and draw their own conclusions. I was not paid for any of this content and do not own assets in any of the companies mentioned.

Buzzword of the Year: ASPM

Runner Up: CoPilot

Suddenly, everyone this year is an ASPM. No longer is it enough to be a best in class SAST or SCA tool, instead teams are looking to centralize all of their scanning in a single place. Some tools like JIT.io and Legit Security are heavily focused in on getting a sense of pipeline coverage based on tool sprawl, others like Arnica and Cycode are displacing with their own scanning mechanisms instead. The most ambitious (like our best of show winner below) did both.

All in all, it’s clear that these tools are addressing the reality that in the war against vulnerabilities, the vulnerabilities are winning.

Most Innovative Startup: Dry Run Security

Runner Up: Riscosity

While there were plenty of “CoPilots” on the show floor, only Dry Run seemed to be using LLMs in a truly helpful way. I learned a lot about what ChatGPT is good at in my comparison of Snyk and ChatGPT for SAST, and Dry Run seemed to be capitalizing on exactly the right thing: finding context for complex systems to raise the right alerts to the right people. Over the years I’ve built numerous custom scripts to monitor the files that really matter, because often, they aren’t detected at all by SAST tools (such as config files for Django or Kong) - Dry Run seemed to really fix that. Beyond their current implementations, I’m excited about the potential of their workflow and bringing LLM into your pipeline.

Riscosity is also worth mentioning - I need to get a hands on to validate the claim, but crawling your code for third party data sending and combining that with egress proxying is a truly powerful combination for getting insight into where your data is actually going.

OK Boomer Award: Prisma Cloud

Runner Up: VeraCode

While in one sense I was surprised to see Prisma Cloud focusing on application security, they’re betting big on their Darwin platform as a “code to cloud” all in one journey. I’m…not; but that didn’t stop me from grabbing some socks. The pivot is smart for lowering customer churn, but not focused enough to be a challenge to innovators.

Most Runtime-y: Oligo Security

Runner Up: Oxeye, DeepFactor

While there were a few vendors at the show doing “runtime insights,” only Oligo was bold enough to slap the grim reaper on a shirt and call everything else legacy. Oligo’s unwavering commitment to runtime application security as “AppSec 2.0” is what I love to see. I’m a results oriented, DevOps guy at heart, so I have to admit that I’m biased. At the end of the day, what’s more important, seeing a vulnerability, or stopping it? Only Oligo is going from “Runtime Prioritization” to “Runtime Stopping.”

That being said, prioritization wise, Deepfactor seems right up there with Oligo. I appreciated the unique runtime take of Oxeye as well, using runtime insights to make a map of the application with insights very similar to what Bionic was working on (before the Sith Lords took them over).

Best API Security: Impart Security

Runner Up: Pangea

There’s a lot of buzz right now trying to figure out the future of API security. On the one hand, a lot of WAF providers have caught up to provide API level protections, and it’s a lot easier to extend an existing tool than implement a new one. On the other, there’s a lot of power that can be found by extending API detection into code bases and gaining general visibility into your API’s and what they’re doing in action. Impart’s combination of accurate discovery with anomaly detection made them stand out in a crowded space filled with other great tools.

Runner up Pangea was only the runner up because their service doesn’t lend well to a demo environment, but if it works cleanly it’s an elegant solution to the same problem. The essentially work as a CDN for your APIs, and automate their protection through their secure API delivery and offering services like aliasing and detection that can otherwise be hard to achieve.

Best AppSec Advocate: Tanya Janca

While the crowd certainly had plenty of VP’s of marketing, community managers, etc. no single person had a better community effect than Tanya. She was thoroughly dedicated all weekend - from speaking at ThreatModCon to going to the vendor events afterwards, Tanya’s passion for AppSec is as genuine as it is nerdy and certainly worth following on Twitter and Linkedin!

Biggest Presence: Arnica

Runner Up: Semgrep

Arnica had the premium booth in the premium spot, and went all out with everything from popcorn to donuts. More importantly, no one was more excited about their own work than Nir Valtman at Arnica. I went into our demo with my typical skepticism of the “ASPM” pitch, with “workflow management” and “too much noise” front and center, but Nir turned me, and many others, into Arnica believers at the conference.

Arnica is boldly not trying to just integrate with the big players like Snyk and Semgrep, but displace them entirely with scanning that is ultimately much more remediation focused than their competitors. A small but impressive example was the workflow for fixing secrets - anyone who’s tried using the BFG Repo Cleaner can attest to how hard it can be to scale to an organization. Arnica instead elegantly opens a PR that cleans up the commit history and can be merged directly into the code to remediate the issue, all through Slack and Jira workflows. While other vendors may offer better secret scanning in certain ways - Arnica’s focus was on remediation, which is the more challenging problem. Throughout the product, from SAST to SCA, there was a laser focus on making the developer experience seamless and simple.

Semgrep also had a strong presence at the conference, both in terms of attendees and events - it’s no doubt they’re busy taking a bite out of Snyk, and their open source engine is powering half of the other tools on the floor.

Biggest Absence: DAST

Runner Up: Kubernetes Security

It’s regrettable that the sentiment “DAST is dead” has gained traction in the AppSec community. Before I met StackHawk, I would’ve easily agreed with this opinion - the legacy vendors truly suck to use in this area. However, I think the industry has largely missed that good DAST is essential to validating your findings, and their only frustration is how separate the DAST and SAST experiences can be. StackHawk is majorly differentiated by reading your API config files, and then scanning against those with pointed injections that actually bring meaningful detection. I was happy to see that Oxeye had a similar commitment to DAST as a validation method.

Similarly, Besides Jimmy Mesta’s talk on Kubernetes security, very few vendors were represented who focused on kubernetes context. It’s a shame that more appsec vendors aren’t thinking of IaC and kubernetes context as much, but I think in large part the industry, as a whole, is starting to recognize its significance. Additionally, many vendors were no doubt saving their budget for Kubecon.

Talk I Enjoyed the Most: Jimmy Mesta - Kubernetes Security Top 10

While there were many talks I enjoyed, I love two things: talks that dive into detail, and talks that cover a lot of ground. Jimmy gave an awesome overview of the Kubernetes Top 10, drawing from hands on experience from what they’ve seen at KSOC combined with his own experience building the Top 10.

Best in Show: Ox Security

Runner Up: Arnica

Ox Security blew my freaking mind. I’m generally skeptical of vendor claims, but optimistic of what they’re trying to accomplish in focused use cases. My first thoughts are “how are they integrating, and therefore, what would they miss?” followed by, “what does the actual workflow look like?” Ox Security seemed well poised for that: they were tucked into the back corner of the convention hall and their dashboard seemed to cover everything:

You could bring your own vendor or use theirs, they covered static analysis, IaC, and container scanning all the way out to production. I thought there was no way they can trace container scanning from code to production, alongside static analysis and meaningful workflow building. But every step of the way, Neatsun’s only answer was “yes we do that” as he showed me a live demo of them having the essential detail or piece of the puzzle.

Before I left, my only comments were, “How much did you raise?” followed by, “just try to remember me when you’re up as the next Wiz.” If you’re looking for your next application security tool, I couldn’t find a reason to say no to Ox.

Learn more about runtime protection from Spyderbat: their history, platform, use cases, pros, and cons. As always, nothing in this post is sponsored or AI generated!

Overview

Cloud configuration and vulnerability scanning were the first frontier of cloud native security startups for a reason: frankly, it was easy. Open source projects like CloudQuery, ScoutSuite, and others were copied with only a few weeks worth of work, and then the Cloud APIs scanned for “misconfigurations.”

Drowning in alerts, many companies have started realizing the difficulty of operationalizing this data without context, and ultimately that runtime protection is where the rubber meets the road for defense. No amount of vulnerability scanning can prevent zero days, missed endpoints, or burn down their own backlogs. Whether it’s runtime context informing the configuration scanning, or runtime defense providing complete prevention, runtime has proven to be the next frontier of cloud protection.

This week, we dive deep on Spyderbat, one of the first companies to invest heavily into eBPF tooling that has since expanded rapidly into K8s and cloud runtime protection. We’ll take a look at Spyderbat’s history, platform, ideal use cases, pros, and cons.

History

Spyderbat was founded in 2019 in Austin Texas, raised a 4.2 million dollar seed round in 2020, and in 2022 raised a 10 million dollar series A. Their early differentiator was visualizing process trees on Linux systems to enable easier investigations for security teams. At the time, the major EDR players were far behind on Linux protection, and this is where Spyderbat excelled.

Spyderbat has continued to focus on runtime insights, but as the major players have slowly added in attack graphs and expanded container support, Spyderbat differentiated through two factors: clearly mapping attacker sessions and expanding into kubernetes protections.

What’s most remarkable about Spyderbat has been their continued innovation with a team of only 25 employees. From meeting with them over the last month, they’re a highly technical team that isn’t afraid to push the boundaries of runtime detection using the immense event data at their disposal. When the product manager and sales team can talk in depth about kubernetes configuration and telemetry data, you have a team that’s more committed to solving technical challenges than finding the perfect “GTM motion” or “market positioning.”

Platform

The Spyderbat platform can be separated into four primary features: the first, investigate, is the historical core of the product. The other three are newer: Kubernetes (a view of alerts tied to containers), Spydertop (shows process hardware utilization), and Guardian (preventative process and network configurations). Each of the newer features offer unique value propositions that show Spyderbat’s expansion into kubernetes workloads.

Investigate

The core workflow of the platform is creating investigations out of “Spydertraces” - rolled up alerts of potentially malicious activity. Spydertraces are triggered by suspicious actions, such as a root shell or sudo command, and roll up the rest of the historical session under them. This is the key noise reduction and insight provided over other EDR vendors - instead of getting a bunch of alerts and trying to piece together what happened with more granular searches, the platform is doing the rollup for you.

Example Spydertraces - the suspicious command rolls up all correlated alerts

The basic Spydertrace rollup offers a ton of nice features: showing if a session is still open, how long it lasted for, and the process tree of what happened. However, things quickly got complicated when trying to expand beyond this: “data layers” can be added in to show additional context, and searches run across the data provided via eBPF.

Data layers are Spyderbat’s concept of showing multiple searches together visually

Overall, the Investigation part of the platform offers the core value proposition of next generation EDR - empowering teams with relevant data to quickly assess threats. Spydertraces accurately reflected attacks that happened, but layering in additional data got just as confusing as it is elsewhere.

Kubernetes

Kubernetes extends the investigation view into a visualization for kubernetes clusters. Most EDR agents are atrocious at accomplishing this piece of modern protection: Linux host alerts are absolutely useless without relevant cluster context. Spyderbat’s visualization of K8s is one of the most useful I’ve seen in that it:

• Shows network traffic from the containers

• Shows the services alongside the pods

• Shows the containers underneath the pods

Visualization of a K8s cluster - you can imagine this gets noisy in large environments

This piece of the platform does a great job visualizing the alerts; however, it is still confusing when the platform will be taking you to this view vs. the investigate view. Furthermore, the investigate view can occasionally show logs from the point of view of the root node rather than the container itself.

Example of investigation showing the node view rather than the cluster view, leading to confusion, especially for users not familiar with what might be happening

Spydertop

The Spydertop functionality offers something for DevOps and SRE teams to get value out of the platform: seeing the process utilization of what’s running, along with network and disk traffic. An additional value layer is seeing this historically, being able to troubleshoot utilization issues during load testing. A lot of the time, the SRE team is separated from the development team and has very little visibility into what’s running inside the container itself. From their perspective, if the container is running, then there are no issues.

Example of a python webapp process

Spydertop helps as a quick and basic way to see what might be happening inside the container. While DataDog, Grafana, etc. offer much more robust telemetry than this, there’s a value in the simplicity of seeing historical data from a process point of view rather than pivoting through graphs of data. This can be especially useful for security teams, as understanding the runtime user of a process can often be challenging.

Ability to sort processes and utilization by namespace

Guardian

Guardian is the latest feature within the Spyderbat platform, and it offers a peak at what I believe is the future of kubernetes security. Network Security Policies and Process level allow lists have long been a potential feature of Kubernetes platforms; however, almost no organizations are mature enough to have robust declarations of allowable network and process actions within their containers. The future of this space will be defined by companies that make implementing these things automatic and safe.

Example of a Guardian Policy in the GUI

Because of their access to the runtime data, Spyderbat has a unique ability to generate these policies based on the actual runtime actions of the processes rather than trying to hypothesize from the code what they will do. Theoretically, one could leave a policy running in audit mode for a day or so at a time, and then elevate that policy to preventative mode for each new deployment. Similar actions could be taken by generating the policy based on actions in staging, and then enforcing it in production.

Implementing these protections would still be a challenge: Spyderbat offers a useful CLI interface to script policy generation and changes, but there’s a lot that can potentially go wrong when implementing something like this. All in all this is still a nerdy problem to solve, but Spyderbat promises to make the impossible achievable through the runtime policy building.

Ideal Use Cases

1. DevOps minded security teams with the freedom to invest in container and linux runtime

Spyderbat is one of very few options available to technical security teams hoping to level up their runtime security in kubernetes environments. The challenge will always be that this requires a level of visibility and sophistication that many teams don’t have, as they’re struggling to manage the deluge of alerts from their other tooling. That being said, meaningful consolidation here can mean reducing the investment in other tools as they become unnecessary. Potential cost savings can be achieved by moving from expensive providers who often overcharge for container agents.

2. Security teams frustrated with their EDR performance in cloud and container environments

As someone who has managed and deployed classic EDR solutions into containers, words cannot describe the frustration and lack of insights they provide. Often, these agents serve as mere fodder for renewal contracts without generating any meaningful alerts. They waste a ton of analyst time with useless data, and waste a ton of engineering time with weird behavior and the need for custom rules. Spyderbat also requires lower compute overhead than other agents.

3. SRE teams looking to shore up their security and gain visibility into processes

SRE teams who care about the security of their running workloads can find a friend in Spyderbat’s Spydertop feature. In my days working closely with SRE teams, one of our constant areas of confusion on incident response calls was deciphering what had happened to a pod to make it crash. Was it truly an attack? Did a process run out of control? Usually, this meant correlating SIEM logs against DataDog just to get a basic picture of what happened.

4. Large enterprises with high sensitivity data scoped to specific environments

If your enterprise has highly sensitive environments, it can be worth implementing the Guardian feature to gain the strictest visibility and guidelines around the workloads.

4. Security teams looking for linux EDR

Beyond containers, Spyderbat has been doing Linux detection longer, and it’s arguably much more mature in this area. When it comes to Linux protection alone, I can’t think of an EDR provider I’d rather be using (when it comes to containers, my opinion here is more situational).

When to Avoid

1. You’re already overwhelmed by your existing alerts and tooling, and getting a handle on kubernetes seems like a distant dream. In this case, adding more alerts will never be an answer unless you can use Spyderbat to remove noise from other existing detections.

2. Lack of containerized or linux workloads

3. Lack of SRE security champions or skill gaps on your existing security team for kubernetes

4. Lack of existing visibility into where your container workloads are and their deployment flows

5. Analysts are unprepared for this level of alerting and your more sophisticated teams are already overwhelmed. Getting your analysts used to the platform will require some level of kubernetes familiarity or training if they don’t already have it.

Pros & Cons

Pros:

1. Rich runtime alert data with process and network visibility

2. Spydertraces provide real time insights into activity into your cluster

3. Guardian offers a unique view to the future of preventative security

4. API driven platform that’s able to integrate with a ton of telemetry providers

5. Kubernetes view provides great visibility into what your workloads are actually doing

Cons:

1. Dashboard UI is built entirely around searches, leading to some confusing use cases, workflows, and data visualization

2. Kubernetes and Linux host views can sometimes collide and cause confusion

3. No FIM or Malware scanning

4. Requires other tooling for general cloud visibility outside of the workloads

5. Alerts require a moderate level of technical kubernetes experience to decipher

Checkout the video for more!