Once a year wasn’t going to cut it
At OSec it’s not unusual to work with financial-services companies to determine the risk posed by adversaries. A recent engagement with FNZ — a global wealth-management platform managing around $1.4 trillion in assets — proved the value of continuous penetration testing. Traditionally, pen testing happens once a year, or as a point-in-time exercise. FNZ opted instead for the ongoing assessment its Incenter platform provides, which is considered a game-changer in the industry.
A client’s gate, cleared in a day
FNZ runs Incenter continuously against its own platform, and the always-on setup also proved its worth outward. One of FNZ’s clients had made an independent security attestation a contractual condition of taking an application live: the application couldn’t ship until it passed a clean test. FNZ had to produce that attestation on a tight deadline, and a traditional pen test would take weeks. Because Incenter was already running, OSec added the application to the platform within 24 hours, with remediation guidance almost immediately; everything was in scope within a couple of days, and the final findings were delivered.
“Incenter is a total game changer in the market. There are only a handful of companies doing continuous pen testing, but OSec’s model is completely different from anything I’ve seen.”
One finding, in detail
Speed only counts if it catches the things that matter. In the same testing that cleared the attestation, OSec surfaced a high-severity race condition in the platform’s bulk-trading flow: a logic flaw that only shows up under real concurrent use, and a serious one when it does.
The checkout step assumed a balance check and the trade that followed it would happen in order. Fire several trade requests at the same instant and they slip past that single check before it settles: a time-of-check to time-of-use gap (CWE-367). The parallel requests bypassed the internal balance-validation logic, and the result was blunt: you could take more money out of an account than it held, driving the available balance below zero.
- Class: time-of-check to time-of-use (TOCTOU) race condition, CWE-367.
- Severity: High. CVSS 4.0 base score 7.0 (CVSS:4.0/AV:N/AC:H/AT:N/PR:H/UI:N/VC:N/VI:H/VA:N/SC:N/SI:H/SA:H).
- Effect: concurrent requests bypass the balance check, letting a user take more money out of an account than it holds and pushing the balance below zero.
Why it matters. On a trading platform an overdraw is not cosmetic. It breaks the rule the whole system rests on, that you cannot spend money you do not have, and it leads straight to reconciliation failures, disputed transactions and lost trust. Race conditions are dangerous because each request looks legitimate on its own; the flaw shows up only when several land together, which is how it slips past checks that reason about one action at a time. Anything that leans on a state check, a uniqueness rule or a resource count is open to the same pattern.
How it was fixed. The remediation was concurrency control on the server: bind the balance check and the debit into one atomic, transactional operation, and hold a server-side lock over that section so parallel requests are serialized instead of raced. Client-side sequencing does not help, since the client is exactly what the attacker controls. With the check and the change tied together and isolated, the outcome no longer depends on request timing, and the fix was re-tested to confirm the window had closed.
A $2M penalty that never landed
The exposure sat with FNZ. Miss the deadline and it couldn’t clear the client’s security gate, the application wouldn’t go live as agreed, and FNZ’s contract carried a $2 million penalty if that happened. Instead the attestation cleared on time, the required level of security was confirmed, and the penalty never landed. Any firm whose customers make a security sign-off a condition of doing business faces the same clock, and the same exposure when testing can’t keep up.
It’s evidence of a shift in the industry: organizations need an ongoing view of threats and vulnerabilities. OSec noted that paradigm shift and built Incenter for it — transitioning from traditional point-in-time pen tests to continuous security assessment, averting crises before they can even arise.