Runtime Protection | Harness Blog Primary Category

August 19, 2026

Technical

Time to Read

Vulnerabilities used to move at human speed. A researcher found one, disclosed it, and defenders had days - sometimes weeks - to respond before it was weaponized in the wild.

That window is gone. According to the Edgescan 2026 Vulnerability Statistics Report, it still takes an average of 55 days to fix a vulnerability - but the Zero Day Clock shows attackers going from disclosure to first exploit in as little as 6 hours. And per the 2025 DORA Report, once a fix is written, it can still take more than a week to get from commit to production. Security teams are trying to close a gap measured in hours with a process measured in weeks.

Frontier models like Claude Mythos are pulling on both ends of that gap at once. On one side, they're giving attackers a faster way to find and chain vulnerabilities. On the other, they're giving defenders a faster way to find vulnerabilities too. Point an LLM scanner at a codebase and it will surface far more findings than traditional tools ever did. Project Glasswing partners saw roughly 10x more vulnerabilities surfaced during testing. That's a good thing only for visibility. But it creates an operationalization challenge. Without any normalization, deduplication, reachability or integration with developer workflow, it just creates more backlog for a remediation process that was already too slow. Comcast, a Project Glasswing participant, put a number on that gap in its own testing: 44% of critical- and high-severity findings turned out to be false positives.

Security has to move at machine speed now, end to end: scan without drowning in noise or cost, triage what's actually worth fixing, remediate it, get the fix into production before the window closes, and still protect the perimeter while the fix is fully deployed. That's what this launch is about.

Scan without the guesswork: AI SAST and LLM Scan Orchestration

Everything downstream starts with the scan, so that's where machine speed has to start too.

LLM-based scanners are genuinely good at finding things traditional static analysis misses, which is exactly why they've generated so much attention. But they're still probabilistic: point the same model at the same code twice and you can get different findings, different false positives, latency that can hold up pipelines, and a token bill that scales with every file you scan. That's a real cost, and it makes it unrealistic to scan continuously in CI/CD.

That’s why Harness is embracing the hybrid approach - use LLMs for one-off hunting scans, and a deterministic SAST augmented by AI in the pipeline.

AI SAST

Harness pairs a high-recall dataflow engine with an AI confidence layer that classifies each finding as confirmed risk, potential risk, or contextually safe. It's deterministic where LLM scanning is probabilistic: same code, same result, every time, with a traceable path from input to sink. In our own benchmarking against the OWASP Java corpus, that confidence layer cut false positives by 79% (from 454 down to 95) and lifted precision from 74% to 93%, while preserving 91% recall - almost no loss of signal for a large gain in precision. It also extends into broken access control (IDOR), a class dataflow analysis alone can't see because there's no malformed input to pattern-match, only a missing authorization check: 71% recall at 99% precision across a 390-case corpus spanning Go, Java, and Python.

LLM Scan Orchestration

For teams that want to run LLM-based scanners, Harness now orchestrates them natively inside the CI/CD pipeline, reducing token spend, increasing scan speed, and feeding results into the same triage and remediation workflow as everything else - instead of a separate spreadsheet living outside your pipeline.

Which should you choose? AI SAST reduced the triage queue by 21% in our benchmark (1,746 flagged cases down to 1,381 actionable ones) without giving up coverage, and without paying a per-scan LLM bill to get there. LLM scanners still have a place, and Harness will keep making them faster and cheaper to run. But when the choice is between a probabilistic result and a deterministic one at comparable or better accuracy, the deterministic one should usually win by default.

From finding to fix: Triage Agent and Remediation Agent

A scanner - any scanner - is only useful if what it finds actually gets fixed. And the steady output of SAST and SCA scanning has a particular shape: a high volume of findings that need to be sorted by real risk before anyone starts fixing, because most security teams already have more open findings than they can act on in a sprint, let alone a day. And most of that backlog isn't as urgent as it looks: in the same Project Glasswing testing, only 36% of critical-severity and 33% of high-severity findings were confirmed exploitable. Sorting through that backlog by hand, then writing and validating each fix one by one, is exactly the kind of toil that doesn't scale with the volume scanning produces, so Harness is introducing an agentic workflow that does.

Triage Agent

Harness’s Triage Agent prioritizes what's actually exploitable, combining CVSS, EPSS, and reachability analysis to cut a sprawling SAST/SCA finding list down to a clean, actionable backlog - so your team works on real risk, not everything with a CVE number.

Remediation Agent

Once a finding is prioritized, the Remediation Agent applies the fix and validates it in your pipeline to prevent breaking builds, then opens a human-reviewed pull request. Developers stay in charge of what merges; the agent just does the work of getting them a validated fix instead of a bare finding.

Function-level reachability

Reachability analysis doesn't stop at "is this vulnerable package called." Harness now traces the call path down to the specific vulnerable function, so a dependency only gets flagged if that exact function is reachable in your code. Both agents work off that sharper signal: fewer false positives for Triage Agent, and a precise code path to close for Remediation Agent.

Because these agents run on top of Harness's existing pipeline governance (policy gates, approvals, chain of custody), a fix doesn't just get written faster, it gets safely into production faster too. That's the piece that's easy to overlook: a fix sitting in a pull request isn't protection. A fix that's deployed with an audit trail through the same governed pipeline you already trust - that's protection.

Zero-days don't wait in line: Zero-Day Agent

Everything above assumes there's time to scan, triage, and prioritize before anyone acts. A zero-day doesn't give you that time. The clock starts the moment it's disclosed, and most of that time doesn't get spent writing a fix - it gets spent figuring out if you're even affected and waiting for a fixed artifact to work its way back through build, test, and deploy.

A newly disclosed zero-day doesn't need to wait in a triage queue behind the rest of the backlog; it needs an immediate, end-to-end response. Zero-Day Agent runs that response itself: it continuously monitors for newly disclosed zero-day vulnerabilities, automatically identifies every affected artifact and pipeline across your environment, and takes it the rest of the way - applying and validating a fix, then opening a human-reviewed pull request. No separate triage step, no handoff to another agent. Blast radius mapping that used to take days happens in seconds, and a fix is ready for review shortly after.

Shielding production while the fix is in flight

Even with agents compressing the fix cycle to hours, hours are still a window. Harness closes that window from the other direction with virtual patching: when API testing discovers a vulnerability, it can create a virtual patch and deploy it on our WAAP - no tickets or code changes required. Production is shielded within minutes of discovery, while the permanent fix is worked in code. When the fix ships, the virtual patch comes down.

That's the same principle running through this whole launch: don't wait for the slowest step in the chain to gate every other step. Contain the risk immediately, fix it in parallel, and let each part of the system move as fast as it's capable of moving.

Security at machine speed

None of this works as a single point tool. The value comes from AI SAST, LLM scan orchestration, Triage Agent, Remediation Agent, Zero-Day Agent, and virtual patching all sitting on the same platform - the same one that's already deploying your code, governing your pipelines, and holding chain of custody on every artifact. Finding a vulnerability faster only matters if fixing it and deploying it are just as fast.

The organizations that build this operating rhythm now, those that scan without noise, triage in minutes, ship a validated fix in hours, shield production the whole time, will be the ones still moving confidently when attackers have the same frontier models defenders do. The ones that don't will keep measuring their response time in weeks while the threat measures its head start in hours.

Want to learn more?

Read about Harness's perspective on how Mythos is not just a security problem, but also an engineering problem. To learn more about the security capabilities in this launch, request a demo or reach out to your Harness account rep.

Harness Announces Capabilities that Enable Security at Machine Speed

August 10, 2026

Technical

Time to Read

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.

ChainDrop npm Worm Shows Why Valid Provenance Is Not Enough

August 6, 2026

Technical

Time to Read

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."

Zero Day to Fix: Why Security Response Speed—Not Discovery—Is Your Real Bottleneck

August 5, 2026

Technical

Time to Read

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.

AI SAST Explained: Why Traditional Application Security Is Reaching Its Breaking Point

July 23, 2026

Technical

Time to Read

Traditional web application firewalls (WAF) are no longer sufficient for protecting modern, API-first applications. WAAP provides unified, comprehensive runtime security for applications & APIs.
A WAAP platform should automate policy creation, reduce alert fatigue, and integrate seamlessly into CI/CD pipelines, eliminating ticket-ops bottlenecks and reducing developer and security toil.
Best practices such as continuous API discovery, API testing, and application-layer threat detection & response enable platform teams to operationalize security at scale without sacrificing delivery speed or developer autonomy.

