Safeguard dashboards for the CISO and the board: what to watch

A CISO should watch one page every week and send the board a short pack every month. In Safeguard that page is the Program Overview dashboard, and the two signals that matter most on it are known exploited vulnerabilities (KEV) open in production and time to remediate. Scheduled reports deliver both without asking engineers for numbers.

Key takeaways

• Safeguard's Analytics surface lives at Home → Dashboards and serves three audiences: engineers triaging their own findings, security leads running the program, and executives who want a single number they can share with the board.
• Six built-in dashboards each answer one leadership question: Program Overview, Vulnerability Backlog, Supply Chain Coverage, Compliance, Zero-Days and Incidents, and Costs.
• The most important tile is KEV-listed findings in production. Safeguard's docs say it should read zero.
• Read time to remediate by severity and environment, next to the exceptions list, or a quiet backlog can look like a fast one.
• Scheduled reports send a daily digest, a Monday executive summary and a monthly board pack, each as a PDF with charts plus a structured JSON payload.
• Exports respect role-based access control, time-travel shows your posture on any past date in the retention window, and every UI metric can flow to your own stack over OpenTelemetry.

What a CISO actually needs from a dashboard

Most security dashboards are built by people who triage findings, so they open on findings. A CISO's weekly question is different: is the program getting better or worse, where is it stuck, and what decision needs to be made? The monthly question is what to tell the people who oversee risk.

Public guidance points the same way. NIST's Cybersecurity Framework 2.0, published on 26 February 2024, describes itself as a taxonomy of outcomes that helps an organization "understand, assess, prioritize, and communicate" its cybersecurity efforts, and it added a GOVERN function. CISA's Cross-Sector Cybersecurity Performance Goals 2.0 mirror that with their own GOVERN function on leadership accountability, oversight and risk management. Neither tells you which chart to draw. Both say security now has an audience above the security team.

NIST SP 800-40 Rev. 4 (April 2022) names the gap a dashboard has to close: there is often "a divide between business/mission owners and security/technology management about the value of patching". NIST SP 800-55 Volume 1 (December 2024) is the reference for choosing measures that show whether policies, procedures and controls are adequate. The practical lesson is that a measure earns its place by supporting a decision. A tile nobody acts on is decoration.

For US public companies, Item 106 of SEC Regulation S-K asks registrants to describe the board's oversight of cybersecurity risk, "the processes by which the board or such committee is informed about such risks", and the processes by which management monitors the prevention, detection, mitigation and remediation of incidents. This is general information, not legal advice, and a dashboard is not a disclosure. But a written, repeatable reporting cadence is one practical way to show that such a process exists and runs.

So a CISO dashboard has to answer program questions rather than ticket questions, support real decisions, arrive on a schedule without a request to engineering, show the past as well as the present, and let every number be traced to the records underneath.

Where the dashboards live and who they are for

The Analytics surface lives at Home → Dashboards. The docs name three audiences: engineers triaging their own findings, security leads running the program, and executives who want a single number to share with the board. Use that split for every tile you add. A tile that serves one audience belongs on that audience's view only.

Inside ESSCM, Safeguard's software supply chain product, there is also an organization dashboard with a security score, vulnerability summary, top risks, trend charts, a project table and alerts. Both are covered below.

Two platform behaviours matter before any tile. Every number on every dashboard is clickable and drills through to the underlying search results, so when a board member asks "which systems are those", the answer is one click away. And dashboards are editable: you can rearrange widgets, pick new chart types and apply time filters. Drill-through makes a number trustworthy; editing lets one dataset serve three audiences.

Every number on these pages is a count of something, so it helps to know whether you are counting CVEs, findings or affected projects. The post on how Safeguard data is structured and how to count vulnerabilities correctly covers that.

The built-in dashboards, one CISO question each

Program Overview

This is the page a CISO opens every Monday. It holds the headline indicators:

