One Dataset, Four Audiences: Security Reports from Safeguard

The same Safeguard scan should produce four different documents: an upgrade list for the engineer, a ranked week of work for the AppSec lead, one number and its direction for the executive, and dated, scoped evidence for the auditor or customer. Safeguard's reporting workflow does this from one dataset, either in the Safeguard app's dashboards and exports or in Claude through the Safeguard connector, where a reporting skill picks the layout, fills a copy-ready template and applies accuracy rules that stop duplicated findings, capped totals and stale scans from turning into wrong numbers. This post walks through the four layouts, the templates and the rules, step by step.

Key takeaways

• Pick the audience before you pick the numbers. An engineer needs component, current version and target version. An AppSec lead needs a ranked list with reachability and blast radius. An executive needs a trend, the top three risks and one number. An auditor needs scan dates, scope and policy status.
• The Safeguard MCP server (GA) and the Claude connector directory listing (a community connector) let Claude read your Safeguard data. A new workspace starts with a small read-only tool set, and an administrator turns on more, one tool at a time.
• The companion skills for the connector, including the reporting skill, are treated in this post as early access. They are published alongside the connector, not listed in Safeguard's offering catalogue yet, so the stricter label applies.
• The accuracy rules matter more than the formatting. Findings are duplicated by design (one row per vulnerability, per component occurrence, per policy gate), severity buckets and platform totals do not always reconcile, totals cap at 10,000, and a DAST project's risk fields mean something different from a repository's.
• In the app, the ESSCM Dashboard (GA), bulk data export in formats such as CSV, Excel, PDF, HTML, JSON and Markdown (GA), and scheduled tasks (GA) cover the reports you circulate on a schedule.
• Vulnerability management with EPSS and CISA KEV (GA) and reachability analysis (GA) are what make a ranked list worth reading. DAST (early access) results report differently and belong in their own table.
• Autonomous remediation (GA) ships switched off, with every category set to Manual. A report can point at it; it cannot turn it on.

Why one scan needs four reports

Most security reporting fails in one of two ways: the raw export goes to everyone and nobody reads it, or one summary is written for the loudest stakeholder and everyone else works around it. The data is rarely the problem. A composition scan already knows which components you ship, which vulnerabilities affect them, which are reachable, which are exploited and which have a fix. Each reader has a different decision to make with that data, and a report that does not serve the decision does not get used.

What the standards ask a report to do

Several primary sources describe what security reporting is for, and none of them say "list every finding".

The NIST Cybersecurity Framework 2.0 puts reporting inside governance. Its Oversight category says results of organisation-wide cybersecurity risk management activities and performance are used to inform, improve and adjust the risk management strategy. GV.OV-03 asks that organisational cybersecurity risk management performance be evaluated and reviewed for adjustments. GV.RR-01 says organisational leadership is responsible and accountable for cybersecurity risk. Those two outcomes describe the executive report: leadership cannot be accountable for something it never sees in a form it can act on.

The same framework covers the working level. ID.RA-01 asks that vulnerabilities in assets are identified, validated and recorded. ID.RA-06 asks that risk responses are chosen, prioritised, planned, tracked and communicated. "Communicated" is the reporting step, and "prioritised" is the AppSec lead's ranked list.

NIST SP 800-55 Volume 1, the Measurement Guide for Information Security published in December 2024, is about choosing measures that show whether in-place policies, procedures and controls are adequate. Its point for reporting is selection: a measure earns a place because it informs a decision, not because the tool can compute it. A board pack with forty charts fails that test as surely as a one-line "all green".

NIST SP 800-218, the Secure Software Development Framework, frames the whole exercise as mitigating the risk of software vulnerabilities. Risk is the operative word. A report that counts vulnerabilities without saying which ones carry risk in your code has measured activity, not risk.

What the scores actually mean

Most reporting mistakes begin with a score shown to the wrong reader.