When APIs now handle the majority of web traffic, protecting only HTML requests creates a blind spot that puts your organization at risk. Traditional WAFs weren't built for this reality and miss API-specific vulnerabilities that define modern attack vectors. Your security platform needs complete visibility into every API endpoint, authentication flow, and data exchange.

A web application and API protection (WAAP) platform should unify API discovery, API testing, API protection, bot & abuse protection, and cloud-scale WAF capabilities into a single platform. Instead of bolting security on after deployment, WAAP should provide standard runtime security control that’s also integrated into your software delivery lifecycle. Harness Web Application & API Protection delivers this unified approach without reintroducing the ticket-ops bottlenecks that slow your teams down.

What Is WAAP?

Web Application and API Protection (WAAP) is a modern cybersecurity approach designed to protect web applications and APIs from a wide range of threats.

Instead of relying on a single layer of defense like a network firewall, WAAP combines multiple security technologies into a unified solution to safeguard modern cloud- and AI-native designs.

At its core, WAAP protects against:

Application-layer attacks (like SQL injection and cross-site scripting)
API-specific exploitation and data exposures
Bots, abuse, and automated threats
Distributed Denial-of-Service (DDoS) attacks

In simple terms:

WAAP ensures that the apps and APIs powering your business stay secure, available, and trustworthy.

Why WAAP Matters More Than Ever

The need for WAAP isn’t just theoretical. It’s driven by real shifts in how applications are built and operated today.

1. The Explosion of APIs

APIs are now the backbone of digital ecosystems. They allow different systems to communicate, power mobile apps, and enable integrations between platforms.

However, APIs are often:

Poorly documented
Exposed to the public internet
Lacking strong authentication

This makes them a prime target for attackers.

2. Cloud and Microservices Architecture

Modern applications are no longer monolithic. They’re built using microservices distributed across cloud environments.

While this improves scalability and flexibility, it also:

Increases the number of endpoints
Makes security visibility more difficult
Expands the attack surface significantly

3. Sophisticated Cyber Threats

Attackers today use automation, AI, and large-scale bot networks to exploit vulnerabilities faster than ever.

They’re not just targeting infrastructure. They’re targeting:

Login forms
Payment systems
Data flows
User sessions

4. Limitations of Traditional Security

Older security tools, such as network firewalls and basic WAFs, were designed for simpler environments. They often:

Rely on static rules and attack signatures
Lack context about user behavior
Struggle to detect modern attack patterns

WAAP fills this gap by offering adaptive, intelligent, and application-aware protection.

The Core Components of WAAP

WAAP isn’t a single tool. It’s a collection of advanced security capabilities working together. Let’s explore each one in more detail.

1. Web Application Firewall (WAF)

A Web Application Firewall (WAF) is one of the foundational layers of WAAP.

It inspects incoming HTTP and HTTPS traffic and filters out malicious requests before they reach your application. But modern WAAP goes far beyond simple rule matching.

They now incorporate:

Behavioral analysis
Machine learning-powered detections
Context-aware filtering

This allows them to detect not only known threats but also suspicious patterns that may indicate new or evolving attacks.

For example, if a user suddenly submits hundreds of unusual requests in a short time, a modern WAAP can flag and block that behavior, even if it doesn’t match a known attack signature.

2. API Security

APIs are one of the most critical and vulnerable parts of modern systems.

WAAP provides dedicated API security that goes beyond traditional protections by focusing on how APIs operate.

Key capabilities include:

API Discovery
Identifies all APIs in your environment, including undocumented or “shadow” APIs that developers may have deployed without formal tracking as well as “zombie” APIs” that were abandoned.
API Schema Validation
Ensures that incoming requests follow the expected structure, preventing attackers from sending malformed or malicious data.
Authentication and Authorization Enforcement
Verifies that only authorized users and systems can access specific API endpoints.
API Attack Prevention
Prevents requests that exploit API functionality or extract sensitive data, including risks defined in the OWASP API Security Top 10.

This WAAP layer is crucial to application security because many breaches today occur as a result of poorly secured APIs.

3. Bot & Abuse Protection

Bots and automation account for a significant portion of internet traffic, and not all of them are friendly.

WAAP includes advanced bot & abuse protectionthat can distinguish between:

Acceptable bot behavior (search engines, monitoring tools)
Undesirable bot behavior (scrapers, account-targeting, transaction fraud)

Instead of blocking all automated traffic, WAAP uses techniques like:

Behavioral analysis
Device fingerprinting
Interaction patterns

This allows it to:

Block malicious bot behavior
Challenge suspicious activity (e.g., insert CAPTCHA dynamically into an application flow)
Allow legitimate automation

4. DDoS Protection

Distributed Denial-of-Service (DDoS) attacks aim to flood your system with traffic until it crashes or becomes unavailable.

WAAP provides robust DDoS protection by:

Detecting abnormal traffic spikes
Filtering malicious requests
Distributing traffic across infrastructure
Automatically scaling defenses

This ensures that your application remains accessible, even under heavy attack conditions.

5. Application Threat Intelligence and Analytics

One of WAAP’s most powerful features is its ability to provide deep visibility into application threats.

Instead of simply blocking attacks, WAAP helps you understand:

Where attacks are coming from
What methods are being used
Which API endpoints are being targeted
How frequently attacks occur

This data enables teams to:

Improve application runtime security
Identify complex attack chains
Respond faster to security incidents

How WAAP Works in Practice

Let’s walk through a simplified example of how WAAP operates behind the scenes.

A user (or bot) sends a request to your application
WAAP intercepts the request before it reaches your servers
The request is analyzed using multiple layers:
- Signature-based detection
- Behavioral analysis
- Machine learning models
WAAP assigns a risk score to the request
Based on that score:
- Safe requests are allowed
- Suspicious requests are challenged
- Malicious requests are blocked

All of this happens in real time, often within milliseconds, ensuring both security and performance.

WAAP vs. Traditional Security Tools

Understanding the difference between WAAP and older tools helps clarify its value.

Traditional Security Tools

Focus on protecting networks rather than applications
Use static, rule-based detection
Provide limited visibility into API traffic
Struggle with modern cloud environments and AI systems

WAAP

Focuses on application-layer security
Protects applications, APIs, and AI
Uses adaptive, intelligent detection methods
Designed for distributed cloud- and AI-native systems

In essence:

WAAP is built for modern application architectures, while other security tools were built for traditional infrastructure.

Common Threats WAAP Protects Against

WAAP is designed to defend against a wide range of modern threats, including:

Injection Attacks - Attackers insert malicious code into inputs to manipulate databases or systems.
Cross-Site Scripting (XSS) - Malicious scripts are injected into web pages to steal user data or hijack sessions.
API Exploitation - Attackers misuse APIs to extract sensitive data or bypass security controls.
Credential Stuffing & Account Takeovers (ATO) - Automated bots use stolen credentials or target account logins to compromise identities and gain unauthorized access.
DDoS Attacks - Flooding systems with traffic to disrupt availability.
Zero-Day Attacks - Previously unknown vulnerabilities that haven’t yet been patched.

WAAP’s behavioral and AI-driven detection helps identify these even before signatures exist.

Benefits of Implementing WAAP

Adopting WAAP provides several key advantages:

Comprehensive Protection - A unified solution that covers multiple attack vectors.
Enhanced Visibility - Clear insights into traffic, usage patterns, and threats.
Reduced Complexity - Eliminates the need for multiple disconnected tools and point solutions.
Improved User Experience - Minimizes false positives, ensuring legitimate users aren’t blocked and availability is maintained.
Scalability - Designed to grow with your applications and handle global traffic.

Who Needs WAAP?

WAAP is essential for any organization that relies on web applications or APIs, especially:

SaaS companies
E-commerce platforms
Financial institutions
Healthcare providers
Enterprises with digital services

If your business operates online, WAAP is no longer optional and is a critical defense layer.

Best Practices for Implementing WAAP

Platform teams can't protect what they can't see, and the scale of the problem is often shocking. Most organizations discover they have three times as many APIs as they thought once they enable continuous discovery.

These enterprise API protection best practices turn visibility gaps and manual processes into automated guardrails that scale with your delivery velocity.

Inventory everything first - Deploy continuous API discovery across all clusters and regions to eliminate shadow endpoints.
Map sensitive data flows early - Identify which APIs handle PII, authentication, and critical business functionality before attackers do.
Fail builds on high-severity issues: Integrate API testing into CI pipelines with contextual remediation guidance for developers.
Enforce policies as code - Embed org-wide security rules in templates and gateway configurations, not manual reviews.
Start with controlled rollouts - Operationalize protection for 7-10 critical services first to prove low friction before expanding.

Smart platform teams treat API protection like any other infrastructure component. Start small, automate the repetitive work, and let unified WAAP capabilities handle the scale while developers focus on shipping features.

