Application Security Testing Blogs

Dek: A self-propagating npm worm poisoned hundreds of packages and spread through legitimate publishing workflows. The incident exposes a critical distinction for software supply chain security: build provenance can be valid even when the source entering the build is malicious.

Based on public reporting available as of August 5, 2026, at 10:19 a.m. Central Time. Package and version counts may change as researchers continue investigating.

What happened

On August 4, a self-propagating npm worm spread from packages in the widely used keyv and cacheable ecosystem into packages controlled by multiple unrelated organizations.

SafeDep confirmed 2,234 poisoned versions across 444 package names and reported that the worm reached 12 organizations in less than four hours. Four foundational affected packages—keyv, flat-cache, file-entry-cache, and cacheable-request—collectively receive approximately 1.88 billion downloads per month.

Each malicious release added an npm preinstall hook that executed before installation completed. The payload searched developer machines and CI/CD environments for GitHub, npm, cloud, HashiCorp Vault, Kubernetes, database, and other credentials. It could also inspect GitHub Actions runner memory and use stolen npm publishing access to modify and republish additional packages.

Researchers also identified persistence mechanisms involving VS Code and Claude Code project configuration. Opening an affected repository in those tools could trigger malicious code independently of a normal package installation.

One of the most important response details is counterintuitive: the malware installed a monitor that could execute an attacker-controlled command when a stolen GitHub token stopped working. Teams therefore need to locate and remove that persistence mechanism before revoking or rotating credentials.

Why this matters

ChainDrop did not rely only on unsigned artifacts or an obviously unauthorized release process.

Some malicious packages were published through legitimate GitHub Actions and npm OpenID Connect trusted-publishing workflows. Those releases retained valid SLSA provenance because the authorized build system had, in fact, produced them.

The provenance was not technically false. It accurately identified the workflow that built and published the artifact. The failure occurred earlier: malicious source or workflow inputs had already entered the trusted process. As Socket summarized, provenance attested to build integrity, not source integrity.

That distinction matters for engineering and security leaders. Signing and attestation are important controls, but they cannot independently answer several essential questions:

• Was the source change reviewed and approved?
• Did the release correspond to an expected commit, pull request, and tag?
• Were workflow files or project configuration modified unexpectedly?
• Should this dependency be allowed to execute an install script?
• Did the build behave consistently with the package’s intended purpose?
• What identities and secrets could the build runner access?

A delivery system can be cryptographically verifiable and still faithfully build malware.

The business consequences extend beyond one poisoned dependency. Credentials taken from a developer workstation or runner can create access to source repositories, registries, cloud environments, clusters, secret stores, and downstream release workflows. What starts as a dependency incident can quickly become an identity compromise, a release-integrity problem, and an organization-wide response effort.

How teams can reduce the risk of similar incidents

Teams should treat provenance as one layer in a broader evidence chain rather than as a standalone trust decision. Provenance confirms how an artifact was produced, not whether the underlying source code is trustworthy.

Govern source and workflow changes. Protect branches, require independent review for release-related code, and apply additional scrutiny to package manifests, lifecycle scripts, CI workflows, editor tasks, and AI-agent configuration. A valid signature should not override an unexpected or unreviewed change.

Correlate releases with source events. Before permitting publication or promotion, verify that an artifact maps to an approved commit, pull request, tag, workflow version, and expected build identity. Unexpected patch releases or artifacts without corresponding source activity should be investigated.

Restrict install-time execution. Disable npm lifecycle scripts in CI where they are unnecessary. Where scripts are required, isolate their execution, monitor network and process activity, and explicitly allow only known behavior.

Use ephemeral, least-privilege identities. Prefer short-lived credentials with narrowly scoped permissions. A build that only needs to read dependencies should not have standing access to publish packages, modify repositories, enumerate cloud secrets, or reach production infrastructure.

Isolate runners. Use disposable build environments, minimize credentials present in memory, restrict outbound connectivity, and rebuild runners after suspected exposure. Long-lived, broadly privileged runners increase both the value of stolen credentials and the worm’s opportunity to persist.

Gate artifact publication and promotion. Evaluate more than signature status. Policies should consider source review, dependency risk, suspicious new scripts, unusual package behavior, scanner findings, and the relationship between the source repository and published artifact.

For this incident specifically, organizations should first hunt for the reported token-monitoring persistence, editor hooks, package IOCs, and unexpected releases. Credential revocation and rotation should then occur from a known-clean environment, followed by rebuilding affected systems and downstream artifacts.

How Harness could help

Harness positions software supply chain security as a combination of dependency governance, security testing, policy enforcement, artifact controls, and delivery evidence not merely the presence of an attestation.

Harness Supply Chain Security supports assessing software supply chain posture, governing open source dependencies using software bills of materials, and managing artifact promotion with SLSA attestations. Harness messaging also emphasizes workflows for rapidly responding to vulnerable or compromised components.

The broader Harness platform can enforce organizational policies through Open Policy Agent, apply security gates within delivery pipelines, use fine-grained access controls, and maintain audit trails. Harness Artifact Registry is designed to centralize artifacts and dependencies while enforcing quality and security standards.

Applied to an incident like ChainDrop, those capabilities could help teams:

• govern which open source dependencies and package versions are permitted
• enforce a minimum package-age policy to delay adoption of newly published dependency versions
• require security and policy checks before publishing or promoting artifacts
• correlate attestations with approved delivery processes
• limit problematic packages through automated policy enforcement
• identify where affected components are used
• preserve audit evidence for investigation and remediation

These controls would not make provenance infallible or guarantee prevention. They could, however, strengthen the surrounding guardrails, reduce exposure, improve visibility, and accelerate remediation when trust signals conflict.

The bigger trend

ChainDrop reflects three converging trends.

First, software supply chain attacks increasingly target identities rather than only source code. npm tokens, GitHub credentials, cloud identities, and CI/CD permissions let attackers move through the same trusted paths maintainers use.

Second, developer environments now include more executable surfaces. Package lifecycle hooks, IDE tasks, automation files, and AI coding-agent configuration can all become persistence or propagation mechanisms.

Third, security decisions increasingly require combined evidence. Provenance, code review, dependency intelligence, workflow history, policy results, and runtime behavior each answer different questions. None is sufficient by itself.

Harness take

ChainDrop shows that “signed” and “safe” are not synonyms. Modern software delivery needs to establish continuity of trust from the proposed source change through the workflow, artifact, promotion decision, and runtime—not simply verify the identity of the pipeline that produced the final package.

Closing

ChainDrop does not make provenance unimportant. It clarifies its proper role.

Attestations remain valuable evidence about how software was produced, but trustworthy delivery requires controls before and after the build: reviewed source, governed workflows, constrained identities, policy-gated artifacts, isolated execution, and evidence from runtime behavior.

Harness helps organizations connect these controls across the software delivery lifecycle so that a valid signature becomes one input to a risk decision—not the entire decision.

Key takeaways

• SafeDep confirmed 444 affected npm package names and 2,234 poisoned versions as of its August 4 analysis.
• The worm executed during package installation and targeted developer, CI/CD, cloud, registry, Vault, and Kubernetes credentials.
• Legitimate OIDC publishing workflows produced artifacts with valid SLSA provenance after malicious inputs entered the pipeline.
• Teams should remove the reported token-revocation persistence before rotating credentials.
• Provenance should be combined with source governance, policy gates, dependency controls, least-privilege identities, and runtime evidence.

