Blog
Supply Chain Security

Harness enhances software supply chain security with SCS module | Harness Blog

Harness now delivers end-to-end software supply chain security with the SCS module.

TL;DR

The Harness Supply Chain Security (SCS) module is designed to prevent attacks similar to the CodeCov and Solarwinds 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.

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.

FIGURE 1: High-profile Attacks And The Supply Chain Elements They Targeted

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.

FIGURE 2: Three Pillars Of Continuous Supply Chain GRC

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.

FIGURE 3: Harness SCS Module Rule Definitions

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

FIGURE 4: Harness SCS Compliance Dashboard

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.

FIGURE 5: Harness SCS offers detailed guidance for remediating rule violations

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

← Previous:
Next: →

Related Resources

Introducing Harness Supply Chain Security (SCS)

Supply Chain Security

Introducing Harness Supply Chain Security (SCS)

September 21, 2023

Sean Roth

+ more
Time to Read

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 Supply Chain Security (SCS)

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

Harness SCS 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 SCS 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 SCS 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 SCS 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 SCS 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 SCS

Let’s take a brief tour of Harness SCS. 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.

SSCA pipeline showing where SLSA provenance and SBOMs are generated, verified, and secured from code to 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 SCS 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.

Harness pipeline stage settings showing the SLSA Provenance section enabled with a Cosign private key and password

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 SCS module generates, manages, and analyzes SBOMs for software artifacts. Below is the SCS workflow for generating a SBOM:

Harness pipeline interface showing the configuration of a Generate SBOM step using Syft and SPDX format
Harness SCS: SBOM Generation Workflow

SCS supports SPDX and CycloneDX formats for SBOM generation and tools such as Syft and Cosign. When an SBOM is generated, the SCS 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 SCS 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 SCS module checks the artifact and its associated SBOM against your defined policies. Policy violations are tabulated and displayed in detail.

Artifact violation details UI in Harness SCS displaying package names, licenses, and allow list policy violations

SLSA Verification 

You can use Harness SCS 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

Harness SCS Artifacts tab showing a failed SLSA Verification status for an image artifact in the deploy stage

Supply Chain Security, 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 SCS follows suit, delivering powerful OSS governance and SLSA compliance features.

To learn more about Harness SCS, visit Harness Supply Chain Security

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

Contact a Harness expert

XZ Utils CVE-2024-3094: Block and Remediate with Harness SSCA

Supply Chain Security

XZ Utils CVE-2024-3094: Block and Remediate with Harness SSCA

April 1, 2024

Teja Kummarikuntla

+ more
Time to Read

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.

Filtering the Harness SSCA Artifacts view for component 'xz' and version '5.6.0' to list affected container images

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.

__wf_reserved_inherit

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

Harness Remediation Tracker creation form for CVE-2024-3094 and the resulting dashboard showing affected artifacts

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

Deployment Details dashboard showing affected environments and pending remediations for CVE-2024-3094

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.

Get Started

Get Started with Harness AI

Try the full platform free. No module restrictions, no credit card.

Sean Roth
Director, Product Marketing - Security (AppSec / Supply Chain Security)
sean-roth
Sean Roth