Operationalize WAAP With Harness

Platform teams can't afford to treat API security as an afterthought when most incidents start with compromised endpoints. Harness Web Application & API Protection transforms security from a bottleneck into an automated control that fits your delivery pipelines. AI-powered detection cuts through alert noise while continuous API discovery eliminates shadow endpoints across your entire infrastructure.

The right WAAP solution integrates with your existing CI/CD workflows without creating new ticket-ops friction. Teams get runtime protection that adapts to application changes and shift-left testing that catches vulnerabilities before production.

Ready to gain full API visibility and protect applications at the speed of modern delivery? Try Harness Web Application & API Protection and see how unified API discovery, API testing, API protection, bot & abuse protection, and WAF can eliminate security toil for your application security program.

WAAP In Practice: CI/CD Integration And Governance FAQ

Platform teams need concrete answers about WAAP integration that avoid new approval workflows and maintain engineering’s ability to deliver quickly. These WAAP FAQ responses address deployment scenarios andstrengthening security posture.

How does WAAP integrate with CI/CD without slowing builds?

WAAP runs API testing as part of your existing pipeline stages, not as a separate gate, to detect issues such as those defined in the OWASP API Security Top 10. Tests run against live traffic patterns and API schemas. Builds fail only on high-severity issues like broken authentication or data exposure, following NIST guidance for automated security enforcement without review delays.

What reduces false positives compared to traditional WAF solutions?

WAAP correlates full user journeys and API call chains (the sequence of service-to-service requests) to understand user intent rather than inspecting isolated requests. Machine learning models tune to your actual application configurations and data flows, not generic signature databases. This contextual approach reduces alert noise significantly compared to rule-based WAFs and catches threats that bypass traditional detection methods.

Which deployment options work for hybrid multi-cloud environments?

Any WAAP should support agentless edge routing, in-line integration with API gateways and load balancers, and out-of-band collection via traffic mirroring or eBPF. Teams should be able to combine deployment methods for different services to support their given application architecture. Kubernetes and container environments may also require native ingress controller and sidecar support for east-west microservices traffic protection. Harness WAAP provides 30+ integrations to support modern designs.

How do you enforce governance without creating ticket-ops?

Policy-as-code templates can be used to embed WAAP deployment directly into service deployment pipelines. Teams inherit org-wide protections automatically when using approved templates, providingguardrails that scale without approval bottlenecks.

What operational overhead should platform teams expect?

AI-assisted policy generation eliminates the need for signature writing and weekly change windows. Runtime protection automatically adapts to application changes. Platform teams generally see a 60-70% reduction in security-related tickets compared to traditional WAF management. Most operational tasks shift to self-service developer workflows.

How do you measure WAAP ROI and security improvements?

WAAP provides metrics on API discovery coverage, vulnerability remediation time, and blocked attacks. Platform teams track developer velocity through build time impact and ticket reduction. Security posture improves through measurable reductions in exposed APIs, faster incident response, and more efficient compliance audits.

What Is Web App and API Protection (WAAP)?

July 14, 2026

Technical

Time to Read

The open-source landscape has witnessed another highly automated, ecosystem-level subversion. On June 17, 2026, a critical software supply chain attack struck the Mastra AI framework - a popular open-source TypeScript ecosystem used widely to build AI agents, workflows and RAG pipelines. By exploiting a compromised contributor account, threat actors successfully mass-published 144 malicious packages under the official @mastra npm scope.

The packages themselves contained no malicious code within their repositories; instead, they were altered at the registry level to pull in a weaponized transitive dependency called easy-day-js. Any developer workstation, CI/CD runner or cloud environment executing a routine installation during the compromise window was immediately exposed to a sophisticated cross-platform information stealer. This article delivers a comprehensive technical teardown of the attack mechanics and its stealthy execution pipeline.

Preface

Modern application engineering moves at the speed of automated dependency resolution. Rather than writing utility functions from scratch, software teams routinely orchestrate architectures that pull hundreds of third-party open-source components during active builds and deployment pipelines. This reliance sets up a structural trust chain: developers trust the package registry, the registry trusts the maintainer's cryptographic identity and downstream environments trust that updates are safe and authentic.

However, this architecture exposes a massive, interconnected attack surface. When an adversary manages to compromise an upstream account or subvert a single verification step, the entire downstream distribution network turns into an automated malware delivery pipeline. The Mastra incident highlights a growing shift where threat actors stop targeting production firewalls directly and focus heavily on poisoning the automated software supply chain.

Introduction

At its core, the Mastra supply chain compromise was designed to abuse default package installation behavior to execute arbitrary code, bypass standard static scanners, harvest sensitive host credentials and establish long-term persistence across multiple operating systems.

What makes this attack structurally advanced is its combination of trust exploitation and defensive evasion:

Provenance Deception - While the Mastra ecosystem typically publishes official releases via automated CI pipelines backed by SLSA provenance attestations, the attacker used a hijacked contributor token to publish directly to the npm registry. By stripping the provenance attestations, the malicious versions bypassed traditional verification layers while remaining structurally identical to legitimate software updates.
Transitive Infiltration - The core source code within Mastra's public GitHub repository remained entirely clean. The anomaly was introduced solely inside the published registry tarballs by altering the package.json configurations to demand an external, attacker-controlled module.
Volatile Loading & Self-Deletion - The first-stage payload was engineered as a transient dropper. It disabled local transport security, fetched a secondary backdoor payload into memory, spawned it as an isolated system process and then deleted its own source files from disk to eliminate obvious post-incident footprints.

Deepdive Into The Mastra Exploit

The campaign was executed within an intensive, automated 88-minute window. Rather than engineering a complex repository exploit, the attacker capitalized on a dormant contributor account ehindero whose publishing access to the @mastra npm scope had not been explicitly revoked. Let's break down the exploit lifecycle step-by-step.

Initial Access & The ehindero Account Compromise

Every supply chain attack requires an initial wedge to subvert the trust architecture. In this campaign, the breach did not stem from a flaw in Mastra’s core source code, but rather from an authentication gap on a historical contributor account by the name of ehindero. Security analysis indicated the account takeover occurred through a combination of two common supply chain vulnerabilities as discussed below.

The contributor account lacked enforced Multi-Factor Authentication on the npm registry. Threat actors cross-referenced public data breaches to match historical password reuse, successfully logging directly into the publisher profile via automated scripting.
Further forensic tracking suggested that an active personal access token with broad scope write permissions had accidentally been preserved inside an unencrypted local configuration environment on a legacy workstation.

The Transitive Dependency & Caret Range Trick

The attack relied heavily on establishing a convincing upstream dependency. On June 16, 2026, the threat actor published a "bait" version of a typosquatted package named easy-day-js, mimicking the popular dayjs library. This initial version, v1.11.21, was completely clean and byte-for-byte identical to legitimate components, designed purely to evade early automated registry profiling.