FAQ

What is the ChainDrop npm worm?

ChainDrop is the name used for a self-propagating npm supply chain campaign that inserts credential-stealing malware into packages and uses compromised publishing access to infect additional packages.

How can malware have valid SLSA provenance?

Provenance verifies information about the build process and identity that produced an artifact. When an authorized workflow builds already-compromised source, the resulting attestation can be valid even though the artifact is malicious.

What should teams do if they installed an affected package?

Treat the relevant developer machine or build runner as potentially compromised. Hunt for the published persistence mechanisms and indicators first, then revoke and rotate exposed credentials from a clean environment and rebuild affected systems and artifacts.

Here's the uncomfortable truth about the Mythos era: knowing about a vulnerability and being able to neutralize it are two entirely different problems.

AI models like Mythos are finding vulnerabilities 10x faster than humans ever could. Project Glasswing participants discovered over 10,000 high and critical vulnerabilities in their applications. Firefox alone had 271 previously unknown zero-days exposed by Mythos. That's the good news.

The bad news? Most organizations aren't unprepared from a security standpoint. They're unprepared from an engineering standpoint. The bottleneck that matters isn't discovery—it's everything that comes after. When you're drowning in vulnerabilities you can't prioritize, remediate, and deploy fixes for, finding more vulnerabilities doesn't reduce risk. It just makes you more aware of how exposed you are.

This is where the real challenge lies: closing the gap between detection and deployment has become the defining challenge of the AI era.

The Discovery Isn't the Problem – Response Is

For years, the security industry has focused on finding vulnerabilities faster. Better SAST tools. More sophisticated scanning. AI-powered analysis. And it worked—SAST tools have been mainstream for two decades. Most organizations have multiple scanners running.

But here's what actually happens when you turn on a SAST tool: you instantly have thousands of vulnerabilities in your backlog. Then what?

You start with CVSS ratings, filtering for critical. You triage, asking which are real, which matter, who owns the code. You assign tickets to developers. They may or may not look at them. They may or may not know how to fix them. You may have to provide security training. Meanwhile, the vulnerability sits in a queue.

Once a developer actually fixes it in code, your security team thinks it's solved. But it's not. If this is a critical application with high DevOps maturity, the fix might deploy in hours. But for most organizations with average DevOps maturity or non-critical applications? That fix takes days or weeks to reach production.

So the real timeline isn't measured in hours. It's measured in days, weeks, sometimes months from discovery to production deployment.

Now introduce Mythos or another frontier LLM scanner. You're finding 10x the vulnerabilities. But you haven't hired 10x more security staff. Your developers haven't multiplied. Your CI/CD pipeline hasn't suddenly gotten faster. Everything after discovery remains the same. You've just made the backlog catastrophically larger.

This is the core problem of the Mythos era: AI accelerated discovery, but it didn't accelerate your ability to respond to that discovery.

The Real Framework: Security at Machine Speed

If machines are finding vulnerabilities at machine speed, your security program must respond at machine speed. This requires rethinking your entire vulnerability response lifecycle across five stages:

1. Understand Exposure — The moment a zero-day drops, you need to know immediately if you're affected and where. This means comprehensive software composition analysis (SBOM) and code analysis across all your applications. When Log4J hit, organizations without visibility took weeks to understand their exposure. With proper instrumentation, it should take hours or minutes.

2. Prioritize Vulnerabilities — Not all vulnerabilities are equal, but CVE scoring doesn't reflect your actual risk. You need exploitability analysis (EPSS), reachability analysis (is the vulnerable code path actually called?), and AI reasoning to cut through noise. Organizations report 90% noise reduction using these techniques.

3. Make Remediation Easier — AI-generated fixes are table stakes now. But the real acceleration comes from auto-generated pull requests with validated fixes. Developers don't need to understand the vulnerability or how to fix it—they just review the PR and click accept.

4. Protect Production Immediately — Don't wait for code fixes to deploy. Use virtual patching in your WAF to block exploitation while you fix the underlying issue. This applies every day, every year, not just during zero-day crises.

5. Verify and Prove Remediation — Automated audit trails prove you've taken action. This is critical for compliance, incident response, and forensics.

A global financial services institution implemented this framework. They had over 1,000 microservices and performed bi-weekly security patch cycles. Before automation, each patch took five days per application and 25 hours of engineering time. After implementing security response automation, patch time dropped to under two hours with nearly zero human effort. That's a 98% improvement. More importantly, if a zero-day dropped, they could respond almost instantly instead of scrambling for days.

The Dual Nature of the Problem: Security + Engineering

This is where most security vendors miss the mark. They focus entirely on the left side of the problem: finding vulnerabilities faster. But the real bottleneck isn't on the security side, it's on the engineering side.

This is both a security problem and an engineering problem. Your security team needs better visibility and prioritization. Your engineering team needs faster, easier ways to consume security findings, build fixes, and deploy them. Your DevOps team needs automated patching and virtual patching capabilities integrated into CI/CD.

The winning organizations treating this as a cross-functional problem. Security initiates, but engineering owns execution. The best customer example came from the engineering side of the house—they wanted faster deployment velocity and realized security response was the constraint. When engineering and security align around speed, that's when real progress happens.

What's Next: AI Agents Close the Loop

The next frontier is AI agents orchestrating the entire response. Imagine this flow:

• A zero-day agent monitors threat intelligence feeds and automatically flags new vulnerabilities in your dashboard when they're disclosed
• A triage agent automatically prioritizes vulnerabilities, applying EPSS, reachability analysis, and false positive filtering
• A remediation agent generates pull requests with validated fixes that developers can merge directly
• A virtual patch agent immediately creates and deploys WAF rules to block exploitation

This isn't science fiction. Organizations are running this today. The key is that each agent has full context—knowledge of your code, infrastructure, configurations, and deployment pipelines. Context is what makes AI agents deterministic and reliable instead of hallucinating random suggestions.

The Window Is Closing

The timeline for action is compressed. Frontier LLM capabilities like Mythos are currently held back—expensive, restricted access, re-released under pressure. But that won't last. Within months to a year, similar capabilities will become generally available. When that happens, attackers will have access to the same tools.

That's when your response speed becomes a competitive advantage. Not weeks, not days. Hours. Minutes. Seconds in some cases.

The organizations that move now—that build security response automation, that integrate security into their CI/CD pipelines, that treat this as an engineering problem alongside a security problem—will be positioned to respond. Everyone else will be scrambling.

The Mythos era isn't about panicking over a flood of zero-days. It's about fundamentally rethinking how fast your organization can respond to any vulnerability, anytime, anywhere. That's security at machine speed. That's what survival looks like.

Ready to close the gap between detection and deployment? Security response speed is your new competitive advantage. Learn how to build a vulnerability response framework that matches the pace of AI discovery.

FORM SUBMISSION THANK YOU MESSAGE

Thank You Message Copy:

"Thanks for downloading! You've taken the first step toward vulnerability response at machine speed. Check your email for the complete Mythos readiness assessment (just 11 questions) plus our vulnerability remediation playbook. See how a global FSI reduced patch cycles from 5 days to 2 hours with security response automation. Your security team can do the same. Questions? Our experts are ready to help you design your response framework."

Alternative (Shorter):

