A weekly security review routine with Safeguard

A weekly security review fits in an hour if you run the same six blocks each week: glance at your phone, refresh the scans, triage only what is new, fix a small batch with approval, check what merged and whether the gates held, then write a short record. Safeguard runs each block from the CLI, desktop app or phone.

This guide is for a developer, tech lead or security engineer who owns a handful of repositories and wants findings to shrink rather than pile up. It gives you a one time setup, a block by block agenda with real commands, a notes template, and the fixes for the problems people hit in the first month.

You can keep the AI assistant you already use while you do it. Bring the Claude, ChatGPT or Codex plan you already pay for and use it inside the Safeguard CLI. Safeguard adds no extra charge for that usage; your plan's own usage limits and terms still apply. You can also connect Claude or ChatGPT to the Safeguard MCP server and run parts of the review from the chat you already use.

What you will have at the end

After the setup and your first week you will have:

• A scheduled scan that refreshes every project before your review starts, so you never review stale data.
• A fixed one hour agenda you can run from a desk, a laptop on a train or, for the short blocks, your phone.
• Simple triage rules, so each new finding gets one of four decisions in under a minute.
• A habit of fixing three findings a week with an assistant that asks before it changes anything.
• A check on everything that merged since last week, against a git tag you set at the end of each review.
• A weekly notes file and a week over week diff, so you can show the trend instead of describing it.

Set it up once

Do these steps before your first review. They take under an hour, and you only do them once.

1. Install the CLI and scan each repository

On macOS and Linux:

curl -fsSL https://cli.safeguard.sh/install | bash

On Windows, in PowerShell:

irm https://cli.safeguard.sh/install.ps1 | iex

Then, in each repository you own:

cd ~/code/payments-api
safeguard

Type /login to sign in through the browser, then /scan .. The CLI scans on your machine and uploads only SBOMs and findings, never your source.

2. Schedule a refresh before the review

Findings go stale as new advisories are published against packages you already ship. A scheduled scan means Monday's data is from Monday. In GitHub Actions, the schedule event runs a workflow on a cron expression:

name: weekly-security-refresh
on:
  schedule:
    - cron: "17 5 * * 1"   # 05:17 UTC every Monday
  workflow_dispatch:

jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - name: Install Safeguard CLI
        run: curl -fsSL https://cli.safeguard.sh/install | bash
      - name: Scan and upload results
        env:
          SAFEGUARD_API_KEY: ${{ secrets.SAFEGUARD_API_KEY }}
        run: safeguard ci scan --local --wait --fail-on critical

safeguard ci scan --local scans the checkout on the runner and uploads only the results, with no integration needed. It authenticates with a secret key that has the scans:trigger scope, plus scans:read for --wait, stored as the CI secret SAFEGUARD_API_KEY. If the installer puts the binary outside the runner's PATH, call it by its full path; the CI guide covers the details.

Four things from GitHub's docs are worth knowing before you rely on the schedule:

• Scheduled workflows run in UTC by default, and you can set a time zone.
• They only run on the default branch, and the workflow file must be there.
• The event can be delayed when load is high, and load peaks at the start of each hour. That is why the example uses minute 17.
• In public repositories, scheduled workflows are disabled after 60 days with no repository activity.

3. Install the desktop and phone apps

The routine moves between devices, so install both:

• Desktop app 3.2.2. Windows 10 and 11 (x64 and ARM, per user, no admin rights), macOS 12 or later on Apple Silicon (signed and notarized, with an Intel build linked) and Linux as an x86_64 AppImage. The Windows installer is not yet code signed, so SmartScreen may warn: check the SHA-256 on the download page first, then choose More info and Run anyway. See the desktop app guide.
• Phone. iOS from the App Store for iPhone and iPad; Android from Google Play, or a direct APK for phones without Google Play.

A CLI session is live: it shows in the web app, the desktop app and the phone app, and other devices can send work to it.

