Writing the software supply chain page of the bank's board report

A bank CISO's annual board report should give software supply chain risk one page: how much of the bank's software you can see, how many known exploited vulnerabilities are open in it, how fast they get fixed, which risks were accepted and by whom, how the critical vendors' software looks, and what you need the board to decide. Each number needs a written definition that does not change when your tools do, so the board can compare this year with last year.

That is the whole answer. The rest of this post gives you the rule behind the report, a one-page template, the metric definitions, a way to show trend honestly, and the questions directors tend to ask.

Key takeaways

• The Interagency Guidelines Establishing Information Security Standards require a report to the board, or a board committee, at least annually on the status of the information security program, including service provider arrangements, test results, incidents and recommended changes (section III.F).
• The 2023 Interagency Guidance on Third-Party Relationships puts ultimate responsibility for third-party risk oversight on the board and lists periodic reporting to the board as part of good documentation.
• Six metrics fit on one page: inventory coverage, known exploited vulnerability (KEV) exposure, median days to remediate, overdue findings, open exceptions with owners and expiry dates, and critical vendor software risk. A seventh line lists the decisions you are asking for.
• Freeze each definition in writing. Report the median with a high percentile, restate the prior year when scope changes, and show new repositories as their own line.
• Exceptions belong on the page with a named owner, an approval date and an expiry date. An exception without an expiry is a permanent risk acceptance and should be presented as one.
• Safeguard can supply most of the inputs: SBOM generation and analysis (GA), software composition analysis and vulnerability management with EPSS and CISA KEV enrichment (GA), reachability prioritisation (GA), the executive risk dashboard with drill-through and exports (GA), the Compliance and GRC suite's Risks tab (GA) and Third-Party Risk Manager vendor risk scores (GA).
• The narrative, the risk appetite, the materiality call and the board's minutes stay with you and the board.

The situation

The annual information security report is on the board calendar. The audit committee chair has asked, politely, for "one page on third-party and open source software risk" with numbers that can be compared year on year. You have scanner exports, a vendor management spreadsheet, a ticket queue and a risk register that each count things differently.

A bad week looks like this. You pull last year's slide and find the vulnerability count was taken from a tool you have since replaced. The new tool finds three times as many components because it reads transitive dependencies, so the count went up while your actual risk went down. A director asks why the "critical vulnerabilities" number doubled, and the honest answer takes ten minutes and a whiteboard. Meanwhile the vendor section says "all critical vendors reviewed", which is true and tells the board nothing about the software those vendors ship into the bank.

The fix is not a better chart. It is a fixed set of definitions, agreed once with the committee, applied the same way every year, and a page that ends with decisions rather than reassurance.

The rule behind the report

This section summarises the primary texts. It is not legal or regulatory advice; your counsel and your examination history decide how these apply to your bank.

The Interagency Guidelines, section III.F

The Interagency Guidelines Establishing Information Security Standards are published by each federal banking agency in its own regulations. The OCC's version is Appendix B to 12 CFR Part 30. The FDIC's version is Appendix B to 12 CFR Part 364. The Federal Reserve carries the same guidelines for the banks it supervises. The structure is the same in each: section III covers developing and implementing the program, with paragraphs A through G.

Paragraph III.F, "Report to the Board", says the institution shall report to its board or an appropriate committee of the board at least annually. The report should "describe the overall status of the information security program" and the institution's compliance with the Guidelines. It should discuss material matters, addressing issues such as:

• risk assessment;
• risk management and control decisions;
• service provider arrangements;
• results of testing;
• security breaches or violations and management's responses;
• recommendations for changes in the information security program.

Three other paragraphs shape what the software supply chain part of that report should contain.

• III.A, Involve the Board. The board or a committee approves the written program and oversees its development, implementation and maintenance, including assigning responsibility and reviewing reports from management.
• III.C.3, testing. Key controls, systems and procedures are tested regularly, with frequency and nature set by the risk assessment, and tests conducted or reviewed by independent parties or staff.
• III.D, Oversee Service Provider Arrangements. The institution exercises due diligence in selecting service providers, requires them by contract to implement appropriate measures, and, where the risk assessment indicates, monitors them, including by reviewing audits, summaries of test results or equivalent evaluations.
• III.E, Adjust the Program. The program is adjusted for changes in technology, threats and business arrangements, including outsourcing.

Read together, the software supply chain page answers III.F's list for one slice of the program. Inventory and KEV exposure are risk assessment. Remediation time and overdue findings are results of testing and control decisions. Exceptions are risk management decisions. Vendor software risk is service provider arrangements. The decisions line is recommendations for changes.

The 2023 Interagency Guidance on Third-Party Relationships

The Federal Reserve, the FDIC and the OCC issued the Interagency Guidance on Third-Party Relationships: Risk Management in the Federal Register on 9 June 2023 (88 FR 37920). It states that the guidance is final as of 6 June 2023 and it replaced each agency's earlier third-party guidance.

Two parts matter for your page. First, the guidance says a banking organization's board "has ultimate responsibility for providing oversight" of third-party risk management and for holding management accountable. It also says the board gives clear guidance on acceptable risk appetite and approves policies. Second, its section on documentation and reporting lists examples of what supports effective oversight. The list includes a current inventory of third-party relationships that identifies those supporting higher-risk and critical activities, remediation plans addressing the quality of a third party's controls, reports from third parties of security breaches or other events that may pose a material risk, results of independent reviews, and periodic reporting to the board, including, where relevant, dependency on a single provider for multiple activities.

Software is now one of the main things banks buy from third parties: core and digital banking platforms, loan origination, payments, fraud tools, and the open source those vendors build on. If the board is ultimately responsible for third-party oversight, the board needs a view of the software risk those relationships bring.

The FFIEC IT Examination Handbook

The FFIEC IT Examination Handbook's Information Security and Management booklets are where examiners look for how a bank governs security and reports on it. Read the current booklets directly on the FFIEC site before you cite them; their structure has changed over the years, and an examiner will expect your citations to match the current text. This post does not quote them.

NIST CSF 2.0 as a common language

Many bank programs map to the NIST Cybersecurity Framework 2.0. Its Govern function has two categories that line up with this page. Oversight (GV.OV) asks that risk management strategy outcomes are reviewed to inform strategy (GV.OV-01), that the strategy is reviewed for coverage of requirements and risks (GV.OV-02), and that risk management performance is evaluated and reviewed for adjustments (GV.OV-03). Cybersecurity Supply Chain Risk Management (GV.SC) asks that suppliers are known and prioritised by criticality (GV.SC-04), and that the risks posed by a supplier and its products and services are understood, recorded, prioritised, assessed, responded to and monitored over the course of the relationship (GV.SC-07). Line 1 and line 6 of the template below support GV.SC-04 and GV.SC-07; the trend lines support GV.OV-03. If your board pack already uses CSF language, tag each metric on the page with the subcategory it supports.

What the board is not asking for

None of these texts ask the board to read vulnerability lists. III.F asks for status, material matters and recommendations. The third-party guidance asks the board to set risk appetite and hold management accountable. Your page should give the board enough to do those two things and nothing more.

Step by step: build the page

These steps work with whatever tools you have: a scanner, a spreadsheet, a ticketing system and a risk register.