"Got it! Your assessment is on the way. While you wait, explore how security response automation closes the gap between zero-day disclosure and production deployment. Watch our live demo showing AI-powered triage, auto-remediation, and virtual patching in action. Or schedule a walkthrough with our team to see your vulnerability response velocity transformed."

AI has fundamentally changed software development.

Developers are writing more code than ever. AI coding assistants can generate features, tests, documentation, and infrastructure configurations in minutes. Engineering organizations are seeing meaningful productivity gains as AI becomes embedded throughout the software development lifecycle.

But there is a catch.

Security teams now face a difficult reality: application security was already struggling to keep pace with software delivery before AI arrived.

Now the gap is widening.

During a recent discussion on AI SAST, Rennye Shen, Senior Director of Product Marketing at Harness, summarized the challenge clearly:

"If you were struggling before with the pace of software development, you're probably going to break once your development organization adopts these tools en masse."

The problem isn't that AI created new security challenges.

The problem is that AI amplified existing ones.

Why Traditional SAST Is Struggling to Keep Up

Most organizations already run some combination of static application security testing (SAST), software composition analysis (SCA), and additional application security tools.

Yet many security leaders face the same outcomes:

• Thousands of findings
• Growing vulnerability backlogs
• Low remediation rates
• Frustrated developers
• Limited pipeline coverage

The issue isn't visibility.

The issue is action.

Security teams can find vulnerabilities. What they struggle with is helping developers resolve them quickly enough to keep pace with delivery demands.

As AI accelerates development velocity, this challenge becomes harder.

More code means more opportunities for vulnerabilities. Larger commits, faster release cycles, and increased deployment frequency create pressure on security workflows that were already stretched thin.

The Four Reasons SAST Programs Fail

1. Developers Don't Trust Findings

False positives remain one of the biggest obstacles to effective application security. When developers repeatedly investigate findings that turn out to be non-issues, trust erodes quickly. Security teams may view a 30% false-positive rate as acceptable. Developers do not. Once trust is lost, remediation rates decline.

2. Vulnerabilities Don't Get Fixed

Finding vulnerabilities is not the same as fixing them. Most developers are measured on shipping software, not performing security analysis. Without clear remediation guidance, security findings often become another item in an already overloaded backlog.

3. Business Logic Vulnerabilities Are Missed

Traditional SAST solutions excel at pattern matching. They identify known coding mistakes, insecure functions, and common weaknesses. But modern applications increasingly fail in more subtle ways. Business logic vulnerabilities, authorization flaws, and complex data flow issues often evade traditional scanning approaches because they require deeper contextual understanding.

4. Security Cannot Match Development Velocity

Many organizations only scan a fraction of their repositories and pipelines. The reason is simple. Traditional security tooling requires tuning, maintenance, and integration effort. As application portfolios grow, coverage often declines. The result is security visibility that scales more slowly than software delivery itself.

AI SAST Is Not One Technology

One of the most important lessons for buyers is that AI SAST is not a single category. There are two fundamentally different approaches emerging.

LLM-Native Security Testing

This approach uses large language models directly to analyze source code.

Its strengths include:

• Deep reasoning capabilities
• Better understanding of business logic
• Ability to discover novel vulnerabilities
• Rich contextual analysis

However, there are tradeoffs.

LLMs are probabilistic systems.

The same code may produce different results across scans. Hallucinations can occur. Findings may be harder to validate and explain.

AI-Assisted SAST

This model starts with a traditional deterministic scanning engine and applies AI to improve results.

Benefits include:

• Consistent findings
• Repeatable scans
• Easier workflow integration
• Greater auditability

The downside is that many implementations provide incremental improvements rather than fundamentally new detection capabilities.

This creates an important tension:

Reasoning versus reliability.

Three Myths About AI SAST

Myth #1: AI Eliminates False Positives

No security technology eliminates false positives completely. AI can reduce noise significantly. But uncertainty does not disappear. Instead, uncertainty changes form. Traditional scanners may generate false positives. LLM-based systems may introduce hallucinations. Security leaders should be skeptical of any claim that promises perfect accuracy.

Myth #2: AI Will Replace Traditional SAST

The future is unlikely to be either-or. Deterministic scanning remains valuable for CI/CD pipelines, compliance requirements, and auditability. LLM reasoning is valuable for code generation workflows and deeper vulnerability analysis. Most organizations will benefit from combining both approaches.

Myth #3: AI Is Always Correct

AI systems often sound confident. Confidence should never be confused with accuracy. Human validation remains essential, particularly when security decisions impact production systems. Trust and explainability will remain critical requirements for AI-driven security tools.

Five Questions Every Buyer Should Ask

When evaluating AI SAST platforms, focus on outcomes rather than marketing claims.

1. Can it secure AI-generated code?

The most important security shift may occur before code reaches a repository.

Can security testing happen directly within AI coding workflows?

2. Does it actually reduce noise?

Ask vendors for measurable evidence.

How much reduction in false positives do customers experience?

3. Can it detect business logic vulnerabilities?

Modern applications require contextual analysis.

Security tools must move beyond pattern matching.

4. Does it improve remediation?

Detection without remediation provides limited value.

Evaluate how effectively developers can fix identified issues.

5. Are findings explainable?

Security teams, developers, and auditors all need understandable evidence.

Trust requires transparency.

The Emerging Hybrid Security Model

The most practical future is neither fully deterministic nor fully probabilistic.

Instead, platform teams should expect hybrid architectures.

Deterministic engines provide repeatability and governance.

LLM-based systems provide reasoning and contextual understanding.

Together, they address different parts of the software delivery lifecycle.

This mirrors a broader trend across platform engineering.

The goal is not simply to find more problems.

The goal is to operationalize security at the speed of software delivery.

What Platform Teams Should Do Next

Three priorities stand out:

Shift Security Earlier

As AI-generated code becomes more common, security controls should move closer to code creation itself.

Optimize for Remediation

The best security finding is the one that gets fixed. Measure remediation effectiveness, not vulnerability volume.

Prioritize Developer Experience

Security programs succeed when developers trust and adopt them. Reducing friction matters as much as improving detection.

Conclusion

AI is not replacing application security.It is forcing application security to evolve.

Organizations that continue relying solely on traditional SAST approaches will find it increasingly difficult to keep pace with AI-driven software development. The winners will be teams that combine reliable security automation with intelligent AI-assisted workflows that developers actually use.

Ready to see how Harness helps platform teams secure software delivery while maintaining developer velocity? Explore Harness Security Testing Orchestration and AI-powered software delivery solutions.

FAQ

What is AI SAST?

AI SAST combines artificial intelligence with static application security testing to improve vulnerability detection, reduce noise, and accelerate remediation.

How is AI SAST different from traditional SAST?

Traditional SAST primarily relies on deterministic pattern matching. AI SAST adds reasoning, contextual analysis, and automated remediation capabilities.

Can AI SAST eliminate false positives?

No. AI can reduce false positives but cannot eliminate them entirely.

What is LLM-native application security testing?

LLM-native testing uses large language models directly to analyze source code and identify vulnerabilities.

Why is AI-generated code creating security challenges?

AI accelerates code production, increasing development velocity and creating more opportunities for vulnerabilities to enter software pipelines.

Can AI SAST detect business logic flaws?

Some AI-based approaches can analyze complex application behavior and identify business logic vulnerabilities that traditional tools may miss.

