Over the next few years, several existing and emerging application security capabilities will converge into a single category: AI Code Security. This new category will be designed by a set of technologies that will define the future of application security.

This category is future-oriented: no single vendor does all of it today, but everyone is building towards it. AI code generation represents a third wave of development workflows - from waterfall to agile to AI-driven - and every major shift in how developers work creates an opportunity to reinvent how security is delivered. The outcomes stay the same: secure code and patching, but the workflows and underlying technologies change completely.

What is AI Code Security

AI Code Security is a category for solutions that provide AI coding agents with tailored security and business context to generate secure code, while giving security teams visibility, findings, and guardrails across their code base. The category will combine several emerging products: continuous threat modeling and design review, developer MDM, AI code review, AI SAST, and AI pentesting.

Rather than being rooted in a fear of AI generated code, this category takes advantage of the opportunities AI presents, completing the vision of shift left by automatically remediating vulnerabilities while shipping more secure code.

The Current Approach Won’t Scale

Current application security scanning platforms have focused on building scanners that can run in the pipeline, and provide feedback to developers as quickly as possible. These platforms enabled the “shift left movement” by promising to stop vulnerabilities before they were deployed.

The wave of shift-left solutions face several fundamental challenges that go deeper than “too many false positives:”

1. Vulnerabilities are discovered over time, and can’t be made “secure by default” - patching is the bottleneck, not discovery

2. No amount of secure developer training or code scans can force secure coding patterns

3. Architectural complexity and developer velocity make design review unscalable

4. Business logic exploits are the most common exploit types, but cannot be detected by deterministic scanning

These challenges are due to two bottlenecks traditional tools have had: a lack of business context, and the complexity of the scanning workflow. First, traditional tools have failed to suggest contextual findings and fixes to your organization. Tools can find a SQL injection, but they can’t tell you what ORM you should use to fix it, or the risk of deploying that fix in the first place. Second, the workflow of traditional tools is built for humans, not AI. Shifting left makes security place speed bumps in front of developers, but AI agents need the feedback before they start coding, not after.

AI Code Security tools focus on maximizing the value of AI Code Generation for Security teams, rather than the risks of using them. They’ll focus on providing teams with guidance on how to fix their security issues, while giving prescriptive advice for security agents. The result is improved remediation workflows, stronger code generation, and a more effective realization of shift-left principles, reducing vulnerability backlogs while giving security teams the oversight they need.

How AI Code Security Works and Why It’s Needed

With the right contextual guidance, AI code generation enables two primary opportunities: first, the effective remediation of backlogs, and second, secure by default code generation. The first addresses the challenge of getting organizational buy-in to fix security issues. The second addresses the challenge of building and enforcing security standards unique to your organization.

AI Code Security solutions begin by analyzing your attack surface, code, and knowledge bases to build a contextual knowledge graph of your product, its goals, and architecture. This contextual graph is the underpinnings of the outcomes these solutions deliver: threat models, contextual security findings, and secure code generation. This knowledge graph is only possible thanks to AI’s abilities to parse contextual data, making the entire security process customized to your organization. Building and enforcing this knowledge graph requires the following four core technologies: threat modeling, AI AST, interactive review tools, and developer MDMs.

First, threat modelling and design review are the foundation of security, but oftentimes treated as luxury investments. AI enables continuous review and enforcement by integrating with a company’s existing documentation to give teams insights into potential threats, while providing guidance on what policies to implement to prevent them. For example, AI Threat Modeling and Design Review tools give teams not just necessary documentation, but guidance on what secure coding practices they need to implement.

Second, AI is transforming traditional scanning capabilities - from SAST to DAST. AI native SAST tools provide a generational improvement over traditional SAST by using contextual graphs to discover novel findings across a code base, and suggest remediations. While this outcome is the closest to existing scanners, the findings themselves are categorically different - discovering unique logic vulnerabilities, while reducing false positives based on holistic application contexts. These capabilities are found across three emerging categories, none of which are all done by a single vendor: AI SAST, SCA autopatching, reachability analysis, and AI Pentesting. While threat modelling provides proactive guidance, AI testing provides the backlog and vulnerability contexts.

Third, the way that teams are interacting with their tools is changing from static scan results in PRs, to interactive chat experiences with coding tools. Security tools are evolving to fix their own issues without interfering with developer experiences by handing the work over to a background agent. Furthermore, teams are looking for ongoing and automatic guidance around their coding decisions, and what features to implement.

Finally, teams need a way to deploy and enforce these secure coding guidelines. We wrote earlier about the emerging capabilities of Developer MDMs, which allow the enforcement of AI coding standards as a side effect of providing broader governance of developer endpoints. Teams need the ability to govern developer endpoints, while enforcing their security rules to generate secure code.

When these capabilities are combined, teams get an end to end solution for securing AI generated code:

1. A threat model is generated specific to your organization and application

2. AI testing discovers and validates existing issues, while continuously assessing new deployments

3. Agents automatically gather security context when applicable to their task to improve and standardize code

Why This Matters for Security Leaders

Executive leadership is pushing for AI adoption, but security is still expected to govern the adoption. Teams need new capabilities to adopt and enforce standards as fast as AI code generation is happening. Security teams need governance capabilities for safe AI adoption.

Why this is Important for Practitioners

Practitioners are stuck using an outdated model of scanning, creating developer friction rather than adopting the new possibilities AI enables. In the long run, this new category of tools will make security’s job easier, not harder. AI Code Security tools will give teams more time to focus on higher level architecture research rather than prioritization and remediation.

Capabilities Guiding the AI Code Security Market

Build your own AI Code Security

Many security teams have already begun rolling their own versions of pieces of this solution:

1. Create a centralized repository for security use cases and best practices, giving developers guidance on what tools and techniques are used.

2. Complete threat models and design reviews on ongoing projects, and update existing documentation accordingly.

3. Give this context to your coding agent of choice in the way that best utilizes the context window. This might mean rules files, skills, MCPs, or a combination of approaches.

Continuous threat modelling and design review vendors

Vendors in this category connect to your code and knowledge bases to create an ongoing threat model of your environment. They can then provide AI generated design reviews for upcoming changes, as well as flagging major changes that are in progress. Leaders in this emerging category also offer in pipeline enforcement to make sure defined security standards are being enforced. Startups in this category are Clover, Prime, Seezo, and Devarmor.

AI SAST and AI Pentesting

In the application security report we highlighted all of the vendors associated with AI SAST and AI Pentesting; however, we didn’t fully break out the AI methodologies taken by these companies. In this context, the AI Native SAST approach that uses LLMs to explore tagged syntax trees is most relevant. Providers that we know work this way are Zeropath, Aisle, Depthfirst, and Corgea - this distinction is important because it benefits from the data imported from the threat model.

Agentic Code Security Management

When it comes to enforcing coding standards, there are two general capabilities:

1. Fetching organizational context to the agent without disrupting its workflows. Corridor specializes in this approach, but we’ve also seen less sophisticated versions from other vendors.

2. Governing permitted AI coding tools on developer endpoints. Backslash is the most mature version of this we’ve seen, but several larger application security platforms such as Snyk, Ox, Pillar and Legit provide versions of these capabilities.

These capabilities provide both the endpoint and agent governance teams need to enforce the context created by the other tools.

Conclusion

This article focuses on the future requirements of the market and how a new category, AI Code Security will be built to deliver the solution. There are several emerging products that help secure AI generated code, but we’re excited to see all of the components get put together. Our prediction is that there will be a new multi-billion dollar application security company, and it will be the one that best puts all of these pieces together.

It’s clear open source malware can no longer be overlooked. Last year, Sonatype cataloged over 877,000 known malicious packages across npm, PyPI, Maven, and other registries. This year, the number of packages being pushed to open source repositories has increased to over 100,000 a day, overwhelming scanners and researchers trying to keep up with the amount of malware being distributed. Most recently, the TeamPCP incidents, beginning with the Trivy takeover, showed how unprepared teams are to respond.

Security teams are prioritizing the structure of their application security programs around vulnerabilities, ignoring the impact, reach, and unique risks malware introduces. This creates a clear path to risk blind spots because CVE scanning doesn’t catch active exploits. Image scanning doesn’t catch compromised build pipelines, and most teams don’t audit their GitHub Actions, Terraform modules, VS Code extensions, or ML models. The attack surface is larger than most teams realize.

This guide provides teams with everything they need to understand and respond to open source malware:

1. Six checklists to prevent malware across third-party packages, container images, Github actions, IaC modules, and AI models.

2. A Claude Code plugin to automate your discovery and remediation of these issues across your codebase.

3. An overview of common attack types per exploit category

4. A maturity matrix to assess your program’s readiness

5. Relevant OSS, freemium, and paid tools

6. Helpful resources for further reading

Subscribe now

How the Checklists Work

The below six checklists provide suggestions for immediate and long-term strategies for preventing open source malware in an organization’s environment. The “Immediate Action” sections indicate high priority items that drastically reduce your attack surface. The “Long-term Initiatives” sections are larger engineering projects that are best practices for defense-in-depth initiatives. These checklists are also available as a Claude Code plugin. Just install the plugin and run /audit-supply-chain and it will identify and fix immediate issues, while providing walkthroughs for more complicated ones, alongside a complete report on the repo.

By starting with the checklists and Claude Code plugin, teams can take immediate action to safeguard their CI/CD pipelines from ongoing attacks. The longer term strategies provide what’s needed to mature your security program with defense in depth measures to validate the code that runs on your systems.

Checklist for Third-Party Packages

Many teams scan their third party packages for vulnerabilities, but often miss the preventative steps required to block malicious code from getting installed during updates. This checklist starts with steps to reduce your attack surface, and moves to active validation and prevention measures.

Immediate Actions

• Pin all dependencies to specific versions - example: requests==2.31.0 instead of requests>=2.0.0

• Require a package cooldown period on your builds, pnpm security docs as an example. NPM security guide.

• Disable pre-install and post-install scripts in your package manager - different package managers have different equivalents. Malware is commonly deployed during package installation.

Larger Initiatives

• Review every new dependency addition for health in PRs before merging - Snyk Advisor, Socket package lookup

• Deploy a malware scanner locally and in CI/CD that blocks on detection - Aikido SafeChain, GuardDog, OpenSource Malware

• Enable namespace/scope restrictions to prevent dependency confusion - Artifactory, Cloudsmith

• Enforce allow-lists for approved packages

• Verify package signatures before deploy - Sigstore

• Generate SBOMs for your dependency tree - CycloneDX, Syft

• Run packages in sandboxed install environments to detect install-time behavior - StepSecurity, or other eBPF/CADR sensors.

Checklist for Container Images

Container images are not as commonly exploited as third party packages, but the underlying risk exposure is similar. This checklist provides teams steps to go from proper version pinning to total image signing and validation before deployment.

Immediate Actions

• Audit your images, ensure you’re using official or verified base images only - Docker Scout, Grype

• Pin base images by digest, not just tag (FROM node:18@sha256:...). Renovate and Dependabot can do this automatically.

• Stop running containers as root - Hadolint

• Scan images for known vulnerabilities - Grype, Docker Scout

Larger Initiatives

• Implement image signing and verification to prevent tampering - Cosign

• Set up admission controllers to block unsigned or unscanned images - Kyverno

• Scan images continuously in the registry, not just at build time - Harbor, Dockle

• Automate weekly rebuilds of base images

• Switch to minimal base images, and/or use multi-step builds - Alpine, Distroless

• Build images in hermetic, reproducible environments

• Generate and attach SBOMs and SLSA provenance attestations to every image - SLSA, in-toto

Checklist for GitHub Actions

Github actions are commonly misconfigured in public repos, allowing attackers to inject code via their own branches. This checklist provides teams guidance on preventing these attacks, as well as how to monitor them in the future.

Immediate Actions

• Pin all Actions to full commit SHAs (not tags or branches) - pin-github-action

• Set permissions: explicitly in every workflow to least-privilege

