An AppSec engineer's day is mostly deciding what not to fix. Safeguard's job in that day is to shrink the list, show the evidence for each item, and make the fix path short.
Here is a realistic day built only from documented behavior.
What it is
You will touch four surfaces. The web app at app.safeguard.sh for findings and policy. The CLI for local scans. The IDE extensions and MCP for the places developers already work. And the platform's policy gates, which decide pass or fail.
The Security Engineer role is scoped for this work: it can triage and remediate findings but cannot modify policy. Policy changes belong to the Security Lead.
How to use it
Morning: triage
Start with a query in the global search bar, which accepts filter and boolean syntax:
severity:critical AND reachable:true
Safeguard classifies a vulnerability as reachable, conditionally reachable, unreachable or unknown. Unknown is treated conservatively as potentially reachable, so read it as "needs a human" rather than "safe". The prioritization docs also combine exploitability signals, EPSS and the CISA KEV list, so a reachable CVE that is also on KEV goes to the top.
You can ask the same thing in chat, for example "which critical findings are reachable and in production". Griffin AI can propose a remediation, and the docs say proposed remediations are reviewed by a person.
Midday: scan what has not been pushed
Some code never reaches a connected repository, or lives in a private repo you will not give OAuth access to. Use the CLI. Install it, then:
curl -fsSL https://cli.safeguard.sh/install | bash
safeguard
Type /login, approve the session in the browser, then /scan . to scan the folder. When you scan from the signed in terminal, the runner uploads the SBOM and findings. Your source stays on the machine. For a one off command outside the terminal:
safeguard scan --dir .
safeguard detect --detect secrets --format sarif --output detect.sarif
One thing to know: safeguard scan exits 0 whenever the scan ran, whatever it found. It exits 2 if results were written but the vulnerability scan did not run. There is no severity threshold flag, so failing a build is done with a policy gate in the platform.
Afternoon: review pull requests
PR Guard is Safeguard's AI code review for pull requests. It appears as a tab on a project page, analyzes the diff and returns a scored summary with comments tied to files and lines. The docs say its current implementation is wired to GitHub pull requests, so check your repository provider first. You can tick Post to GitHub to publish the comments onto the pull request itself.
Anywhere: ask from your assistant
Connect Claude, ChatGPT, Cursor or your own agent to mcp.safeguard.sh. Ask it to list critical vulnerabilities or generate a remediation plan for an npm project. If a tool you want is missing, it is probably off by design: every tool beyond the six read-only defaults is enabled one at a time by an administrator.
Optional: choose the model
The CLI scanner can use an LLM for optional source analysis, and it also works in Zero AI mode. If a repo cannot go near a hosted model, run Zero AI.
Try it yourself
Take one critical finding from your backlog. Check whether it is reachable, whether it is on the KEV list, and what fix version exists. Write down your decision and the evidence in two lines. If the reachability demo matches your case, click through it.
Click through it at your own pace, or open it full screen.
Quick check
Does safeguard scan fail a build when it finds critical vulnerabilities?
No. It exits 0 when the scan ran. Gating on findings is done by policy gates in the platform.
How should an unknown reachability result be read?
Conservatively, as potentially reachable, and as a candidate for human review.