• Total assets, SBOM coverage and ownership coverage. These tell you whether the rest of the page can be trusted. SBOM coverage measures how much of your inventory has a current bill of materials; ownership coverage measures how much has a named owner. A clean KEV tile on a fleet you only partly see is not good news.
• Open critical and high findings by environment. Splitting by environment keeps a noisy sandbox from hiding a production problem.
• KEV-listed findings in production. Findings in production whose CVE is on CISA's Known Exploited Vulnerabilities catalog. The docs say this should be zero.
• Time to remediate over rolling windows. A short window and a longer, quarter-length one. The short window shows this month's behaviour; the long one shows the program.
• Auto-fix activity from Griffin, Safeguard's security model. Pull requests opened, merged and rejected. Rejections are an honest signal of whether engineers trust those pull requests.

Vulnerability Backlog

The head of AppSec's dashboard, and the one a CISO reads when Program Overview moves the wrong way. It shows open findings by severity, priority and reachability, aging buckets from under a week to more than a quarter, the most-affected assets, the packages driving the backlog, and a resolved-versus-new trend.

Resolved versus new is the key line for a leader. A backlog grows for good reasons (more repositories connected, a large advisory) and bad ones (fixes stopped flowing). If resolved tracks new, growth is coming from coverage. If new pulls away while resolved stays flat, the team has fallen behind.

The packages-driving-the-backlog list shows where one upgrade campaign beats a hundred tickets. The post on portfolio sweeps and blast radius shows how to go from that list to every project carrying a component.

Supply Chain Coverage

Every other dashboard depends on this one. It shows connected Git, registry, cloud and model-registry integrations, a shadow asset count with its trend, and vendor SBOM freshness. A rising shadow asset trend means your inventory is growing faster than your ownership process. A stale vendor SBOM is a blind spot with a document attached, which is worse than an honest gap because it looks covered.

Compliance

This shows a readiness score per framework, evidence completeness per control, and exceptions open and expiring. Read what a Safeguard readiness score counts before you put one in front of an audit committee. For a CISO the exceptions tile matters most: expiring exceptions are decisions about to be made again, and exceptions renewed again and again are risks that have quietly become permanent.

Zero-Days and Incidents, and Costs

Zero-Days and Incidents covers the response side: zero-day advisories affecting your environment, the time taken to remediate them, and findings that overlap with active exploitation through KEV. It pairs with time-travel in a post-incident review.

Costs shows inference calls, workflow runs, artifact storage and runner minutes per team and per environment. It answers the question a CISO gets from finance, and per-team breakdowns show where automation does the most work.

The organization dashboard in ESSCM

The ESSCM dashboard gives an overview of the organization's software supply chain posture, and many teams open it first.

Security score. A single organization-wide score on a 0 to 100 scale. The docs list four inputs: vulnerability severity and count, fix rate and remediation speed, policy compliance, and component health. Because fix rate and policy compliance pull against hiding findings, it suits a board. Treat it as a summary, not a target: show it with its trend and the two or three tiles that explain why it moved.

Vulnerability summary and top risks. Totals across all projects, a severity breakdown, a trend and the new vulnerabilities this week. Top risks lists critical vulnerabilities in production, actively exploited CVEs, compliance violations and aging vulnerabilities. That list is a ready agenda for the weekly review: fix it, accept it with an exception, or explain it.

Trend charts. Vulnerability trends show totals by severity and mean time to remediation. Fix rate shows vulnerabilities fixed per week, AI Remediate compared with manual fixes, and time to fix by severity. Component health shows outdated components over time, license compliance trends and new components added. Component health is the leading indicator: today's outdated components are next quarter's vulnerabilities.

Project table. Every project with its last scan (most recent SBOM generation), critical and high counts, project score and compliant or non-compliant status. Sorted by status then score, it is the list of teams to talk to this month. An old last-scan date is a coverage problem, not a clean bill of health.

Alerts and export. Alerts for new critical vulnerabilities, policy violations, SBOM generation failures and score degradation; a formatted PDF export; scheduled weekly or monthly email reports. Score degradation is the alert a CISO should personally receive: it is the earliest sign that a team's posture is slipping between Monday summaries.

Reading KEV exposure in production as a program signal

If a CISO watches one tile, it should be KEV-listed findings in production.

What KEV is

CISA calls its Known Exploited Vulnerabilities catalog "the authoritative source of vulnerabilities that have been exploited in the wild" and says organizations should use it as an input to their prioritization framework. It is published as a web page, CSV and a JSON feed with a schema. Each JSON entry carries the CVE ID, vendor and product, name, date added, short description, required action, due date, known ransomware campaign use, a forensic triage field, notes and CWEs.