1. Fix the scope. Start from the bank's application inventory, not from a scanner's project list. Mark each application with a tier (for example, tier 1 for customer facing or critical activity systems), whether it is built in house, bought, or bought and customised, and whether a third party supports a critical activity through it.
2. Write the definitions. Use the definitions table below. Put it in an appendix to the board report and in your program documentation, with a version number and the date the committee accepted it.
3. Pick a cut-off date. Every number is "as of" one date. Use the same date every year if you can, such as the last business day of the quarter before the board meeting.
4. Collect the inputs. SBOMs or component inventories per application; open findings with first detected date and fixed date; KEV and EPSS flags from the public sources; the exception register; the vendor list with criticality.
5. Compute the six numbers for this year, and recompute last year's under the same definitions if your scope or tools changed.
6. Write one sentence per metric saying what changed and why, in plain terms.
7. List the decisions. Two to four items, each one a yes or no the board or committee can give.
8. Review with the second line. Ask risk management or internal audit to check two numbers back to source before the pack goes out. Note who checked.
9. File the evidence. Keep the export, the query and the definitions version used for each number, so you can answer an examiner's question about the page a year later.

The one-page template

Copy this into your board pack and replace the bracketed fields. The figures in the example column are illustrative round numbers, not benchmarks.

Under the table, three short paragraphs: what improved, what got worse and why, and what you are asking for.

Metric definitions that survive a tool change

The definitions are the part directors never see and examiners always ask about. Each one names the numerator, the denominator, the source and what is excluded.

Two rules make these definitions hold. First, define by the bank's own inventories wherever possible, so a new tool can only change the numerator, never the population. Second, count things a director can picture: applications, vendors, exceptions. Component counts and raw finding totals move with scanner depth and should stay in the appendix.

What the Interagency Guidelines require the board report to cover, and how often

Section III.F requires a report to the board or an appropriate committee at least annually. The report should describe the overall status of the information security program and the institution's compliance with the Guidelines, and discuss material matters such as risk assessment, risk management and control decisions, service provider arrangements, results of testing, security breaches or violations and management's responses, and recommendations for changes.

So the annual minimum is a floor, and the content list is a guide to material matters rather than a fixed form. The text says the report will vary with the complexity of the program; the FDIC's version says so in those terms. A community bank with mostly purchased software will weight the service provider line heavily. A regional bank with its own digital channels and in-house developers will weight testing results and remediation. In both cases, the software supply chain page is one part of the III.F report, not a separate report.

How often beyond annually is your call. Many committees take a short quarterly update on two or three lines (KEV exposure, overdue findings, past expiry exceptions) and the full page once a year. If you do that, use the same definitions in both.

What the third-party guidance and the FFIEC expect boards to oversee

The 2023 guidance does not ask the board to manage vendors. It asks the board to provide oversight and hold management accountable, to give guidance on risk appetite, and to approve policies. For critical activities it expects more rigour across the whole life cycle: planning, due diligence, contract negotiation, ongoing monitoring and termination.

For software, that oversight turns into four questions the board should be able to answer from your page:

1. Which third parties support critical activities through software they deliver or host?
2. Do we know what is inside that software well enough to act when a widely exploited flaw lands?
3. When a vendor's software carries a known exploited vulnerability, how long does it take the vendor and us to close it?
4. Are we dependent on one provider for several critical activities, and what would that mean in an incident?

The guidance's documentation list maps straight onto these: an inventory that flags critical activities, remediation plans for third-party control gaps, reports from third parties on security events, results of independent reviews, and periodic board reporting including single provider dependency. Your line 6 is the software slice of that reporting.

On the FFIEC IT Examination Handbook, check the current Information Security and Management booklets yourself before citing a section. The practical point is simple: examiners will compare what management told the board with what the bank's own records show. Keep your evidence folder (step 9 above) ready for that comparison.

Which five to seven metrics fit on one page

The six in the template, plus the decisions line, are chosen against three tests.

• Does a director know what to do if it gets worse? Inventory coverage getting worse means "fund or prioritise discovery". KEV exposure getting worse means "ask why and when". A raw count of medium severity findings fails this test.
• Is it defined by something the bank controls? Coverage, exceptions and vendor lines are defined by bank inventories. KEV exposure is defined by a public catalog the board can look up.
• Does it link to a rule the board already owns? Remediation targets come from the vulnerability management standard. Exception rules come from the risk acceptance policy. Vendor criticality comes from the third-party program.