CVSS measures severity, not your risk. The CVSS v4.0 specification is explicit that Base metrics are typically what public sources such as the National Vulnerability Database supply, labelled CVSS-B, and that consumers should enrich them with Threat and Environmental metrics as an input to their own risk analysis. A CVSS 9.8 in a component your application never calls is a very different thing from a CVSS 7.5 in a function on your request path.

EPSS is a probability with an awkward shape. FIRST's own guidance explains that EPSS gives both a probability of observed exploitation activity in the next 30 days and a percentile that ranks a vulnerability against all scored vulnerabilities. Because most scores bunch near zero, raw probabilities are hard for people to read. FIRST gives the example that a probability of 0.10 sits at about the 88th percentile, meaning it outranks 88% of scored CVEs. A report that prints "EPSS 0.006" tells most readers nothing. "EPSS 0.6% (46th percentile)" tells them where it stands.

CISA's Known Exploited Vulnerabilities catalog is, in CISA's words, the authoritative source of vulnerabilities that have been exploited in the wild. For US federal civilian agencies, Binding Operational Directive 22-01 (3 November 2021) sets default remediation timelines: within two weeks for KEV entries with CVE IDs assigned in 2021 or later, and within six months for older ones, unless CISA sets a different date. Private companies are not bound by the directive, but many use KEV membership as a hard priority signal, and auditors increasingly ask how KEV items were handled.

Why the reader changes the layout

Put those together and the four audiences fall out naturally.

• The engineer acts on a component and a version. Business impact prose is noise.
• The AppSec lead spends a team's week, so needs a list ordered by reachability, KEV, EPSS and fix availability, grouped by upgrade.
• The executive owns accountability under GV.RR-01, so needs direction, exposure and the one decision being asked.
• The auditor, or a customer's reviewer, needs what was covered, when, by which method, and what the policy said.

One more constraint applies to all four. WCAG 2.2 Success Criterion 1.4.1 says colour must not be the only visual means of conveying information. A severity column that is only red, amber and grey fails a colour-blind reader and a screen reader. Every badge needs its label or number too.

Where the reporting workflow lives in Safeguard

Safeguard gives you two places to produce these reports. They read the same tenant data.

In the Safeguard app. The ESSCM Dashboard (GA) shows projects, components, vulnerabilities, findings, critical counts, the most risky and lowest integrity projects, and remediation time trends. Safeguard's offering lists editable dashboards with a wide range of chart formats and time filters, filtering, sorting and column selection on every table, bulk data export (GA) in formats including CSV, Excel, PDF, HTML, JSON, XML, Markdown, TSV, NDJSON, Parquet and SQL, and scheduled tasks (GA). Safeguard's dashboard docs describe a PDF export of the dashboard and weekly or monthly scheduled email reports. This is where a report you circulate on a calendar belongs.

In Claude, through the Safeguard connector. Safeguard runs a remote MCP server (GA) and is listed in the Claude connector directory as a community connector. Once connected, you ask in plain language ("write this up for my VP", "what do I tell the auditor", "draft tickets for the top three") and Claude reads your Safeguard data. Safeguard also publishes a set of companion skills for the connector. Anthropic's documentation describes skills as task-specific instructions that Claude loads only when they are relevant to the request. The reporting skill is the one that governs presentation.

We label the companion skills early access in this post. They are published by Safeguard with the connector, but Safeguard's offering catalogue does not list them as a capability yet, and the in-app Skills feature is itself early access. The stricter label wins.

The four companion skills

The reporting skill depends on the other three, so it helps to see all four.

The skills attach to an existing Safeguard connection in Claude. You do not call them by name. A request like "summarise our posture for the board" is enough for Claude to load the right one.

What the connector can see by default

Safeguard's Claude integration docs say the server offers a large catalogue of tools, that a new workspace starts with a small read-only set, and that an administrator turns on the rest per tool. The companion skills are written for that read-only starting set: list products, list projects, get one project, list vulnerabilities, get one vulnerability, and list findings for a project or SBOM.

One caveat matters here. Safeguard's own open-issues list notes that the findings tool returns zero results on the Claude connector today. Until that is fixed, build connector reports from projects, the project record and vulnerabilities, and take per-project finding detail from the app's Findings view or an export. If a findings query comes back empty in Claude, that is the known issue, not a clean project.

