vulkro-sf org sharing-rules

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, and LeadShare rows where RowCause is not Owner (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.