Will AI replace traditional application security testing?

Most experts expect hybrid approaches that combine deterministic scanning with AI-powered reasoning.

Modern application security goes from code to runtime. Vulnerabilities are found at every stage of the software development lifecycle (SDLC) - in the code developers write, open source packages they pull in, container images they build, and cloud infrastructure where it all runs. But finding vulnerabilities is no longer enough. With attack surfaces sprawling across pipelines, registries, and production environments, the harder problem is fixing the vulnerabilities that actually matter.

Understanding what’s important increasingly depends on correlating multiple data points. A critical CVE buried in a dependency looks very different depending on whether the vulnerable function is actually reachable, the library is used in production, or the affected service is internet-facing. Without runtime context, security and development teams are often left triaging noise instead of actually reducing risk. And fixing vulnerabilities discovered in production can be challenging without being able to follow the trail back to the repo and line of code where the vulnerability can be found.

No matter where application security lives in your organization - and increasingly, it lives in more than one place - Harness and Wiz are working together to make sure you're covered. Whether your team is shifting left from cloud security or pushing right from the development pipeline, integrating Harness and Wiz brings code and runtime findings together so you always have the context you need to act.

Shift Left, Protect Right. Who Owns Application Security?

Application security used to have a clear owner. The AppSec team ran the scanners, triaged findings, and created tickets for developers. But "shift left" has been pushing security earlier into the development process and ownership has been migrating toward the teams that actually write and ship code. Today, the DevSecOps or platform engineering team owns application security tooling in many organizations. They're the ones who know exactly where a vulnerability lives in code, who owns it, and how to get developers to fix them.

But as applications move to the cloud, cloud security and infrastructure teams have a stake in application security outcomes as well. They're the ones with visibility into what's actually running in production - what's internet-facing, what's over-privileged, what's actively being exploited. Cloud security platforms have expanded their focus from purely infrastructure and runtime back through the SDLC to code. For many cloud teams, application security isn't a handoff; it feeds into their cloud risk picture.

The result is that application security now has multiple stakeholders with different vantage points. DevSecOps teams see risk through the lens of the CI/CD pipeline and the developer workflow. Cloud security teams see it through the lens of the deployed environment and the blast radius of a breach. Neither view is complete on its own. The good news is that these teams don't have to choose between their tools or their workflows. They need integration that lets each team work in their context while sharing the signals that make both more effective.

Integrating Wiz Code into CI/CD Pipelines with Harness STO

DevSecOps teams need to expand right. SAST and SCA tools often generate more findings than any team can fix. Runtime context helps separate signal from noise. Knowing that a vulnerable service is actively internet-facing or that a dependency with a critical CVE is actually loaded in production changes how a team prioritizes. Without it, developers are left triaging based on CVSS scores alone. With it, they can focus effort where exposure is real and the risk in production is highest.

Harness Security Testing Orchestration (STO) makes it easy to orchestrate Wiz Code across your CI/CD pipelines. With a pre-built integration, you can deploy Wiz Code in just a few clicks instead of needing to create a custom integration or write custom scripts. Harness orchestrates Wiz Code alongside all your other scanners so you know your pipelines always get the required security tests, without needing to manually coordinate multiple tools.

Once Wiz Code is integrated, STO aggregates findings with other scanners in your pipeline, automatically deduplicating vulnerabilities so teams aren't triaging the same issue twice. The consolidated view means developers and security engineers can see the full picture in one place, understanding pipeline-level risk and assigning tickets to developers. In addition, Harness Policy as Code lets teams define and take action at the pipeline level instead of tool by tool, so decisions about what to fail a build on, what to flag for review, and what to pass through are applied consistently and holistically across every scan and pipeline.

Feeding Harness SAST and SCA Findings Into Wiz

Cloud security is pushing left - past runtime, past containers, all the way back to the code and open source packages that vulnerabilities originate from. The driver is enabling action. A misconfigured cloud resource or a vulnerable container image is more actionable when you can tie it back to the specific dependency introduced in a pull request, the developer who owns the code, and the pipeline that shipped it. Runtime findings without code context are just alerts. With code context, they become actionable work items that can be routed to the right person and fixed at the source.

Wiz Application Security Posture Management (ASPM) is designed to aggregate findings from across the SDLC and correlate them with runtime context - what's deployed, what's exposed, and what's actually at risk. By integrating Harness SAST and SCA scanner findings directly into Wiz, cloud security teams can connect the dots between a vulnerable open source package or insecure code pattern and the running workloads it affects. That correlation is what turns a list of CVEs into a prioritized risk picture that reflects what's actually happening in production.

For cloud security teams already working in Wiz, this integration means Harness SAST and SCA become part of their existing workflow rather than a separate tool to check. Code-level findings surface alongside runtime signals in the same platform where cloud risk is already being managed, analyzed, and acted on. Teams get broader coverage without adding friction, and the context that makes those findings meaningful - reachability, exposure, business criticality - is already there when they need it.

AppSec Is a Team Sport. Your Tools Should Be Too.

DevSecOps and cloud security teams are not generally not competing - they're looking at risk from different angles. One team lives in the development pipeline; the other lives in the cloud. Both need visibility into what the other sees to do their jobs well. When those views are siloed, findings get duplicated, priorities diverge, and the vulnerabilities that matter most fall through the cracks between teams.

Harness and Wiz close that gap from both directions. DevSecOps teams get runtime signals from Wiz Code inside the pipeline context where they already work, so they can prioritize fixes based on real-world exposure. Cloud security teams get code-level findings from Harness SAST and SCA inside the risk context where they already work, so they can trace production risk back to its source. Each team keeps their workflow. Both teams get the full picture.

The right combination of these integrations depends on how your organization is structured, where application security ownership sits today, and where you want it to go. If you're a Wiz customer evaluating how Harness SAST and SCA fit into your security program, or a Harness customer looking to bring runtime context into your pipelines, contact your Harness account team to understand how you can map the integrations to your specific environment.

We’re excited to share that Harness has been recognized as a Customer Educator in the Wiz Integration Network (WIN) Partner Index 2025—a new, data-driven benchmark highlighting the integrations that deliver the most value to joint customers in modern cloud security programs.

Published by Wiz, the WIN Partner Index provides a transparent, real-world view into the integrations that are essential to modern cloud security programs, based on real-world adoption and impact. It also establishes a clear industry standard for what constitutes a high-quality, customer-centric integration .

What It Means to Be a “Customer Educator”

Harness’s recognition as a Customer Educator reflects our commitment to helping security, platform, and DevOps teams not only integrate security into their delivery pipelines—but truly understand and act on it.

As cloud security becomes increasingly distributed across tools and teams, education and shared context are essential. Harness and Wiz work together to meet teams where they build and deploy software, enabling security insights to flow directly into CI/CD pipelines and developer workflows. The result: faster remediation, better prioritization, and security that scales without slowing innovation.

“At Harness, we believe application security has to be integrated early and continuously across the SDLC, and that requires an open ecosystem. This recognition from Wiz reflects our commitment to helping security, platform, and DevOps teams not only integrate security into their delivery pipelines, but truly understand and act on it,” says Monish Advani, Senior Director of Product Management for Application Security at Harness. “In addition to the security capabilities built natively into the Harness platform, our integration with Wiz brings critical cloud security context so customers can prioritize risk, automate response, and scale security with the flexibility to build the security stack that works best for them, no matter which tools they use. Together, we are helping teams deliver software more securely.”

