MSSP and MSP Guide to Offering Software Supply Chain Security

If you run a managed security or managed IT practice, you can offer software supply chain security as a repeatable service: an inventory of what each client ships (SBOMs), continuous dependency scanning, a triage standard driven by known exploitation, fix pull requests the client merges, and a monthly evidence pack. The work that makes it a service, not a pile of scans, is the scoping: who owns the code, who merges, who accepts risk, and how one client's data never touches another's.

This guide is written for the practice lead or service owner at an MSSP or MSP who has started hearing "can you look after our open source too?" from clients. The first two thirds work with any tooling. Safeguard comes in at the section called "How Safeguard does this".

Key takeaways

• Sell outcomes in tiers (inventory, monitoring, remediation, evidence), and write down in the contract which of them you own and which the client owns. Code changes almost always stay the client's decision.
• Start from the rules your clients already live under: the FTC Safeguards Rule's service provider oversight duty, HIPAA business associate terms, CMMC's treatment of external service providers, and CISA's joint guidance for MSPs. Each one shapes what your client will ask you to prove.
• Triage on exploitation first: CISA's Known Exploited Vulnerabilities catalog, then FIRST's EPSS, then whether the vulnerable code is actually reachable in that client's application. CVSS alone will bury your analysts.
• Keep clients apart by design: one boundary per client, least privilege roles for your analysts, client contacts as viewers, SSO and SCIM so leavers lose access everywhere at once, and an append-only audit log.
• In Safeguard, SBOM generation and analysis is GA, software composition analysis and deep transitive dependency scanning are GA, vulnerability management with EPSS and KEV is GA, reachability analysis is GA, policies and gates are GA (actions are Block, Warn and Notify, with approval handled through exceptions), autonomous remediation with Griffin fix pull requests is GA and ships switched off with every category set to Manual, CSAF and VEX upload is GA, the Compliance and GRC suite is GA, the Trust Center is GA, TPRM is GA, and the CLI with its built in local runner is GA.
• Safeguard's docs describe a Tenant, Organization, Project and Version structure with tenant and organization roles. They do not describe a dedicated MSP console, white labelling or cross client rollups, so confirm anything beyond the documented structure before you sell it.

The situation

The request rarely arrives as a project. It arrives as a forwarded email. A client's largest customer has sent a security questionnaire that asks for a software bill of materials and a vulnerability management policy for third party components. Or a client in financial services has had its own examiner ask how it oversees the service providers that touch customer data, and you are one of them. Or a defense subcontractor you look after is working through CMMC and has realised that you, as the managed provider, sit inside its assessment scope.

Whichever door it comes through, the shape is the same. The client wants you to take on a job it does not have the people for: know what open source is in its software, know when something in it becomes dangerous, get it fixed, and produce paper that shows all of that happened.

You can say yes to this. Many practices already run vulnerability scanning on servers and endpoints, so dependency risk feels adjacent. It is adjacent, but it differs in three ways that matter for a service:

1. The asset is code, not a machine. The fix is a change to a manifest or lockfile in the client's repository, which has to build, pass the client's tests and be merged by someone on the client side.
2. The volume is much higher. One application can pull in hundreds or thousands of transitive packages, and one advisory in a popular library can touch most of your clients on the same morning.
3. The evidence is a deliverable. Your client's customers and auditors want an SBOM, a statement of which vulnerabilities apply, and proof the process works. That paper is often what the client is paying for.

What a bad week looks like

Picture the morning a widely used library gets a critical advisory and lands in CISA's Known Exploited Vulnerabilities catalog. Every client calls. Your analysts open each client's tooling one at a time, with different credentials. Nobody knows which clients ship the vulnerable version, because inventories were last refreshed months ago. Two clients ask for a written statement for their own customers by end of day. One client's developer asks your analyst to "just push the fix", and your contract does not say whether you are allowed to.

The rest of this guide exists to make that morning boring: current inventories, an agreed triage rule, a fix path that respects who owns the code, and a statement template ready to send.

The rules behind the request

None of what follows is legal advice. Your clients' counsel and auditors decide what their obligations mean for them. What you can do is understand the shape of each rule well enough to scope a service that helps your client meet it, and to avoid promising things the rule puts on the client.

CISA and partners: guidance written for MSPs and their customers

