Skip to main content

Vulkro for Salesforce

Know where your Salesforce security stands before the review, the handoff, or the merge.

Whether you are submitting a managed package, handing an org back to a client, or merging to production, Vulkro for Salesforce reviews your Apex, Lightning, Flows, metadata, and live-org settings in the language the AppExchange security reviewer uses. It runs on your machine, reads zero customer records, and uses no AI in detection, so the same code gives the same result every time. Client code never leaves your laptop, so your audit tool is not a third-party data processor on anyone's NDA.

Start the 14-day trialAppExchange readiness docs →
  • Scans run locally
  • Nothing uploaded
  • No AI in the scan
  • Reads zero customer records
  • 14-day full trial
$ vulkro-sf asrr ./force-app   # example output

  AppExchange Security Review readiness
  ------------------------------------------
  VERDICT: GAPS   4 pass, 2 gap, 0 not-evaluated

  [GAP ] SF-ASRR-001  Secure coding and injection defence  (3)
  [PASS] SF-ASRR-002  Sensitive data protection
  [PASS] SF-ASRR-003  Sharing and access control
  [PASS] SF-ASRR-004  Client-side and UI security
  [GAP ] SF-ASRR-005  Integrations and external callouts  (1)
  [PASS] SF-ASRR-006  Least-privilege metadata and automation
Example output. Runs on your machine. Reads zero customer records.

01 / The flagship report

Know the Security Review verdict before you pay for one.

The readiness report is the artifact: every finding rolled up into the published Partner Security Review requirement categories, each scored pass, gap, or not-evaluated, and one verdict, READY or GAPS. CRUD and FLS gaps and sharing mistakes, among the top reasons a review is rejected, are exactly what the underlying detectors target.

The review landscape changed in June 2025, when Salesforce retired Chimera, the free scanner it had provided for partner web apps. Partners now assemble their own pre-submission toolchain, which makes a readiness report generated on your own machine the step you control: run it before you queue, fix what it names, and attach the result to the submission.

The readiness verdict

Six requirement categories, each scored pass, gap, or not-evaluated, and one overall verdict. The release manager's view before clicking submit. A category with no detector coverage says not-evaluated and tells you to verify it manually; it never silently passes.

$ vulkro-sf asrr . --format markdown

The engineer's gate

Ten named go / no-go gates (secrets, CRUD/FLS, injection, sharing, cleartext endpoints, cryptography, Lightning, Visualforce, metadata, Flow) as a pass / fail table for CI. Exit code 0 when every gate passes, 1 when one fails, so the pipeline blocks a doomed submission automatically.

$ vulkro-sf presubmit . --format json

The file you hand off

The full report as one self-contained HTML file, grouped by the same checklist your AppExchange reviewer uses: PASS, FAIL, or NOT EVALUATED per section, the checklist version date pinned in the header, and optional prepared-for and prepared-by lines on the cover. Nothing loads from a CDN, so it opens on an air-gapped laptop. Attach it to the submission or hand it to a client.

$ vulkro-sf appexchange-report -o readiness.html

A failed Security Review costs the per-submission fee Salesforce charges, the resubmission queue, and the release you had planned around it. Finding the blockers on your own machine first is the cheap path.

The readiness check →The HTML report →

Nine areas of risk, dozens of checks each. One command runs all of them on your machine. Pick yours to jump to the detail.

02 / What crosses the wire

The scan uploads nothing. Here is the only thing that touches our servers.

No source code, no findings, and no file names ever leave your machine. Your Apex, metadata, and business records are read locally and stay local.

