The Safeguard VS Code extension can generate and export an SBOM, run a compliance check and export reports of findings for an audit. It is a good source of dated, project level evidence. It is not an audit trail on its own, so you must add scope notes, review sign off and retention.
What does the extension provide?
From the Safeguard docs for IDE support, the VS Code extension (which also works in Cursor through Open VSX) has a Safeguard activity bar view with Vulnerabilities, SBOM, Compliance and Recommendations panels. It installs from the VS Code Marketplace, and the docs give a command line install using the publisher and extension identifier on the page.
Relevant commands listed in the docs include:
- Generate SBOM, Export SBOM, and Compare SBOM with Previous
- Check Compliance, with standards OWASP and EU AI Act named
- Check Code Quality and Check Security Posture
- View Dependency Graph
- Export Security Report
- Export Conversation, for the AI assistant chat
The docs also say you can right-click any panel and choose Export Report to save findings for an audit.
Settings include enableSBOM, enableCompliance, which is on by default, and complianceStandards, which defaults to OWASP, CWE and NIST. SBOM export is supported in CycloneDX and SPDX formats.
What would an auditor want?
Auditors usually ask for evidence that is dated, scoped, reproducible and tied to a control. For a software supply chain control, that means:
- A list of components in a named system at a named time. An SBOM export does that.
- Proof that you look for known flaws and act on them. A findings report with a date, plus the fix history, does that.
- Proof that the process repeats. Several dated exports over time show a pattern.
- Who reviewed it. That has to come from you.
How do you use the extension to produce it?
- Open the project and sign in. Public package scanning works without login. Backend features need it.
- Run Generate SBOM, then Export SBOM in the format your auditor accepts, CycloneDX or SPDX.
- Run Scan Project for Vulnerabilities and use Export Report from the findings panel.
- Run Compare SBOM with Previous after a release, and keep the comparison as evidence of change control.
- Run Check Compliance and export the result if the control you are evidencing maps to a listed standard.
- Name each file with the system, the date and the commit it covers, and store it with your other evidence.
- Add a short note: who ran it, why, and what was done about open findings.
What are the limits?
The docs do not describe the report format, a retention period, tamper protection or pass and fail criteria for the compliance check. They also do not document an audit log inside the extension. Treat the exports as inputs to your own evidence process. Confirm on your installation what each report contains before you promise it to an auditor.
Exports from one developer's machine cover that checkout. They do not prove what runs in production. For that, generate the SBOM from the build in CI, and use the IDE exports as a developer side check.
Also, nothing here certifies you. Safeguard's compliance automation can help organize evidence, and certification or attestation comes from the relevant assessor.
What to do
- Decide which control you are evidencing, and what artifact proves it.
- Run the exports on a schedule that matches your audit period, such as at each release.
- Keep a consistent naming rule and one storage location.
- Pair every export with a review note and a record of fixes.
- Test retrieval: ask a colleague to find the evidence for a past date in ten minutes.
Quick check
Which SBOM formats can the extension export?
The docs say CycloneDX and SPDX.
Is an exported report enough for an auditor?
Usually not alone. Add the date, the scope, who reviewed it and what you did about the findings, and keep it with your other evidence.
Sources
Last reviewed: 18 October 2026.
