Domain 8 covers security in the software lifecycle: development methodologies, secure coding, code repositories and build pipelines, application testing, and the risks in software you buy or integrate instead of write.
Case Study: The "GitHub" API Key Leak
Global Bank built a "Cardless Cash" feature: the mobile app authenticates to a backend API and the ATM dispenses without a card. The right design used OAuth and short-lived tokens. During a hackathon, to save time, the developers hardcoded a master API key into the source. One developer pushed the code to a public GitHub repository to keep working from home.
Bots that scan GitHub for strings like API_KEY found it within seconds. With the key, attackers authenticated to the backend as an administrator, skipping user authentication entirely. The API did not check whether the caller owned the records it asked for, so any account was readable; one endpoint was vulnerable to injection; and the same access could initiate transfers.
Cardless transactions are, in the white paper's terms, one of the strongest answers to skimming, shimming and card trapping, because there is no card at the fascia to attack. What that trade does is move the trust from the card reader to the mobile app and the API behind it. The paper's section on software vulnerabilities lists the failure modes that then matter: application flaws, insecure configuration, default credentials. It also observes that attack tooling is a commodity now, sold on darknet forums with manuals; scraping bots are the same economics applied to leaked secrets.
One organization each, three to six questions apiece in the printed examination. Nothing here gives an answer away — the scenario is what the question hands you before it asks.
Global Bank is rebuilding the build pipeline for Cardless Cash, its cardless ATM withdrawal service, after a master key committed to source reached a public repository. The new design keeps the same three teams and the same weekly release. Secrets move to a managed vault. Builds run on shared runners any team can queue work on, and the repository is private, but every developer can push to the main branch. Nobody can currently say which build produced the artifact running in production. The bank's examiner has asked for evidence that the pipeline enforces the bank's own rules, not merely that the rules exist somewhere.
Global Bank · Cardless Cash mobile app and API
A monitoring service tells Global Bank that a production API key for its Cardless Cash service, the mobile app that lets customers withdraw at an ATM without a card, is sitting in a public repository. A developer pushed it there three days ago while working from home during a hackathon, and scanning bots reach new repositories within seconds. The key grants administrative access to the transaction backend. It is also compiled into the Android and iOS clients already in the app stores. The bank bought a managed secret vault last year and never wired it into anything, and nothing in its process would stop a credential being committed.
Global Bank · Cardless Cash mobile app and API
Coastal Savings processes card transactions for its own customers and for eight hundred merchants. An administrator credential has been found reaching its backend from outside the company, and the security team is now walking the customer API endpoint by endpoint. Statements are served from a path carrying the account number in the query string. The login endpoint builds its database query by concatenating the values submitted to it. Nothing in the API records which caller owns which record. Forensic work has been slow: the servers keep seven days of logs, application logins were never recorded at all, and log review is a manual quarterly task.
Coastal Savings · customer-facing payments API
Global Bank commissioned a penetration test of its customer web portal, the browser front end customers use for statements and transfers. The testers were given one customer login and nothing else. Every finding sits in a part of the portal that renders or fetches content on a user's behalf: a review board that stores and redisplays what customers type, the funds-transfer form, a document download endpoint that takes a filename, and a link-preview feature that fetches whatever URL a user supplies. The portal runs inside the bank's cloud account, on instances that can reach the cloud provider's own metadata service.
Global Bank · customer web portal
Northbridge Clearing settles interbank payments and takes files and messages from card processors and correspondent banks all day. Its partner integration service is the oldest code it runs: a C daemon that parses binary payment messages, a Java component that accepts serialized objects from partner systems over the internet and rebuilds them in memory, and an XML invoice upload used by three suppliers. A destination-account field feeds several downstream systems, and the team maintains an ever-growing filter of known malicious strings against it. None of the service has ever been fuzzed, and a settlement transfer crashed the daemon last week.
Northbridge Clearing · partner integration service
Secrets never live in code. They live in a vault, are issued to services as short-lived tokens through OAuth 2.0 client credentials, and rotate on a schedule and instantly on suspicion. Secret scanning runs as a pre-commit hook and as a pre-receive hook on the server, so a key cannot reach a repository, public or private.
Authorization is checked per object: every API call verifies the caller owns the record. Queries are parameterized. Both are OWASP Top 10 items (broken access control, injection), and both are found by static analysis and code review before a hackathon branch is anywhere near production. Which is the larger point: hackathon code is a prototype. It enters the normal lifecycle, with threat modelling at design and testing before release, or it does not ship.
Repository policy closes the door the developer walked through: no public repositories for bank code, branch protection, and mandatory review before merge. Monitoring on the API catches an administrator identity doing what no administrator does at 2 AM.
The key was rotated as soon as the leak was found and the public repository taken down. The bank's postmortem added secret scanning to every pipeline, per-object authorization to the API, and a rule that prototype code re-enters the lifecycle at the requirements stage.
Expect questions on where security sits in each SDLC phase, on secure coding and the OWASP Top 10 categories this scenario touches (broken access control, injection, identification and authentication failures, cryptographic failures), on secrets management and repository security, on the difference between authentication and authorization, and on why a prototype needs the same gates as production code before it is deployed.
The bank in this scenario is a composite. The trade-off and the controls are documented in: