Cybersecurity

03

Security is engineering, not a checklist

A checklist assumes the threats are known, static and few, and that compliance is the goal. Engineering assumes the threats are adaptive, distributed and personal, and that the goal is survivability. The difference shows up in every decision: a checklist adds a captcha; engineering rates the endpoint and limits it. A checklist pays for a scan once; engineering wires detection that runs every minute.

• Threats are modelled before features — every surface is asked 'who would attack this, how, and what do they win?' before it is built, so security is a design input, not a post-build coating.
• Security is a property of the architecture — authorization lives in the database policies, secrets in a managed store, and limits in the payment functions, so a single page's author cannot silently weaken them.
• The money path gets a higher standard — the surfaces that move cash, hold identity or touch the gateway are hardened beyond the 'good enough' that a content feature tolerates.
• Defaults are secure — private, sealed, least-privilege and encrypted are the starting position, and every exception is an argued, reviewed line in a diff rather than a console click.
• Testing security is scheduled, not annual — dependency scans run on every build, penetration testing on a cadence, and the incident drills on a calendar, because yearly is not security, it is archaeology.
• Security failures are treated as engineering bugs — a breach or a near-miss becomes a root cause, a fix and a test, the same way a double-settlement does, not a report that lands in a folder.

A checklist can be completed. Engineering never is — and that is precisely the point. We run security as an engineering discipline because a money platform has no 'finished' that leaves it safe.

04

The threat model: know who is knocking

Security without a threat model is security theatre — defenses built for imagined attackers while the real ones walk the open door. We begin every build by naming the adversaries, their assets, their incentives and their access, and we keep the model updated as the platform grows. On a payments platform, the threat model is refreshingly specific.

• The opportunistic attacker — bots and scripts scanning for soft targets: open endpoints, default configs, missing auth; the cheapest attacks and the most common.
• The identity thief — Kenyan reality: stolen IDs, SIM-swapped phones, account-takeover via one leaked code; the attacker's goal is to become the legitimate user in the system's eyes.
• The enumeration artist — probing whether a phone number has an account, whether a wallet is funded, whether a reference exists; they turn 'does this exist?' into leverage.
• The self-dealer — the user who games the platform's own features: paying themselves, recycling promotions, fabricating referrals, abusing the escrow and hold rules for free money.
• The insider — the privileged account that misbehaves, careless or malicious; the model assumes privileges can be compromised and designs so one role cannot do everything alone.
• The social engineer — the attacker who never touches the API at all, but convinces a human to approve, release or reveal, which is why the adversarial model includes the staff and the vendor, not just the hackers.

The threat model is the map the rest of the security work follows. We update it as the platform does — because the attackers certainly do.

05

OWASP in practice: the request layer

OWASP's Top Ten is not a checklist to purchase; it is a syllabus of the classes of failure that show up in web and API software. We run the whole syllabus against every build, and on a platform that moves money the OWASP categories are not academic — each one has a real cash price.

• Injection — SQL, NoSQL, command and template injection are closed at the parameter and the query layer; dynamically-built strings that touch the database are forbidden where the architecture can refuse them.
• Broken access control / IDOR — 'can this user read this row?' is enforced by row-level security in the database, not by a well-meaning frontend, so an object-reference attack finds a wall even when it guesses the right ID.
• Cryptographic failures — passwords, keys and PII are hashed and encrypted with current algorithms; the schema stores hashes, not secrets, and the subsystem that reads a password can be counted on one hand.
• Security misconfiguration — private-by-default templates, least-privilege grants and a declared configuration mean the common 'it ships permissive' failure is a review artifact, not a default.
• Vulnerable and outdated components — dependency scanning runs in the delivery pipeline, so a vulnerable library is caught at build time instead of on a post-breach forensics timeline.
• Identification and authentication failures — sessions, tokens and MFA are engineered as first-class systems, not browser cookies hoped to be enough, because money only moves after identity holds.

The OWASP categories are where security becomes concrete. We test them, we trip over them in rehearsals, and we fix them before they trip over us in production.

06

SSRF, CSRF and the server-side blind spots

The less glamorous OWASP categories are where real attacks graduate from theory: the server that fetches URLs, the browser that silently carries cookies, the callback that arrives from the internet uninvited. These matter profoundly on a platform whose servers talk to a payment gateway.