Metrics that usually do not earn a place on the board page:

Why KEV and EPSS rather than CVSS alone

CISA describes its Known Exploited Vulnerabilities catalog as the authoritative source of vulnerabilities that have been exploited in the wild, and recommends organizations use it as an input to vulnerability management prioritisation. A KEV listing is a fact a director can check. That makes it a good board-level filter.

FIRST describes EPSS as a model that estimates the probability that a published CVE will be exploited in the wild in the next 30 days, producing a score between 0 and 1, updated daily. FIRST also notes EPSS is not a complete risk score. Use EPSS in the appendix or in the narrative, for example "of the 20 overdue findings, 4 have an EPSS probability above our threshold". Do not make the board compare EPSS numbers year on year: the model is retrained and scores change daily, so last year's EPSS figure and this year's are not on the same scale.

CVSS stays useful as a severity label in your definitions ("critical" in line 3) but does not need its own line.

How to show year-on-year trend honestly

Directors read arrows. Make sure an arrow means what it looks like it means.

Median versus mean

Remediation times are skewed: most findings close quickly and a few take months. A mean is pulled up by the long tail, so one stubborn vendor fix can make a good year look bad. A median shows the typical case. Report the median and the 90th percentile together: the median tells the board how the process works, the percentile tells them how bad the tail is.

Illustrative example with round numbers: ten KEV findings closed this year, nine in 10 days each and one in 200 days. The mean is 29 days. The median is 10 days. The 90th percentile is near the top of the range. All three are true. Only the median and percentile together tell the board that the process works and one item needs attention.

If a tool reports mean time to remediate by default, keep its number for your own operations and compute the median from the underlying finding data for the board.

Scope changes

When the population changes, restate. If you add 15 applications to tier 1 this year, recompute last year's coverage and exposure lines over the same 15 where you can, or show them as a separate row labelled "added this year". Never let a scope change pass as a trend.

New repositories and new tools

New repositories bring their whole backlog with them on the day they are first scanned. Show "findings inherited from newly scanned applications" as its own figure for the first year, so the board does not read it as new risk created by the teams.

When you change tools, run old and new in parallel for one reporting period if you can, and report the bridge: "under the old method, X; under the new method, Y; the difference is from Z". Then switch the definition version in the appendix.

Cohorts for remediation time

Measure days to remediate on findings closed in the period, and separately count findings still open. Measuring only closed findings rewards closing the easy ones. The overdue line (line 4) catches what the median hides.

How exceptions and accepted risks should appear

An exception is a decision to keep a known risk for a time. The board, or the committee it delegates to, should see the decisions above the delegated threshold and the shape of the rest.

On the page, show three numbers: open exceptions, exceptions expiring in the next 90 days, and exceptions past expiry. Past expiry should be zero. If it is not, say why in one sentence.

In the appendix, list each exception above the board's threshold with:

Two habits help. Make renewal an explicit decision with a new approval, not an automatic extension. And roll vendor-driven exceptions up by vendor, because six exceptions waiting on one supplier is a third-party oversight issue the board should see as one line.

What decisions the report should ask the board for

III.F asks for recommendations for changes in the program. The software supply chain page is a good place to make them concrete. Typical asks:

1. Set or confirm risk appetite for known exploited vulnerabilities in tier 1 applications, stated in days.
2. Approve or decline exceptions above the delegated threshold, listed in the appendix.
3. Fund coverage where the inventory line shows a gap, for example applications without a component inventory.
4. Require component transparency in contracts for vendors supporting critical activities, such as an SBOM at each major release and notification of known exploited vulnerabilities.
5. Accept or address concentration, where one provider supports several critical activities.
6. Approve changes to the standard, such as a shorter remediation target for internet facing systems.

