Skip to main content
Vulkro forSalesforce

Catch every AppExchange-failing pattern before you submit.

One offline scan reviews your whole Salesforce build: the code, the org's security hardening, who can access what, the third-party apps connected to it, and your Agentforce actions. It flags what an AppExchange Security Review will reject and the misconfigurations behind the 2025-26 Salesforce breaches, all on your laptop. No source upload, no account, and the live-org check uses your own Salesforce login, so the access token never reaches us.

Salesforce-mandatory PMD still runs in parallel. Vulkro for Salesforce layers on top, plus the four pillars PMD does not cover.

  • Apex
  • LWC
  • Aura
  • Visualforce
  • Flow
  • Org posture
  • Identity
  • Connected Apps
  • Agentforce
  • AppExchange

Four things we picked, on purpose

Offline. Reviewer-aligned. Five-pillar. Closed-source.

Every Salesforce security tool makes tradeoffs the vendor decided for you. Here are ours, on the front page.

01

Offline

Source never leaves your machine. The org connector reuses your existing sf CLI login so the OAuth token stays in the official credential store, never on Vulkro. No telemetry, no LLM in the loop, no upload.

02

Reviewer-aligned

The AppExchange Security Review readiness HTML report is grouped by the published reviewer checklist sections. You hand it to your reviewer; they see, section by section, what Vulkro caught and what it cleared.

03

Five pillars, one tool

Code scanners cover one slice. Posture tools cover another. Vulkro for Salesforce covers your code, org hardening, access, third-party Connected Apps, and Agentforce in one scan, so you are not buying and stitching together five separate vendors.

04

Closed-source detectors

The detectors are the product. What we publish is the methodology, the benchmark, and every detector ID with positive and negative code examples. We compete on reproducible coverage, not on source openness.

Coverage in one local scan

Code SAST tools cover one slice. We cover five.

Code SAST tools (PMD, sfdx-scanner, Clayton, CodeScan) do not do posture. SSPM tools (AppOmni, Obsidian, Adaptive Shield) do not do code. Vulkro for Salesforce does both, in one binary.

01

Code

Apex SOQL injection, CRUD / FLS (including USER_MODE), sharing violations, IDOR, mass-assignment, secrets, crypto misuse. LWC + Aura DOM XSS. Visualforce escape="false". Flow system-context DML.

02

Org posture

SecuritySettings hardening: session timeout, clickjack, CSRF, HTTPS enforcement, password lockout, login IP ranges. Org-wide defaults and sharing rule audit.

03

Identity

Profile and permission-set over-privilege. Dormant privileged accounts (ghost admins). Permission-set group aggregation. SAML SSO signature algorithms. LoginFlow inventory.

04

Third-party

Connected App OAuth posture (5 checks including the Drift / Gainsight token-sprawl breach class). Named and External Credentials. External Data Sources. CORS and CSP Trusted Sites. Static Resources for hardcoded API keys.

05

AI / Agentforce

Agentforce agent inventory plus the ForcedLeak (CVSS 9.4) class-bypass detector: a GenAiFunction Apex action whose target class is declared without sharing.

06

Plus: anti-patterns

A separate antipatterns command runs Salesforce Well-Architected anti-pattern detection (AP-001 to AP-014): SOQL / DML in loops, hardcoded IDs, missing test classes, multiple triggers per SObject, mixed-DML, recursive triggers, and the rest.

How it works

Install. Scan. Report. Hand off.

Four commands from a fresh clone to a reviewer-ready HTML report. The org connector is optional; source-only scans cover everything except the live posture / identity / Connected App / Agentforce pass.

01

Install

Same one-line installer as the general Vulkro scanner. macOS, Linux, and Windows. No Electron, no JVM warmup, no Salesforce CLI required to scan source-only.

curl -fsSL https://dist.vulkro.com/install-sf.sh | bash
02

Scan your source