Vulkro for Salesforce does require a verified account, and the account layer makes one kind of network call: a usage heartbeat, sent at most once a day. It carries a short, fixed set of usage fields, up to eight in total, and nothing else:

  • productwhich edition sent it (vulkro or vulkro-sf)
  • install ida random, anonymous identifier, never your machine id
  • versionthe scanner version
  • operating systemfor example macos, linux, or windows
  • timestampwhen the heartbeat was sent
  • scan counterhow many scans ran since the last heartbeat, a single number
  • device tokenonly when you are signed in, so the server can refresh your license lease; never your machine id
  • language setonly when a scan ran: the short language tokens it detected (for example apex or javascript), never a path, a file name, or source

That is the whole list. The heartbeat never carries your code, your file paths, your findings, or a single customer record. For a regulated or air-gapped engagement, a machine-bound license file replaces the account sign-in, and offline mode (VULKRO_OFFLINE=1) turns off every outbound call, the heartbeat included, so the scanner runs with no network at all.

How this is verified →

03 / The surface nobody else reviews

Your org runs AI agents now. They are code too, so review them like code.

An AI agent in your org reads record fields, grounds on your data, and calls your Apex. Attacker text planted in a Description field becomes an instruction; an action bound to a without-sharing class becomes a data leak. ForcedLeak proved the class is real. Vulkro ships 15+ detectors for exactly this surface, and reviews both the compiled agent metadata your org runs and the Agent Script source you author.

The ForcedLeak pack

Detectors built from the Noma research that produced the first published Agentforce vulnerability class (rated CVSS 9.4): agent actions bound to Apex that runs without a sharing check, grounding on PII-bearing free-text fields an outsider can write to, and unscoped retrieval an agent can steer to records it should never see.

$ vulkro-sf scan . (rules AP-061..AP-070)

Compiled agent metadata

Reads the agent metadata your org actually runs: bots, planners, prompt templates, and GenAiFunction actions. Fires when an action whose target is Apex points at a class declared without sharing, when an agent-reachable class opts into system-mode data access, and when a grounded prompt template has no allowlist or filter.

$ vulkro-sf scan ./force-app

Agent Script source

The same review for the authoring source that compiles to that metadata: five rules (AS-000 to AS-004) covering actions bound to without-sharing classes, bundles with no least-privilege runAs guard, grounding on untrusted free-text fields, and over-broad action scopes. Ships before your CI compiles the bundle, so the flaw never reaches the org.

$ vulkro-sf scan . (rules AS-000..AS-004)

New in SF v0.5.0

Live-org AI inventory

Inventories the AI surface of a live org through definition objects only: agents, topics, actions with their invocation targets, prompt templates, and the org-level Einstein generative-AI enablement flags. Each probe reports honestly as detected, empty, or unavailable. The OAuth token stays inside your own sf CLI throughout, and zero customer records are read.

$ vulkro-sf serve (Org, Agentforce inventory)

New in SF v0.5.0

AI-origin audit

Reports which findings landed on AI-authored Apex, LWC, and Aura files, broken down per tool, plus the AI-touched file list. Detection is marker-based only: an explicit tool marker in a comment counts, code style is never guessed, so an unmarked file is a safe miss rather than a false claim.

$ vulkro-sf scan --ai-code-segregation ./force-app

A knowledge bundle that keeps up

The Agentforce field and pattern catalog ships as a signed remote bundle, refreshed without a binary release, so new agent attack patterns land as data. Air-gapped runners set one environment variable and use the bundled-in seed catalog with zero outbound calls.

$ VULKRO_SF_OFFLINE=1 vulkro-sf scan .

04 / Verified fixes for Apex

The model drafts the fix. The deterministic re-scan gives the verdict.

vulkro-sf fix --ai asks a local model for a minimal Apex patch, then judges it without trusting it. A fix is verified only when a fresh deterministic re-scan no longer reports the finding, no new finding appears in the file, and the file still parses. That is the whole claim: it does not say your build compiles or your tests pass. Anything less is refused with a reason, and a refusal changes nothing.

$ vulkro-sf fix --ai ./force-app

[HIGH] apex_soql_injection  classes/LeadSearch.cls:12
  draft: static query with a :bind variable
  parse check: ok
  re-scan: finding no longer reported, no new findings
  verified. Run again with --write to apply the diff.