4. Pick a slot, an owner and a notes folder

Put a recurring hour in the calendar, early in the week, after the scheduled scan. Name one owner per week; rotating it spreads the knowledge. Create a folder for the notes and the scan outputs:

mkdir -p ~/security-review/{notes,scans}

The weekly routine, block by block

The times are a guide. Keep the order, because each block feeds the next.

Block 1: glance from your phone (5 minutes)

Before you sit down, open the Safeguard app on your phone. Your conversations are there, including any CLI session still waiting on an approval. Ask the question that frames the week:

how many critical vulns do we have, and which projects are they in?

If a command is waiting for approval from last week's work, you can answer it here. The recorded Android session below shows the flow: the same conversations appear on the phone, "Work on my computer" picks a computer running the CLI and a folder, the command waits for Allow once, Allow for turn or Deny, and the answer shows the tests passed.

Click through it at your own pace, or open it full screen.

Block 2: refresh and diff (10 minutes)

Confirm the scheduled scan ran for every project. For repositories that are not in CI yet, scan locally and keep the output by week, so you can compare:

WEEK=$(date +%G-W%V)
cd ~/code/payments-api
safeguard scan --dir . --output ~/security-review/scans/payments-api/$WEEK

safeguard scan builds an SBOM, matches it against vulnerability databases and writes JSON results, including vuln.json and license.json. With last week's folder next to this week's, the diff shows what is new:

cd ~/security-review/scans/payments-api
diff <(jq -S . 2026-W42/*/vuln.json) <(jq -S . 2026-W43/*/vuln.json) | less

If you want a quick look without uploading anything, safeguard findings sca --dir . runs a scanner locally and prints the findings in one normalised list, with package, version and fixed version. Nothing leaves the machine.

Block 3: triage only what is new (15 minutes)

The rule that keeps the review to an hour: you triage new findings, not the whole backlog. Old findings already have a decision, and that decision only changes when the evidence does.

For each new finding, check these signals:

Then give it exactly one of four decisions:

1. Fix this week. Known exploited, or reachable and exposed.
2. Schedule. Reachable but low exposure. Put it in the next sprint with an owner.
3. Not affected. Present but unreachable or not in the affected range. Record it as a VEX statement with an OpenVEX status of not_affected and a justification such as vulnerable_code_not_in_execute_path, then check it with safeguard validate --strict.
4. Accept for now. No fix exists and the risk is low. Write down why and the date you will look again.

You can ask the assistant to do the lookups for you:

list the critical and high findings in this repo with fix versions,
and say which ones reachability marks as reachable

Block 4: fix a small batch (20 minutes)

Pick up to three findings from "fix this week". Three is small enough to finish and big enough to make the trend move.

Preview dependency fixes first:

safeguard fix --severity high --dry-run
safeguard fix --package PACKAGE --patch-only

--dry-run previews changes without modifying files, and --patch-only keeps upgrades to patch versions. For anything that needs code changes, ask the assistant in the CLI, or send the work from the desktop app to the computer that has the repository. The recorded desktop session below shows that: the CLI session appears in the desktop app's conversation list, and a "2 connected" indicator shows the computer, the browser and Safeguard cloud. You ask for work on your computer, it asks which computer and folder, you pick the folder, then Approve or Deny each command and file edit. It ends with the upgrade done and tests passing.

Click through it at your own pace, or open it full screen.

Run the full test suite before you open the pull request, and keep pushes and merges with a person.

Block 5: review what merged since last week (10 minutes)

New findings are only half the picture. The other half is what your team, and any coding agents, merged. Start from the tag you set at the end of last week's review:

git fetch --tags
git log review-2026-W42..HEAD --oneline
git log review-2026-W42..HEAD --name-only -- package.json package-lock.json go.mod pom.xml requirements.txt
safeguard review --base review-2026-W42