Phrase each one as a yes or no with a date. "The committee is asked to approve a 15 day target for KEV findings in internet facing tier 1 applications, effective next quarter" is a decision. "The committee is asked to note continued progress" is not.

A worked example of the narrative

Illustrative only, with round invented numbers.

"Coverage of tier 1 applications rose from 40 of 50 to 45 of 50. The five without a current inventory are vendor hosted, and three vendors have agreed to supply component lists by the next report. Open KEV findings in tier 1 fell from 10 to 6; the oldest is 40 days old and waits on a vendor release, covered by an approved exception expiring in 30 days. Median days to remediate KEV and critical findings fell from 18 to 12; the 90th percentile is 45 days, driven by two vendor fixes. No exceptions are past expiry. We ask the committee to approve a contract requirement for component lists from vendors supporting critical activities."

Five sentences, every number traceable, one decision.

What stays the CISO's own judgement

The data can be automated. These cannot:

• Risk appetite. Proposing it is your job; approving it is the board's. A tool can show how many findings breach a target; it cannot tell you what the target should be.
• Materiality. Whether an issue is a "material matter" under III.F, or whether an incident needs separate reporting, is a judgement for you, the bank's legal team and senior management.
• The narrative. Which three sentences go under the table, what you call out, and how you frame a bad quarter.
• Vendor conversations. A vendor's score or SBOM tells you where to look. The contract, the escalation and the decision to exit belong to the third-party program and its owners.
• Independent review. Who checks the numbers, and how, is set by your second and third lines.

How Safeguard does this

Everything above works with any toolset. This section shows how Safeguard supplies the inputs, based on Safeguard's documentation. Screens and fields are named only where the docs name them.

1. Build the inventory. SBOM generation and analysis (GA) produces SPDX and CycloneDX SBOMs for each connected project, and software composition analysis (GA) builds the full transitive inventory, including container layers. Safeguard's vulnerability docs say it performs daily continuous scanning of your projects and re-evaluates them when new CVEs are published. Vendor-supplied SBOMs can be analysed too. Map each Safeguard project to an application in your inventory so line 1 counts against your denominator, not Safeguard's project list.

2. Flag KEV exposure. Vulnerability management (GA) groups findings into Critical, High, Medium, Low and Exploitable, where Exploitable means known exploitation in the wild. Each finding carries its CVE, CVSS score, EPSS score, affected component, fixed version and reachability status, and data comes from sources including NVD, GitHub Security Advisories, OSV and CISA KEV. Filter by exploitable status and date range to produce line 2. Natural language search also works; the docs give the example "Show me critical vulnerabilities in production that are actively exploited".

3. Prioritise the backlog behind the number. Reachability analysis and prioritisation (GA) combines call path analysis, runtime and configuration context, EPSS, KEV and business context such as asset criticality and exposure. Use it to decide what to fix first. Keep reachability out of the board definitions unless you also define it there, because it is an engineering judgement aid rather than a number a director can check.

4. Read the executive view. The executive risk dashboard (GA) spans the whole platform rather than one project. Safeguard's dashboard docs describe an organisation-wide security score from 0 to 100, a vulnerability summary with trend, a top risks list that includes actively exploited CVEs and aging vulnerabilities, trend charts that include mean time to remediation and time to fix by severity, and a project table with critical and high counts. Every dashboard number drills through to the underlying results, so you can check any figure before it reaches the pack. Dashboards are editable, with time filters. The docs describe the remediation trend as a mean; for the board's median and 90th percentile, export the finding data and compute them.

5. Record exceptions with expiry dates. On a vulnerability, Accept Risk asks for an expiration date and a business justification and submits it for approval; Mark False Positive asks for a justification and goes for approval if your policy requires it. The Compliance and GRC suite (GA) has a Risks tab for the wider risk register. Policies and gates (GA) enforce your remediation standard in pipelines with Block, Warn or Notify actions, and approvals for a breach run through these exceptions. Count open, expiring and expired exceptions for line 5.

