Security & Compliance Blogs

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:

1. Governance Domain: checking if we should run this pipeline before we even start.
2. Integration Domain (The Inner Loop): getting fast feedback to developers.
3. Trust Domain (Supply Chain): creating proof that the software is safe.
4. 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:

1. Reduced Latency: We squash the wall-clock time by running I/O heavy checks in parallel.
2. 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:

1. 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.
2. 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).
3. 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:

1. 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.
2. 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.
3. 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.

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: 

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

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

Pipeline-Native SAST and SCA with Harness

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

Pre-Defined Security Steps

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

Virtual Pipeline Builder

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

Understanding Pipeline Posture with STO

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

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

Viewing SAST and SCA Findings

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

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

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

Try It for Free Today

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

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

Request a demo

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

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

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

‍

Defining the AI Velocity Paradox in Security

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

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

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

‍

The Dual Risk: Vulnerabilities vs. Compliance

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

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

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

‍

A New Attack Surface: Non-Deterministic AI Agents

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

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

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

‍

Top challenges for AI application security

‍

Prioritizing AI Security Mitigation (OWASP LLM Top 10)

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

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

‍

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

‍

A Deep Dive into Prompt Injection

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

The Attack Path is usually:

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

‍

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

Here’s a playbook to tackle Prompt Injection attacks

‍

Harness’s Vision for AI Security

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

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

‍

Read more about Harness AI security in our blog post.

Looking Ahead: The Evolving Attack Landscape

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

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

‍

To stay ahead, a phased maturity roadmap is recommended:

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

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

‍

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

‍

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

1. Clone the checker tool:

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

cd CVE-2025-55182-checker

2. 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:

1. Enable Traceable WAF protection immediately if not already active
2. Review protection logs for any exploitation attempts
3. Plan patching schedule for affected applications
4. 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

‍

On November 24, 2025, the open source ecosystem experienced a second significant wave of the Shai-Hulud NPM supply-chain attack, now called Shai-Hulud 2.0. Attackers compromised hundreds of NPM publisher accounts, trojanized widely used packages, including those from Zapier and ENS Domains, and introduced a worm-like payload that is triggered during the pre-install lifecycle of affected modules.

The malware installs a separate runtime (Bun), executes hidden scripts (setup_bun.js, bun_environment.js), harvests developer and cloud credentials (GitHub, AWS, GCP, Azure), creates malicious GitHub Actions runners, and spreads by republishing infected packages using stolen credentials.

Impact:

• Over 25,000 compromised GitHub repositories affecting nearly 1,000 packages, with an additional ~1,000 new compromised repos every 30 minutes.
• Thousands of stolen credentials across ecosystems.
• Worm-style propagation across CI/CD runners, developer machines, and repositories.

This attack demonstrates how rapidly a supply chain attack can propagate and reinforces the need for real-time SBOM visibility and policy enforcement. These capabilities are no longer just best practices; they’re foundational safeguards for protecting modern software supply chains.

How Harness Supply Chain Security Helps

Harness SCS provides you with clear visibility into everything flowing through your software supply chain. You can identify risky or untrusted components early, generate Open Policy Agent (OPA) policies to automatically block suspicious dependencies, and ensure only safe, verified artifacts move forward in your pipelines.

Use Harness SCS to trace the complete lineage of every artifact, so you always know where components came from, how they were built, and what they’ve touched. With a component search across all repositories and artifacts, you can instantly find and isolate compromised dependencies the moment a supply chain attack, like Shai-Hulud, is disclosed.

1. Detect Compromised NPM Packages

Harness SCS equips you with a robust open source component search capability that works across every repository and artifact built with Harness pipelines. The moment a vulnerability or malicious package is disclosed, you can instantly search to identify the component and determine whether it exists anywhere, providing you with complete visibility across your entire supply chain.

2. Block Compromised NPM Packages

Harness AI simplifies incident response processes for events like Shai-Hulud 2.0 using natural-language prompts. With a single prompt, users can use this OPA policy to block compromised NPM components across all CI/CD pipelines, prevent tampered or malicious packages from being introduced into new builds or deployments, and provide a strong preventive control throughout your SDLC. 

Note that the list of known packages compromised by Shai-Hulud 2.0 will likely evolve as the worm mutates or infects additional packages. This list of known vulnerable packages informs a deny list, commonly found in security policies. 

3. Track & Remediate Issues with Developers

Harness SCS automatically identifies vulnerable components across all production and non-production environments. Teams can assign fixes to developers, monitor progress from update to deployment, and sync everything with Jira for seamless workflow and ongoing tracking. With real-time visibility into what’s fixed, pending, or still at risk, you can ensure no vulnerability slips through the cracks and keep your supply chain hardened against Shai-Hulud and other similar malware.

Next Steps in the Face of Supply Chain Attacks

Shai-Hulud 2.0 reinforces how quickly a supply chain attack can escalate when an NPM maintainer account is compromised. The impacts of Shai-Haulud were felt across ecosystems within hours, bypassing traditional scanning and manual review processes.

Protecting against and preventing these threats requires more than detection; it requires real-time visibility, automated policy enforcement, and continuous remediation tracking. Harness SCS brings these capabilities together, helping development and security teams to quickly identify where malicious components are used, block them from entering future builds, and ensure fixes are fully rolled out.

With the proper controls in place, organizations can reduce exposure, contain risks early, and strengthen the integrity of their software supply chain against attacks like Shai-Hulud 2.0. Stay protected from future attacks using Harness SCS.

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

Request a demo

Checkout Harness Supply Chain Security

If 2024 was the year AI started quietly showing up in our workflows, 2025 was the year it kicked the door down.

AI-generated code and AI-powered workflows have become part of nearly every software team’s daily rhythm. Developers are moving faster than ever, automation is woven into every step, and new assistants seem to appear in the pipeline every week.

I’ve spent most of my career on both sides of the equation — first in security, then leading engineering teams — and I’ve seen plenty of “next big things” come and go. But this shift feels different. Developers are generating twice the code in half the time. It’s a massive leap forward — and a wake-up call for how we think about security.

The Question Everyone’s Asking

The question I hear most often is, “Has AI made coding less secure?”

Honestly, not really. The code itself isn’t necessarily worse — in fact, a lot of it’s surprisingly good. The real issue isn’t the quality of the code. It’s the sheer volume of it. More code means more surface area: more endpoints, more integrations, more places for something to go wrong.

Harness recently surveyed 500 security practitioners and decision makers responsible for securing AI-native applications from the United States, UK, Germany, and France to share findings on global security practices. In our latest report, The State of AI-Native Application Security 2025, 82% of security practitioners said AI-native applications are the new frontier for cybercriminals, and 63% believe these apps are more vulnerable than traditional ones.

It’s like a farmer suddenly planting five times more crops. The soil hasn’t changed, but now there’s five times more to water, tend, and protect from bugs. The same applies to software. Five times more code doesn’t just mean five times more innovation — it means five times more vulnerabilities to manage.

And the tools we’ve relied on for years weren’t built for this. Traditional security systems were designed for static codebases that changed every few months, not adaptive, learning models that evolve daily. They simply can’t keep pace.

And this is where visibility collapses.

The AI Visibility Problem

In our research, 63% of security practitioners said they have no visibility into where large language models are being used across their organizations. That’s the real crisis — not bad actors or broken tools, but the lack of understanding about what’s actually running and where AI is operating.

When a developer spins up a new AI assistant on their laptop or an analyst scripts a quick workflow in an unapproved tool, it’s not because they want to create risk. It’s because they want to move faster. The intent is good, but the oversight just isn’t there yet.

The problem is that our governance and visibility models haven’t caught up. Traditional security tools were built for systems we could fully map and predict. You can’t monitor a generative model the same way you monitor a server — it behaves differently, evolves differently, and requires a different kind of visibility.

Security Has to Move Closer to Engineering

Security has to live where engineering lives — inside the pipeline, not outside it.

That’s why we’re focused on everything after code: using AI to continuously test, validate, and secure applications after the code is written. Because asking humans to manually keep up with AI speed is a losing game.

If security stays at a checkpoint after development, we’ll always be behind. The future is continuous — continuous delivery, continuous validation, continuous visibility.

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

In the same report, 74% of security leaders said developers view security as a barrier to innovation. I get it — security has a reputation for saying “no.” But the future of software delivery depends on us saying “yes, and safely.”

Developers shouldn’t have to slow down. They need guardrails that let them move quickly without losing control. That means automation that quietly scans for secrets, flags risky dependencies, and tests AI-generated code in real time — all without interrupting the creative flow.

AI isn’t replacing developers; it’s amplifying them. The teams that learn to work with it effectively will outpace everyone else.

Seeing What Matters

We’re generating more innovation than ever before, but if we can’t see where AI is working or what it’s touching, we’re flying blind.

Visibility is the foundation:

• Map where AI exists across your workflows, models, and pipelines.
• Automate validation so issues are caught continuously, not just at release time.
• Embed governance early, not as an afterthought.
• Align security and development around shared goals and shared ownership.
  

AI isn’t creating chaos — it’s revealing the chaos that was already there. And that’s an opportunity. Once you can see it, you can fix it.

You can read the full State of AI-Native Application Security 2025 report here.

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

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

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

Why AI Features Matter Now

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

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

From Pipeline to Production: A Holistic Approach

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

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

What You'll Discover

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

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

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

Join us at DevSecOps Summit 2025.

Summary

On September 8, 2025, the open source community was hit by a major supply chain incident involving more than 18 popular NPM packages (as disclosed by the maintainer). Attackers gained control of a maintainer account and pushed malicious updates to widely used libraries such as chalk, debug, strip-ansi, and wrap-ansi. These poisoned releases, were found to contain code designed to steal cryptocurrency wallets. The event underscores how quickly a single maintainer compromise can ripple across the global software ecosystem and why organizations need stronger safeguards for open source dependencies.

Harness Supply Chain Security (SCS) provides the visibility and controls you need to stay ahead of these threats.

OSS Search and Visibility

Harness SCS gives you a powerful OSS search capability that works across every repository and artifact built with Harness pipelines. The moment a vulnerability or malicious package is disclosed, you can instantly search to identify whether it exists anywhere in your software supply chain. No more guessing or waiting for alerts, you know right away where you’re exposed.

AI-Assisted Policy Enforcement

With Harness AI, creating preventive policies is simple. Using natural language prompts, you can instantly generate OPA policies that block the affected NPM components from being used in pipelines. This ensures that once a package is disclosed as compromised, it can no longer enter new builds or deployments.

You can use this OPA Policy to block the affected NPM components from being used in the Build environment.

Continuous Remediation Tracking

Detecting an issue is only half the battle. Harness SCS comes with a Remediation Tracker that monitors affected components across environments - production and non-production. This makes it easy to track progress as teams update or replace compromised packages, ensuring full closure of the risk.

Conclusion

The NPM package compromise shows how quickly supply chain risks can spread. Harness SCS provides the defence needed with SBOM search to identify exposure, AI-driven OPA policies to block malicious components, and a Remediation Tracker to ensure fixes are applied. Together, these capabilities help teams rapidly detect, prevent, and remediate threats, strengthening the integrity of the software supply chain. Stay protected from future attacks using Harness SCS.

If there’s one thing we all care deeply about, it’s not fame, fortune or perfect HCL formatting; it’s reusability.

Whether you're a seasoned practitioner or new to Infrastructure as Code (IaC), Reusable modules are fast becoming the backbone of modern platform engineering. That's why modern platforms introduced Module Registries, central systems for publishing and consuming OpenTofu/Terraform modules across your organization. 

They promote the DRY principle ("Don't Repeat Yourself") by codifying best practices, reducing duplication, and helping teams ship faster by focusing on what’s unique to their workload

But as teams scale, so does the risk: a misconfigured or buggy module can break dozens of environments in seconds.

Enter testing for infrastructure modules.

Real-world example: How one bug could have taken out everything

A few years ago, a platform engineering team learned a painful lesson: one bad Terraform command can destroy everything.

This real incident describes how a single misconfigured module and an unguarded Terraform destroy wiped out an entire staging environment, dozens of services gone in minutes. Recovery took days.

Now imagine your team building a reusable VPC module. Without testing, a single overlooked bug, say, a missing region variable or a misconfigured ACL that leaves an S3 bucket public, could silently make it into your registry. Every environment using that module would be exposed.

Here’s how to prevent it:

Before publishing, the platform team runs an integration pipeline that provisions a real test workspace with actual cloud credentials. On the first run, the missing region is caught. On the second, the public S3 bucket is flagged. Both are fixed before the module ever touches the registry.

The single step of testing modules in isolation before release turns potential outages into harmless build failures, protecting every downstream environment.

Why test your modules?

When you publish a shared module to your registry, you're trusting that it works now, and will continue to work later. Without dedicated testing, it's easy to miss:

• Required variables that aren't defined
• Breaking changes introduced by new commits
• Inadvertent updates that change resource behaviour across all consumers
• Cross-module dependency conflicts
• Security misconfigurations that expose resources publicly

Testing modules addresses these risks by validating them in isolation before they’re promoted to the registry.

How module tests work

A dedicated Integration pipeline is added to your module’s development branch. This pipeline:

• Provisions a real test environment.
• Executes real init, plan, and apply commands using OpenTofu (or Terraform).
• Validates cross-module compatibility and runtime behaviour.

