Margin of Safety #30: Autonomous Remediation

We have seen several players here. Some of our thoughts below as there is some understandable confusion in the space.

Autonomous Remediation – Market Map

Problem

• Companies get their messaging mixed up. Do they sell to security or IT? Does the product cover first party code or third party code (or first party code using third party code, like Python libraries)?
• As such, investors are too easily confused too.

Our Key Takeaways

1. Gen 1.0 were scanners. Security teams simply weren’t aware of all the vulnerabilities in their code base or infrastructure. However, scanners got too noisy and provided way too many vulnerabilities for anyone to handle. Hence, Gen 2.0 companies were born and these companies provided context and prioritization. The caveat here is that companies here quickly became a ‘nice to have’ product, not a ‘must have’. Gen 3.0 companies (in the market map above) here actually fix vulnerabilities, which pushes them closer to ‘immediate ROI’ and ‘must have’
2. Anyone truly fixing third party code needs to think about the high volumes of third party code that are used as dependencies in first party code – this is especially timely given the recent security nightmares around node.js.
3. Ownership lines can be blurry between engineering and DevOps, but we still believe in having an opinion about the primary user for a tool! This may change over time, but better to have and evolve a thesis than to have no clue who the user is.
4. There are companies that address the problem by layering prompt engineering + LLM on top of Gen 1.0 scanners. These likely will not become the solution buyers want to buy – we think good remediation needs to be aware of an organization’s infrastructure (because how else can you understand risk?) and also its procedures (because how else can you avoid causing change-chaos?). And even if they do, they have the problem that they’re basically thin ChatGPT wrappers.
5. Companies and buyers need to focus in on an initial use case that caters to a focused ICP. We are generally skeptical when early-stage companies say “we can address vulnerabilities to IT and Dev AND security teams, and our scope includes your code, other people’s code and your entire infrastructure.” Fixing everything is a great long term vision, but we think successful teams often start with a single excellent wedge.
6. The closer you get to security for vibe coding, the more existential threat and risk we see as Claude Code or Cursor improves on security and code quality. We don’t think these tools will ever be perfect, but we also think that:

• Historically, most IDE or developer tooling spend has been from businesses
• If that trend continues, it will be existential for the new wave of tools that their quality be high enough for the average business to accept them. We expect a market for companies with significantly above-average security needs to further improve output quality, but we’re still on the fence about the overall market size.

7. We think great solutions in this space will be able to articulate a specific (and singular) buyer and also show not just how they’re driving outcomes beyond prioritization but *also* specifically aligning to the sorts of CVEs that drive compromise.

Please reach out if you are building in this space and we haven’t met with you yet. I believe we have fairly differentiated views vs the average crowd and we have not yet made a bet in the space yet. We’re at kshih@forgepointcap.com or jpark@forgepointcap.com

This blog is also published on Margin of Safety, Jimmy and Kathryn’s Substack, as they research the practical sides of security + AI so you don’t have to.