On 11 May 2022, CISA published joint advisory AA22-131A with the NSA, the FBI and cybersecurity authorities in the United Kingdom, Australia, Canada and New Zealand. It is written for both sides of the relationship: managed service providers and the customers who rely on them. Because an MSP holds trusted access to many networks at once, compromising one provider can reach many customers.

Its recommendations read like a checklist for any service you run on a client's behalf: enforce multifactor authentication on MSP accounts that reach customer environments, apply least privilege, segregate internal networks, retire obsolete accounts, keep logs for at least six months, and understand the cascading supply chain risk the provider itself poses. On the contract side, it asks that MSP and customer contracts transparently identify who owns which security roles and responsibilities, and that MSPs not reuse admin credentials across customers.

Two consequences for a software supply chain service follow directly. First, your own access into each client's repositories and pipelines is an attack path, so it has to be scoped, logged and revocable. Second, your clients are being told to ask you these questions in writing, so have the answers ready.

FTC Safeguards Rule: your financial clients must oversee you

Many US MSP clients are "financial institutions" under the FTC's Standards for Safeguarding Customer Information, 16 CFR Part 314: mortgage brokers, auto dealers that finance, tax preparers, payday lenders and similar non-bank businesses. Section 314.4(f) requires them to oversee their service providers. In practice that means taking reasonable steps to select providers capable of maintaining appropriate safeguards, requiring those safeguards by contract, and periodically assessing providers based on the risk they present.

Section 314.4(d)(2) also asks for continuous monitoring, or, where that is not in place, annual penetration testing and vulnerability assessments at least every six months. A dependency scanning service does not satisfy that on its own, but it is part of the vulnerability assessment picture for the client's own software, and your monthly report is the kind of document their periodic review of you will ask for.

HIPAA: when you become a business associate

If a client is a covered entity or business associate under HIPAA and your service involves access to electronic protected health information, you are likely a business associate yourself. The Security Rule's administrative safeguards at 45 CFR 164.308(b) let a covered entity permit a business associate to handle ePHI only with satisfactory assurances, documented in a contract that meets 164.314(a). Dependency scanning usually does not need ePHI at all, which is a design goal worth writing into your service: scan code and manifests, never production data.

CMMC: external service providers are in scope

For clients in the defense industrial base, the CMMC Program rule at 32 CFR Part 170 defines an External Service Provider as external people, technology or facilities an organization uses to provide and manage IT or cybersecurity services on its behalf, and it counts a provider as an ESP when controlled unclassified information or security protection data, such as log or configuration data, is processed, stored or transmitted on the provider's assets. If that describes your work for a defense client, expect to appear in that client's assessment scope and to be asked for evidence about how you operate.

NIST guidance that defines "good" for the work itself

Three NIST documents give you vocabulary your clients' auditors will recognise:

• NIST SP 800-218, the Secure Software Development Framework (SSDF). It groups practices into Prepare the Organization (PO), Protect the Software (PS), Produce Well-Secured Software (PW) and Respond to Vulnerabilities (RV). The PS and RV groups are where an SBOM and dependency monitoring service fits: keeping provenance data for components, and identifying, analysing and remediating vulnerabilities on an ongoing basis.
• NIST SP 800-161 Revision 1, Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations. It treats suppliers, including service providers, as part of the risk an organization must manage, and it is the document to point to when a client asks why you want a written scope.
• The NIST Cybersecurity Framework 2.0 (CSWP 29, February 2024). It gives organizations of any size a shared taxonomy of cybersecurity outcomes and lists supply chain risk management among its topics, so clients that report against it can map your service to those outcomes.

Federal benchmarks your commercial clients borrow

Federal civilian agencies work to CISA directives, and commercial security programs often borrow the same yardsticks. CISA's Known Exploited Vulnerabilities catalog lists vulnerabilities with evidence of active exploitation. Binding Operational Directive 26-04, issued on 10 June 2026, revoked BOD 19-02 and BOD 22-01 and sets remediation timelines in its Table 1 from variables such as whether the asset is publicly exposed, whether the CVE is in KEV and whether exploitation can be automated. Your commercial clients are not bound by it, but a timeline borrowed from a federal directive is easier to defend than one invented in a sales meeting. Treat it as a reference point and let each client choose its own.