• Use CODEOWNERS to require review on .github/workflows/ changes

• Audit which third-party Actions you’re currently using, and scan them for issues like pull_request_target triggers - Zizmor

• Enable tag protection rules - create a ruleset to prevent forced tag releases

• Don’t allow untrusted input to AI tools in pipeline - ensure that input from Github issues or other public sources doesn’t run in combination with AI review tools.

Larger Initiatives

• Enable GitHub’s Action allow-list to restrict which Actions can run

• Monitor network egress and filesystem activity in workflows - StepSecurity Harden Runner, or other eBPF sensor.

• Use OpenSSF Scorecard to evaluate Action trustworthiness - OpenSSF Scorecard

• Implement OIDC for cloud deployments instead of long-lived secrets

• Separate CI and CD workflows with environment-based approvals

• Enforce SHA pinning at the org level via GitHub policy

• Run self-hosted runners in ephemeral, isolated environments

• Build internal Action mirrors for critical dependencies

• Set up automated Action version updates - Dependabot, Renovate

Checklist for Infrastructure-as-Code Modules

Infrastructure as code is an underexplored attack vector in open source malware, as gaining initial access is more challenging for attackers. A few basic actions can vastly improve your posture.

Immediate Actions

• Pin Terraform modules and providers to exact versions - version = “5.1.2” instead of version = “>= 3.0.0”

• Use only modules from the official verified registry or your org’s private registry

• Run IaC scanning for misconfigurations - Checkov, tflint

Larger Initiatives

• Implement Terraform state encryption and access controls

• Use OPA/Sentinel policies to enforce guardrails (no public S3 buckets, no wildcard IAM, etc.) - Sentinel, OPA

• Enable drift detection to catch out-of-band changes - Spacelift, env0

• Lock down local-exec and external provisioners and Run all IaC applies through audited CI runners - Atlantis, Terraform Cloud

• Require signed commits for IaC repos

• Build internal module libraries with security-reviewed defaults

• Continuously reconcile running infrastructure against declared state - Crossplane, Firefly

Checklist for AI/ML Models

This checklist applies to teams building or using open source models rather than third party providers like Anthropic or OpenAI. Numerous supply chain attacks target these ecosystems, as standards are less rigidly enforced.

Immediate Actions

• Never load untrusted pickle files

• Prefer safer serialization formats over pickle/PyTorch native - SafeTensors, ONNX

• Only pull models from verified organizations on Hugging Face - Hugging Face Hub

• Document which models your team uses and where they come from

Larger Initiatives

• Run Picklescan on all PyTorch models before loading - Picklescan, ModelScan

• Host models in a private registry with access controls

• Verify model hashes against known-good checksums

• Implement model cards and provenance documentation

• Run all model loading in sandboxed environments with no network access

• Implement model signing and verification

• Conduct adversarial testing to detect poisoned models

• Maintain an internal model registry with security review gates

• Monitor AI systems at runtime to spot malicious behavior

Checklist for IDE Extensions and Developer Tools

This checklist targets protecting developer endpoints, which frequently run third party code in browser and VSCode extensions. Endpoint management tools are needed to audit what’s running across developer machines.

Immediate Actions

• Audit currently installed extensions across your team - VS Code Marketplace, Santa, OSQuery

• Only install extensions from verified publishers with meaningful install counts - Wiz: VS Code Supply Chain Risk

• Remove unused extensions

• Review extension permissions before installing (network access, filesystem access)

• Give developer training on extension usage and risks

Larger Initiatives

• Publish an org-approved extension allowlist

• Use VS Code Profiles to standardize extensions across teams - VS Code Profiles

• Restrict VS Code Marketplace access via enterprise policy

• Have a plan to rotate secrets that live on developer workstations

• Run dev environments in remote containers or cloud-based environments - GitHub Codespaces, Gitpod, Dev Containers

• Implement network segmentation for developer workstations

• Monitor extension behavior at the endpoint level

• Use ephemeral dev environments that reset between sessions

Examples of Open Source Malware Attacks

Attacks on Third-Party Packages

This is the highest-volume attack surface, as public registries have little to no gatekeeping on who can publish what. Most developers don’t inspect the code of open source packages they’re importing into their code, and most organizations don’t follow a stringent approval process for adding new libraries. Additionally, trusted packages can become less well maintained over time, increasing the tech debt and attack surface over time.

Example Attacks:

Typosquatting. Publishing packages with names one character off from popular libraries (reqeusts instead of requests, lodashs instead of lodash). Threat actors now use AI to mass-generate look-alike package names and obfuscate payloads to bypass signature-based scanners. The malicious packages mirror the real API, so developers don’t notice the mistake immediately. Install scripts run when npm install or pip install executes.

Dependency confusion. Targeting organizations that use internal package names that are guessable or leaked by creating higher version public packages. Most package managers prefer the public, higher-versioned package over the internal one. Blog on prevention in NPM.

Starjacking. Open source registries don’t verify that a package’s linked GitHub repo actually belongs to the publisher. Attackers link their malicious packages to high-star Github repos to appear to be the legitimate package. This one is easy to miss if searching public registries instead of Github itself.

Malicious install scripts & lifecycle hooks. This is the actual payload delivery mechanism for most open source malware attacks. npm preinstall/postinstall scripts, Python setup.py with arbitrary code, Maven plugins that execute during build phases. Whether the attacker gets their package installed via typosquatting, confusion, social engineering, or a leaked credential, installing the package executes the script that steals credentials.

Maintainer account takeover. Compromising an existing, trusted maintainer’s credentials or PAT and pushing a malicious update to a legitimate, widely-used package. This can lead to directly pushing a malicious package upstream, sneaking in malicious code in a fake commit, or publishing malicious actions.

Attacks on Container Images

Container images from Docker Hub and other public registries carry a similar risk profile, but require different mitigations. With container images, teams are pulling a much larger attack surface than a single package, and they’re harder to scan for smuggled malicious code than Github directly. Because most teams don’t enforce what’s allowed in their images, it can be easy to overlook a package that was smuggled in.

How attacks work:

Poisoned base images. Attackers publish images with names similar to official ones (ngnix vs nginx) or compromise less-maintained “community” images.

Embedded malware in layers. Container images are built in layers, and malicious content can be hidden in intermediate layers that aren’t obvious when inspecting the final image. A RUN curl | sh buried in a multi-stage build is easy to miss. Because layers are cached and shared, the malicious content persists across rebuilds that don’t change that specific layer. Additionally, many teams don’t baseline image behavior, making it easy to miss when malicious actions take place during build.

Registry credential theft. The GhostAction attack in September 2025 exfiltrated 3,325 secrets from 817 repos. Stolen registry credentials allow attackers to push compromised images to legitimate repos without anyone noticing until runtime.

Tag mutability. FROM node:18 doesn’t mean you’ll get the same image every time. Tags are mutable, meaning that the image behind the tag can be changed. Without pinning by digest (@sha256:...), your build is pulling whatever was last pushed to that tag. This is similar to the Github actions attacks - images need to be pinned to full SHAs.

Attacks on GitHub Actions

This is the attack category that continues to explode across Github, and it’s the one most teams are still underestimating. GitHub Actions run with access to your repository secrets, GITHUB_TOKEN, deployment credentials, and whatever else is in the workflow environment. Supply chain attacks targeting GitHub Actions have increased significantly in 2026.

How attacks work:

Action compromise/tag mutation. The tj-actions/changed-files incident was a widespread example of this vector, where attackers compromised a dependency action (reviewdog/action-setup), which cascaded up to tj-actions. The injected payload dumped CI runner memory, exposing secrets from every repo using the action. The attack exploited the fact that GitHub Action tags are mutable, @v3 was pointed to a malicious commit - this is why Github actions need to be pinned to specific SHAs.

Typosquatting action organizations. Orca researchers demonstrated this attack vector by registering 14 GitHub organizations with misspelled names of popular Action owners such as circelci, actons, google-github-actons. There’s no verification system preventing this. A workflow with a typo in uses: silently runs the attacker’s code.

Script injection. Actions that use ${{ github.event }} context in run: blocks are vulnerable to injection. An attacker crafts a PR title or commit message containing shell commands that execute in your workflow. This gives arbitrary code execution without needing to compromise any Action.

Overpermissive workflow tokens. Actions running with permissions: write-all or default broad GITHUB_TOKEN scopes give compromised actions far more access than they need. Combined with any of the above vectors, overly permissive tokens amplify the blast radius dramatically.

Cascading dependency chains. GitHub Actions can depend on other Actions. The tj-actions compromise originated from reviewdog/action-setup, a transitive dependency most users didn’t know they were pulling in. There’s no built-in dependency graph for Actions, making this invisible for most teams.

AI tools with untrusted sources. Aikido researchers demonstrated an attack with AI pipeline tools taking input from untrusted sources, such as reading Github issues to prioritize them. Researchers were able to prompt inject these tools via issues to uncover secrets.

Attacks on Infrastructure-as-Code Modules

IaC modules are a distinct attack surface because they execute with infrastructure-level permissions. A malicious Terraform module can provision resources in your cloud account, modify IAM policies, or open network paths.

How attacks work:

Malicious Terraform modules. The Terraform Registry has the same lack of gatekeeping as npm. At NDC Oslo 2025, researchers gave a live demonstration of supply chain attacks on the Terraform Registry. HashiCorp acknowledges that “Terraform providers and modules used in configurations will have full access to variables and Terraform state” and cannot prevent malicious modules from exfiltrating sensitive data.

local-exec and provisioner abuse. Terraform modules can use local-exec provisioners to execute arbitrary commands in the CI environment, or use the HTTP provider to exfiltrate values from state. State files often contain database passwords, API keys, and other secrets that persist across runs.

Attacks on AI/ML Models

This is the fastest-growing attack surface, and the one where security tooling is least mature. Loading a serialized ML model can execute arbitrary code and many data science teams aren’t thinking about this as a security risk.

How attacks work:

Pickle deserialization attacks. Python’s pickle module is the default serialization format for many ML frameworks. Pickle allows arbitrary Python code execution during deserialization. Loading a malicious .pkl or PyTorch model file can drop a reverse shell, exfiltrate data, or install persistent backdoors. In February 2025, ReversingLabs discovered two malicious ML models on Hugging Face using this exact technique.

The “NullifAI” evasion. Several security scanners exist to detect malicious actions in compressed modules; however, these have been bypassed using a combination of different compression algorithms, as well as various bypasses for picklescan.

Model poisoning. Beyond outright malware, attackers can subtly modify model weights to introduce backdoors. The model can perform normally during certain activities, but be triggered later to take malicious actions.

Attacks on IDE Extensions and Developer Tools

IDE extensions run with full local filesystem and network access on developer workstations, which often hold SSH keys, cloud credentials, and package registry tokens.

How attacks work:

Malicious extension publishing. The “prettier-vscode-plus” attack in November 2025 delivered a multi-stage malware chain through the official VS Code Marketplace, deploying the Anivia loader followed by OctoRAT (a full remote access trojan). Extension marketplaces are not typically scanned by security vendors or maintainers.

Leaked publisher access tokens. Wiz Research identified over 100 cases of secret leakage by VS Code extension publishers, including leaked Personal Access Tokens (PATs) that grant the ability to push extension updates. A leaked Marketplace PAT allows an attacker to distribute malicious updates across the entire install base, one case had over 150,000 cumulative installs exposed.

Extension dependency attacks. VS Code extensions can depend on other extensions and npm packages. A compromised dependency can inject malicious code into an otherwise legitimate extension update, mirroring the cascading dependency problem in GitHub Actions.

Fork/recommended extension attacks. VS Code forks (like Cursor, VSCodium) recommend extensions from the Open VSX registry, which has even fewer security controls than the official Marketplace. Researchers demonstrated that missing extensions in Open VSX could be typosquatted to target users of these forks.

Conclusion

Preventing open source malware is hard but necessary work. The attack surface continues to expand, and many teams are not prepared for zero day responses to these kinds of attacks. Teams should take immediate action to make sure they’re secured by implementing the relevant guardrails.

