vulkro-sf org event-monitoring

Pro

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 Salesforce Shield Event Monitoring log files for anomaly patterns (SF-EVENT-MON-001 through -009).

Queries the Tooling API EventLogFile object over a lookback window and runs a nine-rule pack over the returned metadata rows.

Shield Event Monitoring is a paid Salesforce add-on

When the org does not license it, the EventLogFile object is not queryable. The command detects that condition and degrades gracefully with an actionable message naming the add-on, rather than failing with an opaque API error.

Synopsis

vulkro-sf org event-monitoring --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.
--since-days <n>	integer	7	Lookback window in days. Overrides VULKRO_SF_EVENT_MON_SINCE_DAYS, which is consulted when this flag is absent.
--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).

Environment variables

Variable	Description
VULKRO_SF_EVENT_MON_SINCE_DAYS	Lookback window in days. Default 7. Overridden by --since-days.

What gets reported

Rule	Severity	What fires
SF-EVENT-MON-001	High	A BulkApi row whose RecordsProcessed exceeds 50,000 in a single job: the canonical mass-exfiltration bar.
SF-EVENT-MON-002	High	A BulkApiResult / ApiTotalUsage row showing more than 1,000 DELETE operations from a non-admin user.
SF-EVENT-MON-003	Medium	A ReportExport whose LogDate UTC hour falls outside 06:00 to 22:00.
SF-EVENT-MON-004	High	More than 10 failed Login rows for one user: a brute-force burst.
SF-EVENT-MON-005	Medium	An ApexExecution whose RUN_TIME exceeds 10,000 ms: a slow or abusive transaction.
SF-EVENT-MON-006	Medium	More than 5 ApexUnexpectedException rows.
SF-EVENT-MON-007	High	A Guest user touching more than 100 records: a public-site data leak.
SF-EVENT-MON-008	High	More than 5,000 API-family request rows (Api, RestApi, ApexRest, ApexSoap, ApexCallout) for one user.
SF-EVENT-MON-009	High	More than 10 correlated error events (ApexUnexpectedException plus ApiErrorResponse plus LightningError).

Examples

# Default 7-day lookback.
vulkro-sf org event-monitoring --target-org my-prod

# Widen the window to 30 days.
vulkro-sf org event-monitoring -o my-prod --since-days 30

# Same, driven by environment in CI.
VULKRO_SF_EVENT_MON_SINCE_DAYS=30 vulkro-sf org event-monitoring -o my-prod --format json

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.

The current version audits only the EventLogFile metadata row (EventType, LogDate, LogFileLength, and the augmented per-row fields). Streaming the log file's CSV body for richer per-event correlation is deferred to a follow-up. That is the honest boundary of what these nine rules can see: they reason about the shape and volume of logged activity, not about every individual event inside a log file.

Findings are anomaly signals over an activity log, not runtime-validated exploits and not confirmed incidents. A 60,000-record Bulk API job is very often a scheduled data load. Each finding is a lead for a human to check against what the org is expected to be doing. A run with no findings does not certify that no exfiltration occurred, particularly outside the lookback window.

Where to go next

• Event Monitoring detectors - the wider rule family.
• vulkro-sf logs - offline analysis of exported log data.
• vulkro-sf org audit-trail - Setup changes over the same period.