Two facts are easy to get wrong. CISA's BOD 26-04 implementation guidance says a KEV addition "does not necessarily indicate" CISA is currently seeing active exploitation; a vulnerability can qualify at any age. And the catalog is built on verified evidence, so it is deliberately conservative. Absence from KEV does not mean safe.

What changed in 2026: BOD 26-04

On 10 June 2026 CISA issued Binding Operational Directive 26-04, Prioritizing Security Updates Based on Risk. It supersedes and revokes BOD 19-02 and BOD 22-01, the 2021 directive that created the KEV catalog. BOD 22-01's fixed deadlines are history; do not plan around them.

BOD 26-04 sets urgency from four variables:

1. Asset exposure. Is the vulnerable asset publicly exposed?
2. KEV status. Is the CVE in the KEV catalog?
3. Exploit automation. Can an adversary automate every step of exploitation?
4. Technical impact. Does exploitation give partial or total control?

CISA publishes KEV status, automatability and technical impact for every CVE ID through its Vulnrichment program, and the directive's Table 1 turns the combination into a timeline. Timelines are dynamic: taking an asset off the internet pushes the deadline back, a new KEV listing pulls it forward, and the most urgent cases require remediation within three days plus a forensic triage to check for compromise.

The directive binds federal civilian executive branch agencies, not private companies, and applies to contractors only through their contracts. But its implementation guidance makes a point any CISO can use: the timelines are maximum durations that represent risk tolerance, and an organization with lower tolerance may set shorter ones. Your own policy can borrow the structure without the federal deadlines.

How to read the tile

Read it in three passes.

Is it empty? The docs set the target plainly: none. Empty, with healthy coverage tiles, is one of the few security statements you can make to a board with a straight face.

If not, how old is each item? Click the number. A KEV finding that appeared yesterday because CISA added the CVE is a response in progress. One open for weeks is a decision nobody has made. Different conversations.

Is each item reachable and exposed? Reachability analysis shows whether your code calls the vulnerable path; environment and asset tags show exposure. A reachable KEV finding on an internet-facing production service is the top of the list by any standard, including BOD 26-04's. An unreachable one in an internal batch job still needs a fix, but your policy may let it wait for the next planned upgrade, with an exception recording the decision.

What a zero does not mean

A zero means no production findings match a KEV-listed CVE in the assets Safeguard can see. It does not mean unseen assets are clean, that vulnerabilities outside KEV are unexploited, that staging and development are clean, or that vendor appliances and hosted services you do not build are patched. Say so in the board pack. A board that hears "zero, within this scope" trusts the number more, not less.

Why the tile moves without a code change

When CISA adds a CVE, every asset carrying the affected component becomes a KEV finding. Safeguard's continuous scanning treats vulnerability feed updates, including KEV additions and EPSS changes, as rescoring triggers. New advisories are matched to components already stored in Safeguard's knowledge graph by package URL, version range and CPE, and only affected assets are rescored. The tile moves when the catalog moves, not when your next build runs. Notifications follow the same data and can route by owner, severity, exploitation status and environment, including on-call paging for critical KEV findings in production.

For clearing a KEV finding across many repositories, read remediate a KEV vulnerability across hundreds of repos.

Reading time to remediate without fooling yourself

Time to remediate appears on Program Overview over rolling windows, as mean time to remediation in the ESSCM vulnerability trends chart, as time to fix by severity in the fix rate chart, and for zero-days on the Zero-Days and Incidents dashboard.

What it measures

It is the time between a finding opening and being resolved. Two parts of that definition hide most of the arguments.

When does the clock start? For a finding, when Safeguard first sees it on an asset. For a KEV finding, a stricter reading starts when the CVE was added to the catalog, which is how BOD 26-04 starts its timelines (KEV listing or the agency identifying the vulnerability on an asset, whichever comes first). Say which clock you mean.

What counts as resolved? An upgrade, a retired asset, a reachability or VEX statement showing it does not apply, or an accepted risk. The first three reduce risk. The last moves it to the exceptions list. Count exceptions as fixes and the number will look excellent right up to the incident.

How to read it

