Securing Applications Before AWS: The Pre-Migration Security Baseline for Nigerian Banks

Series · Hardening before AWS · Part 1 of 3 Securing the application · Part 2: Mobile banking app hardening → · Part 3: Identity-first migration →

Companion to the AWS-for-banks architecture series and the DSI banking threat picture.

The problem stated honestly

Most cloud migrations move broken applications onto better infrastructure. The CBN's CSAT directive of March 2026 doesn't care about your AWS landing zone if the application running inside it is shipping signed binaries built from unsigned dependencies, pulling secrets from a config file in the repo, and dropping the same SQL-injection bug into production every release because the SAST scanner has been "in evaluation" for eighteen months.

A Tier 1 Nigerian bank that is about to spend twelve months and three million dollars on the AWS architecture in Part 2 of the AWS-for-banks series needs to spend the first sixty days on something less photogenic: closing the application-security gates that determine whether the new infrastructure is defending good code or amplifying bad code.

This piece documents what we deploy in those sixty days. It is the work that runs in parallel with the landing-zone Terraform — not a prerequisite that delays AWS, but a pipeline modernisation that lands at the same time as the architecture goes live.

What we mean by "the application"

For a Nigerian Tier 1 bank in 2026, the application surface that AWS will host is roughly the following:

• The mobile banking app — typically a hybrid React Native or native Android/iOS build talking to a REST or GraphQL gateway. Over 70% of customer traffic in 2026. (Detailed hardening is Part 2.)
• The customer-facing web channel — internet banking, account opening, loan applications.
• The internal services tier — fraud-inference workloads, customer-360 services, document-OCR pipelines, reconciliation engines.
• The integration tier — NIBSS gateway, card switch, SWIFT, payment-processor APIs, third-party KYC and credit bureaux.
• The data layer — primary core ledger stays on-prem; analytics replicas, fraud features, compliance archive run in AWS.

The pre-AWS baseline applies to all five. The threat model differs per tier, but the gates we install are the same five.

The five pre-flight gates

Modern application security at a Tier 1 bank is not a tool. It is a sequence of pipeline gates that block a release if the evidence is not there. The five gates below are the minimum we deploy before AWS goes live. They map cleanly to the cybersecurity-measure expectations the CBN CSAT directive sets out, to the NDPA 2023 / GAID 2025 obligations on processed personal data, and to the principles of the NIST Risk Management Framework and CIS Controls v8 that increasingly anchor counter-party assurance expectations.

Gate 1 — Static Analysis (SAST) in CI

