Prepare for a security questionnaire with Safeguard

To answer a security questionnaire faster with Safeguard, collect the evidence before you write a word: an SBOM for the release in scope, current findings, VEX statements for what does not affect you, and your policy and gate records. Then draft answers from that data with Griffin, review every one, and publish what you can in a Trust Center.

The assistant that helps you can run on the plan you already have. 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 your findings from the chat you already use.

This guide follows a sample service, payments-api 1.8.0, and a customer spreadsheet asking how you build, test and patch it.

What you will have at the end:

• An answer map that sorts each question by where its evidence lives.
• A validated SBOM for the exact release the customer runs, plus a scan of it.
• A short list of findings you fixed before answering, and VEX statements for the ones that do not apply.
• Policy, gate and exception records you can quote as proof of process.
• Draft answers written from your own data, reviewed by a person.
• A Trust Center that answers the common questions before they are asked, with restricted documents behind an NDA.

Why questionnaires take so long, and where the answers already live

Most questionnaire time goes on finding out, not writing: which version shipped, how many critical issues are open, where last year's policy is, whether the previous answer is still true.

Safeguard already holds most of that, because it is the system that scanned the code. The table below maps common question themes to the place in Safeguard that answers them.

Two rules make the rest of this guide work. First, answer for one named release, not "the product". Second, every answer should point at something a reviewer could check, such as a file, a record or a page.

Before you start

You need four things in place.

1. The Safeguard CLI on your machine. On macOS and Linux run curl -fsSL https://cli.safeguard.sh/install | bash. On Windows run irm https://cli.safeguard.sh/install.ps1 | iex in PowerShell. It is a single static binary with no Node, Python or JVM needed.
2. A signed in session. Run safeguard, then /login, which signs you in through the browser.
3. The project in Safeguard. If payments-api is not connected yet, a first /scan . from the repository folder gives you something to work with.
4. The right role for Trust Center work. The Trust Center lives under Compliance › Trust Center. If that tab is missing, the feature is not switched on for your workspace and your Safeguard administrator needs to turn it on. Approving access requests and publishing an audit outcome need a compliance reviewer.

Open the questionnaire and add two columns: "evidence source" and "status".

Step by step: from blank spreadsheet to reviewed answers

Step 1. Build your answer map

Go through the questionnaire once without answering anything. For each row, write the theme from the table above into the "evidence source" column. Questions that Safeguard cannot answer, such as office access controls or HR screening, get "other team" and go to their owner today, not on the day before the deadline.

Then group questions that ask the same thing in different words. "Do you scan dependencies?", "How do you track third party components?" and "Can you provide a software bill of materials?" all come from the same SBOM and the same scan.

Step 2. Generate an SBOM for the release in scope

Check out the tag the customer runs, then generate the SBOM on your own machine:

git checkout v1.8.0
npm ci
safeguard sbom --dir . --output payments-api-1.8.0-sbom.json

safeguard sbom writes SPDX JSON and stops at the SBOM, without going on to vulnerability analysis. Installing dependencies first matters, because an SBOM can only list what is on disk.

Now check the file meets its format specification:

safeguard validate payments-api-1.8.0-sbom.json --strict -o sbom-validation.json

--strict treats warnings as errors, and -o keeps a report. Keep that report with your questionnaire evidence. If a customer later says your SBOM does not parse, you have a record that it did when you sent it.

Step 3. Scan it and get the numbers

Next, match the SBOM against vulnerability databases:

safeguard scan --sbom payments-api-1.8.0-sbom.json

Results are written as JSON files under ./output, including vuln.json for vulnerabilities and license.json for licences. Those two files answer the vulnerability count and licence questions directly.

If you want a quick look before anything is registered in the platform, run a scanner locally instead:

safeguard findings sca --dir . --json

safeguard findings prints one normalized list with severity, the CVE or rule, the package and version, and the fixed version where one is known. Nothing leaves the machine: no project is registered and no finding is uploaded, even when the CLI is signed in.

Do not paste these counts into the questionnaire yet.

Step 4. Fix what you can before you answer

