vulkro-sf org effective-perms
Audits the cumulative effective permissions users hold right now.
Where org perms reads the
configuration, this command runs three SOQL queries against the live
org and reports the per-user blast radius that the metadata-only view
does not show.
The distinction matters: a permission set can grant ModifyAllData and
be assigned to nobody. Metadata analysis sees the grant, effective-perms
sees whether an active user actually holds it.
Synopsis
vulkro-sf org effective-perms --target-org <alias> [flags]
Flags
| Flag | Type | Default | Description |
|---|---|---|---|
--target-org, -o <alias> | string | (required) | Target org alias or username, as known to sf org login. |
--format <fmt> | table | json | sarif | table | Output format. |
--verbose, -v | flag | off | Bump stderr log verbosity. -v enables debug-level tracing for the vulkro + vulkro_sf targets; -vv enables trace. Honoured only when RUST_LOG is unset (an explicit RUST_LOG always wins). |
What gets reported
| Rule | What fires |
|---|---|
SF-OBJ-PERM-001 | ObjectPermissions per (Profile or Permission Set) x SObjectType. Modify All Records is reported at High, View All Records at Medium. This closes the per-object equivalent of the org-wide ModifyAllData / ViewAllData rules. |
SF-FIELD-PERM-001 | FieldPermissions on PII-shaped fields (SSN, date of birth, bank account, credit card, driver's licence, passport, medical record, taxpayer id, and similar). Read on PII is Medium, Edit on PII is High. |
SF-PERM-ASSIGN-001 | PermissionSetAssignment ground truth: one finding per Permission Set that grants a broad system permission (ModifyAllData, ViewAllData, AuthorApex, ManageUsers) and is held by at least one active user. Every active assignee is listed. |
Standard Salesforce profiles (System Administrator, Standard User, and
the rest) and managed permission sets are skipped, matching the same
filter the metadata-only org perms audit uses.
Examples
# Table output for a connected production org.
vulkro-sf org effective-perms --target-org my-prod
# JSON for a governance dashboard or SIEM.
vulkro-sf org effective-perms -o my-prod --format json > effective-perms.json
# SARIF for a code-scanning surface that ingests SARIF.
vulkro-sf org effective-perms -o my-prod --format sarif > effective-perms.sarif
Exit codes
0- no findings.1- findings reported.2- error.
Scope and honesty
The org is read locally through your own authenticated sf CLI login.
Nothing is sent anywhere, and the OAuth token stays in the sf CLI
credential store on your machine.
The three queries read permission metadata and assignment links. No
business-record SOQL is issued: SF-FIELD-PERM-001 reports that a
field shaped like PII is readable or editable by a given entity, it
does not read the field's values.
Findings are static posture signals derived from configuration, not runtime-validated exploits. A clean run means these rules did not fire, which is not a certification that the org is secure.
Where to go next
- vulkro-sf org perms - the metadata-side over-privilege and dormant-admin view.
- vulkro-sf org psg-composition - escalation that only exists once a Permission Set Group aggregates its components.
- vulkro-sf org integration-users - integration and service-account privilege.