Building on a Strong Partnership with Wiz

This recognition builds on a growing history of collaboration between Harness and Wiz:

• WINvaluable Award (2025): Harness was previously recognized by Wiz for delivering exceptional value to joint customers as part of its ecosystem of over 200 integrations.
• First Certified CI/CD Platform Partner: Harness became the first CI/CD platform vendor certified to partner with Wiz, reinforcing our shared vision of embedding security early and continuously across the software delivery lifecycle.
• End-to-End Security Visibility: Through Harness’s security capabilities—strengthened by our joint solution with Wiz and Traceable—customers gain deeper visibility from code to cloud, correlating risks across APIs, infrastructure, and runtime environments.

"The WIN Partner Index offers a new lens into how integrations perform where it matters most: in the hands of real teams," said Oron Noah, VP of Product, Extensibility & Partnerships at Wiz. "This inaugural report demonstrates the value Harness brings to educating customers. It's a great example of what's possible when partners align around a shared goal, building an open ecosystem where context flows freely and security becomes a team sport."

Learn More

Download the WIN Partner Index 2025 to see why Harness was recognized as a Customer Educator and explore the integrations shaping modern cloud security programs.

We’re proud to partner with Wiz—and even more excited about what this recognition means for our joint customers.

AI is proliferating across enterprise environments faster than security teams can govern it. From third-party LLM integrations to agentic frameworks like Model Context Protocol (MCP), most organisations have limited visibility into how many AI systems are running, what data they process, or what risks they introduce.

Why AI Security Posture Management Matters Now

Three realities are driving this to the top of the security agenda:

• Rapid, ungoverned adoption: AI integrations enter production through multiple vectors simultaneously - developer experiments, third-party SaaS with embedded LLM capabilities, and MCP servers that expose tools and data sources to autonomous AI agents - often without security review.
• Systemic lack of visibility: Most CISOs cannot accurately answer how many AI APIs are running in their environment. AI integrations do not announce themselves to security teams; they surface in compliance audits and incident investigations months after deployment.‍
• Sensitive data exposure at the AI layer: Every AI API is a potential data exposure point. Prompts carry confidential business context and personal information. Model responses can surface training data or infer sensitive attributes. Traditional API security tools were not built to address this risk.

Example: Shadow AI in a financial services firm

A quantitative analyst team integrates an LLM into their research workflow. The integration ships as a product feature. Six months later, a compliance review finds the endpoint is externally accessible, processes client PII, and transmits data to a third-party model provider outside the scope of the firm's data processing agreements. The AI system existed, processed regulated data, and created regulatory exposure - entirely outside the security programme's awareness.

The Framework: Discover - Understand - Assess Risk - Operationalise

Effective AI security is not a single capability - it is a continuous workflow across four phases:

01  Discover: Build the Complete AI Asset Inventory

Harness continuously discovers and classifies every AI asset from live traffic and API specifications - no manual registration required:

• AI APIs: endpoints connecting to external LLM providers (OpenAI, Google, Anthropic, Azure OpenAI)
• MCP servers and tools: discrete capabilities exposed to AI agents, including database queries and external API calls
• MCP resources: data sources exposed to AI agents, including files, documents, and structured data that provide context to AI workflows.
• Non-AI APIs:  APIs that interact with AI infrastructure - including calls to vector databases and RAG (Retrieval-Augmented Generation) data stores - that form part of the AI data pipeline

Shadow AI found by Harness is risk-scored, ownership-flagged, and surfaced for immediate security review. The finding moves directly into the vulnerability lifecycle with a URL, environment classification, and traffic record.

02  Understand: Map Sensitive Data Flows Across the AI Data Plane

Harness continuously analyzes AI API & MCP traffic to identify sensitive data types flowing through every discovered endpoint:

• Request payloads: prompts, user context, and input parameters carrying PII, financial data, or health information
• Response payloads: model outputs and generated content that may surface training data or infer sensitive attributes
• Third-party boundaries: every inference call to an external LLM provider is a data transfer event; Harness monitors exactly what data crosses the model provider boundary

When sensitive data appears in an AI endpoint for the first time, or is transmitted to an external provider, Harness surfaces a real-time Posture Event - giving privacy and compliance teams the window to act before an exposure becomes a breach notification obligation.

03  Assess Risk: AI-Specific Vulnerability Detection and Risk Scoring

Harness detects AI API & MCP tool vulnerabilities passively from live traffic - no active scanning, no disruption to production AI workloads. Detection covers:

• OWASP API Top 10: applied specifically to AI traffic patterns, including auth weaknesses, excessive data exposure in model responses, and missing rate limiting on LLM endpoints
• MCP-specific risks: tools exposed to the public internet without authentication
• Specification drift: shadow endpoints (traffic but no spec) and orphan endpoints (spec but no traffic) identified by continuous conformance analysis

Risk scoring applies AI-specific weighting: an unauthenticated, externally exposed LLM endpoint is simultaneously a prompt injection target, a data extraction vector, and a compute abuse surface. Scores are dynamic, recalculating as traffic patterns and sensitive data classifications change.

04  Operationalise: Integrate AI Posture into Security Workflows

Harness Posture Events feed connects AI security signals to the workflows security teams already run:

• Jira: vulnerabilities auto-generate tickets pre-populated with endpoint details, CVSS score, and mitigation guidance
• SIEM / SOC: real-time AI threats - prompt injection attempts, DLP alerts, anomalous model behaviour - flow into the SIEM for correlation; Harness provides the characterised asset context before the alert reaches the analyst
• Compliance evidence: every Posture Event is timestamped, filterable, and CSV-exportable, building a continuous audit trail without manual assembly

Custom notifications: privacy teams can alert on sensitive data to 3rd parties; SOC on risk score spikes; governance on new shadow AI assets

Maturity Model: Day 1 - Day 30 - Day 90

AI security posture management is a journey, not a deployment. Here is how organisations evolve:

Enterprise Extension: ServiceNow CMDB Integration

For organisations where CMDB governs asset lifecycle, Harness’s Service Graph Connector extends AI-SPM into ServiceNow. Key use cases:

• Change management: new AI APIs discovered by Traceable trigger a ServiceNow change request in 'Pending Review' state before accumulating production traffic
• Vendor risk: third-party AI providers are represented as vendor CIs linked to DPAs and risk assessment records
• Incident response: SOC analysts work on AI incidents with Traceable's threat intelligence and CMDB's organisational context simultaneously
• Compliance evidence: AI compliance questions answered directly from CMDB records populated by Traceable - no manual assembly
• Decommissioning: orphaned AI endpoints identified by Traceable's conformance analysis trigger governed retirement workflows; Traceable confirms the endpoint has gone dark

‍

The Bottom Line

Operationalising AI security is not about scanning prompts. It is about continuously discovering AI systems, understanding how they access sensitive data, assessing the risks they introduce, and integrating AI posture into the security operations that already exist.

The organisations that build this capability now will govern what others are still trying to find, detect exposures before they become incidents, and answer regulatory questions with data rather than approximation - continuously, not periodically.

Harness AI Security operationalizes this discover-to-remediate workflow across every AI asset in production.