The second git log limits the history to dependency files, so every dependency change of the week is in one list. safeguard review reviews the changes for correctness and security, and --base diffs against the ref you give it. Compare license.json between this week's scan and last week's too, if your company has licence rules. The pre-merge review checklist goes deeper on what to look for.

Block 6: gates, record and tag (5 minutes)

Check gate outcomes for the week in the web app. Policies and gates are evaluated in the platform, not by the CLI, so this is where you see whether a pipeline was blocked or warned. If a gate keeps warning on the same thing, either fix the cause or change the policy on purpose; do not let warnings become wallpaper.

Then write the notes file and tag the commit you reviewed up to:

git tag review-2026-W43 && git push origin review-2026-W43

A notes template that takes five minutes to fill in:

# Security review 2026-W43  (owner: Priya)
Projects scanned: 6/6   Scheduled scan ran: yes
New findings: 4  (critical 0, high 2, medium 2)
Decisions: fix 2, schedule 1, not affected 1 (VEX filed)
Fixed this week: 3   Open critical: 0   Open high: 5 (last week 7)
Merged dependency changes: 5, all reviewed
Gates: Release passed all week; one warn on licence policy
Next week: reread advisory for the scheduled item

To have the summary on your phone, send it to yourself: safeguard devices lists your signed in devices, and safeguard send --to DEVICE --stdin sends text read from standard input.

safeguard devices
safeguard send --to DEVICE --stdin < ~/security-review/notes/2026-W43.md

Once a month: three extras

Add 20 minutes to the first review of each month for the checks that do not change weekly.

1. Container images. Source can be clean while the image you deploy is not, because base images and system packages age. Scan the tags that are actually running:

   safeguard container-scan --image registry.example.com/payments-api:2026.10.20
   

2. SBOMs you share. If customers receive SBOMs from you, regenerate them and validate them before they go out. safeguard sbom writes an SPDX JSON SBOM for a folder or image, and safeguard validate checks CycloneDX, SPDX and VEX documents:

   safeguard sbom --dir . --output payments-api-sbom.json
   safeguard validate payments-api-sbom.json --strict
   

3. Old decisions. Reread everything marked "accept for now" or "schedule". A fix may have shipped, an advisory may have widened, or a finding may have been added to the KEV catalog since you decided. Move anything whose evidence changed back into Block 3.

Do the work properly with the Safeguard CLI

You can run the routine with separate tools. The Safeguard CLI keeps the scans, the questions, the fixes and the review in one terminal session. It scans code, container images and SBOMs on your own machine, sends only the results to the platform, and includes an assistant that can fix what it finds. It writes code, not only scans it.

Install

The one line installers are in the setup above. It is a single static binary with no Node, Python or JVM needed, for macOS, Linux and Windows on x86_64 or arm64 (Windows is x86_64 only). safeguard doctor checks the installation, sign in and tools and changes nothing. safeguard self-update updates the binary.

First session of the week

Run safeguard in a repository, then /scan .. Type / to open the command palette. Type @ to attach a file from the folder you started in, such as last week's notes, so the assistant compares against them. /resume picks up your last session in that folder, which is handy when a fix spans two weeks.

Writing and fixing code

Ask in plain language: "upgrade the packages with high findings to their patch fix versions and run the tests". The assistant has tools for local files and for your Safeguard data, and picks whichever the question needs. It reads the findings and files, proposes edits and commands, and asks before it acts. If an edit goes wrong, /rewind or safeguard checkpoints restore with --dry-run previews putting files back. Checkpoints cover files the agent writes or edits, not what a shell command writes, so keep the work on a branch.

Using your Claude, ChatGPT or Codex plan

As covered at the top, you can bring the plan you already pay for, with its own limits and terms. Run /model to see or switch the model, and see the CLI docs for connecting one. To run the glance block from Claude, follow connecting Claude to the Safeguard MCP server.

Approvals

/permissions sets the mode, shown in the bar under the input:

• Ask: reads run; edits and commands ask first.
• Accept edits: edits in this folder and read only commands run; other commands ask. A good fit for the fix block.
• Plan: read and plan only. A good fit for the triage block.
• Auto: read only commands and what the policy allows run; anything else asks. The default.
• Strict: pre approved actions only, for CI.

A --yolo flag approves everything. Keep it for throwaway sandboxes.

CI with safeguard exec

To have a written summary waiting before the review, add a step that runs one non interactive turn:

safeguard exec "summarise the critical findings in this repository" --output-format json > weekly-summary.json

Its default permission mode is strict: nothing is asked, and anything the policy file does not pre approve is denied. It refuses to run outside a git repository.

Troubleshooting

The scheduled workflow did not run. Check it is on the default branch, that the repository had activity in the last 60 days if it is public, and that you are reading the time in UTC.

The week over week diff is huge. Sorting keys with jq -S removes ordering noise, but a scanner or database update can still add many lines. Read the new IDs rather than the line count.

A finding keeps coming back after you fixed it. Another path pulls in the old version. Use npm ls PACKAGE --all or your build tool's tree, and fix every path.

The assistant will not run the tests. You are probably in Plan or Strict mode. Switch with /permissions for the session.

The desktop or phone app does not show your computer. Make sure the CLI is running and signed in on that machine; check with safeguard doctor.

Common mistakes

• Triaging the whole backlog every week. The hour disappears. Triage what is new; revisit old decisions only when evidence changes.
• Ordering by severity alone. Use exploit evidence, reachability and exposure as well.
• Skipping the merged changes block. Most new risk arrives through dependency changes you approved yourself.
• Fixing ten things and finishing none. Three finished fixes beat ten open branches.
• Not writing the record. Without notes there is no trend, and a customer question about last month becomes guesswork.
• Running the fix block in a mode that approves everything. Use Accept edits, and approve commands one at a time.

FAQ

Can I keep using Claude, ChatGPT or Codex for the routine?

Yes. Bring the Claude, ChatGPT or Codex plan you already pay for and use it inside the Safeguard CLI. Safeguard adds no extra charge for that usage; your plan's own usage limits and terms still apply. You can also connect Claude or ChatGPT to the Safeguard MCP server and ask about findings from the chat you already use.

How long should the review take?

About an hour for a handful of repositories. If it runs over, you are probably triaging old findings or fixing too many at once.

Do I need CI for this to work?

No. You can scan locally in Block 2. A scheduled scan simply means the data is fresh before you start.

Does my source code leave my machine?

No. The CLI scans locally and uploads only SBOMs and findings. safeguard findings uploads nothing at all.

Can I do the review entirely from my phone?

The glance and approvals work well on the phone, and you can send work to a computer running the CLI. The diff and merged changes blocks are easier at a desk, in the CLI or the desktop app.

What about findings with no fix available?

Decide "accept for now" or "not affected", write down why, and set a date to look again. If you share status with customers, a validated VEX document is the clearest record.

Who should own the review?

One named person per week. Rotating the owner across the team spreads knowledge of the codebase's risk.

Try it yourself

This walkthrough shows how to set up the runner on your own machine: pick the platform, start it, approve it with its device code, then use the same CLI to scan from the terminal.

Click through it at your own pace, or open it full screen.

Ready to run your first review? Download the Safeguard CLI, run safeguard, type /login, then /scan . in each repository, and book the hour. The full reference is in the CLI docs.

Quick check

Sources

• Safeguard CLI overview
• Safeguard CLI interactive terminal
• Safeguard downloads
• GitHub Actions: events that trigger workflows (schedule)
• actions/checkout
• CISA Known Exploited Vulnerabilities catalog
• FIRST Exploit Prediction Scoring System
• FIRST CVSS v4.0
• OpenVEX specification
• git log documentation
• npm ls documentation

Last reviewed: 21 October 2026.