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

Fintech teams now merge AI-written code into the systems that handle cardholder data, and PCI DSS does not care who or what wrote the line. Your QSA will ask for evidence that the code touching cardholder data was reviewed for security before release. Vulkro produces that evidence on your machine, without your codebase or your findings ever leaving it.

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 scans entirely on your machine, with no upload step and no vendor cloud: your code, paths, and findings never leave it. 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 and vulkro compliance-pack --framework pci-dss 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. The 14-day trial and the issued license both cover the full product, including the evidence packs.

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​

Fintechs running on the Salesforce platform (Financial Services Cloud, Heroku Connect, and the rest of the Salesforce surfaces) are covered by the separate Vulkro for Salesforce product (the vulkro-sf binary), not the general vulkro scanner.

vulkro compliance --profile pci​

The scanner 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​

The scanner ships a 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.

Deployment fit​

• Offline by architecture. The scan runs on your machine or your CI runner; the account entitlement check carries six usage fields (product, install id, version, operating system, timestamp, and a scan counter), never code, paths, or findings.
• Air-gapped environments run on a signed license file with no network access at all, and CVE bundles arrive by sneakernet.
• CI gating uses the standard exit-code contract (0 clean, 1 findings, 2 error) and SARIF output, so the PCI rescan loop lives in the pipeline and blocks release on new high-risk findings.
• Evidence retention is yours: reports, compliance output, and signed evidence packs are files on your infrastructure, kept under your own retention policy.

Honest scope​

Vulkro is a static analyzer, not a QSA and not a compliance certification. It produces the code-level evidence your assessor asks for; it does not attest your network segmentation, your key ceremony, or your physical controls, and a clean scan is not a Report on Compliance. It is also not a WAF or a pentest: it reads code, it does not probe your production cardholder environment.

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