If you’re delivering software in 2026, you’re caught in a swirl. AI-assisted coding is accelerating development. Cloud-native architectures are multiplying both microservices and the pipelines required to deliver them. And increasingly, it’s DevOps teams - not dedicated security teams - who need to catch vulnerabilities before they reach production. 

Bolting application security testing (AST) onto your pipelines kinda worked up until now, but with AI accelerating code velocity and cloud scaling complexity, this approach is breaking down. The problem isn't just integrating security tools—it’s the friction they create. Context switching between platforms, alert fatigue from noise, and slowing down pipelines to chase down false positives. Security still feels bolted on—an external gate rather than a native part of how you build and deliver software.

That's why we're bringing AST natively into the Harness platform. Today, we're excited to announce that Qwiet AI—the AI-powered SAST and SCA engine we acquired last year—is now available as Harness SAST and SCA (with 45-day free trial), with pre-configured security steps in Harness Security Testing Orchestration (STO) and full configuration and results visibility directly in the Harness UI. Security testing that feels like it belongs in your pipeline—because it does.

Introducing Harness SAST and SCA

Most AST solutions flood developers with thousands of findings—many of which are theoretical vulnerabilities in code paths that never actually execute in production. This creates alert fatigue and slows down pipelines while teams triage false positives. Harness takes a fundamentally different approach powered by AI and reachability analysis. Instead of flagging every potential vulnerability, we use our patented code property graph (CPG) analysis to understand how data flows through your application—identifying only the vulnerabilities that are actually reachable through execution paths in your code. This means:

• Fewer false positives, more actionable results—by focusing on reachable vulnerabilities, Harness dramatically reduces noise. Teams spend less time investigating theoretical risks and more time fixing issues that matter.
• Deep visibility into open source risk—Harness SCA goes beyond basic dependency scanning to identify reachable vulnerabilities in third-party libraries, showing you which CVEs in your dependencies are actually exploitable in your application's context.
• AI-powered remediation—Harness SAST doesn't just identify vulnerabilities—it helps fix them with specific, actionable fix recommendations that developers can apply directly, based on your application's architecture and the data flows that make the vulnerability exploitable. 

Harness SAST focuses on the vulnerabilities that actually execute in production instead of flooding developers with theoretical findings.

The result? Security findings that developers actually trust—and act on.

Why Pipeline-Native AST Matters 

There’s a dirty secret of application security: every AST tool can integrate with CI/CD. Every vendor claims they shift left. But application security programs still stall at ~20-30% pipeline coverage because the operational burden doesn’t scale. Manual configuration, the need to piece together findings across multiple vendors and tools, and the challenge of orchestrating the right security testing across 100s or 1000s of pipelines all contribute.

When security testing runs as a first-party capability inside your CI/CD platform, three things happen: 

1. Configuration becomes templated and reusable—you define security steps once and propagate them across pipelines at scale, eliminating the manual toil that kills AppSec coverage. 
2. Feedback loops collapse—findings surface in the same interface where developers manage builds, deployments, and rollbacks, removing the context-switching tax that causes security issues to languish. 
3. Orchestration becomes policy-driven—instead of configuring individual scanners, you define what security posture looks like and let the platform take the right actions based on pipeline-level outcomes. 

The result is security testing that actually operationalizes at the pace and scale of modern software delivery—where covering 80% of your pipelines is a matter of policy enforcement, not heroic manual effort.

Pipeline-Native SAST and SCA with Harness

Harness AST combines the accuracy and actionability of Qwiet AI’s scanners with the operationalization at scale on the Harness platform. 

Pre-Defined Security Steps

Along with API Security Testing, Harness SAST and SCA are now available as pre-defined security steps in Security Testing Orchestration. This eliminates the complex setup and configuration work typically required to integrate security testing tools with CI/CD pipelines, allowing you to add security tests in minutes rather than hours. Instead of spending hours configuring a SAST scanner with the right language runtimes, authentication tokens, and result parsers, simply add the 'Harness SAST' step to your pipeline and you're scanning. This standardized approach ensures consistent security coverage across all projects while removing the friction that often causes teams to skip or delay security testing in their CI/CD workflows.

Virtual Pipeline Builder

Having Harness SAST and SCA as pre-configured steps in the STO step library transforms pipeline creation into an intuitive visual workflow. Developers can simply drag and drop security testing steps directly into their pipeline stages in Harness's virtual pipeline builder, selecting from industry-leading scanners without writing YAML configurations, managing container images, or troubleshooting integrations. The visual interface automatically handles the underlying orchestration, allowing teams to see exactly where security gates fit in their deployment workflow and adjust them with simple parameter changes.

Understanding Pipeline Posture with STO

STO provides a unified view of all security findings, consolidating results from Harness SAST and SCA alongside any of the 50+ integrated partner scanners into a single dashboard. Rather than jumping between different tool interfaces or parsing scattered reports, teams can view all vulnerabilities for a specific pipeline or aggregate findings across multiple pipelines to understand their broader application security posture. 

But STO doesn't just aggregate findings—it provides the context developers need to act. For each vulnerability, you can see which pipeline introduced it, which deployment it affects, and what remediation Harness SAST recommends. You can also set exemption policies, track remediation over time, and understand your security posture across the entire application portfolio—all without leaving the Harness platform.

Viewing SAST and SCA Findings

Harness STO displays comprehensive details for every SAST and SCA finding directly in the Harness UI, eliminating the need to switch to external scanner dashboards or export reports. Teams can click into any vulnerability to access full context about the issue, its severity, affected files, and remediation guidance—all within their existing workflow.

For SAST findings, Harness visualizes the complete data flow for each vulnerability, showing the "source-to-sink" execution path that illustrates how untrusted data propagates through application logic and is ultimately used in a sensitive operation. This visual representation provides precise code-level context based on static analysis, helping developers understand not just where a vulnerability exists, but exactly how malicious input could flow through their application to create a security risk. By mapping the entire taint flow, developers can see each step in the vulnerable code path and identify the optimal point for implementing fixes.

Each finding includes AI-powered remediation guidance from Harness, which explains the vulnerability details, the security concept behind why it's dangerous, and specific steps to fix the issue in context. Rather than generic advice, Harness AI analyzes the specific code pattern and provides tailored recommendations that help developers understand both the immediate fix and the underlying security principle, accelerating remediation while improving the team's security knowledge over time.

Try It for Free Today

Ready to experience integrated SAST and SCA in your pipelines? Harness is offering STO customers a 45-day free trial to explore how native application security testing can transform your development workflow. You can add comprehensive code and dependency scanning to your existing pipelines using our visual pipeline builder, consolidate findings into a single dashboard, and leverage AI-powered remediation guidance—all without complex setup or additional infrastructure to manage.

Reach out to your account team to start your free trial today and see how Harness SAST and SCA eliminate the friction that traditionally keeps security testing out of CI/CD pipelines. 

Request a demo

Harness AI is starting 2026 by doubling down on what it does best: applying intelligent automation to the hardest “after code” problems, incidents, security, and test setup, with three new AI-powered capabilities. These updates continue the same theme as December: move faster, keep control, and let AI handle more of the tedious, error-prone work in your delivery and security pipelines.

What’s New in Harness AI:

• Human-aware incident analysis that correlates conversations with changes
• AI-driven API naming that reduces security noise
• Natural-language auth script generation for faster AST onboarding
• AppSec agent for querying security data and generating policies

