vulkro-sf org event-monitoring
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.
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.