The connector is read only. It reads data and Claude formats it. The read-only set cannot start a scan, change a finding's status, open a ticket or raise a fix pull request, and nothing in this post shows it doing so. Scope comes from your signed-in session, so a report covers exactly what your role can see.

The data model under every report is short:

Product          a top level offering
  └─ Project     a repo, a scanned URL, an uploaded artifact
       └─ SBOM   one component inventory per scan
            └─ Finding   one vulnerability occurrence, evaluated against a policy gate

A vulnerability sits outside that tree. It is the organisation-wide view of a CVE, and one vulnerability can produce many findings across many projects. Hold on to that sentence, because it is the root of most wrong counts.

The accuracy rules that stop wrong counts

A beautiful report with the wrong number is worse than an ugly one with the right number, because people believe beautiful reports. The base companion skill exists mainly to enforce the rules below, and the reporting skill assumes them. They apply equally to a findings export from the app. Every figure quoted in this section is an illustrative example from the skill's documentation, not a measurement of any customer's data.

Rule 1: findings are duplicated by design, so dedupe before you count

A finding is one row per vulnerability, per component occurrence, per policy gate. The same CVE on the same component version appears once for every gate it is evaluated against, with rows identical except for the gate name, gate stage and evaluation time.

The companion skill's illustrative example: a project can report a finding count of 640 while holding around 39 distinct vulnerabilities. Report 640 to an engineering manager and you have told them they have sixteen times more work than they do.

The dedupe key is the CVE, the component name and the component version together:

source_data_cve_id + component_name + component_version

The output phrase is always "N distinct vulnerabilities across M components". Never "you have N findings" where N is a raw row count. If gate coverage matters to the reader (it does to an auditor), state it separately.

Rule 2: severity buckets and totals do not always reconcile, so say which you used

On one project record, the total vulnerability count and the sum of the critical, high, medium and low buckets can disagree. The skill's illustrative example is a project reporting 39 in total with buckets summing to 20.

• Use the individual severity buckets for any breakdown. They are the more reliable figure.
• When the two disagree and someone is making a decision on the number, show the breakdown and footnote that the platform total differs. Do not silently pick one.
• Two fields with different names carry the same total. Never add them together.

Rule 3: totals cap at 10,000

A total of exactly 10,000 is a ceiling, not a count. Write "10,000+" and explain that the true figure is higher. The skill's illustrative example is a DAST project reporting a total of 10,000 with buckets summing to more than 17,000. The buckets are the accurate breakdown.

Rule 4: fields mean different things per provider

Check how a project was scanned before reading its risk fields.

The trap is real. A DAST project can show a risk level of "Unknown" and a risk score of 0 while carrying hundreds of high severity issues. Read literally, your highest volume assets look like your safest. The rule is simple: never present an unknown risk level or a zero risk score on a DAST project as a security conclusion, and put DAST targets in their own table with no Components column, since a zero there reads as "no dependencies" when it means "not applicable".

Rule 5: freshness goes first

A clean report from a scan three months old is worse than no report, because it will be believed. The skills treat a scan older than about 14 days, or one whose assessment has not completed, as stale, and the reporting skill leads with a staleness note rather than burying it (illustrative dates from the skill):

Note: last scan 12 June 2026, 69 days ago. These numbers may not reflect
current code.

A partial scan is never presented as complete. If assessment progress is under 100%, that project's row says so.

Rule 6: a negative answer must say what was checked

"No findings" can mean the code is clean, the scan type does not produce component findings, or the filter missed. If a status filter returns nothing, retry with all statuses before reporting zero, because stored values and aliases do not always match. Name filters are exact match only, so an empty name lookup is followed by a list and a client-side match. And an empty result means nothing matched in the active scope, not that nothing exists elsewhere.

Rule 7: never show internal identifiers or imply knowledge you do not have