‍

‍

✅ Tip: You define test inputs just like consumers would, using actual variables, connectors, and real infrastructure.

Only after the module passes this pipeline should it be promoted to the main branch and published.

Key Benefits

• Confidence in Reuse: Prevent broken or misconfigured modules from being published to your shared registry
• Safe Promotion Workflow: Validate modules in feature branches before promoting to main
• Catch Critical Misconfigurations: Detect missing variables, logic bugs, or public exposure risks early
• Governance and Drift Control: Enforce testing standards for modules, protecting downstream workspaces
• Auditable Changes: Avoid disaster-level rollouts by validating before any code touches production
• Encourages Reusability: With confidence in test coverage, teams are more likely to standardize on shared modules

CI/CD Integration and Testing Approaches

Testing modules complements traditional IaC testing techniques like the following methods:

• tflint, validate
  
  • Syntax, formatting, and static checks
• Terratest
  
  • Unit tests & mocks
• Checkov, tfsec
  
  • Static security scanning
• Registry testing
  
  • Real-world integration and runtime testing

Example CI/CD flow:

‍

The integration testing stage spins up real infrastructure to validate that your modules work as expected before they reach production consumers.

Advanced Use Cases

Multi-Environment Testing

Test your modules across different cloud regions or account configurations to ensure portability:

Dependency Chain Validation

Test complex module hierarchies where modules depend on outputs from other modules:

Compliance and Security Validation

Integrate security scanning directly into your integration tests:

Rollback Testing

Validate that module updates can be safely rolled back by testing both upgrade and downgrade paths.

Implementation Considerations

Setting up tests for your modules requires some initial overhead, but the investment pays dividends as your module ecosystem grows:

Resource Costs: Integration tests provision real infrastructure, so factor in cloud costs for test environments. Use short-lived resources and automated cleanup to minimize expenses.

Test Environment Management: Establish dedicated sandbox accounts or subscriptions for integration testing to avoid conflicts with production resources.

Pipeline Execution Time: Real infrastructure provisioning takes longer than unit tests, so optimize your pipeline for parallel execution where possible.

Where to find Module Registry and Module Testing

Testing modules is becoming a core best practice in the OpenTofu ecosystem. But finding a platform that natively integrates registry management and test pipelines can be challenging.

If you’re looking for a platform that natively integrates module registries with testing pipelines, Harness Infrastructure as Code Management (IaCM) has you covered:

• ✅ Manage reusable modules with a built-in Module Registry
• ✅ Validate them using Integration pipelines before publishing
• ✅ Promote only tested, trusted modules to your consumers
  
  

Check out how to create and register your IaC modules and configure module tests to get started with pipeline setup and test inputs.

Conclusion

If you value stability, reusability, and rapid iteration, then testing your modules is more than a nice-to-have; it’s your safeguard against chaos.

By combining traditional CI/CD validation with real infrastructure testing, you get the best of both worlds: fast feedback and real-world assurance.

Start small. Iterate. And as your registry grows, let testing give you the confidence to scale.

‍

We are incredibly proud and excited to announce that Wiz has honored Harness with the inaugural WINvaluable Award!

This recognition is a special one. It comes as the Wiz Integrations (WIN) partner ecosystem—a network dedicated to creating a new standard for integrated cloud security—surpasses 200 integrations strong. For Harness, this award is more than a trophy; it’s a testament to a deep,collaborative partnership built on a shared vision: to empower organizations to build and deploy software quickly and securely.

‍

A Partnership Forged to Solve the Toughest DevSecOps Challenges

In today's cloud-native world, the pressure to innovate faster is constant. But this acceleration has often created a deep tension with security. The "shift-left" movement aims to solve this by embedding security earlier in the Software Development Lifecycle (SDLC). However, this often leads to a new problem: a "wall of noise" where developers are flooded with low-context alerts, causing fatigue and slowing them down.

‍

This chaos is precisely the challenge our partnership with Wiz solves. As the first certified CI/CD platform vendor to partner with Wiz, we've gone beyond a simple integration. We’ve built a deeply connected solution that delivers high-fidelity, prioritized, and actionable security Insights from Wiz directly into the developer's workflow, right when and where they need them.

‍

From Intelligent Detection to AI-Powered Remediation

At the heart of our integration is Harness Security Testing Orchestration (STO). STO seamlessly orchestrates Wiz’s excellent scanners for containers, Infrastructure as Code (IaC), and secrets directly within Harness CI/CD and Infrastructure-as-Code pipelines. This allows teams to correlate findings across their entire application, for example, automatically elevating the severity of a vulnerability in a container if an IaC scan reveals it’s configured to be exposed to the public internet. We're effectively shifting Wiz's powerful concept of "toxic combinations" into the pre-production pipeline in Harness.

‍

Harness doesn’t stop at detection. This is where the magic of Harness AI comes in. Context-rich findings from Wiz are fed directly to Harness AI. Harness AI analyzes the vulnerability and provides developers with prescriptive remediation guidance, often down to the exact code change needed to fix the issue. This solves the "last mile" problem of DevSecOps. Harness AI doesn’t just tell developers what's broken; it helps them fix it, instantly, transforming their role from researcher to reviewer and dramatically reducing toil.

‍

Building the Future of Cloud Security, Together

Receiving the WINvaluable Award is a significant milestone, and we are grateful to the team at Wiz for this recognition and their incredible partnership. It validates our joint commitment to providing a developer-first security experience that reconciles speed with control. By pairing best-in-class cloud security with an AI-native software delivery platform, we are enabling our mutual customers to accelerate innovation with the confidence that they are building on a secure foundation.

Want to see our WINning integration in action?

• Learn more about the Harness and Wiz integration.
• Request a demo today!

‍

Introducing Traceable Cloud WAAP: Built for the Way Applications Work Today

Today marks a major milestone in our journey to deliver the industry’s first unified DevSecOps platform—one that empowers engineering and security teams to collaborate seamlessly and deliver software quickly and securely. Following the merger of Harness and Traceable, we’re proud to unveil our first major innovation as a combined company: Traceable Cloud Web Application and API Protection (WAAP). This solution is purpose-built to secure modern, cloud-native applications and APIs—wherever and however they run.

The merger of Harness and Traceable was driven by a shared vision: to unify security and software delivery within a seamless, AI-powered platform. Traceable Cloud WAAP is a powerful example of our unified vision in action. It delivers deep, context-aware protection for web applications and APIs—helping you detect threats earlier, respond faster, and enforce consistent, intelligent defenses across your entire stack.

In a world where software changes rapidly and threats evolve just as fast, siloed tools are no longer enough. Together, we are setting a new standard for how teams seamlessly develop, deliver and secure applications, enabling them to embed security at every stage of the software lifecycle—without slowing development.

Why Traditional WAAP Falls Short in a Cloud-Native World

Today’s applications are cloud-native, highly distributed, and powered by APIs that form the backbone of digital interaction. But while apps have evolved, many security solutions haven’t. APIs now account for over 70% of internet traffic, yet traditional WAAP products still focus on perimeter defenses—leaving the core of modern architectures vulnerable.

Attackers have adapted, exploiting APIs, abusing business logic, and evading static defenses. Legacy WAAP solutions were designed for a simpler time—when applications lived behind a static edge, and traffic was easier to inspect and control. But cloud-native applications are anything but static. They scale across multiple environments, communicate through ephemeral APIs, and change frequently as development teams release new features at high velocity.

Traditional WAAPs can’t keep up. They miss shadow APIs, overlook internal traffic, and struggle to detect business logic abuse or human-like bots. They also rely heavily on manual rule tuning and separate runtime protection from development workflows, creating unnecessary friction between security and engineering teams.

As a result, organizations are left with blind spots that attackers are quick to exploit. In today’s API-driven world, reactive, perimeter-based security is no longer enough.

True Defense-in-Depth Starts with Deep Context

Traceable Cloud WAAP unifies four critical security capabilities in a single, integrated solution: 

• Web application protection
• API security
• Bot mitigation
• DDoS defense

But where it truly stands apart is in the depth of its context and intelligence.

Rather than depending solely on static signatures, Cloud WAAP analyzes behavior across users, APIs, and sessions in real-time. It understands how traffic is expected to behave—and intervenes when something deviates from the norm. This enables security teams to detect threats earlier, respond faster, and make decisions with greater confidence.

As environments grow more complex, a unified approach backed by deep context ensures consistent protection across your entire application ecosystem.

How Traceable Solves What Others Miss

Built specifically for cloud-native environments, Traceable Cloud WAAP represents a strategic evolution in application protection for today’s API-first world. It delivers the deep visibility and operational agility that traditional WAAPs lack, ensuring modern applications remain secure as they scale, shift, and grow more complex.

Key capabilities include:

• Comprehensive API discovery from traffic, encrypted flows, and code repositories
  
  
• Sensitive data flow mapping and customizable API risk scoring
  
  
• Real-time runtime protection with attacker fingerprinting, user/session attribution, and anomaly detection
  
  
• Shift-left API testing integrated into your CI/CD pipelines to catch vulnerabilities before production
  

Real-Time Insights, Actionable Defense - Traceable Cloud WAAP provides deep, real-time   visibility into application and API traffic. Instantly identify and respond to OWASP Top 10 threats, blocked attacks, and the most targeted services—all from a single, context-rich dashboard designed for modern, cloud-native environments.

Traceable is also designed for maximum deployment flexibility—integrating seamlessly with your environment, no matter how it’s built:

• Out-of-Band: Mirror traffic from gateways or load balancers, or use eBPF for deep, passive visibility without requiring code changes
  
  
• Inline Agents: Deploy directly in API gateways (e.g., Kong), load balancers (e.g., NGINX), or inside application code using lightweight language agents
  
  
• Edge Deployment: Route traffic securely to our POP’s via DNS or deploy Traceable behind a CDN for fully managed, agentless protection

This combination of deep visibility, intelligent runtime protection, and flexible deployment empowers security teams to close visibility gaps, detect threats earlier, and enforce protection wherever modern applications and APIs live.

Secure What Matters, Wherever It Runs

Speed and security shouldn’t be at odds. Traceable Cloud WAAP eliminates bottlenecks, enabling fast, uninterrupted development—while keeping protection always on.

Whether you’re securing API-driven microservices or hybrid environments across cloud and on-prem, Traceable protects what matters most: your data, your users, and your APIs.

In a world where applications constantly evolve, security must too. Traceable delivers the visibility, context, and adaptability needed to protect modern, dynamic environments from the inside out.

This launch is the first major innovation since Harness and Traceable joined forces—and it reflects our shared vision for a unified, AI-powered DevSecOps platform. Together, we help teams move faster, stay aligned, and defend what matters most.

From bot attacks and API abuse to DDoS threats, Traceable ensures your defenses scale with your apps—without slowing innovation.

Schedule a demo to see how Traceable protects your APIs, apps, and users in real-time.

Incident Date: March 14th, 2024 (discovered)

CVE: CVE-2025-30066

Updates on the incident

This section will be updated regularly based on available information, and analysis related to the incident. Following the report on the tj-actions/changed-files supply chain attack, new findings from Wiz Research reveal that the compromise may have originated from a separate attack on reviewdog/actions-setup@v1. This newly discovered breach likely led to the compromise of the tj-actions-bot's GitHub Personal Access Token (PAT), enabling attackers to modify the tj-actions/changed-files repository and cause widespread secret leaks. The attack involved injecting a base64-encoded payload directly into the install.sh script, impacting CI workflows across multiple repositories.

Given that reviewdog/actions-setup@v1 was compromised before the tj-actions incident and later stealthily reverted, there is a significant risk of recurrence. Security teams should take immediate action by identifying affected repositories, removing references to impacted actions, rotating any potentially exposed credentials, and enforcing stricter security practices such as pinning GitHub Actions to specific commit hashes. Wiz has disclosed these findings to reviewdog and GitHub, and we continue to monitor developments to prevent further supply chain threats.

Overview

On March 14, 2025, a major supply chain attack compromised the tj-actions/changed-files GitHub Action, widely used across 23,000+ repositories. The attackers modified the action’s code and updated multiple version tags to a malicious commit, causing workflows to execute a script that leaked sensitive CI/CD secrets through workflow logs.The compromise is also being tracked as a vulnerability, and has been assigned CVE-2025-30066.

Breaking Down the Attack

The attackers injected malicious code by spoofing the commit with a Node.js function including base64-encoded payloads, which were added to the GitHub Action tags. The payload, once decoded, revealed a script that downloaded additional malicious Python code from a GitHub Gist. The Python script then scanned the memory of the GitHub Runner’s "Runner.worker" process for sensitive credentials using regular expressions. Finally, the extracted secrets were printed in the workflow logs, exposing them to unauthorized access.

Immediate Measures to Control the Impact

To mitigate the risks associated with this attack, consider the following immediate actions:

• Allow-List GitHub Actions: Use GitHub’s allow-list to block compromised actions and keep it updated with trusted ones.
• Pin GitHub Actions to Specific Commit SHAs: Avoid using floating tags (@v35, @latest); always pin to a specific SHA for security.
• Rotate Secrets: Monitor logs for suspicious activity and immediately rotate any compromised secrets.‍
• Manage Workflow Logs: Delete affected logs after analysis to remove traces of exposed secrets.

How can Harness SCS help?