• SSRF is closed at the boundary — any path where the server fetches a URL (webhooks, exports, gateway calls) validates the target, blocks internal networks and restricts protocols, because a server that fetches anything is a free bridge into the internal platform.
• CSRF is foreign to stateless APIs — modern JSON APIs protected with explicit origin checking, same-site semantics and token-based auth leave the browser-cookie confusion dead; we still test it because old habits outlive old APIs.
• The callback surface is the open door — payment callbacks arrive from the public internet by definition, so that surface gets the strongest discipline: signature verification where the gateway supports it, gateway-query re-verification where it does not, and idempotency that survives replay.
• Open redirects are closed — any redirect the app performs is validated against an allowlist because a redirect is a free phishing vector wearing your brand.
• File uploads are suspicious by construction — uploads are content-type-checked, re-encoded, size-limited and stored outside the executable path, so a 'document' cannot become a shell.
• Serialization is not trusted — any user-supplied data that could be interpreted as code (deserialized objects, templates, queries) is treated as untrusted input and validated or rejected at the boundary.

The server-side blind spots are where attackers who read the CVE list outlast teams that read the dashboard. We close them structurally, not by vigilance.

07

Authentication: proving who you are

Authentication answers the first question of any transaction: who is this? On a money platform the answer gates actual cash, and the answers Kenya demands — phone, ID, PIN, OTP, biometrics, device — each bring their own attack surface. We engineer the layers so that stealing one factor is never enough.

• Passwords are stored as strong hashes — bcrypt or argon2 with per-user salt, never reversible, never logged, never transmitted in a recoverable form, and the count of places that can verify one can be listed on a single hand.
• MFA is real, not decorative — the login OTP, the high-risk action OTP and the device-verification flow give sensitive operations a second factor that an account-takeover can't fake with the password alone.
• OTPs are short-lived, rate-limited and single-use — a code's value decays in minutes, its attempts are limited, and its use is one-shot, so interception burns fast instead of farming slow.
• Sessions are explicit and revocable — sessions are tracked, listed per user, revocable per device, and capped at a maximum, so 'sign out this stolen phone' is a feature, not a support ticket.
• Device identity and pairing — devices are described, registered and limited per account, so a new login from a fresh device is an event the user can see and block, not a silent surprise.
• The authentication failure surface is honest — indistinguishable responses to 'wrong phone' and 'no account' close the enumeration door, and rate limits turn an OTP brute-forcer's session into a waste of time.

Authentication is where identity meets cash, and Kenya's reality — shared phones, SIM swaps, downloaded APKs — makes it the most attacked layer of all. We build it to lose to the attacker slowly and win against the user fast.

08

Authorization: least privilege and the walls between roles

Authentication says who you are; authorization says what you may do, and the two must never be confused. Authorization on a money platform is a tower of walls: roles, policies in the database, row-level security, function-level gates, and the honest rule that no surface may silently widen a boundary.

• Roles are explicit and narrow — tenant, landlord, admin and support each hold exactly the capabilities their job needs, and the role matrix is reviewed on every feature because role creep is how insiders become omnipotents.
• Row-level security is the enforcement layer — the database itself answers 'can this user read, write or own this row?', so even a compromised application layer cannot wander into another tenant's wallet or documents.
• SECURITY-DEFINER procedures carry their own checks — the procedures that move money, hold funds or change state verify the caller, the identity and the ownership inside their own body, so a privileged function cannot be called by an unauthorised user through a puzzle of arguments.
• Least privilege is a property, not a promise — identities, tokens and roles are scoped to the minimum, and the grants are declared so 'who can do this?' has a file, not a rumour.
• Admin and support are separated by design — the role that can change settings cannot necessarily approve payouts, and the roles that can read logs cannot necessarily transfer revenue; money decisions are intentionally split.
• Ownership is the ultimate gate — a user may only delete their own account, read their own transactions, or manage their own wallets; the object-reference attack dies at the ownership check that travels with every query and every procedure.

Authorization is the difference between a user and a wanderer. We build the walls in the database, so the truth survives a buggy app, a confused developer and a malicious client alike.

09

The database as the last wall