Point it at your SFDX project root. Native Vulkro detectors run by default; PMD wrappers slot in alongside via --include-pmd if you want both in one SARIF stream.

vulkro-sf scan ./my-sfdx-project --format sarif > findings.sarif
03

Connect a live org (optional, metadata-only)

Reuses your existing sf CLI login. Vulkro reads only metadata: Profiles, Permission Sets, SecuritySettings, Connected Apps, Sharing Rules, Flow definitions, GenAiFunction declarations. It never SELECTs against your business records.

sf org login web --alias my-org
vulkro-sf org status   --target-org my-org
vulkro-sf org perms    --target-org my-org
vulkro-sf org packages --target-org my-org
04

Report and hand off

The HTML report groups every finding by the published AppExchange Security Review checklist sections. Section by section, what was caught and what cleared. Email the report to your reviewer.

vulkro-sf appexchange-report ./my-sfdx-project -o readiness.html

Privacy by design

Connect a live org. We never read your data.

A security tool that "connects to your Salesforce org" should tell you exactly what it reads. Vulkro for Salesforce reads metadata only - the same surface an admin sees in Setup - and uses the official sf CLI for OAuth so the access token never lives in Vulkro. Every org view is read-only: identity and permission posture, Connected App OAuth risk, installed packages, Agentforce inventory, and SecuritySettings hardening (session, IP binding, clickjack, CSRF, password policy). Each audit is a point-in-time snapshot you can re-run to diff what changed since the last one.

What Vulkro reads

Org metadata only: Profiles, Permission Sets, SecuritySettings, Sharing Rules, Connected Apps, Named Credentials, Flow definitions, GenAiFunction declarations, Static Resources, and the Apex / LWC / Aura source you wrote. Same surface a Salesforce admin sees in Setup, never the rows a sales rep sees in records.

What it never reads

No customer records. No Accounts, Opportunities, Leads, Cases, Contacts, custom-object rows, file attachments, or any business data. No SELECT against your live data. Ever. Vulkro for Salesforce uses the Metadata API and the Tooling API only; the SOQL Query and Bulk APIs against business records are out of scope by design.

Where the OAuth token lives

In the official sf CLI credential store on your laptop, not in Vulkro. The connector asks the sf CLI to perform the metadata fetch; the CLI returns the response. Vulkro never sees the access token, never stores it, never transmits it. Revoke the org connection through Salesforce Setup the same way you would for the sf CLI itself.

Built around 2025-26 breach classes

Most SF security work in 2025-26 was not code bugs.

It was misconfiguration: Connected App posture, guest-user exposure, Agentforce class bypass, vishing-pivoted OAuth. Vulkro for Salesforce maps detectors directly to the breach classes that compromised real customer orgs.

01

Salesloft Drift OAuth token theft (700+ orgs)

Refresh tokens stolen at the vendor and replayed. Detected via Connected App Full scope + refresh token co-occurrence.

02

Gainsight OAuth abuse (200+ orgs)

Same vector as Drift, same detector. The OAuth posture suite generalises beyond the named vendors.

03

Experience Cloud guest-user exposure

Loblaw 75M, ADT 10M+; AuraInspector campaign. Detected via guest-licence profile with read or View All on sensitive standard objects.

04

ForcedLeak (Agentforce CVSS 9.4)

Detected via GenAiFunction Apex action whose target class is declared without sharing. Two-pass walk confirms the source-level sharing keyword before emitting.

05

ShinyHunters / UNC6040 vishing

Google 2.55M, Qantas 5.7M, Allianz 1.4M. Vulkro catches the over-permissioned Connected App that becomes the attack pivot; the social-engineering vector itself is human-factor and out of scope by design.

Run it on your packaged source. See what a reviewer would see.

Install vulkro-sf, scan your SFDX project, generate the AppExchange readiness HTML. The same scan a Salesforce reviewer's checklist runs against, only offline and on your timetable.