Finding every repo and image a health system inherits in an acquisition

When a health system closes an acquisition, the CISO inherits software nobody on the acquiring side has seen: source repositories in a different Git organization, container images in a registry with its own credentials, and packages pulled in by build files that were never reviewed. The fastest defensible path is to connect every code host and registry you can find, generate an inventory of software components from each, attach an owner and an ePHI flag to every asset, and then treat anything that exists but is not connected as a finding of its own. Do that in the first 30 days, refresh it continuously, and your HIPAA risk analysis has a real foundation instead of a spreadsheet of guesses.

This post walks that job end to end for a CISO at a US health system. The first two thirds work with whatever tools you already own. Safeguard enters at "How Safeguard does this", with every capability it uses labelled.

Key takeaways

• The HIPAA Security Rule already requires an accurate and thorough risk analysis (45 CFR 164.308(a)(1)(ii)(A)) and a fresh evaluation after operational changes (164.308(a)(8)). An acquisition is the textbook operational change, and you cannot analyse risk on software you have not found.
• HHS proposed in January 2025 to make a written technology asset inventory, with identification, version, accountable person and location for each asset, a standard of its own, reviewed at least every 12 months and after any merger. As of 25 October 2026 the Federal Register shows it only as a proposed rule; plan for it, do not cite it as law.
• The hard part is not scanning. It is finding the repos and images nobody listed in the data room, and assigning a person to each one.
• Work in three passes: enumerate (every code host, registry and build system), characterise (an SBOM and vulnerability picture per asset), and govern (owner, ePHI flag, policy, and a standing alert for anything new or unconnected).
• In Safeguard, this uses asset discovery (GA), SBOM generation and analysis (GA), software composition analysis with vulnerability management and EPSS and KEV enrichment (GA), reachability analysis (GA), policies and gates (GA), Griffin AI natural language search (GA), third-party risk management (GA), the compliance and GRC suite (GA), the CLI and local runner (GA), and autonomous remediation (GA, shipped switched off, every category set to Manual).
• Safeguard does not sign your risk analysis, decide what counts as ePHI, notify regulators, or reach software you never give it access to. Those stay with you.

The situation

The deal closed on a Friday. Your health system has bought a company: a physician group with its own patient portal, a telehealth startup, or a revenue cycle vendor that was already a business associate. "Application security review" is a workstream with your name on it.

On Monday you learn three things. The acquired company's engineering lead left during the deal. The data room listed eleven applications, but the engineers who stayed mention "a few more services" that run in a cloud account the finance team is still trying to get credentials for. And the acquired company's patient scheduling app calls an API on your side through an interface engine that went live before close.

Who is asking, and by when:

• The board's risk committee wants to know at its next meeting whether the acquisition changed the organisation's cyber risk.
• Your compliance and privacy officers need the HIPAA risk analysis updated, because the acquired systems now handle ePHI under your name.
• Integration leadership wants a date for moving the acquired apps onto shared infrastructure, identity and pipelines.
• Security operations cannot monitor services they do not know exist.

What a bad week looks like: a critical library vulnerability is announced, your incident channel asks "are we exposed?", and for the acquired estate the answer is "we think not, we are checking". Or an OCR investigation after a breach at the acquired entity asks for your risk analysis, and the inventory behind it is the data room spreadsheet from before close.

This is the job: produce a complete, owned, current inventory of the software you just bought, and keep it complete as the two estates merge.

The rule behind it

This section interprets regulations so you can plan. It is not legal advice; your counsel and compliance officer decide how these rules apply to your organisation.

What the HIPAA Security Rule requires today

The current text of 45 CFR 164.308, fetched from the eCFR on 25 October 2026, sets out administrative safeguards that apply to covered entities and business associates. Four provisions matter most after an acquisition:

None of these provisions uses the words "software inventory". But the risk analysis has to be accurate and thorough, and in practice that means you have to know which systems handle ePHI and what they are built from.