CVEs and malware are different problems with different mitigations, and conflating them is how you build a program that feels comprehensive but leaves the actual attack surface wide open. Start with the “Do Right Now” items. Pin your versions, audit your Actions, stop loading untrusted pickle files. The harder controls (sandboxed installs, SLSA provenance, ephemeral runners) take longer, but the easy ones eliminate a significant chunk of your exposure today

Appendix:

For the Maturity Model, Tools List, and Additional Resources, see the blog on Latio’s website.

Earlier this week, on March 19, 2026, Aqua’s Trivy scanners were attacked. This latest supply chain malware attack represents a significant advancement in exploit techniques and serves as yet another in a series of endless wakeup calls for security teams.

Previous malware attacks like Shai-Hulud were easier to detect because they generally relied on secret scanners, encoding those secrets (twice for epic security), and then sending them up into a public repo for attackers to scrape. While a pain to deal with, brute force attacks were at least easy to spot: simply scan for the repo prefix to see if you were impacted. The latest Trivy compromise represents a major step forward in attacker sophistication, due to the complexity of fail safes deployed, as well as the usage of C2 servers and encryption over encoding.

This post will focus on why these attacks are so difficult to detect and respond to, and what you’ll need to investigate if you were affected. In the process we’ll see why the industry is fundamentally underprepared for this becoming a major attack vector. For technical deep-dives on the attack itself:

• Rami and the team at Wiz

• Charlie and the team at Aikido

• Paul and the team OpenSourceMalware

• Philipp and the team at Socket

• Varun and the team at StepSecurity

• François and the team at Boost Security

Subscribe now

How we learn if a package has been compromised

Very few organizations invest in upstream malware scanning, and we should be genuinely grateful for each of them. While many companies do bespoke research, it’s better to call what’s emerging “open-source incident response” – and it’s being run by an unofficial consortium of researchers making everyone safer. The primary organizations doing this at scale are Aikido, Wiz, OpenSourceMalware, StepSecurity and Socket; but many other organizations such as Datadog, Veracode, Boost Security and others also contribute research.

While we’re grateful for the research, the underlying concern should be that this stuff isn’t magic, and small research teams are doing a lot of heavy lifting – using open source packages is risky, and you need to take appropriate security steps to secure your environments against zero days.

At the risk of being a broken record, detection and response tools need to expand further into the application layer to detect these attacks when they bypass scanning tools and researchers. Just as we have an EDR instead of antivirus, teams need to adopt CADR rather than relying on searching for file hashes after the exploit has happened. You can read more about the latest developments in preventative application protection in our application security report on page 26, the TL;DR is that as AI makes vulnerability discovery and application layer malware more achievable, the patching and praying approach is too slow.

How to understand if you’ve been impacted

Even if you know that you use affected packages or GitHub actions, most organizations do not have adequate telemetry to assess the impact – and subsequently which secrets need to be rotated. Teams lack telemetry because open source packages get installed everywhere, namely developer machines, pipelines, staging environments, and production. Developer machines and pipelines go especially unmonitored.

In earlier supply chain attacks the blast radius has been lessened by simple mistakes attackers (or researchers) made, such as only working on Github runners, or not properly establishing persistence. The latest Trivy attack shows more sophistication, taking several other paths for optional persistence later, encrypting rather than encoding, posting secrets to an attacker server, and not leaving obvious evidence behind.

IoC’s involve searching for external domain traffic, and monitoring egress traffic for cloud workloads is one of those “we’ll do it later” projects for security teams (one reason I’m a fan of cloudfence). If you’re building your own telemetry, here’s what you need to be able to have quick access to search:

1. Developer laptops for installed package versions, egress traffic to attacker domain, file hashes once provided by a vendor. Typical tools: EDR, local vulnerability scanning (SCA), firewalls.

2. Github actions logs and egress traffic. These are extremely rare for organizations to have in a consolidated location, if at all in the case of egress logs. Typical tools: SIEMs, observability tools, eBPF sensors and CDR tools.

3. Staging/Production file hashes, package versions, and egress traffic. Most organizations do not fully monitor their egress traffic - another benefit of CADR runtime tools. Typical tools: CADR, Container Vulnerability scanners (CNAPP).

In short, being able to know if you’ve been impacted is not automatic: it requires a lot of pre-emptive work to make sure you’re equipped to respond.

How to respond If you’ve been impacted

There’s one line in most of the response blogs that’s easy to say but hard to achieve: “assume total compromise of the system and rotate all credentials.” For most organizations, this project alone ends up being a fire drill made worse by the kind of persistence that impacted Trivy in this case. If all tokens aren’t invalidated first, and then reissued, attackers can use the permissions of an established token to see the newly generated ones.

For most companies, this means guaranteed downtime, and is a complete nightmare:

1. Identify scope of the compromise: which secrets have access to which permissions, which themselves may have access to further secrets downstream

2. Universally deactivate the secrets, or in cases where refresh tokens may be issued (such as AWS), apply a universal deny policy to the identity before deactivation

3. Issue new tokens across workloads.

For most companies, this is far from trivial, and it’s almost a guarantee that things will get missed. There are many approaches worth spinning up sooner than later to avoiding these pain points:

1. Use JIT wherever possible for human and non-human identities

2. Have a clear process in place for secrets rotation, using an external secrets manager rather than hardcoded keys

Scoping the impact is the harder part; to be frank, there isn’t a great way to do this yourself and is the primary benefit of NHI security providers - showing token relationships and permissions, and monitoring them for indicators of compromise.

How to prevent supply chain attacks

Preventing supply chain malware is challenging, because there are so many forms it takes. Did the attack compromise hosted actions? A new package version? An old one? Here are the basic steps to take:

1. As stated everywhere: if you’re using open source github actions, pin to version SHAs rather than version numbers. Yes this is a pain, yes it makes updates harder, but this is the most likely attack vector.

2. Scan for secure workflow configurations

3. Restrict the access of Github Actions across your organization: Follow Github’s guide to use actions with the least privileges required.

4. Lockdown your open source installers (there are several open source tools for doing this, and your default installer might have them as configs such as pip):

   1. Require a cooldown period of one week before version updates (yes this ironically means slower patching for vulnerabilities)

   2. Disable pre and post-install scripts

   3. Expand your data pool for SBOMs to include packages installed on local dev machines, pipelines, staging, and prod environments.

The unspoken assumption behind these preventative measures is they require that malware gets flagged upstream rather quickly. This is something organizations shouldn’t count on, and why preventative ADR capabilities that prevent malware execution in third party packages is so important.

What should you do if you’re an open source maintainer

Open source maintainers are under a lot of pressure already, and preventing supply chain attacks offers yet another headache. In addition to the above steps, maintainers should:

1. Enforce MFA on all the things - GitHub and package registries

2. Audit and cleanup user permissions and unused tokens

3. Stop using Github classic tokens

4. Migrate off of long-lived tokens for deployments, and sign releases

5. Audit Github actions

Conclusion

These attacks are only getting worse and scarier, and if you don’t have these things in place you won’t even know you’ve been impacted, and you may find yourself propagating the next major attack. To use a dated reference, we’re all one malware away from all being Solarwinds - turning our software into distribution centers for more malware.

The core problem is that we treat open source software as trusted software, akin to installing from an app store where every application is approved by a vendor. Unfortunately, Open Source operates more like a shared responsibility model, one where the provider doesn’t actually own any of the responsibility. While Application Security teams have an established practice around vulnerability management, responding to incidents in open source packages is a discipline more akin to security operations, who oftentimes lack the necessary telemetry and training required to respond.

We met with over one hundred application security providers, practitioners, and buyers, to accurately map the past, present, and future of application security into an industry defining report.

This report is for teams building their application security programs and looking to understand the latest developments in application security. It’s also for product builders, marketers, founders, and investors looking to deepen their understanding of the current state of the application security market.

In this report, we argue:

• That application security is a discipline in crisis, as AI rapidly changes scanner capabilities and developer workflows

• The present solutions landscape offers a variety of approaches to scanner consolidation and workflows

• The silent death of ASPM as a standalone management category in favor of broader CTEM platforms with code to cloud capabilities

• There are presently varied approaches to securing AI generated code.

We’ll be sharing various snippets of the report and what they mean for the market from Latio’s page, so follow along for updates. Thank you so much for your continued support of Latio and our hands on keyboard approach to research!

Get the Report

There’s no better way to ring in the new year than opining about the future of cybersecurity tooling with friends and family. Below are five critical features that I predict will sell themselves in 2026, and three features that I personally think are most important.

The 5 Product Capabilities That Will Dominate in 2026

Supply Chain Malware Detection

Whether we like it or not, the security industry is highly reactionary. Upstream supply chain malware detection has existed for a long time, with vendors like Phylum and Socket doing a lot of challenging work early on to detect emerging threats in open source code. This feature was ahead of its time for a few reasons:

• Teams didn’t understand the difference between malware and vulnerabilities

• Teams want this feature as part of their overall application security platform

• Developer adoption for NPM wrappers and firewalls is extremely low

The last two years have seen widespread impact from open source malware, with attacks like Shai Hulud compromising thousands of organizations. The widespread impacts here are no longer hypothetical, forcing teams to answer for their solution.

Supply Chain Malware is no longer an afterthought for teams going into 2026, and it’s a priority feature during application security assessments.

You can watch our video on Shai Hulud here.

AI Vulnerability Remediation and Prioritization

(that’s not just a chatbot)

The emerging Continuous Threat Exposure Management (CTEM) category has been a weird one for startups. 2025 saw many vulnerability management startups consolidate, with buying vendors ranging from application to cloud to network security. This consolidation happened because selling a point solution tool to manage your tools is hard, but it’s a great differentiator between platforms fighting to be the single pane of glass for your security program.

In 2025 we’ve seen an explosion of new vulnerability management approaches driven by AI - from auto-remediation to investigation and prioritization. Historically, vulnerability focused startups struggled to find mass adoption as single panes of glass for the same reason the prior CTEM vendors did - teams treated them as a tool to manage your tools, which wasn’t a compelling budget line item.

The newer solutions have more narrow scopes, tied directly to budgetable outcomes for the teams that understand the importance of AI vulnerability remediation and risk prioritization.

You can watch our video on Maze as an example vendor here.

AI Visibility, Guardrails, and Testing

Two years ago, I shared how AI security architectures are challenging, due to how quickly an organization’s risk exposure can change. Early chatbots introduced little risk - just regurgitation of public information back to a user. Agentic systems however rapidly increase risk, making in depth security measures essential. Adding to the confusion for startup builders, the majority of the security industry doesn’t know what good looks like, while those on the cutting edge have specific expectations of products.

In 2026, most tools offer some basic visibility into your AI systems, telling you what models are getting used by your workloads or called in your code. These tools provide a basic overview of how AI agents function in your environment, and are the starting point for most security teams. These capabilities are already available from most major providers.

Runtime guardrails are a more niche capability of some tooling, but companies that started here have expanded elsewhere. Most major cloud providers and frameworks offer their own guardrails instrumentation that will grow much faster in both adoption and sophistication than security specific tools. While runtime protection remains important more broadly for AI systems, code instrumented guardrails are best left to the major AI providers rather than security startups.

Testing however always has fallen under security’s purview. Many DAST providers are now adding LLM red teaming capabilities, largely trying different prompt injection techniques. While these features will become widespread over time, they’ll be a major testing driver for 2026.

You can access our full AI report here.

AI Based Detections | SAST, DAST, DLP, and Phishing

AI is incredible at helping developers write code, it’s equally incredible at analyzing code for security flaws. AI based detections are a categorical improvement wherever they’re deployed - from SAST to DAST to DLP to Phishing. AI excels anywhere complex manual review of small amounts of static data was required to get the best results.

Many security companies have focused on building AI based assistants and workflows, but those who have focused on rebuilding their detection engines to support semantic analysis will win big in 2026.

