Safeguard for security teams: a day to day working guide

Security teams get the most from Safeguard with a short daily routine: triage new findings in the desktop app or on your phone, rank them by reachability and public exploit data, fix the urgent ones with the CLI assistant under your approval, and record every not affected decision. Policies and gates in the platform then hold the line in CI.

This guide walks through that routine as you would actually run it, from the first look at the queue in the morning to the weekly review. It uses the Safeguard CLI, the desktop app and the phone apps together, because a security engineer's day moves between all three.

You keep the AI assistant you already use. 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 window you already have open.

What you will have at the end

Follow the steps and you will have:

1. A morning triage you can finish in the desktop app or on your phone, with a written ranking rule your whole team uses.
2. A repeatable way to check a developer's branch locally before you comment, without uploading anything.
3. A fix loop where the assistant edits code and runs tests only after you approve each command and file edit.
4. Validated VEX documents for every vulnerability you decide does not affect a product.
5. Gates in the platform that platform teams can enforce in CI with one flag.
6. A weekly summary you can produce from a script.

Do the work properly with the Safeguard CLI

The Safeguard CLI 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, and it already knows your vulnerabilities, so you never paste scan output into a chat window.

Install

On macOS and Linux:

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

On Windows, in PowerShell:

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

It is a single static binary with no Node, Python or JVM needed, for macOS, Linux and Windows on x86_64 or arm64 (Windows ships x86_64 only). Run safeguard --version to confirm, and safeguard doctor if anything looks wrong. Doctor checks the environment, sign in, profile, policy and tools, and changes nothing.

First session

Run safeguard with no arguments to open the interactive terminal. Type /login to sign in through the browser. In a repository, /scan . scans the current folder. Then ask in plain language. The docs give examples such as "how many critical vulns do we have" and "fix the lodash CVE in this repo".

The assistant has tools for your local files and for your Safeguard data, and picks whichever the question needs. So the same session can answer a question about your whole estate and then open the file that matters. Type @ to attach a file from the folder you started in, /model to see or switch the model, and /resume to pick up the last session in that folder.

Approvals that suit security work

Tools that change things, such as writing a file, editing code or running a command, ask before they act. /permissions sets how much asks:

• Ask. Reads run; edits and commands ask first. Good for repositories you do not own.
• Accept edits. Edits in this folder and read only commands run; other commands ask.
• Plan. Read and plan only. Use it when you investigate a team's repository and want a written plan with no changes at all.
• Auto. The default. Read only commands and what the policy allows run; anything else asks.
• Strict. Pre-approved actions only, for CI.

There is also a --yolo flag that approves everything. It belongs in throwaway sandboxes only, never on a machine with credentials or customer data.

Scripted runs

safeguard exec "summarise the critical findings in this repository" runs one non interactive assistant turn and exits. Its default mode is strict: nothing is asked, and anything not pre-approved by the policy file is denied. Add --restricted for a read only tool set with no writes, no shell and no network, which is a sensible default for reporting jobs.

Morning triage, step by step

Step 1: Open the queue where you are

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. Start wherever you are: the desktop app on your workstation, or the iOS or Android app on the way in. The desktop app (3.2.2) runs on Windows, macOS and Linux, and the desktop app guide covers setup.

Ask the same plain language questions you would ask in the terminal:

how many critical vulns do we have
which critical or high findings are new since yesterday, and in which projects
for each one, is it a direct or transitive dependency, and is there a fixed version

For every finding you keep on the list, you want five facts before you decide anything: the package, the installed version, the version that fixes it, whether it is direct or transitive, and the path that pulls it in. A direct dependency is a one line change in a manifest. A transitive one usually means upgrading the parent that brings it in, which is a bigger conversation with the owning team. Getting these five facts in the first minute saves a round trip later.

Step 2: Rank with a written rule

Severity alone produces a long queue. Write down a ranking rule once and use it every morning, so two people looking at the same finding make the same call. Three inputs are worth combining:

• Reachability. Safeguard's reachability analysis helps you see whether your code can actually reach the vulnerable code, so you work reachable findings first.
• CISA KEV. The Known Exploited Vulnerabilities catalog is CISA's list of vulnerabilities exploited in the wild. CISA says organisations should use it as an input to their vulnerability management prioritisation. It is published as CSV and JSON as well as a web page.
• EPSS. FIRST's Exploit Prediction Scoring System publishes a daily probability, between 0 and 1, that a published CVE will be exploited in the wild in the next 30 days. It is a forecast of likelihood, not a measure of severity.

A rule many teams start from, then tune:

The targets are yours to set. What matters is that the rule is written down and the same for everyone.

Step 3: Confirm locally before you comment

Before you ask a team to change something, check their branch on your own machine. safeguard findings runs one scanner locally and prints a single normalised list: id, severity, title, CVE or rule, package and version, fixed version, description and remediation. Nothing leaves the machine, even when the CLI is signed in.

