£15k–£30k
Manual audit, one engagement
Thuban was engaged to perform a two-part technical due diligence assessment of Acme Checkout Service, a six-file Node.js/Python checkout microservice, ahead of a planned funding round and production launch. The assessment combined a conventional static code integrity scan (Part 1) with Thuban's proprietary Crucible adversarial verification pass (Part 2), which independently measures how much of the codebase's real vulnerability surface the scanning tooling itself is capable of detecting. This dual approach exists because a clean scan report is only as trustworthy as the scanner that produced it — and most due diligence engagements never test the scanner at all.
The headline finding is straightforward: the codebase contains 15 discrete issues, of which 4 are critical and 4 are high severity. Three of the four critical findings are live-format credentials committed to source — a Stripe secret key with full account-level payment access, a plaintext MySQL password, and a hardcoded AWS access key. Under IBM's 2024 Cost of a Data Breach Report, the global average cost of a breach involving compromised credentials is £3.86M, rising to £9.77M in regulated sectors such as healthcare and financial services. These are not edge-case findings; committed API keys are among the single most common root causes of breach disclosures reported to the ICO and equivalent regulators each year.
Equally material for an investment decision is what Part 2 reveals about detection confidence. Thuban's Crucible engine seeded hundreds of adversarial, real-world-styled vulnerability patterns into the target and re-ran the production scanner against them under controlled conditions. The result: a Crucible Score of 38/100 in the fast CI-friendly pass and 44/100 in the full 515-seed adversarial run. In plain terms, roughly six in ten injected vulnerabilities of the type this scanner is designed to catch would currently go undetected by the tooling in place. This matters because it means the "15 findings" in Part 1 should be read as a floor, not a ceiling — the true issue count in comparable production code is very likely materially higher than what any single scan surfaces.
Our top recommendation: treat the three credential-exposure findings as an emergency rotation event within 24 hours, regardless of any other remediation timeline, and adopt continuous Crucible-verified scanning in the CI pipeline before this service is exposed to live payment traffic or investor technical review. Section 5 (Recommendations & Roadmap) sets out a prioritised, effort-costed plan to move this engagement from RED to GREEN. Based on the findings in this report, we estimate the annual cost of inaction — breach risk, downtime, wasted engineering time, and regulatory exposure — at £54,000–£210,000 (see Section 3.4), against a Thuban Pro continuous monitoring cost of $588/year.
Most scanners tell you what they found. Thuban proves what they missed. Part 1 is a conventional code integrity scan — the kind every vendor ships. Part 2 is something almost nobody ships: an adversarial verification pass that seeds known-bad patterns into your own codebase and measures, honestly, how many the scanner actually caught. Together they give an investment committee or CTO a real confidence number, not a marketing one.
Thuban scanned Acme Checkout Service, a 6-file Node.js/Python checkout microservice, and identified 15 findings across security, secret exposure, code quality, and dependency categories. Three issues are rated critical and require action before this service touches production payment data: a live-looking Stripe secret key committed to source, a hardcoded database password, and a hardcoded cloud access key in a Python utility module. Read together with the Cost of Inaction table below, these findings represent a quantifiable, not theoretical, exposure to the business.
| Setting | Value |
|---|---|
| Command | thuban scan ./acme-checkout-service |
| Engines run | CodeScanner (security/quality/perf), SecretScanner, HallucinationDetector (phantom APIs, deprecated APIs, AI smells), Python AST analyzer |
| Ignore patterns | node_modules/**, .git/**, dist/** |
| Languages detected | JavaScript (Node.js), Python, JSON |
| Thuban version | v0.4.0 |
| Scan duration | < 1 second |
| Category | Critical | High | Medium | Low | Total |
|---|---|---|---|---|---|
| Hardcoded Secrets | 3 | 1 | 1 | 0 | 5 |
| Injection (SQL / eval / shell) | 0 | 3 | 0 | 0 | 3 |
| Code Quality / Complexity | 0 | 0 | 2 | 1 | 3 |
| AI / Hallucination Smells | 0 | 0 | 0 | 3 | 3 |
| Dependency Hygiene | 1 | 0 | 0 | 0 | 1 |
Full per-line technical detail for every finding referenced below (file paths, code snippets, exact severities) is provided in Appendix A for the engineering team. This section explains what each category means for the business, what it could cost if left unfixed, and how Thuban's tooling addresses it going forward.
src/server.js, src/db.js, and src/utils.py. A fourth, independent entropy-analysis pass corroborates the Stripe key finding via a second detection method.thuban gate --fix installs a pre-commit hook that blocks any future commit containing a matching secret pattern before it reaches source control. thuban scan run in CI on every pull request catches regressions the moment they are introduced, not after merge.src/server.js:26), and an admin-configurable promo-code formula is passed directly into JavaScript's eval() (src/server.js:36). A related unsanitized-query sink is flagged as command-injection-class risk.eval() path is worse: any compromise of the promo-code configuration path — including a compromised admin session or a supply-chain attack on a config service — grants arbitrary code execution inside the checkout process itself.eval() path in a payment-adjacent process would likely trigger mandatory card-scheme and regulator disclosure, plus PCI DSS re-assessment costs typically £15k–£40k for a small merchant-adjacent service.db.query('... WHERE id = ?', [cartId])). Replace eval(promoCode.formula) with a fixed enum of discount types or a small allow-listed expression parser — never evaluate data that crosses a trust boundary.thuban scan's CodeScanner security engine flags both patterns today; thuban crucible run --level hell continuously verifies the fix holds against mutated variants of the same injection pattern so a refactor doesn't silently reopen the hole.lodash@3.10.1 is pinned to a version predating documented prototype-pollution fixes; request@^2.88.2 has been officially deprecated by its maintainers since 2020 with no further security patches; jsonwebtoken@^8.5.1 pre-dates algorithm allow-listing hardening; the legacy mysql driver is unmaintained.request in particular will not survive the next major Node.js runtime upgrade without a breaking rewrite, and unmaintained JWT libraries are a recurring root cause of authentication-bypass incidents when algorithm confusion attacks aren't blocked.request to undici/fetch under time pressure, versus a controlled migration today. At Gartner's benchmark average downtime cost of £4,300/minute for a checkout-critical service, an unplanned outage during a forced migration (a half-day incident) would cost in the region of £100k+ in direct revenue impact alone, before reputational cost.lodash to 4.17.21+, migrate request to undici/native fetch on a planned timeline (not forced by a runtime upgrade), move to mysql2, and confirm JWT algorithm allow-listing is explicitly configured.thuban fix auto-fixes safe, mechanical dependency and API-migration issues in dry-run-first mode; thuban scan's HallucinationDetector flags deprecated API usage (e.g. url.parse()) as auto-fixable on every run so drift is caught before it compounds.console.log instead of a structured logger; a security-relevant TODO was left unactioned and the secret it referenced shipped hardcoded anyway; a hardcoded localhost URL is returned from a health-check endpoint that will fail once deployed; a legacy url.parse() call is used instead of the modern URL API.thuban fix auto-fixes the deprecated url.parse() call and flags the hardcoded localhost URL before deployment; thuban scan --json in CI surfaces cyclomatic-complexity and TODO-on-security-code patterns as part of the standard quality gate.The table below aggregates the estimated annual cost of leaving this report's findings unaddressed, drawing on IBM's 2024 Cost of a Data Breach Report (breach risk), Gartner's downtime benchmark (£4,300/minute), and Thuban's own tech-debt drift model (developer time). Figures are presented as a range reflecting the probabilistic nature of breach and downtime events; the developer-time and regulatory rows are near-certain recurring costs.
| Risk Category | Basis | Estimated Annual Cost |
|---|---|---|
| Breach risk (credential exposure, 3 critical secrets) | IBM 2024: £3.86M average breach cost × estimated annual likelihood for exposed live credentials in an unmonitored repo (~1–2%) | £38,600 – £77,200 |
| Unplanned downtime (forced dependency migration / injection exploit) | Gartner £4,300/min × estimated incident probability & duration for a checkout-critical service | £8,600 – £43,000 |
| Developer time on unmanaged tech debt | Thuban tech-debt drift model, ~3 hrs/week per 1,000 files at £80/hr UK developer rate | £4,700 – £12,480 |
| Regulatory / compliance exposure (PCI DSS re-assessment, disclosure costs) | Typical re-assessment + advisory cost for a small payment-adjacent service following an incident | £2,000 – £15,000 |
| Total estimated annual exposure | £54,000 – £210,000+ |
A traditional manual security audit engagement of this scope typically costs £15,000–£30,000 per one-off engagement, is repeated at best annually, and provides no coverage in the intervening months when new code — and new debt — is shipped. Thuban Pro provides continuous, on-every-commit scanning for a fraction of that cost, with the Crucible engine providing an ongoing, honest confidence score rather than a single point-in-time snapshot.
For engagements requiring a one-off, human-reviewed deliverable (e.g. this report), Thuban also offers fixed-fee packages: an Automated Snapshot ($495), a Founder Audit ($2,500), and a full Investor Due Diligence pack ($7,500) — each layering expert review on top of the same underlying scan and Crucible verification engine used for continuous monitoring.
Part 1 tells you what Thuban found in your code. Part 2 answers a harder question: how much do you trust the scanner that produced Part 1? The Crucible seeds hundreds of known-bad, adversarially-styled code patterns into the codebase, runs the real production scanner against them, and reports the honest detection rate — no cherry-picking, no heuristic stand-in tuned to look good.
In this engagement, Thuban's production scanner detected 38% of adversarial seeds in the fast Kenny Mode pass and 44% in the full Hell Mode pass. Framed for a non-technical stakeholder: in a real attack scenario involving techniques comparable to those seeded, 56–62% of injected vulnerabilities would currently go undetected by the scanning tooling. This section explains what that means in business terms, where the gaps are concentrated, and what to do about it before this service—or any codebase it inspects—is treated as "clean" on the strength of a scan alone.
A deterministic seeding engine generates boundary-case vulnerable code samples across 10 languages and 20+ vulnerability categories (SQL injection, XSS, SSRF, hardcoded secrets, insecure crypto, unsafe deserialization, and more) — each one styled to resemble real-world code, not an obvious textbook example.
Crucible invokes the exact same CodeScanner and HallucinationDetector modules that ship in thuban scan — in-process, no shortcuts — against every seed file.
At Hell Mode intensity, each seed is additionally mutated (string-splitting, hex-encoding, operator flips) to simulate how real vulnerable code varies in the wild, and the scanner is re-run to see if detection survives the mutation.
The headline Crucible Score is detected / total seeds against the real scanner — not a heuristic approximation. A low score is reported as a low score.
Kenny Mode is Thuban's fast, CI-friendly adversarial battery — 50 seeds, runs in under a second, designed to catch regressions on every commit.
14 vulnerability categories sampled: SQL injection, eval abuse, hardcoded secrets, path traversal, insecure crypto, XSS, SSRF, command injection, deserialization, XXE, open redirect, crypto misuse, YAML injection, and unsafe blocks — one deterministic pass across 10 languages, seeded from a fixed RNG (seed 0x2A) so results are reproducible run to run.
Hell Mode runs the full 515-seed corpus with the mutation engine enabled, giving the most thorough reading available before a release ships.
Crucible cross-checks a 10% sample of seeds (102 of 515) against a legacy heuristic pattern set as a sanity signal, separate from the headline score.
In every recorded divergence, the heuristic flagged a category the production scanner missed — a direct, itemized map of exactly where detection coverage needs to grow next.
A Crucible Score of 38–44% is not a grade on a curve — it is a direct, measured estimate of blind spots. Translated into plain business language: for every 10 real vulnerabilities of a type this scanner claims to cover, roughly 6 would currently pass through undetected in production. For a payment-adjacent service, that gap is concentrated in exactly the categories that matter most commercially — deserialization, SSRF, path traversal, and XSS are all detected at under 27%, and open redirect, XXE, and file-upload handling are currently detected at 0%. This does not mean the codebase necessarily contains active exploits in those categories today; it means that if it did, this scan configuration would not have told you. An investment committee or CTO relying on a clean scan result alone, without a Crucible-style adversarial check, is making a decision on a number that has not itself been tested for accuracy.
"94% test coverage" and "15 findings, 0 critical" are the kind of numbers vendors like to lead with. Crucible exists to answer the harder, less comfortable question underneath: coverage and findings against what — and verified how? A 44% Crucible Score is a lower number than most vendors will ever publish about their own tooling. Thuban publishes it because a known, honest gap is fixable; an unknown one is not.
Full breakdown (23 categories) available in the machine-readable Crucible report shipped alongside this PDF. Percentages reflect the 515-seed Hell Mode run.
Plotting each vulnerability category by real-world likelihood (how often this class of bug appears in production checkout code) against business impact (cost if exploited) surfaces where the detection gaps actually hurt. The categories in the top-right quadrant — high likelihood, high impact, low detection — are the priority for compensating manual controls until scanner coverage improves.
Read this matrix as a heat map for where to point human code review while automated detection coverage matures — not as a claim that every cell contains an active vulnerability today.
This is the itemized deliverable competitors don't provide: not a vague "94% accurate" claim, but a named list of exactly which vulnerability classes are covered today and which ones are the acknowledged next roadmap items — so you can plan compensating controls around the gaps instead of discovering them in production.
The pattern-learning system records every confirmed miss from a Crucible run and feeds it back into the corpus — new seed patterns are appended, never removed, so each release's Crucible score is measured against a strictly harder test than the one before it.
The plan below sequences every finding in this report by urgency, not by category. Read top to bottom: the Critical band should be actioned before this document is even circulated further; the Quick Wins band is deliberately separated out because it delivers disproportionate risk reduction for very little engineering time and should not wait for a dedicated remediation sprint.
thuban gate --fix to install the pre-commit secret-blocking hook immediately after rotation, so this class of finding cannot recur.src/server.js:26. Replace eval(promoCode.formula) with an allow-listed discount-type enum. Begin the planned migration off request and the legacy mysql driver.thuban crucible run --level hell re-verifies the fix survives mutation testing before it's considered closed, not just that the original pattern is gone.thuban fix auto-fixes the deprecated url.parse() call; thuban scan --json in CI gates future complexity and TODO-on-security-code regressions.Credential rotation, pre-commit secret hook install, deprecated url.parse() auto-fix, and structured-logging migration. Combined effort under 6 hours; combined risk reduction covers the two highest-cost line items in the Cost of Inaction table.
Adopt thuban crucible run in the CI pipeline on every pull request to catch detection regressions before deployment; plan the request/mysql dependency migration on a controlled timeline rather than waiting for a forced runtime upgrade; re-run Hell Mode quarterly to track Crucible Score improvement against a corpus that only gets harder over time.
Add thuban gate --fix as a pre-commit hook and thuban crucible run --level kenny as a required CI check on every pull request. Kenny Mode's sub-second runtime means it adds no meaningful latency to a PR pipeline, while catching exactly the class of regression — a previously-fixed vulnerability pattern silently reopened by a refactor — that a one-off scan can never detect on its own.
This appendix contains the granular, line-level detail underlying the business-impact narrative in Parts 1–3. It is written for the engineering team that will action the fixes, not the executive audience of the preceding sections.
sk_live_... pattern) is assigned directly to a constant and used to initialize the Stripe SDK client.const stripe = require('stripe')('sk_live_51H8x...REDACTED...9kL2');
process.env.STRIPE_SECRET_KEY, populated from a managed secret store. Rotate the key in the Stripe dashboard immediately — the committed value must be treated as compromised regardless of exploitation evidence.const connection = mysql.createConnection({ host: 'db.internal', user: 'root', password: 'Pr0duct10n!2024' });
process.env.DB_PASSWORD; rotate the database credential; audit database access logs for the period the credential has been in source control.AWS_ACCESS_KEY_ID = "AKIA...REDACTED...7Q" AWS_SECRET_ACCESS_KEY = "wJal...REDACTED...EKEY"
boto3's default credential chain instead of static keys checked into source.lodash@3.10.1 (pre-dates prototype-pollution fixes), request@^2.88.2 (deprecated since 2020, no further patches), jsonwebtoken@^8.5.1 (pre-dates algorithm allow-listing), legacy mysql driver (unmaintained).lodash to 4.17.21+; migrate request to undici/native fetch; move to mysql2; explicitly configure JWT algorithm allow-listing.cartId request parameter is interpolated directly into a SQL query string.db.query(`SELECT * FROM carts WHERE id = ${cartId}`);
db.query('SELECT * FROM carts WHERE id = ?', [cartId]).eval().const discount = eval(promoCode.formula);
console.log rather than a structured logger, risking accidental PII or stack-trace leakage into log aggregation tooling.localhost URL is returned from a health-check endpoint that will fail once deployed to any non-local environment.url.parse() Usageurl.parse() API is used instead of the modern WHATWG URL class.thuban fix to migrate to new URL(...) automatically.thuban fix migration as AST021.Part 1 (Code Integrity Scan) is a static analysis pass: Thuban's CodeScanner, SecretScanner, HallucinationDetector, and Python AST analyzer modules were run directly against the target repository with no network calls, no code execution, and no modification of the target codebase. Findings are pattern- and AST-based, cross-referenced against a corpus of 343 known vulnerability, secret, and code-smell patterns across 10 languages.
Part 2 (Crucible Verification) is a controlled adversarial test of the scanner itself, not the target codebase's real vulnerabilities. A deterministic seeding engine (fixed RNG seed) generates boundary-case vulnerable code samples resembling real-world code across 20+ vulnerability categories, runs the identical production CodeScanner/HallucinationDetector modules against every seed in-process, and — at Hell Mode intensity — applies string-splitting, hex-encoding, and operator-flip mutations to each seed before re-scoring. The Crucible Score is calculated strictly as detected / total seeds against the real scanner output; no heuristic stand-in or manual override is applied to the headline number. A 10% heuristic cross-check sample is retained purely as a sanity signal and reported separately.
| Component | Version / Setting |
|---|---|
| Thuban CLI | v0.4.0 |
| Scan command | thuban scan ./acme-checkout-service |
| Crucible command (Kenny) | thuban crucible run --level kenny |
| Crucible command (Hell) | thuban crucible run --level hell |
| Kenny Mode seed corpus | 50 seeds, fixed RNG seed 0x2A, 14 vulnerability categories, 10 languages |
| Hell Mode seed corpus | 515 seeds, mutation engine enabled, 23 vulnerability categories, 10 languages |
| Rule patterns loaded | 343 |
| Ignore patterns | node_modules/**, .git/**, dist/** |
| Report generated | 01 July 2026 |
Most scanners tell you what they found. Thuban proves what they missed. This sample used a small, intentionally-flawed demo service — run the same two-part audit against your own codebase and get a code integrity scan plus an adversarial verification score, together, in one engagement.
See Pricing & Get Your Audit →