Harness Supply Chain Security (SCS) proactively secures your software supply chain by identifying and mitigating risks within your workflows. It scans for unverified dependencies, unpinned GitHub Actions, and critical security misconfigurations, ensuring vulnerabilities are detected and addressed before they can be exploited. Harness also enforces supply chain benchmarks, performs comprehensive security checks, and implements proactive measures to prevent future attacks.
‍

‍

1. Identify Unpinned Actions: Harness SCS detects unpinned actions in the pipeline workflow. Unpinned GitHub Actions can be modified, allowing attackers to inject malicious code into pipelines, potentially exposing secrets or altering source code.

2. Restrict Action Permissions: Running unverified GitHub Actions without restrictions increases the risk of executing malicious code from compromised or hijacked actions. Enforcing minimal permissions helps limit potential damage and enhance security.

3. Minimal Token Permissions: Use Harness SCS to find and apply minimal token permissions for GitHub Actions, reducing exposure and ensuring adherence to the principle of least privilege.

The SCS module provide additional rules to minimize the blast radius of supply chain risks or attacks, limiting the attack surface and strengthening security.

Integrating Harness SCS Runtime Analysis with Traceable - Coming Soon!

The Traceable eBPF agent is set to offer several features that will significantly enhance runtime protection for both GitHub Actions and Harness CI in the future:

- Detect Leaked Secrets: By integrating with GitHub’s log API, it will be able to detect sensitive secrets exposed in logs, helping to mitigate the risk of data leakage.

- Monitor External URLs: The agent will be capable of spotting unusual GitHub Action calls to external URLs, using a baseline technique to reduce noise and improve detection of suspicious activities.

- Identify Malicious RCE: It will also be able to detect malicious remote code execution (RCE) calls, such as scripts trying to print environment variables, helping to block potential threats before they escalate.

Conclusion

The tj-actions/changed-files supply chain attack highlights the increasing risks in CI/CD security. To prevent similar incidents, organizations must adopt proactive security measures and follow best practices, such as using pinned actions, auditing workflows, and enforcing strict access controls. Consider using the Harness SCS to prevent future attacks.

Request a demo

‍

As authentication complexities grow, have you ever wondered how effortlessly you can switch between different applications without remembering multiple passwords? All you need to do is click an option like "Sign in with <any social account>," and with just one click, You are authorized, and the application is now ready for use.

Sounds simple, right? But behind the scenes, you're actually using a powerful authentication method that not only verifies your identity but also determines what actions you're allowed to perform within the application.

In this article, we will explore and focus on a authentication method specifically —OpenID Connect (OIDC). We will discuss what it is, how it works, how companies leverage it for security and user experience, and how Harness uses OIDC to ensure secure software deployments.

What is OpenID Connect (OIDC)?

OIDC is an authentication protocol built on top of OAuth 2.0. It provides a standardized way to verify user identities for an application while ensuring both security and convenience.

It acts as a digital identity card for the internet, enabling secure access to different applications without the need to manage multiple passwords. It simplifies the authentication process by adding an identity layer to OAuth 2.0.

OIDC ensures that only legitimate users can log into an application, while OAuth 2.0 determines what actions and permissions the user is allowed to perform. One of the benefit of OIDC is short-term token which reduces the blast radius.

Key Components of OIDC

To understand the functionality, let’s begin by dissecting the five essential components and examining how they interact cohesively.

1. Relying Party: This can be any application that needs to verify user identities. For example, when you use "Login with Google" on a website, the website acts as the Relying Party—it relies on Google to verify your identity.
2. Identity Provider(IdP): An Identity Provider (IdP) can be thought of as a trusted authority, like Google, Microsoft, or Okta. They manage your account and verify your identity. When you log in using an IdP, it confirms who you are to other applications.
3. ID Token: It is securely packaged information about you, also known as a JWT (JSON Web Token). It contains verified claims about your identity, such as your name, email, and login details.
4. UserInfo Endpoint: Some applications require additional information about you that may not be available in the ID Token. This endpoint provides a secure way to fetch the missing information.
5. Scopes and Claims: Scopes can be considered as consent requests that inform you about what information an application can access. Claims are the actual pieces of information shared when you approve a scope.

Working and User Journey with OIDC

OIDC offers users a seamless experience while guaranteeing secure access to various applications. The following key stages define the typical user journey with OIDC:

1. Initiation: The user attempts to access a resource that requires authentication. This action prompts the application to redirect the user to the OIDC provider.
2. Authentication: The user is presented with a login page by the OIDC provider. Here, they can enter their credentials or choose to authenticate using a social login option.
3. Authorization: Once authenticated, the user is asked to grant permissions to the application requesting access to their profile information. This step ensures the user is aware of the data being shared.
4. Token Issuance: Upon granting permission, the OIDC provider issues an ID token and, if applicable, an access token. These tokens are crucial for the application to verify the user's identity and access their information.
5. Access Granted: The application receives the tokens and uses them to authenticate the user, allowing access to the requested resources.
6. Session Management: The application manages the user session, which includes handling token expiration and renewal processes to maintain a secure and uninterrupted user experience.

Using the similar workflow, Developers can create more intuitive and secure applications that enhance user satisfaction while maintaining robust security measures.

Traditional Authentication vs OIDC vs OAuth 2.0

Implementing OIDC with Harness

Harness provides multiple options for using OpenID Connect (OIDC); however, in this section, we will focus on executing a pipeline with OIDC. We also encourage you to explore Single Sign-On (SSO) with OIDC, as we plan to share configuration details in future blog posts.

Secure your pipelines by configuring OIDC to ensure deployments run in a specific authorized environment. This section will guide you through configuring OIDC in GCP, requiring setup in both Harness and the cloud platform for secure pipeline execution.

Pre-requisites:

To begin the configuration process, we will need the following.

1. Harness AccountId : Login to your harness account → Account Settings → Account Details. Save it for further configuration.
2. To establish a connection to GCP using OIDC, you must first configure an OIDC Identity provider and link the service account with the necessary permissions that Harness will utilize for operations within GCP. This setup will enable you to configure the following:
   1. GCP workload identity provider, once completed you will be able to get
      • Workload Pool ID
      • Provider ID
      • Project ID
      • Service Account Email
   2. After completing the previous step, you will need the following to set up the GCP connector.
3. To set up your OIDC identity provider, please note below URLs to configure Harness OIDC provider endpoint and OIDC audience settings:
   • For the Harness OIDC provider endpoint that will be used within GCP, replace <YOUR_ACCOUNT_ID>with the Harness account ID you obtained in step 1.
   https://app.harness.io/ng/api/oidc/account/<YOUR_ACCOUNT_ID>
   • Specify the OIDC audience
   https://iam.googleapis.com/projects/<YOUR_GCP_PROJECT_ID>/ locations/global/workloadIdentityPools/<YOUR_WORKLOAD_POOL_ID>/providers/<YOUR_PROVIDER_ID>

For information about these values, we recommend to got through the GCP documentation on Managing workload identity pools, Managing workload identity pool providers, and Creating and managing projects.

Configuring  OIDC with pipeline

1. To configure and verify the GCP connector, follow these steps:
   1. Navigate to Account Settings.
   2. Select Account-level resources.
   3. Click on Connectors.
   4. Choose Cloud Provider (GCP).

‍

2. Create and configure a codebase:
   1. To add or create your codebase in a Harness Code Repository, you will need to connect this repository or any third-party code repositories during the pipeline configuration process.
   2. We have already integrated a codebase into the repository, which we will connect within the pipeline.

3. To set up a Harness CI Pipeline.
   1. Navigate to Continuous Integration, then select Pipelines, and click on Create Pipelines.
   2. After finishing the initial steps, move on to the Build stage and set up the deployment of the codebase as illustrated below. For a comprehensive guide, you can refer to the detailed description here.
   3. The build stage consists of four steps: Overview, Infrastructure, Execution, and Advanced. For now, we will concentrate on the Infrastructure and Execution steps. These steps enable the configuration of pipelines using OIDC.
   4. To deploy your pipeline, begin by selecting one of the options within the Infrastructure stage, which includes Kubernetes, Local, and VMs. Choose the option that best meets your requirements, and then select the appropriate platform accordingly.

4. Deploying a Pipeline with OIDC Environment:
   To successfully execute the deployment of your application, it is essential to establish a clear sequence of steps. When deploying on Google Cloud Platform (GCP), ensure that you have your Host ID and Project ID prepared for configuration, as illustrated in the instructions below.

5. Successful Deployment of Pipeline.
   After configuring your settings, be sure to apply the changes and save them to Run. With a successful deployment, it is confirmed that the pipeline is running in an OIDC-enabled, secure environment.

‍

Advantages of OpenID Connect (OIDC)

1. Secure & Seamless Login – Provides strong authentication with Single Sign-On (SSO) support.
2. Short-Term Tokens – Tokens have a TTL, reducing security risks in case of compromise.
3. No Password Storage – Eliminates the need to store user credentials, reducing the risk of leaks and breaches.
4. Standardized & Interoperable – Works across platforms and identity providers.
5. Secure API Access – Uses short-lived access tokens instead of passwords, preventing unauthorized access.
6. Regulatory Compliance – Aligns with GDPR, HIPAA, and other security standards.

Conclusion

In today's digital world, security and user convenience are more important than ever. OpenID Connect (OIDC) provides a powerful solution that simplifies authentication while ensuring secure access to applications. With OIDC, users can log in seamlessly without managing multiple passwords, and organizations can strengthen security and streamline user management.

As we’ve seen, OIDC not only verifies user identities but also manages their permissions, making it essential for modern applications. When integrated with platforms like Harness, OIDC enhances security in software deployments, allowing teams to focus on innovation instead of authentication challenges.

As digital identity continues to evolve, adopting OIDC will be key for businesses looking to provide a secure and user-friendly experience. Implementing OIDC ensures organizations are prepared for the demands of today’s digital landscape, paving the way for a more secure and efficient future.

Modern software supply chains are extremely complex, comprising not only everything that goes into an application, but also the entire CI/CD toolchain that delivers the application from developers to customers. Attackers love this complexity. They see each link in this chain as an attack vector, with the potential to compromise vulnerable elements without detection. Software supply chain attacks are on the rise in number and in sophistication and Gartner Research estimates that by 2025, at least 45% of enterprise organizations will have experienced at least one software supply chain attack.

In recent years, we’ve witnessed a series of high-profile attacks that emerged in the application space, targeting open source software dependencies. The log4j vulnerability is arguably the most notorious example of this type of breach, as it impacted tens of thousands of organizations and allowed attackers to execute commands remotely through a shell. 

Attacks like the one that compromised SolarWinds targeted the build systems where attackers exploited misconfigured CI/CD tools to replace legitimate source code with new files, giving them backdoor access that compromised tens of thousands of SolarWinds’ customers.

‍

To protect against sophisticated supply chain threats, we need a comprehensive supply chain security solution that can not only effectively block zero day vulnerabilities linked to OSS dependencies, but which can also prevent attackers from compromising code repositories, CI/CD tools, and artifact registries by identifying and eliminating security vulnerabilities and misconfigurations.

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

We routinely hear from customers with clear goals of bringing their software supply chains in line with the leading risk and compliance frameworks, such as CIS, OWASP Top-10, NIST, etc. that achieving their objectives is anything but straightforward. Fortunately, Harness has a deep and detailed understanding of the software supply chain, and since last year’s introduction of integrated features to govern open source software (OSS) dependencies using SBOMs and artifact promotion with SLSA build attestations, we’ve expanded our focus to CI/CD pipelines for end-to-end software supply chain security. 

The Harness Supply Chain Security (SCS) module is designed to prevent attacks similar to the CodeCov and Solarwinds hacks in different attacks paths by rapidly identifying security gaps and aligning code repos, CI/CD tools, and artifact registries with OWASP Top-10 CI/CD Security Risks, CIS Supply Chain Security Benchmarks and other essential risk frameworks. In addition to the Harness platform, SCS integrates with GitHub and other major 3rd party developer platforms.

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

Overall, when it comes to achieving continuous supply chain GRC (governance, risk management & compliance), there are three main stages. The first is focused on software artifact governance, where organizations define and enforce policies to control the use of OSS dependencies using SBOMs (software bill of materials) and artifact promotion using SLSA attestations. 

The second aspect, which is the focus of this blog– involves understanding supply chain security posture through pinpointing CI/CD toolchain risks and bringing code repos, CI and CD tools, and artifact repositories into compliance with major risk frameworks. Through the Supply Chain Security module, Harness makes this possible not only for Harness CR, CI, and CD, but also for 3rd party developer platforms such as GitHub.

Finally, continuous supply chain GRC relies on a readiness to quickly remediate any risk and compliance issues, including the removal of non-compliant OSS dependencies and blocking of dependencies impacted by zero-day vulnerabilities.

‍

‍

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

The first step in building a detailed picture of your software supply chain security posture is to evaluate it against extensive risk and compliance rulesets. In Harness SCS, CIS Supply Chain Security Benchmark and OWASP Top 10 Security Risks for CI/CD and OSS are listed in detail in the ‘Rule Definitions’ section (shown below) of the SCS module’s compliance feature section.

‍

Next, running evaluations of your CI/CD pipelines’ security postures against these rulesets enables you to  pinpoint vulnerabilities and other security gaps, such as pipeline misconfigurations. The results of these checks are presented in the SCS module’s compliance dashboard, which displays rule failures by severity and evaluation trends over time. The bottom of the dashboard highlights rules that fail most often. In this particular example, this list includes 73 counts of failure because of pipelines being ‘vulnerable to command injection’.

