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.
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.
Four things we picked, on purpose
Every Salesforce security tool makes tradeoffs the vendor decided for you. Here are ours, on the front page.
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.
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.
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.
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 (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.
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.
SecuritySettings hardening: session timeout, clickjack, CSRF, HTTPS enforcement, password lockout, login IP ranges. Org-wide defaults and sharing rule audit.
Profile and permission-set over-privilege. Dormant privileged accounts (ghost admins). Permission-set group aggregation. SAML SSO signature algorithms. LoginFlow inventory.
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.
Agentforce agent inventory plus the ForcedLeak (CVSS 9.4) class-bypass detector: a GenAiFunction Apex action whose target class is declared without sharing.
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
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.
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 | bashPoint 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.sarifReuses 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-orgThe 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.htmlPrivacy by design
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.
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.
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.
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
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.
Refresh tokens stolen at the vendor and replayed. Detected via Connected App Full scope + refresh token co-occurrence.
Same vector as Drift, same detector. The OAuth posture suite generalises beyond the named vendors.
Loblaw 75M, ADT 10M+; AuraInspector campaign. Detected via guest-licence profile with read or View All on sensitive standard objects.
Detected via GenAiFunction Apex action whose target class is declared without sharing. Two-pass walk confirms the source-level sharing keyword before emitting.
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.
Community
Subscribe on Substack or follow r/vulkro to hear about new Salesforce detectors, AppExchange-readiness updates, and 2025-26 breach-class advisories the moment they ship.
Subscribe once, get two things: the weekly CVE + release digest in your inbox, and access to the live chat where in-between things land (detector ideas, weird findings, release heads-ups).
Public community at r/vulkro. Bug reports, scan-result war stories, CVE chat, AppSec questions. No email required, indexed by Google so threads stay useful.
Bug reports, install help, billing questions. One human reads every message. No web form, no chatbot, no AI summariser.
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.