• By severity. Fast fixes on low findings can hide slow fixes on critical ones. That is why time to fix by severity exists.
• By environment. Production is the board's number. A fast development average does not offset a slow production one.
• Short window against long window. A worsening short window with a stable long one means something changed recently. Both drifting means a structural problem.
• Next to the backlog. Falling time to remediate with a growing backlog can mean easy findings close while hard ones age. The oldest aging bucket catches this.
• Next to auto-fix activity. Automated upgrade pull requests should pull routine dependency fixes down. If they do not, look at rejected pull requests: they usually point to failing tests or a review step nobody owns.
• Careful with means. A few very old findings pull a mean hard. Click through before drawing conclusions, and describe the distribution in words in the board pack (most findings closed within policy, a small set of long-running items with named owners) rather than a figure one outlier can swing.

Tie it to a written policy

A time-to-remediate chart means little without a target, and a target means little without a policy. Write your own table (exposure, KEV status, automatability, technical impact), get it approved, then hold it with Safeguard policies and gates. Policies evaluate SBOMs and generate findings; gates block deployments when a policy fails. Each policy's action is Block (the gate fails), Warn (passes with a warning naming the policy) or Notify (passes and sends a notification). Exceptions carry a business justification, an expiration date, an approver and an audit trail. Then the chart stops being a number and becomes evidence that a policy is followed, which is a much stronger thing to show an audit committee.

EPSS, CVSS and reachability: supporting signals, not headline tiles

Three more signals belong one level down, where the AppSec lead orders the work.

EPSS. FIRST's Exploit Prediction Scoring System is a data-driven model that estimates the probability a published CVE will be exploited in the wild in the next 30 days, published daily for every CVE as a score between 0 and 1 with percentiles. EPSS is a forecast; KEV is a record. A high EPSS score on a CVE not yet in KEV is an early warning.

CVSS. The Common Vulnerability Scoring System, now at version 4.0 and maintained by FIRST, separates a Base score (CVSS-B) from scores that add Threat and Environmental metrics (CVSS-BT, CVSS-BE, CVSS-BTE). A Base score describes the vulnerability, not your exposure, and BOD 26-04 compares its own technical impact factor to CVSS's idea of severity.

Reachability. Safeguard combines reachability with EPSS, KEV and runtime and business context into one priority. How much noise it removes depends on the codebase and should be measured during evaluation.

Keep them off the board slide. Each is a ranking input, and boards do not rank findings. The board wants to know whether exploited vulnerabilities in production close within an agreed time.

Custom dashboards and team-scoped views

Two ways to build

The docs describe the Dashboard Builder (drag and drop) and a YAML definition. Use YAML for anything a leader relies on: the docs note dashboards can live in Git next to your policies, recommended for auditability. A dashboard in Git has a history, a reviewer and a diff. This is the format the docs show, scoped to one team:

apiVersion: safeguard.sh/v1
kind: Dashboard
metadata:
  name: payments-team-weekly
spec:
  filters:
    team: payments
    environment: ["production", "staging"]
  widgets:
    - type: metric
      title: "KEV findings open"
      query: "findings.severity >= high AND findings.kev == true"
      compare: "7 days ago"
    - type: timeseries
      title: "New findings / day"
      query: "count(findings) by day WHERE findings.created_at > '30d'"
    - type: table
      title: "Top priorities"
      query: "findings ORDER BY priority DESC LIMIT 10"

The filters block scopes every widget to one team, so the file can be copied per team with one line changed. The compare field shows movement against a week earlier. The table lists the work, not only a count, so a team lead knows what to do next. Check the query fields your tenant exposes on the Analytics and Dashboards page before committing.

Scoping by role, team and label

Safeguard's hierarchy runs Organization → Team → Project → Asset. Roles are scoped to a team or the whole organization, and a user can hold different roles in different teams. The built-in roles map onto dashboard audiences:

Permissions can also be sliced by asset labels, for example a role limited to assets labelled team: payments in production and staging. A business unit leader can then have a view of exactly their estate without a spreadsheet or a separate tenant. For boards, which think in product lines rather than repositories, Safeguard's Products group several projects so you see combined risk across a release train or business unit.

Scheduled reports and executive packs

A dashboard nobody opens does not exist. Scheduled reports, driven by any dashboard, send the right view to the right person:

Reports ship as a PDF with embedded charts plus a structured JSON payload for your own reporting tools, so the numbers in board slides and in your risk register come from the same file. The post on scheduled reports, recurring scans and checks covers scheduling in more depth, and one dataset, four audiences covers what each audience's report should contain.

Executive packs

Executive packs are one-click PDFs for board or audit use, built from templates you can customize in your tenant's report configuration:

• Security Posture Executive Summary. A short high-level summary, the natural core of a quarterly board update.
• Compliance Evidence Pack. A per-framework evidence bundle for auditors.
• Incident Retrospective. Timeline, contributing factors and remediations for any resolved incident.
• Vendor Risk Report. A per-vendor summary for procurement.

Match your board's format in the template once, then generate it every quarter. If the CTO also owns compliance, see a security report for a fintech board.

What goes in the board pack

1. One line of status. The security score and its direction over the quarter, in words.
2. Exploited vulnerabilities in production. The KEV tile, scope stated, open items named with owner and expected date.
3. Speed. Time to remediate for critical and high production findings, described as within or outside policy.
4. Coverage. SBOM and ownership coverage, with the plan for any gap.
5. Accepted risk. Open and expiring exceptions, and repeat renewals.
6. Decisions requested. Budget, headcount, a policy change or an exception only the board can approve.

Leave out raw counts without context, per-scanner breakdowns and CVSS distributions. They belong in the AppSec review.

Exports and RBAC

Every dashboard and finding list can be exported: CSV, TSV, Excel, JSON and NDJSON for data; CycloneDX and SPDX for components; OSCAL for compliance evidence; PDF for formal reporting. The rule that matters: exports respect RBAC, so a person can only export what their role can see.

• A Viewer scoped to one business unit exports only that business unit.
• An Auditor exports audit records, findings and compliance evidence, read-only, so an audit request becomes a role assignment rather than a data pull by your team.
• Every action is recorded in Safeguard's audit log (who, what, when, where and, when given, why). The log is append-only and cryptographically chained, and can stream to your SIEM by webhook, scheduled batch export or OpenTelemetry logs.

When board material goes to an outside party such as counsel or an insurer, export from a scoped role rather than an admin account.

Time-travel: posture on the day of an incident

After an incident the question is "what did we know, and when". Safeguard's dashboards support time-travel: pick a date within the last two years and see the state of your fleet then. The docs name three uses: post-incident analysis (what did our posture look like the day of the incident?), program retrospectives, and demonstrating improvement to stakeholders.

Time-travel pairs with each asset's scan timeline, which records when each scan ran, what triggered it, and the diff from the previous scan (added, resolved, severity changed). Together they reconstruct when a finding entered the system and when it left, which supports the kind of monitoring process Item 106 asks registrants to describe. A good habit: after every incident review, generate the Incident Retrospective pack and save the Program Overview time-travel view for the incident date with it.

Metrics over OpenTelemetry into your own stack

Leadership already reads your service health dashboards. Safeguard can put the security program in the same place. The docs state that Safeguard exports every UI metric as OpenTelemetry metrics to your own OTLP endpoint, configured under Settings → Telemetry:

A gauge is a current value; a counter only rises, so you watch its rate. The method label on resolved findings lets you separate real fixes from other ways a finding closes, the time-to-remediate trap above.

OpenTelemetry's docs define a metric as a measurement of a service captured at runtime, together with the time it was captured. The OpenTelemetry Protocol (OTLP) defines the encoding and transport of telemetry over gRPC and HTTP. A backend that speaks OTLP can receive the data directly; otherwise an OpenTelemetry Collector can receive it and forward it on. A Collector configuration has receivers, processors, exporters and connectors, each enabled in a pipeline under service. A minimal receiving Collector that forwards metrics to an internal backend:

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318

exporters:
  otlp_grpc:
    endpoint: metrics-backend.internal:4317
    sending_queue:
      batch:

service:
  pipelines:
    metrics:
      receivers: [otlp]
      exporters: [otlp_grpc]

The OpenTelemetry docs use 0.0.0.0 in examples for convenience and note the Collector defaults to localhost. An endpoint receiving data from Safeguard must be reachable from it, so put it behind TLS and your edge authentication, and check Settings → Telemetry for the options your tenant offers. Validate the file with otelcol validate --config=<file> before deploying.