Illustrative output, one finding. A refused draft is reported the same way, with its reason, and leaves the file untouched.

The tier drafts patches only where the correct remediation idiom is well defined: CRUD and FLS enforcement, sharing declarations, and SOQL injection. Findings outside those classes are never sent to a model, and without --ai no model runs at all. The rest of Vulkro AI (local) ships in this edition too: a vulkro-sf ai command group and scan --ai-explain, advisory, local through Ollama, and never a change to a deterministic scan result.

How a fix gets verified →Vulkro AI (local) →

05 / How it finds real risks

It follows your data across Apex, then tells you if it is safe.

A pattern scanner flags anything that looks like a database call and buries you in false alarms. Vulkro follows the actual path a piece of untrusted input takes through your Apex, and only raises an alarm when it reaches something dangerous with no access check in between. Fewer false alarms, and the serious risks caught.

SafeA user typed value→an Apex controller→a CRUD and FLS check→a SOQL queryNo alarm. The access check is there.
RiskA user typed value→an Apex controller→no access check→a SOQL queryAlarm. A user can read records they should not.

Same input. The only difference is whether an access check sits in the path, and that is exactly what Vulkro follows. The same follow-the-data engine reviews the path from an AI agent action into your Apex.

The same approach powers the Apex, Lightning, Flow, and access checks below. Same code, same result, every time. No AI in detection, no guessing.

06 / The depth

Built for the checks a reviewer actually rejects on.

CRUD and FLS gaps and sharing mistakes are among the top reasons an AppExchange Security Review is rejected, and Vulkro for Salesforce targets them directly.

109

Salesforce detector modules

70+

Well-Architected anti-pattern rules

15+

Agentforce and AI-agent detectors

These are coverage counts, not a score. The Salesforce edition is not measured against our core benchmark, because that corpus is JavaScript, TypeScript, Python, and Go. The Salesforce proof is the per-rule documentation and the checklist mapping, plus the cross-class resolution you can see in the report itself.

Interprocedural Apex taint

Untrusted input followed from source to sink across files, not just the line it appears on, so a risk that spans several classes is still caught.

LWC-to-Apex cross-language bridge

A value that starts in a Lightning Web Component and flows into Apex is tracked across the language boundary, so a browser-side input that reaches a server-side sink does not slip through.

A live-org audit that stays hands-off

The live-org audit reads your settings through your own sf CLI login. It never holds the OAuth token and reads zero customer records: definition objects and settings metadata only, never Accounts, Cases, or any other row of your business data.

$ vulkro-sf org perms (token stays in your sf CLI)

07 / Your code

The code your team wrote.

The flaws in your own Apex, Lightning, and Flows are the ones a reviewer rejects and an attacker hits first.

Apex code

The custom logic behind your org, checked for the flaws that fail a review: places a user can reach records they should not, places their input steers a database query, and missing access checks. Followed across files, not just the line it appears on.

Lightning: LWC and Aura

Your Lightning Web Components and Aura components, checked for the scripting flaws that let a page render something a user should never control, and for customer data left exposed in the browser.

Flows

Screen and autolaunched flows, checked for the same access and exposure gaps as code, including flows that a guest visitor can reach without signing in.

08 / Access, configuration, and secrets

Who can reach what, and how the org is set up.

Most Salesforce incidents were not code bugs. They were an over-broad profile, a connected app with the wrong scope, or a setting nobody wrote down. Vulkro reviews all of it.

Access and sharing

Profiles, permission sets, and sharing rules that hand out more than the job needs, and the guest-user access that turned a public site into a data leak at other companies.

Org configuration

The org-wide settings a reviewer checks: cross-origin rules, content-security policy, remote site access, and session hardening. What cleared and what did not, written down instead of left to memory.

Secrets and credentials