You can watch our video on AI SAST here.

SOC Augmenters

Security Operations teams are currently under a barrage of pitches from startups promising everything from cheaper data ingestion costs to seamless querying of large amounts of data. This has led to a flood of confusion about what is or isn’t a necessary part of a security operations arsenal.

The core of every SOC is quite simple and unchanging: a SIEM. The success of Cribl has revealed to many startups that there is plenty of room for flourishing around the SIEM - from making data ingestion easier, to long term storage, to detection engineering. Even attack surface management solutions and CNAPPs are positioned as SOC enablement tools by providing asset contexts.

CISOs recognize that their SOC teams need a better way to handle everything from AppSec to Cloud Security more effectively, and will allocate budget to modernize this workflow where it makes sense - from AI MDRs to data pipeline tools.

You can read our latest article on AI SOC capabilities here.

3 Capabilities That Should Be On Your Radar in 2026

If I were building a security program, here are the three capabilities that I would make room for in my 2026 security efforts.

1. ADR: runtime function level reachability, robust application detection, and emerging in-application AI detections.

As ADR capabilities have developed, I’ve only grown more impressed with the results they can deliver teams - from exploit prevention, to AI security, to prioritization. This category of tools is in my opinion the best budget line item a team can open up.

2. Developer endpoint security:

Developer endpoints continue to face dismal security standards, with many teams having no real way to even know what their attack surface looks like on these devices. From MCP servers to open source malware, developer laptops are more exposed than ever before. Tools like Koi led the charge in 2025, but expect massive investments in this category as AI coding assists have forced Application Security vendors to take a second look at developer endpoints more broadly.

3. Realtime AI threat modeling and design review: building an overall map of your application architecture that updates with your documentation and pull requests

In application security we’ve said for a long time that a threat model should be the starting point for a program rather than an after thought. Despite this, AI threat modelling has yet to be widely deployed by most application security platforms. Early versions of these tools do a great job at both exposing potential vulnerabilities and helping teams better understand how their applications function.

Subscribe now

As an emerging category, AI SOC has earned mixed reviews and seen massive changes over the last year. On the one hand, like most AI tooling, when it works it feels magical, delivering unique insights and automation. On the other hand, too often the tools create instant friction as they lead security analysts down wrong paths while driving up costs with inefficient queries.

This article will cover the challenges that arrived with the first wave of AI SOC tools, and how a second wave of AI SOC tools are addressing these concerns by delivering a more AI native user experience. I argue that this transformed user experience gets us much closer to the outcomes we expect from AI.

As a quick aside, there is a third kind of AI SOC tool which functions more as a complete data platform, two examples being Exaforce and AI Strike, which won’t be the subject of this article because there are far fewer vendors doing it, and the use case is more robust.

The Challenges with AI SOC Tools

It’s always challenging to be the first mover in a new category. The first generation of AI SOC tools revealed some early challenges in applying LLMs to SOC workflows:

1. Summaries that don’t add additional value to the initial alert

2. Running data enrichments that are cheaper done natively in the SIEM

3. Leaning on verbose summaries rather than actionable guidance

4. Increasing tool costs through unoptimized queries

5. Require manually building and maintaining accurate knowledge bases

These tools should be commended for their big experimental bets, but the investments were often missed due to being too much like SOAR platforms compared to providing a true copilot experience. In the worst case, these summaries just provide additional layers of abstraction before needing to click into alerts anyways. For example, oftentimes in the tools that I have used I find myself going to the JSON responses themselves rather than trusting their AI summaries.

Many first generation AI SOC platforms have ended up closely related to traditional SOAR platforms, being used for specific enrichment or automations. Leading SOAR providers like Tines and Torq have been able to quickly incorporate AI into their tooling, further diluting the differentiation.

At their best, these tools can fetch unique insights, correlating data that otherwise an analyst would miss; but at their worst, they can spin in circles investigating meaningless information while driving up costs, like trying to look up the IP abuse status of a localhost domain.

How New AI SOC Tools are Different

A second generation of AI SOC tools offer a glimpse of future AI SOC workflows, functioning more as contextual copilots than SOAR + AI. These SOC copilots are the first tools that provide a “Claude Code but for SOC” experience rather than a “here’s some text we generated that could be possible be helpful” one.

The fundamental features of these tools are what’s setting them apart and up for success:

1. Taking actions on behalf of the security analyst, for investigation and response

2. Investigating alongside the analyst rather than trying to provide a complete summary at the end

3. Continuously learning and applying organization context

4. Giving the analyst complete control over their workflows as they’re happening

5. Fine tuning agents to enable autonomous actions

The leading tools in this new category are Mate and Legion, and I was able to get in depth most recently with Mate, so this article will focus on their methodology in order to demonstrate the differentiators in this new generation of tools.

First Differentiator: Continuous Learning

From my experience working at an MDR provider, mapping organizational contexts is one of the largest challenges in security operations. Constant updates are needed to track who is responsible for an alert, what common alerts occurred, and what to do in various situations. For example, imagine having one customer who uses different DNS resolvers based on environments, and the headache that creates trying to keep analysts up to date! In the context of AI SOC, continuous learning takes on these hurdles in two forms: building an organizational knowledge base, and fine tuning various agents to excel at different tasks.

When it comes to building an organizational knowledge base, the basic version has been creating a library of text that the agent can look at before deciding on an alert. The problem is that these pieces of information enter the context window too late - when the agent has already made several decisions.

Solutions like Mate instead integrate across your tools to automatically build out the context the agent will need later on - whether it’s asset ownership information, or information about your environment. What stood out to me about Mate’s approach to integrations is how it looks up data via user accounts, rather than relying on a series of bespoke integrations.

The other aspect of continuously tuning these tools to your environment is being able to configure agents to create better outcomes. Many AI SOC tools create lackluster results, as their context window becomes bloated with unhelpful information. Mate offers the ability to create and manage custom agents, giving them relevant tools and knowledge bases. This feels more like a next generation of SOAR - tweaking agent behavior rather than APIs.

Mate’s one of the first tools I’ve seen in this category with the amount of customization necessary to roll out automations at scale.

Second Differentiator: Copilot User Experience

The second major aspect experienced in the first wave of tools was it lacked a copilot experience, and introduced a dashboard-y one. Unfortunately, most early AI SOC tools end up with this experience, offering yet another alert board. Or as I always affectionately call many tools - a SIEM for your SIEM.

Another differentiator coming from the second wave of tools like Mate is focusing on a user experience that helps with investigations: not just summarizing what happened, but giving you actually helpful pieces of information along the way. I can’t help but compare this to the generations of AI coding tools - moving from copy pasting code in and out of ChatGPT to using Claude Code or Cursor to work alongside AI to get to the end result.

This shift in user experience is what has finally made me open up to the category as a whole - not expecting the AI to be perfect, and instead building a UX that is always useful. This comes across first with investigations, and then fetching additional data to enrich the incident. The most helpful automation is sending a Slack to confirm common anomalous safe alerts like impossible travel.

Again like coding assistants, the UI/UX also moves with the user to remediation actions - allowing you to take multiple actions based on what might be the most beneficial. It’s clear that moving these into the browser proves helpful, as teams can take more flexible actions based on the specific alert, instead of relying on general summaries of what to do.

Conclusion

Overall, I’m excited to see what’s next within the development of these more copilot-like experiences from AI SOC tools as they’ve learned from the SOAR + AI challenges that the first wave of tools dealt with. I look forward to sharing more insights about these AI SOC tools once I have more hands-on experience with them, but what I’ve seen so far is very promising, offering increased speed and precision to analysts rather than seeking to wholeheartedly replace them.

A proliferation of various vendor resources have been released on Shai Hulud v2, from AI generated marketing pieces to thoughtful independent research. This is an attempt to collect all of the most useful information in one place.

Quick Summary: A massive number of code libraries were compromised, most prominently from Zapier, ENS Domains, PostHog, and Postman. If you ran the infected package, most secrets on the device that ran the package install can be considered compromised, and a persistent RCE was potentially setup on your device in the form of a GitHub runner. Secrets were posted via public GitHub repos which are being taken down by GitHub, with secrets owners being notified in the cases where this data is available.

Responder Tools:

IOCs:
These are collections of infected package names and versions, as well as SHAs of the malware files that get left behind on endpoints that run the install.

1. Wiz GitHub CSV, their article also has the SHA1 for the infected files.
2. DataDog’s GitHub CSV
3. Koi CSV which has individual lines for when multiple package versions are there. This link also contains SHA256 for the infected JS files for threat hunting
4. Several vendor blogs have comprehensive bulleted lists: Aikido, Semgrep, Socket

Scanners (Packages):
In my opinion, it’s best to rely on your SCA tool or even a code search to check for impacted versions before scanning for them all over your environment. Second, I’d look for the SHAs included in the Wiz and Koi articles for the infected files to see if I was impacted rather than trying to hunt for the specific versions in my packages. Finally, I have not personally verified the effectiveness of these scanners.

1. ndaal_public_detect
2. Phoenix Security Scanner
3. Jaime - Scanner and Package.json uploader
4. sngular scanner

Compromised Secrets Checker:
These companies say they gathered the public secrets exposed, decoded them, and added them into their exposed secrets databases. While I haven’t verified the comprehensiveness of what was added and always feel icky pasting secrets into public web forms, I can vouch for these being real companies that you’re yeeting your secrets into:

1. Entro Are my Secrets Out?
2. GitGuardian Has my Secret Leaked?

Free or Open Source NPM Package Safety Tools

1. Using pnpm with cooldowns, blocking postinstall scripts, and trust policies
2. Aikido’s open source safechain, which checks against their malware feed before installing a package.
3. NPQ - with a variety of open source health factor checks available, including a cooldown period setting and checking for pre and post install scripts.

James Thoughts:

1. Saying “use fewer dependencies” is an incomplete answer. It’s a great aspirational goal, but dependencies are the reality of modern software development, and “just using less of them,” isn’t the reality. Let’s especially consider that several of these compromised dependencies were tied to commercial offerings - where you wouldn’t be able to build them in house anyways.

2. We can be grateful to live in a new world where more than one vendor is detecting upstream malware. As common as the headline “X vendor discovers massive ongoing supply chain attack!” is, the reality is that multiple vendors are discovering this stuff in parallel. While as early as two years ago only a couple of companies like Phylum (acquired by Veracode) and Socket were monitoring for these attacks, now a plethora of vendors are doing upstream monitoring with various tools from AI to runtime build monitoring - such as Aikido, Koi, SourceCodeRED, and StepSecurity.

3. Similarly, there are now many open source “protection” tools out there - with one of the first ones being Liran’s NPQ. I’m not listing them all here because they all have the same challenge: developer adoption requires conscious effort and enforcement. Liran’s tool was released 8 years ago, your SCA scanning vendor may offer their own.

4. The only way you can absolutely prevent these attacks is version pinning. The only way to detect these attacks is runtime monitoring of developer endpoints, build systems, and production systems. The other preventative measures are more defense in depth ways to protect your build system while allowing some amount of automation.

5. This article from Liran at Snyk, written in 2022, remains comprehensive and relevant for preventing supply chain attacks.

6. The only way for this to get solved ✨ magically upstream are further hardenings and automation from maintainers, enforced by NPM. The most important of these is the rollout of trusted publishing, which publishes NPM packages via OIDC credentials and trusted runners, rather than long lived credentials.

7. For runtime mitigation of this as a zero day, the answer is complicated because you would need runtime monitoring of dev machines, CI runners, staging, and production environments. This is an unusual combination, but I’ll endlessly support using the best runtime, agent based security you can get on cloud workloads. CADR exists precisely to stop these sorts of malicious zero days in your production systems, even if in this example the best case would’ve been an alert.