Human-Aware Change Agent for AI SRE

Harness AI SRE now includes the Human-Aware Change Agent, an AI system that treats human insight as first-class operational data and connects it to the changes that actually break production. Instead of relying only on logs and metrics, it listens to real incident conversations in tools like Slack, Teams, and Zoom and turns those clues into structured signals.​

• The AI Scribe captures key decisions, timestamps, symptoms, and “right before this happened…” moments from live conversations, filtering out unrelated chatter.​
• The Change Agent uses these human signals to drive a change-centric investigation across deployments, feature flags, config, infra changes, and ITSM records, then produces evidence-backed hypotheses such as, “This checkout deployment changed retry behavior 12 minutes before the incident, and latency spiked immediately after.”​​

By unifying human observations with the software delivery knowledge graph and change intelligence, teams get a much faster path from “what are we seeing?” to “what changed?” to “what should we roll back or fix safely?” The result is shorter incidents, clearer ownership, and a teammate-like AI that reasons about both people and systems in real time.​ Learn more in the announcement blog post.

AI-Powered API Naming for Cleaner Security Signals

Effective application security starts with knowing what you actually have in production. Traditional API naming based on regex heuristics often leads to over-merged or under-merged API groups, noisy inventories, and false positives across detection workflows.​

This month, API naming in our Traceable product gets a major upgrade with AI-powered API semantics:

• API naming is now powered by LLMs that understand intent, behavior, and functional semantics, not just URL or path similarity. The result is more stable, meaningful API groupings that reflect how your services actually behave.​
• The LLM-driven results were baselined against custom naming rules from advanced users and achieved >98.7% average match in internal benchmarking.​
• With cleaner API groupings, teams see reduced false positives across vulnerability detection, AST, and runtime protection, and a less noisy API inventory that’s easier for security and platform teams to act on.​

For security leaders trying to tame API sprawl, this is a foundational improvement that boosts signal quality across the entire platform.​

AI-Based Auth Script Generation: Faster, Safer API Security Testing Setup

Authentication setup has been one of the most consistent sources of friction for application security testing. Manual scripting, validation cycles, and back-and-forths often create bottlenecks — and a broken auth script can quietly invalidate an entire scan run.​

To solve this, all API Security Testing customers now get AI-based Authentication Script Generation:

• Generate auth scripts by simply describing the scenario in natural language; AI produces a ready-to-use script in a few seconds, which you can refine, edit, or use as a base for existing scripts.​
• The feature works alongside existing flows, so teams can keep using form-based or code-based auth with identical behavior while layering in AI where it helps most.​​

The result is less time lost to brittle auth setup, faster onboarding for new apps, and fewer failed scans due to script errors.​

You can find implementation details and examples in the docs. 

Chat with AppSec Agent: Security Data, in Plain Language

Security and platform teams often know the question they want to ask: “Where is this component used?” “Which exemptions are still pending?” , but answering it requires hopping across dashboards and stitching together filters by hand.​

The new AppSec Agent makes this dramatically easier by letting you query AppSec data using natural language.

Here's what it does:

• In Harness STO, you can ask about security issues and exemptions, then drill into issue-level insights from STO results without manually navigating views or composing complex filters. Questions like “Approve all valid pending exemptions in this project of issue type secret” become a single prompt instead of a multi-step workflow.​
• In Harness SCS, you can query for artifacts, code repos, SBOMs, chain-of-custody, and compliance results, then even generate OPA policies with a single prompt to block components based on license risk or vulnerable packages. For example, “Create an OPA policy to block the deployment of components licensed under the GPL-3.0 license” or “Help me identify whether the chalk and xz-utils components are present in any of the artifacts in this project” are fully supported.​
• The AppSec Agent is available across all production environments and integrates directly with Harness Security Testing Orchestration (STO) and Software Supply Chain Assurance (SCS).

This is a big step toward making AppSec data as queryable and collaborative as the rest of your engineering stack. Learn more in the docs.​

How This Fits the Harness AI Vision

Harness AI is focused on everything after code is written — building, testing, deploying, securing, and optimizing software through intelligent automation and agentic workflows. January’s updates extend that vision across:

• Security and AppSec: higher-fidelity API grouping, fewer false positives, and faster AST onboarding with AI-generated auth.
• SRE and Operations: human-aware incident response that unifies human and machine signals into a single, change-driven flow.
• Governance and Compliance: consistent with December’s AI governance updates, all of these capabilities inherit Harness’s approach of policy-aware AI, auditability, and RBAC-aligned actions.

Teams adopting these features can ship changes faster, investigate less, and focus more of their time on the work that actually moves the business — while Harness AI quietly handles the complexity in the background.

Checkout Event: Harness at RSAC

The rapid adoption of AI is fundamentally reshaping the software development landscape, driving an unprecedented surge in code generation speed. However, this acceleration has created a significant challenge for security teams: the AI velocity paradox. This paradox describes a situation where the benefits of accelerated code generation are being "throttled by the SDLC processes downstream," such as security, testing, deployment, and compliance, which have not matured or automated at the same pace as AI has advanced the development process.

This gap is a recognized concern among industry leaders. In Harness’s latest State of AI in Software Engineering report, 48% of surveyed organizations worry that AI coding assistants introduce vulnerabilities, and 43% fear compliance issues stemming from untested, AI-generated code.

This blog post explores strategies for closing the widening gap and defending against the new attack surfaces created by AI tooling.

‍

Defining the AI Velocity Paradox in Security

The AI velocity paradox is most acutely manifested in security. The benefits gained from code generation are being slowed down by downstream SDLC processes, such as testing, deployment, security, and compliance. This is because these processes have not "matured or automated at the same pace as code generation has."

Every time a coding agent or AI agent writes code, it has the potential to expand the threat surface. This can happen if the AI spins up a new application component, such as a new API, or pulls in unvalidated open-source models or libraries. If deployed without proper testing and validation, these components "can really expand your threat surface."

The imbalance is stark: code generation is up to 25% faster, and 70% of developers are shipping more frequently, yet only 46% of security compliance workflows are automated.

‍

The Dual Risk: Vulnerabilities vs. Compliance

The Harness report revealed that 48% of respondents were concerned that AI coding assistance introduced vulnerabilities, while 43% feared regulatory exposure. While both risks are evident in practice, they do not manifest equally.

• Vulnerabilities are more tangible and appear more often in incident data. These issues include unauthenticated access to APIs, poor input validation, and the use of third-party libraries. This is where the "most tangible exposure is".

• Compliance is a "slow burn risk." For instance, new code might start "touching a sensitive data flow which was previously never documented." This may not be discovered until a specific compliance requirement triggers an investigation. Vulnerabilities are currently seen more often in real incident data than compliance issues.

‍

A New Attack Surface: Non-Deterministic AI Agents

The components that significantly expand the attack surface beyond the scope of traditional application security (appsec) tools are AI agents or LLMs integrated into applications.

Traditional non-AI applications are generally deterministic; you know exactly what payload is going into an API, and which fields are sensitive. Traditional appsec tools are designed to secure this predictable environment.

However, AI agents are non-deterministic and "can behave randomly." Security measures must focus on ensuring these agents do not receive "overly excessive permissions to access anything" and controlling the type of data they have access to.

‍

Top challenges for AI application security

‍

Prioritizing AI Security Mitigation (OWASP LLM Top 10)