Every pull request runs through a static analyser before it can be merged. The tools we ship with are Semgrep for first-pass policy enforcement (custom rules per repo, tuned to the bank's frameworks) and SonarQube or Snyk Code for deeper code-quality and vulnerability detection. CodeQL is the alternative where the engineering team has GitHub Advanced Security.

The configuration matters more than the choice of tool. Three rules:

1. Block on high or critical findings. Don't ship a "warning" build. The PR doesn't merge until the finding is either fixed or formally accepted with a documented exception that flows into the risk register.
2. Tune to the framework. Generic Java rules find generic Java bugs. The bank's Spring or Quarkus codebase needs custom Semgrep rules for its specific authentication and authorisation patterns, its specific SQL access conventions, its specific error-handling idioms.
3. Track the trendline. Vulnerability count per repository, tracked quarterly, reported into the board's risk pack. The number must contract. A flat line means the scanner is broken.

Gate 2 — Dynamic Analysis (DAST) against staging

After the build deploys to staging, a DAST run hits it before promotion to UAT. OWASP ZAP and Burp Suite Pro are the operational tools; SecPoint Penetrator (the platform we deploy through DSI Advisory for ongoing vulnerability management) is the post-deployment continuous layer that runs against the production-facing surfaces on a scheduled cadence.

The point of DAST in staging is not to find the same bugs SAST already found. It is to find the bugs that only exist when the application is running — broken access control between roles, session-management flaws, authorisation logic that fails when two requests race, file-upload paths that accept what the documentation says they don't. These are the patterns that hit Nigerian banks in real incidents and never appear in code review.

Gate 3 — Software Composition Analysis (SCA) against the dependency tree

A Tier 1 banking application pulls 200 to 800 direct dependencies and 1,500 to 5,000 transitive dependencies. Every one of those is a supply-chain attack surface. SCA — Snyk Open Source, GitHub Dependabot, OWASP Dependency-Check, or Mend — runs continuously and blocks the build if a dependency has a known CVE above the bank's risk threshold.

Two rules:

1. Patch in days, not quarters. The convention of accumulating dependency updates into a quarterly maintenance release is the convention that produces the Log4Shell incident the bank reads about three years later. Patch on a weekly cadence; auto-merge low-risk patch versions; review minor and major changes.
2. Pin and verify. Pin dependencies by exact version with a lock file (package-lock.json, pom.xml with explicit versions, requirements.txt with hashes). The build doesn't pull "latest" from a registry. The registry doesn't get to silently update what the application runs.

Gate 4 — SBOM generated per release

A Software Bill of Materials — generated automatically per build, attached to the release artefact, stored in the bank's audit-evidence vault — is the document a regulator or a JV counter-party assurance team asks for first. Syft generates it; CycloneDX or SPDX is the format.

The SBOM does three things:

• Answers the dependency question in minutes. When the next Log4Shell-class vulnerability is announced, the bank queries its SBOM archive and knows within five minutes which builds across which subsidiaries shipped the affected component. Without an SBOM, this answer takes two weeks and a consultancy.
• Closes the supply-chain gap that the EU Cyber Resilience Act now writes into procurement contracts. The CRA, in force across the EU and applying to digital products entering the EU market from late 2027, makes SBOM provision a vendor obligation. Nigerian banks selling cards, processing payments, or operating subsidiaries inside the EU will inherit this obligation by extension; banks not directly in scope still face it via European vendors who must now flow it down.
• Provides the evidence base for CBN CSAT. "Demonstrate that you know what software runs in your environment" is a question SBOM was designed to answer.

Gate 5 — Secrets in a vault, not in a config file

The most reliable way to compromise a Nigerian bank's AWS account in 2026 is still a hardcoded AWS access key checked into a public-mirror of a private repository by an outsourced contractor with stale Git hygiene. The fix is not "remind people not to do that." The fix is to remove the option.

A central secrets vault — HashiCorp Vault if the bank is self-hosting, AWS Secrets Manager once the landing zone is live, or AWS Systems Manager Parameter Store for less-sensitive configuration — becomes the single source of truth. Applications authenticate to the vault using short-lived workload identities (IRSA on EKS, IAM Roles for EC2, IAM Identity Center for human operators). No long-lived static credentials in environment variables, in CI/CD secrets, in .env files, in config maps, anywhere.

In CI, we add Gitleaks or TruffleHog as a pre-commit and PR-level gate. A commit that contains a credential pattern doesn't merge. The pipeline doesn't run. The branch is quarantined. The developer learns. This is unpopular for the first two weeks and uncontroversial for the next two years.

The signing chain

The five gates above protect the build. The signing chain protects the artefact between the build and the deployment. Three components:

• Sigstore + cosign — every container image, every release artefact, every infrastructure module is signed at build time. The deployment pipeline verifies the signature before the artefact runs. An unsigned or wrong-signed artefact is rejected.
• In-toto attestations — provenance metadata generated at build time documents which CI runner produced the artefact, which source-controlled commit it built from, which dependencies it included, and which gates it passed. The attestation travels with the artefact.
• SLSA Level 3 — Supply-chain Levels for Software Artefacts is the industry framework that ties the above together. SLSA 3 is the bar we deploy. Higher levels (SLSA 4) require hermetic builds and are appropriate for the core-banking platform tier; SLSA 3 is the right baseline for general application workloads.

The signing chain is what makes the Part 2 AWS architecture defensible. An attacker who reaches an AWS workload cannot replace its container image with a tampered version, because the cluster admission controller rejects the unsigned image. This is the control that closes the lateral-movement path the DSI threat picture documents in the post-incident reports.

What changes in the developer workflow

The pipeline gates above sound onerous to a developer who has not lived inside them. In practice, after the first eight weeks, they accelerate delivery rather than slowing it. The reason: the gates surface the bug at the moment the developer wrote it, not three months later when an examiner asks why customer data leaked.

The workflow we deploy at Nigerian Tier 1 banks looks like this:

1. Local pre-commit hooks — formatters, linters, the secret scanner. Five seconds, zero infrastructure dependency. Catches 70% of issues before the commit even leaves the developer's laptop.
2. PR-level CI — SAST, SCA, dependency lock verification, unit tests with coverage thresholds. Five to fifteen minutes. Blocks merge until green.
3. Post-merge build pipeline — build, sign, generate SBOM, generate attestation, upload to artefact registry. Ten minutes. Produces a deployable artefact with full provenance.
4. Deploy to staging — DAST run against staging environment after deployment. Twenty to forty minutes. Blocks promotion to UAT if findings are above threshold.
5. Pre-production gate — manual review of the SBOM, the attestation, and the open findings. Human sign-off. Logged.
6. Production deploy — admission controller verifies signature and attestation. Deployment proceeds only if both verify.

The developer's workflow gains: faster feedback, fewer post-deploy rollbacks, fewer Friday-evening incident calls. The bank gains: an evidence chain at every step that a CBN examiner, NDPA assessor, or counter-party assurance team can audit without disrupting operations.

The CSAT and NDPA mapping

The five gates and the signing chain map cleanly to specific obligations under the regulatory regimes a Nigerian Tier 1 bank now operates under:

The mapping is what converts the work from "engineering hygiene" into "regulatory evidence". The bank doesn't run SAST because it is good practice. It runs SAST because the directive of 30 March 2026 implies the bank has a tested process to detect application vulnerabilities before release, and SAST is the only credible evidence of that process running.

The 30-60 day pre-flight programme

We deliver the five gates and the signing chain in a 30-60 day programme that runs in parallel with the AWS landing zone build. The shape:

• Weeks 1-2 — Discovery and tooling decisions. Audit existing CI/CD, document the application stack, choose the specific SAST/DAST/SCA tools that fit the bank's languages and frameworks. Procure where needed.
• Weeks 3-6 — Pipeline integration. Wire SAST, SCA, and the secret scanner into the existing CI on a per-repo basis. Start with the highest-traffic services (mobile gateway, customer-360) and roll outward. Each repo gets onboarded with a workshop for its engineering team.
• Weeks 5-8 — Staging DAST. Deploy DAST against the staging environment. Start with non-authenticated scans; add authenticated scans for the higher-risk surfaces. Tune false positives.
• Weeks 7-9 — Signing chain. Stand up Sigstore, cosign, in-toto. Migrate the artefact registry to verify signatures. Connect to the SBOM generator.
• Weeks 8-10 — Secrets migration. Stand up the vault, migrate secrets out of config maps and CI variables, rotate everything. The legacy access keys get revoked at the end of this phase, on a specific date, communicated in advance.
• Weeks 9-12 — Audit-evidence integration. SBOM archive, SAST/SCA findings archive, DAST reports, signing attestations all land in the same evidence vault that the AWS architecture's CloudTrail Lake will land in.

At day 60, the bank has a pipeline that produces audit-grade evidence with every release. At day 90 (or whenever the AWS landing zone goes live), the architecture in Part 2 of the AWS-for-banks series is defending workloads that have been built under that pipeline. The two halves meet.

What this does not cover

Three things that are adjacent but out of scope for this piece:

• The mobile-banking app surface has its own threat model — device tampering, certificate pinning, RASP, OTP weaknesses — and gets its own dedicated treatment in Part 2: Mobile banking app hardening.
• The identity perimeter — IAM Identity Center, federated identity, MFA, role design — has to be architected before the AWS account is provisioned, and is Part 3 of this series.
• The on-prem core-banking platform stays on-prem and is hardened under a separate workstream that follows the same five-gate logic but against a different toolchain (mainframe, legacy Unix, vendor-controlled environments). We treat it in a forthcoming piece.

Why this comes first

The shape of every cloud migration that fails in production at a Nigerian Tier 1 bank is the same shape. The infrastructure team gets the landing zone right. The application team ships the same code they shipped before — with the same SQL-injection bug, the same hardcoded credential, the same Log4j dependency at the version that was current the day the project started — onto better-instrumented infrastructure.

The new infrastructure observes the incident more cleanly. It does not prevent it.

The pre-AWS baseline is what converts "we moved to AWS" into "we moved to AWS and the application surface is no longer the weakest link." It is not glamorous work. It is the work. The five gates and the signing chain are deployable in sixty days. The bank that runs them lands on AWS with an application surface that the architecture can actually defend.

Part 2 — Mobile Banking App Hardening for Nigerian Tier 1 Deployments covers the device-side surface that delivers most of the customer traffic. Part 3 — Identity-First Migration covers the IAM architecture that has to land before any AWS workload is provisioned.

The AWS-for-banks architecture series — the threat picture (DSI ↗), the architecture, the operational implementation — is the substrate this prequel series prepares the application surface for.