What HHS has proposed

On 6 January 2025 HHS published a notice of proposed rulemaking, "HIPAA Security Rule To Strengthen the Cybersecurity of Electronic Protected Health Information" (RIN 0945-AA22). The comment period closed on 7 March 2025. A search of the Federal Register API on 25 October 2026 for that RIN returned the proposed rule and no final rule, so treat everything below as proposed.

In the proposed regulatory text, HHS would replace the current security management process standard with a new standard at 164.308(a)(1), "Technology asset inventory". It would require:

1. A written inventory of technology assets containing the identification, version, person accountable and location of each asset.
2. A network map showing how ePHI moves through the entity's electronic information systems, including how it enters, exits and is accessed from outside.
3. Review and update of both on an ongoing basis, at least once every 12 months, and when there is a change in environment or operations that may affect ePHI. The proposed text lists, among those changes, "a sale, transfer, merger, or consolidation" of all or part of the entity.

The proposed definition of "technology asset" in 164.304 includes hardware, software, electronic media, information and data. Software, in other words, is in scope by name.

Finalised or not, the proposed text states plainly what HHS considers a thorough foundation for risk analysis, and it is a sensible bar to hold yourself to.

Federal frameworks that give you the vocabulary

NIST SP 800-66 Rev. 2, published in February 2024, is NIST's resource guide for implementing the HIPAA Security Rule. It is not a regulation, but OCR and auditors know it, and it organises risk assessment activities around knowing where ePHI is created, received, maintained and transmitted.

The NIST Cybersecurity Framework 2.0 (CSWP 29) gives you outcome language that boards and auditors recognise:

SBOMs as the common format

You will want a software bill of materials for each acquired application, because it is the format that lets you answer "are we exposed?" in minutes later. CISA maintains its SBOM program page at cisa.gov/sbom, which as of 25 October 2026 lists the 2026 update to the minimum elements for an SBOM as the current guidance. The two formats you will meet are CycloneDX (an OWASP standard) and SPDX. Either works for this job, as long as you pick one internal format and convert everything to it.

How teams do it today and where it breaks

Most health systems run the same playbook after an acquisition: start from the data room's application list, interview the acquired engineers, scan the flagship product, import the target's CMDB, and refresh it all quarterly. Each step is reasonable. Interviews are honest but incomplete, because people remember the services they work on, not the proof of concept with a public endpoint or the image a contractor pushed to a personal namespace. The flagship is usually the best maintained code the target has; the risk sits in the long tail. And a quarterly refresh misses everything the acquired developers ship in between, which our piece on continuous asset discovery versus quarterly inventory covers in depth.

The common failure is the same in every row: the inventory describes what someone said exists rather than what the code hosts and registries say exists.

Step by step, with or without Safeguard

This is the playbook. It works with open source tools, commercial tools, or a mix. Plan it in three phases across roughly 90 days, and assign a named owner to each phase.

Phase 1, days 0 to 30: enumerate everything

Step 1. Get credentials first. List every system at the acquired company that can hold code or built artifacts: Git hosts, container registries, internal package registries, artifact stores, CI systems and cloud accounts. Request read-only access to each, with a deadline in the integration plan, because access is the long pole.

Step 2. Enumerate from the systems, not from people. List every organization and repository in each Git host (archived ones too), every repository and tag in each registry, and the running container services and functions in each cloud account. One row per asset.

Step 3. Reconcile against the data room. An enumerated asset that maps to no listed application is a question for the acquired team. A listed application with no repository is a bigger one: the code is somewhere you have not looked, or it is vendor software.

Step 4. Freeze nothing, tag everything. Shutting down unknown assets on day one can break a clinical workflow. Tag each "unowned" until someone claims it.

Use this intake template for every asset row. It mirrors the four fields HHS proposed for the written inventory, plus the fields you need to act:

Phase 2, days 15 to 60: characterise each asset