8. From an industry analyst perspective, what does the prevalence of these attacks do to the market? From one perspective, not that much. Point solutions that focused on preventing these attacks have existed for a long time, and none have found product market fit without being part of a broader set of solutions. However, within a broader set of supply chain solutions, I believe these features to be more critical than ever.
   
   Outside of traditional AppSec platform features, three categories that also get a small bump in usefulness are NHI, MDM (the Koi kind), and CADR, as monitoring these blind spots become more important, and there aren’t already a ton of great alternative solutions out there.

Consolidated Prevention Methods

1. Pin your dependency versions

2. Restrict pre and post install NPM scripts with your build tool

3. Use an allowlist model for egress on build systems

4. Use OIDC where possible for build secrets and/or regularly rotate them. Consider the right method for publishing to NPM.

5. Monitor developer, build, staging, and production systems for malicious activity. Warning: this can be noisy and expensive, especially for developer workstations and build stages.

6. A theoretically total visibility strategy here that I’m not recommending, but more to think through everything that’s possible:

   1. On the developer endpoint, monitoring plugins and open source versions and activities, alongside meaningful EDR that works here (easier said than done).

   2. On the non-human identity side, monitoring for unusual NHI token activity and unrotated credentials, indicating compromised credentials

   3. On the runtime side, monitoring build systems, staging, and production for detection of malicious activity.

Especially Useful Vendor Articles:

Updated, Latest Articles:

1. Aikido breaks down the initial attack and a compromised VSX (IDE) extension

2. Wiz shares insights to the amount of real compromise that happened from incident

Original:

1. Wiz - for their incident timeline, scope, and general analysis. Contains the payload that sets up local machines as a Github runner, and then the payload that the malware uses to scrape Github secrets by setting up a new workflow.

2. Aikido - their research covers some extra methods that are continuing to be used as part of the attack, such as workflow triggers in pipelines. Also everyone loves Charlie, and he likely found patient zero.

3. Socket, Step Security, Endor Labs and Gitlab all provide the best walkthroughs of the exploit logic and payload itself

4. Datadog - great diagrams of the attack, lots of examples of the exploit code, and their gharchive queries

5. I appreciated HelixGuard giving the JSON format of repos containing the secrets

6. Hackernews thread always has interesting takes to follow along with

7. Stream Security gave a good example of what detecting this behavior at runtime might look like. For clarity, they’re not the only tool that would detect this, but this is useful for seeing what the alerts look like.

Over the last two weeks I attended user conferences for two of the biggest presences in cloud and application security - GitHub and Wiz. Both conferences demonstrated smart leadership decisions, filling feature gaps with competitors alongside delivering innovations that highlight their platform’s strengths. In this article, I’ll cover both the product announcements and what these investments signal for the industry.

GitHub

At their user conference, GitHub showed agility in opening up their platform to third party LLMs, and a new focus on enabling AI code generation at enterprise scale. Additionally, many experimental features launched: from kicking off copilot workflows from Slack conversations, to using copilot to fix vulnerabilities. GitHub also showed continued focus on enterprise management features, enabling the product to work better at scale.

Bringing AI to Enterprise

The overarching theme of GitHub’s releases across security and the rest of the product were bringing AI coding tools to enterprises. It’s no secret that AI code generation has the strongest product market fit in AI, and it’s awesome to see GitHub immediately moving to deliver these features to large enterprises.

While tools like Cursor, Codex, and Claude Code are getting the benchmark attention, the reality for the average enterprise developer is much more restricted. Startups can freely experiment with almost any AI CLI tool that gives the best results and vibe code their minimal viable product, but enterprise teams have to approach the adoption of AI tools responsibly and at scale across massive, complex codebases.

In order to enable deploying AI tools at scale, most of GitHub’s non-security announcements were providing ways to solve management challenges with managed rules, custom agents, and knowledge bases across distributed teams and repos. GitHub is allowing teams to bring their own models, agents, and workflows to copilot, while giving managers the ability to orchestrate these tools across their enterprise, safely.

From a UX perspective, there’s an unavoidable tension between cloud based and local agentic coding flows, e.g. calling copilot via Slack to open a PR, versus using copilot CLI on a developer machine. GitHub is taking steps towards unifying these experiences, allowing developers to more easily navigate between branches as some coding tasks are completed locally, and others in the cloud through VSCode. Their early experimentations with custom agents and knowledge bases are essential to making the cloud only PR experience a reality.

Copilot Workflows Introduce a New Way to Scan

Now that AI code generation workflows can be kicked off asynchronously, GitHub is introducing a CodeQL analysis step that fits directly into the code generation process. For cloud based copilot generation workflows, CodeQL will get called as part of the pull request, checking for SAST vulnerabilities in the generated code. Copilot will then remediate any findings. GitHub is bringing these capabilities first to cloud generated code where the UX challenges will be less apparent. On the one hand, this promises a future where code security happens before the developer even sees the code. On the other, I haven’t found the workflow of calling a SAST tool via MCP to lead to great results when testing other tools.

The more fundamental threat GitHub’s releases pose to the application security industry is baking secure coding practices directly into the code generation workflow. AI coding is rapidly opening a new generation of what “shift left” means, as baking into the IDE becomes more about being baked into the context window itself. This shift is already hitting the market from companies like Backslash and Arnica, whose rules management approaches help developers produce secure code, without interrupting their workflows. I’ve been extremely impressed with some early hands on time comparing code generated with and without these tools.

Code Quality Rules

In addition to CodeQL running on AI generated code, the other major scanning announcement was the introduction of code quality rules, also using CodeQL. While the code quality feature seemed early, lacking code coverage and clear management workflows, many teams are more than happy to migrate off their legacy code quality tools and get a more unified solution. This allows GitHub to join the surprisingly few vendors that offer unified code quality and security solutions: Sonar, Aikido, and Codacy. For a long time end users have wanted these tools consolidated, but vendors haven’t quite delivered the maturity needed across both sides to completely win both end users over. As a developer tool first, it seems likely that GitHub takes the necessary steps to mature this solution.

Alongside these major announcements, most of the product improvements continue to make GitHub Advanced Security enticing to teams who may prefer the management features of standalone solutions. GitHub’s management capabilities have come a long way in the last year, adding features like internet reachability from Microsoft Defender and importing Sarifs from third parties. GitHub seems to be investing in expanding their partnership capabilities, getting data in and out of the platform more effectively to enhance vulnerability workflows. All of these releases point to making GitHub a more enterprise friendly and connected platform.

Wiz

As we covered in the Cloud Security Report, it’s clear that cloud security is evolving beyond the traditional set of CNAPP features and Wiz’s announcements reinforce this. During Wizdom they defined two clear goals: continued cloud security leadership, while expanding their footprint across a company’s broader security stack - from traditional vulnerability management to attacks surface management.

Goal 1: Continued Cloud Security Leadership

First, Wiz expanded their agentless threat detection capabilities into workloads. By checking network and application logs on disk, Wiz is now providing agentless runtime detection that goes beyond looking at cloud logs alone. While this approach doesn’t spot or stop attacks in real time, it’s a clever addition to agentless scanning capabilities. For workloads that customers can’t deploy agents on, this provides meaningful new visibility and defense capabilities.

When it comes to their introduction of AI to the cloud security offering (both in terms of securing AI and using it to enable defenders) Wiz has stayed competitive with other providers. Their posture discoveries (AI-SPM) are the most ahead of competitors, extending toxic combination discoveries through to Bedrock configurations and sensitive data flows. For enabling defenders with AI, summaries now exist for Defend issues, but the grouping isn’t as mature as I’ve seen elsewhere.

Wiz is also offering two AI agents: one focused on accessing and fixing issues, and another on incident response. I was able to do a hands-on workshop with MCP and the SecOps flow, and unfortunately like most AI use cases, the value was mixed. Sometimes I was able to one-shot some cool investigations, and at other times the agent would get stuck in a loop trying and struggling to accurately navigate the MCP tools calls. These are limitations I’ve experienced in most of my MCP usage and stem more from the client side than anything with the MCP tools themselves, but as the technologies improve, Wiz’s support for the capabilities will become more essential. The lead here is Wiz’s sophistication in rolling out MCP at scale with safe authorization flows for enterprises.

Goal 2: Entering New Markets

Beyond their core offering, Wiz has also rapidly extended into other markets - from ASM to SaaS security.

First, there’s entering the SaaS security market with a powerful Microsoft 365 integration. This extends the Wiz graph beyond current SaaS integrations like Github and Snowflake, to include workplace identities, file types, and threat detection. While at this point it’s not a full SaaS security platform, Microsoft 365 is at the heart of these tools. While Wiz’s offering wouldn’t be enough to replace a SaaS security solution, it will be a strong offering for teams who haven’t invested in that market.

Next, cloud security is quickly evolving into a larger vulnerability management project. Wiz’s release of ASM as a standout offering is a smart move towards this holistic future. For a long time, Wiz has done basic validation of external facing endpoints, providing screenshots of what the web application looks like from the outside. With ASM, they’re beginning the evolution towards a more robust testing solution that will likely lead to full external scanning - from DAST to Nuclei scanning styles. This moves Wiz towards providing end to end validation of if a vulnerability is exploitable.

For Wiz customers, this means that Wiz is delivering more actionable findings across your cloud, building upon the already great posture capabilities. Whether integrating third party tools, or deploying sensors on-premise, Wiz can now be used as a management platform for vulnerabilities across on-prem and cloud. Additionally, security leaders and practitioners wanting to experiment with the value of AI in their programs should encourage their teams to try the MCP integrations for themselves. While I found them of mixed helpfulness in my hands on time, the times it does work feel magical and are a glimpse of what future workflows will look like.

In many ways, Wiz’s feature investments capture the shift of the entire industry, where cloud security platforms are pivoting from a siloed function to a unified platform, and that the future of cloud security has left CNAPP behind.

Conclusion

Wiz and GitHub’s events demonstrate how cloud and application security solutions are evolving: application security is moving towards securing AI code generation, while cloud security is moving towards unified vulnerability and exposure management. What’s remarkable about both companies is their ability to execute on these developments at a large scale - a testament to letting strong teams continue building even in the midst of acquisitions.

After meeting with every cloud security provider on the market, practitioners, and buyers, we’ve mapped out the past, present, and future of cloud security into an actionable and industry defining report.

This report is for teams building their security programs, looking to understand the latest developments and approaches vendors are taking to help. It’s also for product builders, marketers, and investors looking to deepen their own understanding of the clouds security market evolution.

In the cloud security report, we argue that Cloud Native Application Protection Platforms (CNAPP) is defined in the present by code-to-cloud and runtime capabilities, and that the future will be defined by broader vulnerability management and incident response programs.

Ready to get the report? There are three ways to gain access:

1. Subscribe to Latio’s Substack (Link Below)

2. Signup for a Latio Pro subscription, which includes AI product searching, subcategory visualization, and maturity assessments

3. Get a link from a distributing vendor

We will also be sharing various snippets of the report from Latio’s Linkedin page, so follow along for updates. Thank you so much for your support of Latio and our hands on keyboard approach to analyst research!

Read more

One of the challenges I often faced as a systems engineer was dealing with developer endpoints. The security controls we had in place often just didn’t apply; whether it was exemptions from VPN policies, or trying to patch third party libraries, no one was ever quite sure what developer risks were or how to mitigate them.

I don’t typically do vendor specific pieces like this around product launches; however, Koi Security is a great example of identifying an overlooked security gap, and building a no-nonsense tool to fix it. Additionally, I wanted to write about some of the approaches to securing developer endpoints in light of the NPM malware attacks this week. In this article we’ll cover the challenges protecting & managing developer endpoints, and how Koi is tackling it.

The Developer Endpoint Gap

In 2024, I met with three founders on the verge of publishing a research project that covered a malicious VSCode extension called “Darcula.” This extension advertised as a dark mode extension (spoofing a known good one), but in reality sent the contents of every opened file to a remote host. To their surprise, this fake IDE plugin took off in popularity, and infected developer machines at some of the largest organizations in the United States.

In response to their surprising success, they published a project called ExtensionTotal (now Koidex), allowing you to check for malicious VSCode extensions.