"One high severity issue, fixed in 1.8.1" reads very differently from "one high severity issue, open". If a fix is a version bump away, do it now.

From the repository folder, open the assistant and ask in plain language:

safeguard
> fix the lodash CVE in this repo

The recorded session below shows exactly this on a sample payments-api project. The assistant reads the finding, the files and the advisory, then asks before each command, where you press y or n. It edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, and prints a summary with a suggested commit message. It pushes nothing. The session then shows /permissions, /model and /scan ..

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

After the fix ships, repeat Steps 2 and 3 for the new tag, and answer for the release the customer will actually run.

Step 5. Write VEX statements for what does not affect you

Some remaining findings will not affect your product, for example because the vulnerable code is never shipped. VEX records that in a machine readable form.

Here is a minimal OpenVEX statement for a finding where the vulnerable code is not present:

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

Replace the placeholder identifier with the real one from your scan, then validate the file:

safeguard validate payments-api-1.8.0.openvex.json --strict

safeguard validate checks CSAF and OpenVEX documents as well as CycloneDX and SPDX.

Then upload it to the platform. Open Integrations from the sidebar, filter by Upload, and click Connect on the Upload CSAF/VEX card. Enter a Name, drop the file in, set the Project Name and Version, and click Upload. Safeguard accepts CSAF 2.0, CycloneDX VEX, OpenVEX and the CSAF VEX profile, all as JSON, and validates the file on upload. Uploading VEX can mark vulnerabilities as not affected for your products, which is the record you want behind an exploitability answer.

Only write not_affected when someone has checked. A VEX statement is a claim your customer may rely on.

Step 6. Turn policies and gates into proof of process

Many questions are not about today's numbers. They ask whether you have a process: "Do you prevent known critical vulnerabilities from reaching production?" "How are exceptions approved?" Policies and gates answer those.

In Safeguard, policies are rules that evaluate your SBOMs and generate findings, and gates are checkpoints that enforce them. To create one, go to Settings → Policies, click Create Policy, define conditions with the visual builder or YAML, set severity and actions, then save and enable. Conditions include vulnerability severity, CVSS score, EPSS score, licence, component age, maintenance and SLSA level. Actions are Block, Warn and Notify.

Policies and gates are evaluated in the platform, on scans it runs for connected repositories. Where policy outcomes are switched on for your workspace, a CI job can fail on a gate:

safeguard ci scan --wait --fail-on-gate no-critical-vulns

Use your own gate name in place of no-critical-vulns.

Reviewers also ask what happens when you cannot fix something. In Safeguard you click Request Exception, select the policy and finding, give a business justification, set an expiration date and submit for approval. Approvers approve or deny, and each decision goes into the audit trail. Policy reports cover compliance status by policy, exception history and violation trends.

So the honest answer to "do you block releases with critical vulnerabilities?" becomes something like: "Yes. A policy blocks the gate on any critical vulnerability. Exceptions need a written justification, an expiry date and an approver, and every decision is recorded." Only write that if it is how your gates are actually set.

Step 7. Draft answers from your data with Griffin

Now you write. Griffin AI is Safeguard's model for software supply chain security, and it can search your SBOMs and findings in natural language. You reach it from the search bar or the chat interface. The docs give prompts such as:

• "Show me all critical vulnerabilities in production services"
• "What GPL-licensed packages are we using?"
• "Compare last two scans"
• "Generate executive summary"

For a questionnaire, ask one question per row group from your answer map, and ask for the evidence with the answer. For example: "How many open critical and high vulnerabilities affect payments-api 1.8.1, and which are marked not affected by VEX?" Paste the answer into your draft column, then check it against vuln.json and the VEX you uploaded.

From the terminal, ask the interactive CLI "how many critical vulns do we have", or draft a set of questions kept in your repository with one non-interactive turn:

safeguard exec --restricted "Read questionnaire/vuln-management.md and draft an answer to each question using our current Safeguard findings for payments-api. Mark any answer you are not sure of as NEEDS REVIEW."