Step 5. Generate an SBOM per repository and per image. Scan each repository's dependency manifests and lockfiles, and each container image's layers. Store the SBOMs in one place, in one format. Record the date each was generated, because an SBOM older than the last deployment tells you little.

Step 6. Join SBOMs to vulnerability data. Match components to known vulnerabilities. Enrich with the CISA Known Exploited Vulnerabilities catalogue and with EPSS scores, so your first list is ordered by what attackers are actually using, not by raw CVSS.

Step 7. Find the ePHI paths. With the privacy officer, mark which assets create, receive, maintain or transmit ePHI: the obvious ones (portals, scheduling, billing exports, interface feeds) and the less obvious (analytics jobs, support tools, logging pipelines that capture request bodies). This also feeds the network map HHS proposed.

Step 8. Rank by ePHI handling, then internet exposure, then known exploited vulnerabilities. That gives a first remediation queue you can defend to a board and an auditor.

Here is a simple triage table you can use the same day:

Phase 3, days 30 to 90: govern and keep it current

Step 9. Assign owners, by name. Every asset row gets a person. Where nobody will claim an asset, the integration lead assigns one or the asset goes on the retire list. Unowned assets are where breaches start.

Step 10. Put a gate in front of new risk. Agree a minimum policy for anything that ships from the acquired estate from now on: for example, no new critical vulnerabilities, no components on the KEV catalogue, and an SBOM generated at build time. Enforce it in the acquired company's pipelines as well as your own.

Step 11. Watch for new and ungoverned assets. Set up a standing check that flags any new repository, new registry namespace, or running image that is not in the inventory. This is the control that keeps Phase 1 from decaying.

Step 12. Fold the acquired assets into your normal programmes: vulnerability SLAs, third-party reviews of the acquired company's suppliers, access reviews and the annual risk analysis.

Step 13. Write it up. Scope, method, asset counts, owner and SBOM coverage, open risks with treatment decisions, and the next review date. That document is your evidence that the post-change evaluation happened.

Board-ready one-pager template

For the next risk committee meeting, use four lines and one chart:

1. Scope. "We have identified N repositories, M container images and K running services from the acquired company, of which P handle ePHI." (Replace the letters with your counts.)
2. Coverage. Owner coverage and SBOM coverage, as two percentages, with the trend since close.
3. Exposure. The number of ePHI-handling, internet-exposed assets with a known exploited vulnerability, and the date by which each will be fixed or isolated.
4. Decision needed. Any asset where the business must choose between funding a fix, accepting the risk, or retiring the application.

The chart is coverage over time.

What usually hides in an acquired healthcare codebase

The following are patterns to look for, drawn from how software estates grow, not findings from any specific company.

• Archived repositories that still build images. Archived in the Git host, yet the image built from it still runs because nobody rebuilt it.
• Images without source. You can inventory what is inside them, but you cannot fix them at the source until you find or rebuild it.
• Forked internal libraries. One library copied into several repositories and modified separately. Each copy drifts and needs its own entry.
• Integration glue. Small scripts and services between the acquired product and EHR interfaces or clearinghouses. Rarely reviewed, very often touching ePHI.
• Demo environments. Built for a trade show, never torn down, sometimes loaded with test data that turns out to be real.
• Personal namespaces. Repositories or images under a developer's own account. When that developer leaves, so does your access.
• Vendor software you thought was code. Licensed products belong in third-party risk, with a vendor SBOM request.

Our related post on asset discovery for merger and acquisition due diligence covers the pre-close side of this; this post assumes the deal has already closed.

Illustrative scenario: a regional health system absorbs a telehealth company

This is a composite example built for this post. It is not a customer, and it describes no real organisation. All numbers below are example inputs chosen to make the arithmetic easy, not results.