For SBOM content, CISA published updated Minimum Elements for a Software Bill of Materials on 29 July 2026, replacing the NTIA's 2021 list. Build your SBOM deliverable to those elements, in either SPDX or CycloneDX.

For vulnerability exploitability statements, OASIS CSAF 2.0 defines a machine readable advisory format with a VEX profile, and CycloneDX supports VEX as well. A VEX statement lets a client say, in a standard form, "this CVE is in our SBOM but does not affect our product, and here is why".

Step by step: build the service, with or without Safeguard

These steps assume nothing about your tooling. Use them to write the service description, the statement of work and the internal runbook.

1. Decide what you are selling, in tiers

Clients understand tiers. Your analysts need them too, because each tier implies a different amount of work per client. A workable catalogue has four layers that stack:

Keep license compliance and third party vendor SBOM review as add ons. They use the same inventory but different expertise, and some clients will not need them.

2. Write the responsibility matrix before the first scan

Disputes come from an unclear line between "you watch" and "you act". Put this table in the statement of work:

The "Merge" row is the one to argue about early. A provider that merges code inherits responsibility for outages. Most practices keep merge rights with the client and sell speed of preparation instead.

3. Design client separation and your own access

Write down, per client, the exact boundary that holds that client's data, which of your staff can see it, with which role, and how access is removed. A short standard you can apply the same way every time:

• One boundary per client (an organization, workspace, tenant or account, depending on your tooling). No client data in a shared bucket, shared spreadsheet or shared ticket queue.
• Your analysts get the least privilege role that lets them triage and prepare fixes. Policy changes are reserved for named leads.
• Client contacts get read only access by default.
• Single sign on into your tooling, with SCIM or an equivalent offboarding hook, so a leaver loses access to every client at once.
• Short lived or scoped credentials for automation. No personal tokens in shared scripts.
• An audit log you can export per client, because AA22-131A tells your clients to ask for exactly that.
• Where a client will not grant cloud access to its repositories, a scanning path that runs inside the client's network and sends only results out.

4. Onboard each client with the same checklist

Use one checklist for every client:

1. List every application, service and repository in scope, with an owner on the client side for each.
2. Identify package ecosystems and build tools per repository (for example npm, PyPI, Maven or Gradle, Go modules, NuGet, Cargo).
3. Identify container images the client builds and where they are stored.
4. Decide the SBOM trigger: on every merge to main, on every release, or on a schedule.
5. Agree the triage policy (step 5 below) and get the client's security owner to sign it.
6. Agree notification channels and ticketing (chat channel, email, the client's tracker).
7. Run the first full scan, then hold a short findings review so the client sees the baseline before alerts start.
8. Record any third party software the client wants you to watch through the vendor's own SBOMs.
9. Confirm data handling: what you store, where, for how long, and how it is returned or deleted at exit.

5. Set a triage standard every client signs

Agree the triage rule in advance. Here is an illustrative starting point. The timelines are examples to adapt, not a regulatory requirement and not a promise:

Two notes on this table. EPSS is FIRST's daily estimate of the probability that a published CVE will be exploited in the wild in the next 30 days; it is a ranking aid, not a verdict. And "not reachable" should carry a reason someone can audit later, which is exactly what a VEX statement is for.

6. Run remediation as pull requests, not tickets

Tickets that say "upgrade package X" sit in backlogs. A prepared pull request that bumps the version, updates the lockfile and passes the client's tests gets merged. Your remediation tier should promise the pull request, not the merge:

• Prepare the smallest safe upgrade first (patch or minor version), and call out breaking changes in the pull request description.
• Run the client's own test suite in their CI. If tests fail, say so and stop; do not edit their tests.
• Group related upgrades per repository so reviewers see one change, not twenty.
• Track every open fix pull request with an age, and escalate stalled ones in the monthly review.
• For findings with no fix yet, record a mitigation or an exception with an expiry date, approved by the client's owner.

7. Ship a monthly evidence pack per client

Keep the structure identical for every client so it is cheap to produce:

1. Scope: applications and repositories covered, SBOM count and freshness.
2. Exposure: open vulnerabilities by priority, with KEV items called out.
3. Movement: new, fixed and still open since last month; median age of open P1 and P2 items.
4. Remediation: fix pull requests opened, merged and stalled.
5. Exceptions: active exceptions with owner and expiry date; expired exceptions.
6. Policy: gate results from the client's pipelines, if the tier includes gates.
7. Statements: VEX statements issued, questionnaires supported.
8. Changes in scope: repositories added or retired.

8. Rehearse the "big CVE morning"

Write the runbook now and test it once with a past advisory:

1. Search across every client's latest SBOMs for the affected package and versions.
2. Produce a list of affected clients and applications, with reachability where known.
3. Send a holding note to every client, affected or not, within an agreed window. Unaffected clients want to hear "not affected, here is why" as much as affected ones want a plan.
4. For affected clients, open fix pull requests where a fixed version exists, or record a mitigation where it does not.
5. Draft VEX or customer facing statements for clients that asked, and hand them to the client's owner to sign.
6. Close the incident in each client's monthly pack.

9. Plan the exit on day one

State in the contract that at exit you will export the client's SBOMs, findings history, exceptions and audit records in open formats, revoke your access, remove your integrations and runners, and confirm deletion in writing.

What should a managed software supply chain service include?

At minimum: a current SBOM per application, continuous monitoring against vulnerability sources, a written triage policy, a defined path to fix, and a monthly report. Anything less is a resold scan. License compliance, vendor SBOM review and VEX authoring are sensible add ons.

Who should merge the fix, you or the client?

The client, in almost every case. Your value is the quality and speed of preparation. If a client wants you to merge, make it a separate written authorisation with named repositories, and check your insurance covers the outcome.

What do you need from the client's developers?

Four things: read access to repositories (or a way to run scans inside their network), a named reviewer per repository for fix pull requests, a working CI test suite so your pull requests can prove themselves, and a contact who can answer "is this function actually used?" when reachability is unclear. Put all four in the onboarding checklist and the statement of work.

Which contract clauses matter most?

Without giving legal advice: scope, the responsibility matrix, merge rights, notification timelines in both directions, data handling and retention, the tooling vendors you use, audit rights and exit. AA22-131A tells customers to ask about several of these.

How Safeguard does this

Everything in this section comes from Safeguard's offering documentation and docs.safeguard.sh. Where the docs show a screen or a command, it is named. Where they do not, the outcome is described instead. Commands below are quoted from the docs and were not run for this article.

1. Map clients to the documented structure

Safeguard's Organization and User Management page describes a hierarchy of Tenant, then Organizations, then Projects, then Versions. The tenant is the top level container: a single billing entity with global settings, SSO configuration and API key management. Organizations are logical groupings within the tenant, which the docs describe as suitable for separate business units, project portfolios and access boundaries. Projects are the units that get SBOMs, scans and policies. A Product can also group several projects so you see combined risk across a release train.

For a managed practice, the natural reading is one organization per client inside your tenant, with one project per client application or repository. The docs do not prescribe an MSP layout, so treat this as a design choice and confirm it with Safeguard before onboarding the first client, especially if any client needs its own billing, its own SSO configuration or its own deployment. Those live at the tenant level.

Per organization, the docs list settings for a default security policy, notification settings, integration defaults and data retention. That maps cleanly onto "each client has its own triage policy and its own alert channel".

Organizations are created at Settings › Organizations with + New Organization, a name, a description and a primary contact email.

2. Give your staff and the client's staff the right roles

The same docs page lists four roles. A Tenant Admin has full access to all organizations and settings. A Manager manages specific organizations, users and policies, within the organizations assigned to them. A User views and works with assigned projects, including creating projects, configuring integrations and managing mitigations. A Viewer has read only access to assigned projects.

A pattern that fits the responsibility matrix above:

Members are invited at Settings › Members with + Invite Member, choosing a role and the organizations the person belongs to. The Members page shows status, role, organization membership and last active date, which is the list you review every quarter. The offering files note that Members and Organization settings require tenant admin or org admin rights.

For identity, Safeguard supports SSO through SAML 2.0, Google, OpenID, Microsoft and GitHub, SCIM provisioning, and 2FA with WebAuthn, passkeys, TOTP and FIDO2. Role based access control has built in and custom roles, and the audit log is append only. Those are the controls AA22-131A asks providers to show.

3. Connect each client's code, or scan inside the client's network

From Integrations in the sidebar, the Add Project/Product tab lists source code connections (GitHub, GitLab, Bitbucket and generic Git), container registries (Amazon ECR, Docker Hub, GCP sources and OCI compatible registries), AI models from Hugging Face, and file uploads including package manifests and CSAF or VEX files. Each connected repository becomes a project with a branch or tag and a version.

Many clients will not hand a cloud service OAuth access to their repositories. For them, the docs describe the local runner, which is built into the Safeguard CLI (GA). It polls the platform for jobs assigned to that machine, runs each scan locally and uploads only the resulting SBOM and findings. All traffic is outbound HTTPS that the runner opens, and source code stays on the machine. Install and headless operation, exactly as the docs show them:

# macOS and Linux
curl -fsSL https://cli.safeguard.sh/install | bash

# Start without the terminal UI and serve this workspace
safeguard runner start --workspace ./path/to/repo
safeguard runner status
safeguard runner stop

On a first interactive run, safeguard opens the terminal and /login approves the session in a browser. On networks that forbid held connections, the docs describe --poll-wait 0 to poll at a fixed interval instead. A runner on a small server inside the client's network is often the answer that unblocks a cautious client.

4. Produce the SBOM deliverable

SBOM generation and analysis is GA, in SPDX and CycloneDX, with continuous scanning on push, on a schedule or on release. Software composition analysis with full transitive inventory and deep dependency scanning is GA across the major package ecosystems and container layers. Where a repository cannot be connected, the docs list a package manifest upload, and CSAF and VEX upload is GA: the docs list CSAF 2.0, CycloneDX VEX, OpenVEX and the CSAF VEX profile as supported formats, uploaded from Integrations with the Upload filter.

That gives you the Inventory tier: a versioned SBOM per client project, kept current without an analyst running anything by hand.

5. Triage on exploitation, not on volume

Vulnerability management is GA, with CVE detection from public sources enriched with EPSS and CISA KEV. Reachability analysis and prioritisation is GA: it combines static, dynamic and configuration reachability with EPSS, KEV and context to rank which findings matter in that client's application. Safeguard does not promise a fixed reduction in findings, and nor should your service.

This is how the triage table in step 5 becomes something your analysts execute instead of argue about. KEV status, EPSS and reachability arrive on the finding, and the client's policy decides the priority.

6. Turn each client's triage policy into a gate

Policies and gates are GA. Policies evaluate SBOMs and generate findings; gates are checkpoints that enforce them. Policies are built at Settings › Policies with Create Policy, using the visual builder or YAML, and the docs list conditions such as vulnerability severity, CVSS score, EPSS score, license, component age, maintenance status and SLSA attestation level, plus templates such as No Critical Vulnerabilities and License Compliance. Policy creation from a plain English prompt is also GA.

Each policy has one Action, and there are three:

Approval is not a gate action. It runs through exceptions: a developer requests an exception against a policy and finding, gives a business justification and an expiration date, approvers are notified, decide, and the decision is recorded in the audit trail. That is precisely the "client approves, MSP tracks expiry" row in the responsibility matrix.

To fail a client's CI build on a gate, the docs show:

safeguard ci scan --wait --fail-on-gate <gate name or id | all>

It exits zero when the gate is Passed or Warning and non zero when it is Failed, Error or Not evaluated. The docs note that policy outcomes are switched on per workspace by Safeguard, so ask for it during onboarding.

7. Prepare fixes the client merges

Autonomous remediation is GA. Griffin opens tested fix pull requests, for one repository or in bulk with one pull request per repository, with breaking change detection. It ships switched off, with every category set to Manual, and nothing is applied until the master toggle is enabled. For a managed service that default is the right one: start every client on Manual, generate fix pull requests on request, and let the client's reviewers merge. Move a category to automatic only with written agreement from the client, recorded against the responsibility matrix.

8. Deliver evidence and answer questionnaires

The Compliance and GRC suite is GA, with frameworks, controls, evidence, monitoring, tests, questionnaires, risks and vendors in one place. Policy compliance reporting covers status by policy, exception history and violation trends, which are three of the eight sections in the monthly pack above. Bulk export is available in common formats including CSV, Excel, PDF, JSON and Markdown, which helps when a client wants raw data rather than a report.

The Trust Center is GA. The docs describe it as a public page, managed on Compliance › Trust Center, published at a slug under trust.safeguard.sh, where an organization shows its frameworks, controls, policies, subprocessors and documents. Publishing is always an explicit action, and restricted documents are shared through access requests. Whether a client publishes one is the client's decision; your service can prepare it.

9. Extend to the client's own vendors

TPRM is GA. It lets you onboard a client's software vendors, request SBOMs, projects or products from them, score and monitor supplier risk, and apply policies and gates. For clients under the FTC Safeguards Rule or CMMC, reviewing their vendors' SBOMs is a natural add on to your own service.

10. Work across clients without breaking separation

Notifications go to Slack, Microsoft Teams, Google Chat and Discord, and ticketing connects to Jira, Notion, Microsoft Planner, Linear and Asana, so each client's alerts can land in that client's channel. The MCP server (GA) at mcp.safeguard.sh lets analysts work from assistants such as Claude; the docs say the assistant acts as the signed in user and can do only what that user's role allows. The docs also warn that an MCP key acts as the member who created it across the whole workspace, so prefer OAuth for analysts and keep keys out of shared scripts. The desktop app and mobile apps are GA for on call analysts.

For clients that cannot send code to any third party model, the offering files describe Zero AI mode (GA), where the platform runs deterministically with no LLM, and bring your own model (GA). They describe the AI mode as configurable per tenant, not per organization. If one client requires Zero AI and another wants full AI features, confirm with Safeguard how that maps to your layout before you sign either client.

For clients that need their own isolation, the offering files list SaaS in US, EU and government regions, private VPC or dedicated tenancy, on-prem, and fully air-gapped deployment, all GA. Safeguard's posture is designed for FedRAMP High, and its SOC 2 Type II audit is in progress. Put that wording, and nothing stronger, in your own client documents.

Related reading

If you want the shorter, setup focused version, see How an MSP can organize client work in Safeguard. For the relationship side, How the MSSP business and vendor relationship works covers what to agree in writing. Consultants working client by client may prefer A security consultant's toolkit. For the incident that made every client ask about provider risk, read Kaseya VSA: eight questions for your RMM and MSP risk. And when a client's supplier sends an SBOM, how to tell if a partner's SBOM is complete and what VEX is and whether a partner should send one will help.

What Safeguard does not do

• It does not document a dedicated MSP console. The docs describe tenants, organizations, projects and roles. They do not describe white labelling, a cross client rollup dashboard, delegated access between separate tenants, or partner billing. Do not sell any of those to a client on the strength of this article; confirm them with Safeguard first.
• It does not decide or merge for your client. Fix pull requests are prepared for review. Merging, releasing, approving exceptions and accepting risk stay with the client, and autonomous remediation ships off with every category set to Manual.
• It does not write your contract or sign your client's statements. The responsibility matrix, the statement of work, any VEX statement sent to a client's customer, and any attestation to a regulator are human decisions with human signatures.
• It does not set AI mode per client organization. The offering files describe AI mode as configurable per tenant. If clients differ on whether any model may see their code, plan the tenant layout around that.
• It does not fix code you do not build. Vulnerabilities inside a vendor appliance, a hosted service or an operating system runtime still need the vendor's fix. The service covers the open source dependencies and images the client builds and ships.
• It does not give you a working provisioning API today. Several docs pages carry a banner that the documented /v1 REST endpoints are not yet available. Plan client onboarding through the app, the CLI and CI, not through scripts against those endpoints.
• It does not make your practice compliant. Using Safeguard does not make you or your client compliant with the FTC Safeguards Rule, HIPAA or CMMC. It produces evidence that helps your client's assessors.

Common mistakes

1. Selling scans instead of a service. A monthly PDF of findings, with no triage policy, fix path or evidence pack, churns at renewal.
2. Pooling client data for convenience. A shared workspace with a "client" tag feels efficient until an analyst exports the wrong list.
3. Triage on CVSS alone. Severity without KEV, EPSS and reachability buries analysts and annoys developers.
4. Silent merge rights. A developer says "just push it", your analyst does, and production breaks. Write merge rights down or do not merge.
5. Personal tokens in shared automation. An analyst leaves and their token keeps running scripts for six clients.
6. No exit plan. A departing client asks for its history and you rebuild exports by hand.
7. Overstating your tooling's certifications. Repeat your vendors' posture language exactly. "Designed for FedRAMP High" is not "FedRAMP authorized".
8. Forgetting the unaffected clients. On the big CVE morning, clients that are not affected still want a note saying so, with a reason.

FAQ

Can an MSP sell software supply chain security without developers on staff?

Yes, if the client's developers merge. Your analysts need to read a manifest, understand semantic versioning and explain a breaking change, not own the code.

Do we need SBOMs if the client never asked for one?

Yes. The SBOM is the inventory the service runs on, and you need it to answer "are we affected" in minutes.

How do we handle a client that will not give us repository access?

Run the scan inside the client's network. In Safeguard, the local runner built into the CLI does this, polling outbound and uploading only SBOMs and findings.

Which clients should we start with?

Clients with a forcing function: a customer asking for SBOMs, a CMMC assessment coming up, or a regulator or examiner asking how they oversee providers. They feel the value in the first month.

Should we use BOD 26-04 timelines with commercial clients?

Only as a reference point. BOD 26-04 binds federal civilian agencies, not your clients. Offer it as a benchmark and let each client's security owner set their own targets.

What goes in a VEX statement?

The product and version, the vulnerability, and a status. CSAF 2.0 uses known affected, known not affected, fixed and under investigation, and its VEX profile expects an impact statement for products marked not affected. CycloneDX VEX covers the same ground.

Does using Safeguard make our client compliant?

No. It gives your client inventory, findings, fixes and evidence. Compliance is a judgement by the client's assessors against the client's whole program.

Can our analysts use AI assistants on client data?

Only where the client agrees. Safeguard's MCP server lets an assistant act with the analyst's own permissions, and Zero AI mode exists for tenants that cannot allow any model. Put the client's choice in the statement of work.

Before you close a finding

A managed service lives or dies on how fast a client goes from "affected" to "fixed". The block below sets out the three fix paths Safeguard offers, which is the menu your remediation tier draws from for every client.

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 the runner set up on a machine you control, approved with its device code, then scanning from the terminal. For a managed practice, that is the pattern for a client who will not grant cloud access: the runner sits inside their network and only results leave.

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

The second demo is a real CLI session: install, safeguard opens the interactive terminal, and a request to fix a lodash CVE leads it to read the finding and advisory, ask before any command that changes something, edit package.json, run npm install and npm test with approval, and print a summary without pushing anything. That is the shape of the remediation tier: a prepared change, tested, left for the client's reviewer.

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

The third demo connects Claude to the Safeguard MCP server with OAuth and chooses which tools Claude can use. For an analyst team, that choice is where you keep assistants inside the same least privilege rules as people.

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

Quick check

Sources

• CISA: AA22-131A, Protecting Against Cyber Threats to Managed Service Providers and their Customers
• 16 CFR 314.4, FTC Safeguards Rule elements (Cornell LII)
• 45 CFR 164.308, HIPAA administrative safeguards (Cornell LII)
• 32 CFR 170.4, CMMC Program definitions (Cornell LII)
• CISA: BOD 26-04, Prioritizing Security Updates Based on Risk
• CISA: 2026 Minimum Elements for a Software Bill of Materials
• CISA: Known Exploited Vulnerabilities Catalog
• NIST SP 800-218, Secure Software Development Framework
• NIST SP 800-161 Rev. 1, Cybersecurity Supply Chain Risk Management Practices
• NIST CSWP 29, The NIST Cybersecurity Framework 2.0
• FIRST: Exploit Prediction Scoring System (EPSS)
• OASIS: Common Security Advisory Framework Version 2.0
• Safeguard docs: Organization and User Management
• Safeguard docs: RBAC, Teams and Organizations
• Safeguard docs: Local Runner
• Safeguard docs: Generate SBOM
• Safeguard docs: CSAF/VEX Upload
• Safeguard docs: Policies and Gates
• Safeguard docs: Policy outcomes and actions
• Safeguard docs: Trust Center setup
• Safeguard docs: MCP Integrations

To try the flows in this guide, download the CLI and apps at safeguard.sh/download and read the documentation at docs.safeguard.sh/docs.

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