On-Premise or Cloud AppSec Tools: Selection Criteria for Banks and the Public Sector

For banks and government organizations in Central Asia, installing AppSec tools in their own environment (on-premise) is by default the safer option and the easier one to get approved: source code and vulnerability data do not leave the perimeter. The cloud wins on launch speed and operating costs, and suits cases without strict requirements on where code and data are hosted. The decision should be made not by trend but by the set of criteria covered below.

What exactly goes into a security tool

To understand the level of risk, you need to know what data the service receives. It differs between tool classes:

• SAST analyzes source or binary code — the most sensitive development asset: business logic, integrations, and sometimes secrets left in the code by mistake;
• SCA works mainly with the list of dependencies (manifests, SBOM), which is much less sensitive but still reveals the composition and versions of the software;
• DAST accesses running applications and processes responses and request parameters;
• scan results are themselves a map of the organization's vulnerabilities, which must not be left publicly accessible.

That is why the same bank can comfortably use a cloud service for SCA while requiring a local installation for SAST. The tool classes are described in the article "SAST, DAST, SCA and MAST".

Selection criteria

1. Regulatory and internal requirements for data location

In the countries of the region there are requirements for storing personal data, industry rules set by financial regulators, and internal information security policies of banks and government bodies. For example, the Law of the Republic of Kazakhstan "On Personal Data and Its Protection" provides for storing personal data in databases located on the territory of the country (commentaries link this to Article 12 of the law; verify the current wording at adilet.zan.kz). If source code or scan results contain such data, or if bank policy prohibits taking code outside the perimeter, the foreign cloud option is ruled out immediately. Requirements differ from country to country — check the current acts and consult your lawyers. We do not provide legal opinions here: this is a general reference point for discussion.

2. Code sensitivity and threat model

Ask yourself: what happens if source code or the vulnerability map ends up with third parties? For payment systems, processing and systems holding citizens' personal data, the answer is usually "unacceptable." For a marketing website or an internal prototype, it is acceptable. A cloud service can be well protected, but you add one more organization with access to your assets to the chain.

3. Network isolation and offline operation

Many critical environments operate in segments without internet access. They need the ability to work fully autonomously, including receiving updates to rule and vulnerability databases through a controlled channel. For example, Sonatype states that Nexus Repository can be used as a managed cloud service, as a self-deployed solution in a data center or cloud, or in air-gapped environments. The DerScanner platform is available as an on-premise deployment. Details of licensing and update conditions should be confirmed with us.

4. Auditor and regulator requirements for control

With a local installation, you control the logs, access, backups, and can show the auditor the entire chain. In the cloud, part of the controls sit with the provider, and you have to rely on its reports and certificates. For organizations where a regulator's inspection or an information security audit is a regular procedure, this is a significant argument.

5. Launch speed

The cloud launches faster: there is no server procurement, infrastructure approval, deployment or configuration. For a pilot, this is a serious advantage. But if the cloud option requires months of approvals with information security and legal teams, the time advantage disappears.

6. Operations and load on the team

On-premise requires servers, administration, updates, backups, monitoring and qualified people. In the cloud, the vendor performs this work. If the bank already has a mature operations team and infrastructure, the additional load is small; if not, it is a real expense.

7. Cost

The cloud moves costs into operating expenses (subscription) and removes capital investment in infrastructure. On-premise requires investment in hardware and people, but can be cheaper at large volumes and over a long horizon. Compare the total cost of ownership, not just the license price (see the structure of the DevSecOps budget).

8. Scalability and availability

The cloud scales easily to peak loads. In your own environment, capacity has to be planned in advance, but you control availability yourself and do not depend on external communication channels.

Comparison in one list

• Control over code and data: on-premise — full; cloud — limited by the contract and the vendor's measures.
• Operation in an isolated environment: on-premise — possible; cloud — not possible.
• Launch speed: on-premise — slower; cloud — faster.
• Operational load: on-premise — on you; cloud — on the vendor.
• Costs: on-premise — hardware and people; cloud — subscription.
• Passing information security approvals: on-premise — usually easier for banks and the public sector; cloud — requires a separate vendor assessment.

Hybrid approach

In practice, many organizations do not choose one option exclusively. A typical setup: SAST and the artifact repository run in your own environment, because they work with source code and build artifacts; cloud services are used for non-critical projects, pilots, and external perimeter DAST scanning. The key is to fix a rule: which classes of systems are allowed to be processed in the cloud and which are not.

How to decide: a short algorithm

1. Classify systems by criticality and by the types of data they process.
2. List the mandatory requirements: law, regulator, internal policy, contracts.
3. For systems with strict limitations, choose on-premise; for the rest, consider the cloud.
4. Check whether the vendor supports the required deployment model and how updates are delivered in a closed environment.
5. Run the pilot in the model you will use in production (where to start).

Questions for the vendor before choosing a model

Whatever model you choose, ask the vendor specific questions and record the answers in writing:

• What data is sent to the vendor's side in each operating mode, and can this be disabled?
• How are updates to the rule and vulnerability databases delivered in a closed environment, and how often?
• What are the requirements for servers, DBMS and OS for an installation with you, and how does the solution scale?
• How is technical support organized for closed environments where remote access is not possible, and how are incidents handled?
• What happens to the data when the contract ends: retention and deletion periods?
• What is the migration path between the cloud and a local installation if requirements change?

The answers to these questions often matter more than a comparison of functionality: they determine whether the solution will pass the information security department's approval.

Regional specifics

In Kazakhstan, Uzbekistan, Kyrgyzstan, Tajikistan and Turkmenistan, requirements for data location and for the use of foreign cloud services differ, and in some cases they change. In addition, the availability of local data centers, the quality of communication channels and the presence of local technical support from the vendor all matter. There is therefore no universal answer: take the criteria from this article, check the current acts of your country, and record the decision in your secure development policy.

Frequently asked questions

Sources

• Sonatype: Nexus Repository — deployment options
• Digital Business: How SMEs Can Save on IT and Protect Data (on data localization in Kazakhstan)