The setup. A regional US health system (call it "the Health System") acquires a telehealth company (call it "the Target"). The Target has a patient-facing video visit app, a scheduling service that books into the Health System's EHR through an interface engine, and a billing export that sends claims data to a clearinghouse. The data room lists 12 applications.

Week 1. The Health System's CISO gets read-only access to the Target's cloud Git organization and its main container registry. Enumeration returns, as example inputs, 140 repositories (30 archived) and 220 image repositories. The 12 listed applications map to 48 of the repositories. That leaves 92 repositories that no listed application explains, and a registry with images for services nobody mentioned.

Week 2. Interviews explain most of the 92: shared libraries, infrastructure code and experiments. Eight remain unclaimed, and two of those build images still pulled by a service in a cloud account the Health System reached only on day nine.

Weeks 3 to 6. An SBOM is generated for every non-archived repository and every deployed image tag. The privacy officer marks 19 repositories as handling ePHI. Four land in the top triage row (ePHI, internet exposed, a KEV-listed component) and are fixed or isolated first.

Weeks 6 to 12. Every asset gets a named owner or a retire decision. A policy against new critical vulnerabilities on ePHI-handling images runs in Warn mode for two weeks, then Block. A standing alert flags any new repository or namespace without an owner, and a risk analysis addendum is filed as the post-change evaluation.

Nothing here depends on a particular tool. The next section shows how Safeguard runs the same workflow.

How Safeguard does this

Safeguard is a software supply chain security platform. For this job, the relevant parts are its Enterprise Software Supply Chain Manager (ESSCM, GA) and the capabilities inside it. Each step below links the docs page it is built from. Where the docs do not show a command or screen, this post describes the outcome instead of inventing one. The CLI snippets are quoted from the docs and were not run for this post.

1. Set up the organization structure for the acquired company

Organization and user management describes the hierarchy (Tenant, Organization, Project, Version); you add an organization under Settings, then Organizations. A separate organization for the acquired company keeps its projects, default policy, notifications and data retention apart while integration runs. Roles are Tenant Admin, Manager, User and Viewer, assignable through SSO group mappings: give the acquired engineering lead Manager on that organization, and your auditors Viewer. Logins, project access, setting changes and role changes land in the exportable audit log under Settings, then Audit Log.

2. Connect every code host and registry you have access to

Asset discovery (GA) is the capability for this job. The asset discovery docs describe it as continuously cataloguing the software an organization builds, buys or consumes, across seven asset classes: source repositories, container images, packages, AI models, SBOMs, vendors and runtime workloads. The offering positions it as discovery plus guardrails and enforcement on the discovered assets, not inventory alone.

You connect sources from the Integrations page. The integrations docs list source code integrations (GitHub, Bitbucket, GitLab cloud or self-hosted, generic Git), container image integrations (including Amazon ECR, Docker Hub, Google Cloud sources and OCI registries) and file uploads. A private connection runs: enter credentials, verify, pick a workspace, review repositories, set branch or tag, project name and version, connect. Projects then appear with their organization, findings and vulnerability counts.

The asset discovery docs describe three feeds: agentless integrations through OAuth or IAM roles, lightweight agents, and SBOM ingestion. Start with agentless integrations, since they need only read access and nothing deployed inside the acquired environment. Once connected, the docs say Safeguard enumerates new repositories, images and models, and polls for pushes, tags, releases and deletions.

3. Get a software inventory for every repository and image

SBOM generation and analysis (GA) produces an SBOM for every connected project, in SPDX and CycloneDX, with software composition analysis (GA) and deep transitive dependency scanning. Each project in ESSCM gets a per-project explorer with tabs that include Dependencies, Vulnerabilities, Suppliers and Licenses, Provenance and Findings.

For images built in the acquired company's pipelines, the container images CI page shows a single step after the build that scans the image on the runner and records it under the image's repository, one version per environment:

safeguard ci scan --image "ghcr.io/acme/api:$TAG" --environment prod --wait --fail-on critical