Every layer above the database can have a bug today; the database is the layer the money actually lives on, so it carries the hardest defenses. Row-level security keeps rows owned, SECURITY-DEFINER procedures keep the money-moving logic a single verified path, and constraints make an impossible state unrepresentable. This is where our money platform's security is actually enacted, not described.

• RLS is the ownership enforcement — every money table carries policy 'you may see your own rows', and the policies are declared with the schema so they cannot drift silently; a user's read of another tenant's wallet fails at the database, however the query is shaped.
• The ledger writes only through procedures — balances and journals change through server-side procedures that lock, verify and audit in one atomic act; a direct insert, update or delete from outside is refused by the database itself.
• Balance constraints are the floor — a CHECK constraint makes a negative balance unrepresentable even if every higher layer fails at once, the final wall behind the pre-flight check and the atomic decrement.
• Locks make races impossible — FOR UPDATE row locks ensure two concurrent payments physically cannot decrement the same available balance, and advisory locks keep the money crons from double-running.
• Audit rows are born with the money — every movement writes actor, timestamp, reference and outcome in the same transaction as the balance change, so the trail and the money cannot be separated.
• The gatekeys live in the schema, not the app — KYC holds, subscription holds, escrow states and freeze flags are enforced in the procedures the database runs, so a client or a compromised app cannot click past a hold that protects real money.

If a platform's security only lives in the application, its security lives as long as the application's best day. We put the walls in the database so the money is safe even on the worst day.

10

Secrets management: the moat around the machine

The gateway credentials that move real money, the signing keys that prove callbacks, the database passwords that unlock the ledger — a leaked secret is not a configuration problem, it is a found door. We treat secrets as the moat around the entire platform, and the discipline is absolute.

• Zero secrets in the repository — API keys, gateway credentials, signing secrets and database passwords never appear in code, config or history; a leak is treated as an incident, not a shrug.
• Secrets are injected from a managed store — functions and services receive credentials at runtime from a vault with access controls and rotation, so the credential never travels through a config file or a container layer.
• Gateway keys are the crown jewels — on the M-Pesa platform the Daraja consumer key, the verification secrets and the signing material are managed, rotated and audited with the discipline reserved for actual money keys.
• Rotation is a routine, not a panic — keys rotate on a schedule, the pipeline re-verifies after rotation, and a suspected compromise means rotating now and auditing the window, because a leaked key for money is a loss multiplier.
• Least privilege reaches the store — each service reads the secrets it owns and nothing more; a compromised frontend cannot read the gateway secret, because it was never granted the right.
• Per-environment secrets are alien to each other — test keys cannot sign production callbacks and staging cannot move real money; the blast radius of one leaked environment stays inside that environment.

Every serious breach narrative starts with a secret that was managed casually. We make secrets the most defended entry-point in the platform, because on a money platform they are.

11

Encryption at rest and in transit

Encryption is the guarantee that stolen data is a bust, not a jackpot: seizing a disk, a backup, a logs export or a network capture yields ciphertext, not customer money or identity. We apply it in both directions, everywhere it matters, with the keys managed and rotation rehearsed.

• In transit is mandatory and terminal — TLS everywhere, from the app to the API to the gateway, with modern protocols only; there is no address where a customer's money travels in plaintext, whichever rail carried it.
• At rest is the baseline, not the upgrade — databases, backups, object storage and documents are encrypted with managed keys, so the physical media of the platform is a locked box by default.
• Sensitive columns earn column-level care — hashes for passwords, and where the schema must hold a verifier, the value stored is never the value that must be protected.
• Keys are managed, not orphaned — encryption keys live in the key manager with rotation and access logs; an encrypted backup whose key is lost is a data-lost event, so key custody is an explicit discipline.
• Backups inherit the encryption — a backup is encrypted with its own managed key, because backups are the most stolen, least defended and most valuable copy a platform owns.
• The threat model decides coverage — not every byte is equal; the coverage is decided by what the loss costs, and on a money platform the answer is: the money data and the identity data lose the most, so they are encrypted without exception.

Encryption does not stop the thief; it stops the theft. We make the seized data worthless so attackers chase easier targets — and on money platforms, there are none easier than a careless neighbor's.

12

The money paths get the hardest protections

