With the increasing number of software supply chain attacks, implementing DevSecOps best practices in a windless environment is necessary. In an effort to secure the internal network of the organization, the trend of separating the internal network from the external is increasing. It is important to create an integrated and disconnected environment from the public internet.
An air gapped solution provides more stringent security requirements, but that’s not enough. 3rd party dependencies used by your software developers, CI processes, and deployment pipelines should also be scanned for security vulnerabilities and license violations!
how Integrating a security vulnerability solution such as JFrog Xray, allows you to protect your air gap environment, and exclude all vulnerable artifacts from use within the internal development environment.
Our previous post showed how, with a little tooling and scripting, you can continue to access your remote dependencies in an air-gapped environment. This post will go through the steps and best practices for protecting your software and maintaining strict security policies in your development environments.
Example Setup: Using an external DMZ
The following setup shows an example solution that uses an external DMZ, with JFrog Xray installed to scan your remote dependencies for vulnerabilities. JFrog Xray is also installed internally, to provide seamless scanning for your software packages, protecting your organization from any potential future vulnerabilities.
Best practice for working with Xray in an air gap solution
-
The interior and DMZ must have Xray installed. Not just the DMZ. This will ensure continuous scanning of your artifacts, insuring them from any new vulnerabilities that may arise in the future for ‘approved’ dependencies.
-
Distinguish between policies and watches configured internally and DMZ; You may have a global policy for resolving dependency in the DMZ, but then for a particular product/release a more stringent approach, in the internal environment.
-
Use the JFrog CLI to update your internal Xray database with the latest intelligence vulnerabilities, in case you are completely out of breath.
-
DB sync should be done automatically, periodically (using a scheduler) and preferably daily.
-
In addition, the sync process (even online) should be monitored regularly to make sure it’s not broken.
-
-
Work in a duplicated presentation environment that lets you test all of your air gap flow processes, before implementing them into production.
-
The DMZ should be managed by SecOps with respect to ignoring specific violations, patching, testing and promoting a weak dependency as necessary.
* Best practices on how to easily onboard JFrog Xray >>
Implementation Example: Process of curation of repositories based on air gap identification environment
For enterprise companies, with large development teams spread around the world, an identity -based solution becomes the de facto standard approach. The next generation of air gapped environments is based on defining everything about the request. More specifically, tracking:
-
Requesting an external 3rd party dependency that is not available in the internal environment.
-
The approval/disapproval of such dependencies, if not allowed to use them based on company policies.
The following diagram illustrates the process of selecting, organizing, and downloading 3rd party dependencies in an identity-based air gapped solution. All within the context of artifact management, especially in a highly controlled and secure environment.
The process of managing the security of your software binaries in an air gapped environment
The steps are explained
-
Kermit, the developer, has declared a new 3rd party dependency and is trying to build his project.
-
Kermit accepts ‘404 Not Found’, this dependency is not available within the Curated Repository in the internal Artifactory.
-
The Webhook request is sent to inform a ‘Self Service Curate Process’.
-
Opened Ticket #1 (via ServiceNow / Jira or other ticketing system) representing this request.
-
The request is sent to the external Artifactory to download this dependency to the DMZ Artifactory.
-
The DMZ retrieves the dependency from the internet.
-
Xray checks the dependency.
-
Vulnerability is reported via webhook.
If no violation is committed:
- Ticket #1 is closed.
-
Kermit has been notified and can now download the dependency from Curated storage, which will then access Open the Repository that there is a dependency available there to be used after the scan.
If a violation has been committed:
-
Ticket #2 was created, which represents the Xray violation that restricts the use of this dependency.
-
Kermit has been notified that there is now a violation of her use of this dependency, and SecOps will review it.
-
Kermit examines his violated dependency in a Sandbox environment to understand if he can use it (perhaps not need the vulnerable function for his development?) And to provide evidence to SecOps that it is valid and should be approved.
-
Kermit updates ticket #2 after his test results and research done on that dependency.
-
The SecOps engineer was notified about ticket #2.
If the violated artifacts are approved by SecOps:
-
Approved by SecOps and sent webhook.
-
The dependency is retrieved from the Open to the Curated repository.
-
Ticket #2 is closed.
If the violated artifacts are not approved by SecOps:
-
Kermit was notified that SecOps had reviewed and decided not to approve using the violated dependency.
The benefits of using this solution
-
Provides the necessary audit process
-
Sets up the infrastructure for organizations to grow
-
Allows the SecOps team to be easily integrated into the process
-
Provides ease of thought for developers, as the process is automated and hidden from them (they just need to download their dependencies and everything else is handled for them)
Note that this solution requires strong automation to implement, and a highly dedicated SecOps team to properly handle incoming tickets.
Related Resources
.