Source scan vs live-org scan

vulkro-sf reads Salesforce in two ways: source (an SFDX project or retrieved metadata on disk) and live org (a running org, read through your own sf CLI login).

vulkro-sf scan ./force-app                          # source only
vulkro-sf org report --target-org my-prod -O org.html   # live org
vulkro-sf scan ./force-app --org my-prod            # source, with live-org facts on the attack paths

What each one sees

Area	Source scan	Live org
Code: Apex, LWC, Aura, Visualforce, Flow	Full coverage	Not needed
Settings: session, password, clickjack, CSRF, sharing	Only what was retrieved into the project	What is active right now
Identity: profiles, permission sets, groups	The XML on disk	Who actually holds each grant, dormant admins, integration users
Third party: Connected Apps, credentials, packages	App and credential metadata in source	Installed packages, OAuth token use, External Client Apps
Agentforce	Agent actions and their Apex classes	Same, plus who the agents run as
Activity	Not available	LoginHistory, Setup Audit Trail, event log files

Short version: source finds code problems; the live org adds what is configured and who holds it right now.

Use a source scan for

• A managed package before submission (the readiness report is built from source).
• Pull request gates: a CI runner should not log in to a real org.
• Third-party code you only have as files.
• Air-gapped machines: it contacts nothing.

Use the live org for

• Configuration drift: settings changed in Setup but not in source.
• Real access: dormant admins, effective permissions, integration users.
• Installed packages and app usage, which never appear in source.
• Regular org audits (for scheduled scans across orgs, see Vulkro Cloud).

The live-org path needs the sf CLI and one login per org. It only reads; nothing in the org changes, and it does not read the contents of business records. See Live-org setup.

Combining both

scan --org <alias> adds live-org facts to a source scan: a path nobody holds is lowered one severity step; a path whose grant is widely held, whose guest user owns records, or whose app is in use is raised one step. The findings themselves stay the same. For a full picture, also run vulkro-sf org report and keep both reports.

Question	Use
Preparing a package submission?	scan and appexchange-report
Gating a pull request?	scan --gate-vs <base>
Auditing production?	org report, plus scan --org if you have the source
No internet?	Source only

See also: Your first scan, Live-org setup