Internal identifiers for the organisation, tenant, product, component, gate, policy, SBOM and individual findings are suppressed unless someone asks. Field name prefixes are serialisation artefacts: a CVSS score is shown as "CVSS". And the component path field is redacted at the API, so a report never claims to know which file a component was found in.

Pick the audience first

The reporting skill's first instruction is to pick the reader, and to ask if it is unclear. The same scan produces four documents.

Most bad security reports are good reports for a different reader.

Step by step: four reports from one session

This walkthrough uses Claude with the Safeguard connector, because that is where the four layouts are applied automatically. The same structure works if you build the reports by hand from the app's dashboards and exports.

1. Connect Safeguard from the Claude connector directory. Open the Safeguard entry in Claude's connector directory and connect. Sign in to Safeguard, check the app name and the host the authorisation code goes to, then choose Authorize access. No URL to paste, no key to copy. The full walkthrough, including Team and Enterprise organisations, is in Safeguard in your IDE and in the Claude and ChatGPT connector directories.

2. Check coverage and freshness first. Ask "Which repositories have not been scanned recently?" The answer leads with how much of the estate is scanned. If Claude does not know your real repository count, it should ask. Rescan stale projects before you produce anything you will circulate.

3. Get the estate overview. Ask "Show me our posture." You get a one-line answer, the scan date range, and one table per provider, sorted by critical, then high.

4. Engineer. Ask "Draft a ticket for the top fix in the payments repo." Claude writes a plain fenced block per component upgrade, built from the project and vulnerability data, for you to paste into your tracker yourself. The connector does not create the ticket.

5. AppSec lead. Ask "What should we fix first across the estate?" The triage skill ranks; the reporting skill renders one row per upgrade, cut at ten.

6. Executive. Ask "Summarise our security posture for the board." You get two or three sentences with no CVE IDs, component names or CVSS, and "point in time" if there is no earlier snapshot.

7. Auditor or customer. Ask "What do I tell the auditor about the payments product?" You get scope, period, exclusions, a dated per-project table and policy status.

8. Save a snapshot. The connector is stateless and cannot compute "new this week" alone. Save this week's overview so next week's digest has a baseline.

9. Move anything recurring into the app. A report that goes out every Monday belongs in a Safeguard dashboard with export and scheduling. Conversation is for drafting and questioning a report; a schedule is for running it.

The four layouts, with copy-ready templates

The reporting skill carries two template libraries. The markdown library is for anything read in the conversation or pasted elsewhere. The visual library renders widgets such as severity badges, posture dashboards and vulnerability cards when the session has a visual renderer. The rule for every template: replace each token with real data, delete any row or line you do not have data for, and never invent a value to fill a gap.

Two layout rules apply everywhere. Markdown tables for reading, fenced code blocks only for copying, because a fenced block does not wrap and turns into a horizontal scroll bar on a phone. And six columns is the ceiling, with numbers right aligned and long identifiers truncated, because chat is narrow and often mobile.

The engineer: a ticket per upgrade

Engineers act on upgrades, so the unit is one component upgrade, not one CVE. The ticket block is plain text in a fenced block, because you paste it into a tracker that may not render markdown. Lines the data cannot fill, such as gate and policy details that today come from the app's Findings view, are deleted rather than guessed.

Title: Upgrade {component} {current} to {fix version}

Clears {n} vulnerabilities:
  {CVE-1}  {severity}  CVSS {score}  {reachable/not reachable}
  {CVE-2}  {severity}  CVSS {score}  {reachable/not reachable}

Component: {name} {version}
Dependency: {direct/transitive, depth N}
Blast radius: {m} projects, {k} occurrences
Policy: {policy name} ({action}), open {n} days

Action: bump to {fix version} and run the test suite.

