Blog Home

No Internet? No Problem. Use Xray with an Air Gap – Part II

How you can protect your software in an air gapped environment

Tal Yitzhak

By Tal Yitzhak

6 min read

Secure Your Air-gapped Environment

With software supply chain attacks on the rise, implementing DevSecOps best practices in an air gapped environment is a must. In an effort to secure an organization’s internal network, there is an increasing trend of separating the internal network from the external one. Essentially creating an enclosed and disconnected environment from the public internet.

An air gapped solution provides stricter security requirements, but that’s not enough. The 3rd party dependencies used by your software developers, CI processes, and deployment pipelines must also be scanned for security vulnerabilities and license violations!

How? Combining a security vulnerability solution like JFrog Xray, allows you to protect your air gap environment, and exclude all vulnerable artifacts from being used within the internal development environment.

Our previous post showed how, with a bit of 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 continuous scanning for your software packages,  protecting your organization from any potential vulnerabilities in the future.

Using an external DMZ, with JFrog Xray installed to scan your remote dependencies for vulnerabilities

Best practices for working with Xray in an air gap solution

  • Both the internal and DMZ must have Xray installed. Not just the DMZ. This will ensure continuous scanning of your artifacts, securing them from any new vulnerabilities that may come up in the future for already ‘approved’ dependencies.
  • Differentiate between policies and watches configured in the internal and DMZ; You might have a global policy for dependency resolution on the DMZ, but then for a specific product/release a more strict approach, on the internal environment.
  • Use JFrog CLI to update your internal Xray database with the latest vulnerabilities intelligence, in case you are completely air-gapped.
    • DB sync must be done automatically, periodically (using a scheduler) and preferably daily.
    • In addition, the sync process (even the online one) should be monitored regularly for making sure it is not broken.
  • Work with a duplicated staging environment that allows you to test all of your processes of the air gap flow, before implementing them in production.
  • DMZ should be managed by SecOps regarding ignore of specific violations, patching, testing and promoting a vulnerable dependency if it’s needed.

* Best practices on how to easily onboard JFrog Xray >>

Implementation Example: Curation process of repositories based on identity air gap environment

For enterprise companies, with large development teams spread out around the world, an identity based solution is becoming the de facto standard approach. The next generation of air gapped environments is based on identifying everything about the request. More specifically, tracking:

  • The requester of the external 3rd party dependency that is not available in the internal environment.
  • The approval/disapproval of such dependencies, if they are not allowed to be used based on the company’s policies.

The following diagram describes 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 regulated and secured environment.

Process of managing the security of your software binaries in an air gapped environment

The process of managing the security of your software binaries in an air gapped environment

Steps explained

  1. Kermit, the developer, declares a new 3rd party dependency and tries to build his project.
  2. Kermit receives ‘404 Not Found’, this dependency is not available within the Curated Repository in the internal Artifactory.
  3. Webhook request is sent to notify a ‘Self Service Curate Process’.
  4. Ticket #1 is opened (via ServiceNow / Jira or other ticketing system) that represents this request.
  5. Request is sent to the external Artifactory to download this dependency in the DMZ Artifactory.
  6. DMZ pulls the dependency from the internet.
  7. Xray scans the dependency.
  8. Vulnerability is reported via a webhook.

If no violation is created:

  1. Ticket #1 is closed.
  2. Kermit gets notified and can now download the dependency from the Curated Repository, which then access the Open Repository that has that dependency available there to use after the scan.

If violation is created:

  1. Ticket #2 is created, representing the Xray violation that restricts the usage of this dependency.
  2. Kermit gets notified that a violation is now restricting him from using this dependency, and SecOps will review it.
  3. Kermit tests his violated dependency on a Sandbox environment to understand if he can use it (maybe the vulnerable function is not needed for his development?) and to provide evidence to the SecOps that it’s valid and should be approved.
  4. Kermit updates ticket #2 after his tests results & research done on that dependency.
  5. SecOps engineer gets notified about ticket #2.

If the violated artifacts is approved by SecOps:

  1. SecOps approves and a webhook is sent.
  2. Dependency is pulled from the Open to the Curated repository.
  3. Ticket #2 is closed.

If the violated artifacts is not approved by SecOps:

  1. Kermit gets notified that SecOps has reviewed and decided to not approve to use the violated dependency.

The benefits of using this solution

  • Provides the necessary auditing process
  • Sets the infrastructure for organizations to scale up
  • Allows to easily incorporate the SecOps team into the process
  • Provides ease of mind for the developers, since the process is automatic and hidden from them (they just need to download their dependencies and everything else is handled for them)

Keep in mind that this solution requires strong automation to be implemented, and a highly engaged SecOps team to properly handle the incoming tickets.

Related Resources

Popular Tags