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.

A Nigerian Tier 1 bank cuts over to its new AWS landing zone on a Saturday morning. The architecture diagram is signed off. The Terraform is clean. The CISO posts a photo of the team in the war room. On Tuesday at 14:07 a customer-data file appears on a Telegram channel known for selling leaked datasets. The leak does not come from AWS. It comes from a hardcoded database password sitting in a config file in a Bitbucket repo a contractor cloned to a public mirror three months earlier. The new infrastructure observed the exfiltration more cleanly than the old one would have. It did not prevent it.

This is the shape of every cloud migration that fails in production at a Nigerian Tier 1 bank. The infrastructure team gets the landing zone right. The application team ships the same code they shipped before — same SQL-injection bug, same hardcoded credential, same Log4j dependency at the version that was current the day the project started — onto better-instrumented infrastructure. The new infrastructure makes the incident easier to investigate. It does not stop it happening.

The Less Photogenic Sixty Days

A Tier 1 Nigerian bank 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 "The Application" Actually Is

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, with detailed hardening in 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, where the primary core ledger stays on-prem and analytics replicas, fraud features, and the compliance archive run in AWS.

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

Five Gates The Pipeline Has To Pass

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 and 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 one — Static analysis 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. Block on high or critical findings — do not ship a "warning" build, because the PR does not merge until the finding is either fixed or formally accepted with a documented exception that flows into the risk register. Tune to the framework — generic Java rules find generic Java bugs, but 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. 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 two — Dynamic analysis 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 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 do not. These are the patterns that hit Nigerian banks in real incidents and never appear in code review. Think of SAST as proofreading the recipe and DAST as tasting the soup. Different bugs surface at different stages.

Gate three — Software composition analysis

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.

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. 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 does not pull "latest" from a registry. The registry does not get to silently update what the application runs.

Gate four — SBOM 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 counter-party assurance team asks for first. Syft generates it; CycloneDX or SPDX is the format. Think of it as the manifest a shipping container carries — the inspector at the dock wants to know what is inside, sealed at the factory, signed by the loader.

The SBOM does three things. It 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. It 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. And it 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 five — Secrets in a vault

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 — exactly the path that produced the leak at the start of this piece. 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 does not merge. The pipeline does not 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 protect the build. The signing chain protects the artefact between the build and the deployment — like a tamper-evident seal on a courier's package that the recipient checks before they sign for it.

Three components. Sigstore plus cosign sign every container image, every release artefact, every infrastructure module at build time. The deployment pipeline verifies the signature before the artefact runs. An unsigned or wrong-signed artefact is rejected. In-toto attestations carry provenance metadata generated at build time — which CI runner produced the artefact, which source-controlled commit it built from, which dependencies it included, which gates it passed. The attestation travels with the artefact. SLSA Level 3 is the industry framework that ties the above together — Supply-chain Levels for Software Artefacts. SLSA 3 is the bar we deploy; higher levels (SLSA 4) require hermetic builds and are appropriate for the core-banking platform tier, but 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. Local pre-commit hooks run formatters, linters, and the secret scanner in five seconds with zero infrastructure dependency, catching 70% of issues before the commit even leaves the developer's laptop. PR-level CI runs SAST, SCA, dependency lock verification, and unit tests with coverage thresholds in five to fifteen minutes, blocking merge until green. Post-merge build pipeline builds, signs, generates SBOM, generates attestation, and uploads to artefact registry in ten minutes, producing a deployable artefact with full provenance. Deploy to staging runs DAST against the staging environment after deployment in twenty to forty minutes, blocking promotion to UAT if findings are above threshold. The pre-production gate is manual review of the SBOM, the attestation, and the open findings, with human sign-off, logged. Production deploy has the admission controller verify signature and attestation, proceeding 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 does not 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 60-Day Pre-Flight Programme

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

Weeks 1-2 are 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 are pipeline integration — wire SAST, SCA, and the secret scanner into existing CI on a per-repo basis, starting with the highest-traffic services (mobile gateway, customer-360) and rolling outward. Each repo gets onboarded with a workshop for its engineering team. Weeks 5-8 are 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 are the signing chain — stand up Sigstore, cosign, in-toto; migrate the artefact registry to verify signatures; connect to the SBOM generator. Weeks 8-10 are 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 are audit-evidence integration — SBOM archive, SAST/SCA findings archive, DAST reports, signing attestations all land in the same evidence vault 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 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 The Less Photogenic Work Comes First

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 the architecture can actually defend.

The CISO posting the war-room photo on cut-over Saturday gets a different Tuesday — one where the leaked credential never existed, because the secret scanner caught it on the developer's first commit, three months before anyone walked into a war room at all.

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.