‍

By clicking on a specific evaluation status, you can access detailed information about the rule, including the reason for its failure and general remediation steps to help address the issue identified.

‍

‍

Conclusion

Attacks on software supply chains will only continue to intensify, so it is critical to have the tools in place to rapidly assess and remediate areas of vulnerability across repos, CI/CD tooling, registries, software artifacts, and other elements in the chain. If you’re a CISO or a compliance leader, you know first-hand that bringing your software supply chains into compliance can be a convoluted process. The good news is that Harness SCS now gives you the tools and workflows to enable fast identification and remediation of improper CI/CD access controls, misconfigurations and vulnerabilities. These capabilities make software supply chain GRC substantially easier for you!

‍

Want to learn more about what Harness SCS can do for your software supply chain security posture? Request a demo!

Contact a Harness expert

Checkout Harness SCS

Learn about Software Supply Chain Security

What is a DevSecOps Pipeline?

DevSecOps (short for development, security, and operations) is an approach to secure software development that integrates security practices throughout the entire software development lifecycle. It emphasizes collaboration and communication between development teams, security teams, and operations teams to ensure that security is seamlessly built into every stage of the software development process.

Within the context of software development, a DevSecOps pipeline is a CI/CD pipeline with integrated security tooling and processes for application security testing, remediation, and security & compliance governance. Instead of bolting security processes on to the end of software development projects with point-in-time audits and penetration tests after code is deployed, DevSecOps seamlessly integrates security and shifts it left, which essentially means that security is applied as early as possible in each phase of the software development lifecycle.

Organizations that can leverage DevSecOps pipelines successfully achieve stronger security posture and code quality without impacting developer productivity and velocity. 

DevSecOps Pipeline Tools And Services

A Successful DevSecOps practice relies on the use of the following application security scanners and governance:

‍Software Composition Analysis (SCA) Scanners

SCA is a security technology that protects applications against risks that originate from open source software (OSS). SCA solutions identify and manage vulnerabilities within open source libraries and components, in order to meet security & compliance requirements.

‍SAST (Static Application Security Testing) Scanners

SAST scanners are critical for uncovering and eliminating vulnerabilities in proprietary software early in the SDLC, before an application is deployed.

‍Secret Detection Scanners

Secret scanners automatically scan text and files for secrets, such as passwords or API keys.

‍Container Scanners

Container scanning involves comparing the contents of each container to a database of known vulnerabilities. If the scanner determines that a library or other dependency within a container image is subject to a known vulnerability, it will flag the image as insecure.

‍DAST (Dynamic Application Security Testing)

DAST scanners are used after application deployment to spot issues that manifest at runtime, such as authentication and network configuration flaws.

‍Infrastructure-as-Code (Iac) Scanners

IaC scanners enable the identification of all the variables for which the proper settings are either undefined or are set incorrectly. Scanning IaC involves checking templates, files, and modules and their variables against known policies. 

‍Policy-as-Code Governance

DevSecOps pipelines require strong governance to ensure that vulnerable code isn’t deployed or promoted to the next pipeline. This requires enforcement of policies throughout the pipeline, such as ones that break the pipeline upon discovery of certain types or severity of vulnerabilities.

Key Benefits of DevSecOps Pipelines

The primary objective of DevSecOps is to deliver more secure software without degrading developer velocity. If DevSecOps pipelines are implemented correctly, software-producing organizations will reap the following benefits:

• decrease in application security incidents 
• decrease in time spent on compliance audits
• increase in deployment frequency
• decrease in change failure rate
• decrease in the number of vulnerabilities deployed to production 
• decrease in lead time to zero day vulnerability remediation

‍

Want to learn more about how Harness Security Testing Orchestration helps you build robust DevSecOps pipelines? Visit the STO product page or sign up for a demo with one of our experts!

‍

Securing Containers With DevSecOps

Containers have revolutionized software development and deployment, offering consistency and efficiency across environments. A container packages up a short piece of code– the container image– along with all of its dependencies, binaries, and libraries. The widespread adoption of containers also comes with new and challenging security risks that organizations must address. Containers are inherently isolated, but vulnerabilities still exist at various levels—within the container images, the runtime, the orchestration, and the underlying infrastructure. For modern containerized applications, DevSecOps is an effective methodology for securing containers by automating security testing and shifting it left to uncover known vulnerabilities as early in the software development lifecycle as possible.

Container Security Vulnerabilities

Containers have a variety of vulnerabilities that pose a significant security risk. Organizations building modern applications must ensure that their software developers, DevOps teams, and application security teams are prepared to address these vulnerabilities proactively to strengthen the application’s overall security posture. Here are some common types of container vulnerabilities:

Insecure Container Images

Using container images with known vulnerabilities can expose the entire infrastructure to cyberattacks. Attackers can exploit these vulnerabilities to compromise the host system, gain unauthorized access, or execute malicious code. DevSecOps stakeholders must regularly scan container images for known vulnerabilities and keep them up to date.

Container Runtime Misconfigurations

Misconfigurations in container runtimes can lead to inadequate isolation between containers, allowing unauthorized access and lateral movement by an attacker. 

Vulnerable or Outdated Container Dependencies

Containers regularly include dependencies such as libraries and frameworks. These can contain security vulnerabilities, as is often the case with many open source dependencies. 

Exposed Secrets And Sensitive Data

Storing sensitive data or secrets within containers without adequate protection can lead to data breaches or unauthorized access. Organizations need to use strong encryption and dedicated solutions such as secrets managers for storing secrets securely.

‍

Addressing Container Security With DevSecOps

In DevSecOps, application security tests are executed by security scanners that are configured to analyze different aspects of the application and report on any vulnerabilities that could be exploited. The DevSecOps methodology is essential for container security, because security tests are seamlessly integrated and run in a shift left manner across software pipelines which makes it easier for developers to remediate their code.

‍

Testing For Container Security Vulnerabilities 

There are several different types of application security tests that should be run as part of a DevSecOps program delivering secure containerized applications:

Static Code Analysis (SCA)

SCA is used to inspect an application’s source code. During the software development process, it aims to identify known vulnerabilities like potential injection attacks, insecure coding practices, or unhandled exceptions. Integrating SCA in CI/CD pipelines has several advantages. First, it helps decrease the number of vulnerabilities that find their way to production. SCA also helps developers to adhere to coding standards and best practices. It also streamlines the development process by automating security checks, reducing manual effort and accelerating the delivery of secure software.

Container Scanning

Container scanning tools are purpose built to analyze containers and their contents against a database of known vulnerabilities. If, for example, a library or dependency within a container image contains a known vulnerability, the scanner will flag the image as insecure.

Secret Detection

Secret detection scanners look for different types of sensitive information, such as passwords or API keys that can sometimes be hard-coded in application code by developers. For example, API keys are often in the format of a long string of letters and numbers. Similarly, passwords are often stored as hashes. By searching for these patterns, potential secrets in container images can be identified.

Dynamic Application Security Testing (DAST)

DAST scanners are used to simulate attacks against containers while they are running. This allows developers and application security teams to identify vulnerabilities inherent to the running application, and which would otherwise not present themselves in the code. DAST tools analyze how containers behave at runtime, such as how they handle network traffic, how they validate inputs and their authentication mechanisms.

‍

Take Container Security Testing To The Next Level With Harness STO

Harness Security Testing Orchestration (STO) is shift-left security built for your CI/CD pipelines and designed for developers. With Harness STO, you can seamlessly integrate security scanners and orchestrate application security tests anywhere across your build pipelines and enable developers to rapidly remediate vulnerabilities through intelligent prioritization and deduplication, and AI-driven remediation guidance.

Learn more about how the Harness Security Testing Orchestration (STO) module can help you shift application security testing left and accelerate vulnerability remediation without toil.

What is Dynamic Application Security Testing (DAST)?

Dynamic Application Security Testing (DAST) is an approach to application security testing whereby an application (typically a web application or service) is analyzed for security vulnerabilities when it is running, using a tool that simulates attacks and observes the application’s corresponding behavior. DAST tools don’t have internal information about the application or its source code; the attacks they simulate mirror what a malicious actor would do when trying to compromise an application whose inner workings are unknown to them.

Why Run Dynamic Application Security Tests?

Modern applications are complex, distributed, and built with a broad range of components, such as open source software. While other types of security scanners like SAST and container scanners are used to detect vulnerabilities within individual elements of the application, DAST tools address the entire running application to assess vulnerability to attacks like SQL injections, Cross-Site Scripting (XSS), and more. Since DAST tools are designed to operate in a runtime environment, they can detect runtime flaws which SAST tools can’t identify.

Benefits of Dynamic Application Security Testing

The purpose of DAST is to determine whether the application is vulnerable and if it could be susceptible to a cyberattack. DAST is key to strengthening the overall security posture of modern applications. The feedback produced by a DAST security scanner can be integrated with the security tools and DevOps tools the organization’s DevSecOps practice relies on.

Take Dynamic Application Security Testing to the Next Level With Harness STO

Harness Security Testing Orchestration (STO) is shift-left security built for your CI/CD pipelines and designed for developers. With Harness STO, you can seamlessly integrate application security scanners to orchestrate scans within build and deploy pipelines.

Built-in steps enable you to add DAST scans quickly and with minimal configuration. Harness STO offers the Zed Attack Proxy (ZAP) as a built-in DAST scanner, which is ready to run as soon as you add it to your pipeline. 

STO enables developers to rapidly remediate vulnerabilities through intelligent prioritization and deduplication, along with AI-driven remediation guidance.

Learn more about how the Harness Security Testing Orchestration (STO) module can help you shift application security testing left and accelerate vulnerability remediation without toil.

What is Application Security Testing?

Application Security Testing is the practice of scanning various aspects of an application throughout its development lifecycle for the purpose of uncovering and remediating known vulnerabilities, thus strengthening the application’s security posture.

‍

Application Security Testing is an essential part of DevSecOps, which is the practice of seamlessly integrating security tools, technologies, and practices throughout the entire software development lifecycle and shifting them left in order to address security vulnerabilities as early as possible. Application security tests are executed by security scanners that are configured to analyze different aspects of the application and report on any vulnerabilities that could be exploited.

Types of Application Security Tests

There are several different types of application security tests that should be run throughout the software development lifecycle:

‍SAST (Static Application Security Testing) Scanners

Static application security testing (SAST) involves analyzing application source code to detect security vulnerabilities that could potentially be exploited. SAST is applied early in the SLDC, prior to code being compiled. SAST scanners should be run on code on a regular basis, such as during periodic builds, at each code check-in, or during a code release. Catching and fixing vulnerabilities in the code base at an early stage has a dramatic impact on the quality and security posture of the final application.

‍SCA (Software Composition Analysis)

SCA tools are used to identify open source software within a code base, for the purpose of evaluating security, license compliance and overall code quality. As the vast majority of modern applications are built with open source software components, it is very important to be aware not only of the inherent security risks associated with a particular artifact, but also of licensing considerations regarding the use of that artifact or library.

‍Secret Detection

Sensitive information can be exposed through various means, such as through unsecured code, leaked code repositories, or unencrypted communication channels. Secret scanning is the practice of running automated scans on code repositories, execution pipelines, configuration files, commits, and other data sources to identify security vulnerabilities related to exposed secrets.

‍Container Scanning

A rapidly-growing number of modern applications are built as collections of small composable elements called containers. A container packages up a short piece of code– the container image– along with all of its dependencies, binaries, and libraries. Container scanning tools are purpose built to analyze containers and their contents for known security issues. 

‍DAST (Dynamic Application Security Testing) Scanners

Dynamic application security testing involves analyzing running applications. This methodology applies mainly to web applications and services and is used to find run-time vulnerabilities and environment-related issues.

‍IAST (Interactive Application Security Testing)

IAST is an application security testing method that tests an application while the application is run by an automated test, a human tester, or any activity “interacting” with the application functionality. At the core of the IAST tool are sensor modules which track application behavior while the interactive tests are running. Alerts are generated if a vulnerability is detected.

Benefits of Application Security Testing

The main advantage for running SAST, SCA, Container, DAST, and IAST scans is that it allows developers, DevOps teams and application security teams to discover and fix any known security vulnerabilities before an application makes it to production. Detected vulnerabilities can be prioritized by severity and then remediated by software developers, in collaboration with security teams.

‍

Application Security Testing: Best Practices

Shift Application Security Testing Left

As part of an effective DevSecOps program, it is critical to run application security tests as early on in the software development life cycle as possible, which enables developers and security engineers to detect and fix security vulnerabilities with the least amount of disruption and toil.

Automate Application Security Testing

Reduce the amount of manual operations and automate application security testing where possible. Integrating security scanners with a software development platform and automatically running them within build and deploy pipelines is highly recommended.

Feed Clear And Actionable Vulnerability Information To Developers

In order for shift left security to be effective, developers need to be able to act fast and remediate vulnerabilities with as little toil as possible. The use of multiple security scanners often produces a mountain of vulnerability data which must be deduplicated and prioritized in order for developers to immediately begin remediating them.

‍

Take Application Security Testing to the Next Level With Harness STO