The docs note that only results leave the runner and no repository integration is needed. That matters when the acquired company's Git host is still being migrated and you cannot connect it yet.

For teams that will not grant repository access at all during integration, the CLI (GA) and the local runner (GA) scan on the engineer's own machine. The integrations docs show the CLI install and scan:

curl -fsSL https://cli.safeguard.sh/install | bash
safeguard
safeguard scan --dir .

The docs say a signed-in scan from the interactive terminal uploads the SBOM and findings while the source stays on the machine, which suits the unclaimed repositories in the scenario.

For vendor software in the acquired estate, ingest the vendor's SBOM and manage the vendor in third-party risk management (TPRM, GA), which requests SBOMs from vendors and scores and monitors supplier risk.

4. Put vulnerabilities in order

Vulnerability management (GA) matches components to known vulnerabilities and enriches them with EPSS and CISA KEV data. Reachability analysis (GA) ranks findings by whether your code actually calls the vulnerable path, so the first items on the list are the ones that matter in the acquired code, not the ones that merely appear in a lockfile. Safeguard does not publish a guaranteed noise reduction figure for this, and neither should you when you brief the board.

5. Attach an owner, a business unit and an ePHI flag to every asset

The asset discovery docs describe four fields on every asset: owner (inferred from CODEOWNERS or container labels, or set manually), business unit, environment, and sensitivity, which includes regulated categories such as HIPAA. These fields drive routing, so a finding in a production workload with regulated data reaches different people than one in a sandbox. Treat inferred owners as drafts: departed staff linger in CODEOWNERS files.

6. Treat unconnected assets as findings

The asset discovery docs describe shadow asset detection: an unconnected repository, a registry image with no SBOM, a running image in no SBOM, or a vendor API called from production but missing from TPRM. These show on the Asset Discovery dashboard as UNGOVERNED and, per the docs, can drive automation such as a Jira ticket. This is the control that keeps Phase 1 from decaying. The same dashboard tracks SBOM, vendor and ownership coverage over time: the numbers for the board one-pager.

7. Ask questions across the whole inventory

Search with Griffin AI (GA) queries SBOMs, components and vulnerabilities in plain English. The search docs give examples such as "Which projects have exploitable vulnerabilities?", and an @ mention scopes a query to one project. When the next widely exploited library flaw lands, "which acquired projects include this component?" becomes a search, not a meeting. Star the weekly queries.

8. Gate what ships next

Policies and gates (GA) apply your minimum standard to the acquired pipelines. The policies and gates docs describe creating a policy under Settings, then Policies, with a visual builder or YAML, using conditions such as vulnerability severity, CVSS score, EPSS score, license, component age and maintenance status, plus templates such as "No Critical Vulnerabilities". Each policy's action decides what a failure does to the gate:

Approvals run through exceptions: a developer requests one against a specific policy and finding, gives a business justification and an expiry date, and an approver decides, with the decision recorded in the audit trail. The docs show a CI job failing on a gate with:

safeguard ci scan --wait --fail-on-gate <gate>

That requires policy outcomes to be on for the workspace. Start the acquired organization's policies on Warn, read what would have been blocked, then move the ePHI-handling projects to Block.

9. Fix, with a human in the loop

Autonomous remediation (GA) can open tested, policy gated fix pull requests through Griffin, for one repository or in bulk. It ships switched off, with every category set to Manual, so nothing changes in the acquired code until your team turns a category on. In the first weeks after close, keep it on Manual and review each pull request, because the acquired code has owners who are still learning your process.

10. Map it to your HIPAA evidence

The compliance and GRC suite (GA) includes HIPAA among its frameworks and stores controls, evidence, tests and risks in one place. The inventory, coverage trend, policy history and exception log from the steps above become evidence for the risk analysis and evaluation provisions. Safeguard's own posture is designed for FedRAMP High, with a SOC 2 Type II audit in progress; ask for current status in your vendor review.

