How a Health System Should Manage Open Source in Apps It Builds

A health system that builds its own patient portals, interface engines and clinical tools should run a small, proportionate open source program: keep a dependency inventory for every in-house app, fix known exploited vulnerabilities first on clocks the CISO sets, gate releases of patient-facing apps on a short list of rules, and scan inside the network where policy forbids sending code out. HHS's own health sector guidance, the 2023 Health Industry Cybersecurity Practices (HICP) and the HPH Cybersecurity Performance Goals, already gives you the baseline. You do not need a large AppSec team to meet it, but you do need named owners and a written rule for what stops a release.

This post is for the CISO or the security lead who has inherited AppSec at a US hospital or health system. It covers what the health sector guidance asks, how in-house code differs from vendor and device software, and a method you can run with your own tools. Safeguard appears near the end, with every capability labelled.

This is not legal advice, and no program, tool or vendor makes you HIPAA compliant on its own.

Key takeaways

• Your own code is your own problem. Vendor software and medical devices come with a supplier who patches. Code your developers build, and the open source packages inside it, has no one else on the hook.
• HHS has already set the floor. The HPH Cybersecurity Performance Goals list "Mitigate Known Vulnerabilities" as an essential goal and "Asset Inventory" as an enhanced goal. HICP Technical Volume 2, Practice #7, gives suggested fix windows by severity and exposure.
• Inventory comes first. For each in-house app you need an owner, an exposure rating, a list of every direct and transitive open source component, and an SBOM per release.
• Exploited beats severe. Use CISA's Known Exploited Vulnerabilities (KEV) catalog and exposure to set the clock, not CVSS alone. CISA's BOD 26-04 shows the federal version of that logic, though it does not bind hospitals.
• Gate patient-facing releases on a short list. Block on a few rules you will actually enforce, and route everything else through a dated, approved exception.
• Scan where policy allows. If code cannot leave the network or no external AI model may touch it, choose tools that run on your own machines and can run with no model at all.
• Safeguard labels in this post: SCA and SBOM generation, GA; vulnerability management with EPSS and KEV, GA; reachability analysis, GA; policies and gates, GA; license compliance, GA; CLI and local runner, GA; on-prem and air-gapped deployment, GA; Zero AI mode and bring your own model, GA; autonomous remediation and Griffin fix pull requests, GA, shipped off with every category set to Manual; SAST, GA; data security posture, GA; fork and patch, GA; Gold Open Source and Gold Registry, GA.

Why in-house software is now a security problem for health systems

Ten years ago most hospital software arrived from a vendor, and the security team's job was to patch what the vendor shipped. Today most health systems of any size run development teams. They build patient portal pages the EHR does not provide, scheduling apps, FHIR and HL7 interfaces for new clinics, research data pipelines, internal tools for nurses and schedulers, and small AI assistants around clinical documentation.

Almost all of that code is assembled from open source. A web front end pulls in hundreds of npm packages; a Python integration service pulls in a framework, an HTTP client, a FHIR library and everything they depend on. Developers chose perhaps twenty of those packages. The rest arrived as transitive dependencies.

The security team often learns about these apps late. A team under digital health or research IT can ship a patient-facing app without the review a purchased system gets in procurement: no questionnaire, no contract clause, no SBOM request. The fix is not a large AppSec department. It is the discipline the health sector guidance already asks for, adjusted for the fact that your organisation is now also the software supplier.

What HICP and the HPH Cybersecurity Performance Goals expect

Two voluntary HHS documents set the tone. Neither is a regulation, and both are worth reading in the original.

HICP 2023: the practices and the fix windows

HICP 2023, from the HHS 405(d) program and the Health Sector Coordinating Council, describes five threats (social engineering, ransomware, loss or theft of equipment or data, insider data loss, and attacks on network connected medical devices) and ten practices. Technical Volume 2 covers medium and large organisations, where most health systems with development teams sit.

Practice #7 in Technical Volume 2 is Vulnerability Management. The parts that matter for in-house software are:

• 7.M.B Web Application Scanning. Scanners that test a running web application, with SQL injection, cross-site scripting and misconfiguration named as common attack types. HICP calls web application flaws on systems with sensitive data a high risk.
• 7.M.C System Placement and Data Classification. Rank remediation higher for internet-exposed sensitive systems, systems needed for life and patient safety, and internet-exposed or vendor-managed remote access systems.
• 7.M.D Patch Management, Configuration Management. A routine procedure to patch servers, applications (including web applications) and third-party software. Active exploitation can justify moving a less severe flaw up the queue.
• 7.M.E Change Management. Put a vulnerability scan into each change's testing plan, run before the change reaches production.
• 7.L.B Vulnerability Remediation Planning. For flaws a simple patch will not fix, a plan with a single owner, dates and regular status. HICP warns that plans without a single owner tend to stall.

HICP's Table 9 gives recommended time frames for mitigating IT vulnerabilities, split by where the system sits:

The table was written with servers in mind, but the logic carries across. An internet-facing patient portal sits in the DMZ column; an internal scheduling tool sits in the data center column.

Notice where HICP's SBOM text sits: in Practice #9, Network Connected Medical Devices, as something to request from device makers. HICP does not yet frame SBOMs as something the hospital produces for its own software. That is the gap this post is about.

The HPH Cybersecurity Performance Goals

HHS published the HPH CPGs as a voluntary subset of high-impact practices, built on CISA's cross-sector CPGs and mapped to HICP. Essential goals set a floor; enhanced goals help organisations mature. The ones that touch in-house software:

The HHS page for "Mitigate Known Vulnerabilities" links to CISA's KEV catalog as an additional resource: start with what attackers already use. A patient-facing app is very likely internet-facing under that essential goal, and the shadow asset language in the Asset Inventory goal fits apps built outside central IT almost exactly.

Where HIPAA fits

HIPAA's Security Rule is the regulation in the background. NIST SP 800-66 Revision 2, NIST's guide to implementing it, describes the rule as protecting electronic protected health information (ePHI) against reasonably anticipated threats. This post does not map controls to the rule; go to HHS's text and your counsel for that. The narrower point: an exploited library inside a portal that handles ePHI is the kind of threat your risk analysis should already be catching.

How in-house software differs from vendor and device software

A health system's software splits into three groups. The instinct trained on purchased systems is to wait for a patch. For in-house software, nobody is going to send one.

Three consequences follow. Speed is in your hands: when a fixed version exists, an in-house app can take it in days, so slow fixes are a choice you must justify. Ownership has to be named: an app built by a team that has since reorganised may have nobody. Evidence is yours to produce: when the board asks what is inside the portal, there is no supplier to forward the question to.

If your team also reviews device makers' SBOMs, the sister post on reviewing a medical device maker's SBOM as a hospital security team covers that side.

What inventory the security team needs for internally built apps

Every later step depends on knowing what you have. For in-house software, inventory has two layers: a register of applications, and a component list for each one.

Layer one: the application register