Koidex is a quick way to query if an extension is malicious. While the success of their fake plugin might be surprising to some, IT teams have been long aware that their developer workstations are basically unprotected targets due to generous exemptions from their existing security tools. Furthermore, there are now many types of spoofing attacks targeting developers, from software supply chain takeovers to browser extensions.

In my Sysadmin life, there was an unbelievably common workflow when it came to onboarding developers: they would quickly ask for an exemption from any and all endpoint security controls. I once even had a developer get clearance on an Mobile Device Management (MDM) exemption before they accepted the role. This back and forth struggle between product leadership and IT leadership was never-ending, from false positive vulnerabilities to broken staging environments.

What is a Developer MDM

I use Mobile Device Management (MDM) as shorthand for a broad suite of tools focused on controlling end user devices, from phones to tablets to laptops and desktops.

Typically, IT teams try to consolidate their device management tooling into an Mobile Device Management (MDM) tool to manage:

1. User onboarding/offboarding

2. Maintaining approved applications

3. Deploying software

4. Handling routine tasks like password resets.

Traditional MDM tools are often part of securing endpoints alongside network and endpoint protection. However, these security functionalities typically break for developers as they either don’t support developer tools, flag a ton of false positives, or break existing applications.

While it can be easy to point and call developers primadonnas, the reality is endpoint security controls weren’t designed to make developers' lives easier. Older endpoint security solutions break several workflows: The VPN would break staging connections, SASE tools would break local host port-forwarding, EDR would break local application tools, vulnerability scanners would lead to nonsensical results as they detected application dependencies, and MDM would hinder productivity as they waited weeks for approval of every new developer tool.

Why Developer MDMs are an Emerging Need

CISOs spend millions on endpoint security controls, just for their most privileged workers to need exemptions. In the business world, developer productivity out ranks every other concern, and typically these machines are given wide exemptions to the normal controls, creating a massive blindspots in organizations. Unfortunately, the developer workstation has become the focal point of many modern attacks.

With open source and extension ecosystems becoming the defacto standards, it’s never been easier to trick developers (or even AI agents) into running malicious actions. While security solutions exist for each of these areas, but deployment and maintenance has been untenable. Open source malware protection requires a specialized wrapper, IDE extension adoption is always low, and MCP gateways are a pain to setup and maintain.

Threat Modelling Developer Endpoints

Just as developer workflows require unusually privileged access to their workstations, they’re also vulnerable to unusual attacks. It’s worth walking through some of these in detail:

1. AI Security Concerns. I’ve been pretty anti-FUD when it comes to AI model usage. After all, what real risk is there in an employee asking ChatGPT for help responding to an email? However, developers are vulnerable due to their specific ecosystems: MCP Servers, Hugging Face Models, and various prompt injection techniques via rules or public channels make them more susceptible than the average user. Security teams have been left scrambling for visibility into developer environments in order to detect if these attacks or vulnerabilities are being exploited.

2. Supply Chain Attacks. As open source repository takeovers grow increasingly common, with the latest series of supply chain attacks like the NX attack leaking many tokens that are still exploitable, this trend isn’t going to stop any time soon. Developer workstations are often the first place these packages are installed to build local versions of their applications, and traditional vulnerability scanning just doesn’t matter here, as patching application vulnerabilities is significantly harder than running an Adobe update.

3. Extension Manipulations. Developers often use specialized, privileged extensions in IDE and browser environments. Malicious IDE extensions continue to be deployed with little protection options available to teams.

Mitigating these risks is why I call Koi a developer MDM - existing device management tools exist for mitigating each of these concerns, but they’re all niche parts of other platforms making them difficult to deploy and maintain. AI security solutions provide visibility into MCP and model misuse, SCA tools sometimes provide a wrapper for safeguarding against malware installs, and secure browsers offer protections for chrome extensions. Koi is unique for bringing all of these tools together in a single place to make protecting developer systems obtainable for the average organization.

Everywhere I’ve seen, this developer endpoint security problem has been recognized, but the juice just is not worth the squeeze to prevent potential exploits. Setting up NPM wrappers, secure browsers, VPNs, and more just didn’t seem worth the risk prevention, especially knowing the developer backlash that would inevitably come. Furthermore, I’m unaware of any solutions that organically do malicious VSCode extension tracking. An example of how widespread this challenge is comes from Figma’s experience rolling out the open source solution Santa to secure their endpoints.

Designed to Give Visibility Where and How it Matters

Koi works by injecting endpoint visibility functionalities via existing agents - from ZScaler to Crowdstrike - to give visibility and control into developer workstations. Using this approach, they’re able to create some very native developer experiences without requiring a new agent deployment. This organically keeps developer workstations safe from malware, without compromising their workflow.

To highlight one specific aspect of the tool that shows the team’s focus, I often bring up how traditional AppSec advice is to patch as quickly as possible; however, the tradeoff here of using unstable packages or ones that have been taken over increases. For example, the XZ-utils attack was only mitigated because most people were not on bleeding edge Linux distros. Similarly, several vendors are now offering pipeline checks for not installing packages updated within a set amount of time.

Security teams have a well defined process for managing these risks in Windows environments, rolling latest patches to a small test group before deploying them system wide. However, these processes haven’t been automated for developer packages, which this example policy from Koi is doing for teams.

Subscribe now

Conclusion

These are my favorite types of security tools: ones that come from organic research into vulnerabilities, and building platforms around unknown niches that solve real organizational challenges. As attacks on developer tooling and workstations only increase, it’s exciting to see a solution that promises a holistic solution rather than more isolated features around particular angles. Shout out to the Koi team for trying to build a product that works for developers, not against them.

Thank you for reading Latio Pulse, if you’re a security practitioner, please consider taking this brief survey for our upcoming Cloud Security Report.

Guests:

• Jonathan Rau - VP and Distinguished Engineer at Query.ai

Summary Points:

• The traditional SIEM model is being challenged by new data management approaches.

• Data lakes are becoming essential for effective security data management.

• Cybersecurity mesh offers a new way to access and utilize data across platforms.

• Data hygiene is crucial for effective security operations.

• Security teams often lack the necessary data management skills.

• The role of data engineers is increasingly important in security teams.

• Organizations need to be proactive in their data governance strategies.

• AI is transforming how security operations are conducted.

• Understanding the complexities of security tools is vital for effective management.

• The future of cybersecurity standards is still evolving and requires adaptation.

Chapters

00:00 Introduction to Cybersecurity and Data Management

02:21 The Evolution of Security Information and Event Management (SIEM)

05:39 Challenges with Traditional SIEMs and Data Centralization

08:16 The Shift Towards Data Lakes and Pipelines

10:44 Understanding Data Mesh and Federated Search

13:28 Navigating the Complexity of Modern Data Architectures

16:22 The Role of Data Normalization and Processing

19:21 Future Trends in Cybersecurity Data Management

26:26 Making Security Analysts' Jobs Easier

27:45 The Distinction Between Vulnerability Management and Incident Response

29:16 The Role of Data Engineers in Security

34:26 Data Hygiene and Security Hygiene

36:49 The Need for Data Engineers in Security Teams

39:41 Challenges in Tool Selection and Integration

43:56 Understanding OCSF and Apache Iceberg

Over the last few months, we’ve seen an onslaught of AI Security acquisitions - all at strong margins for investors. One might look at these and think they’re all the same, but each actually tells a slightly different story. We just published an in depth AI security market report on each of these vendors, so it’s worth unpacking some similarities and differences between these acquisitions.

In this article, we’ll discuss the six recent AI Security acquisitions:

Breaking Down the Acquisition Strategies and Customer Value

The two acquisitions with the clearest use cases :

While each of these acquisitions makes a surprising amount of sense, there are two that bring clear and immediate value propositions to their customers:

1. SentinelOne’s acquisition of Prompt Security. Of the acquisitions so far, Prompt and Aim provided the most comprehensive AI security platforms. They had solutions for browsers, endpoints, APIs, network proxies - basically anywhere that AI lived, they could provide visibility and some amount of control. In part because of that breadth, they were weakest at advanced application protection use cases, as well as what’s being referred to as “semantic permissioning,” i.e. determining if access is appropriate for a user based on the context of their request.Prompt and Aim were both strongest on the endpoint side of the AI security equation: providing visibility and protection for end users navigating workplace AI tools from ChatGPT to Microsoft Co-pilot. Both provided strong detection capabilities via browser plugin and other forms of endpoint controls. This acquisition makes sense for SentinelOne, looking to use their endpoint technologies to provide greater visibility and control for employee usage of generative AI - a clear and immediate value to their customer base.

2. Cato Network’s acquisition of Aim Security. Similar to the SentinelOne acquisition, this makes a lot of sense to bolster Cato’s visibility and control of employee facing AI usage. SASE providers already have the necessary data to control AI Security usage, but they need the expertise to capitalize on the possibilities of their deep network controls. Aim’s familiarity with the data and the approaches will enable them to move quickly on the possibilities, expanding what’s possible on the AI front.

The acquisitions with more nuanced value adds

While Cato and SentinelOne’s acquisitions make straightforward sense for expanding endpoint security, the other acquisitions fit into broader AI acquisition territory.

1. Palo Alto’s acquisition of ProtectAI was an interesting one because it indicates their confidence in building the firewall use cases in house. Palo has already deployed a lot of network based AI security controls, and an acquisition here wouldn’t have been as helpful for them. Conversely, ProtectAI was very application focused - providing testing, red teaming, runtime protection, etc. This acquisition points to Palo’s continued diversification of a security portfolio, building out more of their capabilities around what might be considered application or cloud security.

2. Tenable’s acquisition of Apex is the least straight-forward of the acquisitions, and likely has more to do with the team than the product. Apex’s approach to AI security was heavily network based, providing some great capabilities around in-flight data protection and alerting, but they expanded into the more platform areas like APIs. Tenable’s acquisition notes here involve expanding to cover the “AI Attack Surface” which I interpret to mean incorporating Apex’s LLM detections from an attack surface management perspective, highlighting what AI technologies are in use. I would be shocked to see Tenable release a network proxy however to bring Apex’s capabilities in house.

3. Snyk’s acquisition of Invariant Labs is the most targeted of the acquisitions here, and is built around bringing runtime AI application protection in house. Invariant provided a series of tools for building application guardrails for AI applications. This seems to indicate that Snyk has a targeted product specific approach for getting into the real time AI protection game, which makes sense given LLM’s being non-deterministic, and static analysis providing less value (e.g. “you’re not begging the model hard enough not to be vulnerable to prompt injection!”). Snyk’s focus here is an early indicator of application security vendors focusing more on AI development and AI protection than the larger AI platform offerings, which makes sense.

4. CrowdStike’s acquisition of Onum is a pure data play rather than having much to do with AI security. CrowdStrike’s backend data model has heavily evolved over the last ten years, and the acquisition of Onum is about that continued evolution - from batch oriented SIEM architecture, to faster processing of telemetry. This is an important step in their ability to function as a modern holistic data platform that can process massive diverse logs at scale.

Key thoughts on the AI security market for companies and customers:

1. The AI Security platforms have set themselves up well for acquisition success, especially for the massive endpoint security market. While installing an additional agent or browser plug–in was a tough pill to swallow for the capabilities by themselves, they’re well accepted in the context of existing platforms.

2. Palo and Snyk’s acquisitions are the most forward thinking, as the real long term risk resides in letting non-deterministic outputs loose with sensitive user information. CISO’s continue to worry about employee AI usage falling in line with company policies, but it’s difficult to see how much longer this concern lasts outside of being just another flavor of DLP. For unregulated industries, an employee using LLM carries little more risk than a search engine.

3. It’s a go big or go acquisition time for the AI Security market. Noma’s fundraising of 100 million dollars suggests a bet on a distinctive AI Security platform that can rise as the “next CNAPP” opportunity, but there are several rivals who have yet to make the decision.