If sending code or SBOM data to a hosted service is a problem, Safeguard can run on-prem or air-gapped (GA), in Zero AI mode with no language model in the loop (GA), or with a model you bring (GA). Settle this with your privacy officer before connecting the acquired repositories.

Requirement to responsibility map

What to measure

Use this as a checklist. These are measures to track, not outcomes to expect; your baseline depends on what you inherited.

• Enumeration completeness. Every Git host, registry and cloud account at the acquired company is connected or has a dated access request.
• Ownership coverage. The share of acquired assets with a named, current owner. Track weekly until it stops moving.
• SBOM coverage. The share of running acquired workloads with at least one SBOM generated since the last deployment.
• Ungoverned assets. The count of repositories, images and workloads flagged as not connected or not owned. It should fall over time and spike only when the acquired team creates something new.
• ePHI-handling assets with known exploited vulnerabilities. The count, and the age of the oldest one.
• Time to answer "are we exposed?" For a newly announced vulnerability, how long until you can say which acquired projects include the component. Run a drill to measure it.
• Exceptions. Count, age and owner of open policy exceptions on acquired projects. Every exception should have an expiry.
• Risk analysis status. The date the acquired estate entered your risk analysis, and the date of the next scheduled review.

What Safeguard does not do

• It does not decide what is ePHI. Sensitivity tags carry your privacy officer's classification; they cannot discover that a logging pipeline captures patient data.
• It does not find what it cannot reach. A Git host or registry without credentials, code on a laptop, or a cloud account the seller still owns stays invisible until connected or scanned locally.
• It does not replace your risk analysis or sign it. The HIPAA risk analysis, the risk ratings and the decisions to accept, mitigate or transfer risk are yours and your compliance officer's.
• It does not handle breach notification or regulator correspondence. If you find evidence of a past incident in the acquired estate, your incident response, legal and privacy teams own what happens next.
• There is no CLI command for the asset graph yet. The asset discovery docs say so directly. Use the web app's Asset Discovery dashboard and Search for asset questions.
• The documented REST endpoints for assets are not live. The asset discovery and organization docs carry a notice that the /v1 REST paths return 404 today and describe intended shape only. Do not plan integration scripts around them yet.
• Kubernetes admission enforcement is not available. The guardrails and enforcement docs say the admission controller is not published. Gates apply to the scans the platform runs and to CI steps.
• Vendor appliances and hosted services still depend on the vendor. For licensed software the acquired company runs but does not build, Safeguard can hold the vendor SBOM and track supplier risk, but the fix has to come from the vendor.

Common mistakes

1. Trusting the data room list as the inventory. It is a starting point for questions, not an answer. Enumerate from the systems.
2. Scanning only the flagship application. The well maintained product is rarely where the risk is. Scan the long tail first if you have to choose.
3. Counting team aliases as owners. "platform-team@" is not an accountable person. HHS's proposed text asks for the person accountable; use names.
4. Shutting down unknown assets on day one. You may stop a clinical workflow. Tag, investigate, then decide.
5. Treating archived as retired. Check whether archived repositories still feed images that run.
6. Turning on blocking gates before anyone has seen the results. Start on Warn, read what would have failed, agree exceptions, then Block.
7. Forgetting the acquired company's own vendors. Their suppliers and business associates are now part of your supply chain and your third-party risk scope.
8. Running the inventory once. Without a standing check for ungoverned assets, you will repeat this exercise next year.
9. Citing a proposed rule as final. The January 2025 HIPAA Security Rule changes are proposed until a final rule is published.

FAQ

Does HIPAA require a software asset inventory?

The current Security Rule does not use those words, but it requires an accurate and thorough risk analysis (45 CFR 164.308(a)(1)(ii)(A)), which in practice depends on knowing which systems handle ePHI and what they contain. HHS's January 2025 proposed rule would add an explicit written technology asset inventory. As of 25 October 2026 that rule is still proposed.