git clone https://git.example.com/payments/payments-api.git
cd payments-api
git checkout feature/new-billing
safeguard findings sca --dir .
safeguard findings iac --dir ./deploy --json

That gives you a fact to quote in your comment instead of a screenshot from last week.

The same works for images and infrastructure another team owns. safeguard findings container --image node:22-slim --json checks a base image they plan to adopt, and safeguard iac-scan --target ./deploy runs a misconfiguration scan over Terraform, CloudFormation, Helm, Kubernetes manifests, Dockerfiles and ARM or Bicep and records the result in the platform.

Step 4: Hand off with everything the owner needs

A finding that reaches a developer without context comes back as a question. A good handoff has the five facts from step 1, your ranking from step 2, the command you ran in step 3 and what you expect: "upgrade to the fixed version this week" or "tell me if this code path is reachable from the API". Short and specific beats a long ticket.

If you find something on the desktop and want to pick it up later on your phone, safeguard devices lists your signed in devices and safeguard send --to pixel --link https://app.example.com/finding/123 sends the link to one of them. --text sends up to 8,000 characters of notes instead. safeguard inbox on the CLI shows what your other devices sent back to it.

Step 5: Approve fixes from the phone if you need to

If the fix is small and the developer's machine or a shared build host runs the CLI, you can approve it from wherever you are. In this recorded Android session 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 on the phone, and the answer shows the tests passed.

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

Android installs from Google Play, with a direct APK on the download page for phones without Google Play or for company managed rollout. iPhone and iPad install from the App Store. The Android guide covers the details.

Fix, review and record decisions

Fix with the assistant, one approval at a time

From the desktop app you can send the work to a computer running the CLI. In this recorded desktop session, the CLI session shows in the app's conversation list and "2 connected" shows the computer, the browser and Safeguard cloud. You ask for work on your computer, the app 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.

A prompt that keeps the change small:

Fix the high and critical findings in this repo from the latest scan.
Use the lowest version that fixes each one.
Change only the manifest and the lockfile. Do not add packages.
Ask me before any major version change.
Run the tests, then list every package you changed with old and new versions.

For a non interactive preview, safeguard fix shows what it would change without touching files:

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

It only upgrades by default and keeps to minor and patch versions unless you allow major upgrades. In the platform, autonomous remediation can open fix PRs for you. It ships switched off, so turning it on, and for which categories, is a decision for your team.

Review what changed before it merges

Some changes are written by coding agents. Review the result the same way, whoever wrote it:

git fetch origin
git checkout feature/new-billing
safeguard review --base origin/main
safeguard findings sca --dir .

safeguard review reviews the working tree changes for correctness and security; --base diffs against a git ref instead. The longer checklist is in review AI generated code before merge.

If an assistant session edited a file you did not want changed, safeguard checkpoints list --session ID lists the snapshots taken before each file change, and safeguard checkpoints restore CHECKPOINT --session ID --dry-run shows the restore as a diff first. These are the same checkpoints /rewind uses. Files the agent writes or edits are snapshotted; anything a shell command writes is not.

Record not affected decisions as VEX

When a finding does not affect a product, write that down in a form machines can read. OpenVEX defines four statuses: not_affected, affected, fixed and under_investigation. A not_affected statement must carry a justification or an impact statement. The justifications are component_not_present, vulnerable_code_not_present, vulnerable_code_not_in_execute_path, vulnerable_code_cannot_be_controlled_by_adversary and inline_mitigations_already_exist.

A minimal document, with placeholders for the identifiers:

{
  "@context": "https://openvex.dev/ns/v0.2.0",
  "@id": "https://example.com/vex/payments-api-2026-10-21",
  "author": "Security team",
  "timestamp": "2026-10-21T09:00:00Z",
  "version": 1,
  "statements": [
    {
      "vulnerability": { "name": "CVE-YYYY-NNNNN" },
      "products": [
        {
          "@id": "pkg:npm/payments-api@1.8.0",
          "subcomponents": [{ "@id": "pkg:npm/example-lib@2.3.1" }]
        }
      ],
      "status": "not_affected",
      "justification": "vulnerable_code_not_in_execute_path"
    }
  ]
}

Then validate it before anyone relies on it:

safeguard validate payments-api.openvex.json --strict
safeguard validate ./vex --recursive -o vex-report.json

safeguard validate checks CycloneDX, SPDX and VEX (CSAF or OpenVEX) documents. --strict treats warnings as errors.

Weekly and on demand work

When a new disclosure lands

Ask across the estate first, then go to the repositories:

which projects include example-lib, at which versions, and is the vulnerable function reachable in each

Then work the reachable ones with the fix loop above, and record VEX statements for the rest.

When a vendor sends an SBOM

Validate it, then scan it:

safeguard validate vendor-gateway.cdx.json --strict
safeguard scan --sbom vendor-gateway.cdx.json

safeguard scan builds or reads the SBOM and matches it against vulnerability databases. Results are JSON files under ./output, including vuln.json and license.json, which you can attach to the vendor review.