Beyond the general defenses, the surfaces that move cash carry protections nobody else gets: rate limits as financial controls, verification against the gateway before trust, escrow and holds against the abuses money attracts, and freeze paths for the account that has turned hostile. Every one of these is structural, running always, not a checkbox anyone has to remember.

• Rate limiting is a financial control — every money action carries a per-user, per-action window (5-second budgets on the payments platform) at the gateway and inside business logic, so a CDN bypass, a script or a fast finger cannot outrun the ledger.
• Callback verification is the money gate — a payment callback is treated as a claim, not proof, on every rail; the backend asks the gateway's own verification/query API, and only a genuinely verified result settles the money. A forged callback — whether it mimics a Daraja message, a card webhook or a bank-transfer notification — finds an empty pocket.
• Escrow and holds protect both directions — money for a hold (KYC, subscription, dispute, unverified recipient) is moved available-to-locked at initiation, consumed on success, released on failure, so a balance is never spendable twice.
• Self-dealing is blocked structurally — the platform rejects paying yourself through a peer-to-peer rail, recycling a promotion for your own benefit, or fabricating a referral that pays you; recipient checks and participation rules make the exploit fail before the money moves.
• KYC gates the exits — unverified recipients, large withdrawals and payouts to unknown parties meet the KYC gate with holds, refund schedules and honest user messaging, protecting the platform from being laundered and the honest user from being robbed.
• Freeze and unfreeze are first-class — a flagged account can be frozen with the owner informed and a clear path back; and the freeze state is enforced by the database procedures, so 'frozen' is not a UI state that can be clicked past.

These are the protections our own platform actually runs, hourly, against real money. The money paths get the hardest protections because they are the paths where the damage is measured in shillings.

13

The social-engineering reality of Kenya: M-Pesa scams

The most successful attacks on Kenyan money never touch an API. They are the phone call that pretends to be a bank, the KYB alert that asks the shopkeeper to 'confirm' a code, the 'your M-Pesa has been credited, share the reversal PIN' script, the fake goods on a marketplace. Social engineering defeats every technical control the moment a human completes the scam. We engineer the platform and the user journey so the human has fewer levers to pull against themselves.

• The interface teaches the truth — confirmation screens name the recipient, the amount and the fee before money moves, and the payment surfaces show the real business name so 'confirm the transfer to Mr. Fake' is visibly wrong.
• Codes are never asked for, ever — no legitimate flow asks the user to share a code, read back a PIN, or 'reverse' a transfer to a stranger; the product's own flows never condition users into the script the scammers run.
• Suspicious behaviour is presented as a question, not an answer — when a flow looks like a known scam shape, the product stops and asks, rather than completing the action and letting the human sort it out after the money is gone.
• Support is trained to the reality — the humans who answer 'my M-Pesa is stuck', 'someone is calling pretending to be you', 'I shared my code' are drilled in the actual scam scripts, because the first real defense is the person who hears the panic.
• The platform names impersonation as a threat — users are warned in-app, in emails and at checkout that no official account will ever ask for a PIN or a code, making the brand itself a harder costume to wear.
• We reduce the damage of the inevitable — for the user who did fall for a script, the platform makes freezing, reporting and support swift, because the honest measure of social-engineering defense is not 'never scammed' but 'caught fast'.

On a money platform, the human is in the security perimeter — so the perimeter must be built to help the human rather than trick them. We build the technical walls, and we build the user knowledge that makes the social attacks bounce.

14

Defensive monitoring and detection

Prevention without detection is optimism: the attack you fail to stop is discovered only by whoever finds the money missing. Defensive monitoring is the radar — watching the logs, the money path, the authentication failures, the rate-limit trips and the anomaly shapes, and escalating to humans in minutes, not weeks.

• Detect at the edge and the core — gateway endpoints and the ledger procedures log their own security events, so a forged callback and a double-spend attempt both leave forensic footprints where they happened.
• Authentication is watched like a health signal — login failures, OTP storms, device floods and enumeration patterns trip thresholds that page a human, because an attacker rehearsing login is an incident in progress, not analytics.
• The money path is monitored for shape — deposits, settlements, withdrawals and their success rates are charted; an anomaly in the shape of money (a withdrawal spike, a deposit thunder run) is an alert before it is a loss.
• Rate-limit trips are reviewed, not ignored — every time a financial control fires is a signal; some are user frustration, some are the platform being tested, and the difference is a human review, not a log that rots.
• Audit trails are queryable by the defenders — the security engineer can ask 'what happened with this wallet in the last hour?' and get the answer from the immutable trail, because incident response is mostly honest history.
• Detections are tested like code — a detection that never fires and an alarm that always fires are both failures; we inject the attack shapes periodically to prove the radar actually sees them.