Harness Security Testing Orchestration (STO) is shift-left security built for your CI/CD pipelines and designed for developers. With Harness STO, you can seamlessly integrate security scanners and orchestrate application security tests anywhere across your build pipelines and enable developers to rapidly remediate vulnerabilities through intelligent prioritization and deduplication, and AI-driven remediation guidance.

Learn more about how the Harness Security Testing Orchestration (STO) module can help you shift application security testing left and accelerate vulnerability remediation without toil.

Introduction to DevSecOps

DevSecOps (short for development, security, and operations) is an approach to secure software development that integrates security practices throughout the entire software development lifecycle. It emphasizes collaboration and communication between development teams, security teams, and operations teams to ensure that security is built into every stage of the software development process.

Within the context of software development pipelines, DevSecOps aims to “shift security left”, which essentially means as early as possible in the development process. It involves integrating security practices and tools into the development pipeline from the very beginning. By doing so, security becomes an integral part of the software development process rather than a late-stage add-on.

This approach makes it significantly easier for organizations to identify and resolve security vulnerabilities early on, and meet regulatory obligations. It's also important to note that DevSecOps is built upon a culture of collaboration and shared responsibility. It breaks down silos and encourages cross-functional teams to work together towards a common goal of building more secure applications at high velocity.

Why Is DevSecOps Critical?

There are many attack vectors used to access an organization’s data and digital assets, but a common tactic is to exploit vulnerabilities in software applications. These types of breaches are costly, time consuming, and depending on the severity, damaging to an organization's reputation and brand. The DevSecOps approach to building and deploying modern applications reduces the risk of deploying vulnerable or misconfigured software that attackers can exploit.

Core Principles of DevSecOps

Make security a shared responsibility

The importance of culture for successful DevSecOps shouldn’t be underestimated, and it starts with accepting security as a priority for all stakeholders. Every single member of an organization has an impact on its overall security posture– not just those with ‘security’ in their titles. At its core, DevSecOps is a culture of shared responsibility, and operating with a common security-oriented mindset determines how well DevSecOps processes fit into place and can drive better decision making when choosing DevOps platforms, tooling, and individual security solutions.

Mindsets don’t change overnight, but alignment and a sense of security accountability can be achieved through the following:

• Commitment to regular internal security training tailored to DevSecOps that includes developers, DevOps engineers, and security engineers. Skills gaps and needs shouldn’t be underestimated.
• Developer adoption of secure coding methodologies and resources
• Security engineering contributes to application and environment architecture, design reviews. It’s always easier to identify and fix security issues early in the software development lifecycle.

Break down functional silos and collaborate continuously

Since DevSecOps is a result of the confluence of software development, IT operations, and security, breaking down silos and actively collaborating on a continuous basis is critical for success. Typically, DevOps-centric organizations operating without any formal DevSecOps framework see security entering the picture like an unwelcome party crasher. Process changes or tooling that is suddenly imposed (as opposed to collaboratively chosen and instantiated) invariably results in development pipeline friction and unnecessary toil for developers. A common scenario involves security mandating additional application security checks without consideration for their placement within the pipeline, or for how much workload is required to process scanner output and remediate vulnerabilities, which inevitably falls to developers.

Driving collaboration and operating as a cohesive DevSecOps team involves:

• Defining and agreeing upon a set of measurable security objectives
• Involvement from software developers and DevOps teams throughout the evaluation and procurement processes for new security tools
• Ensuring no DevSecOps process has a single functional gatekeeper

Iteratively optimizing tooling choices and security practices for developer productivity and velocity

Shift security information left, not security workload

Broach the subject of DevSecOps and it’s impossible not to mention ‘shift-left’. The shift-left security mantra is so prevalent in current DevSecOps-oriented articles, blogs, and marketing collateral, it’s easy to think that by simply moving security checks further upstream in the software development lifecycle you’ve achieved a working DevSecOps program. The reality is that WHAT you shift left is what makes or breaks your DevSecOps success.

Shift left security is predicated on the proven idea that performing application security tests earlier in software development pipelines (as opposed to just prior to production) results in a better overall chance of catching known code and artifact vulnerabilities and remediating them in a timely manner. However, if developers alone bear the entire burden of running tests, collecting scanner output, and prioritizing vulnerabilities on top of remediating them, the resulting mental load and toil is certain to impact productivity.

DevSecOps Tools and Practices

The DevSecOps toolkit is primarily made up of CI and CD pipelines, application security scanners, and policy-as-code governance enforcement. AI and intelligent automation are key factors in making DevSecOps work successfully.

DevSecOps: Application Security Testing

‍

Software Composition Analysis (SCA)

SCA is a security technology that protects applications against risks that originate from open source software (OSS). SCA solutions identify and manage vulnerabilities within open source libraries and components, in order to meet security & compliance requirements.

‍

SAST (Static Application Security Testing)

SAST is critical for uncovering and eliminating vulnerabilities in proprietary software early in the SDLC, before an application is deployed.

‍

SECRET SCANNING

Secret scanning is the practice of automatically scanning text and files for secrets, such as passwords or API keys.

‍

CONTAINER SCANNING

Container scanning involves comparing the contents of each container to a database of known vulnerabilities. If the scanner determines that a library or other dependency within a container image is subject to a known vulnerability, it will flag the image as insecure.

‍

DAST (Dynamic Application Security Testing)

DAST is used after application deployment to spot issues that manifest at runtime, such as authentication and network configuration flaws.

‍

INFRASTRUCTURE-AS-CODE (IaC) SCANNING

IaC scanning enables the identification of all the variables for which the proper settings are either undefined or are set incorrectly. Scanning IaC involves checking templates, files, and modules and their variables against known policies. 

Key Benefits of DevSecOps

The primary objective of DevSecOps is to deliver more secure software without degrading developer velocity. If DevSecOps is implemented correctly, software-producing organizations will reap the following benefits:

• decrease in application security incidents 
• decrease in time spent on compliance audits
• increase in deployment frequency
• decrease in change failure rate
• decrease in the number of vulnerabilities deployed to production 
• decrease in lead time to zero day vulnerability remediation

‍

Want to learn more about how Harness Security Testing Orchestration helps you build a world-class DevSecOps practice? Visit the STO product page or sign up for a demo with one of our experts!

Explore more resources: Integrate security in software development while maintaining speed, 5 Core Tenets of Effective DevSecOps

What Is Shift Left Security? 

Shift left security, or “taking a shift left approach” to security, is the idea of integrating security and running application security tests as early on in the software development life-cycle (SDLC) as possible to uncover and remediate known vulnerabilities and other issues. The main objective of shifting security left is to improve the efficiency of these tasks, as it’s easier to fix vulnerabilities earlier as opposed to later in the development process. Waiting until the end of the development process almost always results in costly fixes, especially if significant architectural changes are needed. Finding and fixing errors early often results in less time and money spent on remediating security issues in the code. 

Traditional application security practices are not effective in a modern DevOps world. When security scans are run only at the end of the software delivery lifecycle (either right before or after a service is deployed), the ensuing process of compiling and fixing vulnerabilities creates massive overhead for developers; overhead that degrades velocity and puts production deadlines at risk.

Shift left security testing is effective for improving the overall quality of application code, reducing application security testing efforts by avoiding rework, and for reducing the amount of toil that degrades the overall developer experience. Therefore, shift left security is a fundamental tenet of DevSecOps.

Why Is Shift Left Security Beneficial for DevOps? 

DevOps teams enabling the development of modern applications are supporting developers with shift-left security tools and processes that automate security testing, governance, and remediation guidance for software developers.

Developers benefit greatly from shift left security, mainly because they are not interrupted by frequent, arduous remediation processes. The less time it takes to get static analysis, dynamic analysis, or testing results after checking in code, the more likely it is that the recently written code is still fresh in the developer’s mind. 

Shift Left Security Best Practices 

If you’re working on shifting security left in your CI/CD pipelines, here are some guiding principles to follow:

Assess your current software development process and map out a shift left methodology

Where in your CI/CD pipelines are you currently testing for security vulnerabilities? Could those tests be run earlier in the process? Could any waterfall methodologies become more agile (for example, rather than testing for flaws iteratively and integrating security solutions that can continuously monitor code and identify security bugs)?

Once you have a detailed picture about how you’re currently managing application security testing, create a document that defines your new shift left security objectives. This strategy should include how your organization will define shifting left and the processes and tools involved, how you will measure success, and both individual and team responsibilities across software developer teams, devops teams, and application security teams. 

Educate development teams in secure coding best practices

Shift left security training is a shared responsibility; organizations need to provide education to the right teams who can support and enhance shift left security. With more eyes on application code and with developers and application security engineers educated on what issues to look for and which tools to use, shift left security testing will become an important early step in the software development lifecycle.

Secure coding standards provide rules and guidelines compiled by security experts with years of knowledge that help prevent, detect, and eliminate errors that could compromise software security. Key security standards include CERT CWE, OWASP, DISA STIG, IEC 62443, and more. Educating your team about such standards and implementing static analysis tools to enforce coding standards across your codebase will safeguard your code from coding vulnerabilities early in the process. 

Mindsets don’t change overnight, but alignment and a sense of security accountability can be achieved through the following:

• Commitment to regular internal security training– tailored to DevSecOps– that includes developers, DevOps engineers, and security engineers. Skills gaps and needs shouldn’t be underestimated.
• Developer adoption of secure coding methodologies and resources
• Security engineering contributes to application and environment architecture, design reviews. It’s always easier to identify and fix security issues early in the software development lifecycle.

‍

Shift Security INFORMATION left, and not security workload

It’s easy to think that by simply moving security checks further upstream in the software development lifecycle you’ve achieved your application security objectives. The reality is that WHAT you shift left is what makes or breaks your success.

Shift left security is predicated on the proven idea that performing SCA, SAST, Container, Secret Detection, IaC, and DAST scans earlier in software development pipelines (as opposed to just prior to production) results in a better overall chance of catching known vulnerabilities and remediating them in a timely manner. However, if developers alone bear the entire burden of running tests, collecting scanner output, and prioritizing vulnerabilities on top of remediating them, the resulting mental load and toil is certain to impact speed to production. Instead, following these guidelines offers the best path to success for shift left security:

• Security teams should own the orchestration and automation of application security tests throughout CI and CD pipelines
• Remove the burden of deduplicating and prioritizing detected vulnerabilities from developers. Instead, security should ensure developers get a fully processed vulnerability list in a timely manner
• Accelerate remediation by generating actionable developer-oriented guidance for understanding and resolving each vulnerability

How Harness Security Testing Orchestration (STO) Shifts Security Left

Harness Security Testing Orchestration (STO) is shift-left security built for your CI/CD pipelines and designed for developers. With Harness STO, you can seamlessly integrate security scanners and orchestrate tests anywhere across your build pipelines and enable developers to rapidly remediate vulnerabilities through intelligent prioritization and deduplication.

‍

Benefits of Harness STO

Shift security left without friction

Easily configure and run SAST, SCA, Container, Secret Detection, and DAST scans within Harness CI/CD stages or in a standalone mode, integrating with any CI/CD tooling.

Use your preferred security scanners

Natively integrate with over 40 open source and commercial security scanners and create custom integrations to support your scanner of choice.

Accelerate vulnerability remediation with AI

Harness STO allows you to zero in on consequential security vulnerabilities through intelligent organization and deduplication. Developers get AI-enhanced remediation guidance and contextual information enabling them to apply the right fixes with no additional toil.

Strengthen application security governance

Create customized policies with centralized security governance templates powered by OPA and granular RBAC, ensuring that all desired application security scans are performed and achieve acceptable results.

SLSA: Supply Chain Levels for Software Artifacts

The software supply chain has come increasingly under attack in recent years, with attacks on software dependencies and build systems alike resulting in damaging breaches that have impacted tens to hundreds of thousands of customers and users at a time.

Supply Chain Levels for Software Artifacts (SLSA) is a security framework that helps ensure the integrity of software artifacts, serving as a mode of evaluating trust in a particular software artifact. It helps you assess if the code you’re using is tamper-free and offers a way to evaluate if the source code or build system used to create software packages is trustworthy. It aims to help secure the software supply chain against attacks by providing a model for security capabilities throughout the supply chain (the current SLSA framework focuses on the build stage). The OpenSSF launched SLSA in 2021.

What differentiates SLSA from other security guidelines is its design based on automatically creating verifiable metadata rather than simply providing a list of best practices. This metadata is useful for making policy decisions. SLSA goes beyond describing the process required to secure the software supply chain—it helps you implement security in the real world and obtain the data to demonstrate it.

SLSA Framework: Levels

The SLSA framework for the build track has four distinct levels:

• Level 0 — No assurance.
• Level 1 — Documented provenance of a package’s build process, helping to identify mistakes and to provide documentation for future reference.
• Level 2 — Associates identities and systems with the software. It entails cryptographically signed provenance, generated by the build system, which aims to detect tampering after the build process.
• Level 3 — This level is meant to detect tampering during the build. It enforces security at the individual build levels to help prevent attacks against the build systems themselves (malicious builds can’t affect other builds in the system).

Using SLSA for Securing The Software Supply Chain 

SLSA is only useful if someone is inspecting and verifying it. Organizations adhering to the SLSA framework need to be able to verify SLSA attestations and ensure provenance values match their standards. It’s expected that verification is performed automatically by tools and that expectations are formed by trusted authorities (package registry) or automatically (to detect unexpected changes). Here is a look at some of the capabilities needed.