Set the gates, let CI enforce them

Policies and gates are evaluated in the platform, not by the CLI. Your team writes the policies and gives each one an action such as block, warn or notify. Platform teams then add one flag to their pipeline:

safeguard ci scan --wait --fail-on-gate Release

The step fails when the gate is Failed (a policy with the block action failed), Error or Not evaluated. Warning, where only warn policies failed, and Passed both pass, and failed warn and notify policies are printed in the log. This needs the policies outcomes feature on your tenant. Changing what blocks a release then means editing a policy, not fifty pipeline files. For scripted reports in CI, see Safeguard CLI in CI with safeguard exec.

The weekly summary

Run one read only summary per repository and collect the output:

for repo in payments-api ledger-service web-checkout; do
  (cd "$repo" && safeguard exec --restricted --output-format json \
    "summarise the critical findings in this repository") > "summary-$repo.json"
done

exec refuses to run outside a git repository, so run it in each checkout.

A weekly review agenda

Thirty minutes once a week keeps the queue honest. A simple agenda:

1. Read the weekly summaries and compare the count of reachable critical and high findings with last week.
2. Go through anything in rows 1 and 2 of your ranking table that is still open, and ask the owner for a date.
3. Review VEX statements older than a month. Code changes, and a path that was unreachable can become reachable.
4. Look at gate outcomes from the week. Repeated Warning results on the same policy may mean it should block, or that it needs rewording.
5. Check whether any vendor SBOMs arrived and were validated and scanned.
6. Write down one change to the ranking rule or a policy, or decide explicitly that nothing changes.

Keep the notes in one place. Over a quarter they become the record of how your team made decisions, which is what auditors and customers ask for.

Ask from Claude or ChatGPT

Some questions come up in a chat you already have open. Connect Claude or ChatGPT to the Safeguard MCP server with OAuth, choose which tools it may use, and ask there. The setup is in connect Claude to the Safeguard MCP server.

Troubleshooting and common mistakes

Troubleshooting

The desktop or phone app shows no computer to send work to. The CLI has to be running and signed in on that computer. On the computer, run safeguard doctor and check it can make outbound HTTPS calls. For a machine that should always be reachable, safeguard runner install registers a per user login service.

safeguard findings results do not show up in the platform. That is by design: findings uploads nothing. Use safeguard scan when the result should be recorded.

safeguard validate fails on a vendor file that looks fine. Check the format first. Use --format to force one, for example --format cyclonedx-xml, and drop --strict once to see whether you are looking at warnings or errors.

safeguard exec refuses to start. It will not run outside a git repository. Run it inside the checkout.

A gate shows Not evaluated and the build failed. Not evaluated fails the step on purpose. Confirm the gate name and that the policies outcomes feature is on.

Common mistakes

• Ranking by CVSS alone. Combine reachability, KEV and EPSS in a written rule.
• Closing findings without a record. Write a VEX statement with a justification, and validate it.
• Reviewing in Auto mode on someone else's repository. Use Plan to investigate and Ask to change.
• Trusting the assistant's word that it is fixed. Run the scan again. A finding is fixed when the scanner stops reporting it.
• Using --yolo to save clicks. It approves everything. Keep it for throwaway sandboxes.
• Putting release rules in pipeline YAML. Keep them in platform gates so you can change them in one place.

FAQ

Can my team use the AI plan we already pay for?

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. See the CLI docs or /model for connecting a model. You can also connect Claude or ChatGPT to the Safeguard MCP server.

Does our source code leave the machine?

Not when you work in the CLI. It scans on your machine and uploads SBOMs and findings, never source. safeguard findings uploads nothing at all.

Will the assistant change code without asking?

No. Writing a file, editing code or running a command asks first, according to the /permissions mode. Plan mode reads and plans only.

Do we still need KEV and EPSS?

They are public inputs that complement reachability. Use them together in your ranking rule.

Can I triage without a laptop?

Yes. The iOS and Android apps show the same conversations, and you can approve or deny each command on a computer running the CLI from the phone.

Who enforces our policies?

The platform evaluates policies and gates. Pipelines enforce the result with safeguard ci scan --fail-on-gate.

What if the same finding shows up in many projects?

Ask across the estate once, rank each project with the same rule, and fix the reachable ones first. Record VEX statements per product for the rest, because reachability can differ between products that share a library.

Does Safeguard open fix PRs automatically?

Only if you turn it on. Autonomous remediation ships switched off.

Try it yourself

This demo sets 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.

Download the CLI, desktop and phone apps from safeguard.sh/download, and keep the CLI docs open while you set up your first morning triage.

Quick check

Sources

• Safeguard CLI documentation
• Safeguard CLI interactive terminal
• Safeguard download page
• CISA Known Exploited Vulnerabilities Catalog
• FIRST Exploit Prediction Scoring System
• OpenVEX specification
• CycloneDX specification overview

Last reviewed: 21 October 2026.