4. There’s an interesting subtext here as well that every acquisition is also in some way an “AI acquisition” as companies look to aqui-hire specialist talent, and the investor story needs some AI juice to get it to the finish line, regardless of what the current product does.

5. Creating a strong brand that sets you apart is critical for a winning business strategy- there are a ton of startups here, but the ones getting acquired quickly and at a premium are the ones with the biggest names and most hype behind them. As I stated in our Black Hat summary, AI Security at the moment is really whatever you say it is as best practices have yet to be established, so brand and trust carry more weight than product details.

1. Omer Yair - Co-founder of Raven.io

2. Martin Torp - Co-founder of Coana (Now part of Socket.dev)

Summary

In this conversation, the hosts explore how reachability technologies help in vulnerability management, the challenges faced in implementation, and the best practices for choosing the right approach. The discussion also highlights the significance of network reachability and function execution in assessing risks, as well as the importance of vendor comparisons in the cybersecurity landscape.

Takeaways

Reachability is about determining if a vulnerability is relevant to an application.

The goal of reachability is to assess exploitability.

Static analysis is simpler and does not require a running application.

Runtime reachability provides real-time insights into application behavior.

Network reachability helps prioritize vulnerabilities based on actual risk.

Function execution during runtime indicates the highest priority vulnerabilities.

Choosing between static and runtime reachability depends on organizational constraints.

The volume of CVEs is increasing, making effective prioritization essential.

Understanding vendor capabilities is crucial for effective reachability analysis.

Performance monitoring tools like Grafana can help assess the impact of security sensors.

Chapters

00:00 Introduction to Reachability Technologies

01:39 Defining Reachability and Its Importance

04:38 Exploring Static vs. Runtime Reachability

10:23 Diving Deeper into Static Reachability

19:02 Understanding Runtime Reachability and Its Types

26:19 Understanding Runtime Function Execution

28:33 Static vs. Runtime Analysis: A Complementary Approach

34:23 Choosing the Right Reachability Method

37:32 Challenges in In-House Vulnerability Management

39:47 The Importance of Effective CVE Management

42:45 Navigating Reachability Analysis Challenges

45:45 Optimizing Scan Times and Performance

50:47 Performance Insights and Attack Path Considerations

• Dor Sarig - Co-Founder of Pillar Security

• Vrajesh Bhavsar - Co-Founder of Operant AI

In this episode, the hosts discuss the critical aspects of AI security with industry experts. They explore the unique challenges posed by AI technologies, the role of CISOs in navigating these challenges, and the emerging threats that organizations face. The conversation emphasizes the importance of data control, compliance, and the need for robust testing and red teaming strategies. The experts also highlight industry-specific concerns and the future of AI security tools, providing valuable insights for organizations looking to secure their AI applications.

Takeaways

• AI fundamentally changes how we approach security.

• Protecting sensitive data and models is crucial.

• Security must enable innovation, not hinder it.

• Data is now executable, increasing risks.

• CISOs need to focus on compliance and data control.

• Emerging threats require new security strategies.

• Testing AI systems is complex and requires new methods.

• Industry-specific regulations impact AI security needs.

• Collaboration between security and data teams is essential.

• The future of AI security tools is evolving rapidly.

Chapters

00:00 Introduction to AI Security

02:29 Understanding the Shift in Security Paradigms

05:18 The Rapid Evolution of AI Technologies

07:45 CISO Perspectives on AI Security

10:13 Top Concerns in AI Security

11:59 Emerging Threats and Attack Vectors

14:27 Data Governance and Compliance Challenges

17:21 The Role of Security Teams in AI Programs

22:30 Collaboration Between Security and Data Science

23:39 The Importance of Data Control in AI Security

25:00 Understanding Risks in AI Security

29:02 Identifying Malicious vs. Benign Activities

31:26 The Role of Testing Infrastructure in AI Security

33:45 Industry-Specific Security Concerns

35:52 Red Teaming and AI Security Testing

39:10 The Need for Comprehensive Threat Modeling

41:21 Data Security in the Age of AI

In this conversation, James Berthoty, Kyle Polley from Perplexity, and Ariful Huq from Exaforce explore the complexities of security operations, focusing on the role of Security Operations Centers (SOCs), the integration of AI, and the evolving landscape of cloud security. They discuss the motivations behind purchasing SOCs, the importance of compliance, and the challenges faced by security teams in managing alerts and incidents. The conversation highlights the potential of AI to enhance SOC functions, reduce alert fatigue, and improve detection engineering, while also addressing the need for context in security operations. The discussion concludes with insights on the future of security data and the operationalization of detection engineering.

Takeaways

1. The initial push for SOCs often stems from compliance needs.

2. Understanding the budget is crucial when considering SOC options.

3. AI can significantly enhance the efficiency of SOC operations.

4. The integration of CNAPP and SOC is becoming increasingly important.

5. Contextual information is vital for effective incident response.

6. MDR solutions can be beneficial but may lack the necessary context.

7. Detection engineering requires a blend of security and software engineering skills.

8. Alert fatigue is a significant challenge for SOC teams.

9. The future of security data will encompass more than just logs.

10. AI has the potential to democratize security operations and improve analyst capabilities.

Chapters

00:00 Introduction to Security Operations

01:31 Understanding the Need for SOCs

05:42 The Role of CNAP in Security

08:34 Balancing SOC and CNAP Solutions

10:08 Traditional SOC Roles and Responsibilities

11:45 The Evolving Nature of SOC Teams

13:49 Contextualizing Alerts in Security

15:32 Integrating AI into SOC Operations

20:52 Enhancing Analyst Efficiency with AI

25:39 Learning from Past Investigations

27:06 The Importance of Threat Hunting in SOCs

29:43 Leveraging AI for Threat Intelligence and Detection

31:02 Modernizing SOC Skills and Detection Engineering

35:00 Reimagining Detection Engineering with AI

38:43 The Role of Data Normalization in AI Models

40:48 The Future of AI in Security Operations

43:12 The Evolution of SIEM and Security Data Lakes

Guest: Yoad Fekete (ex-Co-Founder & CEO, Mirror Security; now leads Security & Infrastructure at Lynx Security)
Hosts: James Berthoty & Charrah
Recorded: Wednesday, June 4

Why we wanted Yoad on

Mirror Security caught our eye back in 2022 for one reason: it tackled SolarWinds-style software-supply-chain attacks head-on, instead of stopping at familiar SCA vulnerability scans. Myrror had the rare combination of genuinely differentiated and useful technology. Two years (and one graceful shutdown) later, Yoad has a rare 360-degree view of what happens when brilliant tech meets a market that just isn’t ready.

Conversation highlights

0:17 Yoad’s background: Microsoft IR after SolarWinds → co-founding Mirror to catch supply-chain intrusions early

4:14 Why “traditional” SCA tools don’t flag injected build artifacts—and how Mirror’s binary-to-source matching tried to fix that

9:18 Early market signals vs. real product-market fit: the danger of mistaking enthusiasm for intent

15:35 Founder-led sales lessons: when a two-week POC needs to end at two weeks

26:20 How to judge pivots: technical edge, ecosystem partnerships, and the “three-year-contract” wall

51:45 Recognizing shutdown flags: stagnant pipeline, long sales cycles, and repeated VC “no’s”

56:23 Yoad’s three red lights before closing: 1) zero VC appetite, 2) no pipeline growth, 3) POCs that don’t convert

Five takeaways you can use today

1. “Cool” isn’t a buying signal
   If the prospect understands your tech and still won’t sign, it’s time to revisit the problem you solve.

2. Own the first sales yourself
   Hiring reps won’t save a product the founder can’t sell; use outside experts only to tighten the motion.

3. Two-week POC rule
   Value uncovered after week two rarely tips a deal—set a stop date and stick to it.

4. Plan for the acquisition audit
   If a big-box buyer mainly wants your team, a fully remote, distributed headcount can complicate the offer.

5. Graceful shutdowns take cash
   Budget early for vendor obligations and employee support; you owe the team a soft landing before worrying about yourself.

What’s next for Yoad

He’s publishing weekly LinkedIn essays on founder lessons, cybersecurity GTM strategy, and supply-chain security—worth a follow if you’re iterating on a security startup or wrestling with product-market fit.

🎧 Listen to the full episode wherever you get your podcasts, and let us know which insight resonated most.

After months of vendor briefings, test drives, writing, and design, I’m thrilled to be sharing the 2025 Latio AI Security Report.

Security practitioners have been searching for a resource that clearly describes both what AI security challenges exist, and what solutions the market has provided. As part of this report, we surveyed numerous security leaders and found a consistent response: interest in AI Security is high, but it’s still unclear what the actual problems are.

This report brings Latio’s characteristic practitioner focused mindset to the problem, highlighting what challenges are out there, and clearly stating the maturity of various vendor offerings to the challenges. Unlike the AI-TRiSM mega category, we’ve split the market into three overall categories:

1. End User Data Control

2. AI Posture Management

3. AI Application Protection

In this report, we also explore what emerging AI capabilities are being deployed from various vendors, and delineate between AI Native offerings, and AI leading ones.

You can download the first five pages of the report here, or become a paid subscriber for access to the full report.

Read more

This post was completed in collaboration with the team at Sweet Security who let me use their product to show their runtime CNAPP capabilities and asked me to speak honestly about the pros and cons of the platform. Also, to see a demo of Sweet and many other Cloud Security tools, tune in to the Cloud Security Showdown today!

It’s exciting to see Cloud Native Application Protection Platforms (CNAPPs) evolve beyond their endless posture management (CSPM) origins. The idea of a runtime-first CNAPP is appealing to anyone who expects their cloud security solution to actually detect and stop ongoing attacks rather than focusing on only the discovery of posture related issues and potential vulnerabilities.

In 2025, endless posture scanning is played out and security teams need ways to reduce noise and make cloud security alerts actionable. That concept of runtime actionability has implications for both posture and runtime detection events. I suspect people will use these new breeds of runtime oriented solutions as either augments to their existing CSPM solutions, or as standalone solutions, depending on the specifics of their environment and coverage capabilities.

In this report, we’ll first talk about where “runtime CNAPPs” fit in the overall landscape of security products, then discuss what makes Sweet Security’s offering exciting for cloud security, and finally, what use cases would not be a good fit.

What is Sweet Security?

Sweet Security is positioned in the growing cluster of runtime-first CNAPP solutions, with capabilities growing into the category I refer to as Cloud Application Detection Response (CADR). Sweet is meant to enable meaningful detection and response in cloud environments. They stand out for how they approach detection and response, especially when it comes to reducing alert noise and helping SOC teams understand what actually happened during an incident. Additionally, their detection methodology is genuinely unique among anomaly based detections, with some pros and cons.

Where Sweet Fits in the CNAPP Landscape

Before getting into the product specifics, it’s worth briefly reviewing the broader CNAPP category. Many platforms in this space attempt to unify cloud posture management (CSPM), vulnerability management (CTEM), code scanning (ASPM), and runtime protection (CADR). The problem is, most of them either spread themselves too thin, or bolt on features that lack depth. Larger platforms have long failed to be the single pane of glass for everything, and that has led to weaker performance at the edges. As a result, many teams end up pairing specialized tools rather than relying on single platforms. The go-to example of this is Aqua (runtime) and Orca (posture) having a partnership, despite offering the same features on paper.

Sweet fits into the landscape as a strong option on the runtime side. It’s not trying to be everything from code to cloud to third party vulnerability management, but instead offers meaningful detection capabilities, vulnerability discovery & prioritization, and API security capabilities.

Personally, I’m a fan of this approach, and what is becoming a new category in Cloud Application Detection and Response (CADR). Instead of trying to pretend that all of these offerings are one massive tool (CNAPP), we can acknowledge that we’re really talking about four distinct clusters of capabilities, each of which are built for different security users. Every vendor chooses particular features from these clusters to implement, but it’s overly reductionistic to refer to them all as a single thing and assign a grade.

At the end of the day, securing large complex cloud systems requires some combination of four capabilities:

1. The ability to deeply scan and contextualize their code findings (ASPM). These tools are for helping developers fix issues with code.

2. Visibility of cloud assets with information from vulnerabilities to technologies being deployed (CSPM). These tools are for helping cloud engineers fix misconfigurations in their cloud environments.

3. Best in class cloud workload protection (CADR). These emerging tools are to make cloud security operations achievable - whether for traditional SOC teams or emerging product security incident response teams.

4. A place to consolidate vulnerability data for reporting and actioning (CTEM). These are for vulnerability management teams in large distributed environments. Whether or not this should be merged with CSPM I’ll leave up to the reader, I could go either way.

Unfortunately, CNAPP just means some amount of these four things is happening, which is why I prefer keeping the acronyms distinct. But in this case, I use Runtime CNAPP and CADR interchangeably - enabling best in class cloud workload protection will come with some CSPM functionalities that makes the tools competitive.

A brief note on identity and DSPM, I usually lump these features up into CSPM because they are extensions of the same data, but it’s fair play to argue for them as separate categories.

Runtime Detection: Where Sweet Shines

Let’s start where Sweet was the strongest. In testing, Sweet stood out for its approach to incident correlation. Where other detection tools tend to drown you in alerts, often firing off dozens of findings for a single attack sequence, Sweet does a much better job summarizing what happened into a single understandable attack chain. It ties together bash execution, container drift, file tampering, and network behavior into a coherent incident view.

If the main failure of operationalizing cloud security operations is the SOC not understanding cloud alerts, Sweet does a great job breaking down the attack.

For example, when running a series of Atomic Red Team tests, including container escapes and file manipulations, Sweet correctly identified each technique and grouped them into a single, understandable attack chain. The tool provided clear details about what was run, which pods were involved, and how the activity unfolded. It also offered full process logs for investigation.

The most fun part of testing Sweet is how it will call me out if it notices the attack not working. The drift and manual detections correlate behind the scenes to deftly craft an accurate story of what happened, even when that involves making mistakes. In the SOC, this context is critical and the difference between pinging the DevOps team one time with a complete story of what happened and fifteen times trying to track down a false positive. I also managed to get my test environment infected by a real attacker, but it was immediately clear what was happening in the environment.

It’s also worth mentioning how the detection capabilities cross between API, cloud and workload layers. Sweet applies this detection methodology across all of the attack layers to identify when attacks pivot into the cloud from the workload.

The ability to create custom detection rules is essential to security operations teams as well. You can define behaviors, like outbound calls to suspicious IPs, that should trigger alerts, allowing for tuning and proactive guardrails. SOAR capabilities are limited, but this is far ahead of where most security teams are at. Basic capabilities like killing processes work well but teams looking to build fully automated response pipelines should look towards the Torq integration.

Despite being a newer feature, application layer attack detection worked really well and was well summarized. In the above screenshot, I saw both some of my own application attacks, as well as some web crawlers trying to exploit non-existent PHP services. In keeping with the noise reduction, my actual attacks triggered stories, while the unsuccessful crawlers were logged without triggering incidents.

If you’re new to cloud security, you may not instantly recognize how cool the above screenshot attack story is. In isolation, a DevOps team member might look at the environment variables in a running pod, triggering an alert that an analyst has to go and hunt down; however, a DevOps team is never running an XML injection payload before doing that. This is a critical example of where the application layer enables meaningful response.

The ability for SecOps teams to get actionable application insights is what CADR is all about, and it’s awesome to see more from vendors.

It’s also worth briefly mentioning that unlike many other runtime focused providers, Sweet also provides support for Windows OS, enabling them to be a one stop replacement for your runtime security.

Where There’s Still Room to Grow on Detections

The attack summaries could also have pros and cons when striking that delicate balance between too much noise and not enough. Every meaningful test I conducted got a story created; however, some individual events would trigger a finding. To be clear, the sensor always detected the event, so custom alerting would still have caught the attack, but it wasn’t always rolled up into an entire incident. To be honest, due to the noisiness of most cloud detection tools, I think Sweet struck a good overall balance when deciding what to alert about as critical. Every security tool has to strike a balance on deciding what to service, and Sweet did a good job.

While it wasn’t in the UI at time of testing, I’m extremely excited for Sweet’s soon to be launched potential misconfiguration detection. One of the key challenges in cloud security in the SOC is differentiating interesting events from impactful ones; Sweet picks up a lot of activity that the security team might be interested in, but isn’t necessarily related to an attack. Automatically delineating between these events is awesome and helps give security teams real time visibility without clogging up their alerts.

For example, in this test case I opened my cluster to the internet, and Sweet alerted me to it as a potentially suspicious change (in this case it was a classic oopsie in my terraform). Similarly, Sweet alerted me when I made some impactful IAM and S3 configuration changes. I’m excited for when these are surfaced as interesting misconfiguration findings rather than alerts.

Vulnerability Insights: Better than Average

Sweet includes vulnerability discovery and management capabilities amplified by runtime data and LLM based prioritization. At a basic level, Sweet can prioritize with the standard loaded/executed and network reachability distinctions. For the execution detection, reliability seemed based on language, and I didn’t see any function level reachability happening. This data carries into detection by optionally integrating your container registry.

However, the Sweet scoring was surprisingly accurate, understanding the nature of the packages and their common usages in applications, and prioritizing based on the context of the app.

With remediation guidance, the effected image layer is given, but the LLM remediation guidance was usually not that helpful. Some critical context for fixing container vulnerabilities, like base image versions, fix availability per distro, or whether a vulnerability is fixable in an upstream layer is missing. These are the kinds of details teams need in order to actually remediate issues at scale - and details most CNAPPs don’t provide.

Prioritization is present, and Sweet shows the patterns to highlight “toxic combinations” of exposed services and critical vulnerabilities. The implementation here is functional but basic. It’s also worth mentioning the biggest feature gap on the vulnerability side - the lack of agentless scanning.

Posture and Asset Management

Sweet includes some basic CSPM functionality, including compliance checks and hardening recommendations, but the depth is limited. Teams used to richer policy management or better search and customization will find these features underwhelming. Asset visibility is also skewed toward containerized environments, with gaps in coverage for unmanaged assets unless a sensor is deployed.

The topology view provides a helpful visual of how services connect with the sensor showing service to service traffic. I appreciated how all meaningful AWS assets are mapped in the topology instead of only showing workloads - it was great to see my critical lambda functions grouped in with the clusters. Unfortunately, only basic data exists for workloads without the sensor installed.

API Catalog and Identity Data

It’s been exciting to see API security grow into a feature of CADR, as gathering this application layer data has long been a missing point of context for understanding cloud workloads. Understanding API catalogues and regular traffic is foundational to understanding how workloads are operating and detecting application layer attacks. In testing, Sweet was able to helpfully group by either hostnames or service names to know exactly what API endpoints a service was surfacing.

Identity was an unexpected but strong functionality in the platform. Sweet does a good job highlighting non-human identities and associated risks thanks to its runtime visibility. It’s not building behavior-based IAM policies yet, but the foundational data is solid - especially the NHI detection

Integration and Workflow

Sweet offers the standard integrations for event forwarding, ticketing, and notifications. Nothing particularly novel here, but it covers the basics well enough for most SOC workflows. The workflow capabilities aren’t incredibly mature, but probably assume that is happening more in other tools.

Final Take

Sweet Security is a strong runtime detection platform, particularly for teams looking for better incident context and alert fidelity. Its ability to correlate attacks and reduce noise is a clear strength. Especially for teams looking for a simple workload protection tool to enable their SOC and Cloud Security teams to better respond to runtime alerts, they have a strong offering.

As I’ve written elsewhere, I’m not a believer in the all-in-one CNAPP Megazord that gobbles up the security budget; however, if you're looking for that full feature list CNAPP replacement, i.e. something that has a check the box offering on everything from your asset and vulnerability management, compliance posture, IaC scanning, and code security, Sweet does not have all of these capabilities. The runtime piece is more mature than most of the larger competition, but the other areas are less developed.

Rather than being a drawback, I think these solutions are especially well paired with robust application security scanning solutions that surface vulnerability findings to developers. As part of a layered approach that includes a solid ASPM or shift left application security tools, Sweet is the runtime complement to secure the applications once they’re deployed. I believe teams with cloud native architectures should adopt a strong ASPM platform alongside a runtime CNAPP (or CADR) in order to get true code to cloud coverage and application protection. For larger enterprises with highly distributed environments I typically recommend separate CSPM, CADR, and ASPM platforms to allow each to really get operationalized to its fullest extent.

Overall, Sweet is a great tool for teams looking to get runtime protection of their cloud environments. It’s not the best tool for teams looking primarily for basic cloud asset visibility and vulnerability management, or for establishing code to cloud pictures for vulnerability remediation; however, I don’t want to sell the CSPM features short either, they’re pretty good. My practitioner preference has always been keeping these tools distinct where possible: CSPM, ASPM, and CADR. I would certainly include Sweet in any evaluation for runtime oriented cloud security capabilities.

Let’s back up and answer the question, “what is a runtime CNAPP?” The answer is a tool that helps you deeply understand your cloud workloads, and that you can trust to find attackers in your environment. And that’s Sweet.

Takeaways

• Container security is crucial in today's software development.

• Low CVE images help reduce known vulnerabilities.

• Docker's ease of use contributed to its widespread adoption.

• Runtime protection is essential for securing containers.

• Understanding the architecture of containers is key to security.

• Compliance frameworks often drive security practices.

• AI poses new challenges for security teams.

• Holistic security approaches are necessary for effective protection.

• Regularly rebuilding and redeploying images is vital for security.

Chapters

00:00 Introduction to Container Security

01:45 Understanding Containers and Their Functionality

07:05 The Evolution of Software Appliances

08:49 The Rise of Docker and Its Impact

12:45 Addressing Vulnerabilities in Container Images

16:00 Runtime Security and Unknown Vulnerabilities

18:26 The Need for Coupling Security Solutions

21:31 The Misconception of Containers as VMs

24:56 The Importance of Regular Redeployment

26:52 Building Secure Software Components

28:37 Tools for Software Composition

30:42 The Role of Base Images in Security

31:17 Runtime Protection with Adara

36:38 Micro-VMs and Container Security

40:27 The Impact of AI on Security

45:23 The Future of Secure Computing

In this episode, we go deep on eBPF and what it actually takes to build reliable, performant runtime detection, beyond the buzzwords. James and Charrah are joined by Daniel Pacak, a longtime engineer in the cloud security space whose work spans Aqua Security, Cycode, RAD Security, and now Miggo. Daniel brings years of firsthand experience building eBPF sensors and walking the line between kernel-level complexity and practical detection coverage.

We open with Daniel’s journey into runtime security, beginning with his early work on Aqua’s Tracee project and continuing through multiple startup roles where he helped shape eBPF-based detection systems. He shares candid insights about the challenges of kernel instrumentation, the tradeoffs of performance versus visibility, and why function-level detection is so difficult but increasingly important.

Key discussion points include:

• Why runtime protection historically underperformed on Linux

• How vendors differ in their approaches to eBPF integration

• The technical realities behind stack unwinding, kernel hooks, and symbolization

• What ADR (and CADR) really means from a backend detection perspective

• Common misconceptions around eBPF and what it can (and can’t) do

• Why the industry lacks a common SDK or standard framework for building sensors

• Practical advice for evaluating vendors’ claims and assessing impact in real-world clusters

Daniel also walks through his thinking on why some tools overload the node with too much local processing, and what a healthier architecture looks like, particularly for teams focused on tuning alerts and scaling reliably.

The episode closes with a reminder that learning eBPF is a long road, but one with real payoffs for engineers interested in modern detection systems. And for security teams trying to figure out if eBPF tooling fits into their environment, Daniel gives straightforward guidance: test it in a real cluster, give it time to run, and measure both what it detects and how it performs.

Follow Daniel’s work on GitHub or LinkedIn.