The following day, the attacker published easy-day-js@1.11.22 - this time embedding a malicious postinstall script execution block. Simultaneously, using the hijacked contributor credentials, the attacker mass-republished 144 packages across the @mastra/* scope. In each of these packages, the attacker injected exactly one line given below into the published package.json:

"dependencies": {
  "easy-day-js": "^1.11.21"
}

Because npm interprets the caret ( ^ ) range to mean any minor or patch update up to the next major version, any fresh invocation of npm install for a Mastra package automatically resolved, downloaded and integrated the malicious v1.11.22 payload.

Bypassing Trusted Publishing Infrastructure

Mastra's legitimate delivery pipeline relies on OIDC-based short-lived publishing tokens. However, the npm registry still allowed manual token authentication paths. By utilizing a long-lived personal token belonging to the compromised account, the adversary circumvented the official GitHub Actions release loop. Although the resulting packages lacked the standard SLSA provenance attestations generated by the framework’s CI runner, consumption policies at the developer level rarely block packages simply due to missing attestations, allowing the unauthorized code to execute freely.

Detached Execution & Stealth Mechanics

When a system triggers the installation of the tainted package, the postinstall lifecycle hook automatically invokes an obfuscated script named setup.cjs. The loader performs the following actions:

Disables TLS Verification - It overrides the environment configuration with process.env.NODE_TLS_REJECT_UNAUTHORIZED = "0", forcing the Node runtime to accept unverified, self-signed SSL certificates from the attacker's infrastructure.
Drops Operational Logs - It creates temporary tracking files under the host's temp directory named .pkg_history and .pkg_logs.
Fetches Stage 2 - The loader initiates an outbound HTTP request to the attacker's Command and Control (C2) endpoint, 23.254.164.92:8000, to retrieve an encrypted secondary payload.
Detached Spawning - The second stage is written to a randomized 12-hex-character .js file and executed as a detached child process, giving it an independent process group that outlives the parent npm install command.
Forensic Self-Deletion - The moment the second stage initializes in memory, the loader invokes fs.rmSync(__filename, { force: true }), completely removing the installer script from the local node_modules directory to blind basic static security utilities.

Cross-Platform Info-Stealing & Persistence

The secondary payload operates as a comprehensive cross-platform credential harvester. It systematically searches the host environment for sensitive telemetry:

Browser Data Extraction - Targets local storage and credentials from Google Chrome, Microsoft Edge and Brave browsers.
Cryptocurrency Exfiltration - Targets more than 160 browser-based cryptocurrency wallet extensions including MetaMask, Phantom, Coinbase and Binance to drain active sessions.
Credential Harvesting - Scans local user spaces for cloud configuration tokens like .aws/credentials, environment variables, database keys and SSH profiles.

Screenshot illustrating: Cross-Platform Info-Stealing & Persistence

To ensure long-term control, the malware checks the host OS and installs specific persistence payloads. All harvested data is packaged and exfiltrated to the secondary C2 server located at 23.254.164.123.

Attacker compromises active/former contributor account (ehindero)
↓
Attacker publishes clean bait version easy-day-js@1.11.21
↓
Attacker uploads weaponized version easy-day-js@1.11.22 with postinstall hook
↓
Attacker uses compromised token to mass-publish 144+ @mastra packages
↓
Injected dependency ("easy-day-js": "^1.11.21") added directly to registry tarballs
↓
Developer or CI/CD runner executes npm install for a Mastra package
↓
Registry resolves caret range ^1.11.21 to the malicious v1.11.22
↓
postinstall lifecycle script triggers setup.cjs hook automatically
↓
Loader disables TLS verification and writes local tracking logs
↓
Second-stage payload downloaded from C2 infrastructure (23.254.164.92)
↓
Payload executed as a detached child process to survive parent completion
↓
setup.cjs executes self-deletion routine to erase forensic footprint
↓
Second stage harvests browser data, 160+ crypto wallets and password managers
↓
Cross-platform persistence established via LaunchAgents, systemd or Registry Run keys
↓
Stolen host credentials and secrets exfiltrated to C2 server (23.254.164.123)

Ecosystem Impact: The AI Pipeline Risk Factor

The blast radius of this campaign is significantly amplified by Mastra's core function as an AI development framework. Unlike generic utility libraries, AI orchestration frameworks are explicitly deployed in data-rich environments. They sit at the intersection of production software loops and deep enterprise backends, routinely interacting with proprietary vector databases, LLM clusters and extensive data integration pipelines.

Consequently, a compromise within this specific ecosystem does not just threaten basic web infrastructure but also exposes high-value LLM API tokens, production database credentials and training data connection points. With a weekly download volume exceeding 1.1 million across the framework and the foundational @mastra/core package pulling roughly 918K downloads alone, the potential data exposure across developer endpoints and automated AI build servers represents a systemic risk to enterprise AI security models.

Compromised Packages

The entire compromise in the npm registry stems from the weaponized library easy-day-js, specifically version v1.11.22. This served as the malicious transitive dependency, resulting in the compromised Mastra AI framework outlined in the table below.

Notable Impacted Packages	Affected Version Range
@mastra/core	v0.1.112 – v0.1.118
@mastra/engine	v0.1.45 – v0.1.49
@mastra/rag	v0.1.32 – v0.1.36
@mastra/deployers	v0.1.12 – v0.1.14
mastra (Top-level wrapper)	v0.1.112 – v0.1.118
create-mastra	v0.1.50

‍

Remediations

Defending against registry-level poisoning requires moving beyond passive perimeter filtering to implement proactive environment isolation and strict runtime controls. Organizations should immediately deploy the following protective protocols:

Neutralize install-time droppers by globally disabling automatic package script execution. Run npm config set ignore-scripts true across all developer workstations and CI environments.
Commit strict lockfiles like package-lock.json and pnpm-lock.yaml to version control and utilize deterministic installation flags like npm ci or pnpm install --frozen-lockfile within CI pipelines to prevent automated caret resolutions from pulling unverified upstream releases.
Configure internal package consumption policies to strictly reject public registry updates that lack verified SLSA provenance attestations or match anomalies where a package shifts from a trusted CI publisher workflow to a manual personal token publish.
If an infection vector is discovered, treat the host or runner as entirely compromised. Immediately rotate all connected cloud credentials, source control keys, database strings and LLM API keys exposed within that environment.
Use Software Composition Analysis platforms such as Harness Supply Chain Security (SCS) to continuously inventory dependencies, enforce policy gates, detect malicious packages and block compromised artifacts before they enter build and release pipelines

According to Harness’s analysis of the npm attacks, organizations should treat CI/CD pipelines as critical security infrastructure, combining SBOM visibility, policy enforcement, provenance validation and automated dependency risk analysis to prevent trusted publishing systems from becoming malware distribution channels. Read more about it here.

How Harness Supply Chain Security Helps

Harness SCS helps you quickly detect and contain compromised dependencies like the Mastra AI packages before they impact your pipelines. With real-time visibility into your SBOMs and dependency graph, you can identify affected versions, trace their usage across builds and environments and block them using OPA policies. This ensures malicious packages never propagate through your CI/CD or AI workflows.

Detect Compromised Packages

Harness SCS enables instant search across all repositories and artifacts to quickly identify if compromised package versions exist in your environment. The moment such a malicious package is disclosed, you can pinpoint its presence and assess impact across your entire supply chain in seconds.

Block Compromised Packages

Harness AI streamlines response to incidents like the Mastra AI compromise through simple natural-language prompts. With a single prompt, you can generate OPA policies to block affected versions of Mastra packages, for example, across all pipelines, preventing malicious packages from entering builds or deployments. As new compromised versions emerge, these policies can be quickly updated to maintain strong preventive controls across your SDLC. SCS customers can use this OPA policy to detect and block the affected versions.

Track & Remediate Issues with Developers

Harness SCS automatically detects compromised versions across both production and non-production environments. Teams can track remediation, assign fixes and monitor progress through to deployment, ensuring exposed credentials and vulnerable dependencies are addressed quickly. This end-to-end visibility helps contain the impact and prevents compromised packages from persisting in your supply chain.

Next Steps In The Face Of Supply Chain Attacks

The easy-day-js campaign highlights how quickly a malicious package can expose high-value secrets when embedded deep within registries and CI runners. Given its role in managing dependencies and packages across projects, the impact extends beyond code to API keys, prompt data and downstream systems, often bypassing traditional security checks.

Defending against such attacks requires more than reactive fixes. Teams need real-time visibility into dependencies, the ability to enforce policies to block compromised versions and continuous tracking to ensure remediation is complete across all environments. Harness SCS enables teams to quickly identify where affected package versions are used, prevent them from entering new builds and ensure fixes are consistently rolled out.

With these controls in place, organizations can limit credential exposure, contain threats early and secure their supply chain against attacks like the Mastra packages compromise.

Poisoning The Pipeline: How The Mastra AI Ecosystem Was Poisoned At The Registry Level

July 2, 2026

Technical

Time to Read

Harness AI Security provides a unified control plane for AI discovery, risk visibility, and runtime protection, helping organizations operationalize key requirements of the EU AI Act. Instead of relying on manual audits or fragmented tooling, teams get continuous insight into how AI systems are built, exposed, and used, along with the evidence needed to demonstrate compliance.

By combining AI asset discovery, risk classification, data flow visibility, and runtime enforcement, Harness enables customers to proactively identify high-risk systems, prevent unsafe integrations, and continuously monitor AI behavior in production. This approach aligns directly with the EU AI Act's focus on transparency, traceability, and ongoing risk management.

Harness helps in the following areas of the EU AI Act

AI System Inventory

Harness automatically discovers all AI assets—AI APIs, Agents, MCP servers, MCP tools, resources, prompts, and AI backends by analyzing live network traffic. The centralized inventory provides a real-time breakdown of discovered assets by type, call volume trends, and sensitive data exposure across your environment. Security and compliance teams gain a single, continuously updated source of truth for every AI component in use, without requiring manual cataloging or developer-submitted forms.

Risk Identification & Classification (Article 6)

Once assets are discovered, Harness derives a risk score for each based on policy violations, known vulnerabilities, exposure level (internal vs. external), and sensitive data flow. This scoring helps teams prioritize remediation efforts and demonstrate that high-risk AI systems have been identified and assessed, which is a core expectation under the EU AI Act's risk-based framework.

Prohibited Use Cases (Article 5)

Harness detects shadow AI vendors, unapproved MCP servers, and undocumented AI APIs surfacing in your environment. The Third Party view surfaces AI APIs grouped by vendor (e.g., OpenAI, Google, Anthropic) so teams can identify integrations that haven't undergone procurement or security review. This is directly relevant to the EU AI Act's prohibition on certain AI use cases and its requirements around supply chain transparency for AI systems.

Data Governance & Quality (Article 10)

Harness monitors sensitive data flows across all discovered AI assets, identifying where PII and regulated data enters and exits AI systems. The platform classifies data sensitivity automatically by analyzing asset metadata and observed traffic patterns, giving teams a continuous view of which assets handle sensitive information and surfacing misuse risks before they become compliance incidents.

Technical Documentation & Auditability (Articles 11, 16)

Harness automatically generates schemas for AI APIs, MCP tools, resources, and prompts by analyzing real network traffic with no manual documentation effort required. Each asset detail page captures the asset's type, dependencies, call volume, risk posture, and data flows in one place. This detail provides compliance teams with the structured technical records required under Articles 11 and 16 without burdening engineering teams with additional documentation.

Logging & Traceability (Article 12)

Harness captures all AI interactions, including AI API calls, MCP tool invocations, database calls, and non-AI API calls, in a centralized data lake with seven-day standard retention and 30-day retention for threat activity. This complete, queryable record of AI system behavior supports both routine audit needs and forensic investigations, directly satisfying Article 12's requirements for logging and traceability of high-risk AI systems.

Accuracy, Robustness & Security (Article 9)

The AI Firewall (beta) provides runtime enforcement against the most common AI-layer threats: prompt injection attacks, PII leakage in model responses, excessive model usage, and unauthorized model access. Together, these controls address the robustness and security requirements of Article 9, helping organizations demonstrate that their AI systems have active protections in place rather than passive policies.

Post-Market Monitoring (Article 72)

Harness continuously discovers new AI assets, shadow AI usage, and emerging sensitive data risks in production as your environment evolves. Real-time alerts are triggered for new vulnerabilities and compliance violations, with native integrations into SOC/SIEM workflows for rapid response. This ongoing monitoring capability aligns directly with the EU AI Act's post-market surveillance requirements, ensuring compliance doesn't end at deployment.

Bottom line: Harness AI Security provides the visibility, controls, and audit evidence layer required to operationalize EU AI Act compliance at scale and oversee AI system security. (Article 14)

Prepare for the EU AI Act with Harness AI Security

June 17, 2026

Company News

Time to Read

Harness has been recognized as a Leader in the 2026 Gartner® Magic Quadrant™ for DevSecOps Platforms for the third consecutive year. Harness was also positioned furthest on the Completeness of Vision axis in the report.

Our Key takeaways:

Harness is named a Leader for the third consecutive year
Harness is positioned furthest on the Completeness of Vision axis
Harness continues investing in governed, AI-powered DevSecOps

Harness is the AI platform for engineering, security, and operations teams to build, secure, deploy, govern, and optimize software delivery across the SDLC.

We believe our recognition in the Gartner Magic Quadrant for DevSecOps Platforms reflects the continued evolution of the Harness platform and our commitment to helping teams deliver software faster, safer, and with greater governance across the software delivery lifecycle.

We’re thrilled to share this recognition, which we believe reflects the strength of our product strategy, the breadth of our platform, and our continued investment in helping enterprises modernize software delivery with security, reliability, cost management, and AI built into the development lifecycle.

Today, organizations across industries like United Airlines, Ancestry, and Citi rely on Harness to reduce delivery complexity, improve developer productivity, strengthen governance, and accelerate innovation across increasingly complex software environments.

Why This Matters Now

Software delivery has entered a new era. AI coding assistants are helping teams create software faster than ever, but faster code generation also means more changes, more tests, more vulnerabilities, more deployments, and more incidents for organizations to manage. The next era of DevSecOps will not be defined by who can generate code faster. It will be defined by who can safely convert that speed into reliable business outcomes.

Our view is that the future of DevSecOps is autonomous AI agents, governed and directed by expert engineers. As humans and AI agents both contribute to software change, enterprises will need one connected platform to understand, validate, secure, deploy, observe, optimize, roll back, and prove every change across the software delivery lifecycle.

Our Journey

As a pioneer in modern software delivery, Harness offers over 15 platform products and has built one of the industry’s most comprehensive platforms to support the full spectrum of application development, deployment, security, reliability, feature management, cost management, and operations.

Harness has evolved through a combination of product innovation, internal entrepreneurship, open source investment, and strategic acquisitions. We believe our recognition as furthest on the Completeness of Vision axis in the 2026 Gartner® Magic Quadrant™ for DevSecOps Platforms is proof that Harness is solving problems for our customers in a measurable way.

Over the past year, Harness has continued to expand platform capabilities and AI agents across:

Security and risk management
AI-native testing capabilities including flaky test detection and AI impact testing
Feature Management and Experimentation
Cloud and AI Cost Management
AI DLC insights
Resilience Testing, and more

This matters because software delivery is no longer just about building and deploying code. Teams must now manage security risk, release complexity, infrastructure cost, compliance requirements, production reliability, and the growing impact of AI-generated software. The Harness platform allows teams to adopt what they need, when they need it, in one place.

With operations across North America, Europe, APAC, Latin America, and India, Harness serves organizations of all sizes across industries. Customers choose Harness not only for the breadth of the platform but also for the flexibility to adopt individual modules or the full platform based on their needs, maturity, and business priorities.

What’s Next for Harness

This recognition in our opinion is a milestone, and we’re proud, but we’re even more excited by the road ahead.

We build security in the software delivery lifecycle natively, not as a separate stage or disconnected toolchain. As AI increases the volume of code, changes, and security findings, enterprises will need platforms that connect detection, prioritization, policy, remediation, deployment, and runtime defense into a single, governed workflow.

Harness is focused on helping enterprises meet that moment. We will continue investing in AI software delivery to help teams move faster without losing control. Our goal is to help every organization deliver software that is faster to build, safer to release, easier to govern, and more resilient in production.

Thank you to our customers, partners, employees, and community for your continued trust. We’re excited about the journey ahead and can’t wait to show you what’s next.

Learn More

Get a complimentary copy of the 2026 Gartner® Magic Quadrant™ for DevSecOps Platforms.

Or, to talk to someone about Harness, please contact us.

Gartner Disclaimer

Gartner, Magic Quadrant for DevSecOps Platforms, 2026, Keith Mann, Thomas Murphy, Bill Holz, 15 June 2026

Gartner does not endorse any vendor, product, or service depicted in its research publications and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner research publications consist of the opinions of Gartner’s research organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this research, including any warranties of merchantability or fitness for a particular purpose.

GARTNER is a registered trademark and service mark of Gartner, and Magic Quadrant is a registered trademark of Gartner, Inc. and/or its affiliates in the U.S. and internationally, and is used herein with permission. All rights reserved.

Harness Named a Leader in the 2026 Gartner® Magic Quadrant™ for DevSecOps Platforms for the Third Consecutive Year

June 9, 2026

Technical

Time to Read

Your Harness pipelines, logs, and deployment approvals are now a sidebar panel away inside VS Code.

The Harness VS Code Extension is live on the VS Code Marketplace today, no .vsix download, no manual install. Search "Harness" in the Extensions view, and you're a click away from real-time CI/CD visibility without leaving your editor.

Screenshot related to: The Harness VS Code Extension is live on the VS Code Marketplace today, no .vsix download, no manual install.

Everything Software Delivery in One Panel

Capability	What it does
Pipeline monitoring	Live status for active runs, with automatic git context detection, executions for your current branch and commit surface automatically.
Log viewer	Click any pipeline step to open its logs in a dedicated editor tab, syntax-highlighted. Failed steps are flagged immediately.
Inline approvals	Approve or reject Harness native, Jira, and ServiceNow deployment gates directly in the editor. No navigating to the UI.
AI-assisted debugging	Ask IDE-integrated Cursor, GitHub Copilot, or Claude about a failure. Pipeline context (name, status, execution ID, URL) is injected automatically. No copy-pasting.

Ask Your AI. It Already Has the Context.

When a pipeline fails, the default loop is: open Harness UI, find the execution, read the logs, copy the relevant output, open your AI assistant, paste, and ask. That's four context switches before you've started fixing anything.

The extension collapses that into one step. An input sits at the bottom of the Harness panel. Type your question, select Claude Code, GitHub Copilot, or Cursor from the dropdown, and the extension packages the current execution context automatically before sending.

‍

Screenshot illustrating: Ask Your AI. It Already Has the Context.

‍

What makes the context useful, not just present, is the Harness Software Delivery Knowledge Graph. The Knowledge Graph is a structured data model that connects every entity across your SDLC: pipelines, services, deployments, environments, artifacts, policy results, and more. When the extension sends your AI tool the execution context for a failing pipeline, it's pulling from that graph. So Claude Code, Copilot, or Cursor isn't just reading a raw log dump. It's receiving structured, relationship-aware data about what ran, what it depends on, and where it broke. That's the difference between an AI that can technically answer a question about your pipeline and one that can accurately answer it.

‍Claude Code responses appear directly in the Harness sidebar (CLI mode) or open the Claude Code panel with the prompt pre-loaded (extension mode). Click Configure MCP in the AI footer to wire up your Harness credentials: project scope or global, your choice.

‍GitHub Copilot is auto-detected when the extension is installed. Context and prompt open in Copilot Chat, ready to go.

‍Cursor is auto-detected when you're running inside Cursor. For the simplest setup, install the Harness plugin from the Cursor marketplace. OAuth authentication, no manual configuration.

Install in Two Minutes

Install:

Open the Extensions view (Ctrl+Shift+X), search "Harness", and click Install. Or from the terminal:

code --install-extension harness-inc.harness-vscode

Connect your account:

Click the Harness icon in the Activity Bar → run Harness: Configure API Key → enter your instance URL and Personal Access Token. Your Account ID is extracted from the PAT automatically.

Select your org and project. Pipelines load immediately.

‍Requirements: VS Code 1.85.0+, active Harness account.

Watch it in action

Watch the walkthrough from our very own Luis Redda.

Stay in VS Code. Your Pipelines Will Follow.

The context-switching loop (open Harness, find the execution, copy the log, switch to your AI tool, paste, and ask) doesn't have to be part of how you work. Pipeline status, logs, approvals, and AI-assisted debugging all live in the same panel as your code. Install the extension, connect your account, and the next time something breaks, you'll already be where you need to be.‍

For more information, checkout the docs.

From Commit to Approval, Without Leaving VS Code

June 5, 2026

Technical

Time to Read

The Shai-Hulud lineage has a new face. On June 1, 2026, security teams independently flagged a fresh supply chain compromise inside the @redhat-cloud-services npm namespace. 32 packages and 96 versions were all republished with a credential-stealing worm.

These aren't typosquats. They are the official packages in a trusted scope, pulling somewhere 80,000-117,000 average weekly downloads. This article walks through how one compromised maintainer account turned Red Hat's own CI/CD pipeline into a malware channel, what is actually new under the hood versus earlier Shai-Hulud waves, and how to clean it up without tripping the worm's self-destruct.

Preface

Open-source ecosystems run on trust and most of that trust is now automated. A modern build pulls hundreds of transitive dependencies, publishes through CI/CD with nobody watching and checks provenance to prove an artifact came from where it claims. Provenance can tell you where a package was built but can't tell you if the build environment was clean.

“Miasma is what happens when an attacker stops trying to fake that trust signal and just earns it from inside a pipeline that already has it.”

Introduction

Miasma is a multi-stage dropper. It runs during npm installation, scans the machine and any reachable cloud for credentials, then republishes itself through every package the stolen tokens can reach. It's a direct descendant of the Mini Shai-Hulud worm. What changed is the packaging: the wrapping, the staging, and the disguise. Where Shai-Hulud used Dune references, Miasma switches to Greek mythology hence naming things "spartan" and labeling its exfiltration repos Miasma: The Spreading Blight.

Here's what actually separates this wave from earlier Shai-Hulud activity:

Every infection gets its own encryption.
- Instead of copying itself byte for byte, the malware generates a uniquely encrypted payload per infection. So a hash-based IOC is only good for one package version, which quietly breaks both version tracking and signature detection.
It goes after cloud identities, not just secrets.
- New collectors enumerate every GCP and Azure identity the infected machine can reach. Earlier variants mostly grabbed the static keys.
It abuses trusted publishing from a hijacked account.
- Rather than steal a long-lived npm token, the attacker pushed commits that requested short-lived OIDC tokens inside GitHub Actions and published with valid SLSA provenance. It's the same trick we saw in the TanStack and Bitwarden compromises.

Timeline

Date	Target	What happened
Apr 22, 2026	`@bitwarden/cli`	Compromised via a poisoned GitHub Actions workflow. Payload self-identifies as "Shai-Hulud: The Third Coming."
Apr 29, 2026	4 SAP npm packages	Compromised using an npm token leaked through a malicious CircleCI pull-request build.
May 12, 2026	160+ packages (incl. Mistral, TanStack)	Mini Shai-Hulud hits in one wave; malicious releases carry valid provenance.
May 12, 2026	Shai-Hulud source code	TeamPCP publishes the full source to GitHub and posts on BreachForums urging others to run their own campaigns.
May 29, 2026	First Miasma marker	First repo carrying the Miasma: The Spreading Blight description appears, likely the actor testing the variant.
Jun 1, 2026	30+ `@redhat-cloud-services` packages	Red Hat Cloud Services npm packages compromised ("Miasma").

‍

Deep Dive Into the Miasma Compromise

This wasn't a stolen token push. It happened inside Red Hat's own release infrastructure. A Red Hat employee's GitHub account was taken over and used to commit straight into internal repositories hence skipping the code review step entirely. Here's how it played out:

Step 1: The Big Picture

Red Hat publishes free software building blocks (called "packages") that thousands of other developers download and use in their own apps. An attacker found a way to poison those building blocks so that anyone who downloaded them would get secretly hacked. This kind of attack is called a "supply chain attack." Instead of breaking into your house, they forge the lock before it ever reaches the store.

Step 2: How they got in

The attacker didn't steal a password or a key. They hijacked a Red Hat employee's GitHub account and quietly slipped their own code into Red Hat's project. Normally, any code change gets reviewed by another human first. But they used a sneaky trick of Orphan commits that let the changes bypass that review making sure that nobody saw them go in.

Step 3: The clever part about "trust"

The industry recently moved to a system where instead of using permanent passwords to publish software, the publishing system hands out temporary and single-use permission slips (short lived tokens).

The idea was "no permanent password to steal means safer."

But the attacker had taken over the machine that creates those permission slips. So every poisoned package came stamped with a legitimate "this was built by a trusted system" seal of approval which was technically true and completely useless because the trusted system itself was compromised.

Step 4: The trap springs instantly

They rigged the poisoned packages so the malicious code runs the instant you install them, before you can read the code or before anything looks wrong. One giant red flag they point out: one of the infected packages was supposed to contain only text definitions (no programs at all), yet it was set up to run a program on install. That's like a sealed envelope that somehow starts ticking.

Step 5: Hiding the malware

The actual malicious code was buried under layers of disguise. It was scrambled, encrypted and rebuilt from lists of numbers, specifically to fool automated security scanners. It also quietly downloads its own tools if your machine doesn't already have them to make sure that it works on almost any computer.

Step 6: Stealing credentials

Once running, it grabs everything it can. It reads environment variables, host details, and local credential files, pulls GitHub CLI tokens with gh auth token and scans the filesystem for secrets that match known patterns. It doesn't stop at files on disk. If it has a valid identity, it queries cloud metadata services, reads from AWS Secrets Manager and SSM Parameter Store, pulls Azure Key Vault and GCP Secret Manager values and lists Kubernetes and Vault secrets. On CI runners it can even read secrets out of the runner's memory, which gets around log masking because the secret is never written to a log.

Representative token patterns searched by the payload include:

Step 7: Hiding the exfiltration as Anthropic traffic

To smuggle the stolen secrets out without setting off alarms, the malware sent data to a web address that looks normal. The full address is hxxps[:]//api[.]anthropic[.]com/v1/api, which is a real Anthropic host. A plain GET to it returns Anthropic's normal 404 not_found_error, so /v1/api isn't a real route and Anthropic's systems were not compromised. The point is to cover. The domain looks harmless in network logs and the path looks like an API call. It's also awkward to block, since lots of companies legitimately call Anthropic.

The malware reuses the same "GitHub dead-drop" trick from earlier Shai-Hulud versions. If it finds a working GitHub token, it uses it to create a public repo on the victim's account and saves stolen data there as JSON files (under a results/ folder, named with a timestamp and counter). The repo gets a random name in the form adjective-noun-number and its description is set to a fixed string.

“Miasma: The Spreading Blight”

When the payload includes a stolen token in a commit message, it uses the threat marker:

IfYouInvalidateThisTokenItWillNukeTheComputerOfTheOwner

Step 8: Spreading itself

Why it spreads like a worm: This is the nastiest part. When the malware finds credentials that can publish software, it infects those packages too and republishes them so the infection jumps from victim to victim automatically similar to the way a real worm or virus spreads. Researchers found it in over 200 infected projects. It also has multiple hidden backup copies of itself buried around GitHub so even if you clean one up it is designed to crawl back.

Affected Packages

The names of some of the affected packages are:

@redhat-cloud-services/vulnerabilities-client
@redhat-cloud-services/tsc-transform-imports
@redhat-cloud-services/topological-inventory-client
@redhat-cloud-services/sources-client
@redhat-cloud-services/rule-components
@redhat-cloud-services/remediations-client
@redhat-cloud-services/rbac-client

Mitigation

The single biggest takeaway for a normal developer: be suspicious when installing a package triggers programs to run, especially a package that has no business running anything. That `preinstall` behavior was the whole foundation of the attack.

Because of the dead-man switch, sequence is the whole game. Work through these in order:

Isolate first by taking infected machines and CI runners offline. Save logs and then remove the malware's persistence.
Then rotate the keys.
Remove bad packages by uninstalling any affected @redhat-cloud-services version. Reinstall a clean one and regenerate the lockfiles.
Block install scripts by running npm ci --ignore-scripts in CI so the preinstall hook can't run.
Fix the pipeline and don't allow workflows that run on any branch with id-token: write and also review every commit.
Search for traces by looking for new repos named Miasma: The Spreading Blight and odd patch-version published.

How Harness Supply Chain Security Helps

Harness SCS helps you quickly detect and contain compromised dependencies like the redhat-cloud-services package before they impact your pipelines. With real-time visibility into your SBOMs and dependency graph, you can identify affected versions, trace their usage across builds and environments and block them using OPA policies. This ensures malicious packages never propagate through your CI/CD or AI workflows.

Detect Compromised Packages

Harness SCS enables instant search across all repositories and artifacts to quickly identify if compromised package versions exist in your environment. The moment such a malicious package is disclosed, you can pinpoint its presence and assess impact across your entire supply chain in seconds.

Block Compromised Packages

Harness AI streamlines response to incidents like the redhat-cloud-services package compromise through simple natural-language prompts. With a single prompt, you can generate OPA policies to block affected versions of redhat-cloud-services packages, for example, across all pipelines, preventing malicious packages from entering builds or deployments. As new compromised versions emerge, these policies can be quickly updated to maintain strong preventive controls across your SDLC.

Harness SCS automatically detects compromised versions across both production and non-production environments. Teams can track remediation, assign fixes and monitor progress through to deployment, ensuring exposed credentials and vulnerable dependencies are addressed quickly. This end-to-end visibility helps contain the impact and prevents compromised packages from persisting in your supply chain.

Next Steps In The Face Of Supply Chain Attacks

The Mini Shai-Hulud worm highlights how quickly a malicious package can expose high-value secrets when embedded deep within registries and CI runners. Given its role in managing dependencies and packages across projects, the impact extends beyond code to API keys, prompt data and downstream systems, often bypassing traditional security checks.

Defending against such attacks requires more than reactive fixes. Teams need real-time visibility into dependencies, the ability to enforce policies to block compromised versions and continuous tracking to ensure remediation is complete across all environments. Harness SCS enables teams to quickly identify where affected package versions are used, prevent them from entering new builds and ensure fixes are consistently rolled out.

With these controls in place, organizations can limit credential exposure, contain threats early and secure their supply chain against attacks like the redhat-cloud-services compromise.

Shai-Hulud Miasma: Inside the Compromise of Red Hat’s Packages

June 1, 2026

Partners

Time to Read

AI agents are only as good as the context they operate in. That's not a design philosophy. It's a practical constraint. An AI agent that doesn't understand how the underlying software delivery entities relate to each other, or what the data actually means, will get things wrong. In software delivery, wrong looks like a botched deployment, a misread failure, or an approval granted when it shouldn't have been, which directly affects your users.

Today, we're announcing that the Harness MCP Server is in the official Claude Connectors Directory, making Harness discoverable and connectable for every team using Claude. But the announcement isn't really about the directory listing. It's about what Harness + Claude can actually do in your delivery system.

Screenshot related to: Today, we're announcing that the Harness MCP Server is in the official Claude Connectors Directory, making

What You Can Do with Claude and Harness

Claude can work across the full Harness delivery platform:

Capability	What Claude can do
Pipeline execution	Trigger and monitor builds across GitHub, GitLab, Bitbucket, or Harness Code
Deployment management	Promote services across environments with approval gate verification
Failure diagnosis	Pull structured execution context and surface root cause analysis
Approval workflows	Retrieve pending approvals and take governed delivery actions
Environment state	Query what's deployed where, in real time
Security posture	Review SBOMs, vulnerability scan results, and SSCA compliance status
Resilience testing	Initiate chaos experiments and retrieve structured results
Cost signals	Surface cloud cost anomalies tied to deployment activity

‍

Screenshot illustrating: What You Can Do with Claude and Harness

All of it is grounded in the Knowledge Graph, not raw API responses, but a structured model of your delivery system that Claude can reason over precisely.

The Problem With Giving AI Agents Raw API Access

MCP lets AI models call external tools by reading API descriptions and deciding which to invoke. That flexibility is useful. But when you're building an agent that needs to reason across an entire software delivery lifecycle, CI, CD, security scans, approvals, feature flags, cost signals, and environments, raw API access creates a deep reliability problem.

Consider a question a platform engineering lead might ask:

‍"Show me the pipelines with the highest failure rate over the last 30 days, and for each one, tell me which services they deploy and whether any of those services have open critical vulnerabilities."

That question spans four domains: pipeline execution history, service-to-pipeline relationships, environment state, and security scan results. An agent working off raw APIs has to discover which APIs exist across each domain, call them in the right order, paginate correctly, infer how field names correspond across systems, and synthesize the results without misinterpreting nested objects or guessing at relationships.

The result is 5+ sequential LLM calls, hundreds of thousands of input tokens, high latency, and an agent that had to guess at every join. Guessing is where hallucinations happen.

What the Harness + Claude Integration Changes

The Harness Software Delivery Knowledge Graph is a purpose-built model of everything that happens after code is written: builds, test runs, deployments, approvals, security scans, environment states, feature flags, infrastructure changes, cost signals, and rollbacks. Not as raw data but as a connected, typed, semantically annotated graph of entities and relationships.

Every field in the graph carries metadata that tells an agent exactly how to use it: whether a value is a number or a string, whether it can be aggregated or only filtered, what its unit is, and how it joins to related entities. Cross-module relationships, between a pipeline and the services it deploys, between a deployment and the security scan results for that artifact, between an environment change and the cost anomaly that followed, are explicitly declared, not inferred.

This is the difference between an agent that can access your delivery system and one that understands it.

When Claude connects to Harness via MCP, it doesn't receive a set of API endpoints. It's getting access to a structured model of your entire delivery organization, one where the relationships are known, the data types are enforced, and the agent can construct precise queries rather than guessing at field semantics.

‍The practical effect with Harness + Claude: that same cross-domain question above becomes 2–3 structured queries against a known schema. The agent selects the right entity types from the graph, generates queries with exact fields and declared relationships, and returns a deterministic answer. No guesswork. No hallucinated field names. No silent wrong answers.

What This Looks Like in Practice

Debugging a failed pipeline without context switching

A build has failed. Normally, you'd open the Harness UI, navigate to the execution, copy the relevant logs, paste them into a conversation, and wait for analysis. The AI reasons over whatever you managed to capture.

With the Harness MCP connection active in Claude, you ask what failed. Claude doesn't just pull logs; it queries the Knowledge Graph to understand the structure of that pipeline, which stage failed, what services were involved, whether similar failures have occurred before, and what changed since the last successful run. The answer it surfaces reflects the full delivery context, not just the stack trace you happened to copy.

Screenshot illustrating: Debugging a failed pipeline without context switching

Promoting a deployment through governed gates

Your team is ready to move a service from staging to production. Claude checks the current environment state, verifies that required approval gates have been satisfied, confirms the security scan passed for the artifact version you're promoting, and initiates the deployment — with every action running through your existing RBAC policies and logged for audit.

The agent isn't guessing about whether conditions are met. It's querying a graph where those conditions are modeled as typed relationships with known states. The answer is deterministic because the data is structured to make it so.

This Is Not AI Without Guardrails

The natural question when Claude can trigger pipelines and manage deployments: what stops it from doing something it shouldn't?

The same controls that govern everything else in Harness. Every action taken through the MCP server runs through your existing RBAC permissions, OPA policy enforcement, approval gates, and audit logging. Claude operates with exactly the permissions you have, nothing more. Every action is tracked. Nothing bypasses the governance layer.

The Knowledge Graph reinforces this: because Harness AI understands your delivery system structurally, it also understands the constraints within it. Approval gates aren't just optional steps the agent might skip; they're modeled as typed relationships with state. The agent can't promote past a gate that hasn't cleared because the graph reflects that clearly.

Speed and governance aren't a tradeoff. They coexist by design.

Why the Claude Connectors Directory Matters

The Claude Connectors Directory is a curated, reviewed set of integrations. Anthropic evaluates each server before listing it. Being approved is a signal of trust that carries weight for enterprise teams deciding which AI integrations to enable.

It also means discoverability at scale: engineering teams using Claude for DevOps workflows will find Harness natively. One-click OAuth connection, no API key management, no manual configuration.

This fits a broader pattern. The Google Cloud partnership brought Harness into Google's AI ecosystem through Vertex AI and Gemini CLI. The Cursor plugin brought it into the IDE. The Claude Connectors Directory brings it into conversational AI. In each case, the goal is the same: wherever developers are doing their best thinking and wherever AI is being asked to help with software delivery, Harness should be present with the right context for that AI to act reliably.

Getting Started

If you're already a Harness customer:

Open Claude and then the Connectors page
Search for Harness in the MCP directory
Authenticate with OAuth, no API keys, no manual configuration
Start asking Claude about your pipelines, deployments, and delivery workflows

If you're new to Harness, sign up for free and connect from day one. Detailed steps are listed in the documentation.

The Harness Connector gives Claude the ability to act in your delivery system. The Knowledge Graph gives it the understanding to act well. Together, that's what reliable AI in software delivery actually looks like.

Software Delivery Context, Now Inside Claude

May 29, 2026

Technical

Time to Read

When Anthropic broke the news of Mythos and Project Glasswing, the security community did what it always does. It published a flurry of papers asking "What does this mean for security?" It's a reasonable instinct, but it's the wrong question.

The real question is who actually owns the problem?

The Advice Is Right. The Audience Is Wrong.

Even Anthropic's own guidance on preparing your security team for the AI era, comprehensive and well-reasoned as it is, lands squarely on steps that security teams can influence but cannot execute. Maintaining accurate inventories of exposed systems, decommissioning legacy services, and minimizing API exposure. These are all the right steps. They are also, unambiguously, engineering steps.

Security teams have owned these conversations for years, not because they were ever truly equipped to act on them, but because engineering was remarkably effective at passing the responsibility to someone else. That era is over.

The Eng & Sec Silos Have to Go

Take attack surface reduction as a concrete example. Anthropic's recommendations are sound: know what you're exposing, shut down what you don't need, lock down your APIs. But a security team cannot decommission a legacy service. They cannot refactor an API. They can nag, escalate, and document, then watch the ticket sit in a backlog for six months.

Engineering has to take this on. Not reluctantly, not after repeated escalations, but as a core ownership responsibility. The framing of "security's job" versus "engineering's job" is a liability the industry can no longer afford.

The Path Forward Is Uncomfortable — But It Starts Now

This transition won't be easy. Changing ownership models inside organizations is political, slow, and often painful. But the alternative means maintaining siloed teams while AI-accelerated vulnerability exploitation scales faster than any manual process can respond. That isn't a strategy. It's a countdown.

Here's what needs to happen immediately:

Security and engineering must jointly review what we know about threats like Mythos and the recommendations Anthropic has put forward — together, in the same room, with shared accountability.
Joint planning sessions aren't optional. Shared war-gaming, shared roadmaps, shared ownership of remediation timelines.
Cross-industry knowledge sharing is no longer optional. Threat actors collaborate, share tooling, and iterate in the open. The industry has to build the same sharing culture attackers already have.

The Wave Is Already Here

This isn't a theoretical future risk. The wave is already forming offshore, and most organizations are still debating whether to build a seawall.

AI hasn't just made attackers faster, it has fundamentally changed the economics of exploitation. What once required a skilled threat actor, weeks of reconnaissance, and significant resources can now be automated, scaled, and deployed by someone with a capable model and a motivated prompt. Zero day vulnerabilities that previously had a window of days or weeks before widespread exploitation are now being weaponized in hours. The asymmetry between attack and defense has never been more extreme.

Here's the uncomfortable truth: the traditional security model was never built for this speed. It was built for a world where humans attacked and humans defended, where there was time to deliberate, escalate, and patch. That world is gone.

Mythos doesn't wait for your quarterly security review. GlassWing doesn't care that your legacy service decommission is "on the roadmap for H2." AI-powered exploit tooling operates at machine speed. And right now, the defense side of that equation is still running on organizational clock time.

Two Futures

Organizations that recognize this moment and act on it will look very different in three years. Security and engineering will share OKRs, not just Slack channels. Remediation won't be a ticket handed off between teams, it will be a joint sprint. Attack surface reduction will be an engineering hygiene standard, not a security audit finding.

Organizations that don't adapt will face a different outcome. It won’t be a gradual decline, but a sudden, forced reorganization triggered by a breach that exposes exactly how brittle the old model was. The silo walls won't come down in a planned migration. They'll come down in an incident post-mortem.

This Is the Moment

Industry inflection points rarely announce themselves clearly, but this one is. The research is public and the threat models are documented. Anthropic, and others, have laid out precisely what needs to happen. The gap between knowing and doing is entirely organizational — and that gap is where the real risk lives.

The teams that start the hard conversations now about ownership, accountability, and shared responsibility are the ones that will be positioned to respond when the wave hits. And it will hit. The question isn't whether your organization needs to change. The question is whether you'll choose the terms.

Runtime Protection Agent Blogs

Featured Blogs

Harness Named a Leader in the 2026 Gartner® Magic Quadrant™ for DevSecOps Platforms for the Third Consecutive Year

Why This Matters Now

Our Journey

What’s Next for Harness

Learn More

Gartner Disclaimer

Latest Blogs

Scan without the guesswork: AI SAST and LLM Scan Orchestration

AI SAST

LLM Scan Orchestration

From finding to fix: Triage Agent and Remediation Agent

Triage Agent

Remediation Agent

Function-level reachability

Zero-days don't wait in line: Zero-Day Agent

Shielding production while the fix is in flight

Security at machine speed

Want to learn more?

Harness Announces Capabilities that Enable Security at Machine Speed

What happened

Why this matters

How teams can reduce the risk of similar incidents

How Harness could help

The bigger trend

Harness take

Closing

Key takeaways

FAQ

What is the ChainDrop npm worm?

How can malware have valid SLSA provenance?

What should teams do if they installed an affected package?

ChainDrop npm Worm Shows Why Valid Provenance Is Not Enough

The Discovery Isn't the Problem – Response Is

The Real Framework: Security at Machine Speed

The Dual Nature of the Problem: Security + Engineering

What's Next: AI Agents Close the Loop

The Window Is Closing

FORM SUBMISSION THANK YOU MESSAGE

Zero Day to Fix: Why Security Response Speed—Not Discovery—Is Your Real Bottleneck

Why Traditional SAST Is Struggling to Keep Up

The Four Reasons SAST Programs Fail

1. Developers Don't Trust Findings

2. Vulnerabilities Don't Get Fixed

3. Business Logic Vulnerabilities Are Missed

4. Security Cannot Match Development Velocity

AI SAST Is Not One Technology

LLM-Native Security Testing

AI-Assisted SAST

Three Myths About AI SAST

Myth #1: AI Eliminates False Positives

Myth #2: AI Will Replace Traditional SAST

Myth #3: AI Is Always Correct

Five Questions Every Buyer Should Ask

1. Can it secure AI-generated code?

2. Does it actually reduce noise?

3. Can it detect business logic vulnerabilities?

4. Does it improve remediation?

5. Are findings explainable?

The Emerging Hybrid Security Model

What Platform Teams Should Do Next

Shift Security Earlier

Optimize for Remediation

Prioritize Developer Experience

Conclusion

AI SAST Explained: Why Traditional Application Security Is Reaching Its Breaking Point

What Is WAAP?

Why WAAP Matters More Than Ever

1. The Explosion of APIs

2. Cloud and Microservices Architecture

3. Sophisticated Cyber Threats

4. Limitations of Traditional Security

The Core Components of WAAP

1. Web Application Firewall (WAF)

2. API Security

3. Bot & Abuse Protection

4. DDoS Protection

5. Application Threat Intelligence and Analytics

How WAAP Works in Practice