When an engineer asks about one vulnerability rather than one upgrade, the vulnerability card is the right shape. It starts with a facts strip, a single line separated by middle dots that carries five or six attributes without a table (the values below are the skill's illustrative example):

High · CVSS 7.5 · EPSS 0.6% (46th) · Reachable · Fix available

Then the card says which component and version it affects, across how many projects, whether a fix exists, two or three sentences on what the flaw is and what an attacker gets, and one sentence on why it matters in this tenant. The full advisory description is never pasted. Some run to several thousand words. Summarise, then offer the detail.

What the engineer's version leaves out is as deliberate as what it includes: no business impact prose and no risk scores. The engineer is not deciding whether to fix it. Someone already did.

The AppSec lead: a ranked fix list and a blast radius answer

The ranked fix list is the reporting skill's default deliverable, and it is the one that saves the most time.

**{n} upgrades clear {m} vulnerabilities**

| # | Component | Upgrade to | Clears | Reachable | Also in |
|--:|---|---|--:|---|--:|
| 1 | {name} {version} | {fix version} | {n} CVEs | Yes | {k} projects |

Three choices in that template are worth copying even if you never use Safeguard.

• One row per upgrade, never per CVE. Ten CVEs in one library are one pull request.
• Reachable and Also in are columns, CVSS is not. Whether the vulnerable code is called, and how many projects one change fixes, decide where the week goes. Reachability analysis (GA) in Safeguard ranks the paths your code actually calls; how to prioritise with reachability, EPSS and KEV explains the signals in depth.
• Cut at ten. A list nobody finishes is not a plan. Say how many sit below the line.

When the reasoning matters more than density, the list form replaces the table:

**1. {component} {current} to {fix version}**
Clears {n} CVEs, {k} of them reachable. Direct dependency.
Present in {m} other projects.

**2. {component} {current} to {fix version}**
Clears {n} CVE. Not reachable, so this can wait for the next dependency sweep.

The second entry is the useful one: a report that says what can wait is doing real work.

The AppSec lead also gets the blast radius question: "is this CVE anywhere in our estate?" The yes answer leads with the count, then the component, version, total occurrences and fix version, then a table of projects with occurrences and reachability, then the line that matters: one upgrade to the fixed version clears all of them. The no answer is one line that states what was checked and as of when, so the negative can be trusted:

**No. {CVE} does not appear in any of your {n} scanned projects.**
Checked against the full vulnerability index as of {date}.

"Scanned projects" is doing honest work there. It is not "your estate".

The executive: one number, its direction, and the action

The executive summary has the strictest rules of the four: no CVE IDs, no component names, no CVSS.

Across {n} scanned projects there {is/are} **{c} critical and {h} high severity
{issue/issues}** open. {The critical is/The criticals are} in {direct dependencies
with fixes available / X}, scheduled {timeframe}. {One sentence on the largest
concentration of risk and who owns it.}

{One sentence on coverage: what fraction of the estate this represents.}

Read it against CSF 2.0's oversight outcomes. It tells leadership the exposure, the plan, who is accountable, and how much of the estate the statement covers. The last sentence is the one most executive summaries leave out, and it is the one an incident investigation asks about later.

Two rules protect the executive version from overstating. If there is no prior snapshot, it says "point in time" and does not imply a trend. And because it is written in prose, a single severity colour or icon is the most decoration it gets. No emoji, ever, in executive or auditor output.

If the board wants a chart, the skill's guidance is narrow: a chart earns its place for severity distribution across a portfolio of 20 or more projects, or open counts over time. It never earns it for four numbers. For a recurring board pack, the Safeguard Dashboard's trend charts and PDF export are the better source than a chart drawn in chat.

The auditor or customer: every claim dated and scoped

Audit evidence is the layout where accuracy rules turn into format rules.

**Scope**: {n} projects, scanned {method}, covering {what}
**Period**: {start} to {end}
**Excluded**: {anything omitted, and why}

| Project | Method | Last scan | Status | Critical | High |
|---|---|---|---|--:|--:|
| {name} | {provider} | {date} | {complete/partial} | {c} | {h} |

**Policy status**
{gate and policy names with their action and current pass/fail}

Every row has a date and a method. Exclusions are stated, not implied. A partial scan says "partial". Policy status names the gate, its action and whether it currently passes, which is what an auditor checking "do you enforce your own standard?" needs to see. The visual library is explicit that audit tables stay as markdown rather than widgets, because they get pasted into documents.

The same layout works for a customer's security reviewer, with two cautions. First, a customer usually wants a statement about the product they buy, so scope it to that product, not your whole estate. Second, if the honest answer for a specific CVE is "present but not exploitable in our product", the right artefact is a VEX statement, not a sentence in a report; see ingesting and sharing VEX and CSAF in Safeguard. CSAF and VEX upload is GA. For a standing public page rather than a one-off report, Safeguard's Trust Center is early access.

If the auditor's question is about controls rather than vulnerabilities, the compliance and GRC suite (GA) is the right source: frameworks, controls, evidence and tests are covered in continuous compliance in Safeguard. The reporting layout here is for the vulnerability and scan coverage part of the evidence.

Coverage: the number dashboards hide

Coverage gets its own template because it is the question most posture reports dodge.

**{n} of {m} known repositories are scanned ({pct}%).**

| Status | Projects |
|---|--:|
| Scanned in last 14 days | {n} |
| Stale (over 14 days) | {n} |
| Scan incomplete | {n} |
| Never scanned | {n} |

If there are fewer than about ten stale or never-scanned projects, the report names them. And if the true repository count is unknown, the skill asks for it. A coverage report that silently divides by the scanned set will always say 100%.

The weekly digest

The digest is short: new critical, new high, closed and scans gone stale for the week, then "needs a decision" items, then the top three from the ranked fix list, one line each. Its honesty rule is the important part. The connector cannot compute a week-on-week delta. Either there is a saved snapshot from last week, or the "this week" column says it is unavailable.

Numbers and styling rules

The reporting skill's number rules are short and worth adopting wholesale.

• Thousands separators on anything above 999.
• A total of exactly 10,000 is written "10,000+".
• When severity buckets and the platform total disagree, show the buckets and footnote the difference.
• CVSS rounded to one decimal.
• EPSS as a percentage with its percentile alongside, because the raw probability is meaningless to most readers. That follows FIRST's own advice on probabilities and percentiles.
• Deduplicated counts only: "47 distinct vulnerabilities across 12 components", never a raw finding row count.

Severity is ordered critical, high, medium, low, always in that direction, and styled once. In the visual library critical is red, high is coral, medium is amber, and low is neutral grey. Low is never green, because green reads as resolved or safe, and a low severity finding is neither. Colour never carries meaning alone: every badge shows its label or count, which is what WCAG 2.2 SC 1.4.1 asks for.

The visual widgets deliberately avoid Safeguard's brand colours and use the host's own colour variables, so a posture card looks like part of your conversation in light and dark mode. They open with a screen reader summary, keep caveats outside the graphic (a staleness warning inside a chart is one nobody reads), and cap at about eight rows. Widgets suit a posture overview, a single vulnerability or a fix queue; tickets, audit tables and anything over about twelve rows stay as markdown. Without a visual renderer, the skill falls back to markdown.

On a fix queue, signal chips carry the data that matters: reachable, in KEV, fix available or no fix, direct dependency, blast radius, age, and whether a policy blocks the build. Only the KEV chip is tinted. Two levels of emphasis, or emphasis stops meaning anything.

Empty, partial and error states

These are most of what goes wrong in practice, and the reporting skill has a short template for each. "No findings" names the scan date and whether that scan type produces component findings at all. "Project not found" says name filters are exact match and offers the closest names. Capped counts say the true figure is higher. Stale data leads with the date. Suspected test or demo projects are excluded from totals by name, with an offer to include them, never dropped silently.

In the Safeguard app: dashboards, exports and schedules

Conversation is where a report gets drafted, questioned and tailored. The app is where it gets standardised and repeated.

The ESSCM Dashboard (GA) is the in-app view of the same data. Safeguard's dashboard docs describe a security score, a vulnerability summary with severity breakdown and trend, a top risks list, trend charts including mean time to remediation, a fix rate view, and a project table with last scan date, critical and high counts, score and compliance status.

To match the four layouts in the app:

1. Engineer. Use a project's Vulnerabilities and Findings tabs, filtered to the project and sorted by severity, and export the filtered table. Findings in the app carry a status of open, resolved or mitigated.
2. AppSec lead. Start from the dashboard's top risks, which the docs say include critical vulnerabilities in production and actively exploited CVEs, then use the project table to see which projects carry them. Filter and sort the tables to the reporting scope and export as CSV or Excel for the planning meeting.
3. Executive. Use the trend charts and the vulnerability summary, set the time filter to the reporting period, and export the dashboard as PDF.
4. Auditor or customer. Export the project table with last scan dates and status for the audit period, and pair it with policy and gate results. For control evidence, use the compliance suite.

For anything recurring, Safeguard's docs describe weekly or monthly scheduled email reports from the dashboard, and the offering lists scheduled tasks as GA. Exports respect roles: you can only export what your role can see.

One caution from the docs themselves. Safeguard's analytics docs page shows /v1 REST endpoints for querying metrics, and carries a banner that those endpoints are not yet available. Do not build a reporting pipeline on them today. Use the in-app exports, the CLI, or the connector.

Which report, which surface: a decision table

What Safeguard does not do

Be clear about the limits before you rely on any of this.

• The default connector tools are read only. With the starting tool set, Claude cannot start a scan, change a finding's status, open a ticket or raise a fix pull request. Those actions happen in the Safeguard app, the CLI and CI, or through tools an administrator chooses to turn on. A report produced in Claude describes the state of your tenant; it does not change it.
• The connector is stateless. It cannot tell you what changed since last week unless you saved last week's snapshot. A digest without a baseline says so rather than estimating a delta.
• It cannot see what you have not scanned. Coverage is only as complete as the repositories, images and targets connected to Safeguard. If you do not supply your true repository count, no report can tell you what fraction of the estate is covered.
• It does not know which file a component came from. The component path field is redacted at the API. Reports must not imply file level knowledge.
• It does not write your risk narrative or make your risk decisions. The executive template leaves a slot for "who owns it" and "scheduled timeframe" because only your organisation knows those. A report that fills them with plausible guesses is wrong.
• A report is not an audit opinion. The audit evidence layout organises dated, scoped facts for an auditor. It does not attest to anything, and it says nothing about Safeguard's own certifications.
• The companion skills are early access. Treat their templates as a strong default you review, not a finished deliverable you send unread.
• The /v1 metrics API shown in the analytics docs is not available yet. Use exports, the CLI or the connector.

Common mistakes

Counting finding rows. The most common error by far. A finding is a vulnerability times an occurrence times a gate. Dedupe by CVE, component and version, and report distinct vulnerabilities across components.

Reading a DAST project's "Unknown" risk level as low risk. That provider does not populate the field. Use the severity buckets.

Reporting 10,000 as a count. It is a cap. Write 10,000+.

Sending one report to everyone. The executive gets CVE IDs they cannot use, the engineer gets risk prose they will not read, and the auditor gets a document with no dates. Pick the audience first.

Listing CVEs instead of upgrades. A per-CVE list makes ten findings in one library look like ten pieces of work. Group by the upgrade that clears them.

Burying staleness. A footnote that the scan is 69 days old does not undo the headline above it. Put the date first.

Implying a trend from one snapshot. "Critical count is 3" is a point in time. "Down from 7" needs last week's number, saved.

Calling a scanned subset "the estate". "No critical vulnerabilities in our estate" is a claim about every repository you have. "None in our 41 scanned projects, out of 60 known" is a claim you can defend.

Colour as the only signal. A red cell with no label fails WCAG 2.2 SC 1.4.1.

FAQ

How do I make a security report for executives from vulnerability scan data?

Lead with one number and its direction, the top concentration of risk and who owns it, and what fraction of your estate the number covers. Leave out CVE IDs, component names and CVSS scores. If you have no earlier snapshot, say "point in time" instead of implying a trend. The Safeguard reporting template for executives follows exactly that shape.

What should a vulnerability report for auditors include?

Scope (which projects, scanned how, covering what), the period, anything excluded and why, a per-project table with method, last scan date and whether the scan completed, critical and high counts, and the current pass or fail status of each policy gate. Every claim should carry a date and a source. Never present a partial scan as complete.

Why does my findings count not match my vulnerability count?

Because a finding is one row per vulnerability, per component occurrence, per policy gate. The same CVE on the same component appears once for each gate that evaluates it. Deduplicate on CVE, component name and component version, and report distinct vulnerabilities across components.

Can Claude generate security reports from Safeguard?

Yes. Connect Safeguard from the Claude connector directory, and Claude can read your projects and vulnerabilities and present them in a layout for the reader you name. Safeguard's companion skills (early access) supply the templates and accuracy rules. The connector is read only: it reads scans that already exist and Claude formats them. It does not start scans or create tickets, and per-project findings currently come from the app, because Safeguard notes the findings tool returns zero on the Claude connector today.

How should I show EPSS in a report?

As a percentage with its percentile alongside, for example "EPSS 0.6% (46th percentile)". FIRST, which maintains EPSS, notes that raw probabilities are hard for people to interpret because most values bunch near zero, and that the percentile shows where a score ranks against all scored vulnerabilities.

Is CVSS a good measure of risk for a board report?

No. The CVSS v4.0 specification treats the Base score as an input to the consumer's own risk analysis, enriched with threat and environmental context. Boards need exposure and direction. Keep CVSS for engineers and AppSec, and use reachability, KEV status and fix availability to decide what reaches the executive summary.

Can I schedule Safeguard reports?

Yes, in the Safeguard app. The dashboard docs describe PDF export and weekly or monthly scheduled email reports, and the offering lists scheduled tasks and bulk data export as GA. Conversations in Claude are better for drafting and tailoring a report than for running it on a schedule.

Does a Safeguard report prove we are compliant with a framework?

No. A report organises dated, scoped facts. Compliance is an assessment against a framework's controls, made by you and your auditor. Safeguard's compliance suite (GA) maps evidence to controls, but neither it nor a report replaces the assessment.

A ranked fix list is only as useful as the fixes behind it, and the hardest row in any report is the one that says "no fix available". These three routes are how teams turn that row, and the rest of the list, into merged changes.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo shows the connection step this whole workflow depends on: connecting Claude to the Safeguard MCP server with OAuth and choosing which tools Claude can use. Once that connection exists, every report in this post is a plain language request in the same conversation.

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

The second demo is a real CLI session: ask the interactive terminal to fix the lodash CVE in a repo, and it reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, and pushes nothing. That is the engineer's ticket block carried through to a tested change.

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

The third demo sets up the local runner on your own machine, approves it with its device code, then scans from the terminal. Fresh scans keep every report above clear of its own staleness warning. More in choosing between a repo connection, the CLI and the local runner.

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

To try this on your own projects, download Safeguard and follow the setup guides in the Safeguard docs. For a map of everything else Safeguard does, with each capability's maturity label, see what Safeguard does today.

Quick check

Sources

• NIST CSWP 29, The NIST Cybersecurity Framework (CSF) 2.0
• NIST SP 800-55 Vol. 1, Measurement Guide for Information Security
• NIST SP 800-218, Secure Software Development Framework
• FIRST, CVSS v4.0 Specification Document
• FIRST, EPSS: Probability, Percentiles, and Binning
• FIRST, EPSS FAQ
• CISA, Known Exploited Vulnerabilities Catalog
• CISA, BOD 22-01: Reducing the Significant Risk of Known Exploited Vulnerabilities
• W3C, Understanding WCAG 2.2 Success Criterion 1.4.1: Use of Color
• Anthropic, Agent Skills overview
• Anthropic Help Center, What are skills?
• Anthropic, Claude Code plugins overview
• Safeguard docs, Claude integration
• Safeguard docs, ESSCM Dashboard
• Safeguard docs, ESSCM Findings
• Safeguard docs, Analytics and dashboards
• Safeguard MCP directory
• Safeguard Gold Open Source

Last reviewed: 24 October 2026. Product capabilities change; check docs.safeguard.sh for the current state.