--restricted gives the turn a read-only tool set, with no writes, no shell and no network, which suits drafting. safeguard exec runs in strict permission mode by default and refuses to run outside a git repository.

If your team lives in Claude or ChatGPT, connect it to the Safeguard MCP server instead and ask the same questions there. The steps are in connecting Claude to the Safeguard MCP server and connecting ChatGPT to the Safeguard MCP server.

Whatever drafts the answer, a person signs it off. Read every draft, compare it with the source, and remove anything you cannot stand behind.

On data handling, which reviewers sometimes ask about when you mention AI: the Griffin docs state that it runs on Safeguard infrastructure and that customer code is never stored or used for training.

Step 8. Send the SBOM with the right access

If the questionnaire asks for the SBOM itself, share it from the platform rather than by email attachment. Pick View (online only), Download or Full (view, download and re-share), or click Create Link to set an expiration date, download limit and password. You can also require NDA acceptance. Tracking shows who opened it, and Revoke ends access immediately. View or Download with an expiry date suits most requests.

Step 9. Publish what you can in a Trust Center

The fastest questionnaire is the one the customer does not send because they found the answers already. A Safeguard Trust Center is a public page at an address like your-slug.trust.safeguard.sh that shows your compliance status, controls, policies, sub-processors and documents.

Set it up under Compliance › Trust Center:

1. Choose Edit Trust Center to edit the live page in place, or Advanced settings for the full form.
2. Fill in the Public slug, Organization name, Headline, Description, Security contact email and Privacy contact email.
3. Add an FAQ. Take the questions you answer most often from Step 1 and answer them once here.
4. Add documents with Add document. Pick a Category (the list includes Compliance report, Penetration test, Questionnaire and Policy) and a Visibility of Public or Restricted. A completed standard questionnaire you are happy to reuse fits the Questionnaire category, usually as Restricted. Each file shows its size and SHA-256 hash.
5. In Advanced settings, turn on Publish Trust Center and save. Until you do, the public page returns a 404, and new content such as a highlight starts as a draft.

Framework statuses need care. A framework shows Compliant, In progress, Not assessed or Signed. Frameworks that require an independent auditor or certification body cannot be declared Compliant through self-assessment, so show the issued report or certificate instead. If your SOC 2 audit is still under way, the honest status is In progress, and that is what your questionnaire answer should say as well.

For a Not assessed framework you can choose Publish live readiness, which shows your control readiness score. It is a readiness score, not an audit, and the page says so. Published controls are read live from continuous monitoring, so a failing control shows as failing without you republishing.

Step 10. Handle requests for restricted documents

A customer who wants restricted documents selects Request access, confirms their email and accepts your current NDA by ticking a box and typing their full name. Each acceptance records the NDA version, name, time, IP address, browser and the agreement's SHA-256 hash.

Your team sees the request in Access requests with flags such as "Free email" and "Previously denied". A compliance reviewer chooses Approve, sets Access to Full or Limited and sets Access ends, or chooses Deny with an optional reason. Under Viewers you can Revoke access, which signs the viewer out immediately. The Access log records approvals, denials, NDA acceptances and downloads, and Export CSV gives you a copy.

That log shows who outside the company has seen your security documents, and on what terms. Repeat Steps 2 to 6 on every release so the next questionnaire starts from current data.

Do the work properly with the Safeguard CLI

Most of this work starts in the terminal, where the code and release tags are. 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 and edits code, not only scans. When the local runner runs platform scan jobs, your source code never leaves the machine; only SBOMs and findings are uploaded. For a wider tour, see the Safeguard CLI as a security aware coding assistant.

Install and first session

Install with the command from Before you start. It runs on macOS, Linux and Windows, on x86_64 or arm64 (Windows x86_64 only). @ attaches a file from the folder you started in, which is handy for @questionnaire.csv. /resume picks up the last session in that folder.

Use your Claude, ChatGPT or Codex plan

/model shows or switches the AI model. The plan you already pay for works here, as covered at the top of this guide; see the CLI docs or /model for connecting a model.

Approvals

The assistant has tools for your local files and for your Safeguard data. Tools that change things, such as writing a file, editing code or running a command, ask before they act. /permissions sets the mode:

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