A spreadsheet is fine to start. For each internally built app, record its purpose; a named business owner and technical owner; every repository, including departmental accounts; exposure (internet-facing, partner-facing or internal, which maps to HICP's DMZ and data center columns); whether it handles ePHI; whether a failure could affect patient care; where it runs and how often it ships; and whether it is active or due for retirement. The register tells you which apps fall into HICP 7.M.C's "rank higher" cases.

Layer two: a component list per release

For each app, you need the list of open source components that actually ship, direct and transitive, with versions. The standard way to hold it is a software bill of materials in SPDX or CycloneDX format.

On 29 July 2026, CISA, NSA, FBI and international partners released the 2026 Minimum Elements for a Software Bill of Materials, which replaces the 2021 NTIA minimum elements as the baseline. CISA's announcement lists new fields including component hash, license, SBOM tool name and SBOM generation context, and stresses machine-processable formats. It is guidance, not regulation, but it is the right completeness checklist.

NIST's SSDF (SP 800-218) points the same way. PS.3.2 says to collect, safeguard, maintain and share provenance data for all components of each release, with an SBOM as an example. PW.4.4 says to verify that open source and other third-party components meet your requirements throughout their life cycles.

Practical rules for the component inventory

• Generate from lockfiles. Manifests list what developers asked for; lockfiles list what installed.
• Generate per release, including container images. Last year's SBOM does not describe this week's portal.
• Keep the SBOM with the build artifact, so a responder can say what was live on a given date.
• Search across apps. In the next big open source incident you will be asked "do we use this anywhere". Answer it in minutes.

The post on making a first SBOM when a hospital asks for one covers the mechanics from the supplier side, which is the role your developers now play.

How fast exploited vulnerabilities in internal apps should be fixed, and who decides

No health sector rule sets a fix deadline for in-house software. You set one, write it down and get it approved, using three reference points.

Reference point one: HICP's Table 9

HICP's windows are already familiar to hospital IT from server patching, so reusing them keeps one language. HICP 7.M.D also notes that a less critical flaw under active threat may justify starting incident response and patching quickly. That is the bridge to KEV.

Reference point two: CISA's KEV catalog

CISA calls the KEV catalog the authoritative source of vulnerabilities exploited in the wild, and tells organisations to use it as an input to prioritisation. On 25 October 2026 it listed more than 1,700 entries, each with a CVE ID, date added, known ransomware use and required action. Most entries are commercial products and devices, but open source libraries and frameworks appear too. When one is in your portal, it goes to the top, whatever its CVSS score.

Reference point three: BOD 26-04, as a model rather than a mandate

On 10 June 2026 CISA issued BOD 26-04, Prioritizing Security Updates Based on Risk, which revoked BOD 22-01 (the 2021 directive that created KEV) and BOD 19-02. It binds federal civilian executive branch agencies only, not hospitals. It is still a useful model, because it replaces severity-only deadlines with four questions:

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

The answers set the timeline in the directive's Table 1. The most urgent tier means remediation within three days plus a forensic triage; low-risk cases can wait for the next scheduled major upgrade or rebuild. CISA publishes the KEV, automation and impact answers through its Vulnrichment program, so you can reuse the same inputs.

A worked example policy

This worked example combines HICP's exposure split with the BOD 26-04 questions. It is an illustration, not a standard; the numbers are your governance committee's choice.

Who decides

The clock is a governance decision. The CISO owns the policy and who may approve exceptions. The AppSec lead owns triage: does it apply, is the code reachable, who fixes it. The app's technical owner owns the upgrade, test and deployment. The business owner signs any exception that leaves an exploited flaw open past its clock, with an expiry date. The change advisory board can treat a KEV fix on an internet-facing app as an emergency change, with the after-action review HICP 7.M.E describes. SSDF RV.2.2 (plan and implement risk responses) is the framework language: each vulnerability gets a recorded decision and owner.

The sister post on keeping a contract promise of no known exploited vulnerabilities covers the same KEV discipline from the supplier side.

How to keep source code and data inside the network

Many health systems have a policy that source code for clinical and patient-facing systems does not leave the network and that no external AI model may read it. Source code can hold connection details, internal hostnames and test data that looks a lot like real patient records.

What "inside the network" can mean

Four common patterns, from least to most restrictive:

1. Cloud scanning with repository access. Simplest, and usually ruled out by such a policy.
2. Scanning on your own build machines. Only the component list and findings leave; source code does not.
3. Self-hosted platform. Platform, database and dashboards run in your data center.
4. Air-gapped. No outbound connection; vulnerability data arrives by signed transfer.

Pattern 2 suits most health systems. Patterns 3 and 4 are for policies that treat even the component list as sensitive.

What about AI in the loop

Many AppSec tools use large language models to explain findings or write fixes. Ask any tool in writing: can AI be switched off with scanning still working; which model, hosted where, and do prompts include source code; can we use our own approved model or run it on our hardware; is our data used for training? The post on questions to ask before sending code to an AI vendor has a longer list.

Network rules that make local scanning workable

• Outbound only. Prefer tools that open outbound HTTPS and accept no inbound connections.
• Scoped keys. CI scanning keys should only start scans and read results, stored as CI secrets.
• Database updates. A scanner on stale vulnerability data reports a clean bill of health on old knowledge. Decide how updates arrive.

The related post on air-gapped vulnerability management goes deeper on the most restrictive case.

What should block a release of a patient-facing app

A gate is only useful if it is short enough to enforce. A twenty-rule gate everyone overrides is worse than a four-rule gate that holds.

A short list for patient-facing apps

A sensible starting gate blocks a release when:

1. A known exploited vulnerability is present in a shipped component, with no approved exception. This is the line that matters most, and it follows from the essential HPH CPG.
2. A critical-severity vulnerability with a fixed version available is present in a shipped component. If a fix exists, there is rarely a good reason to ship without it.
3. A component carries a license your counsel has ruled out for distributed or hosted software.
4. The scan did not run or did not finish. A gate that passes when the scanner fails is not a gate. Treat "not evaluated" and "error" as a fail.

Warn, but do not block, on:

• High-severity vulnerabilities with a fix available, so the team plans them into the next release.
• Components that look abandoned or are far behind their current version.
• Findings from code analysis that have not yet been triaged.

Exceptions that do not rot

Every gate needs an exception path, or teams route around it. Make each exception specific (one finding, one app), justified (the function is not called, a compensating control exists, or the fix needs clinical testing), dated, and approved by the right person: the business owner for exploited flaws, the AppSec lead for the rest.

Gate at more than one point

The same rules can warn on every pull request, block on merge to the release branch, and check the built image. The sister posts on proving every production release passed a security gate and stopping vulnerable dependencies at five checkpoints work through that layering.

A proportionate program you can run with your own tools

A small team can run this in a quarter with open source scanners, a spreadsheet and your existing CI.

First 30 days: find and rank

1. Build the application register. Ask development, research IT and digital health leads for every app; search source control for unclaimed repositories.
2. Rate each app's exposure, ePHI handling and patient safety relevance.
3. Generate SBOMs for the production release of the top ten apps by exposure.
4. Match them against vulnerability data and the KEV catalog, which CISA publishes as CSV and JSON.

Days 31 to 60: set the rules

1. Write and approve the fix clock policy.
2. Name technical and business owners for the top ten apps.
3. Fix or formally accept every KEV match found.
4. Add SBOM generation and a vulnerability check to each top ten pipeline, warn-only.

Days 61 to 90: enforce and extend

1. Switch the check to blocking for internet-facing apps, with dated exceptions.
2. Re-check stored SBOMs daily or weekly, so a new KEV entry against an old release is caught between deployments.
3. Extend to the rest of the register, and report to the board in HPH CPG terms: apps inventoried, exploited flaws open, time to close.

The hard parts are finding the apps, naming owners and holding the line on exceptions. A tool makes the technical parts faster; it cannot do the governance.

How Safeguard does this job

Safeguard is a software supply chain security platform. For a health system building its own software, the relevant parts are SCA and SBOM generation (GA), vulnerability management with EPSS and KEV enrichment (GA), policies and gates (GA), the CLI and its local runner (GA), on-prem and air-gapped deployment (GA), Zero AI mode and bring your own model (GA), and autonomous remediation (GA, shipped switched off with every category set to Manual). The steps below follow Safeguard's docs; where the docs do not show a screen or command, the outcome is described instead.

Step 1: choose where Safeguard runs

Safeguard offers SaaS, private VPC or dedicated tenancy, on-prem and air-gapped deployment, all GA. The air-gapped docs describe a control plane inside your perimeter fed by signed snapshot bundles of vulnerability data (including NVD, OSV, CISA KEV and daily EPSS), with no component inside calling outbound. It runs on your own Kubernetes cluster, Postgres and object storage. Most health systems will instead use SaaS with the local runner, so source code stays home.

Step 2: install the CLI and start the local runner

The local runner docs describe the runner as part of the CLI. It runs scan jobs on your machine and uploads only the SBOM and findings, never source code, which suits private repositories and networks that only allow outbound HTTPS.

The docs show this installer:

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

Then run safeguard, type /login, approve the session in your browser, and the runner starts. The first run downloads the scanner tools and the vulnerability database.

For a build server or a shared machine with no terminal session, the docs show headless commands:

# Start without the terminal UI and serve assistant turns for this workspace
safeguard runner start --workspace ./path/to/repo

# Is it running, and what is it doing
safeguard runner status

# Drain in-flight work and stop
safeguard runner stop

According to the docs, all runner traffic is outbound HTTPS that the runner opens, and nothing connects to it. On a network that forbids held connections, --poll-wait 0 switches to polling at a fixed interval set by SAFEGUARD_POLL_INTERVAL (10 seconds by default). safeguard update refreshes the vulnerability databases, and safeguard self-update updates the CLI itself.

Step 3: decide whether any AI model is in the loop

Safeguard offers four AI modes per tenant, all GA: Full AI with Safeguard's models, Zero AI with no LLM in the loop, bring your own approved model, and local models inside your environment. The AI models docs say Zero has no model weights, and that customer code, SBOMs and telemetry are never used to train shared models. Under a no-external-AI policy, choose Zero AI or local models. Scanning, matching, policies and gates are deterministic; Griffin work such as fix pull requests needs a model in the loop.

Step 4: build the component inventory

Safeguard's SCA docs describe resolving the full dependency graph from manifests and lockfiles, including deep transitive dependencies, across npm, pnpm and Yarn, PyPI, Maven and Gradle, Go modules, Cargo, NuGet, Composer and Ruby Bundler, plus components found inside container image layers. SBOM generation in SPDX and CycloneDX is GA.

You can start a project scan from the CLI, as the SCA docs show:

safeguard scan --project my-api

Or, on a build machine, scan a directory fully on the runner and keep the output files, as the CI docs show:

safeguard scan --dir . --output out/

Each finding carries the component and version, CVE or GHSA IDs, severity with EPSS and KEV context, the transitive path, the reachability verdict where available, and the safe upgrade target. Findings from every project sit in one place, so "do we use this anywhere" is one search. License compliance (GA) reads the same graph.

Step 5: rank exploited vulnerabilities first

Safeguard's Vulnerabilities tab shows findings in five categories: Critical, High, Medium, Low and Exploitable, where Exploitable means known active exploitation in the wild. The docs list CISA KEV as a data source and describe filters for severity, CVSS range, EPSS range, exploitable status, fix availability and reachability status. Safeguard's docs also describe daily continuous scanning, so stored projects are re-evaluated when new CVEs are published.

The daily routine: filter to Exploitable, then sort by your exposure rating. Reachability analysis (GA, some language support marked Preview) shows whether the vulnerable function is called; Safeguard's docs say it cuts 60 to 80% of CVE noise, which is Safeguard's stated figure, not a promise. Mark False Positive and Accept Risk (with expiry and justification) go for approval where policy requires, matching the dated exceptions above.

Step 6: write the release rules as policies and gates

In Safeguard, policies evaluate your SBOMs and produce findings, and gates are checkpoints that enforce policies. The policies and gates docs describe creating a policy under Settings, Policies, Create Policy, using a visual builder or YAML. Documented conditions include vulnerability severity, CVSS score, EPSS score, license, component age, maintenance (abandoned packages) and SLSA level. Templates include No Critical Vulnerabilities, License Compliance and No Abandoned Packages.

Each policy has one action, and the policy outcomes docs define three:

• Block. A failed policy fails the gate.
• Warn. The gate passes with a warning naming the policy.
• Notify. The gate passes and Safeguard sends a notification to your configured channels.

Approval works through exceptions: a developer requests one for a specific policy and finding, gives a business justification and an expiry date, and an approver decides, with an audit trail recorded.

Policy outcomes are turned on per workspace by Safeguard, so ask your contact to enable them. The docs treat an unevaluated gate as Not evaluated, never Passed, and never count an Error as a pass, matching rule 4 above.

KEV status is a filter on the Vulnerabilities tab, not a documented gate condition. To hold the "no known exploited vulnerability in a patient-facing release" line, check the Exploitable filter as part of release sign-off, and ask Safeguard whether a policy in your workspace can express it before you depend on one.

Step 7: run the gate in CI

The CI docs show one pipeline step running safeguard ci scan, with guides for GitHub Actions, GitLab CI/CD, Bitbucket Pipelines, Jenkins and Azure Pipelines. Create a secret key under Settings, Developer with the scans:trigger and scans:read scopes and store it as SAFEGUARD_API_KEY.

With --local, the docs say only the results leave the runner, which also works for self-hosted and firewalled Git servers, covering SBOM and dependency vulnerabilities. A blocking step for the patient portal, using flags from the docs:

curl -fsSL https://cli.safeguard.sh/install | bash
safeguard ci scan --local --wait --fail-on critical

To fail on a named gate instead, the policy outcomes docs show --fail-on-gate with a gate name, id or all:

safeguard ci scan --wait --fail-on-gate "Patient portal release"

It exits 0 when the gate is Passed or Warning, and non-zero when it is Failed, Error or Not evaluated. It needs policy outcomes switched on, and the policies docs say gates are evaluated on scans the platform runs for connected repositories, so a local-only pipeline should rely on --fail-on with a severity. The CLI also accepts --scan-mode fast, deep or progressive. SAST (GA) findings are not part of --fail-on yet.

Step 8: fix with pull requests, under your control

Autonomous remediation (GA) uses Griffin to open pull requests that move a vulnerable dependency to a fixed version, singly or in bulk (one pull request per repository), with breaking change detection and optional tests. It ships switched off, with every category set to Manual. For a clinical app, keep it on Manual and route every pull request through change control.

The Safeguard CLI also includes an assistant that can edit code and run commands on your machine. Since CLI v11.10.0, it asks before any command that changes something. For scripts, safeguard exec defaults to strict permissions, where anything a policy file has not pre-approved is denied.

Step 9: keep the evidence

Each CI scan becomes a new project version named after branch and commit, so you keep a history of what each release contained. The docs describe gate evaluation history and reports with exception history and violation trends: material for your risk analysis, board and incident responders.

Requirement, what Safeguard does, what you still own

What remains outside this program

An open source program for in-house apps covers one slice of a health system's risk. Say plainly what it leaves out:

• PHI data flows. Knowing library versions says nothing about where patient data goes. That is HICP Practice #4 work, including 4.L.B Mapping Data Flows.
• Medical devices. HICP Practice #9. The maker patches under FDA oversight; your levers are procurement, segmentation and vendor coordination.
• Vendor SaaS and purchased systems. Covered by the Vendor/Supplier and Third Party Vulnerability Disclosure goals, through contracts and notifications, not your CI.
• Your own code's logic. Dependency scanning will not find an authorisation bug that returns another patient's record. That needs design review, code review, the web application testing in HICP 7.M.B and penetration testing under 7.L.A.
• Infrastructure and identity. A clean SBOM on an unpatched host is not a secure portal.

What Safeguard does not do

• It does not classify PHI or map patient data flows in this program. Data security posture capabilities exist in Safeguard (GA) and are not part of this post. Your data protection program still owns PHI.
• It does not secure medical devices or vendor SaaS. The flows above cover software you build and the open source inside it. Device software and purchased systems need their makers' patches and your vendor management.
• It does not make you, or itself, HIPAA compliant. No tool does. Safeguard helps with inventory, vulnerability management and release evidence; your risk analysis, policies, workforce and counsel decide compliance.
• KEV status is not a documented gate condition. It is a filter in the Vulnerabilities tab. Documented gate conditions include severity, CVSS, EPSS, license, component age, maintenance and SLSA level. Hold a KEV line through release sign-off, or confirm with Safeguard whether a policy in your workspace can express it.
• Policy outcomes are off until Safeguard turns them on for your workspace. Until then, gate results and --fail-on-gate are not available; --fail-on with a severity still works. Gates are evaluated on scans the platform runs for connected repositories, so a local-only pipeline gates on severity.
• SAST findings cannot fail a build yet. SAST is generally available, and its findings are not part of --fail-on today.
• Self-hosting needs your infrastructure. On-prem and air-gapped deployments run on your Kubernetes cluster, databases and storage, and your team operates them.
• Fix pull requests do not merge themselves by default. Autonomous remediation ships off, with every category set to Manual, and Griffin-generated fixes need a model in the loop. Testing and change approval stay with you.
• It does not set your fix clocks or name your owners. The policy, the approvals and the board reporting are governance work.

Common mistakes

Waiting for a patch nobody will send. If your team built it, your team fixes it.

Inventorying repositories instead of releases. An incident asks what was deployed on a given date. Keep SBOMs per release.

Using CVSS alone. An unreachable critical flaw in an internal tool is less urgent than a medium KEV flaw on the patient portal.

Gating on too much, too soon. A gate that blocks every high finding on day one is switched off by week two.

Exceptions with no expiry. An accepted risk with no end date becomes permanent.

Letting a scanner failure pass the gate. An errored or skipped scan is not a pass.

Forgetting apps built outside central IT. Research groups and service lines build software too.

No approved path for AI help. Under deadline, someone pastes code into an external chat. Give developers a sanctioned option.

FAQ

Do HIPAA rules require a health system to scan open source in software it builds?

The Security Rule does not name open source scanning. It requires protecting ePHI against reasonably anticipated threats, and how you address an exploited library is a risk analysis decision. Check HHS's text and your counsel; this is not legal advice.

Are the HPH Cybersecurity Performance Goals mandatory for hospitals?

No. HHS describes them as voluntary, with essential goals as a floor and enhanced goals for maturity. They are mapped to HICP and NIST controls, which makes them useful for board reporting.

What does HICP say about patching timelines?

HICP 2023 Technical Volume 2, Practice #7, Table 9, suggests mitigating critical vulnerabilities in under 14 days in the DMZ and under 30 days in the data center, with longer windows for high, medium and low. It also says active exploitation can justify faster action on a less severe flaw.

Does BOD 26-04 apply to hospitals?

No. BOD 26-04 binds federal civilian executive branch agencies. It replaced BOD 22-01 in June 2026. Hospitals can still borrow its four questions (exposure, KEV status, exploit automation, technical impact) as a model for their own fix clocks.

How do we find in-house apps that security does not know about?

Ask every development lead, including research and digital health, for their apps. Search source control for unowned repositories, and check DNS and certificate records for hostnames pointing at internal builds.

What should an SBOM for an internal hospital app contain?

At minimum, the fields in CISA's 2026 Minimum Elements for a Software Bill of Materials, which include component identity, version, hash, license, the tool that generated the SBOM and the context it was generated in. Produce it in SPDX or CycloneDX, per release, from lockfiles.

Can we scan our code without sending it to a cloud service?

Yes. Scan on machines you control and send out only the component list and findings, or self-host the platform. With Safeguard, the local runner and safeguard ci scan --local keep source code on your machines.

Can we use an AppSec tool with no AI model at all?

Some tools allow it. Safeguard's Zero AI mode (GA) runs the platform with no LLM in the loop. Scanning, matching and gates still work. Features that rely on a model, such as generated fix pull requests, then need a local or approved model.

Who should approve an exception for an exploited vulnerability in a patient portal?

The business owner of the portal, with the CISO's policy setting the limits. The AppSec lead should confirm the justification. Every exception should name the finding, give a reason and carry an expiry date.

How small can a health system AppSec program be and still work?

Small. One person part time can run the 90-day plan for the top ten apps if development leads own their fixes and the CISO backs the gate.

Next steps

If you want to try the Safeguard flows above, install the CLI from safeguard.sh/download and read the setup guides at docs.safeguard.sh. For background on the health sector guidance, see HICP 2023's five threats and ten practices and the HPH CPGs, essential versus enhanced goals.

Fixing an exploited library in an in-house app is usually a dependency upgrade, but sometimes no fixed version exists yet and the clock is still running. The section below describes how Safeguard approaches both the routine upgrade and that harder case for the open source you build and ship.

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 sets up the local runner on a machine you control, approves it with its device code, and scans from the terminal. That is the same flow a health system would use to keep source code for a patient portal on its own build servers while still getting an inventory and findings. Only results leave the machine.

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

The second demo is a real CLI session: install, open the interactive terminal, and ask it to fix the lodash CVE in a repository. 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. For an in-house clinical app, that is how a developer would take a fixed version locally and hand it to your normal change process, with every changing command approved first.

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

Quick check

Sources

• HHS 405(d), Health Industry Cybersecurity Practices 2023, main document
• HHS 405(d), HICP Technical Volume 2: Cybersecurity Practices for Medium and Large Healthcare Organizations
• HHS, HPH Cybersecurity Performance Goals
• NIST SP 800-66 Rev. 2, Implementing the HIPAA Security Rule
• NIST SP 800-218, Secure Software Development Framework
• NIST SP 800-218 full text (PDF)
• CISA, Known Exploited Vulnerabilities Catalog
• CISA, BOD 26-04: Prioritizing Security Updates Based on Risk
• CISA, release of the 2026 Minimum Elements for a Software Bill of Materials (29 July 2026)
• Safeguard docs, Software Composition Analysis
• Safeguard docs, Local Runner
• Safeguard docs, Air-Gapped Deployment
• Safeguard docs, AI Models
• Safeguard docs, Policies and Gates
• Safeguard docs, Policy outcomes and actions
• Safeguard docs, CI/CD Integration
• Safeguard docs, Vulnerabilities
• Safeguard docs, AI Remediate

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