Generate a SLSA attestation during the build process

Harness SSCA, for example, when used with Harness CI Hosted Builds (Harness Cloud), ensures that the resulting artifacts have SLSA Level 3 provenance that every consumer (including the following deployment stage) can verify for artifact integrity prior to making use of this artifact. Build hardening for Level 3 compliance is achieved through:

• Built-in infrastructure isolation for every build where new infrastructure is created for every run and deleted after the run completes.
• OPA policy enforcement on CI stage templates with non-privileged, hosted containerized steps that do not use volume mounts. This disallows the build steps to access the provenance key information in compliance with SLSA specifications.

The end result is that attackers cannot tamper with the build process.

Verify a SLSA attestation and Enforce Governance Policies

SLSA attestations should be verified in either the build stage or deploy stage, and then be subject to policies that permit or deny the use of the artifact based on whether or not the artifact’s provenance meets your criteria. For example, you may only want to allow the deployment of software artifacts from a specific build repository and branch. When the pipeline runs, the authenticity of the SLSA attestation will be verified, along with the provenance data within it.

Learn More About How Harness Software Supply Chain Assurance Allows You To Govern Artifact Promotion Based On SLSA.

Contact a Harness expert

Get a demo

‍

Last month, we rolled out a set of built-in security scanners for Harness STO for the purpose of creating an easy on-ramp to shift-left security, whereby users can add a preconfigured scan step that's ready to run with just one click. Our default choice for Static Application Security Test (SAST) scanning within that set is Semgrep.

Semgrep is an application security platform that helps automate and manage SAST, supply chain, and secrets scanning at scale. We’re excited to announce that we’ve partnered with Semgrep through the integration of Semgrep Code and Semgrep’s open source SAST with Harness STO!

‍

‍

‍

‍

‍

Given our goal of simplifying shift-left security for users, we have now enabled native orchestration of the Semgrep Open Source and Semgrep Code SAST scanners. Harness STO users can scan a code repository and ingest the results with little to no manual configuration. STO then normalizes, deduplicates, and prioritizes the vulnerabilities, providing developers with AI-based remediation guidance.

Harness STO users can get started with Semgrep Open Source and then seamlessly upgrade to Semgrep Code for SAST scanning by providing the access token in the configuration. This upgrade brings additional analysis capabilities and code coverage through interfile analysis and Pro rules, resulting in more true positive findings and fewer false positives.

“We’re thrilled to partner with Harness to enable easy access and configurability of Semgrep’s products from the Harness STO module's interface”, said Luke O’Malley, Chief Product Officer.  “Joint customers will accelerate time to value when deploying Semgrep’s products, especially in complex hybrid environments.” 

Want to learn more about how Harness STO and Semgrep help you shift security left? Visit the STO product page or sign up for a demo with one of our experts!

Request a demo

Harness STO module now integrates Wiz for IaC, SAST, Secret Detection, Container, and SCA scans

The Harness team is excited to announce our new partnership with industry-leading cloud security provider Wiz! Harness became the first CI/CD platform vendor to partner with Wiz.

Through the Harness Security Testing Orchestration (STO) module, the Wiz scanner can be easily added as a step– natively– in your pipeline. 

‍

‍

‍

‍

What does this mean for you? With the integration of Wiz into Harness STO, you can:

• Detect secrets, identify misconfigurations and vulnerabilities as part of developers’ pull requests
• Reduce alert fatigue by deduplicating and prioritizing vulnerabilities
• Block pipeline based on vulnerability severity provided by Wiz
• Auto remediate vulnerabilities using Harness AIDA (AI Developer Assistant)

‍

‍

“Harness’s platform approach to shifting security left and its integration of Wiz demonstrates that detecting and remediating vulnerabilities can be done in a developer-friendly manner ,” said Oron Noah, Head of Product Extensibility & Partnerships at Wiz. “We’re thrilled to have Harness as our first certified CI/CD platform partner in the Wiz partner ecosystem.”

Want to learn more about how Harness STO helps you shift security left? Visit the STO product page or sign up for a demo with one of our experts!

Achieving SLSA Level 3 is crucial for software producers to ensure their build and delivery process is tamper-proof and safeguarded against supply chain attacks. In this blog post, we will explore SLSA, its various levels, and how you can efficiently achieve SLSA Level-3 compliance using Harness Continuous Integration (CI) and Supply Chain Security (SCS) modules.

Introduction

The rise of software supply chain attacks, including notable incidents like SolarWinds and Codecov, underscores the critical risks throughout the software delivery ecosystem. These attacks demonstrate the potential to compromise software integrity at any stage of the software delivery process, resulting in severe and costly consequences for software producers, consumers, and users alike. For instance, the SolarWinds attack disrupted operations for government agencies and many Fortune 500 companies, resulting in substantial financial costs. 

‍

