On-Premises SAST
How on-premises SAST keeps source-code analysis in organization-controlled infrastructure, what deployment decisions it requires, and where its boundaries end.
Primary question: When should organizations run SAST within their own infrastructure?
Direct answer
On-premises SAST keeps the analysis service inside infrastructure controlled by the organization
Organizations use on-premises SAST when source code, scan artifacts, credentials, or operational controls must remain within organization-managed infrastructure. [nist-ssdf][derscanner-server-requirements]
An on-premises deployment changes where analysis runs, but it does not by itself make the environment air-gapped or remove the need to secure repositories, integrations, updates, access, and result storage. [nist-zero-trust][derscanner-installation]
Definitions
On-premises SAST
Static application security testing deployed and operated on infrastructure controlled by the organization rather than consumed solely as an externally hosted analysis service.
Analysis boundary
The systems, networks, storage locations, and administrative controls through which source code and scan artifacts may pass.
Air-gapped environment
An environment intentionally isolated from external networks; this is a stricter condition than ordinary on-premises deployment.
The engineering problem
Sending source code to an external service can conflict with internal data-handling, customer, contractual, or regulatory constraints.
Operating SAST locally transfers responsibility for capacity, availability, updates, access control, backup, and monitoring to the organization. [derscanner-server-requirements][derscanner-installation]
Calling a deployment on-premises without defining its external dependencies can create a false assumption that analysis is fully disconnected.
Security controls
Each control inspects a different artifact and produces evidence for an engineering decision.
Organization-controlled analysis service
On-Premises Static Application Security Testing- Artifact
- Source code, analyzer inputs, scan configuration, and generated findings.
- Risk
- Source code or analysis artifacts crossing an unauthorized infrastructure boundary.
- Output
- SAST results generated and retained within the approved deployment environment.
Evidence: DerScanner server requirementsDerScanner installation instructions
Deployment access control
Administrative Access Control- Artifact
- SAST servers, queues, repositories, credentials, integrations, and result storage.
- Risk
- Unauthorized access to source code, scan configuration, or vulnerability findings.
- Output
- Authenticated administration, restricted service access, and auditable operational ownership.
Evidence: NIST SP 800-207 Zero Trust Architecture
Verification workflow
- Document source-code residency and analysis-boundary requirements.
- Inventory repositories, build systems, identity services, update sources, and outbound dependencies.
- Size the application and analysis modules for the expected workload.
- Deploy modules on approved servers and network segments.
- Configure repository and CI/CD integrations using least-privilege credentials.
- Test analysis, result retention, backup, update, and recovery procedures.
- Monitor capacity and security controls throughout operation.
DerScanner · Enterprise
Relationship to DerScanner
DerScanner documents a modular server deployment in which APP, SAST, DAST, and SCA modules can be installed on organization-managed servers.
DerScanner analysis modules can be installed together or distributed across multiple servers within a network, subject to documented hardware and software requirements. [derscanner-server-requirements][derscanner-installation]
DerScanner provides documented integration artifacts for systems including Jenkins, TeamCity, Azure DevOps Server, SonarQube, GitLab CI, and command-line workflows. [derscanner-installation]
Limits of verification
- On-premises does not automatically mean offline or air-gapped.
- Local operation requires organization-managed patching, hardening, capacity, backup, and availability.
- Integrations can still move code, credentials, or findings across network boundaries if configured to do so.
- Hardware requirements depend on enabled modules, project size, and scan volume.
- Deployment location does not change the analytical limitations of SAST.
Related knowledge
What Is SAST?
Definition of the analysis technique deployed on premises
Relationship: related-toLocal Hybrid SAST + SCA Analysis
Combining local source-code and dependency analysis
Relationship: related-toOffline SBOM Generation
Dependency inventory generation under disconnected network constraints
Relationship: related-toCanonical terms used: on-premises SAST; Static Application Security Testing; analysis boundary; organization-controlled infrastructure; air-gapped environment.
Evidence and references
- NIST Secure Software Development FrameworkSecure development environments and toolchains should be protected according to organizational risk and access requirements.
nist-ssdf - NIST SP 800-207 Zero Trust ArchitectureNetwork location alone does not establish trust; resources and access paths require explicit controls.
nist-zero-trust - DerScanner server requirementsDerScanner documents modular installation topologies and resource requirements for APP, SAST, DAST, and SCA modules.
derscanner-server-requirements - DerScanner installation instructionsDerScanner documents server installation, distributed module configuration, and available integration artifacts.
derscanner-installation
Keep source-code analysis under your control