6. Score critical vendors' software. Third-Party Risk Manager, TPRM (GA), requests SBOMs from vendors and tracks each request's status. Its Risk Assessment gives each vendor a risk score from 0 to 100 where higher is better: the docs band it as 0 to 25 Critical, 26 to 50 High, 51 to 75 Medium and 76 to 100 Low. The score draws on vulnerability risk (including EPSS and known exploited vulnerabilities), compliance risk based on SBOM quality and age, component risk and operational risk. Comparative analysis shows vendors side by side with trend over time, and the assessment report includes an executive summary. TPRM monitoring alerts on events such as a KEV addition, a risk change or an SBOM expiry. Note the direction: component risk scores elsewhere in Safeguard run the other way, so do not put the two on the same chart.

7. Export and schedule. The dashboard docs list PDF export and scheduled weekly or monthly reports. Bulk export (GA) covers formats including CSV, Excel, PDF, JSON and Parquet, which is what you want for the evidence folder and for computing medians. Save the export used for each line with the definitions version.

8. Fix faster before next year's report. Autonomous remediation (GA) can open tested, policy gated fix pull requests through Griffin AI, one repository at a time or in bulk. It ships switched off, with every category set to Manual, so your teams decide what runs on its own. The Remediate flow on the Vulnerabilities page has you review proposed changes before pull requests are created.

9. Ask questions from your assistant. Safeguard's MCP server (GA) lets external assistants such as Claude operate the platform, within the tools you allow. Safeguard is listed in the Claude connector directory as a community connector. That is handy for the questions directors send after the pack goes out, such as "which tier 1 applications have open KEV findings older than 30 days?"

Requirement, Safeguard input, and what you still own

What Safeguard does not do

• It does not write the board narrative or set risk appetite. It supplies the numbers and the drill-down. The page's sentences, the appetite and the materiality call are yours.
• Its metrics cover what it scans and the vendors you enrol. Software outside connected projects, vendor hosted systems that supply no SBOM, and vendors not enrolled in TPRM are not in its numbers. Your coverage line should say so.
• It does not give a legal reading of the Interagency Guidelines or the third-party guidance. It does not decide what is a material matter or what the examiner will expect.
• Board minutes, approvals and committee charters live elsewhere. Safeguard records exception approvals for findings; it is not the board's system of record.
• The vendor score is not due diligence. A 0 to 100 score helps you rank vendors and spot change. III.D due diligence, contract terms and the decision to keep or exit a vendor stay with the third-party program.
• It does not fix vendor code. When the vulnerable code sits inside a vendor's product or hosted service, the fix has to come from that vendor.
• The dashboard trend is a mean. If you report medians, as this post recommends, compute them from the export.

Common mistakes

• Letting the tool define the denominator. If coverage is "projects scanned divided by projects in the scanner", it is always near full. Use the bank's application inventory.
• Reporting raw finding totals year on year. A deeper scanner raises the count. Report application and CVE pairs for KEV, and keep totals in the appendix.
• Mean time to remediate with no percentile. One long vendor fix distorts the year. Report median with the 90th percentile.
• Exceptions without expiry. "Until the vendor fixes it" is not a date. Give every exception an expiry and make renewal a fresh approval.
• Vendor lines that measure questionnaires. "All critical vendors assessed" says nothing about the software. Count SBOMs on file and open KEV findings.
• No decisions. A page that ends with "for information" misses III.F's recommendations line and the board's appetite role in the third-party guidance.
• Changing definitions silently. Version the definitions and restate the prior year when they change.
• Comparing EPSS over time. The model and scores change. Use EPSS to rank within a period, not to trend across years.

FAQ

What does section III.F of the Interagency Guidelines require?

A report to the board or an appropriate board committee at least annually on the overall status of the information security program and compliance with the Guidelines, discussing material matters such as risk assessment, control decisions, service provider arrangements, testing results, breaches and responses, and recommended changes.