The payoff: engineering leadership sees security next to uptime without a new login, your existing alert rules can page on a rise in open critical production findings, and retention follows your own platform's rules.

What to show the board versus what to watch weekly

A first 30 days setup

This plan takes a CISO from a new tenant to a Monday summary and a first board pack in about a month.

Week 1: connect the sources

1. Connect every Git organization you own. A partial inventory makes every later number misleading.
2. Connect container registries and cloud accounts. Without them "in production" has no meaning.
3. Connect model registries if you ship AI; models appear on Supply Chain Coverage.
4. Request or upload vendor SBOMs, starting with the vendors your board has heard of.
5. Done when every expected source shows on Supply Chain Coverage and the shadow asset list has been reviewed once.

Week 2: name ownership and tag environments

1. Create teams that match your org chart, and assign projects to them using CODEOWNERS and container labels where they exist.
2. Tag environments: production, staging and development at minimum. The KEV and time-to-remediate tiles only mean something per environment.
3. Assign roles: Security Lead for the CISO and AppSec lead, Developer for engineering, Auditor for internal audit, Viewer for executives.
4. Done when the remaining ownership gaps on Program Overview can be named in one sentence.

Week 3: pick five tiles and write the policy behind them

1. Pick five tiles for the CISO view. A good default: KEV-listed findings in production; time to remediate for critical and high production findings; SBOM coverage; ownership coverage; open and expiring exceptions.
2. Write the remediation policy using BOD 26-04's four factors and your own maximum timelines, and get it approved by whoever owns risk.
3. Encode it as Safeguard policies and gates: Block for what the policy will not tolerate, Warn or Notify for the rest, expiry dates on every exception.
4. Define team dashboards as YAML in Git next to the policies.
5. Route alerts: critical KEV findings in production to on-call, the rest to team channels and daily digests.

Week 4: schedule the cadence

1. Schedule the daily digest for security engineers and the on-call lead.
2. Schedule the Monday executive summary for the CISO and engineering leadership.
3. Schedule the monthly board pack and tailor the Security Posture Executive Summary template to your board's format.
4. If you run an observability platform, point Settings → Telemetry at your OTLP endpoint and add an alert on open critical production findings.
5. Record today as the program baseline date, so the first time-travel retrospective has a starting point.

By the end of week 4 the CISO has a Monday email, a monthly pack and a live page, and nobody has built a spreadsheet.

Honest limits

• Coverage bounds every number. Safeguard reports on the assets it can see. Unconnected assets, vendor appliances, hosted services and operating system runtimes you do not build sit outside the numbers, and their fixes come from their vendors.
• A score is a summary. Use the security score for trend and a one-line status, never as a substitute for the tiles that explain it.
• Readiness is not certification. A readiness score is not an auditor's opinion. Safeguard is SOC 2 Type II compliant, and its architecture is designed for FedRAMP High without a FedRAMP authorization today.

Common mistakes

Putting raw finding counts on the board slide. Counts rise when coverage improves, which punishes the team for doing the right thing. Show KEV exposure, time to remediate against policy and coverage.

Reading a KEV zero without coverage. A zero on a partial inventory is a guess.

Counting exceptions as fixes. Watch the method label on resolved findings and the exceptions tile together.

Trusting a mean without looking at the tail. Click through to the oldest items first.

Mixing environments. Split every leadership tile by environment.

Treating KEV absence as safety. KEV is conservative. Use EPSS and reachability to see what is not on it yet.

Planning around revoked deadlines. BOD 22-01 was revoked on 10 June 2026. Policies quoting its fixed deadlines need updating to BOD 26-04's model.

Hand-building every team's view. Define dashboards as YAML in Git and copy per team.

Letting exports bypass roles. Give auditors and business unit leaders scoped roles so their exports are scoped too.

FAQ

What should a CISO show the board about application security?

Exploited vulnerabilities open in production (KEV-listed findings), time to remediate critical and high production findings against your written policy, SBOM and ownership coverage, open and expiring exceptions, and the decisions you need. Program Overview and the monthly board pack cover all of these.

