I often refer to civilian DevSecOps practitioners working on critical infrastructure programs as the “Defender Force.” We live in an era where they are more important than ever. Through critical infrastructure, the Homeland has become vulnerable to assault from our adversaries via cyber attacks. For those of you reading this who are unfamiliar with critical infrastructure, the Cybersecurity and Information Agency (CISA) defines 16 critical infrastructure sectors which are overwhelmingly privately owned in the USA.
As of late, these exact same adversaries have been targeting the software supply chain. This means that it’s now critical for DevSecOps practitioners of all roles and skill levels to have access to relevant knowledge and guidance in order to provide the best levels of protection possible.
However, even the highest levels of knowledge and guidance are useless without the platforms necessary to put those skills to use as nation-states and syndicates continue mounting offensive operations.
At Sonatype, we provide a platform that serves as a force multiplier to the Defender Force, securing the software supply chain. Capabilities available in Sonatype’s Nexus platform include:
- Nexus Repository Manager
- Nexus Firewall
- Nexus Lifecycle
In August 2022, the Cybersecurity and Information Security Agency (CISA), the Office of the Director of National Intelligence (ODNI), and the National Security Agency (NSA) released “Securing the Software Supply Chain: Recommended Practices Guide for Developers.” This document acts as an extension of CISA’s work in support of Executive Order 14028.
In Part 1 of this series, we will walk through the diagram labeled figure 3, found on page 15 of the original document, and explain in more detail how Sonatype’s Nexus Platform helps avert these attempts to undermine the security of the software supply chain. We will define the capabilities in the form of use cases, corresponding to the numbers from the diagram in purple.
Use Case #1
A developer has been perusing the npm public open source repository and notices a new open source component that may be useful in a project. In the developer’s Visual Studio Code IDE, which is configured with the Nexus Lifecycle plug-in, they type in the commands to download the component. (1)
How Sonatype makes the process more secure:
The component gets downloaded to the Nexus Repository proxy repo from the npm public open source repository. The Nexus Firewall AI/ML then flags the component as “suspicious” and places it in “quarantine” in the proxy repo. The developer then receives a message that the component has been placed in quarantine. (2)(3)
Next, Sonatype security analysts inspect the component and find that it is “malicious” and marks it as so in the data model. This means that the policy engine will now automatically quarantine the component if any other developers attempt to download the component in a separate environment.
Use Case #2
A developer decides to download a java OSS component from the public Maven repository using the IntelliJ developer IDE, typing the relevant command in the environment. The OSS component does not violate any security policy configured in Nexus Firewall and slips past to be downloaded to the Nexus Repository Manager proxy repo for use. The java OSS component is then downloaded from the repo to the developer’s filesystem, with the message forwarded as a response to the initial command. (1) (2) (3) (4) (5a)
How Sonatype increases security:
In the IDE, the developer is able to view the SBOM of the current project by using the Nexus Lifecycle plug-in. By clicking on the component, the developer can view the current vulnerability (CVE) posture of the OSS component that was downloaded. (4)
The developer’s branch is merged with the main branch. The nightly build breaks per the Nexus Lifecycle Jenkins plug-in, flagging a policy violation due to a critical CVE recently reported on the OSS component. Stakeholders are messaged as configured and can navigate to the Nexus Lifecycle Component Detail View for situational awareness of License, Security, Quality posture, and version update advice. (4) (5b)
Use Case #3
A release candidate is built into an OCI-compliant container destined for Kubernetes and placed into a Nexus Repository Manager staging repo. Security gate tests pass, and the Jenkins plug-in ensures that the SBOM–the results of the scan of the release candidate–is viewable in Nexus Lifecycle. (4)
How Sonatype helps ensure greater security:
All automated testing passes in the release phase, and a release package is built. The security gate checks also pass here, including a scan for SBOM via Nexus Lifecycle. Next, the release package is placed in the Nexus Repository Manager release repo. Nexus Lifecycle Continuous Monitoring is turned on to provide daily status updates on the SBOM regarding security, license, and quality violations.
On day 4, stakeholders are notified of a new critical CVE reported per a security policy violation. They are able to cut over to the server directly through their notifications to view the SBOM and gain situational awareness on License, Security, Quality posture, and version update advice per OSS component.
Securing the software supply chain is hard work
We hope that this series of blog posts will help DevSecOps practitioners defend critical infrastructure and help their executives understand how to operationalize the US government’s recommendations articulated in the “Secure Repository Process Flow” diagram above. However, these posts are not just for DevSecOps practitioners. We also hope to aid those involved with government policy.
In future additions to this series, we will continue to present the Nexus Platform force multiplier in the context of US government policy and legislation. We have every intention to help arm the Defender Force with the capability to quickly and continuously harden our critical infrastructure as our adversaries are quickly taking advantage of our currently lagging cyber posture.