Is software supply chain risk a separate board report?

No. It is part of the III.F information security report, covering software inventory, known exploited vulnerabilities, remediation, exceptions and vendor software risk. Some banks also show the vendor line in the third-party risk report; use the same definitions in both.

How many metrics should a bank board see on software supply chain risk?

Five to seven. The six in this post (coverage, KEV exposure, median days to remediate, overdue findings, exceptions, critical vendor software risk) plus a line of decisions fit on one page.

Should I report mean or median time to remediate to the board?

Median with the 90th percentile. Remediation times are skewed by a few long fixes, which pull the mean up and hide how the process usually performs.

How do I show trend when we changed scanners this year?

Run both tools for one period if you can, report the bridge between them, and restate last year under the new definitions. Version the definitions in the appendix so the change is visible.

Why use the CISA KEV catalog on a board page?

CISA describes it as the authoritative source of vulnerabilities exploited in the wild. A listing is a public fact a director can check, so it is a stable filter for the most important findings.

What should the board see about exceptions?

The count of open exceptions, how many expire in the next 90 days and how many are past expiry, with an appendix listing each one above the delegated threshold, its owner, approver and expiry date.

What does the 2023 third-party guidance expect the board to do?

Provide oversight of third-party risk management, hold management accountable, give guidance on risk appetite and approve policies. Its documentation examples include periodic reporting to the board, including dependency on a single provider for multiple activities.

Does a vendor risk score satisfy third-party due diligence?

No. A score helps rank vendors and track change over time. Due diligence, contract requirements and monitoring under III.D and the 2023 guidance remain the bank's own process.

What decisions should the CISO ask the board for?

Risk appetite for known exploited vulnerabilities in critical systems, approval of exceptions above the delegated threshold, funding for coverage gaps, contract requirements for component transparency from critical vendors, and any change to the remediation standard.

The page counts what is still open; next year's KEV and overdue lines shrink fastest when the time between a fix existing and that fix running in production gets shorter. The section below is Safeguard's standard note on closing that gap, for the open source dependencies and container images your teams build.

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

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

Gold Registry provides hardened, drop in replacements for upstream packages and container images. 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, compatibility tested 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 first demo shows Claude connected to the Safeguard MCP server with OAuth, and how you choose which Safeguard tools Claude may use. For a board report, the same connection lets you or your analyst ask Claude about the projects and findings behind each number while you check the page.

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

The second demo is a real Android session with the Safeguard mobile app: you send work to a computer running the Safeguard CLI and approve the command on the phone with Allow once, Allow for turn or Deny. The CLI asks before any command that changes something. For a CISO between committee meetings, that is how a scan or a fix request keeps moving without a laptop, while every change still needs your approval.

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

Related reading: a one-page supply chain posture summary for the board, how often AppSec should report to the board, median or mean time to remediate, a checklist before quoting a patch statistic in a board deck and how the Interagency Guidelines shape service provider oversight.

Quick check

Sources

• OCC: 12 CFR Part 30, Appendix B, Interagency Guidelines Establishing Information Security Standards (eCFR)
• FDIC: 12 CFR Part 364, Appendix B, Interagency Guidelines Establishing Information Security Standards (eCFR)
• Interagency Guidance on Third-Party Relationships: Risk Management, 88 FR 37920 (Federal Register)
• Interagency Guidance on Third-Party Relationships: Risk Management, full text (GovInfo)
• CISA: Known Exploited Vulnerabilities Catalog
• FIRST: Exploit Prediction Scoring System
• FIRST: EPSS frequently asked questions
• NIST: The NIST Cybersecurity Framework (CSF) 2.0, CSWP 29
• Safeguard docs: ESSCM Dashboard
• Safeguard docs: Vulnerabilities
• Safeguard docs: Risk Score
• Safeguard docs: TPRM Risk Assessment
• Safeguard docs: Compliance

Get started: download Safeguard and read the documentation.

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