PCI scoping that does not ship cardholder code to a third party.

Fintech and any merchant handling cardholder data has the same problem healthcare does, with extra teeth. PCI DSS Requirement 6 (secure software) and Requirement 11 (security testing) expect you to run a SAST tool against the codebase that handles cardholder data, and to keep evidence of that. The catch: uploading that same code to a vendor cloud potentially expands PCI scope to the vendor's environment. Most cloud SAST vendors are not in your QSA's pre-approved scope-reduction list, which means the audit conversation gets a lot longer.

Vulkro runs entirely on your machine, with no upload step, no account, and no vendor cloud. The PCI scope conversation stays exactly where it was before you added the scanner.

What PCI asks your codebase to prove​

A QSA assessing your application against PCI DSS 4.0 will ask two questions of the code itself:

1. Are you actually reviewing custom software for security bugs before each release? Hardcoded payment credentials, SQL injection on transaction endpoints, broken auth on the charge or refund routes, weak crypto on stored cardholder data. A SAST run pinned to a specific commit is what the auditor wants to see. The high-risk findings need to be fixed before the build ships, not merely tracked.

2. Are you re-running that check often enough to catch regressions? A one-time scan is not enough. The rescan loop needs to live in CI, with new high-risk issues blocking release and the existing backlog burning down on a separate cadence.

Vulkro covers both questions:

• vulkro scan finds the issues a QSA cares about: auth bypass on payment routes, SQL injection in the charge path, hardcoded PAN-shaped literals in source or fixtures, weak crypto on cardholder data sinks, plaintext API keys in code or git history.
• vulkro scan --ratchet is the rescan shape. Only new findings fail the build; the existing backlog tracks to closure on a separate cadence.
• vulkro compliance --profile pci (Free) and vulkro compliance-pack --framework pci-dss (Pro) translate the findings into the clause-by-clause language your QSA wants stapled to the audit binder. The output cites the exact PCI DSS 4.0 sections your evidence satisfies, so the reviewer can sign off without you having to translate.

Cardholder data flow scoping​

The hard part of PCI is scoping. Anything that stores, processes, or transmits cardholder data is in scope; the scope-reduction work is identifying which code paths can be proven to never touch cardholder data. Vulkro contributes to that mapping with three structural checks:

Hardcoded PAN-format detection. The secrets detector catches PAN-shaped literal strings in source code: the Luhn-valid 13-19 digit shape across Visa, Mastercard, AmEx, Discover, JCB, Diners, UnionPay prefixes. A literal PAN in code is a PCI-0001 finding with severity Critical regardless of context. This catches both deliberate test-fixture PANs that should be moved to a test-only fixture file and accidental hardcoded customer data committed during debugging.

Callout-credential audit for payment processors. Every payment processor SDK ships a credential boundary: a publishable key, a secret key, a webhook signing secret, an OAuth client secret. Vulkro recognises the credential shapes for:

• Stripe (sk_live_, sk_test_, whsec_, restricted keys)
• Braintree (production_, sandbox_, partner credentials)
• Adyen (live and test API keys, HMAC keys)
• Authorize.net (login ID and transaction key pairs)
• Square, PayPal, Worldpay, Checkout.com (each with their documented credential shape)

Findings differentiate between live and test credentials and flag any live credential committed to source. Webhook signing secrets get their own ID family because the failure mode is different (signature bypass, not direct theft).

Crypto weakness audit. PCI DSS 4.0 requires AES-128 (or stronger) for stored cardholder data and PFS-capable TLS for transmission. Vulkro's crypto_weakness family detects:

• MD5, SHA-1, DES, 3DES, RC4 used on any path tagged with PAN / cardholder data shapes.
• AES used in ECB mode or with a hardcoded IV / key.
• TLS configurations that omit PFS-capable ciphersuites or accept TLS 1.0 / 1.1.
• Random-number sources for nonce / IV generation that use non-CSPRNG sources (e.g. Math.random for an HMAC nonce).

The cross-reference to PCI 3.4 (rendering PAN unreadable), PCI 3.5 (cryptographic key management), and PCI 4.1 (transmission encryption) is in the compliance mapping.

Salesforce Financial Services Cloud (Pro)​

Fintechs running on the Salesforce platform get the Financial Services Cloud detector pack under the same Pro license. FSC ships its own SObjects (FinServ__Account__c, FinServ__FinancialAccount__c, FinServ__InvestmentAccount__c) with regulated data shapes, and its Compliant Data Sharing mechanism uses AccountShare records with AccessLevel = 'Edit' or 'All'. A request-reachable Apex method that writes that share with caller-controlled inputs is the FSC equivalent of an unscoped grant. The pack catches that pattern (rule IND-006), the FSC permission-set group misuse (IND-002), and PHI / PII flowing through @AuraEnabled returns (IND-005).

Heroku-hosted fintech apps that mirror the Salesforce general ledger into Postgres are covered by the Heroku Connect detector pack: account number and SSN columns replicated without a redaction transform, plaintext postgres:// URLs in committed app.json, and write-back conflict policies missing on FinServ__FinancialAccount__c. These are the patterns a PCI reviewer flags as cleartext-storage and weak-key-management issues.

vulkro compliance --profile pci​

The Free tier ships the PCI mapping subcommand:

vulkro compliance --profile pci

Output is the control-by-control breakdown, citing PCI DSS 4.0 clause numbers. Sample row (truncated):

6.2.4 Review addresses common software attacks
  PASS  No SQL injection findings on cardholder-data sinks.
  FAIL  1 finding (critical) at services/payments/charge.py:142.
        Auth-bypass on /api/charge: missing requireMerchant() check.
        See findings: AUTH-0042.

3.4   PAN rendered unreadable wherever stored
  FAIL  2 findings (critical): hardcoded PAN-shape constants
        at tests/fixtures/cards.py:8 and migrations/0007_seed.py:34.
        See findings: PCI-0001, PCI-0001.

The output is also available as JSON (--format json) or HTML (--format html) for handing to a non-engineering auditor.

vulkro compliance-pack --framework pci-dss (Pro)​

The Pro tier ships the signed evidence-pack output for PCI DSS:

vulkro compliance-pack --framework pci-dss --output pci.pdf

The pack is the audit-ready document: PCI clause coverage, finding cross-references, executive summary, cryptographic signature over the report body and commit hash. The QSA can verify the report was generated against a specific git ref without rerunning the scan.

At a glance: Vulkro vs typical SaaS SAST on PCI​

The "vendor does not enter PCI scope" property is the structural advantage. A cloud-first competitor cannot match it without re-architecting their data plane.

Use cases we hear from​

• Payment startups and processors. PAN handling in tokenization paths, callout-credential audit for upstream acquirers, webhook signature verification.
• Marketplace platforms with payments. Cardholder data flowing through ledger / payout code, mass-assignment risk on payout endpoints, IDOR on transaction lookup.
• Banks and credit unions building internal apps. Internal treasury, ledger, or reconciliation tools that touch PAN or account data; conventional cloud SAST is often forbidden by internal policy.
• PCI Level 1 merchants. Annual report-on-compliance (ROC) evidence; Vulkro's compliance-pack output fits cleanly into the QSA evidence binder.
• Crypto and stablecoin payment rails. Same mapping applies; the crypto-weakness checks (key management, IV reuse, weak RNG) get a heavier workout.

Talk to us​

If you are evaluating Vulkro for a PCI DSS scope or want to walk through the mapping, the evidence-pack format, or the air-gap deployment recipe, email [email protected].

Read the manifesto for the architectural commitment. See the compliance docs for the full PCI control mapping. See the benchmark for reproducible detection numbers.