How to Scan Code Without Sending It to the Cloud: A Guide to On-Premise and Air-Gapped AST

Most modern application security tools are SaaS by default. Point them at the repository, cloud infrastructure pulls the code, scans run on their servers, and results come back to a web dashboard. For many organizations, this is fine. For others — it is not.

A defense contractor whose source code is export-controlled under ITAR cannot legally upload it to a third-party cloud. A bank whose codebase contains trading algorithms classified as trade secrets cannot risk exposing them in transit to an external scanning service. A European healthcare provider subject to GDPR and national data residency laws cannot send patient-adjacent code outside the jurisdiction it was written in. A government agency running classified workloads in an air-gapped network has no option to use the cloud, because by definition there is no cloud to use.

 

When On-Premise or Air-Gapped Is Actually Required

On-premise deployment means the AST platform runs inside your own infrastructure — servers, network, all under your control. Air-gapped goes a step further: the entire system operates with no network connection to external services at all, with updates delivered through physical media or tightly controlled offline transfer mechanisms.

• Defense and aerospace companies handling ITAR or EAR-controlled code fall into this category by law. 

• Financial institutions subject to certain DORA third-party risk provisions may need to demonstrate that source code never leaves the regulated environment. 

• Organizations in critical infrastructure sectors (like energy, water, transportation), often operate OT networks that are intentionally disconnected from corporate IT. 

• Government contractors running classified or controlled unclassified information (CUI) workloads face similar constraints.

Under GDPR, Article 44 restricts the transfer of personal data outside the EU/EEA — so if the source code contains PII, test data, or any references to personal data structures, sending it to a cloud scanner hosted in a non-adequate jurisdiction can create a compliance exposure. The EU Cyber Resilience Act does not directly mandate on-premise scanning, but its provisions around software supply chain transparency and SBOM generation create strong incentives for organizations to keep their build and scan pipelines under direct control.

 

 

What to Look For in an On-Premise AST Deployment

Feature parity with the cloud version

The first trap to avoid is vendors that offer “on-premise” as a stripped-down variant of their cloud product. The on-premise version should include the same language coverage, detection rules, SBOM generation capabilities, and the same reporting.

 

Offline updates for vulnerability databases and rule sets

Static analysis rules and CVE databases need to be updated continuously — new vulnerabilities are disclosed daily. A usable on-premise AST platform must support a controlled update mechanism: signed update bundles that can be downloaded from a connected network, verified, and imported into the air-gapped environment.

 

No telemetry, no phone-home

A true on-premise deployment does not send usage analytics, crash reports, scan metadata, or license validation pings to vendor servers. Verify this in the technical documentation. Some vendors describe their product as on-premise but require outbound connections for license validation or telemetry — which defeats the purpose in an air-gapped environment and creates audit concerns in a regulated one.

 

Integration with local CI/CD and identity

The AST platform needs to work with your on-prem GitLab, Jenkins, TeamCity, or equivalent, and it needs to authenticate against your LDAP/AD/SAML infrastructure without relying on external identity providers. Anything less creates operational friction that eventually pushes teams back toward cloud tools.

 

Scan performance at scale without cloud autoscaling

The platform should support parallelization across multiple scan agents, scan prioritization, and tunable resource allocation — otherwise security becomes a bottleneck every time someone pushes a large PR.

 

Five Questions to Ask Any Vendor

1. Does your on-premise version have feature parity with your cloud version, including all language support, AI triage, and remediation capabilities?
   If not, get the gap documented in writing.

2. What outbound network connections does the on-premise deployment require, and can they be fully disabled?

3. How are vulnerability database and rule updates delivered to an air-gapped environment?
   Look for signed update bundles.

4. Does the product store our source code anywhere we don’t control?
   The answer should be a clear no. DerScanner, for example, does not store source code and runs all analysis locally in the chosen environment.

5. Can the platform integrate with our existing on-prem CI/CD, ticketing, and identity systems without cloud relays?
   Ask for the list of supported integrations in on-premise mode specifically.

 

DerScanner supports both cloud and on-premise deployments, and the on-premise version is functionally complete: 43+ language SAST coverage, SCA with Supply Chain Security detection, DerTriage and DerCodeFix AI features, CycloneDX SBOM generation. 

Source code is not stored by the platform; analysis runs locally in whatever environment the customer chooses. For organizations with data residency obligations under GDPR, or export control obligations under ITAR, or sovereignty requirements under national security frameworks, this is the baseline that makes the conversation possible.