Security & Compliance | Harness Blog Primary Category

Technical

Authentication vs Authorization: What’s the Difference and Why It Matters

Learn the difference between authentication vs authorization, why both matter for app security, and how to protect modern APIs and microservices.

Michael Isbitski

April 3, 2026

Time to read

Authentication (autnN) proves identity; authorization (authZ) controls what that identity can access. You need both. One without the other leaves gaps.
In modern apps and microservices, you typically authenticate once but authorize at every sensitive boundary: APIs, services, and individual resources.
Strong authN/authZ, plus runtime protection, give you the layered defense modern web apps and APIs actually need.

‍

Let's get something out of the way: authentication and authorization are not the same thing.

We know, we know. People swap the two terms constantly. And honestly, it's easy to see why. They both start with "auth," they both deal with security, and they often show up in the same conversations on access control. But if you build or secure software, blurring the line between authentication and authorization is how you end up with a system where everyone is logged in and everyone is an admin. Not great.

Getting this distinction right is really the starting point for securing any modern web app or API with strong access controls. Authentication proves who's calling. Authorization decides what that caller can actually touch. And if you want runtime protection that goes beyond just getting those two right (think API discovery, security testing, and real-time threat defense), that's where a platform like Harness Web Application & API Protection (WAAP) fits in.

But first, let's break this down properly.

What Is Authentication?

Authentication answers one question: "Are you who you say you are?"

That's it. It's the process of verifying that a user, service, or machine is actually who they claim to be. They present something only they should possess; you check it against something you trust. Done.

The factors you'll see in practice usually fall into three buckets:

Something you know. Passwords, PINs, challenge question answers.
Something you have. Hardware tokens, authenticator apps, SMS codes, smart cards.
Something you are. Fingerprints, facial recognition, voice recognition.

Most modern systems don't rely on just one of these. They combine them into multi-factor authentication (MFA). You've done this yourself: type in your password, then confirm with a code from your authenticator app, which is often called two-factor authentication (2FA).

Here's what a typical authentication flow looks like in a web or mobile app:

A user submits credentials on a login page.
An identity provider (IdP) or authentication server verifies those credentials.
If everything checks out, the system creates an authenticated session and issues an authentication token.
Subsequent requests include that session identifier, the authentication token, or both, depending on the implementation, to prove the user has already been authenticated.

A handy way to think about it: authentication is the front desk of a secure building checking your ID badge before you’re able to walk in.

And this doesn't just apply to end users. In a mature engineering setup, you also want strong authentication to control access to your delivery tools. If you're using Harness Continuous Integration or Harness Continuous Delivery & GitOps, that means tying in SSO and MFA so only verified identities can trigger or modify your pipelines. It's a seemingly small matter, but it prevents big headaches.

What Is Authorization?

Authorization answers a different question entirely: "What are you allowed to do?"

Someone can be fully authenticated — you know exactly who they are — and still be blocked from certain actions. That's authorization doing its job.

There are a few common models for expressing authorization:

Discretionary Access Control (DAC). The resource owner decides who gets access. Think file sharing permissions.
Role-Based Access Control (RBAC). Permissions get grouped into roles like "viewer," "editor," or "admin." You assign users roles rather than giving them raw permissions one by one.
Attribute-Based Access Control (ABAC). Access decisions factor in attributes — department, region, environment, risk score, time of day. More flexible, but more complex.

Some quick examples of authorization in the real world:

A regular user can view their own profile but can't edit someone else's.
A team member can see project data, but only the project owner can delete the project.
An internal service can read from a database but can never write to certain tables.

If authentication is the front desk checking your ID, authorization is the badge reader on each door deciding which rooms your badge actually opens.

You see this play out in any mature platform. Fine-grained RBAC and policy controls determine who can deploy, who can approve changes, and who can modify infrastructure or experiment with configurations. It's not enough to know who someone is; you need to control what they can do.

Authentication vs Authorization: Key Differences at a Glance

Here's a quick comparison table you can bookmark and come back to.

Aspect	Authentication	Authorization
Core question	Who are you?	What are you allowed to do?
Purpose	Verify identity	Control access and actions
Happens when	At login or initial connection	After authentication, on every access decision
Basis for decision	Credentials or identity factors	Policies, roles, attributes, permissions
Data involved	Usernames, passwords, keys, tokens, certificates	Roles, scopes, permissions, resource rules
Visible to user?	Usually, yes: login prompts, MFA challenges	Often invisible: access is allowed or denied behind the scenes
Granularity	Identity level (user, service, device)	Resource and action level (what, where, how)
Example question	"Is this really Alice?"	"Can Alice edit this invoice?"
Typical components	Identity provider, login form, MFA provider	Policy engine, ACLs, RBAC/ABAC rules, permission checks
Failure result	Cannot log in or start a session	Logged in, but specific operations or resources are denied

The short version: authentication proves identity, authorization limits power.

How Authentication Works in Modern Applications

Password-based login. The classic username-and-password combo, usually augmented with MFA these days.

Single Sign-On (SSO). You authenticate once against an IdP, then use multiple apps without logging in again. Typically powered by SAML or OpenID Connect. If you've ever clicked "Sign in with Google" at work and had five different tools just... work, that's SSO.

Passwordless authentication. Magic links, WebAuthn, hardware keys, or biometrics. The whole idea is to reduce your dependence on passwords, which — let's be honest — people are terrible at managing.

A few protocols and standards worth knowing:

OAuth 2.0. A framework for delegated access. Often paired with OpenID Connect for authentication.
OpenID Connect (OIDC). Sits on top of OAuth 2.0 and defines how to authenticate users and issue ID tokens.
SAML 2.0. The XML-based standard you'll see all over enterprise SSO setups.

A typical OIDC-based flow looks like this:

Your application redirects the user to the IdP login page.
The user authenticates with credentials (and possibly MFA).
The IdP issues an ID token (who the user is) and often an access token (for API calls).
Your application validates the token and starts an authenticated session.

But here's the thing people forget: once someone is authenticated, they still need authorization checks for every specific action they try to take. That's the next layer.

And as you automate more of your software delivery lifecycle with tools like Harness CI/CD and Harness Feature Management & Experimentation, enforcing strong authentication for deploys, rollouts, and feature flag operations becomes part of your security posture — not something you bolt on later.

How Authorization Works in Modern Applications

After authentication establishes identity, authorization decides what that identity is actually allowed to do. This is where the real granularity lives.

The key building blocks:

Roles and permissions. Roles like "user," "manager," "admin," "billing," "support." Permissions like "read:projects," "update:billing," "delete:users." You map permissions to roles, and roles to identities. Usually, this is synonymous with permissioning data and functionality so that people can access them, but in the age of AI, identities are increasingly machines.

Policies. Conditional rules, for instance: "Allow role = manager to approve expenses up to $10,000" or "Deny write access to production logs for everyone except SREs." This is where things get interesting.

Scopes. Common in OAuth flows: strings like read:user or write:orders that get granted to clients or tokens.

Here's a practical example. Imagine a project management SaaS:

Members can create and edit tasks within their own projects.
Project owners can invite users and manage project-level permissions.
Organization admins can configure billing and company-wide settings.

In code, authorization checks can live in several places:

API gateways (route level)
Middleware (request pipeline)
Business logic (right before executing an operation),
External policy engines (dedicated decision services your app queries).

The best practice? Keep these rules streamlined, centralized, and auditable. If access rules are scattered across dozens of gateways, controllers, and routing services, you’ll struggle to track what's actually enforced.

Common Pitfalls When You Mix Up Authentication and Authorization

Confusing authentication and authorization isn't just a terminology slip. It's a security problem that shows up in real systems all the time.

Here are the mistakes we see most often:

"If you're logged in, you can do everything." The system treats authentication as the only gate. The result? Every authenticated user basically has admin access. This is more common than you'd think, especially in internal tools that start as quick prototypes and never get proper authorization layers.
Authorization checks only in the UI. The buttons are hidden from certain users, but the underlying APIs don't enforce the same rules. Anyone with network access and a bit of curiosity (or a tool like Postman) can call privileged endpoints directly.
Permissions scattered across the codebase with no central view. Developers copy-paste authorization checks into controllers, services, and frontends. Over time, it becomes impossible to understand who can actually do what in the system.
Over-trusting third-party auth. Teams assume that because SSO or social login is in place, authorization is "handled." But authentication-as-a-service doesn't mean authorization is solved. They're separate problems.

The fix is straightforward in concept: treat authentication and authorization as separate, layered concerns; each with their own design, tooling, and governance. Strong identity and access control at the application and platform level, combined with runtime defense from something like Harness WAAP, gives you visibility, prevention, and protection to mitigate threats that inevitably arise.

Authentication vs Authorization in Cloud and Microservices

In distributed cloud-native systems, the authentication vs authorization picture gets more complex. It's not just about human users anymore. It's also services, workloads, and machines, or non-human identities (NHI) talking to each other. Authentication material, often referred to as secrets, can proliferate rapidly.

Here are the patterns that matter:

API and gateway authentication. Gateways and microgateways verify tokens, certificates, or API keys. Once a request is authenticated, authorization policies determine which backend services or microservices it can actually reach.
Service-to-service identity. Microservices authenticate to each other using mutual TLS, service accounts, or workload identities. Authorization then defines which services can call which APIs, and with what HTTP methods.
Fine-grained authorization per resource. Picture a multi-tenant SaaS that authorizes every single request based on tenant, user role, resource owner, and environment (dev, staging, production). That's a lot of decisions happening very fast.

A useful mental model: Authenticate once. Authorize often. Identity gets established at the start of a request. Authorization happens at every gate where something sensitive might occur.