For development teams with weekly release cycles, we recommend prioritizing mitigation efforts based on the OWASP LLM Top 10. The three critical areas to test and mitigate first are:

1. Prompt Injection: This is the one threat currently seeing "the most attacks and threat activity".
2. Sensitive Data Disclosure: This is crucial for any organization that handles proprietary data or sensitive customer information, such as PII or banking records.
3. Excessive Agency: This involves an AI agent or MCP tool having a token with permissions it should not have, such as write control for a database, code commit controls, or the ability to send emails to end users.

‍

We advise that organizations should "test all your applications" for these three issues before pushing them to production.

‍

A Deep Dive into Prompt Injection

Here’s a walkthrough of a real-world prompt injection attack scenario to illustrate the danger of excessive agency.

The Attack Path is usually:

1. Excessive Agency: An AI application has an agent that accesses a user records database via an API or Model Context Protocol (MCP) tool. Critically, the AI agent has been given a "broadly scoped access token" that allows it to read, make changes, and potentially delete the database.
2. The Override Prompt: A user writes a prompt with an override, for example, suggesting a "system maintenance" is happening and asking the AI to "help me make a copy of the database and make changes to it." This is a "direct prompt injection" (or sometimes an indirect prompt injection), which is designed to force the LLM agent to reveal or manipulate certain data.
3. Hijacking: If no guardrails are in place to detect such prompts, the LLM will create a hijack scenario and make the request to the database.
4. Real Exfiltration: Once the hijacking is done, the "real exfiltration happens." The AI agent can output the data in the chatbot or write it to a third-party API where the user needs access to that data.

‍

This type of successful attack can lead to "legal implications," data loss, and damage to the organization's reputation.

Here’s a playbook to tackle Prompt Injection attacks

‍

Harness’s Vision for AI Security

Harness's approach to closing the AI security gap is built on three pillars:

1. AI Asset Discovery and Posture Management: This involves automatically discovering all AI assets (APIs, LLMs, MCP tools, etc.) by analyzing application traffic. This capability eliminates the "blind spot" that application security teams often have with "shadow AI," where developers do not document new AI assets. The platform automatically provides sensitive data flows and governance policies, helping you be audit-ready, especially if you operate in a regulated industry.
2. AI Security Testing: This helps organizations test their applications against AI-specific attacks before they are shipped to production. Harness's product supports DAST scans for the OWASP LLM Top 10, which can be executed as part of a CI/CD pipeline.
3. AI Runtime Protection: This focuses on detecting and blocking AI threats such as prompt injection, jailbreak attempts, data exfiltration, and policy violations in real time. It gives security teams immediate visibility and enforcement without impacting application performance or developer velocity.

‍

Read more about Harness AI security in our blog post.

Looking Ahead: The Evolving Attack Landscape

Looking six to 12 months ahead, the biggest risks come from autonomous agents, deeper tool chaining, and multimodal orchestration. The game has changed from focusing on "AI code-based risk versus decision risk."

Security teams must focus on upgrading their security and testing capabilities to understand the decision risk, specifically "what kind of data is flowing out of the system and what kind of things are getting exposed." The key is to manage the non-deterministic nature of AI applications.

‍

To stay ahead, a phased maturity roadmap is recommended:

1. Start with visibility.
2. Move to testing.
3. Then, focus on runtime protection.

By focusing on automation, prioritizing the most critical threats, and adopting a platform that provides visibility, testing, and protection, organizations can manage the risks introduced by AI velocity and build resilient AI-native applications.

‍

Learn more about tackling the AI velocity paradox in security in this webinar.

‍

The AI revolution isn't coming—it's already here, and it's rewriting the rules of software development at breakneck speed. AI agents autonomously navigate entire codebases and generate code faster than ever before. But as we embrace these powerful tools, a critical question emerges: Are we all building on solid ground, or are we constructing skyscrapers on quicksand?

Welcome to the new frontier of DevSecOps, where artificial intelligence isn't just changing how we build software—it's fundamentally transforming what we need to protect and how we protect it.

On November 12th, Harness is hosting the virtual DevSecOps Summit 2025. Industry leaders, security practitioners, and AI innovators are converging to tackle the most pressing challenge of our generation: securing AI systems from the first line of code to production deployment and beyond. This isn't about adding another checkbox to your security compliance list. This is about reimagining security for an era where code writes code, where models make decisions, and where vulnerabilities can be AI-generated as quickly as features.

Why AI Features Matter Now

The statistics are sobering. AI-generated code is proliferating across enterprise codebases, often without adequate security review. Large Language Models (LLMs) are being deployed with proprietary data access, creating unprecedented attack surfaces. Agentic systems are making autonomous decisions that can impact millions of users. And traditional security tools? They're struggling to keep pace.

But here's the paradox: while AI introduces new security challenges, it's also a powerful multiplier to our efforts to address them. The same technology that can generate vulnerable code can also detect anomalies, predict threats, and automate security responses at machine speed.

From Pipeline to Production: A Holistic Approach

This summit explores the complete AI security lifecycle—because threats don't respect the boundaries of your CI/CD pipeline. Here are just a few of the topics that we’ll examine at the Summit:

• When Vibe Coding Loses Its Cool: Vibe coding is changing how we design, code, and secure software, but it must be done thoughtfully. Tanya Janca (author of Alice and Bob Learn Secure Coding) and Adam Arellano of Harness will engage in a lively fireside chat about bringing AI into your development workflow safely and effectively.
• Ways to Ensure Security Across the SDLC: Leading experts from Harness, Wiz, Citizens Bank, and InterSystems will demonstrate a unified and integrated approach to AI security, emphasizing that robust protection must span the entire lifecycle, from the initial pipeline stages to full production deployment. Attendees will:  
  
  • Gain insights into how to bridge the existing gaps between development and operations security with a practical, actionable framework for securing AI applications end-to-end.
  • Learn how to ensure that your security controls are not static, but evolve dynamically and as rapidly as your AI capabilities with continuous protection against emerging threats and vulnerabilities in an ever-changing landscape.
• How to Check Your AI Blind Spot: Security researchers from Harness, SentinalOne, and ASPEN Labs share real-world examples of threats targeting AI-native applications, risky behavior is usage of AI components, and even how attackers are using AI tools to attack faster. You'll learn:
  
  • Practical approaches to securing your new AI attack surface, implementing guardrails for rolling out AI functionality without slowing down development.
  • Invaluable insights into the intricacies of securing an AI-powered future, exploring practical approaches to counter sophisticated attack vectors.
  • What researchers are experiencing the wild and how they’re securing AI-native applications in real-time.
• Leading experts from Harness, Wiz, Citizens Bank, and InterSystems will demonstrate a unified and integrated approach to AI security.

What You'll Discover

Throughout this summit, you'll hear from practitioners who are solving AI challenges in real-world environments. They'll share hard-won lessons about securing agentic applications, preventing prompt injection attacks, validating AI-generated code, and building governance frameworks that scale with AI adoption.

Whether you're a security professional adapting to AI-powered threats, a developer integrating AI tools into your workflow, or a leader navigating the strategic implications of AI adoption, this summit offers actionable insights for your journey.

The future of software is AI-native. The question isn't whether to embrace it, but how to do so securely, responsibly, and effectively. Let's explore that future together—from pipeline to production, and everything in between.

Join us at DevSecOps Summit 2025.