Why we built a scanner commercial tools can't replace

GitGuardian detects 1,000+ secret types. TruffleHog runs 700+ detectors. Gitleaks ships with 100+ rules. None of them catch the Nigerian fintech provider stack, and the architecture of all three has a blind spot that affects every Nigerian fintech backend in production today. Here is what that blind spot looks like, why we built Securva's scanner to close it, and what we found in the first seventy-two hours of running it.

The problem with how secret scanners work

Your backend integrates with Flutterwave, Paystack, Monnify, WalletAfrica, Seerbit, and three Nigerian banks. Your config.js file has fourteen API credentials. You ran GitGuardian against your codebase, and it flagged two of them. The other twelve never got surfaced.

This is not a GitGuardian bug. Their detectors are correct for the providers they cover. The problem is architectural: every commercial secret scanner in the market checks for one provider at a time. When they find a Flutterwave key, they flag it and move on. They do not know that the same file contains thirteen more credentials sitting next to the one they found.

For a US SaaS startup with one Stripe integration in one service, this works perfectly. For a Nigerian fintech aggregator backend with fourteen payment provider integrations in one config.js file, it is a 7% detection rate, and a 7% detection rate is not a scanner - it is a false sense of security.

What commercial tools do well

Before explaining what we built, I want to acknowledge what commercial tools do well, because this matters for honest positioning.

GitGuardian detects over 550 distinct secret types with entropy-based verification, ML-driven false positive suppression, and enterprise-grade tooling. If you are a global SaaS company scanning a monorepo of microservices, GitGuardian is probably the right choice for you. Their coverage of Stripe, AWS, Salesforce, Slack, and hundreds of other universal providers is excellent, and their enterprise features (SSO, Jira integration, SOC 2 audit trails) are things Securva will not be able to match for years.

TruffleHog runs roughly 700 detectors with a feature we do not have: live verification. When TruffleHog finds a secret, it can optionally call the provider's API to confirm whether the secret is actually still valid. That is a genuinely useful feature, especially for security teams who get a lot of false positives from historical commits.

Gitleaks is the popular open-source scanner with 100+ default rules and a fast Go binary that scans gigabytes of git history in seconds. It is the right choice for a developer who wants a free pre-commit hook without signing up for a commercial product.

All three are excellent tools for their intended use cases. What they share is an architectural assumption: each scan finds independent, isolated secrets. That assumption breaks down for Nigerian fintech.

Why Nigerian fintech is different

A typical Nigerian fintech backend is an aggregator. One Node.js or Python or PHP application wraps multiple payment providers - Flutterwave for card payments, Monnify for bank transfers, Paystack for subscriptions, WalletAfrica for USD wallets, Seerbit for Pan-African reach - and routes customer traffic through whichever provider has the best uptime or lowest fees. This makes business sense. A Nigerian fintech does not want to bet their entire customer experience on one payment processor's availability.

But it means the backend's .env or config.js file has dozens of provider credentials, not one.

Commercial scanners were designed for the "one startup, one provider per service category" model. When they scan a Nigerian fintech aggregator backend, they find the first credential they have a rule for and stop. They report a single finding. The security team fixes that one finding and believes the job is done. Meanwhile, the same file contains thirteen more credentials for providers the commercial scanner has never heard of.

We found a real example of this during our research. One public GitHub repository with a single 38-line config/.env file leaked production credentials for sixteen distinct service integrations - ten payment processors, two Nigerian commercial banks, a production MySQL database, a KYC provider, a transactional email service, and an SMS gateway. The file had been public for nearly four years. Existing secret scanners would have flagged it as "1 Flutterwave leak," because that is the only rule any of them had for the Nigerian fintech stack. Nobody rotated the other fifteen.

Three things Securva does differently

1. Nigerian provider coverage

Securva is the only secret scanner that detects these providers out of the box. We verified this by checking each tool's published detector list against each Nigerian provider we care about.

Securva is the only scanner covering eleven or more Nigerian-specific payment providers, banks, and SMS gateways. This is a verifiable claim. You can check the commercial tools' published detector lists and confirm.

