Skip to main content

vulkro-sf org perms

Walks every Profile, Permission Set, and Permission Set Group in the live org and reports over-privilege, dormant admin assignments, and the guest-user posture that has been the root cause of the published Experience Cloud breaches (Loblaw, ADT). This is the most operational of the vulkro-sf org subcommands: it surfaces what a real auditor would write up in an IAM review.

Findings are reported with the assigning entity (the profile or permset that grants the perm) AND the count of users currently inheriting it, so you can see both the configuration risk and its blast radius in one row.

Synopsis​

vulkro-sf org perms --target-org <alias> [flags]

Flags​

FlagTypeDefaultDescription
--target-org, -o <alias>string(required)The sf CLI org alias or username, as known to sf org login.
--format <fmt>enumtableOutput format: table (human-readable on the terminal) or json (machine-readable, e.g. for piping into a CI annotation or a triage tool).

What gets reported​

  • Profiles with ModifyAllData - the single most powerful data permission on the platform. Reported at High severity for every custom profile that grants it; standard profiles are excluded by default.
  • Profiles with ManageUsers - lateral-movement risk: a user with this perm can create or modify other users and reassign ownership.
  • Profiles with AuthorApex - authoring permission for Apex code, which means write access to detector-bypass logic. Reported on every assignee.
  • Permission Sets with the same three perms - identical scope to the profile rules above, but reported per assigned user (a permset grants finer-grained surface than a profile).
  • Permission Set Groups - aggregated perms via group composition are walked transitively. The reported assignee count includes every user who inherits the perm through any group in the org.
  • Dormant admin assignments - any user whose LastLoginDate is older than 90 days AND who holds at least one of the three admin perms above. The first published breach class to highlight this risk was the Salesloft Drift incident, where dormant integration users were the lateral-movement pivot.
  • Guest-user license profiles with read or View All on sensitive standard objects (Account, Contact, Opportunity, Case, Lead, Quote). This is the configuration shape that produced the Loblaw and ADT Experience Cloud breaches and the AuraInspector class of enumerations. Reported at Critical severity for any custom guest profile with read on Account or Contact.

Examples​

# Default run: profiles + permsets + groups + dormant admins, table output.
vulkro-sf org perms --target-org my-prod

# Short alias form (-o is an alias for --target-org).
vulkro-sf org perms -o my-prod

# JSON output for ingestion into a SIEM or governance dashboard.
vulkro-sf org perms --target-org my-prod --format json > perms.json

Exit codes​

  • 0 - scan completed, no over-privilege or dormant-admin findings.
  • 1 - scan completed, findings were reported.
  • 2 - error: sf CLI not on PATH, alias not authenticated, network failure, or the org rejected the metadata / tooling API call.

Privacy​

org perms reads Profile, PermissionSet, PermissionSetGroup, PermissionSetAssignment, and the User records used to compute LastLoginDate for dormant-admin detection. No business-record SOQL is issued: no Account, no Opportunity, no Case row is fetched. The read against User is restricted to the fields needed for the dormant-admin computation (Id, Username, LastLoginDate, plus the permset / profile assignment links).

Where to go next​

Last updated on