Named credentials, API keys hardcoded into your source, and secrets left behind in your git history. What should never be in the code, found before it ships.

Data exposure

Where personal data ends up somewhere it should not: a debug log, an error message, a place a user can see. A privacy slip caught before a customer finds it.

All of this runs on your machine. Vulkro for Salesforce reads your code and settings only, and never reads your customer data.

09 / The proof

Built from the breaches that actually hit Salesforce.

Each check maps to the weak spot behind a real, published Salesforce incident. You are catching the patterns that already cost other teams real customers.

ForcedLeak, the first Agentforce breach

An AI agent could be steered by attacker text planted in a record field, and the code it triggered ran without a sharing check (rated CVSS 9.4 in the Noma research). Vulkro catches the class bypass, the untrusted grounding field, and the agent action that exposes them.

Drift OAuth token theft

One of the 2025 Salesforce supply-chain breaches driven by stolen OAuth tokens: a third-party assistant lost its tokens and attackers replayed them straight into customer orgs. Vulkro catches the over-permissioned connected app that turns a vendor slip into your incident.

Gainsight OAuth abuse

Same vector, same year, a different vendor. The same check catches it, because the underlying misconfiguration is the same. Vendor names change; the weak spot does not.

Experience Cloud guest user exposure

A guest-user profile that could read standard objects it should never have seen. Vulkro flags the profile setting that makes the exposure possible.

ShinyHunters vishing campaigns

Records lifted after attackers talked someone into approving a connected app with the wrong scope. Vulkro flags the connected-app setting that makes the call worth making.

Reviewer-aligned. Reads zero customer records. Runs on your machine. Licensed the same way as the core scanner: per seat, directly through our team.

Reviewer-aligned report
Reads zero customer records
Runs on your machine, nothing uploaded
No AI in detection: same code, same result
See the full detector list →How licensing works →

10 / Not just Salesforce

The same offline engine scans your other code.

Your services outside Salesforce have their own risks: broken access, injected input, leaked keys, risky dependencies, and the new risks your AI coding tools bring in. Those ship in the core Vulkro scanner, built on the same offline engine, so nothing you run ever leaves your machine.

See what the core scanner checks →Talk to us →

What the core scanner covers

Your application

Secrets and personal data

Dependencies and supply chain

AI development surface

Infrastructure

11 / What it does not do

Where this edition is the wrong tool, we say so.

Your customer records
Vulkro for Salesforce never reads them. No Accounts, Opportunities, Leads, Cases, custom-object rows, or attachments. The live-org audit reads definition objects and settings through your own sf CLI login; the OAuth token stays inside that CLI and is never held by Vulkro.
What the static scan cannot see
A source scan reviews the code and metadata in your repo. It cannot see what changed in the org after deployment: a permission set edited in Setup, a connected app approved yesterday, a session policy relaxed by an admin. That is what the live-org audit is for; run both.
What the live-org audit cannot see
The live-org audit reads settings and definitions, not code paths. It cannot follow tainted input through your Apex or tell you a SOQL query is injectable; that depth needs the source scan. The two halves are different views of the same org, not substitutes.
Checks it cannot evaluate
A readiness category with no detector coverage on a given scan is reported as not-evaluated, and does not silently pass. The report tells you to verify it manually rather than pretending it cleared.
AI-written code detection
The AI-origin audit is marker-based only: it counts a file as AI-authored when a comment carries an explicit tool marker. It never guesses from code style, so unmarked AI code is a safe miss, not a false claim.
Anything outside Salesforce
This edition is Salesforce-only. For your other services and their code, use the core Vulkro scanner.
A live penetration test
This is a review of your code and settings, not an attack against a running org. It finds the weak spot; it does not exploit it.

If it is not on this page, assume this edition does not check it yet, and tell us what you need. Covers Agentforce and Agent Script, Apex, Lightning (LWC and Aura), Flow, Visualforce, and your org configuration.