There is also a --yolo flag that approves everything. Keep it for throwaway sandboxes only.

One live session, three devices

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. From the desktop or phone app you pick the computer and folder, then approve each command and file edit there. The recorded session below shows the desktop app: the CLI conversation appears in the list, "2 connected" shows the computer, the browser and Safeguard cloud, you pick the folder, then Approve or Deny each command and file edit, and it ends with the upgrade done and tests passing.

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

So a security lead can ask for a fix from the desktop app while an engineer approves it on the machine with the repository. The desktop app guide covers setup.

CI with safeguard exec

safeguard exec "summarise the critical findings in this repository" runs one non-interactive assistant turn, so you can produce a fresh findings summary on every release and keep it with your evidence. Running the Safeguard CLI in CI with safeguard exec has a full pipeline.

Troubleshooting

The SBOM lists fewer components than you expect. Dependencies were not installed when you generated it. Run your package manager's install step first, such as npm ci, then run safeguard sbom again.

safeguard validate fails on your VEX file. Check that it is valid JSON, that required fields are present, and that it is one of the supported formats. The upload page lists the same three common errors: "Invalid file format", "Schema validation failed" and "Unsupported VEX format".

The public Trust Center page shows a 404. Publish Trust Center is off. Turn it on in Advanced settings and save.

safeguard exec refuses to run. It will not run outside a git repository, because there would be no way to undo what it changes. Run it from the repository folder.

Common mistakes

• Answering for "the product" instead of a release. Name the version every time. Numbers change with each build.
• Writing not_affected without checking. A VEX statement is a claim. If nobody has confirmed the vulnerable code is absent, leave the statement out until someone has.
• Sending AI drafts unread. Griffin and the CLI assistant draft from your data, but a person signs off. Check every number against vuln.json or the platform.
• Overstating compliance. If an audit is in progress, say "in progress". Never imply an audit result you do not hold.
• Answering the same question twice. Anything you have answered for two customers belongs in the Trust Center FAQ.

FAQ

Can I keep using my Claude, ChatGPT or Codex subscription for this work?

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 use Safeguard from the chat you already use. See the CLI docs or /model for connecting a model.

Does Safeguard fill in the questionnaire for me?

Safeguard holds the evidence and Griffin can draft answers from it, but you stay in charge of what is sent. Treat every draft as a starting point. Safeguard's compliance workflows are built the same way: assistants can prepare work, and a person approves it.

Does preparing evidence upload my source code?

safeguard findings uploads nothing at all. When the local runner runs platform scan jobs, your source code stays on your machine and only SBOMs and findings are uploaded.

How do I answer "are you affected by this advisory?"

Search for the component in your findings, decide whether it affects the release, and record the result as a VEX statement. Upload it through the Upload CSAF/VEX card so the platform marks it not affected for that product. Then quote the VEX status and justification in your answer.

Can I give a customer my pen test report without emailing it?

Yes. Add it to the Trust Center with Add document, category Penetration test, visibility Restricted. The customer requests access, accepts your NDA, and a compliance reviewer approves it with an end date. Every download is in the Access log.

What should I write about our SOC 2 status?

Write what is true on the day. If your audit is under way, say it is in progress. In the Trust Center, a framework that needs an independent auditor cannot be declared Compliant through self-assessment, so show the issued report when you have it and keep the page and your answer in agreement.

Try it yourself

This walkthrough 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.

Then download Safeguard for the terminal, the desktop or your phone, generate an SBOM for your latest release and start your answer map before the next questionnaire lands. Every command is in the CLI docs.

Quick check

Sources

• Safeguard CLI documentation
• Safeguard CLI: interactive terminal
• Safeguard downloads
• Safeguard: Trust Center
• Safeguard: Trust Center access requests
• Safeguard: Compliance
• Safeguard: Requests and approvals
• Safeguard: Griffin AI
• Safeguard: Policies and gates
• Safeguard: CSAF and VEX uploads
• Safeguard: Sharing SBOMs

Last reviewed: 21 October 2026.