Is an acquisition a trigger for a new HIPAA risk analysis?

The current rule at 164.308(a)(8) calls for evaluation in response to environmental or operational changes affecting ePHI security, and an acquisition is a clear example. The proposed rule names "a sale, transfer, merger, or consolidation" explicitly as a change that would require updating the inventory and network map. Ask your compliance officer and counsel how to document it.

What should a post-acquisition software inventory contain?

At minimum: an identifier, a version, a named accountable person and a location for each repository, image and running service, which matches the four fields in HHS's proposed text. Add whether it handles ePHI, whether it is internet exposed, whether an SBOM exists, and a keep, merge or retire decision.

How do I find repos and images that nobody listed?

Enumerate every organization in every Git host and every repository in every registry you can access, then reconcile against the data room list. Anything that maps to no listed application is a question. A standing check for ungoverned assets catches the ones created after close.

Do I need SBOMs from the acquired company's vendors?

For licensed software the acquired company runs but does not build, yes, ask for one. It belongs in third-party risk management, and the vendor's fix timelines become part of your risk treatment.

Should I give a security platform access to the acquired company's code?

That is a privacy and contractual decision. If repository access is a problem during integration, a CI step that sends only results, or a local scan that keeps source on the engineer's machine, gives you an SBOM without granting the platform read access to the repository.

What do I tell the board?

Scope (how many repositories, images and services, and how many handle ePHI), coverage (owners and SBOMs, as a trend), exposure (ePHI-handling, internet-exposed assets with known exploited vulnerabilities, and when each will be fixed), and any decision the business needs to make.

How is this different from pre-close due diligence?

Diligence works with limited access and a deadline, and its job is to price risk. Post-close discovery has full access and a different job: making the acquired estate governable for the long term. The pre-close side is covered in asset discovery for M&A due diligence.

Once the inventory is in place, the next question for most acquired codebases is how quickly the vulnerable components inside it can be replaced. The section below is the same for every post in this series, and it covers what to do when a fix exists, when it does not, and when you would rather start from components that are already fixed.

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 asset discovery use case page summarises the capability. The three demos below show the hands-on pieces of the workflow in this post.

The first demo sets up the local runner on your own machine, approves it with its device code, and then scans from the terminal. That is the route for acquired repositories you cannot yet connect to the platform: an engineer scans locally while ownership and access are sorted out.

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

The second demo is a real CLI session. After install, safeguard opens the interactive terminal, the user asks it to fix the lodash CVE in a repository, and 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. It ends with /permissions, /model and /scan. The same approval-first flow suits acquired code whose owners are still learning your process.

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 a CISO, that means questions about the merged estate can be asked from an assistant your team already uses, with tool access you decide.

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

For more on the healthcare side, see healthcare software security, HIPAA and SBOMs, the healthcare supply chain security baseline for 2026, and turning SBOM data into prioritised action.

Quick check

Sources

• 45 CFR 164.308, Administrative safeguards (eCFR)
• HIPAA Security Rule To Strengthen the Cybersecurity of ePHI, proposed rule, Federal Register, 6 January 2025
• Proposed rule full text, 90 FR 898 (govinfo)
• Federal Register API search for RIN 0945-AA22
• NIST SP 800-66 Rev. 2, Implementing the HIPAA Security Rule
• NIST Cybersecurity Framework 2.0, CSWP 29
• CISA, Software Bill of Materials
• CycloneDX specification overview
• Safeguard docs: Asset Discovery
• Safeguard docs: Organization and User Management
• Safeguard docs: Integrations
• Safeguard docs: Container images in CI/CD
• Safeguard docs: Policies and Gates
• Safeguard docs: Guardrails and Enforcement
• Safeguard docs: Search
• Safeguard use case: Asset Discovery

To try the workflow on your own repositories, download Safeguard at safeguard.sh/download and read the docs at docs.safeguard.sh/docs.

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