In response to a growing number of software supply chain threats, the Software Supply Chain Levels for Software Artifacts or SLSA (pronounced "salsa”) was defined. SLSA is a security framework originally developed by Google to protect the integrity of software artifacts throughout their lifecycle; it is a means of evaluating the trustworthiness of a software artifact.  In 2021, stewardship of SLSA transitioned to the Open Source Security Foundation (OpenSSF). SLSA is set up as a sequence of levels, each increasing the security of the software supply chain. This approach assures that the software is protected from tampering and can be confidently traced back to its original source.

Why is SLSA so important?

• Mitigates supply chain attacks: SLSA helps prevent unauthorized alterations and ensures software integrity from development to delivery.
• Builds trust with consumers: By adhering to SLSA, producers can assure customers that their software is secure and trustworthy.
• Enhances software transparency: SLSA’s guidelines improve traceability, allowing software to be confidently traced back to its source.
• Enables compliance with EO 14028: Aligning with SLSA helps meet some of the requirements of Executive Order 14028 on improving the nation's cybersecurity.
• Proactive defense strategy: Adopting SLSA is a proactive step towards protecting against emerging threats targeting the software supply chains. 

Achieve SLSA Levels with Harness SCS

Harness SCS ensures the artifact integrity by enabling customers to meet all SLSA levels(L1, L2, L3) in the build track. Let's dive into the details of each level, its requirements, and how Harness SCS helps you achieve them

Build L1 - Provenance shows how the package was built

SLSA Requirements:

• Software producer follows a consistent build process so that others can form expectations about what a “correct” build looks like.
• Provenance exists, describing how the artifact was built, including the build platform, build process, and top-level inputs.
• Software producer distributes provenance to consumers, preferably using a convention determined by the package ecosystem.

Achieving SLSA-L1 compliance with Harness SCS:

The Harness SCS module automatically generates detailed provenance, which outlines the build platform, process, and top-level inputs involved in creating the artifact. This provenance can be downloaded or distributed as needed. To explore this feature, please refer to the detailed instructions on generating SLSA provenance.

       (The image shows the Provenance details of the build process in the Harness CI pipeline)

Build L2 - Signed provenance, generated by a hosted build platform

SLSA Requirements:

• Build platform runs on dedicated infrastructure, not an individual’s workstation, and the provenance is tied to that infrastructure through a digital signature.
• Downstream verification of provenance includes validating the authenticity of the provenance.

Achieving SLSA-L2 compliance with Harness SCS:

• Organizations can connect their hosted infrastructure with Harness to execute builds.
• Following the in-toto attestation framework with cosign, Harness digitally signs the generated provenance, ensuring its authenticity and integrity. Refer to generate SLSA provenance for the implementation.
• Downstream systems can verify provenance attestation, validate authenticity, and secure the supply chain against unauthorized changes. To try this out, refer to the Verify SLSA provenance document.

‍

Build L3 - Hardened build platform

SLSA Requirements:

• Prevent runs from influencing one another, even within the same project.
• Prevent secret material used to sign the provenance from being accessible to the user-defined build steps.

Achieving SLSA-L3 with Harness SCS:

• Harness CI Cloud runs each build in an isolated, ephemeral environment that prevents cross-build influence, helps you achieve SLSA L3 v1.2 compliance. Hosted containerized steps operate in a restricted sandbox, ensuring that build processes cannot interfere with or influence each other.
• If you run your Harness pipelines on your own Kubernetes cluster or VMs as the infra, you can technically achieve SLSA Level 3, but only if you enforce stronger isolation controls across the build environment and the cluster.

Here’s a complete overview of the process.

‍

Conclusion

With Harness SCS, organizations can achieve SLSA Level 3 compliance, fulfilling all of the prescriptive requirements as outlined in the SLSA v1.2 specification. This ensures that tampering by hackers during the build process is effectively prevented. When this capability is combined with open-source governance through SBOM (Software Bill of Materials), it results in the most advanced platform-based shift-left supply chain security solutions available today.

Read more: What is Continuous Software Compliance?

‍

XZ Backdoor Attack Overview

Package: XZ Utils (includes liblzma library)

Vulnerable versions:  5.6.0 and 5.6.1

Common Users: Most Linux distributions

Incident Date: March 29th, 2024 (discovered)

CVE: CVE-2024-3094

The Attack

On March 29th 2024, a critical vulnerability was discovered in XZ Utils, a widely used software utility on Linux systems. In specific cases, this critical flaw involved malicious code designed to grant unauthorized remote access via SSH. Fortunately, the issue was limited to the most recent versions, 5.6.0 and 5.6.1. The project's GitHub repository has been suspended due to the severity of the breach.

XZ compromise at a glance

1. Modifying the Build Process: The attackers snuck malicious code into the project's GitHub repository through a modified build script. This script wasn't present in the official release files.
2. Triggering Script: Specific test files within the project triggered the malicious script during the build process, injecting the backdoor code.
3. Exploiting glibc: The attackers took advantage of a mechanism called IFUNC in glibc to manipulate OpenSSH's authentication routines at runtime. This potentially allowed them to bypass authentication and gain control of affected systems.

While research continues, the above approach to compromise is thoroughly documented and detailed by Andres Freund and thesamesam/xz-backdoor.md.

Who is Affected by CVE-2024-3094

Repology's analysis indicates a significant number of Linux distributions could be at risk due to CVE-2024-3094. Here are a few linux distributions that announced their status and patch requirements.

• Fedora 41 and Rawhide distributions contain identified vulnerable packages. Red Hat urges users to stop using these immediately for security reasons. 
• In Debian's Testing, Unstable, and Experimental versions, vulnerable packages have been found. Although stable releases remain secure, users in these distributions should promptly update their xz-utils packages. 
• Kali Linux users who updated their system from March 26th to March 29th are at risk. Immediate updates are necessary for these installations, while those not updated before March 26th are safe.
• For openSUSE, SUSE has confirmed the vulnerability and released updates. Users should urgently apply these to ensure their system's safety. 
• For Alpine, edge (active development) branch is affected and needs an update to the latest version - 5.6.1-r2.

The vulnerable version of the XZ package, implicated in security concerns, was not found in several Linux distributions, including Amazon Linux, Ubuntu, and RHEL, among others.

How to Remediate CVE-2024-3094 using Harness Software Supply Chain Assurance (SSCA)

The primary defense against CVE-2024-3094 is to downgrade XZ Utils to the earlier version as soon as possible. Use your distribution's package manager to update your system immediately, making sure you are not using XZ 5.6.0 or 5.6.1

For you to perform the update immediately, you might need to identify affected deployments and configure your build system to block vulnerable packages, and track the progress of patching effectively.

This is where Harness SSCA comes in handy. Here's how Harness can help you take immediate action and respond effectively:

• Search for XZ utils in vulnerable artifacts: Harness SSCA leverages Software Bill of Materials (SBOMs) to pinpoint deployments using vulnerable XZ versions.
• Block Build Pipelines: Implement policies within your Build process to block the inclusion of vulnerable XZ versions.
• Track in existing deployed environments: Once vulnerable artifacts are identified, the Remediation Tracker within SSCA swiftly locates the deployments affected by these vulnerabilities. This streamlines the patching process by providing a clear list of deployments that require immediate attention.

Using Harness SSCA to Search for XZ Utils in your Artifacts

In events like these, when vulnerability scanners may lag in updating their databases, a Software Bill of Materials (SBOM) becomes an invaluable tool. SBOM provides a comprehensive inventory of every component within your software, detailing everything from its origins to the current package version. Having the capability to quickly review the SBOMs for all your software and accurately identify affected container images significantly enhances the efficiency and effectiveness of your response. 

The Artifact view in Harness SSCA can help you here to rightly point out all the artifacts that are using the XZ 5.6.0 or 5.6.1.

‍

Blocking XZ 5.6.0/1 Using Harness SSCA in Build Pipelines

Remediating vulnerable deployments is crucial, but preventing future occurrences is equally important. Here's how you can leverage Harness SSCA policies to strengthen your build process:

• Block Vulnerable Versions: Add specific vulnerable versions, such as XZ 5.6.0 and 5.6.1, to a deny list within your SSCA policy.
• Enforce Policy on Build SBOMs: This policy will be enforced against the Software Bill of Materials (SBOM) generated during the build process.
• Pipeline Block on Violations: If the build process attempts to use a blacklisted version, the pipeline will be blocked, preventing the deployment of vulnerable software.

By implementing these steps, you can ensure that your build process automatically flags and prevents the inclusion of known vulnerable components. This proactive approach significantly reduces the risk of pushing out vulnerable software.

Tracking XZ utils using Remediation Tracker in existing deployed environments for patching

Once you've identified vulnerable artifacts, the next step is to pinpoint the environments where they're deployed. This is where the Harness Remediation Tracker shines.

Remediation Tracker in Harness SSCA simplifies this process by leveraging defined remediation rules. Simply provide details of the affected component, and the tracker efficiently pulls out all deployments using that component. Additionally the integration with Jira enables you to swiftly initiate the patching process across all impacted environments. To learn more about the tracker creation, refer to the documentation on creating a remediation tracker

‍

‍

Furthermore, upon selecting an artifact the tracker fetches all the deployments that are affected by the vulnerability.

‍

Conclusion

As software supply chain attacks become more prevalent, securing your software delivery process is paramount. Harness SSCA empowers you to proactively combat these attacks. Leveraging SBOMs, SSCA pinpoints vulnerable artifacts within your deployments.  Furthermore, it efficiently tracks impacted deployments and enforces policies to block these vulnerable components.  This comprehensive approach grants you crucial visibility, streamlines remediation efforts, and ultimately safeguards the integrity of your software supply chain.

Introduction

In a software-centric world, the Software Bill of Materials (SBOM) has become more than just a best practice—it's a necessity. With the rising prominence of open-source software and increasing threats from software supply chain attacks, an SBOM provides a critical layer of transparency and security. The significance of SBOMs has been further underlined by Executive Order 14028, pushing it to the forefront of cybersecurity discussions. In this blog post, we'll delve into the concept of an SBOM, its various formats, the implications of Executive Order 14028, and how the Software Supply Chain Assurance (SSCA) module can help manage the SBOM lifecycle.

What is an SBOM?

An SBOM is a detailed, machine-readable inventory of all libraries, modules, and dependencies involved in building a software product. It records essential information such as component names, component versions, supplier, and licenses for every component used in the software. An SBOM offers valuable transparency into the software's anatomy, ensuring both traceability and security.

Importance of SBOMs

1. Transparency: Provides full visibility into the components in use and their metadata.
2. Compliance: Ensures adherence to Executing Order 14028 and to licensing requirements
3. Security: Enables swift response to new vulnerabilities by precisely identifying impacted components.

SBOM Formats: CycloneDX and SPDX

Different industry standards have emerged for creating SBOMs, with CycloneDX and Software Package Data Exchange (SPDX) being the most prominent.

• CycloneDX is a lightweight software bill of materials (SBOM) standard designed by OWASP for use in application security contexts and supply chain component analysis.
• Software Package Data Exchange (SPDX)  is an open standard by The Linux Foundation for communicating software bill of materials information, including provenance, license, security, and other related information.

Executive Order 14028

Issued by President Biden in May 2021, Executive Order 14028 aims to bolster the nation's cybersecurity infrastructure. A key focus of this order is enhancing software supply chain security, and SBOMs have been highlighted as a critical tool in this context. The order has accelerated the adoption and standardization of SBOMs, pushing organizations to implement robust SBOM management practices.

How SSCA Can Help

SBOM Orchestration and Management

The Software Supply Chain Assurance (SSCA) module offers customers the flexibility to use their preferred tools for generating Software Bill of Materials (SBOM) in both CycloneDX and SPDX formats with every build. Moreover, it empowers users to sign and attest SBOMs using their private keys, ensuring secure storage and sharing with software consumers.

Comprehensive Visibility

The SSCA module offers deep visibility into the usage of every open-source component across all artifacts and their deployments.

Policy Enforcement

SSCA provides advanced policy management capabilities based on attributes like Component name and version, Supplier, License, and PURL:

• Allow Lists: Allow components based on a pre-approved criteria to reduce risk and exposure
• Deny List: Block components that pose any security or legal risk

CI/CD Integration

SSCA seamlessly fits into existing CI/CD pipelines, offering a flexible and integrated approach to SBOM management.

Conclusion

The strategic importance of managing the SBOM lifecycle cannot be overstated, especially in light of heightened cybersecurity threats and new regulations like Executive Order 14028. With its rich feature set, SSCA serves as a comprehensive solution for managing SBOMs in both CycloneDX and SPDX formats. From policy enforcement to lifecycle management and tracking, SSCA has got you covered. Take control of your software supply chain today with SSCA!

In the relatively short time since we announced the availability of our Software Supply Chain Assurance (SSCA) module, we’ve been hard at work broadening our feature set in ways that enhance customers’ ability to decisively remediate zero-day vulnerabilities with speed, and enable them to generate and manage higher quality software bills of materials (SBOMs). In this brief product update blog, we’ll have a closer look at our set newly-released SSCA features: SBOM scoring, SBOM drift detection, and real-time remediation tracking.

Real-time Zero-day Remediation Tracking

Because modern applications and their software supply chains are an increasingly desirable target of cyber attackers, it is imperative to be ready and able to harden an application upon discovery of a zero day vulnerability before that vulnerability can be exploited. But this is a highly complicated undertaking given the complexity of modern application code bases and the myriad of dependencies within them.

‍

To solve these challenges, Harness SSCA now features real-time remediation tracking, giving security practitioners and developers a set of powerful tools for rapidly and decisively remediating zero-day vulnerabilities– a huge advantage for mitigating security and compliance risk.

‍

FIGURE 1: Harness SSCA Remediation Tracking

‍

Artifact Enumeration

The Remediation Tracker simplifies the process of identifying vulnerable components across software deployments. By providing the component/dependency details, the tracker conducts a comprehensive scan of all artifacts. It efficiently lists down the artifacts utilizing the given component, offering a quick and accurate overview of the affected artifacts within the codebase.

Environment Visibility

The tracker goes beyond artifact enumeration to provide insights into the deployment environments impacted by the identified vulnerabilities. Once the affected artifacts are listed, the tracker offers visibility into all environments where these artifacts are deployed. This feature ensures a comprehensive understanding of the scope and reach of the vulnerabilities across various deployment environments.

Deployment Pipeline Tracing

In addition to artifact and environment details, the tracker brings transparency to the deployment pipelines associated with the identified artifacts. By attaching the environments, the tracker goes a step further to include all tied deployment pipelines used for the deployment of affected artifacts. This tracing capability allows users to navigate and take necessary actions across the entire development cycle, ensuring a holistic remediation approach.

Artifact Exclusion Mechanism

The Remediation Tracker offers a granular approach to remediation by allowing users to exclude selected artifacts from the remediation process. This mechanism ensures flexibility in the process with more control.

Deployment Status Overview

Users can easily track the overall status of remediation efforts through the tracker. It provides a clear snapshot of the number of deployments pending action and the successful deployments where remediation has been completed.

‍

These key features collectively empower organizations to swiftly and effectively address vulnerabilities in their software supply chain, ensuring a proactive and robust approach to software supply chain security.

Analysis and Summary

The tracker provides a quick summary for a concise overview of the overall remediation progress across artifacts. This summary includes informative charts that present key metrics such as the "Mean Time to Remediate," an overview of the "Remediation Status," and a snapshot of "Pending Remediations.”

Integration Capabilities

Streamlining collaboration, the tracker integrates seamlessly with Jira, enabling the creation of tickets directly from the tracker. This integration facilitates efficient communication and task management. Users can raise Jira tickets directly from the tracker, ensuring a synchronized workflow between remediation efforts and project management tools. Looking ahead, the tracker will expand its support for various project management softwares.

‍

SBOM Scoring

There is a growing necessity to have a detailed account of an application’s components and dependencies, and the Software Bill of Materials (SBOM) has become an essential element of software supply chain security. However, the wide variation in the type and completeness of information captured in a typical SBOM makes it difficult to reliably improve supply chain security and reduce risk. According to a recent IEEE study on SBOMs, only one percent of the generated SBOMs contain the NTIA “minimum elements” data for all reported components. 

‍

Given how SBOMs are commonly deficient in a variety of different ways, Harness now offers customers and users the ability to assess SBOM quality and automatically assign it an overall quality score from 1 to 10. This pays dividends for mitigating software vulnerability risks, as an SBOM can be marked as high quality, compliant, and ready to share, or it can be identified as needing improvement or further investigation on the part of DevSecOps teams. SBOM scoring is also a valuable means for software-producing organizations to determine which SBOM tools are best suited to their needs.

Harness SSCA SBOM Scoring Criteria

The evaluation criteria for scoring SBOM quality falls into these categories:

‍

• NTIA-Minimum-Elements: Assesses compliance with NTIA minimum element guidelines
• Structural: Checks adherence to underlying specifications of SPDX or CycloneDX
• Semantic: Evaluates the correctness of SBOM field meanings specific to their standard
• Quality: Determines the overall data quality present in the SBOM
• Sharing: Assesses the SBOM's readiness for sharing

‍

Harness SSCA uses the sbomqs tool to evaluate SBOMs across the above categories and assign a score, upon generating the SBOM in the first place. Overall scores are shown alongside the SBOM within the ‘Pipeline Execution’ view, and can be expanded to show the individual score per evaluation criteria 

listed above.

‍

FIGURE 2: Harness SSCA SBOM Score Report

Automated SBOM Drift Detection

As some software artifacts often change– sometimes with each successive build– it’s expected that that artifact’s SBOM changes accordingly. SBOM drift– if left unchecked– puts organizations at risk of missing newly introduced vulnerabilities or falling out of compliance with licensing and security policies.

‍

Harness SSCA now offers users SBOM drift detection capabilities for tracking changes between successive versions of an artifact, or between the artifact’s latest version and a pre-established baseline. SSCA provides a detailed analysis highlighting the addition or removal of components and licenses, which greatly improves management and oversight of software artifacts. Customers can also create policies to manually review and approve any changes before moving to production. The SSCA module’s SBOM drift detection supports both images and code repositories.

‍

FIGURE 3: Harness SSCA SBOM Drift Report

‍

Software Supply Chain Assurance, the Harness Way

More and more enterprise organizations are taking a platform approach to building out their DevSecOps practices, and a big reason why customers come to Harness is the seamless integration of critical security capabilities such as Security Testing Orchestration (STO). Harness SSCA follows suit, delivering powerful OSS governance and SLSA compliance features, along with SBOM scoring, drift detection, and real-time remediation of zero-day vulnerabilities.

To learn more about Harness SSCA and its expanded feature set, visit Harness Software Supply Chain Assurance

Request a demo

Contact a Harness expert

‍

If you’ve instituted a shift-left security approach where application developers are handily remediating code vulnerabilities without last-minute toil, your DevSecOps practice is off to a great start. But like the vast majority of organizations building modern applications, your company’s software probably comprises a variety of open-source artifacts and other third-party components whose integrity the company is on the hook to ensure. Why? Look no further than the Solarwinds, Log4j, and Codecov breaches to see that a single, compromised artifact can wreak havoc for tens or hundreds of thousands of the software’s consumers. For the purpose of preventing these types of destructive cyberattacks, a ubiquitous framework for hardening the software supply chain is required. 

Executive Order 14028 was issued for the purpose of strengthening the United States’ cybersecurity posture and requires organizations to implement safe development practices and maintain greater visibility into their software and its artifacts. EO 14028 has accelerated the adoption and standardization of Software Bills of Material (SBOMs) as a means of accounting for and ensuring the integrity of an application and all of its artifacts. The SBOM provides a critical layer of transparency and security, and its lifecycle management is a vital capability of a successful DevSecOps program. To comply with EO 14028, organizations need to adopt a framework like SLSA that aligns with NIST recommended SSDF to ensure artifact integrity, and generate SBOMs.

Introducing Harness Software Supply Chain Assurance (SSCA)

Building on the integrated, platform approach to DevSecOps that the majority of software-producing organizations are seeking, we're excited to introduce Harness SSCA today at Unscripted!

Harness SSCA extends application security beyond your own application code to the whole supply chain, enabling you to monitor and control open source software components and third-party artifacts, generate comprehensive SBOMs for enhanced visibility, and guarantee software integrity in accordance with SLSA and Executive Order 14028 requirements.

Here’s an overview of the SSCA module’s key capabilities:

Software Integrity based on SLSA

Supply-chain Levels for Software Artifacts (SLSA) is an important framework for creating a secure software supply chain. It lays out practices and guidelines to help you securely build your software and prove that it is not tampered with as it moves through different stages of your pipeline. Harness SSCA ensures the integrity of software by generating and validating the provenance (such as build source, branch, etc.) as per SLSA v1.0 specifications.

SBOM Orchestration and Lifecycle Management

The SSCA module offers users the flexibility to select their preferred tools for generating SBOMs in both CycloneDX and SPDX formats. Moreover, it empowers users to sign and validate SBOMs using their private keys, ensuring secure storage and sharing with software consumers.

Visibility and Control Of Open Source Software

With approximately 80% of a typical software application relying on open source software, the SSCA module offers deep visibility into the usage of open source components across all artifacts and their deployments. Further, it enables users to enforce policies by granting or restricting the use of components based on their versions, license, suppliers, and PURL.

A Look At Harness SSCA

Let’s take a brief tour of Harness SSCA. We’ll step through some of the workflows DevOps engineers and security analysts would undertake in generating SLSA provenance and SBOMs, verifying SLSA provenance, and enforcing policies to ensure that any risky open source software artifacts do not pass through to the deployment.

‍

Guaranteeing that your application maintains its integrity throughout its journey through the pipeline begins with enabling SLSA.

SLSA Generation And Attestation 

With the Harness SSCA module, you can achieve SLSA Level 2 compliance by generating SLSA provenance according to the SLSA v1.0 specification. While SLSA level 1 stipulates that provenance exists, showing how a particular software package was built (what entity built the package, what build process they used, and what the top-level input to the build were), SLSA level 2 adds the requirement that the particular build runs on a hosted build platform that generates and signs the provenance itself. 

In generating SLSA provenance within the build pipeline, you need to first generate a key pair using Cosign, as shown in the screenshot below.

SBOM Orchestration And Generation

A Software Bill of Materials (SBOM) is essential for understanding the components and dependencies within an application, which in turn enables your organization to manage open-source component risks effectively.

The Harness SSCA module generates, manages, and analyzes SBOMs for software artifacts. Below is the SSCA workflow for generating a SBOM:

‍

SSCA supports SPDX and CycloneDX formats for SBOM generation and tools such as Syft and Cosign. When an SBOM is generated, the SSCA module generates and signs the attestation, ensuring that the information is accurate and trustworthy. The attestations are then securely stored in your artifact repository, where you can access and analyze them as needed.

OSS Governance Through Policy

With Harness, you have full control over their use throughout CI and CD stages via the SSCA module’s policy management and enforcement capabilities. As you seek to deploy only compliant artifacts, you can put two types of policies into effect:

• ‍Deny list policies: Define components, or combinations of component attributes, that are not allowed. If an artifact includes a component that is part of the deny list, the artifact's policy evaluation fails.‍

• Allow list policies: Define components or combinations of component attributes that are allowed. If an artifact includes a component that is not part of the allow list, the artifact's policy evaluation fails.

When an artifact moves through your pipelines, the SSCA module checks the artifact and its associated SBOM against your defined policies. Policy violations are tabulated and displayed in detail.

SLSA Verification 

You can use Harness SSCA to verify SLSA provenance using an OPA policy. In the example below, we are ensuring integrity of the application by validating the branch name on which it was built in the deploy

Software Supply Chain Assurance, the Harness Way

More and more enterprise organizations are taking a platform approach to building out their DevSecOps practices, and a big reason why customers come to Harness is the seamless integration of critical security capabilities such as Security Testing Orchestration (STO). Harness SSCA follows suit, delivering powerful OSS governance and SLSA compliance features.

To learn more about Harness SSCA, visit Harness Software Supply Chain Assurance

Interested in seeing Harness SSCA in action? Sign up for a demo!

Contact a Harness expert

Harness Platform Continues to Expand to Address Key Customer Needs in Modern Software Delivery 

San Francisco– Sept 21, 2023– At the {unscripted} conference, Harness, the Modern Software Delivery Platform® company, today announced four new product modules on the Harness platform. Each module is aimed at advancing the state of software delivery and developer experience, and includes Harness Code Repository, Harness Internal Developer Portal, Harness Infrastructure as Code Management, Harness Software Supply Chain Assurance.

Harness Code Repository 

Harness Code Repository is a premium module based on open source Gitness^TM (launched today) and tailored to meet the demands of enterprise teams and organizations. Gitness is a developer-friendly, open source Git platform created to address common obstacles in traditional software development workflows. Read more in the Gitness press release here. Harness Code Repository provides additional enhanced features and capabilities for Gitness, including: 

• Collaborative code reviews to foster collaboration and knowledge sharing, for higher code quality and fewer errors
• Advanced governance with branch protection to ensure stability by preventing unauthorized or risky changes from being merged into critical branches, reducing the chance of introducing bugs or vulnerabilities
• Policy enforcement powered by OPA to ensure code complies with predefined organizational standards and best practices, reducing manual intervention and human error 
• Seamless integrations tailored for the development process on the Harness platform help streamline the development process by connecting code repos with other development and deployment tools to improve efficiency and collaboration, which accelerates  the software delivery pipeline 

Harness Code Repository will be available in beta next month.

Harness Internal Developer Portal (IDP)

With the rapidly emerging trend of Platform Engineering teams who seek to streamline developer experience for their organizations, developer portals are becoming a “must-have” for large engineering organizations. According to Gartner®, “By 2025, 75% of organizations with platform teams will provide self-service developer portals to improve developer experience and accelerate product innovation.” ¹

Answering that demand from Harness customers, the Harness Internal Developer Portal (IDP) helps organizations accelerate new service onboarding, simplifying the often complex and time-consuming process of setting up infrastructure, configuring frameworks, establishing CI/CD pipelines, and more. Harness IDP is built on the Backstage.io platform, providing critical governance features out of the box and a simplified management experience. 

Harness IDP includes:

• Self-service automation enables developers to create new services quickly, eliminating up to days or weeks of waiting time 
• The Software Catalog unifies essential service information, such as builds, deployments, alerts, and health metrics, into a single pane of glass called the Software Catalog 
• Discoverability of tools enhances collaboration and communication within organizations by providing easy discoverability of internal services, APIs, and tools, which helps prevent duplication of efforts and enables efficient knowledge sharing 
• Scorecards enable platform engineers to gauge service maturity and encourage the adoption of best practices from DevOps, development, and security perspectives—effectively gamifying the quest for excellence in software development 

The result is that developers spend less time being blocked and more time innovating. Visit harness.io/products/internal-developer-portal to learn more.

Harness Infrastructure as Code Management (IaCM)

Companies are using Infrastructure as Code (IaC) to define infrastructure requirements, configurations, and dependencies, and to manage resources in a more efficient and repeatable way. However, customers are still finding that most IaC solutions are labor intensive, create errors, and come with limited visibility and guardrails. Harness Infrastructure as Code Management (IaCM) addresses these challenges and adds automation and security.

Harness IaCM provides:

• An advanced pipeline for IaC automation, simplifying code management from Pull Request (PR) to provisioning. Streamlining the process speeds up the creation, testing, review, and deployment of infrastructure changes, significantly improving efficiency
• Automatic drift detection and remediation continuously monitors the infrastructure for deviations, ensuring all changes are done in the right process 
• OPA-based infrastructure policies to enforce security and compliance standards. These policies, defined as code, are applied automatically during the provisioning process, reducing the risk of misconfigurations and vulnerabilities 
• Provides the PR process for reviewing infrastructure changes, making it more efficient and error-resistant by allowing developers to understand the impact of their changes before merging the code 

Harness IaCM helps organizations achieve the benefits of self-service infrastructure management, mitigate risks associated with manual processes, and optimize operational efficiency, resulting in more secure, compliant, and efficient infrastructure management. Get started with Harness IaCM today at harness.io/products/infrastructure-as-code-management. 

Harness Software Supply Chain Assurance

Modern applications are being built with an exponentially growing number of open source components, each of which introduces new vulnerabilities that can put the application’s consumers at risk. For these reasons, the software supply chain has become the focus of cyberattacks that are increasing in both number and sophistication. According to Gartner, “By 2025, 45% of organizations worldwide will have experienced attacks on their software supply chains, a three-fold increase from 2021.” ²

Recent supply chain attacks, such as log4j and SolarWinds, underscore the importance of open source governance and ensuring software artifact integrity in alignment with standards like Supply Chain Levels for Software Artifacts (SLSA). In the United States, Executive Order 14028 mandates SBOMs, provenance verification, policy enforcement, and rapid zero-day vulnerability response to enhance supply chain security. 

The Harness Software Supply Chain Assurance (SSCA) module comprehensively addresses these requirements by providing:

• Deep visibility and control over open source software components, allowing organizations to monitor and enforce policies based on component versions, licenses, suppliers, and more
• Streamlines the generation of SBOMs in various formats, enabling secure sharing and storage. Users can sign and validate SBOMs with their private keys 
• Enables governance by setting up policies to block harmful or risky components, such as log4j, in an organization’s supply chain 
• Ensures software integrity by generating and verifying attestations, following SLSA specifications and mandates listed in Executive Order 14028 
• Strengthens software development with DevSecOps practices, further letting software producers effectively ship secure software artifacts to their consumers 

Learn more about Harness SSCA at harness.io/products/software-supply-chain-assurance.

"The four new modules we are launching today represent a significant leap forward on our mission to enhance efficiency, foster collaboration, and fortify security throughout the software delivery lifecycle,” said Jyoti Bansal, CEO and cofounder of Harness. “These new innovations are the latest way we are providing developers and organizations with the tools and capabilities to help them achieve their software development goals.”

Harness additionally announced two new industry-wide communities:

• FinOps Excellence: A community-driven initiative to bring together leaders working in cloud cost management globally. This initiative provides a forum for leaders working on managing cloud cost initiatives within their organizations to come together and collaborate to discuss challenges and exchange best practices. Controlling cloud costs is a developer-led initiative, and Harness is at a unique position to drive and facilitate conversations where “efficient” software delivery is key. In the last few months, a growing cohort of experts from some of the largest banks, consumer/retail, telecom, IT, and insurance companies have met to further the conversations about cloud cost efficiency. You can learn more or request an invitation at linkedin.com/company/finops-excellence.

• Engineering Excellence Collective™: An industry-wide consortium of 300 senior engineering leaders working together to solve some of the most pressing challenges in the industry. Read more in the press release here.

¹ Gartner, Innovation Insight for Internal Developer Portals, By Manjunath Bhat, Mark O’Neill, Oleksandr Matvitskyy, Published 1 February 2022. 

²Gartner, Emerging Tech: A Software Bill of Materials Is Critical to Software Supply Chain Management by Mark Driver, Published 6 September 2022. 

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

About Harness

Harness is the leading end-to-end platform for complete software delivery. It provides a simple, safe, and secure way for engineering and DevOps teams to release applications into production. Harness uses machine learning to detect the quality of deployments and automatically roll back failed ones, saving time and reducing the need for custom scripting and manual oversight, giving engineers their weekends back. Harness is based in San Francisco. Please visit www.harness.io to learn more.

Learn about Targeting Rule

The Convergence of DevOps and GenAI

The DevOps ecosystem is continuously evolving, and the infusion of GenAI is the latest milestone in this journey. As the software delivery landscape expands, the role of GenAI becomes increasingly pivotal, offering efficient, secure, and innovative solutions.

GenAI, or Generative Artificial Intelligence, represents the next frontier in computing, where machines can perform intellectual tasks. By integrating GenAI into DevOps, we're not just automating processes but introducing intelligent decision-making into the software delivery lifecycle.

Harness AI and Harness Security Testing Orchestration: Beyond Traditional Software Delivery

Harness AI and Harness STO (Security Testing Orchestration) are not just tools; they are transformative solutions that redefine the boundaries of software delivery. 

Harness AI can automatically identify security vulnerabilities and generate code fixes. Trained on all publicly known Common Vulnerabilities and Exposures (CVEs) and Common Weakness Enumerations (CWEs), Harness AI significantly accelerates vulnerability remediation, reducing developer effort by 50-75%. Harness AI seamlessly integrates with the Harness Security Testing Orchestration module.

The combination of these tools ensures that software delivery is fast and secure, meeting modern enterprises' high standards.

Why GenAI Matters in DevOps

In today's rapidly evolving tech landscape, AI-powered tools are becoming indispensable for businesses striving for excellence. Harness AI stands at the forefront of this transformation, addressing three critical pillars of modern software delivery: efficiency, security, and innovation. Here's how:

Efficiency: GenAI automates repetitive tasks, streamlining processes and ensuring faster software delivery. GenAI can preemptively address potential bottlenecks by understanding patterns and making predictions, providing a smooth delivery process.

Security: With AI-driven insights, potential vulnerabilities can be identified and addressed proactively rather than sitting on a backlog of work that needs to be prioritized and assessed.

Innovation: GenAI opens the door to continuous learning and improvement. Analyzing past outcomes can suggest improvement areas, ensuring that software delivery solutions are always ahead of the curve.

The Role of Google Vertex AI in Harness Security Testing Orchestration

Google Vertex AI is a managed machine learning platform that offers everything you need to build and use generative AI—from AI solutions, to Search and Conversation, to 100+ foundation models, to a unified AI platform. It seamlessly integrates tools for the entire machine learning workflow, from data labeling and model training to deployment and monitoring. This unified platform simplifies the ML process, catering to both experienced data scientists and newcomers to the field.

Harness's collaboration with Google and the use of Vertex AI for the STO use case signifies a commitment to excellence. Google Vertex AI, known for its advanced machine learning capabilities, enhances STO's ability to address vulnerabilities precisely. This collaboration ensures that STO is efficient and accurate, providing users with unparalleled security in software delivery.

Looking Ahead: The Future of DevOps with GenAI

The integration of GenAI in DevOps, exemplified by tools like Harness Harness AI & Harness Security Testing Orchestration, marks the beginning of a new chapter in software delivery. It's about embracing the potential of AI, leveraging the best tools available, and delivering unparalleled value to users. The role of GenAI in shaping the future of software delivery will become even more pronounced, setting new standards of excellence in the industry.

Are you intrigued by the transformative power of GenAI in DevOps? Request a demo of our Security Test Orchestration (STO) and explore the capabilities of Harness AI in a dynamic software delivery landscape.

Check out our Harness YouTube channel to see the product in action!

Harness AI to Explain and Fix Vulnerabilities (YouTube video)

Read more: It takes Generative AI to test Generative AI, Secure Software Delivery Pipelines