What does the KEV-listed findings in production tile count?

Findings in production whose CVE is in CISA's Known Exploited Vulnerabilities catalog. Safeguard's docs set the target at zero. Click the number to see each finding, its asset, owner and age.

Does BOD 26-04 apply to private companies?

No. It binds federal civilian executive branch agencies and reaches contractors only through their contracts. Many private organizations borrow its four factors to write their own remediation policy.

Is BOD 22-01 still in force?

No. CISA revoked it on 10 June 2026 when it issued BOD 26-04. The KEV catalog it created continues.

How is time to remediate shown in Safeguard?

Over rolling windows on Program Overview, as mean time to remediation in the ESSCM vulnerability trends chart, and as time to fix by severity in the fix rate chart. Read it by severity and environment, and alongside the exceptions list.

Can I send Safeguard metrics to my observability platform?

Yes. Safeguard exports every UI metric as OpenTelemetry metrics to your OTLP endpoint, configured under Settings → Telemetry.

Can each team see only its own dashboard?

Yes. Roles can be scoped to a team, permissions can be sliced by asset labels, custom dashboards can filter to one team, and exports respect the same boundaries.

Can I see our posture on the day of an incident?

Yes. Time-travel shows the state of your fleet on any date within the last two years. Pair it with the per-asset scan timeline and the Incident Retrospective pack.

How often do scheduled reports run?

The docs describe a daily digest at 09:00 local time, a weekly executive summary on Mondays and a monthly board pack, each as a PDF with charts and a JSON payload.

The dashboards show where exposure sits. Closing it still comes down to the software supply chain: the open source components and container images inside the services those tiles count, which is where most KEV findings in an application estate live.

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, Griffin, Safeguard's security model, opens a policy gated pull request that moves the affected dependency to the safe version, and your own CI runs your tests on it before anyone merges. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. 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. Auto-merge is a separate switch and stays off by default, so your team decides what merges 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.

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

Safeguard Gold rebuilds patched versions of open-source packages and images from source, signs each build, attaches an SBOM, SLSA provenance and VEX, and serves them from registry.safeguard.sh to your organization. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) 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 build of a specific package. 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 dashboards are where a CISO watches the program. These demos show three places the work behind the tiles happens.

The first demo connects Claude to the Safeguard MCP server with OAuth and shows how you choose which tools Claude can use. Between Monday summaries, a security lead can ask an assistant "which production projects have open KEV findings, and who owns them?" instead of building a new view.

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

The second demo is a real Safeguard CLI session. A developer asks the assistant to fix a lodash CVE; it reads the finding and advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, prints a summary and pushes nothing. This is what moves the time-to-remediate tile: an owned finding becoming a tested fix.

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, and scans from the terminal. Teams that will not grant repository access can still feed the coverage tiles this way, because the scan runs where the code lives.

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

To try Safeguard yourself, download the apps or read the CLI docs.

Quick check

Sources

• Safeguard docs: Analytics and Dashboards
• Safeguard docs: ESSCM Dashboard
• Safeguard docs: Continuous Scanning
• Safeguard docs: RBAC, Teams and Organizations
• Safeguard docs: Compliance
• Safeguard docs: Policies and Gates
• CISA: Known Exploited Vulnerabilities Catalog
• CISA: KEV catalog JSON feed
• CISA: BOD 26-04, Prioritizing Security Updates Based on Risk
• CISA: BOD 26-04 Implementation Guidance
• CISA: BOD 22-01 (Revoked)
• CISA: Cross-Sector Cybersecurity Performance Goals
• FIRST: Exploit Prediction Scoring System (EPSS)
• FIRST: EPSS FAQ
• FIRST: CVSS v4.0
• NIST: The NIST Cybersecurity Framework (CSF) 2.0, CSWP 29
• NIST: Cybersecurity Framework
• NIST: SP 800-40 Rev. 4, Guide to Enterprise Patch Management Planning
• NIST: SP 800-55 Vol. 1, Measurement Guide for Information Security
• eCFR: 17 CFR 229.106 (Regulation S-K Item 106), Cybersecurity
• OpenTelemetry: Metrics
• OpenTelemetry: OTLP Specification
• OpenTelemetry: Collector configuration

Last reviewed: 27 October 2026.