Install the Safeguard CLI, run a scan command from a scheduled CI workflow, and have a person or a scheduled assistant task review the results. Use CI for the deterministic scan and keep any assistant task read only. The download page shows the install and scan commands.
What the download page confirms
The Safeguard download page, read on 19 October 2026, describes the CLI as a single static binary with no runtime to install, version 1.4.0. It installs with a curl command on macOS and Linux and a PowerShell command on Windows, with checksum verification. It lists these example commands: a scan of a project directory, a code scan of a single file, and a detect command for a path. The page says you can scan from your terminal or wire the CLI into a CI/CD pipeline. It also lists a Local agent and a Cloud agent as Available, and the CLI can also write code. This post covers scheduling the scan. It does not make performance or comparison claims.
Design: scan in CI, summarize with care
A scheduled scan is a deterministic job, so put it where deterministic jobs belong, in CI. Then decide what reads the results.
| Step | Where | Why |
|---|---|---|
| Install the CLI and run the scan | CI scheduled workflow | Reproducible, reviewable, versioned |
| Store results as a file or artifact | CI | Evidence you can keep |
| Summarize for humans | Person, or scheduled assistant task with read only access | Judgment over text |
| Open a ticket or fix pull request | A step with narrow credentials and review | Keep writes controlled |
Steps
- Pin the install. Fetch the installer in the workflow, and record the CLI version in the logs. Check the page for the current version before you pin.
- Schedule at an off minute. GitHub notes scheduled workflows can be delayed at the top of the hour, so choose something like 17 minutes past.
- Run on the default branch. GitHub scheduled workflows run only there, using the latest commit.
- Give the job least privilege. Read the repository, write nothing else. If it needs credentials for the scan service, store them as encrypted secrets and never print them.
- Save the output. Upload the result as an artifact with a name that includes the date.
- Fail on a chosen condition. Decide in advance what blocks: for example any new critical finding. Document it.
- Alert on absence. If no artifact appears by a set time, notify the owner. See silently stopped scheduled scans.
If an assistant task reads the results
Keep it read only. Give it the artifact or the report file and nothing else. Ask it to list new findings, group them by component and draft a short summary, and to say explicitly if the file is missing or older than expected. Do not let it hold write access to the repository or tickets unless a person approves each action. The inputs include package names and advisory text, which are untrusted strings.
Worked example
A team runs the scan nightly at 02:17 UTC from a workflow on the default branch. It uploads the report as an artifact. A scheduled assistant task at 03:00, read only on that artifact, writes a five line summary and posts it as a draft for the security lead. One night the workflow is delayed and the artifact is missing at 03:00. The task reports that no new report exists and stops, as its prompt instructs. The lead sees the alert and checks the workflow rather than trusting a stale summary.
Keeping the scheduled job healthy
A scheduled scan is only useful while it keeps running. Three habits help. First, record the CLI version and the scan target in the job log, so a change in results can be traced to a change in the tool or the code. Second, review the schedule itself: GitHub notes that on public repositories scheduled workflows are disabled after 60 days without repository activity, so a quiet project can lose its scan without a warning. Third, name an owner. If the owner leaves, the workflow's actor can change, and the Actions documentation says notifications go to whoever last changed the cron syntax.
Think also about what the scan should do on failure. A scan that cannot reach its service should fail the job, not report success with empty results. Check the exit code behavior of the command in your own pipeline with a deliberately broken input before you trust it, since this post does not describe exit codes beyond what the page shows.
Finally, compare scheduled scans with scans on every pull request. Both have a place: pull request scans catch new problems before merge, and scheduled scans catch newly published advisories against code that has not changed. See scan cadence, on commit or on schedule.
Fix versus report
Scanning is read only. Fixing changes code, so use separate credentials and the review steps described in should a scheduled task push code. The Safeguard CLI can also write code, and the page lists a Local agent and a Cloud agent as Available. Whatever opens the change, keep it as a pull request that must pass checks.
You can also try a quick scan without installing anything at https://gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Follow the CLI session and note which parts would run unattended in a scheduled job and which need a person.
Quick check
Does the CLI need a runtime installed?
The download page describes it as a single static binary with no runtime to install.
Where should a scheduled scan run?
In CI, where the definition is versioned and reviewable. Use an assistant task only to summarize results, with read only access.
Can the CLI install on Windows?
Yes. The page gives a PowerShell installer for Windows and a curl installer for macOS and Linux. npm is listed as coming soon.
Sources
Last reviewed: 19 October 2026.