Why does this matter? The commercial vendors are not going to add Monnify to their default rule set. The total addressable market for a Nigerian-specific detector is too small for them to allocate engineering time. Our insight is that the Nigerian fintech market is big enough to matter for the Nigerian fintech community, even if it is too small for international vendors to care. That gap is the market niche Securva exists to serve.

2. Multi-provider density scoring

Every commercial scanner reports findings as a flat list. One credential per row. Fourteen credentials in one file become fourteen flat rows. The scanner does not know that those fourteen findings are all in the same file.

Securva does. We compute a credential density score per file and automatically flag any file with five or more distinct provider categories as CRITICAL, independent of the severity of any individual credential in the file.

Why this matters: a fourteen-credential aggregator file is not fourteen independent incidents. It is one systemic incident with fourteen blast radii. The remediation is not "rotate one key" - it is "rotate fourteen credentials across fourteen providers and audit the backend template that generated the leak." Commercial scanners miss this distinction entirely. In the 38-line file I mentioned earlier, GitGuardian would have reported "density 1" (one Flutterwave match). Securva scored it as "density 16, CRITICAL, systemic aggregator failure." The difference is the mental model, and it changes what a security team does next.

3. Owner expansion and template clustering

When Securva finds a CRITICAL hit on a public GitHub owner, we automatically enumerate all of that owner's other public repositories and scan them for the same patterns. This catches the freelance template reuse class of leak - where a developer builds the same backend template for multiple clients, and all the clients inherit the same hardcoded secrets.

We also detect template clone signatures across owners. When the same hardcoded value (like an AES master encryption key) appears in multiple repositories owned by different developers, Securva groups them as a single cluster representing the shared template's total blast radius.

This is how we recently discovered that one freelance developer had built five different gambling backends for five different clients, all sharing the same hardcoded Flutterwave secret key, the same Twilio auth token, the same SPENN API key, and the same AES-256-CBC master encryption key. Commercial scanners would have reported five independent incidents across five repositories. Securva reports one template-scale security failure affecting every operator who hired that developer. We also identified a second freelance developer - completely unknown to us until the signature search surfaced him - who uses the same AES master key in his own four gambling backend repositories. That is a new class of finding: not "one developer made one mistake" but "the same template code is being cloned across multiple freelance developers in the African gambling ecosystem." No commercial scanner catches this pattern.

Honest positioning

When to use Securva

Use Securva if you are:

• A Nigerian fintech integrating any local provider beyond Flutterwave and Paystack - Monnify, Seerbit, WalletAfrica, Providus, GTBank, SPENN, Kaleyra
• An African payments aggregator routing traffic through three or more providers
• A gambling or gaming backend built by a freelance developer from a template
• A Web3 or DeFi team worried about Ethereum private keys, BIP39 mnemonics, or Privy credentials in your codebase
• Already running GitGuardian or TruffleHog and want Nigerian-specific rule coverage on top

Use a commercial scanner if you are:

• Primarily integrating global providers like Stripe, AWS, or Salesforce
• Scanning a monorepo with thousands of microservices and needing breadth over depth
• Required by compliance to use a specific vendor with SOC 2 certification

The best setup for most Nigerian fintech teams is both: commercial scanner for universal coverage plus Securva for the Nigerian plus aggregator plus template gap that commercial tools structurally miss. We are not trying to replace GitGuardian. We are trying to close the vertical gap that GitGuardian will never close.

What we built in 72 hours

The Securva scanner went through eight versions in three days during the research sprint that produced this article. Version 1 scanned seven auth providers. Version 4.2 added depth-check and owner expansion. Version 4.3 added thirteen Web3 patterns including Ethereum private key detection, BIP39 mnemonic phrase detection, and Privy credential detection. The full evolution is visible in our private scanner repository, and the architectural decisions are documented in the commit history.

What we found with it, also in seventy-two hours, is the subject of several follow-up research posts that will appear on this blog in the coming weeks. Each one is gated on coordinated disclosure practice - vendors get notified first, given time to verify and remediate, and only after rotation is confirmed do we write about the findings publicly. That is how security research is supposed to work.

Nigerian fintech deserves tooling built for its actual ecosystem, not a global tool with a regional add-on pack bolted on. That is why Securva exists, and that is the gap we will keep closing one provider at a time.