Every platform gets attacked; the difference between a scare and a catastrophe is how soon anyone knew. We make detection the kind of discipline that finds the breach before the customer does.

15

Incident response: runbooks, roles and the first fifteen minutes

An incident is not the moment the alert fires; it is the moment the organization decides what an alert means. Incident response is a rehearsed machine: roles assigned, runbooks concrete, communication approved, evidence preserved, recovery measured. For a money platform, the first fifteen minutes are the difference between a contained event and a frozen-wallet catastrophe.

• Roles are named before the incident — there is a commander, a communications owner, a technical lead and a recorder, and everyone knows their seat from the drills, not from the emergency.
• Runbooks are concrete, not conceptual — 'verify the callback was replayed' carries the actual queries, the actual rollback step and the actual freeze command; a runbook that ends with 'investigate further' is a poem, not a procedure.
• The first response is containment, not root cause — stop the bleeding first (freeze the account, revoke the key, hold the payout), explain second, and for a money platform containment often means 'stop the money moving' instantly.
• Evidence is preserved by policy — the forensics timeline, logs and audit rows are captured read-only from the first moment, so the investigation is honest and the regulator can be answered without reconstruction.
• Communication is pre-approved — the internal page, the user-facing notice and the regulatory notification each have a drafted shape, so 'what do we say' never stalls the response while money is in motion.
• Post-incident is rehearsed too — the review produces the root cause, the fix, the test and the detection update, and the drills run again, because the second occurrence is the failure the first was supposed to prevent.

An incident is a rehearsal with real consequences. We rehearse with fake consequences until the real one is handled by muscle, not improvisation.

16

Penetration testing cadence and honest limits

Penetration testing is the closest thing security has to a fire inspection: a qualified adversary with a scope, a budget and a deadline tries to break what you built. We run it on a cadence, treat findings as engineering requirements, and pair it with the honest truth that a pen test proves what a test can prove — not that the platform is finished.

• Pen tests run on a cadence, not a one-off — a test before launch is a ceremony; a test every major release cycle is a discipline; the findings are triaged into the backlog like any other defect.
• The scope models the real attacker — we scope tests against the actual public surface (the app, the APIs, the gateway callbacks) the way the real attacker sees it, not the way the audit committee imagines it.
• Findings are prioritized by reachability, not severity — a 'high' finding in a place nobody can reach is below a 'medium' finding that moves money; the platform's risk is the map, not the scanner's vanity.
• The retest is part of the engagement — findings are fixed and retested until closed, because a pen test report with open high findings is a brochure for a breach, dressed as reassurance.
• Internal testing runs continuously — the dependency scans, the code review gates, the money-test rehearsals and the security tests in CI are the pen test's everyday sibling; the annual exercise proves what the daily one has kept true.
• The honest boundary is stated — a pen test proves no exploitable path was found within its scope and time; it does not prove tomorrow's attacker is today's nothing — so monitoring and response remain permanent organs of the platform.

A pen test is a snapshot of the wall at one moment, taken by one crowd of climbers. We take snapshots on a cadence, repair what they reveal, and stay honest that the wall must be watched every day regardless.

17

Secure delivery: dependency, supply chain and the pipeline

Attackers increasingly skip the target and compromise the road to it: a poisoned dependency, a hijacked build, a compromised container registry, a CI vault with too many keys. Supply-chain security is the discipline of protecting the delivery itself, and on a money platform the deployment pipeline is itself a money surface.

• Dependencies are scanned at build time — every dependency and its transitive graph is checked in CI, and a vulnerable library fails the gate before it ever reaches the artifact.
• Artifacts are signed and verified — what ships is verifiably what was built, so a compromised registry or a swapped image cannot wedge into production undetected.
• Least privilege rides the pipeline — CI tokens can build, deploy roles can deploy, and the payment function can only reach its own endpoints; a compromised pipeline cannot become a compromised everything.
• Registry and base images are curated — verified base images and pinned, reviewed versions replace 'latest' chaos, because the supply chain allows no anonymous imports into a money platform.
• Build reproducibility is itself a defense — a rebuild from the same inputs produces the same artifact, so a tampered build is a detectable anomaly, not an indistinguishable surprise.
• The vendor and human surface is modelled — the people and vendors with keys to the platform are reviewed, limited and audited, because the supply chain includes the person with access, not only the package with a URL.

