vulkro-sf org sandbox-refresh-lag
Audits sandbox refresh lag (SF-SANDBOX-001 / -002 / -003).
A pre-production org that has not been refreshed in months is testing against a schema that no longer matches production. That is the classic release-week detonation: everything passed in the sandbox because the sandbox was wrong.
SandboxInfo is only queryable against a DevHub. Point --target-org
at the DevHub, not at the sandbox. If the object is not queryable the
command reports that requirement in the error message.
Synopsis
vulkro-sf org sandbox-refresh-lag --target-org <devhub-alias> [flags]
Flags
| Flag | Type | Default | Description |
|---|---|---|---|
--target-org, -o <alias> | string | (required) | Target org alias or username, as known to sf org login. Must be a DevHub. |
--format <fmt> | enum | 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
SandboxInfo rows: Id, SandboxName, SandboxOrganization,
LicenseType, EndDate, ExpirationDate, StartDate.
What gets reported
| Rule | Severity | What fires |
|---|---|---|
SF-SANDBOX-001 | High | Any sandbox whose StartDate is older than 180 days. Signal org-sandbox-refresh-stale-180d. |
SF-SANDBOX-002 | Medium | A Full sandbox whose StartDate is older than 90 days. Full sandboxes can only refresh once every 29 days, so lag beyond 90 days is unusual and worth flagging on its own. Signal org-sandbox-license-type-full-stale-90d. |
SF-SANDBOX-003 | Low | A sandbox whose ExpirationDate falls inside the next 30 days. Signal org-sandbox-expiration-near. |
Examples
vulkro-sf org sandbox-refresh-lag --target-org my-devhub
vulkro-sf org sandbox-refresh-lag -o my-devhub --format json > sandboxes.json
Exit codes
0- no findings.1- posture findings reported.2- error.
These follow the org command-family contract printed by
vulkro-sf org --help.
Scope and honesty
The DevHub is read locally through your own authenticated sf CLI
login; nothing is sent anywhere. Only sandbox metadata is read: no
sandbox data, and no production data.
This is a staleness and lifecycle signal, not a security finding in the exploit sense. Refresh lag is judged purely from dates: the command does not compare sandbox schema against production, so a recently refreshed sandbox can still have drifted, and an old sandbox may be intentionally frozen for a long-running project. Treat the findings as prompts for a release-management conversation.
Where to go next
- vulkro-sf org status - confirm which org you are pointed at.
- Masking rules - PII masking on sandbox copies.
- Metadata diff - actual drift between two orgs.