In our previous blog post, we delved into the critical role of SLSA in bolstering software supply chain security. Shifting the focus, this post centers on the seamless compatibility between SLSA and Sonatype products, highlighting the powerful synergy that can enhance your software security efforts.
Drawing parallels with food safety guidelines, where the FDA safeguards both producers and consumers, SLSA serves as a comparable framework for the software industry. Similar to ensuring the safety and authenticity of ingredients in the culinary world, SLSA ensures the credibility and integrity of software components in the tech realm.
In essence, SLSA acts as a common language, guiding leaders and teams to elevate software security levels in managing the software supply chain. While acknowledging existing gaps, it plays a crucial role in fortifying software security and managing supply chains.
For those well-versed in the benefits of SLSA, this post will directly explore how Sonatype and our products seamlessly support and extend the goals of SLSA, forming a robust alliance in your software security initiatives.
SLSA + Sonatype: Tackling specific supply chain threats
SLSA can be an extremely valuable tool for helping secure your software supply chain, offering a standardized approach to evaluate and enhance trustworthiness throughout the development and distribution process. Best of all, it works on both sides, providing benefits for producers and consumers by establishing a universal framework for supply chain security.
However, without the support of tooling, much of what SLSA recommends will need to be done manually and likely won't scale for large enterprises. The Sonatype Platform directly addresses a number of the threats identified by SLSA, and in a number of cases, it extends or even provides support for critical threats where SLSA doesn't currently apply.
In the following section, we've outlined specific threat use cases provided by SLSA, along with both the SLSA recommendations and the ways the Sonatype Platform can help.
SLSA use case: Build from modified source (not matching source repository)
In the case of Webmin, the attacker manipulated the build infrastructure to incorporate source files that did not align with the designated source control.
SLSA recommendation: A SLSA-compliant build server would have generated provenance records, disclosing the actual sources utilized. This would have enabled consumers to swiftly identify such unauthorized modifications.
How Sonatype helps:
- Sonatype Nexus Repository: Sonatype Nexus Repository serves as a trusted source for proxying repositories, providing teams with a reliable source of components.
- Component Intelligence: Sonatype employs Advanced Binary Fingerprinting (ABF) to ascertain the components in use, employing methods like source code analysis, dependency tree examination, call flow analysis, and partial matching. This effectively detects components masquerading as others, as well as false InnerSource claims. Additionally, Sonatype's component intelligence encompasses transitive, direct, and InnerSource dependencies, flagging vulnerabilities accordingly. Transitive dependencies are provided with a remediation path through the direct dependencies, including InnerSource projects.
- Sonatype Repository Firewall: Sonatype's component matching capabilities ensure that the component being utilized aligns precisely with the component sourced from the designated repository.
- Sonatype Lifecycle: The Policy Management features within Lifecycle empower the creation of rules grounded in component matching, leveraging Sonatype's proprietary component intelligence. Coupled with seamless integrations with the build server, these policy rules and automated actions act as safeguards, preventing builds based on the presence of non-matching components.
SLSA use case: Use compromised dependency (i.e. A-H, recursively)
A compromised dependency like event-stream was manipulated by an attacker, who added an innocuous version initially and later updated it with malicious behavior, avoiding detection on GitHub.
SLSA recommendation: Applying SLSA recursively to all dependencies would have prevented this attack, as it would have revealed the improper source or builder, indicating a potential security threat.
How Sonatype helps:
- Sonatype Nexus Repository: Sonatype Nexus Repository serves as a trusted source for proxying repositories, providing teams with a reliable source of components.
- Component Intelligence: Sonatype employs behavioral AI to automatically halt suspicious packages, subjecting them to review by their security research team. This prevents vulnerabilities from entering the development pipeline, aligning with security policies.
- Sonatype Repository Firewall: Malicious components are identified and quarantined, while safe ones are permitted to continue through the supply chain. Sonatype has successfully identified over 106,000 malicious packages to date.
- Sonatype Lifecycle: Sonatype employs a quarantine process for potentially malicious components. They are released only after confirmation of safety and reported for public repository removal if deemed unsafe. Over 106,000 malicious packages have been identified and managed using this process.
SLSA use case: Compromise package registry
In scenarios involving attacks on Package Mirrors, a researcher operated mirrors for widely used package registries, potentially serving malicious packages.
SLSA recommendation: Provenance records of the compromised artifacts would have revealed that they were not built as anticipated or sourced from the expected repository, thus flagging them as potential threats.
How Sonatype helps:
- Sonatype Nexus Repository: Employing an artifact repository manager like Sonatype Nexus Repository guarantees that developers retrieve components from verified and trusted sources. This stands in contrast to results from internet searches or web links through alternative methods, which could be more susceptible to compromise.
- Component Intelligence: Sonatype diligently captures the provenance of each component, including details about the initial uploader, the originating repository, and whether the provenance has been verified when using Nexus Repository. Additionally, it can pinpoint which container introduced the vulnerable item.
- Sonatype Repository Firewall: Leveraging Sonatype's component intelligence, malicious packages are intercepted before entering the proxy repository. They are automatically blocked and reported to the public repository for removal. If deemed safe, they are released from quarantine and permitted to proceed through the software supply chain. To date, Sonatype has successfully identified and managed over 106,000 malicious packages.
- Sonatype Lifecycle: In the event of a compromised package, Lifecycle taps into Sonatype's proprietary component intelligence to offer insights across the development lifecycle. If a compromised component attempts to enter the build or release process, automated actions can be configured to prevent the build or release, adding an extra layer of security and assurance.
SLSA use case: Use compromised package
In the case of Browserify typosquatting, the attacker uploaded a malicious package with a name similar to the original.
SLSA recommendation: While SLSA does not directly address this specific type of threat, it underscores the importance of establishing provenance linking back to source control, which can serve as a foundational element for enhancing other security solutions.
How Sonatype helps:
- Component Intelligence: Sonatype diligently captures the provenance of each component, including details about the initial uploader, the originating repository, and whether the provenance has been verified when using Nexus Repository. Additionally, it can pinpoint which container introduced the vulnerable item.
- Sonatype Lifecycle: In the event of a compromised package, Lifecycle leverages Sonatype's proprietary component intelligence to offer insights throughout the software development life cycle (SDLC). Should a compromised component attempt to enter the build or release process, automated actions can be configured to halt the build or release, providing an additional layer of protection.
- Sonatype Repository Firewall: Sonatype's component intelligence ensures that malicious packages are intercepted before entering the proxy repository. They are automatically blocked and reported to the public repository for removal. If deemed safe, they are released from quarantine and allowed to proceed through the software supply chain. Sonatype has effectively identified and managed over 106,000 malicious packages to date.
SLSA use case: Dependency becomes unavailable
A package or its version may be intentionally removed from the repository by the producer without any prior notice, which became the case with Mimemagic. Alternatively, network errors or service outages could temporarily render packages inaccessible.
SLSA recommendation: While SLSA does not directly tackle this threat, it does facilitate and enhance other solutions through provenance linking back to source control.
How Sonatype helps: Repository: Employing an artifact repository manager like Nexus Repository guarantees that developers have access to components required by their builds regardless of any change in external availability (e.g. public repository). This stands in contrast to results from public sources, even an official repository, which could be more susceptible to availability changes.
Written by Jeff Wayman
Currently in his second tour at Sonatype, Jeff is our resident Conduit of Goodness, helping bridge gaps across teams to improve developer relations, content strategy, and brand awareness. In the past, he served and led teams across product management, technical writing, and customer education. When not writing about cybersecurity and open source software, you can find him outside (likely in the humid southeast) enjoying time with his family.