The strongest wall is worthless if the road in front of it was bought with a poisoned brick. We protect the delivery road the way we protect the platform it delivers.

18

Evidence delivered with the build

Security you cannot prove is security you cannot defend in front of a customer, a partner, an investor or a regulator. The deliverable of a security engagement is not only the fortified platform — it is the evidence: the documentation, the audit trails, the test results, the review notes and the threat model, all of it written to be read by the next engineer and the next auditor.

• The threat model is a living document — the named adversaries, the defended assets and the decisions are written down and updated, so a new engineer inherits the reasoning, not a mystery.
• Security documentation ships with the delivery — architecture notes, the authorization model, the secrets policy and the incident runbooks arrive as part of the build, not as a separate 'ask us later' engagement.
• Audit trails are immediate — the platform answers 'who did what and when' natively from the ledger and the action logs, because the audit is a feature, not an afterthought project.
• Review notes survive as decisions — the security review of every change is a record, so 'why is this endpoint open?' has a written answer and an owner who reviewed it.
• The compliance answer is rehearsed — the artifacts a regulator or an auditor would request (logs, grants, encryption configuration, incident history) are assembled as a matter of routine, not discovered on the day of the meeting.
• Honest evidence includes the open questions — the document records what is known, what is assumed and what is still to be verified, because a security posture you can interrogate is one you can actually defend.

Security that lives only in memory dies with the memory. We deliver the evidence that lets your security posture outlive every person who built it.

19

The honest truth: no system is finished securing

We will say plainly what the industry rarely does: there is no such thing as a finished or fully secure system. The gateways change, the attacks change, the staff change, and every release opens a new inch of wall. What we sell is not 'completeness' — it is a permanently-running discipline that treats each change, each scan and each incident as another training step toward a platform that fails safely.

• 'Secure' is a property of the process, not an endpoint — the platform that is genuinely safe is the one whose team keeps running the threats, the tests and the drills, not the one that once passed an audit.
• Attackers iterate; defenses must too — the playbook from last year's incident is last year's; the cadence of pen tests, dependency scans and threat-model reviews is the actual security posture.
• The human layer never retires — software can be patched; a trained staff, an honest support queue and a user who knows the scam scripts are the walls that never get a CVSS score, and they must be maintained as deliberately as any code.
• Perfect is the enemy of survivable — we aim for fail-safe, measured, detected and recoverable, because a system engineered to fail gracefully outperforms a system engineered to be perfect that never is.
• Compliance is a floor, not a ceiling — meeting a standard proves nothing beyond meeting it; the engineering above the floor is what stops the attacker who did not read the standard.
• The honest offer is the daily discipline — we will tell you the truth about your posture, fix what can be fixed now, wire the monitoring for what will be found later, and keep the discipline running for as long as the platform runs.

The most dangerous security claim is 'we are secure.' The most honest is 'we are watching, we rehearse the failures, and we keep improving.' That is what we actually deliver — the watching, the rehearsing and the improving, on a platform that moves real money.

The toolchain

The Cybersecurity toolchain

The same classes of defense that keep our payment platform — where a leaked key moves real money and a forged callback costs real cash — hardened and watched. Every tool exists because an attacker taught us it was needed.

Lifecycle

The Security lifecycle — from threat model to watched platform

Security is a standing discipline, not a launch-week sprint. This is the arc every platform we secure passes through — and the one our own money platform is permanently travelling.

Closing

More than development

Security is not the department that says no; it is the engineering discipline that lets the whole platform say yes — safely, provably and for real money. The work we bring to clients includes:

A platform that moves money is a promise that is attacked every hour, by people who know exactly where the money is. Securing it is not a project; it is the running state of the business.

We have hardened a live M-Pesa platform after real attacks — and we keep hardening it. When your platform needs security that has survived contact with the real world, that is what you get.