Vibe coding is writing production code by iterating on AI generated or intuition driven output until it runs, with no threat model, no input validation pass, and no review gate before it reaches a build pipeline. In a bank, the risk is not the coding style itself, it is that regulated software ships without the evidence trail CBUAE and internal audit expect.
- Vibe coding skips threat modelling and input validation, the two steps that catch most exploitable bugs
- Hardcoded secrets and broken access control are the most common findings in fast shipped banking applications
- Examiners and auditors want evidence of secure SDLC gates, not just a working feature
- A design stage security gap caught after release costs far more to fix than one caught in code review
What "vibe coding" means inside a bank's SDLC
Vibe coding is shipping code that works before anyone has verified it is safe: a developer prompts an AI assistant or types quickly until a feature runs, skips the design and threat modelling step, and pushes to a branch that a CI pipeline deploys with minimal gates. The term is new; the failure mode is not. It is the same shortcut that produced insecure ad hoc scripts for two decades, accelerated now because AI code generation makes "something that runs" available in seconds and because sprint cadence rewards visible progress over controls nobody can see.
The problem for a bank is not that the code was written quickly. Plenty of well engineered software ships fast. The problem is that nobody can produce evidence a security control was ever considered, and in a regulated environment that absence is itself a finding.
Why banks are more exposed than most organisations
Three pressures compound here. Digital banking and open banking initiatives put customer facing APIs on aggressive release schedules, and product teams often treat a security review as a delay rather than a gate. AI coding assistants are now standard in development teams, and they generate functional code readily but do not enforce an organisation's secure coding standard unless that standard is fed back into the prompt or caught by a downstream scanner. Fintech partnerships also mean a bank's attack surface increasingly includes code it did not write and cannot fully review, built the same way.
The risks that keep showing up in code and architecture reviews
These are recurring findings in application security assessments of fast shipped software, not hypothetical ones, and they map directly onto what a penetration test or secure code review will surface.
Insecure design and data flow
Without a design phase, sensitive data flows through the path of least resistance rather than the path with the fewest exposure points. Plaintext storage of data that should be encrypted, services that trust each other implicitly because segmenting them would have taken another sprint, and API endpoints that return more fields than the client needs are symptoms of the same root cause: nobody mapped the data flow before writing the code.
Missing input validation
This is the single most common finding. Code written to make a feature work assumes inputs will be well formed, because in development and demo environments they usually are. In production, an attacker controls every field, header and parameter they can reach. String concatenation into a SQL query, unescaped output rendered into a page, and shell commands built from user supplied filenames are all input validation failures, and all three still turn up in production code because validating and encoding input at the boundary keeps getting skipped under deadline pressure.
Weak authentication and authorisation
Under time pressure, authentication and authorisation are the parts developers most often shortcut, because building them correctly, with proper session handling, multi factor enforcement and server side checks on every request, takes real effort with no visible feature to show for it. The pattern that shows up in reviews is authorisation checks in the interface but not the API behind it, session tokens that never expire, and administrative functions reachable by changing a role parameter in a request.
Hardcoded secrets and configuration drift
API keys, database credentials and signing keys end up in source because that is the fastest way to get a feature working locally, and the step to move them into a secrets manager gets deferred indefinitely. Once a repository or build artefact leaks, even briefly, those secrets are compromised, and most organisations find the hardcoded secret during a scan rather than before one is ever run.
Unmanaged dependencies
Vibe coded projects pull in libraries the way they pull in code: whatever answers the immediate problem, with no review of what else ships inside the package or whether the maintainer is still active. Nobody tracks which of dozens of transitive dependencies carries an unpatched vulnerability, because nobody wrote dependency management into the process as a step.
Skipped fundamentals: logging, error handling, cryptography
Error handling that fails closed, logging that captures security relevant events without leaking sensitive data into the log itself, and using vetted cryptographic libraries instead of home rolled encryption are unglamorous work that vibe coding routinely skips. None of it is visible until an incident happens and the logs turn out useless for the investigation.
What examiners and assessors actually look for
What a regulated entity generally needs to show is not that one specific line of code is safe, but that a process existed: a documented SDLC with security gates, records of threat modelling for new features, static and dynamic analysis results before release, a dependency inventory with a patching cadence, and a code review sign off that is more than a rubber stamp. Vibe coded projects fail this not because the software is always worse, but because there is no artefact to show for it. For background on what regulated entities are expected to demonstrate, see our overview of CBUAE cybersecurity requirements for UAE banks.
A penetration test against vibe coded software tends to be short and unflattering: the injection and access control classes above are usually found on the first day, because nobody designed against them. If your team is deciding when to schedule penetration testing against a new release, the honest answer is before the release, not after a customer or regulator finds the gap for you.
Fixing this without stopping delivery
Organisations that manage vibe coding well do not ban AI assistants or slow every sprint to a crawl. They add a small number of gates that catch the recurring failures without a full waterfall design phase:
- A short threat model for any feature touching authentication, payments or customer data, even a one page version, written before code is
- Parameterised queries and output encoding enforced by a linter rule or a pre commit hook, not left to developer memory
- Secrets kept out of source control by tooling, not by policy, since policy alone rarely survives a deadline
- A software composition scan in the pipeline that blocks a build on a known exploited dependency vulnerability, tied into a wider vulnerability management programme rather than run as a one off
- A security focused code review gate before merge for anything touching authentication, authorisation or data handling
- A written secure SDLC document the organisation can actually produce during an audit
The gate that actually stops this
If a bank keeps only one control, make it this: no code that touches authentication, payment processing or customer data reaches a production build without a review that specifically checks for injection, broken access control and hardcoded secrets. That single gate, enforced without exception, catches most of what vibe coding introduces. Everything else above makes that gate faster and more reliable, but it is the one control that prevents the finding an examiner cannot ignore.