At this scale, you also need visibility. Harness WAAP discovers APIs (including shadow APIs and zombie APIs you didn't even know existed), understands traffic patterns, and applies API-centric protection on top of whatever access controls you already have in place. It's built for cloud-native environments, with deployment options ranging from out-of-band traffic mirroring to inline agents at the gateway level to edge-delivered protection.

Choosing the Right Authentication Strategy

A good authentication strategy balances usability, security, and operational overhead. Here's what to think about:

MFA by default for admin accounts, financial operations, and anything touching production. MFA should also be a preferred default for customer identity, particularly when controlling access to sensitive or regulated data like PHI or PII.
Single Sign-On with a central IdP for teams and enterprises. It reduces password reuse and credential fatigue so users stop creating variations of "Summer2024!" across twelve different applications.
Passwordless options where you can get away with them, such as in customer applications where lower friction and higher usability are paramount. These options cut phishing risk dramatically.
Token-based auth such as JSON Web Tokens (JWT) and opaque tokens for APIs and mobile apps, with proper expiration and rotation policies.

Some design questions worth asking early:

Who are your users? Humans, non-human identities, or both?
How critical is the data or operation they're accessing?
What regulatory or compliance requirements apply?
How will you cleanly onboard and offboard users?

On the delivery side, use strong authentication for everything that can change your production system. Production impact should never hang on a shared service account or a weak auth story.

Designing a Solid Authorization Model

Authorization design has a direct impact on how secure and maintainable your system feels day to day. Get it right early, and life is good. Get it wrong, and you'll be untangling spaghetti permissions for years.

Here's what works:

Use roles, not individual permission lists everywhere. Map your real-world responsibilities to roles, then assign permissions to those roles. It's far easier to reason about "what can an editor do?" than to track permission assignments for 500 individual users.
Add attributes when roles aren't enough. ABAC patterns shine when you need to factor in department, geography, environment, or risk signals. Not every access decision is as simple as "admin or not admin."
Enforce least privilege. Start with minimal permissions and add what's actually needed. This sounds obvious, but the default in most organizations is to hand out broad access and hope for the best.
Centralize your decision logic. Use a consistent policy engine or middleware for all authorization checks, with proper logging and audit trails.
Review regularly. Roles and policies drift over time. People change teams, projects wind down, new services spin up. Periodic reviews keep your model aligned with reality.

Platforms that bake in policy-as-code, governance, and auditability make this much more practical.

Get Authentication and Authorization Right Early

The difference between authentication and authorization is simple to describe and surprisingly easy to forget in the day-to-day rush of shipping features. Authentication proves identity. Authorization defines and enforces what that identity can do. Two separate problems, two separate layers of defense.

Designing both layers up front — with clear models, strong authentication, and auditable authorization policies — saves you from painful retrofits, compliance surprises, and security incidents down the road.

Then you protect everything you've built at runtime. For full API visibility and real-time defense of your web apps and APIs — without slowing down your engineering teams — take a closer look at Harness Web Application & API Protection (WAAP) and pair it with secure delivery powered by Harness CI/CD.

Book a demo to get started.

FAQ: Authentication vs Authorization

Why is it important to understand authentication vs authorization?

Because they solve different problems. Authentication proves identity. Authorization controls access. If you blur that line, you either block valid users from doing their work or, worse, grant excessive power to anyone who can log in.

Can you have authorization without authentication?

In any secure system, not really. You need an authenticated identity before you can make meaningful authorization decisions. There are anonymous or public access patterns, sure, but those are modeled as very limited authorization cases; not a free pass.

What are some real-world examples of authentication?

Typing a password into a login form. Using Face ID on your phone. Inserting a smart card into a corporate laptop. Scanning a fingerprint to open a secure door. Confirming a login with a one-time code from an authenticator app. If you're proving you are who you say you are, that's authentication.

What are some real-world examples of authorization?

Being able to view a dashboard but not edit system settings. Having read-only access to a database table. Being allowed to approve expenses up to a certain dollar amount. Having permission to deploy to staging but not to production. If the system is deciding what you can and can't do, that's authorization.

How do OAuth 2.0 and OpenID Connect relate to authentication vs authorization?

OAuth 2.0 started primarily as a framework for authorization — specifically, delegated access. OpenID Connect adds a standardized authentication layer on top of OAuth 2.0. In practice, many systems use them both, but they still map cleanly to the separate ideas of "who are you" (authentication) and "what can you do" (authorization).

Technical

LiteLLM Compromise: Securing AI Pipelines from PyPI Supply Chain Attacks

LiteLLM PyPI was compromised in a supply chain attack, using .pth files and blockchain C2 to steal credentials and execute persistent, multi-stage malware.

Pranay Shah

Roshan Piyush

March 26, 2026

Time to read

On March 24, 2026, the AI open-source ecosystem was impacted by a critical supply chain attack involving the widely used Python package LiteLLM. Attackers compromised the LiteLLM PyPI distribution pipeline and published malicious versions (notably in the 1.82.7-1.82.8 range), embedding a multi-stage payload designed to steal credentials and execute remote code.

The malicious code executed during normal library usage, making it particularly dangerous for AI applications that integrate LiteLLM into inference pipelines, RAG systems, and API gateways. The attack leveraged Python’s .pth file mechanism, a lesser-known but powerful feature that allows arbitrary code execution during interpreter initialization. The malicious package dropped a file (e.g., litellm_init.pth) into the Python environment, ensuring that the payload was executed every time the Python interpreter started, regardless of whether LiteLLM was explicitly imported.

However, this was not a simple static backdoor. The package implemented a multi-stage execution chain, where initial execution triggered outbound communication to attacker-controlled infrastructure to retrieve further instructions dynamically.

Notably, the malware leveraged blockchain-based command-and-control (C2) and extracting payload locations from transaction metadata. This allowed attackers to update payload delivery dynamically without modifying the package itself, making detection and takedown significantly harder.

The attack also performed a cross-language execution pivot, downloading a Node.js runtime onto the host system and executing an obfuscated second-stage JavaScript payload. This technique enabled evasion of Python-focused security controls and introduced runtime behavior that would not typically be expected during dependency execution.

Once triggered, the payload attempted to exfiltrate sensitive environment variables and secrets, including API keys for major LLM providers (OpenAI, Anthropic), cloud credentials, and internal tokens.

Python .pth Files: Silent Execution Hooks at Interpreter Startup

A critical aspect of this attack is the abuse of Python’s .pth file mechanism, an often overlooked feature that can be weaponized for persistent, pre-execution code injection.

.pth files are automatically processed during Python interpreter startup via the site module. They are typically located in site-packages or user site directories and are intended to extend Python’s module search path.

However, .pth files support more than just path configuration. If a line starts with an import, it is executed immediately:

Example: Simple Demo of Hidden Code Execution

DIY: Find your site-packages path

python3 -c "import site; print(site.getsitepackages())"
# Or 
python3 -c "import site; print(site.getusersitepackages())"
#  Choose the one with write access and 
#  write a demo1.pth file to that site packages dir
echo 'import sys; print("[PTH DEMO EXECUTED]")' > /path/to/site-packages/demo1.pth

Or

Automated script to create the demo .pth file

git clone https://github.com/aspen-labs/python_pth_autoexecution.git
cd python_pth_autoexecution
python3 demo_pth.py

Now, every time Python runs,

> python3 -c "print('Hello')"
[PTH DEMO EXECUTED]
Hello

Impact:

Compromised PyPI versions of LiteLLM (primarily 1.82.x series) distributed malicious code to downstream users.
Persistent execution via .pth interpreter hijacking, enabling code execution on every Python startup without intended use of the library.
Use of decentralized C2 (blockchain) makes traditional takedown and IOC blocking less effective.
Execution of second-stage JavaScript payloads (e.g., i.js), enabling cross-language runtime pivoting and evasion of Python-focused detection controls
Exposure of sensitive credentials, including LLM API keys, cloud provider secrets, and environment variables.
High risk to AI/LLM applications, especially RAG pipelines and backend services handling user prompts and responses.
Potential lateral movement into CI/CD systems and production environments due to leaked credentials.

This attack highlights a new class of supply chain risk centered around AI infrastructure dependencies. Unlike traditional package compromises, the blast radius extends into model access, prompt data, and downstream AI workflows. It reinforces the need for continuous dependency monitoring, real-time SBOM visibility, and strict policy enforcement to prevent compromised packages from entering build and runtime environments.

How Harness Supply Chain Security Helps

Harness SCS helps you quickly detect and contain compromised dependencies like the LiteLLM 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 LiteLLM Package

Harness SCS enables instant search across all repositories and artifacts to quickly identify if compromised LiteLLM 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 LiteLLM Packages

Harness AI streamlines response to incidents like the LiteLLM compromise through simple natural-language prompts. With a single prompt, you can generate OPA policies to block affected LiteLLM versions 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 LiteLLM 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 LiteLLM compromise highlights how quickly a malicious package can expose high-value secrets when embedded deep within AI application stacks. Given its role in handling LLM requests, 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 LiteLLM 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 AI supply chain against attacks like the LiteLLM compromise.

Also, learn how Harness SCS defends against Shai-Hulud, TJ Actions, NPM 1.0, xz-utils supply chain attacks.

Technical

Introducing Radar in Harness Bot & Abuse Protection

Radar, a new threat visualization engine for Harness Bot & Abuse Protection, instantly maps complex attack sequences and speeds up incident response.

Michael Isbitski

Ayan Halder

March 25, 2026

Time to read

Visualizing the DNA of Distributed Attacks

We are thrilled to announce the launch of Radar, a major update to Harness Bot & Abuse Protection that fundamentally changes how security teams investigate and respond to sophisticated threats.

Sophisticated bot attacks are rarely isolated incidents. They are complex networks of connected identities, shared fingerprints, and coordinated behaviors. Traditional lists and tables pulled from disparate logs and event data fail to capture this reality, forcing SOC analysts to manually correlate relevant attack data—a process that costs hours when seconds matter in a potential breach.

Introducing Radar in Harness Bot & Abuse Protection

Radar changes the game for bot attack response. It is an intelligent threat visualization engine that instantly unmasks hidden relationships in bot attacks, turning the abstract "DNA" of an automated threat into a clear, interactive map.

It helps with

Speed to Verdict: What used to take hours of manual cross-referencing now takes seconds of visual inspection.
Explainable Security: Radar "white-boxes" our detection logic, giving you visual proof of why we flagged a cluster of users.
Enterprise-Grade Depth: Built to meet the rigorous demands of leading financial institutions and E-Commerce, Radar handles the complexity of high-stakes fraud investigations with ease.

Why SecOps Teams Need Threat Visualization

SOC analysts struggle to quickly respond to advanced threats and bot attacks targeting their organization’s systems. Analysis of recent breach data shows that on average organizations take roughly six months to identify the related incident. Advanced automated bot and abuse attacks, increasingly accelerated with AI, frequently go undiscovered for this time period. The harsh reality is that data relationships and system interconnects in enterprise environments are complex to unwind as automated threats play out, leaving significant incident response gaps for threat detection.

Inhibited response: Security teams spend days, weeks, or months manually cross-referencing siloed data, delaying incident response when speed is critical.
Opaque Security: Detection logic in other bot mitigation offerings is a black box, leaving SecOps teams with little insight or evidence to justify why users or clusters are flagged.
Limited Depth: Existing tools struggle to handle the complexity and scale of high-stakes fraud investigations, falling short of enterprise requirements for financial institutions and e-commerce.

Radar Key Capabilities

1. The Unified Threat Canvas

Stop investigating accounts in silos. Radar projects user connections onto an interactive graph, instantly revealing the shared threat signatures—such as IP subnets, device fingerprints, and behavioral patterns—that bind disparate accounts and activities together. You can now see the shape of the attack campaign at a glance.

‍

2. AI-Powered Context

Understanding why accounts are connected is just as important as knowing that they are connected. Radar integrates deep AI insights that analyze the cluster to provide a narrative summary of the attack. Whether it's a "distributed credential stuffing attack via a residential proxy ring" or "coordinated inventory hoarding," Harness AI explains the security context so you don't have to guess.

3. Portable Forensics

We know your investigation doesn't always end in our console. Radar features a robust export engine that packages every data point—user details, threat activities, and linkage evidence—into a comprehensive format ready for your SIEM and SOAR tools or related DFIR workflows.

‍

Get Started Today

Radar is available immediately with your existing Harness Bot & Abuse Protection subscription. There is no additional cost or setup required.

Current Customers: Log in to your dashboard today to start exploring your threat data in a whole new dimension.
New to the Platform? If you aren't yet protected, contact us to schedule a personalized demo of Radar in action.

Request a demo

Technical

Zachary Gruenberg on Machine Identity Security in the Age of AI

Palo Alto Networks Solution Engineer Zachary Gruenberg joins the ShipTalk podcast at SREday NYC 2026 to discuss machine identity security, AI agents, and how SRE teams can manage identity sprawl.

Dewan Ahmed

March 19, 2026

Time to read

At SREday NYC 2026, the ShipTalk podcast welcomed Zachary Gruenberg, Solution Engineer and Machine Identity SME at Palo Alto Networks, for a conversation about one of the fastest growing challenges in modern infrastructure: machine identity management.

Throughout the conference, much of the discussion centered on AI agents automating operational tasks—from incident response to infrastructure management. But every automated agent interacting with systems still requires credentials and access permissions.

In the episode, ShipTalk host Dewan Ahmed, Principal Developer Advocate at Harness, spoke with Zachary about how the rapid rise of AI-driven automation is creating an explosion of machine identities—and why managing them is quickly becoming a major security concern for SRE and platform teams.

🎧 Listen to the Full Episode

The Explosion of Machine Identities

In the past, identity management primarily focused on human users logging into systems.

Today, the landscape looks very different.

Modern infrastructure environments include a growing number of non-human identities such as:

service accounts
automation scripts
CI/CD pipelines
microservices communicating with each other
AI agents performing operational tasks

Each of these components requires credentials in order to interact with infrastructure, APIs, and other services.

As organizations deploy more automation and AI-driven workflows, the number of machine identities can quickly outnumber human users by several orders of magnitude.

For SRE teams, this creates a new challenge: tracking which systems have access to what resources—and ensuring those permissions remain secure.

Building Security That Scales with Automation

One of the most common problems Zachary sees is that teams prioritize functionality when deploying new automation systems.

When engineers introduce AI agents or automated workflows, identity management is often treated as an afterthought.

That approach can lead to:

overly permissive service accounts
long-lived credentials
unclear ownership of machine identities
difficulty auditing access across systems

To address this, Zachary encourages organizations to treat machine identity as a core component of their security architecture, rather than a secondary concern.

This often includes practices such as:

implementing short-lived credentials
centralizing identity management across services
applying the principle of least privilege to machine accounts
automating identity lifecycle management alongside infrastructure automation

When these controls are built into the platform early, security can scale alongside automation instead of becoming a bottleneck.

The Most Common Machine Identity Blind Spot

Despite the growing awareness of identity security, Zachary frequently encounters one recurring issue.

Many teams simply lose track of the machine identities they have created.

Over time, environments accumulate service accounts, API keys, tokens, and automation credentials that remain active long after the systems that created them are gone.

This “identity sprawl” can create significant risk, particularly in environments where automated systems are interacting with critical infrastructure.

The challenge becomes even greater as AI agents begin performing more complex operational tasks.

Ensuring that these agents have the right level of access—and no more—requires visibility into every identity operating within the system.

Security in an Autonomous Infrastructure World

As organizations adopt AI-driven automation across operations, the importance of identity security will only increase.

Each new automation tool or AI workflow adds another layer of machine identities interacting with infrastructure.

For SRE and platform teams, this means reliability engineering and security practices are becoming increasingly interconnected.

Strong machine identity management ensures that automation systems can operate safely while protecting the infrastructure they interact with.

‍

Final Thoughts

Zachary Gruenberg’s message is a timely reminder that the growth of AI agents and automation does not eliminate the need for strong security foundations.

If anything, it makes them even more critical.

As organizations move toward more autonomous systems, understanding who—or what—has access to critical infrastructure will remain one of the most important challenges for reliability and security teams alike.

🎧 Listen to the Full Episode

Subscribe to the ShipTalk Podcast

Enjoy conversations like this with engineers, platform builders, and reliability leaders from across the industry.

Follow ShipTalk on your favorite podcast platform and stay tuned for more stories from the people building the systems that power modern technology. 🎙️🚀

Technical

Securing AI and Securing With AI: AI Security from Code to Runtime With Harness

Harness launches AI Security and Secure AI Coding to discover, test, and protect AI-native apps and AI-generated code across the DevSecOps lifecycle.

Renny Shen

Rahul Sood

March 17, 2026

Time to read

AI is changing both what you build and how you build it - at the same time. Today, Harness is announcing two new products to secure both: AI Security, a new product to discover, test, and protect AI running in your applications, and Secure AI Coding, a new capability of Harness SAST that secures the code your AI tools are writing. Together, they further extend Harness's DevSecOps platform into the age of AI, covering the full lifecycle from the first line of AI-generated code to the models running in production.

In November, Harness published our State of AI-Native Application Security report, a survey of hundreds of security and engineering leaders on how AI-native applications are changing your threat surface. The findings were stark: 61% of new applications are now AI-powered, yet most organizations lack the tools to discover what AI models and agents exist in their environments, test them for vulnerabilities unique to AI, or protect them at runtime. The attack surface has expanded dramatically — but the tools to defend it haven't kept up.

The picture is equally concerning on the development side. Our State of AI in Software Engineering report found that 63% of organizations are already using AI coding assistants - tools like Claude Code, Cursor, and Windsurf - to write code faster. But faster isn't safer. AI-generated code has the same vulnerabilities as human-written code, but now with larger and more frequent commits. AppSec programs that were already stretched thin are now breaking under the volume and velocity.

The result is a blind spot on both sides of the AI equation - what you're building, and what you're building with. Today, Harness is closing that gap.

What Makes Harness Different?

Most security vendors are stuck in their lane. Shift-left tools catch vulnerabilities in code before they reach production. Runtime protection tools block attacks after applications are deployed. And the two rarely talk to each other.

Harness was built on a different premise: real DevSecOps means connecting every stage of the software delivery lifecycle, and closing the loop between what you find in production and what you fix in code.

That's what the Harness platform does today. Application Security Testing brings SAST and SCA directly into the development workflow, surfacing vulnerabilities where they're faster and cheaper to fix. SCS ensures the integrity of artifacts from build to deploy, while STO provides a unified view of security posture — along with policy and governance — across the entire organization.

As code ships to production, Web Application & API Protection monitors and defends applications and APIs in real time, detecting and blocking attacks as they happen. And critically, findings from runtime don't disappear into a security team's backlog — they flow back to developers to address root causes before the next release.

The result is a closed loop: find it in code, protect it in production, fix it fast. All on a single, unified platform.

Today, we're extending that loop into AI - on both sides. AI is reshaping what you build and how you build it simultaneously. A platform that can only address one side of that equation leaves you exposed on the other. Harness closes both gaps.

Introducing AI Security

In the State of AI-Native Application Security, 66% of respondents said they are flying blind when it comes to securing AI-native apps. 72% call shadow AI a gaping chasm in their security posture. 63% believe AI-native applications are more vulnerable than traditional IT applications. They’re right to be concerned.

Harness AI Security is built on the foundation of our API security platform. Every LLM call, every MCP server, every AI agent communicating with an external service does so via APIs. Your AI attack surface isn't separate from your API attack surface; it's an expansion of it. AI threats introduce new vectors like prompt injection, model manipulation, and data poisoning on top of the API vulnerabilities your teams already contend with. There is no AI security without API security.

With the launch of AI Security, we are introducing AI Discovery in General Availability (GA). AI security starts where API security starts: discovery. You can't assess or mitigate risk from AI components you don't know exist. Harness already continuously monitors your environment for new API endpoints the moment they're deployed. Recognizing LLMs, MCP servers, AI agents, and third-party GenAI services like OpenAI and Anthropic is a natural extension of that. AI Discovery automatically inventories your entire AI attack surface in real time, including calls to external GenAI services that could expose sensitive data, and surfaces runtime risks, such as unauthenticated APIs calling LLMs, weak encryption, or regulated data flowing to external models.

Beyond discovering and inventorying your AI application components, we are also introducing AI Testing and AI Firewall in Beta, extending AI Security across the full discover-test-protect lifecycle.

AI Testing actively probes your LLMs, agents, and AI-powered APIs for vulnerabilities unique to AI-native applications, including prompt injection, jailbreaks, model manipulation, data leakage, and more. These aren't vulnerabilities that a traditional DAST tool is designed to find. AI Testing was purpose-built for AI threats, continuously validating that your models and the APIs that expose them behave safely under adversarial conditions. It integrates directly into your existing CI/CD pipelines, so AI-specific security testing becomes part of every release — not a one-time audit.

AI Firewall actively protects your AI applications from AI-specific threats, such as the OWASP Top 10 for LLM Applications. It inspects and filters LLM inputs and outputs in real time, blocking prompt injection attempts, preventing sensitive data exfiltration, and enforcing behavioral guardrails on your models and agents before an attack can succeed. Unlike traditional WAF rules that require manual tuning for every new threat pattern, AI Firewall understands AI-native attack vectors natively, adapting to the evolving tactics attackers use against generative AI.

Harness AI Security with AI Discovery is now available in GA, while AI Testing and AI Firewall are available in Beta.

Introducing Secure AI Coding

"As AI-assisted development becomes standard practice, the security implications of AI-generated code are becoming a material blind spot for enterprises. IDC research indicates developers accept nearly 40% of AI-generated code without revision, which can allow insecure patterns to propagate as organizations increase code output faster than they expand validation and governance, widening the gap between development velocity and application risk."

— Katie Norton, Research Manager, DevSecOps, IDC

AI Security addresses the risks inside your AI-native applications. Secure AI Coding addresses a different problem: the vulnerabilities your AI tools are introducing into your codebase.

Developers are generating more code than ever, and shipping it faster than ever. AI coding assistants now contribute to the majority of new code at many organizations — and nearly half (48%) of security and engineering leaders are concerned about the vulnerabilities that come with it. AI-generated code arrives in larger commits, at higher frequency, and often with less review than human-written code would receive.

SAST tools catch vulnerabilities at the PR stage — but by then, AI-generated code has already been written, reviewed, and often partially shipped. Harness SAST's new Secure AI Coding capability moves the security check earlier to the moment of generation, integrating directly with AI coding tools like Cursor, Windsurf, and Claude Code to scan code as it appears in the IDE. Developers never leave their workflow. They see a vulnerability warning inline, alongside a prompt to send the flagged code back to the agent for remediation — all without switching tools or even needing to trigger a manual scan.

"Security shouldn't be an afterthought when using AI dev tools. Our collaboration with Harness kicks off vulnerability detection directly in the developer workflow, so all generated code is screened from the start." — Jeff Wang, CEO, Windsurf

What sets Secure AI Coding apart from simpler linting tools is what happens beneath the surface. Rather than pattern-matching the AI-generated code in isolation, it leverages Harness's Code Property Graph (CPG) to trace how data flows through the entire application - before, through, and after the AI-generated code in question. That means Secure AI Coding can surface complex vulnerabilities like injection flaws and insecure data handling that only become visible in the context of the broader codebase. The result is security that understands your application - not just the last thing an AI assistant wrote.

We Had the Same Problem

When we deployed AI across our own platform, our AI ecosystem grew faster than our visibility into it. We needed a way to track every API call, identify sensitive data exposure, and monitor calls to external vendors — including OpenAI, Vertex AI, and Anthropic — without slowing down our engineering teams.

Deploying AI Security turned that black box into a transparent, manageable environment. Some milestones from our last 90 days:

We now track 111 AI assets and monitor over 4.76 million monthly API calls, giving our security team a granular, real-time map of our entire AI attack surface.
We now run 2,500 AI testing scans a week and have remediated 92% of the issues found, including critical weak authentication and encryption gaps in MCP tools.
We identified and blocked 1,140 unique threat actors attempting more than 14,900 attacks against our AI infrastructure.

The shift wasn't just operational — it was cultural. We moved from reactive monitoring to proactive defense. As our team put it: "Securing AI is foundational for us. Because our own product runs on AI, it must be resilient and secure. We use our own AI Security tools to ensure that every innovation we ship is backed by the highest security standards."

Ready to Secure Your AI?

AI is moving fast. Your attack surface is expanding in two directions at once - inside the applications you're building, and inside the code your teams are generating to build them.

Harness AI Security and Secure AI Coding are available now. Whether you're trying to get visibility into the AI running in your environment, test it for vulnerabilities before attackers do, or stop insecure AI-generated code from reaching production, Harness’ platform is ready.

Talk to your account team about AI Security. Get a live walkthrough of AI Discovery, AI Testing, and AI Firewall, and see how your AI attack surface maps against your existing API security posture.

Already a Harness CI customer? Start a free trial of Harness SAST - including Secure AI Coding. Connect it to your AI coding assistant, and see what's shipping in your AI-generated code today.

Contact us

Technical

From Shadow AI to Full Visibility: Operationalising AI Security at Scale

How modern enterprises discover AI systems, understand sensitive data exposure, assess AI-specific risks, and integrate AI posture into security operations.

Sanket Raut

March 16, 2026

Time to read

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

Why AI Security Posture Management Matters Now

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

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

Example: Shadow AI in a financial services firm

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

The Framework: Discover - Understand - Assess Risk - Operationalise

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

01 Discover
Shadow AI & MCP

02 Understand
Sensitive data flows

03 Assess Risk
AI-specific risks

04 Operationalise
Integrate into SecOps

01 Discover: Build the Complete AI Asset Inventory

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

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

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

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

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

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

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

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

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

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

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

04 Operationalise: Integrate AI Posture into Security Workflows

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

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

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

Maturity Model: Day 1 - Day 30 - Day 90

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

Stage	Security Focus	Outcome
Day 1	Discover all AI APIs, MCP servers, MCP Tools, Vector DB, and RAG APIs across all environments	Complete AI asset inventory; shadow AI flagged for immediate review
Day 30	Map sensitive data flows; apply AI-specific risk scoring; prioritise remediation	High-risk AI endpoints identified; 3rd-party data flows assessed against DPAs
Day 90	Integrate AI posture into SOC, compliance reporting, and vulnerability SLAs	AI security governed continuously; audit evidence on demand; attack surface shrinking

KEY
INSIGHT

The Day 1 to Day 30 transition is the most critical: moving from 'we have a list' to 'we understand what our AI systems touch and which carry the most risk.' Most organisations stall at Day 1 because they lack the data classification and risk scoring layer to act on what they found.

Enterprise Extension: ServiceNow CMDB Integration

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

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

‍

The Bottom Line

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

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

Technical

From Artifact Storage to Supply Chain Control: Rethinking Artifact Management with Harness

Modernize artifact management with built-in security and governance. Secure dependencies at ingest and scale software delivery with confidence.

Mrinalini Sugosh

February 19, 2026

Time to read

From Artifact Storage to Supply Chain Control: Rethinking Artifact Management with Harness

Harness Artifact Registry marks an important milestone as it evolves from universal artifact management into an active control point for the software supply chain. With growing enterprise adoption and new security and governance capabilities, Artifact Registry is helping teams block risky dependencies before they reach the pipeline, reduce supply chain exposure, and scale artifact management without slowing developers down.

In little over a year, Harness Artifact Registry has grown from early discovery to strong enterprise adoption, supporting a wide range of artifact formats, enterprise-scale storage, and high-throughput CI/CD pipelines across both customers and internal teams. What started as a focused initiative inside Harness has evolved into a startup within a startup, quickly becoming a core pillar of the Harness platform.

Today, we’re sharing how Artifact Registry is helping organizations scale software delivery by simplifying artifact management, strengthening supply chain security, and improving developer experience and where we’re headed next.

[Intro Video]

Building a Modernized, Cloud Native Artifact Management

In customer conversations, one theme came up repeatedly: as organizations scale CI/CD, artifacts multiply fast. Containers, packages, binaries, Helm charts, and more end up spreading across fragmented tools with inconsistent controls. Teams don't want just another registry. They want one trusted system, deeply integrated with CI/CD, that can scale globally and enforce policy by default. That's exactly what the Artifact Registry was built to be. By embedding artifact management directly into the Harness platform, it reduces tooling sprawl while giving platform engineering, DevOps, and AppSec teams centralized visibility and control, without slowing developers down.

Artifact Registry: A Unified Home for Every Artifact

Today, Artifact Registry supports a growing ecosystem of artifact types, with Docker, Helm (OCI), Generic, Python, npm, Go, NuGet, Dart, Conda, PHP Composer, and AI artifacts now available, and more on the way. With Artifact Registry, teams can:

Centralize all artifacts across CI and CD in one platform-native registry
Scale globally with multi-region replication for performance and resilience
Simplify migration with built-in tooling to move from existing registries
Deliver faster, more reliable artifact pulls across environments

The business impact is already clear. Artifact Registry has quickly gained traction with several enterprise customers, driven by strong platform integration, low-friction adoption, and the advantage of having artifact management natively embedded within the CI/CD platform.

One early customer managing artifacts across Docker, Helm, Python, NPM, Go, and more has standardized on Harness Artifact Registry, achieving 100% CI adoption across teams and pipelines.

“Harness Artifact Registry is stable, performant, and easy to trust at scale, delivering faster and more reliable artifact pulls than our previous vendor”
— SRE Lead

By unifying artifact storage with the rest of the software delivery lifecycle, Artifact Registry simplifies operations while helping teams focus on shipping software.

Shifting from Passive Storage to Active Governance

Software supply chain threats have become both more frequent and more sophisticated. High-profile incidents like the SolarWinds breach, where attackers injected malicious code into trusted update binaries affecting thousands of organizations, exposed how deeply a compromised artifact can penetrate enterprise systems. More recently, the Shai-Hulud 2.0 campaign saw self-propagating malware compromise hundreds of npm packages and tens of thousands of downstream repositories, harvesting credentials and spreading automatically through development environments.

As these attacks show, risk doesn’t only exist after a build, it can be embedded long before artifacts reach CI/CD pipelines. That’s why Harness Artifact Registry was designed with governance at its core.

Blocking Risky Dependencies Before They Reach Your Pipeline

Harness Artifact Registry includes Dependency Firewall, a control point that allows organizations to govern which dependencies are allowed into their environment in the first place. Rather than relying on downstream scans after a package has already been pulled into CI/CD, Dependency Firewall evaluates dependency requests at ingest using policy-based controls.

This allows teams to proactively block risky artifacts before they are ever downloaded. Organizations can prevent the use of dependencies with known CVEs or license violations, blocking risky dependencies before they reach your pipeline, and restrict access to untrusted or unsafe upstream sources by default. The result is earlier risk reduction, fewer security exceptions later in the pipeline, and stronger alignment between AppSec and development teams without slowing delivery.

[Dependency Firewall Explainer Video]

Automatically Blocking Risky Artifacts Before Deployment

To further strengthen supply chain protection, Artifact Registry provides built-in artifact quarantine, allowing organizations to automatically block artifacts that fail security or compliance checks. Quarantined artifacts cannot be downloaded or deployed until they meet defined policy requirements, helping teams stop risk before it moves downstream. All quarantine actions are policy-driven, fully auditable, and governed by RBAC, ensuring that only authorized users or systems can quarantine or release artifacts.

Integrating Security into Existing Scanning Workflows

Rather than forcing teams to replace the tools they already use, Harness Artifact Registry is built to fit into real-world security workflows by unifying scanning and governance at the registry layer. Today, Artifact Registry includes built-in scanning powered by Aqua Trivy for vulnerabilities, license issues, and misconfigurations, and integrates with over 40 security scanners, including tools like Wiz, for container, SCA, and compliance checks. Teams can orchestrate these scans directly in their CI pipelines, with scan results feeding into policy evaluation to automatically determine whether an artifact is released or quarantined.

Artifact Registry also exposes APIs that allow external security and ASPM platforms to trigger quarantine or release actions based on centralized policy decisions. Together, these capabilities enable organizations to enforce consistent, policy-driven controls early, stop risky artifacts before they move downstream, and connect artifact governance to broader enterprise security workflows all without slowing down developers.

How Artifact Registry Is Transforming Software Delivery

As organizations scaled, legacy registries have become bottlenecks disconnected from CI/CD, security, and governance workflows. Harness takes a different approach. Because Artifact Registry is natively integrated into the Harness platform, teams benefit from:

Native CI/CD integration with no extra tooling
Fast and seamless adoption for existing Harness customers
Shared visibility across Platform, DevOps, and AppSec teams
Security enforced early through built-in governance and Dependency Firewall

This tight integration has accelerated adoption by removing friction from day-to-day workflows. Teams are standardizing how artifacts are secured, distributed, and governed across the software delivery lifecycle, while keeping developer workflows fast and familiar.

What’s Next for Artifact Registry?

Harness Artifact Registry was built to modernize artifact management for the enterprise, combining high-performance distribution with built-in security, governance, and visibility. We’ve continued to invest in a platform designed to scale with modern delivery pipelines and we’re just getting started.

Looking ahead, we’re expanding Artifact Registry in three key areas:

Package Ecosystem Expansion

Support is coming for Alpine, Debian, Swift, RubyGems, Conan, and Terraform packages, enabling teams to standardize more of their software supply chain on a single platform.

Governance, Security, and Operational Control

We’re investing in artifact lifecycle management, immutability, audit logging, storage quota controls, and deeper integration with Harness Security Solutions.

AI, Visibility, and Integrations

Upcoming capabilities include semantic artifact discovery, custom dashboards, AI-powered chat, OSS gatekeeper agents, and deeper integration with Harness Internal Developer Portal.

Modern software delivery demands clear control over how software is built, secured, and distributed. As supply chain threats increase and delivery velocity accelerates, organizations need earlier visibility and enforcement without introducing new friction or operational complexity.

We invite you to sign up for a demo and see firsthand how Harness Artifact Registry delivers high-performance artifact distribution with built-in security and governance at scale.

Technical

Engineering Blog

API Failure: 7 Causes and How to Fix Them

An API failure is any response that doesn’t conform to the system’s expected behavior. Learn seven API failures and how to fix them.

Harness Team

March 13, 2026

Time to read

What Is an API Failure?

An API failure is any response that doesn’t conform to the system’s expected behavior being invoked by the client. One example is when a client makes a request to an API that is supposed to return a list of users but returns an empty list (i.e., {}). A successful response must have a status code in the 200 series. An unsuccessful response must have either an HTTP error code or a 0 return value.

What Are the Common API Error Codes?

An API will raise an exception if it can’t process a client request correctly. The following are the common error codes and their meanings:

400 Bad Request: This error occurs when the client request is malformed or cannot be processed by your API.
401 Unauthorized: This error occurs when an API key is missing or incorrectly entered.
403 Forbidden: This error occurs when a user tries to access a resource they don’t have permission to see.
404 Not Found: This error, also known as a File Not Found error, rarely has anything to do with the API itself but instead with the underlying system (for example, if trying to access a file that doesn’t exist on the server). This is usually related to something else and not directly related to your API code.
500 Internal Server: This error occurs when your server can’t respond to a request from a user or can’t find some data (for example, you’re trying to access any post, but none of the posts exist for the given ID).

What Causes API Failure?

An API failure can happen because of issues with the endpoints like network connectivity, latency, and load balancing issues. The examples below may give you a good understanding of what causes an API failure.

1. Incorrect API Permissions

Some APIs are better left locked down to those who need access and are only available to those using an approved key. However, when you don’t set up the correct permissions for users, you can impede the application’s basic functionality. If you’re using an external API, like Facebook, Twitter, or even Google Analytics, make sure you’re adding the permissions for your users to access the data they need. Also, keep on top of any newly added features that can increase security risks.

How to Fix Incorrect API Permissions

If you’re leveraging external APIs requiring extra configuration, get the correct API key so the app has the proper permissions. Also, provide your clients with API keys relevant to their authorization levels. Thus, your users will have the correct permissions and will seamlessly access your application.

2. Unsecured Endpoints and Data Access Tokens

We’ve all seen it happen a million times: someone discovers an API that’s exposed to everyone after gaining user consent. Until now, this was usually reasonably benign, but when credentials are leaked, things can get ugly fast, and companies lose brand trust. The biggest problem here is keeping admins from having unsecured access to sensitive data.

How to Fix Unsecured Endpoints and Data Access Tokens

Using a secure key management system that includes the “View Keys” permission for the account will help mitigate this risk. For example, you could use AWS Key Management Service (AWS KMS) to help you manage and create your encryption keys. If you can’t protect your keys, then at the very least, include a strong master password that all users can access, and only give out these keys when needed.

3. Invalid Session Management

Untrusted tokens and session variables can cause problems for how a website functions, causing timing issues with page loads and login calls or even creating a denial of service, which can harm the end-user experience and your brand.

How to Fix Invalid Session Management

The best way to secure sensitive data is by using token authentication, which will encode user data into the token itself based on time/date stamps. You can then enforce this to ensure that whenever you reissue tokens, they expire after a set amount of time or use them for API requests only. As for session variables, these are usually created based on your authentication keys and should be handled the same way as your privileged keys—with some encryption. And keep the source of your keys out of the hands of anyone who can access them.

4. Expiring APIs

If you’re using an API to power a website, you must upload new data in real time or save it to a cache for later use. When you set an expiry time for an API and fail to update, you make it unavailable. When a user or application tries to access it after the expiry, they get a 404 or 500 error.

How to Fix Expiring APIs

You should use a middle ground option—a proxy API. This will allow you to cache your data before you make it available and only allow access to the correct bits of the APIs as needed. You should also schedule tasks that run daily to import updated data and bring it into your system.

5. Bad URLs

This one isn’t necessarily a mistake, but it happens from time to time when developers aren’t careful about how they name things or if they’re using an improper URL structure for their API endpoints. When the URL structure is too complex or has invalid characters, you will get errors and failures. Look at some examples of bad URL structure: “http://example.com/api/v1?mode=get” The above structure is bad because the "?" character filters a single parameter, not the type of request. The default request type is GET; thus, a better URL would look like this: “http://example.com/api/v1”

How to Fix Bad URLs

Remove any unsafe characters in your URL, like angle brackets (<>). You use angle brackets as delimiters in your URL. Also, design the API to make it more friendly for users. For example, this URL "https://example.com/users/name" tells users they’re querying the names of users, unlike this URL "https://example.com/usr/nm" It’s also good practice to use a space after the “?” in your API URL because otherwise, people can mistakenly think that the space is part of a query string.

6. Overly Complex API Endpoints

This happens when trying to build multiple ways of accessing multiple applications. You do this by relying on generic endpoints instead of target audiences and specific applications. Creating a lot of different paths for the same data results in non-intuitive routes.

How to Fix Overly Complex API Endpoints

There are several ways to go about this, but for most, you want to use a network proxy system that can handle the different data access methods and bring it all into one spot. This will help minimize potential issues with your APIs routes and help with user confusion and brand damage.

7. Exposed APIs on IPs

This can happen when organizations are not properly securing their public IP addresses, or there is no solid monitoring process. This exposes your assets by providing easy access to anyone. Exposed IPs make your application vulnerable to DDoS attacks and other forms of abuse or phishing.

How to Fix Exposed APIs on IPs

Make sure you properly manage your IP addresses and have a solid monitoring system. You must block all IPv6 traffic and enforce strict firewall rules on your network. You should only allow service access through secure transport methods like TLS.

Conclusion

API errors are a plague on the internet. Sometimes they come as very poor performance that can produce long response times and bring down APIs, or they can be network-related and cause unavailable services. They’re often caused by problems such as inconsistent resource access errors, neglect in proper authentication checks, faulty authentication data validation on endpoints, failure to read return codes from an endpoint, etc. Once organizations recognize what causes API failures and how to mitigate them, they seek web application and API protection (WAAP) platforms to address the security gaps. Harness WAAP by Traceable helps you analyze and protect your application from risk and thus prevent failures.

About Traceable

Harness WAAP is the industry’s leading API security platform that identifies APIs, evaluates API risk posture, stops API attacks, and provides deep analytics for threat hunting and forensic research. With visual depictions of API paths at the core of its technology, its platform applies the power of distributed tracing and machine learning models for API security across the entire software development lifecycle. Book a demo today.

Technical

Harness Artifact Registry: Your Unified OCI-Compliant Gateway for Secure Artifact Management

Harness Artifact Registry secures Docker images and dependencies with OCI compliance, vulnerability scanning, SBOM generation, and seamless CI/CD integration.

Shibam Dhar

March 5, 2026

Time to read

If you've worked with builds and deployments, then you already know how central Docker images, dependencies, and containers are to modern software delivery. The introduction of Docker revolutionised how we package and run software, while the Open Container Initiative (OCI) brought much-needed standardisation to container formats and distribution. Docker made containers mainstream; OCI made them universal.

Even though Docker Hub and private registries have served us well, they often introduce challenges at scale:

Limited governance and control — OCI defines standards, but managing how standardised images are used, updated, and secured across environments is often left to manual processes.
Security at the edge instead of by design — vulnerability scans and policy checks typically happen after the fact, leaving pipelines exposed to build failures or compromised dependencies.
Exposure to supply chain risks — even perfectly built artifacts can fall victim to typosquatting or malicious dependency injection, quietly introducing malware into trusted environments.

And even after every dependency and sanity check passes, one question remains:

How effectively can you integrate and deploy artifacts through your CI/CD supply chain, without risking credential leaks or losing end-to-end visibility?

The Problems Are Clear — So Is the Solution

This is exactly where Harness Artifact Registry comes in.

Harness Artifact Registry is a cloud-native, secure artifact storage and management platform built for the future. Unlike traditional Docker registries or basic container registries, it's designed not just to store your Docker images and artifacts but also to actively secure and govern them. It's fully OCI-compliant, supporting Docker containers and other container formats natively, whilst integrating directly with CI/CD pipelines, policy engines, and vulnerability scanners.

Let me walk you through the complete journey of how an artifact moves through Harness Artifact Registry, from the moment you build it to when it's deployed in production.

The OCI-Compliant Artifact Journey

‍

Docker Registry Client Setup

It all begins with the very first step after you build your Docker image on your system: storing it in a secure artifact storage layer through your container registry. Harness Artifact Registry supports more than 16 registry types and is fully OCI-compliant. You can simply use Docker to push the artifacts into the registry or even use the Harness CLI for it.

‍

It is as simple as pushing to Docker Hub. Once you've authenticated with your Harness Artifact Registry, you can use standard Docker commands to push Docker images:

# Step 1: Tag the existing image (using its digest) with a new tag

docker tag <REGISTRY_URL>/<REPOSITORY>/<IMAGE_NAME>@<DIGEST> <REGISTRY_URL>/<REPOSITORY>/<IMAGE_NAME>:<NEW_TAG>

# Step 2: Push the newly tagged image to the registry

docker push <REGISTRY_URL>/<REPOSITORY>/<IMAGE_NAME>:<NEW_TAG>

‍

Because Harness Artifact Registry is fully OCI-compliant, it works seamlessly with any OCI-compatible client. This means you don't need to learn new tools or change your existing Docker workflows. Whether you're migrating from Google Artifact Registry, Azure Container Registry, AWS ECR, or Docker Hub, the experience remains consistent.

Pulling from External Resources

We understand that a build requires many dependencies and versioning, with some even pulling from open-source repositories. These sources can vary significantly for enterprises. That's why we've made it easy to integrate custom registries so you can cache artifacts via a proxy.

Harness Artifact Registry allows you to configure upstream registries as remote repositories. This means you can:

Cache dependencies locally to reduce external network calls and improve build times
Control access to external Docker registries and artifact repositories through a single point of entry
Scan external artifacts before they enter your environment

Apart from Docker Hub, Google Artifact Registry, and AWS ECR, you can set up custom registries with just a Remote Registry URL and basic authentication using a username and password. This proxy capability ensures that even when your teams pull Docker images from public registries, everything flows through Harness Artifact Registry first, giving you complete visibility, governance, and unified artifact storage control.

Security by Design

This is where Harness Artifact Registry truly shines. Rather than treating security as an afterthought, it's baked into every layer of the artifact lifecycle.

Built-in Container Scanners

Container vulnerability scanners detect security issues in your Docker images and container images before they can cause problems. Harness Artifact Registry integrates with industry-leading scanners like Aqua Trivy and Snyk, allowing you to automatically scan every artifact that enters your registry.

Here's what makes this powerful: when a Docker image is pushed, Harness automatically triggers a security pipeline that scans the artifact and generates a complete Software Bill of Materials (SBOM) along with detailed vulnerability reports. You get immediate visibility into:

Known CVEs (Common Vulnerabilities and Exposures) with severity ratings
All packages and libraries included in the Docker image
Outdated dependencies and their versions
Licence compliance issues
Configuration vulnerabilities

The SBOM and vulnerability details are displayed directly in the Harness interface, giving you complete transparency into what's inside your containers and their security posture. This level of container security goes beyond what traditional Docker registries offer.

Dependency Firewall

When you're pulling dependencies from external sources through the upstream proxy, the Dependency Firewall actively blocks risky or unapproved packages before they even enter your registry. You can configure it to either block suspicious dependencies outright or set it to warn mode for your team to review. This means malicious dependencies are stopped at the gate, not discovered later in your pipeline.

Policy Sets

Beyond vulnerability scanning, you can assign policy sets to be evaluated against each artifact. These policies act as automated gatekeepers, enforcing your organisation's security and compliance requirements.

For example, you might create policies that:

Block Docker images with critical vulnerabilities from being deployed
Require all container images to be signed
Enforce naming conventions for artifacts
Mandate specific base images for Docker containers

Policies are evaluated automatically, and non-compliant artifacts can be quarantined or blocked entirely.

Quarantine

When an artifact fails a security scan or violates a policy, it can be automatically quarantined. This prevents it from being used in deployments whilst still allowing your team to investigate and remediate the issues. This proactive approach significantly reduces your attack surface and ensures only verified artifacts make it to production.

Integrating with Harness CI/CD Pipelines

Your artifact is now ready, fully scanned for vulnerabilities, and stored securely in your container registry. This is where everything comes together for developers and platform engineers alike. The seamless integration between Harness Artifact Registry and Harness CI/CD pipelines means you can build Docker images, store artifacts, and deploy without context switching or managing complex credentials across multiple registry systems.

‍

Building and Publishing with Harness CI

Harness CI is all about getting your code built, tested, and packaged efficiently. Harness Artifact Registry fits naturally into this workflow by providing native steps that eliminate the complexity of managing Docker registry credentials and connections.

Build and Push to Docker: This native CI step allows you to build your Docker images and push them directly to Harness Artifact Registry without any external connectors. The platform handles Docker registry authentication automatically, so you can focus on your build logic rather than credential management.

Upload artifacts: Beyond Docker images, you can publish Maven artifacts, npm packages, Helm charts, or generic files directly to Harness Artifact Registry. This unified artifact management approach means all your build outputs live in one place, with consistent vulnerability scanning and policy enforcement across every artifact type.

The essence here is simplicity: your CI pipeline produces artifacts and Docker containers, and they're automatically stored, scanned, and made available for deployment, all within the same platform.

Deploying with Harness CD

Every deployment needs an artifact. Whether you're deploying Docker containers to Kubernetes, AWS ECS, Google Cloud Run, or traditional VMs, your deployment pipeline needs to know which version of your application to deploy and where to get it from.

This is where Harness Artifact Registry becomes invaluable. Because it's natively integrated with Harness CD, your deployment pipelines can pull Docker images and artifacts directly without managing external Docker registry credentials or complex authentication flows.

Harness CD supports numerous deployment types (often called CD swimlanes), and Harness Artifact Registry works seamlessly with all of them. When you configure a CD service, you simply select Harness Artifact Registry as your artifact source, specify which container registry and artifact to use, and define your version selection criteria.

From there, the deployment pipeline handles everything: authenticating with the registry, pulling the correct Docker image version, verifying it's passed vulnerability scans and security checks, and deploying it to your target environment. You can deploy to production with strict version pinning for stability, or to non-production environments with dynamic version selection for testing. The choice is yours, and it's all configured through the same intuitive interface.

The real power lies in the traceability. Every deployment is logged with complete details: which artifact version was deployed, when, by whom, and to which environment. If you need to roll back, the previous Docker image versions are right there, ready to be redeployed.

Why This Matters

From the moment you build a Docker image to when it's running in production, Harness Artifact Registry provides a complete, secure, and governed artifact lifecycle. You get container security that prevents issues before they occur, complete visibility through SBOM generation and audit logs, and native CI/CD integration that eliminates the complexity of managing multiple Docker registries and credentials.

This isn't just about storing Docker images. It's about building confidence in your software supply chain with a secure, OCI-compliant container registry.

In a world where supply chain attacks are increasingly common and compliance requirements continue to grow, having a robust artifact management and container registry strategy is essential. Harness Artifact Registry delivers that strategy through a platform that's both powerful and intuitive.

Whether you're a developer pushing your first Docker image, a platform engineer managing deployment pipelines, or a security professional ensuring compliance, Harness Artifact Registry provides the tools you need to move fast without compromising on security.

Ready to experience a fully OCI-compliant Docker registry with built-in vulnerability scanning, dependency firewall, and seamless CI/CD integration? Explore Harness Artifact Registry and see how it transforms your software delivery pipeline with secure artifact management.

‍

Technical

How to Build AI-Native Security Resilience (And Finally Get Developers And Security On The Same Team)

Developers and security professionals have struggled to get on the same page and AI is only making that divide larger. Learn how organizations can unlock the value of their AI investments.

Adam Arellano

March 4, 2026

Time to read

Developers and security professionals have struggled to get on the same page for what seems like forever and AI is only making that divide larger, according to results from our State of AI-Native Application Security 2025 research report.

AI applications are spreading through organizations at a fast rate, in many cases becoming the new “shadow IT” - 62% of our survey takers said they can’t identify where the LLMs are in their organizations, with 75% saying they’re potentially creating much greater risks than ever before. All told, 61% of those surveyed said two-third of their organizations' newly built applications are being designed with AI components.

But are those apps secure? Likely not: 62% of respondents believe AI apps are more vulnerable to cybercriminals than traditional IT applications and over two-thirds of survey takers report already experiencing an attack on an AI application.

And, unfortunately, dev and sec teams aren’t facing this problem together, at least according to our findings. Survey takers said:

Developers lack time and training: 62% say devs are too busy to implement comprehensive AI-native security, and the same percentage say they lack the necessary expertise.
Speed and security are mismatched: 75% believe AI applications evolve faster than security can keep up.
Collaboration breakdowns are widening the gap: Only 34% of developers notify security before starting AI projects, and just 53% before going live.
Perception remains a barrier: 74% of security leaders say developers view security as a blocker to AI innovation.

But, organizations can unlock the value of their AI investments *and* make them more secure at the same time, while, (bonus!), bringing security pros and developers together - if they commit to building AI-native security resilience. This is a mindset and culture shift, perhaps of monumental proportions, but we promise the payoff is worth it. Here’s how to get started:

Lay the groundwork with shared governance

‍Manual reviews are tedious, prone to human error, and can double or triple the wait times for approval. To break that cycle, opt for Policy as Code rather than manual reviews, building something that engineering and security agree upon beforehand. That could look like security defining policies that devs embed into CI/CD pipelines and violations that trigger automated feedback rather than blocking progress.

This is a great place to start - or stress - a true “shift left” mentality.

Make AI components discoverable

AI components can’t be secure if they’re not seen. Teams need to monitor and log all AI components, of course, but the organization needs to make it as easy as possible to use safe and sanctioned AI tools. Shadow AI only gets worse when the “official tools” are difficult to use.

Detect anomalies by tracking AI implementations in real-time

Normal rules won’t apply here, so instead teams need to look at model behavior (sudden spikes or abnormal token usage), security signals (prompt injection patterns or hidden tool calls), and operational (cost anomalies or context window size spikes). Also consider building real-time guardrails with policy automation that can throttle model calls or downgrade agent permissions.

Test dynamically against AI-specific threats

Up your testing game with specific threat catalogs including OWASP Top 10 for LLM Apps and MITRE ATLAS and don’t forget the TEVV concepts. A dedicated security test harness can be particularly helpful here, as can adversarial “prompt fuzzing.”

Don’t forget to protect what’s already in production

‍In the immortal words of Fox Mulder “trust no one,” or in this case, don’t trust *any* of the AI inputs and outputs. Enforce data classification and context boundaries, secure the model interaction layer, and make sure to monitor the behavior and not just the infrastructure.

FAQs on AI-Native Security Resilience

What does "AI-native security resilience" actually mean in practice?

AI-native security resilience means security isn't a gate at the end of the pipeline — it's woven into every stage of delivery. Harness uses contextual insights and agentic workflows to detect and mitigate risks from build to post-deployment, covering everything from application and API discovery to AI-powered threat prevention.

How does Harness help security and developer teams work from the same playbook?

The merger of Harness and Traceable enables software teams to seamlessly develop, deploy, and secure applications, ensuring security is embedded at every stage of the software lifecycle. By unifying DevOps and AppSec in a single platform, both teams operate with the same pipeline context — eliminating the handoff friction that traditionally breaks collaboration.

How does Harness reduce the burden on developers when it comes to fixing vulnerabilities?

Harness AI streamlines the process of fixing vulnerabilities, enabling developers and security personnel to manage security backlogs, address critical issues promptly, and generate code suggestions and pull requests to remediate issues directly from the security testing orchestration (STO) module.

With shadow AI becoming a major enterprise risk, how does Harness help organizations stay in control?

Harness addresses AI visibility through the Software Delivery Knowledge Graph — a contextual layer that maps a company's security policies, compliance requirements, infrastructure, and development practices — so AI agents can enforce guardrails automatically, rather than relying on developers to remember them.

Engineering Blog

From Chef to Chief Architect: Navigating the Intersection of AI and Data Security

IBM's Devan Shah shares how to scale DevSecOps for 450+ devs, manage AI coding agents, and secure the "crown jewels" in the age of DSPM.

Dewan Ahmed

February 23, 2026

Time to read

Prefer to watch the video instead?

Managing a global army of 450+ developers, Devan has seen the "DevOps to DevSecOps to AI" evolution firsthand. Here are the core AI data security insights from his conversation on ShipTalk.

1. The Bedrock: Scaling to 450+ Developers

IBM’s internal "OnePipeline" isn't just a convenience; it’s a necessity. Built on Tekton (CI) and Argo CD, the platform has become the standard for both SaaS and on-prem deliveries.

The "Speed vs. Value" Trade-off: During the migration from Travis CI to Tekton, build times initially jumped from 10 minutes to 30. However, the team realized this wasn't inefficiency—it was automated maturity. The extra time accounted for mandatory static, dynamic, and open source scanning.
The Result: Audits for SOX, NIST, and ISO compliance changed from "scrambling for logs" to "pulling automated reports."

This transition highlights a growing industry trend: as code generation accelerates, the bottleneck shifts to delivery and security. This phenomenon, often called the AI Velocity Paradox, suggests that without downstream automation, upstream speed gains are often neutralized by manual security gates.

2. AI in the SDLC: "Bob" and the Rules of Engagement

IBM uses an internal AI coding agent called "Bob." But how do you ensure AI-generated code doesn't become technical debt?

"It’s not just about the code working; it’s about it being maintainable. If you don't provide context, the AI will build its own functions for JWT validation or encryption instead of using your existing, secure SDKs." — Devan Shah

To combat this, the team implements:

Contextual Rules Files: Hard-coded guidelines that tell the AI which helper packages and security protocols to use.
AI Code Reviews: Using LLMs to review PRs with specific guardrails, ensuring that "vibe coding" (quick POCs) is elevated to production-ready standards.

Quantifying the success of these initiatives is the next frontier. For organizations looking to move beyond "vibes" and toward hard data, the ebook Measuring the Impact of AI Development Tools offers a framework for tracking how these assistants actually affect cycle time and code quality.

3. AI Data Security: "Crown Jewels In, Crown Jewels Out"

We’ve all heard of "Garbage In, Garbage Out," but in the AI era, Devan warns of "Crown Jewels In, Crown Jewels Out." If you feed sensitive data or hard-coded secrets into an LLM training set, that model becomes a potential leak for attackers using sophisticated prompt injection.

The Rise of DSPM

Data Security Posture Management (DSPM) has emerged as a critical layer. It solves three major problems:

Shadow Data Discovery: Finding where PII lives in unstructured formats (PDFs, logs, S3 buckets).
Posture Verification: Identifying unencrypted buckets or public-facing databases.
Data Flow Mapping: Detecting GDPR violations.

For a deeper technical look at how infrastructure must be architected to protect customer data in this environment, the Harness Data Security Whitepaper provides an excellent breakdown of security and privacy-by-design principles.

4. Architecting for the "Agentic" Future

We are moving beyond simple chatbots to Agentic Workflows—where AI agents talk to other agents and API endpoints.

The Risk: An agent with "Full Admin" permissions could accidentally delete an entire cloud account if it misinterprets a prompt.
The Solution: Architecting for Just-In-Time (JIT) token provisioning and Least Privilege access. Agents should only have the permissions they need for the exact second they are performing a task.

5. The "No Jail" Architectural Principle

When asked how to balance speed with security, Devan's philosophy is simple: Identify the "Bare Minimum 15." You don't need a list of 300 compliance checks to start, but you do need 10 to 15 non-negotiables:

Automated CI/CD security gates: Ensuring every piece of code—AI or human—passes the same rigorous checks.
An inventory of every AI model used: To prevent "Shadow AI."
Pre-approved weight and training data reviews: For off-the-shelf models.

Final Thoughts

Whether you are a startup or a global giant like IBM, the goal of software delivery remains the same: Ship fast, but stay out of legal trouble. By integrating AI data security guardrails and robust data protection directly into the pipeline, security stops being a "speed bump" and starts being a foundational feature.

Want to dive deeper? Connect with Devan Shah on LinkedIn to follow his latest work, and subscribe to the ShipTalk podcast for more insights on using AI for everything after code.

Engineering Blog

Architecting Trust: The Blueprint for a "Golden Standard" Software Supply Chain

Move beyond bespoke CI/CD scripts. Learn how to architect a "Golden Standard" pipeline that enforces governance, accelerates security testing, and guarantees artifact integrity using a Zero Trust approach.

Aditya Kashyap

February 5, 2026

Time to read

We’ve all seen it happen. A DevOps initiative starts with high energy, but two years later, you’re left with a sprawl of "fragile agile" pipelines. Every team has built their own bespoke scripts, security checks are inconsistent (or non-existent), and maintaining the system feels like playing whack-a-mole.

This is where the industry is shifting from simple DevOps execution to Platform Engineering.

The goal of a modern platform team isn't to be a help desk that writes YAML files for developers. The goal is to architect a "Golden Path"—a standardized, pre-vetted route to production that is actually easier to use than the alternative. It reduces the cognitive load for developers while ensuring that organizational governance isn't just a policy document, but a reality baked into every commit.

In this post, I want to walk through the architecture of a Golden Standard Pipeline. We’re going to look beyond simple task automation and explore how to weave Governance, Security, and Supply Chain integrity into a unified workflow that stands the test of time.

The Architectural Blueprint

A Golden Standard Pipeline isn't defined by the tools you use—Harness, Gitlab, GitHub Actions—but by its layers of validation. It’s not enough to simply "build and deploy" anymore. We need to architect a system that establishes trust at every single stage.

I like to break this architecture down into four distinct domains:

Governance Domain: checking if we should run this pipeline before we even start.
Integration Domain (The Inner Loop): getting fast feedback to developers.
Trust Domain (Supply Chain): creating proof that the software is safe.
Delivery Domain (The Outer Loop): getting it to production reliably.

Visualizing the Flow

Layer 1: Governance as the First Gate

The Principle: Don't process what you can't approve.

In traditional pipelines, we often see compliance checks shoehorned in right before production deployment. This is painful. There is nothing worse than waiting 20 minutes for a build and test cycle, only to be told you can't deploy because you used a non-compliant base image.

In a Golden Standard architecture, we shift governance to Step Zero.

By implementing Policy as Code (using frameworks like OPA) at the very start of execution, we solve a few problems:

Drift Prevention: Pipelines simply won't run if they’ve been hacked to bypass standard steps.
Resource Efficiency: We don't waste expensive compute building artifacts that are doomed to fail compliance.
Security Baseline: Unauthorized workflows are stopped dead before they can access secrets or internal networks.

Layer 2: Parallelized Security Orchestration

The Principle: Security must speed the developer up, not slow them down.

The "Inner Loop" is sacred ground. This is where developers live. If your security scanning adds friction or takes too long, developers will find a way to bypass it. To solve this, we rely on Parallel Orchestration.

Instead of running checks linearly (Lint → then SAST → then Secrets), we group "Code Smells," "Linting," and "Security Scanners" to run simultaneously.

This gives us a huge architectural advantage:

Reduced Latency: We squash the wall-clock time by running I/O heavy checks in parallel.
Cost Optimization: We only trigger expensive Unit Test runners after the cheap, fast security checks pass. There is zero value in running a heavy test suite on a codebase that contains a hardcoded API key.

Layer 3: The Trust Layer (Supply Chain Security)

The Principle: Prove the origin and ingredients of your software.

This is the biggest evolution we've seen in CI/CD recently. We need to stop treating the build artifact (Docker image/Binary) as a black box. Instead, we generate three critical pieces of metadata that travel with the artifact:

SBOM (Software Bill of Materials): Think of this as the ingredients list on a food packet. It’s a machine-readable inventory of every library inside your container. When the next Log4j happens, you don't need to scan the world; you just query your inventory.
SLSA Provenance: This is an unforgeable ID card for your build. It proves where the build happened, when it happened, and what inputs were used. This is your defense against tampering attacks (like SolarWinds).
Cryptographic Signing: Finally, we sign the artifact using a private key (via Cosign). This acts like a digital wax seal; if the image is modified by even one bit after the build, the seal breaks, and your cluster will refuse to run it.

Layer 4: Immutable Delivery

The Principle: Build once, deploy everywhere.

A common anti-pattern I see is rebuilding artifacts for different environments—building a "QA image" and then rebuilding a "Prod image" later. This introduces risk.

In the Golden Standard, the artifact generated and signed in Layer 3 is the exact same immutable object deployed to QA and Production. We use a Rolling Deployment strategy with an Approval Gate between environments. The production stage explicitly references the digest of the artifact verified in QA, ensuring zero drift.

The Capability Map

To successfully build this, your platform needs to provide specific capabilities mapped to these layers.

Future-Proofing Your Platform

Tools change. Jenkins, Harness, GitHub Actions—they all evolve. But the Architecture remains constant. If you adhere to these principles, you future-proof your organization:

Decouple Policy from Pipeline: Store your policies separately from your pipeline YAML. This lets you update security rules globally without needing a massive migration project to edit hundreds of pipelines.
Standardize Interfaces: Use standard formats for your metadata (SPDX for SBOMs, In-toto for attestations). This prevents vendor lock-in and ensures your data is portable.
Invest in "Shift Left" Culture: The best architecture in the world fails if developers see it as a hurdle. Position the Golden Pipeline as a product that solves developer pain points (like setting up environments or managing credentials) while silently enforcing security in the background.

Conclusion

Adopting a Golden Standard architecture transforms the CI/CD pipeline from a simple task runner into a governance engine. By abstracting security and compliance into these reusable layers, Platform Engineering teams can guarantee that every microservice—regardless of the language or framework—adheres to the organization's highest standards of trust.

Company News

Qwiet AI Is Now Harness SAST and SCA

Harness SAST and SCA (formerly Qwiet AI) now available as pre-defined pipeline steps on the Harness platform. CPG, reachability, and AI guidance improve accuracy, help prioritize, and simplify remediation. Pipeline-native AST improves governance and scales security coverage across every pipeline.

Renny Shen

February 4, 2026

Time to read

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

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

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

Introducing Harness SAST and SCA

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

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

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

Why Pipeline-Native AST Matters

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

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

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

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

Pipeline-Native SAST and SCA with Harness

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

Pre-Defined Security Steps

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

Virtual Pipeline Builder

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

Understanding Pipeline Posture with STO

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

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

Viewing SAST and SCA Findings

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

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

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

Try It for Free Today

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

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

Request a demo

Engineering Blog

Overcoming the AI Velocity Paradox in Security

Discover how the organizations can bridge the critical gap between rapid AI code generation and lagging security processes to prevent vulnerabilities and compliance risks.

Vikas Gautam

January 23, 2026

Time to read

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

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

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

‍

Defining the AI Velocity Paradox in Security

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

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

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

‍

The Dual Risk: Vulnerabilities vs. Compliance

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

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

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

‍

A New Attack Surface: Non-Deterministic AI Agents

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

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

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

‍

Top challenges for AI application security

‍

Prioritizing AI Security Mitigation (OWASP LLM Top 10)

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

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

‍

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

‍

A Deep Dive into Prompt Injection

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

The Attack Path is usually:

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

‍

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

Here’s a playbook to tackle Prompt Injection attacks

‍

Harness’s Vision for AI Security

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

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

‍

Read more about Harness AI security in our blog post.

Looking Ahead: The Evolving Attack Landscape

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

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

‍

To stay ahead, a phased maturity roadmap is recommended:

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

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

‍

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

‍

Technical

Protect Against Critical Unauthenticated RCE in React & Next.js (CVE-2025-55182) with Traceable WAF

Critical, unauthenticated RCE (CVE-2025-55182) found in React and Next.js applications. Traceable WAF by Harness provides immediate, proactive protection.

Roshan Piyush

December 4, 2025

Time to read

Protect Against Critical Unauthenticated RCE in React & Next.js (CVE-2025-55182) with Traceable WAF

The cybersecurity landscape was rocked on December 3rd, 2025, by the disclosure of another critical remote code execution (RCE) vulnerability affecting React Server Components and Next.js applications. With CVSS scores of 10.0, the maximum severity rating, CVE-2025-55182 (React) and the related CVE-2025-66478 (Next.js, later marked as a duplicate) represent an immediate, severe threat to modern web applications. At Harness, we have comprehensive protections in Traceable WAF that were already shielding your applications from these vulnerabilities, even before the CVEs were created.

Understanding the Threat

These vulnerabilities, discovered by security researcher Lachlan Davidson, strike at the heart of React's new server-side rendering architecture. The flaws exist in the React Server Components (RSC) "Flight" protocol, which handles data serialization and deserialization between the server and client. What makes these vulnerabilities particularly dangerous is their combination of the following critical characteristics:

Unauthenticated exploitation: No credentials or authentication required
Remote code execution: Full server compromise possible
Default configurations are vulnerable: Standard deployments are immediately at risk
Near-100% exploitation reliability: Attacks have shown consistent success rates
Broad ecosystem impact: Affects React 19, Next.js, and numerous dependent frameworks

The vulnerability stems from insecure deserialization in the RSC protocol's handling of incoming payloads. When a server receives a specially crafted, malformed payload, it fails to validate the structure correctly, allowing attacker-controlled data to influence server-side execution logic and execute arbitrary JavaScript code.

Affected Versions

React Server Components:

Vulnerable Versions: 19.0, 19.1.0, 19.1.1, and 19.2.0
Affected packages: react-server-dom-parcel, react-server-dom-webpack, react-server-dom-turbopack
Fixed versions: 19.0.1, 19.1.2, 19.2.1

Next.js (App Router):

Vulnerable Versions: 15.x, 16.x, and 14.3.0-canary.77+
Fixed versions: 15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7, 16.0.7

Other affected frameworks:

React Router
Waku
RedwoodJS (rwsdk)
Parcel (@parcel/rsc)
Vite RSC Plugin (@vitejs/plugin-rsc)

Immediate Protection with Traceable WAF's Multi-Layered Defense

Protection by Default - Already Active Before Disclosure

The most important news: If you had Traceable WAF enabled, you were already protected against well-known exploits at this moment. Our advanced payload analysis engine was already defending against this vulnerability class through multiple existing rules that included:

Server Side Template Injection (SSTI) Attempt: Blocks injection patterns, including those used in RSC deserialization attacks
Node.js Injection Attack: Prevents code injection attempts targeting the Node.js runtime

This proactive protection demonstrates the value of comprehensive security rules that defend against entire vulnerability classes rather than just specific CVEs.

Dedicated CVE-Specific Analysis

Following the disclosure, our security research team identified multiple possible exploitation techniques and developed additional specific detection signatures. The following signatures protect against the payload patterns characteristic of CVE-2025-55182 exploitation attempts across different components:

React & Next.js Server Functions Deserialization RCE: (CVE-2025-55182)
ReactJS Server Functions Deserialization RCE: (CVE-2025-55182)

Ensure these two rules are set with the action Block

AI-Powered Anomaly Detection

Beyond signature-based detection, Traceable's behavioral analysis identifies attempts to bypass detection or discover new attack vectors. Our anomaly detection engine monitors for:

Unexpected or unknown parameters: Identifying parameters not seen in normal traffic
Unseen parameter contents: Detecting unusual values in known parameters
Unusual request sizes: Flagging requests that deviate from typical patterns
Abnormal execution paths: Recognizing when requests trigger unexpected behavior

Testing Your Applications for Vulnerability

ASPEN Labs CVE-2025-55182 Checker

Our security researchers at ASPEN Labs by Harness have developed an open-source tool to help organizations test whether their applications are vulnerable to CVE-2025-55182. This tool provides a safe, controlled way to verify if your React and Next.js applications are vulnerable.

Tool Repository: Github(https://github.com/aspen-labs/CVE-2025-55182-checker)

Quick Testing Guide

Clone the checker tool:

git clone https://github.com/aspen-labs/CVE-2025-55182-checker.git

cd CVE-2025-55182-checker

Run the vulnerability check:‍

# Install uv
curl -LsSf https://astral.sh/uv/install.sh | sh

# Test a specific endpoint
uv run check https://your-app.com

# Test multiple endpoints from a file
uv run check --file targets.txt.example -o vulnerable.txt

‍

The Harness Advantage is Research-Driven Security

At Harness, our unique approach to security, where researchers function as both researchers and developers, enables rapid development of defences and response to vulnerabilities. Our security research team doesn't just analyze these vulnerabilities; they immediately evaluate and translate their findings into practical protections deployed across our WAF infrastructure.

This research-to-product pipeline means:

Faster protection deployment: Hours, not days, from disclosure to protection
Higher efficacy rates: Researchers who understand the vulnerability build the defense
Continuous improvement: Real-world data feeds back into research
Proactive defense: Identifying vulnerability classes before they're exploited

Continuous Protection is Necessary

The disclosure of CVE-2025-55182 serves as a stark reminder of the evolving threat landscape facing modern web applications. As frameworks become more sophisticated, so do the attack vectors targeting them. Traceable by Harness WAF represents not just a response to today's threats, but a platform built for tomorrow's challenges.

Our commitment to our customers includes:

24/7 threat monitoring: Continuous surveillance for emerging threats
Rapid rule deployment: Protection updates within hours of disclosure
Research-driven innovation: Leveraging cutting-edge security research
Community collaboration: Sharing threat intelligence for collective defense

Take Action Now

The critical nature of these vulnerabilities demands immediate action. Organizations running React Server Components or Next.js applications should:

Enable Traceable WAF protection immediately if not already active
Review protection logs for any exploitation attempts
Plan patching schedule for affected applications
Contact our security team for customized protection strategies

Be Ready for the Next Vulnerability

CVE-2025-55182 represents one of the most severe vulnerability disclosures in recent memory for the JavaScript ecosystem. With their combination of ease of exploitation, widespread impact, and critical severity, these vulnerabilities pose an immediate threat to organizations worldwide.

Traceable by Harness WAF provides comprehensive, immediate protection against these vulnerabilities through multiple layers of defense, from signature-based detection to AI-powered behavioral analysis. While patching remains essential for long-term security, our WAF ensures your applications remain protected during this critical period.

At Harness, we understand that security is not just about responding to threats; it's about staying ahead of them. Our research-driven approach, combined with our advanced WAF capabilities, ensures that your applications remain secure not only against today's disclosed vulnerabilities but also against tomorrow's emerging threats.

Stay protected. Stay ahead. Choose Traceable by Harness WAF.

For more information about Traceable WAF protection against CVE-2025-55182, or guidance, contact our team at security@harness.io

‍

Security & Compliance Blogs

Featured Blogs

The AI Visibility Problem: When Speed Outruns Security

The Question Everyone’s Asking

The AI Visibility Problem

Security Has to Move Closer to Engineering

Developers Don’t Need to Slow Down — They Need Guardrails

Seeing What Matters

GitHub Actions Supply Chain Attack: tj-actions/changed-files - Impact Assessment and Mitigation Guidance

Updates on the incident

Overview

Breaking Down the Attack

Immediate Measures to Control the Impact

How can Harness SCS help?

Integrating Harness SCS Runtime Analysis with Traceable - Coming Soon!

Conclusion

Harness enhances software supply chain security with SCS module

Announcing CI/CD Security Posture Management With Harness Supply Chain Security (SCS)

Preventing Attacks And Achieving Continuous Software Supply Chain GRC With Harness SCS

Harness SCS: A Look At CI/CD Security Posture Management

Conclusion

Latest Blogs

Authentication vs Authorization: What’s the Difference and Why It Matters

What Is Authentication?

What Is Authorization?

Authentication vs Authorization: Key Differences at a Glance

How Authentication Works in Modern Applications

How Authorization Works in Modern Applications

Common Pitfalls When You Mix Up Authentication and Authorization

Authentication vs Authorization in Cloud and Microservices

Choosing the Right Authentication Strategy

Designing a Solid Authorization Model

Get Authentication and Authorization Right Early

FAQ: Authentication vs Authorization

Why is it important to understand authentication vs authorization?

Can you have authorization without authentication?

What are some real-world examples of authentication?

What are some real-world examples of authorization?

How do OAuth 2.0 and OpenID Connect relate to authentication vs authorization?

LiteLLM Compromise: Securing AI Pipelines from PyPI Supply Chain Attacks

Python .pth Files: Silent Execution Hooks at Interpreter Startup

How Harness Supply Chain Security Helps

Detect Compromised LiteLLM Package

Block Compromised LiteLLM Packages

Track & Remediate Issues with Developers

Next Steps in the Face of Supply Chain Attacks

Introducing Radar in Harness Bot & Abuse Protection

Visualizing the DNA of Distributed Attacks

Introducing Radar in Harness Bot & Abuse Protection

Why SecOps Teams Need Threat Visualization

Radar Key Capabilities

1. The Unified Threat Canvas

2. AI-Powered Context

3. Portable Forensics

Get Started Today

Zachary Gruenberg on Machine Identity Security in the Age of AI

🎧 Listen to the Full Episode

The Explosion of Machine Identities

Building Security That Scales with Automation

The Most Common Machine Identity Blind Spot

Security in an Autonomous Infrastructure World

Final Thoughts

🎧 Listen to the Full Episode

Securing AI and Securing With AI: AI Security from Code to Runtime With Harness

What Makes Harness Different?

Introducing AI Security

Introducing Secure AI Coding

We Had the Same Problem

Ready to Secure Your AI?

From Shadow AI to Full Visibility: Operationalising AI Security at Scale

Why AI Security Posture Management Matters Now

The Framework: Discover - Understand - Assess Risk - Operationalise

01 Discover: Build the Complete AI Asset Inventory

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

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

04 Operationalise: Integrate AI Posture into Security Workflows

Maturity Model: Day 1 - Day 30 - Day 90

Enterprise Extension: ServiceNow CMDB Integration

The Bottom Line

From Artifact Storage to Supply Chain Control: Rethinking Artifact Management with Harness