vulkro-sf org sharing-rules
Every live-org command (vulkro-sf org ...) is part of Pro: Live-org audit (sf-live-org), permissions, session, MFA, sharing, packages and trust, read from the org itself. On Free it stops before doing any work, prints what it needs and where to get it, and exits 1. See Pricing.
Audits standard-object sharing entries for over-broad write access,
portal-user manual shares, and criteria-based shares covering many
records (SF-SHARING-001 / -002 / -003).
Sharing is where a correct permission model still leaks data: the profile may be tight, but a share row hands the record over anyway.
Synopsis
vulkro-sf org sharing-rules --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 | 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 read
AccountShare,OpportunityShare,ContactShare, andLeadSharerows whereRowCauseis notOwner(owner rows are the record's own ownership, not a share decision).- The org's public-group directory (
Group), so a share to a group can be named rather than shown as an opaque id. - Per-object record counts, used to judge how much of an object a criteria-based share actually covers.
The command is a pure audit over the joined data. It performs no writes.
What gets reported
| Rule | Severity | Signal |
|---|---|---|
SF-SHARING-001 | High | org-sharing-rule-broad-write-access |
SF-SHARING-002 | Medium | org-sharing-rule-manual-share-to-portal |
SF-SHARING-003 | Low | org-sharing-rule-criteria-based-broad |
Examples
vulkro-sf org sharing-rules --target-org my-prod
vulkro-sf org sharing-rules -o my-prod --format json > sharing.json
Exit codes
0- no findings.1- posture findings reported.2- error.
Scope and honesty
The org is read locally through your own authenticated sf CLI login;
nothing is sent anywhere. The audit reads share rows, the group
directory, and record counts. It does not read the field values of
the shared Accounts, Opportunities, Contacts, or Leads.
The scope is standard-object sharing entries on those four objects. Custom-object sharing is not covered by this command, so a quiet run says nothing about custom objects.
Findings are static posture signals about the sharing configuration, not proof that a specific user read a specific record. Broad shares are frequently intentional in a collaborative org. Nothing here certifies an org's sharing model correct.
Where to go next
- vulkro-sf org role-hierarchy - the role structure that sharing rules propagate through.
- Sharing and leakage detectors - the source-format side of this risk class.
- vulkro-sf org guest-live - the unauthenticated end of the same problem.