How To Put Cloud Nimble to Work to Shift Left Security
Creating a Multi-cloud/Hybrid DMZ for Open Source
Shifting security left means preventing developers from using unacceptably vulnerable software supply chain components as early as possible: before their first build. By helping assure that no build is ever created using packages with known vulnerabilities, this saves substantial remediation costs in advance.
Some JFrog customers restrict the use of open source scanning software (OSS) packages to only those that have been screened and approved by their security team. Under this DevSecOps curation practice, developers are never permitted to use packages directly from external public repositories such as Maven Central or Docker Hub, but must instead draw them from an internal proxy repository that is curated by the security team.
SecOps teams like the way this gives them a security-first way of keeping threats out of every application. Developers like being able to rely on a trusted catalog for their packages. And department leaders love how it speeds software delivery while reducing costs.
How It Works
JFrog’s unique ability to help make your operations cloud nimble — running pipeline segments wherever and however you need them to be hosted – helps enable this trusted catalog strategy.
Let’s look at how several of our customers use the way that JFrog DevOps Platform deployments can interoperate across clouds to build and maintain a front-end DMZ for curation of OSS components across the entire organization.
Creating the DMZ
In this example, the primary JFrog Platform deployment for managing private repositories for production are deployed on servers in the company’s on-premises secure intranet. These on-prem repositories are the “single source of truth” for development and staging of all binaries and builds that will ultimately be deployed into production.
The security team maintains a front-end DMZ for open source – a separate JFrog Platform deployment whose sole purpose is to proxy public repositories such as Maven and DockerHub. This DMZ, curated by the security team, provides the trusted catalog of OSS components.
You can host your DMZ in any cloud. Because it only contains read-only remote repositories that mirror public repositories (and no private intellectual property), security requirements are minimal – the DMZ can safely occupy an open JFrog-managed SaaS cloud account. And because it’s JFrog, you can choose it to be hosted in any of the major cloud service providers (AWS, Google, or Azure).
Curating Repositories
In the DMZ deployment, JFrog Xray performs continuous scans of each remote repository, identifying the known vulnerabilities of every package in the proxies. By setting Xray rules, policies, and watches the security team can help Xray to automatically decide which vulnerabilities are too minor to worry about, or severe enough to demand scrutiny.
Xray can help automate most of these decisions – such as automatically blocking from use any package with a CVE that has a critical threat score – and save the team a great deal of time.
Other vulnerabilities may demand a closer look, and Xray can alert the security team that their examination is needed.
Did You Know?
JFrog’s integrations provide security teams with many ways to amplify alerts from Xray. Whether through ITSM systems (such as PagerDuty or ServiceNow) or collaboration tools (such as Slack or Microsoft Teams), teams can alert each other to act. They may even wish to automatically create Jira issue tickets from Xray to track next steps.
Xray alerts sent to PagerDuty ITSM
Using the Trusted Catalog
Once curated through Xray by the security team, the DMZ JFrog deployment now provides a trusted catalog of open source components that are approved for use throughout the organization.
The on-prem production system can freely pull components from the curated proxy repositories in the DMZ – everything available from there has been deemed sufficiently safe. A VPN connection to the DMZ can help assure a secure connection to protect the production system from malicious attack.
Pulling packages over a VPN, however, imposes significant speed penalties on a build – up to 10 times slower (or more, depending on topology) than from a local repository. For faster build times, the DevOps team can set up remote repositories in the on-prem production JFrog Platform deployment to provide local caches of the DMZ repositories in Artifactory.
When maximum speed for every build is required, the DMZ can instead be configured to automatically push-replicate every new component from its curated repositories to equivalent local repositories in Artifactory on the production system. Under this method, production builds are guaranteed to always have a local version of a trusted component – ones that can’t be easily flushed by Ops teams trying to recover storage space.
Shift Left With Multi-cloud or Hybrid Cloud
Using a DMZ for open source components in this way offers several important benefits:
- Keeps unapproved OSS components out of production builds.
- Isolates production environment from untrusted networks (e.g., the internet).
- Stores approved open source packages as immutable binaries privately.
- Protects against malicious injection attacks made on the public repository.
- JFrog Xray rules, policies, and watches assist the curation process through automation.
When you’re cloud nimble, you can host either your DMZ or your production systems wherever suits you best – in a JFrog-managed cloud account, or in a self-managed system in the cloud or on-prem – and still interoperate between JFrog Platform deployments.
Need to see for yourself how Xray can help you maintain a trusted OSS catalog in Artifactory? Schedule a demo and we’ll show you how.
