Higher Ed and Edtech Software Supply Chain: Rules, Incidents, 90 Days

A university or edtech company secures its software supply chain by knowing which components sit inside every system that holds student, financial aid or research data, holding vendors to written inventory and disclosure terms, and folding that evidence into the FERPA, GLBA Safeguards Rule and research security work it already owes. In practice that means one inventory, one vendor process and one evidence trail, built over about 90 days and kept current after that.

This guide is written for the people who carry that work: the university CISO, the enterprise applications and student systems team, the research computing and research security leads, the privacy and compliance officers, procurement and vendor risk, and, on the other side of the contract, the CTO and security lead of an edtech company. The first two thirds work with whatever tools you already have. Safeguard only enters at the section titled "How Safeguard does this".

Key takeaways

• FERPA lets a school share education records with a vendor under the school official exception only when the school keeps direct control over how the vendor uses and maintains them (34 CFR 99.31(a)(1)(i)(B)). You cannot exercise control over components you have never listed.
• Colleges that take part in federal student aid programs are financial institutions under the FTC's GLBA Safeguards Rule. That rule asks for a written risk assessment, an inventory of systems, secure development practices for in-house applications and oversight of service providers (16 CFR 314.4). Its notification requirement to the FTC has applied since 13 May 2024.
• Edtech companies that serve children under 13 work under the amended COPPA Rule, whose compliance date was 22 April 2026 and which now spells out a written information security program.
• Research groups holding controlled unclassified information work to NIST SP 800-171, with CMMC phasing into Defense contracts since 10 November 2025, and NIH now asks users of controlled-access human genomic data to attest to the same standard.
• Several of the incidents that hurt schools in the last three years came through vendors and shared components: a student information system vendor's support portal, an ERP product used across campuses, and a self-spreading worm in the npm registry.
• Safeguard capabilities used in this guide, all GA: TPRM (Third-Party Risk Manager) with vendor SBOM requests and continuous monitoring, SBOM generation and analysis, SCA with deep transitive dependency scanning, vulnerability management with EPSS and CISA KEV enrichment, reachability analysis, policies and gates, license compliance, CSAF and VEX upload, the Compliance and GRC suite with FERPA, GLBA, COPPA and NIST SP 800-171 framework mappings, Trust Center, autonomous remediation (ships switched off, every category set to Manual), the CLI and local runner, and on-prem and air-gapped deployment with Zero AI mode.

The situation

Campuses rarely start this work because someone read a framework. They start because something lands on a desk with a date attached.

For a university it might be a GLBA finding in the annual compliance audit, a student information system renewal with counsel asking what to add to the contract, a Defense award with a CMMC clause, an NIH data use agreement that asks for an attestation, or a vendor email saying student data was taken over the holidays.

For an edtech company it is usually a questionnaire: a HECVAT, a state student data privacy agreement or a long security list, with the deal waiting on the answers. More of those questions now ask what open source the product carries and how fast it is patched.

A bad week looks like this. A widely used open source library gets a critical advisory on Monday. By Tuesday the CISO is asked whether the admissions portal, the financial aid system, the research cluster and the learning platform are affected. The central IT team can answer for its own code after some searching. The research groups each run their own software and answer in different ways, or not at all. Vendors answer slowly. By Friday the honest answer is "we think we are fine", which nobody wants to tell the president's cabinet, a federal program officer or a parent.

The rest of this guide is about turning that answer into "here is the list, here is the status, and here is the evidence".

What software a university and an edtech company actually run

Higher education is unusually decentralised: central IT owns some systems, departments buy their own, and research groups run software central IT has never seen. Edtech companies ship software that becomes part of every school's estate.

Three points follow.

First, central IT's own code is the easiest part to secure and the smallest part of the estate. A plan that covers only that code covers a sliver of the risk.

Second, the systems that carry the most regulated data (the SIS, the ERP and financial aid systems, the LMS) are the ones where the university has the least direct visibility. The lever there is contract terms and vendor process, not scanning.

Third, research computing is the part most programs skip. It holds some of the most sensitive data on campus, runs on fast-moving open source, and is managed by people whose job is science rather than security.

The regulations and frameworks that apply

This section summarises primary sources as they stood on 25 October 2026. It is not legal or regulatory advice. Your counsel, compliance office and research security office decide how each rule applies to your institution or company.

FERPA and the school official exception

The Family Educational Rights and Privacy Act (20 U.S.C. 1232g) and its regulations at 34 CFR Part 99 govern education records at any school that receives funds from Department of Education programs. FERPA does not mention software components. It does three things that bring them into scope.

• The school official exception. Under 34 CFR 99.31(a)(1)(i)(B), a school may treat a contractor, consultant or other outside party as a school official if that party performs a service the school would otherwise use its own staff for, is under the direct control of the school with respect to the use and maintenance of education records, and is subject to the use and redisclosure limits in 99.33(a). Direct control is hard to show for a hosted platform whose components, subprocessors and update practices you have never asked about.
• Reasonable methods. Under 99.31(a)(1)(ii), the school must use reasonable methods to make sure school officials see only the records in which they have a legitimate educational interest. That is an access control duty that applies to vendor systems as well as your own.
• Recordkeeping. Section 99.32 requires a record of requests for and disclosures of education records. You cannot keep that record for systems you have not listed.

FERPA itself sets no breach notification deadline, so state laws and contracts fill the gap, which is why student data privacy agreements carry notice periods.

The GLBA Safeguards Rule for institutions in federal student aid

The FTC's Standards for Safeguarding Customer Information (16 CFR Part 314) apply to colleges and universities because they are financial institutions when they administer federal student aid and other financial products. Federal Student Aid notes that every institution in the Title IV programs has agreed, in its Program Participation Agreement, to comply with the rule, and the Department enforces it through annual compliance audits.

The 2021 amendments, most of which took effect on 9 June 2023, turned general language into specific elements in 314.4. Several of them read like a software supply chain checklist.

• 314.4(b): a written risk assessment that identifies reasonably foreseeable internal and external risks to customer information.
• 314.4(c)(2): an inventory. Identify and manage the data, personnel, devices, systems and facilities that let you achieve your business purposes.
• 314.4(c)(4): secure development and testing. Adopt secure development practices for in-house applications that handle customer information, and procedures for evaluating, assessing or testing the security of externally developed applications you use.
• 314.4(d)(2): testing. Continuous monitoring, or annual penetration testing plus vulnerability assessments at least every six months and whenever there are material changes.
• 314.4(f): service providers. Select providers capable of maintaining appropriate safeguards, require them by contract, and periodically assess them based on the risk they present.
• 314.4(i): an annual written report from the Qualified Individual to the board or a senior officer.
• 314.4(j): notification. Since 13 May 2024, a notification event involving the information of at least 500 consumers must be reported to the FTC as soon as possible and no later than 30 days after discovery.

For a financial aid office this means every system that touches aid data, including the ERP, the document collection portal and any outsourced servicer, belongs in the inventory and in the vendor oversight program.

COPPA for edtech serving children under 13

The FTC's Children's Online Privacy Protection Rule (16 CFR Part 312) applies to operators of websites and online services directed to children under 13, which covers much of K-12 edtech. The amended rule was published on 22 April 2025, took effect on 23 June 2025, and set a compliance date of 22 April 2026 for most provisions.

The amended 312.8 now asks operators to keep a written information security program with a designated coordinator, an annual risk assessment, safeguards that address the risks found, regular testing and an annual evaluation. It also asks operators to take reasonable steps to release children's personal information only to service providers and third parties that can keep it secure, and to obtain written assurances. For an edtech engineering team, the SDKs, analytics libraries and hosted services in the product are where most of those third parties live.

Research security, CUI and controlled-access data

Research universities carry obligations that most companies never see.

• NIST SP 800-171. Contracts that involve controlled unclassified information (CUI) usually require the security requirements in NIST SP 800-171. NIST published Revision 3 in May 2024, superseding Revision 2, but CMMC Level 2 is defined against Revision 2, so check which revision your award names.
• CMMC. The Cybersecurity Maturity Model Certification program rule (32 CFR Part 170) took effect on 16 December 2024, and the Defense acquisition rule that puts CMMC into contracts took effect on 10 November 2025, starting a phased rollout whose second phase begins on 10 November 2026. Universities that perform Defense-funded work with CUI should expect CMMC levels to appear in solicitations.
• NIH controlled-access data. Under NIH notice NOT-OD-24-157, approved users of controlled-access human genomic data attest that the systems used to store and analyse it meet NIST SP 800-171. University research offices report that this applies to new or renewed data use agreements from 25 January 2025.

Inventory, vulnerability scanning and timely flaw remediation are at the centre of 800-171 (requirements 3.4.1, 3.11.2 and 3.14.1 in Revision 2). For a research cluster built from open source, that inventory is a component inventory.

HECVAT, data privacy agreements and other community frameworks

Not every rule comes from a regulator. The EDUCAUSE Higher Education Community Vendor Assessment Toolkit (HECVAT) is the questionnaire many universities send to vendors, and HECVAT 4, released in 2025, folds the earlier Full, Lite and On-Premise versions into one questionnaire. K-12 districts often use state or consortium student data privacy agreements that list required security practices and subprocessor terms. These documents are where software supply chain questions reach edtech companies first.

Federal SBOM guidance as a common language

CISA published its 2026 Minimum Elements for a Software Bill of Materials on 29 July 2026, replacing the 2021 NTIA baseline. Universities are not federal agencies, but the minimum elements give procurement a ready definition of a useful SBOM, in SPDX or CycloneDX.

What the rules have in common

The common duty is the same everywhere: know what you run, know who supplies it, fix what matters on time, and be able to show it.

Real public incidents from the last three years

These incidents are summarised from official statements and government notices. The point is not to judge anyone involved; it is to show where education's software supply chain has actually failed.

PowerSchool, December 2024

PowerSchool, which supplies student information systems to a large share of North American K-12 districts, says it became aware on 28 December 2024 of the exfiltration of personal information from certain customers' SIS environments. Its investigation found that the attacker reached PowerSource, a customer support portal, with a single compromised credential and took the Students and Teachers tables from selected SIS instances. Depending on the person, the data included names, contact details, dates of birth, limited medical alert information and Social Security numbers.

What it shows: the attack path ran through the vendor's own support portal, not through any school's network. A district's direct control over records depends on how the vendor controls that kind of access.

Oracle E-Business Suite, October 2025

On 4 October 2025 Oracle published a security alert for CVE-2025-61882, a remotely exploitable flaw in Oracle E-Business Suite, and CISA added it to the Known Exploited Vulnerabilities catalog on 6 October 2025. Oracle listed versions 12.2.3 through 12.2.14 as affected. E-Business Suite runs finance and HR at many universities, and in October 2025 Harvard said it was aware of reports that university data had been obtained through the flaw, that the incident affected a limited number of parties associated with a small administrative unit, that it had applied Oracle's patch, and that it had no evidence of compromise to other systems.

What it shows: one flaw in a vendor product used across campuses becomes a sector-wide event, and the first question is an inventory question: do we run the affected versions?

XZ Utils, March 2024

On 29 March 2024 CISA warned that malicious code had been inserted into versions 5.6.0 and 5.6.1 of XZ Utils, a compression library found in many Linux distributions (CVE-2024-3094).

What it shows: research clusters and lab workstations that follow fast-moving distributions are exposed to upstream changes that no university reviewed. Knowing which systems run which library versions is the first step to answering the advisory.

The npm worm, September 2025

On 23 September 2025 CISA described a widespread compromise of the npm registry in which a self-replicating worm, publicly known as Shai-Hulud, stole developer credentials and used them to publish altered versions of further packages. CISA urged organisations to review their dependencies, pin versions and rotate credentials.

What it shows: edtech companies and campus web teams build on npm every day. A package that was safe last week can be replaced by a malicious version through a maintainer's stolen token, and lockfiles and dependency inventories decide how quickly you can tell.

What the incidents have in common

In each case the first practical question for a school was exposure: which data, which versions, which systems.

The personas who own the problem

No single person owns this risk at a university; it is spread across roles that rarely meet. An edtech company is smaller, but the same jobs exist. Write the owners down before the next advisory.

If the answer to "who speaks for research computing?" is "each lab", name the person who collects the labs' answers.

Step by step: a 30/60/90-day plan

This plan works with spreadsheets, open source tools and the people you already have. It assumes a mid-sized university or an edtech company with a small security team. Scale the numbers to your size.

Days 1 to 30: see what you have

1. Name the owners. Use the persona table above. Write down one accountable person for central IT systems, research computing, the GLBA program, FERPA vendor terms and procurement. Edtech companies need an owner for product dependencies and one for customer questionnaires.
2. Build the system list from contracts, not only from IT. Start with purchasing records, card spend on software, data privacy agreements and the vendor list in the GLBA program. Departments buy SaaS that never reaches the IT asset list.
3. Tier the vendors. A simple four-tier model works well.

4. Inventory your own code. Generate an SBOM for every repository and container image that central IT, web teams and the research computing group build. Open source generators exist for most ecosystems. Store the SBOMs somewhere you can search.
5. Start with research computing. Ask each research group with regulated data for its environment files (requirements files, conda environments, container definitions). Even a partial picture is better than none.
6. Run one tabletop. Pick a recent advisory and time how long it takes to answer "are we affected?" for one critical system. That time is your baseline.

Days 31 to 60: set terms and gates

1. Send SBOM and disclosure requests to Critical vendors. Ask for SPDX or CycloneDX, a vulnerability disclosure contact, a commitment to tell you about exploited vulnerabilities in a stated time, and VEX or CSAF statements where the vendor uses them.
2. Update contract language. Add software inventory, disclosure and notice terms to the template your counsel uses for data privacy agreements and GLBA service provider contracts. Use the vendor's renewal date as the deadline.
3. Put gates in the pipelines you own. For in-house and edtech code, fail or flag builds that add a component with a known exploited vulnerability or a disallowed license. Start with warnings for two weeks so teams can see what would fail.
4. Rank findings. Use CISA KEV status and EPSS scores to put exploited and likely-exploited issues first. If you can tell whether the vulnerable code is actually called, rank those higher still.
5. Write the exception process. Decide who can accept a risk, for how long, and where the record lives. A finding accepted with a reason and an expiry date is evidence. A finding ignored is not.
6. Edtech companies: build the answer library. Draft standard answers to the software supply chain questions in HECVAT and the privacy agreements you sign most often, backed by real SBOMs and scan records.

Days 61 to 90: prove it and rehearse

1. Map evidence to clauses. For each rule in the table above, list the evidence you now have: inventories, scan records, vendor responses, exceptions, and fix history.
2. Feed the GLBA annual report. The Qualified Individual's report under 314.4(i) should state the inventory coverage, the testing done and the status of provider oversight.
3. Rerun the tabletop. Use a new advisory. Compare the time to answer with the day 1 baseline. Include one research system and one Critical vendor.
4. Set a cadence. Monthly review of Critical vendors, quarterly review of High vendors, and a re-request of SBOMs at each renewal.
5. Publish what you can. Edtech companies can publish a security page that answers the common questions directly.
6. Report. Give the CISO and the cabinet a short page: coverage, top risks, open exceptions and the next quarter's goals.

A same-day checklist for an advisory

• Which of our in-house repositories and images contain the affected component and version?
• Which Critical and High vendors could contain it, and have we asked them?
• Is it in CISA KEV, and what is its EPSS score?
• Does any research system with regulated data run it?
• Who decides, and where do we record the decision?

What about software the research groups build themselves?

Research software is written to produce results, not to be maintained. Treat research systems with regulated data as their own tier. Ask for environment files, scan them on a schedule, and make the research computing team the owner of the answer. Focus on the systems that hold CUI, controlled-access data, student records or protected health information from clinical research.

What should an edtech vendor show a university or district?

A vendor that can hand over a current SBOM in a standard format, a vulnerability disclosure policy, its patch timelines and its record of exceptions can answer most supply chain questions in HECVAT and privacy agreements. A public security page that says the same things saves repeating them in every deal.

How Safeguard does this

The steps above can be done with spreadsheets, open source tools and discipline. Safeguard puts them in one platform. Every capability named below is GA. Commands and screens are described only as Safeguard's documentation shows them; the commands were not run for this article.

1. Tier vendors and request SBOMs in TPRM (GA). Third-Party Risk Manager keeps a vendor directory with contacts, contracts and risk categorisation. From a vendor's page you choose Request SBOM, select the products, pick a request template, set a deadline and send. Bulk requests go to several vendors at once. The standard template asks for SPDX or CycloneDX and lists required fields.
2. Track responses without a spreadsheet. Each request moves through documented statuses: Sent, Viewed, In Progress, Submitted, Validated and Rejected. When an SBOM arrives, TPRM checks its format and completeness, scans it for vulnerabilities and notifies the requester. Vendors' CSAF and VEX documents can be uploaded too (CSAF and VEX upload, GA), so a vendor's "not affected" statement sits next to the component it covers.
3. Monitor Critical vendors continuously. TPRM monitoring watches for new vulnerabilities affecting vendor SBOMs, severity changes and CISA KEV additions, and you can set alerts for the conditions that matter to you. That turns the advisory-week question about SIS and ERP vendors into a list.
4. Build SBOMs for in-house and research code (SBOM generation and analysis, SCA with deep transitive dependency scanning, both GA). Connect repositories and registries from the Integrations page, or scan locally with the CLI (GA). The CLI documentation shows these forms; each takes exactly one target:

# A local directory
safeguard scan --dir .

# A container image
safeguard scan --image myregistry.azurecr.io/myapp:v1

# An SBOM you already have, such as one a vendor sent
safeguard scan --sbom sbom.json

# Check an SBOM or VEX document against its specification
safeguard validate sbom.json --strict -o report.json

Results are written as JSON under ./output by default. Per the docs, safeguard scan does not fail on findings; gating is done by policy gates in the platform.

5. Keep research code on university machines with the local runner (GA). Some research groups cannot grant a cloud service access to repositories near CUI or controlled-access data. The local runner is part of the CLI: you sign in once, and the machine polls the platform for scan jobs. The docs state that it runs each job locally and uploads only the resulting SBOM and findings, never source code, and it works where only outbound HTTPS is allowed.
6. Rank findings so engineers fix what matters (vulnerability management with EPSS and KEV enrichment, reachability analysis, both GA). Findings carry EPSS and KEV context, and reachability analysis ranks the vulnerable code paths your application actually calls. That gives a small campus team a short list instead of a long one.
7. Set release rules with policies and gates (GA). Policies evaluate SBOMs and generate findings; gates enforce them. Each policy's action decides what a failure does: Block fails the gate, Warn passes it with a warning naming the policy, and Notify passes it and sends a notification. Legitimate exceptions go through a documented exception request with a business justification and an expiry date, submitted for approval and decided by approvers, with an audit trail recorded. Policy outcomes are switched on per workspace by Safeguard; with them on, the docs show a CI job failing on a gate like this:

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

License policies (license compliance, GA) can sit in the same gates, which helps edtech teams answer the license questions in district contracts.

8. Open fixes as pull requests (autonomous remediation, GA). Griffin can open tested, policy-gated upgrade pull requests, one repository at a time or in bulk. It ships switched off, with every category set to Manual, so your team decides what runs on its own and what waits for a human.
9. Map the evidence to FERPA, GLBA, COPPA and 800-171 (Compliance and GRC suite, GA). The Compliance suite includes framework pages for FERPA, the GLBA Safeguards Rule, COPPA and NIST SP 800-171. Each lists scan requirements tied to clauses (for FERPA, the school official exception at 99.31(a)(1)(i)(B), reasonable methods at 99.31(a)(1)(ii) and recordkeeping at 99.32; for GLBA, the inventory at 314.4(c)(2) and the risk assessment at 314.4(b); for 800-171, requirements 3.4.1, 3.11.2 and 3.14.1). Each scan of a product checks those requirements against its software inventory. Frameworks are managed under Compliance › Manage. The Compliance frameworks page explains what each kind of coverage means and what the readiness score counts. Treat a passing requirement as evidence for your auditor, not as a finding that you comply.
10. Answer questionnaires from a public page (Trust Center, GA). Edtech companies can publish a Trust Center at their own slug on trust.safeguard.sh, managed under Compliance › Trust Center, showing frameworks, monitored controls, policies, subprocessors and documents. Publishing is always an explicit action, and nothing goes live on its own. A district's reviewer can read the same evidence your sales team would otherwise paste into a questionnaire.
11. Deploy where your data rules require. Safeguard runs as SaaS, in a private VPC, on premises or fully air-gapped (GA). Zero AI mode (GA) runs the platform with no LLM in the loop, and bring your own model (GA) lets a university use a model its review board has already approved.

Requirement versus what Safeguard does versus what you still own

What Safeguard does not do

• It does not patch vendor products. When a vulnerable component lives inside a hosted SIS, an ERP suite or a proctoring service, the fix comes from that vendor. Safeguard helps you find it, track the vendor's answer and record your decision.
• It does not make vendors respond. TPRM sends requests and reminders. Whether a vendor delivers an SBOM depends on your contract and your position at renewal.
• It does not decide FERPA, GLBA or COPPA questions. Whether a vendor qualifies as a school official, whether a notification event occurred, or how parental consent works are decisions for your privacy officer and counsel. A passing check is evidence toward a control, not proof that it is met.
• It does not replace your system security plan or a CMMC assessment. It supplies inventory, scan and remediation evidence that those documents and assessors can use.
• It does not replace incident response, backups or identity security. The PowerSchool case turned on a stolen credential, which calls for a separate program.
• It does not make your institution compliant on its own. Safeguard's own posture is designed for FedRAMP High, and its SOC 2 Type II audit is in progress; neither says anything about your FERPA or GLBA compliance.

Common mistakes

• Starting from the IT asset list alone. Departmental SaaS and research systems are missing from it. Start from contracts, card spend and data privacy agreements.
• Treating research computing as out of scope. Some of the most regulated data on campus sits on clusters built from open source.
• Asking every vendor for everything at once. Requests to hundreds of vendors produce a few files nobody reads. Start with the Critical tier.
• Accepting a PDF of package names. Ask for SPDX or CycloneDX so the SBOM can be loaded and matched against advisories.
• Treating every finding as urgent. Without KEV, EPSS and reachability, the list is too long, and engineers stop listening.
• Leaving the GLBA program in the financial aid office. The Qualified Individual needs IT's inventory and testing records, and IT needs the aid office's vendor list.
• Edtech teams answering questionnaires from memory. Answers drift from reality. Tie each answer to a current SBOM or scan record.

FAQ

Does FERPA require SBOMs from edtech vendors?

Not by name. FERPA's school official exception requires that the school keep direct control over how a vendor uses and maintains education records (34 CFR 99.31(a)(1)(i)(B)). Asking for an SBOM and disclosure terms is one practical way to show that control over the software holding those records.

Does the GLBA Safeguards Rule apply to universities?

Yes, for institutions that take part in federal student aid programs. The FTC treats them as financial institutions under 16 CFR Part 314, and the Department of Education expects compliance as part of program participation and the annual audit.

When must an institution notify the FTC of a breach under GLBA?

Since 13 May 2024, a notification event involving the information of at least 500 consumers must be reported to the FTC as soon as possible and no later than 30 days after discovery. State laws and contracts may set other deadlines.

What changed in the 2025 COPPA amendments for edtech companies?

The amended rule took effect on 23 June 2025 with a compliance date of 22 April 2026. Among other changes, 312.8 now spells out a written information security program and asks operators to obtain written assurances from service providers and third parties that receive children's information.

Does a university research lab need NIST SP 800-171?

Only for systems that handle CUI under a contract or agreement that requires it, or controlled-access data under terms such as NIH's NOT-OD-24-157. The research security office should keep the list of such projects.

What is HECVAT and why does it ask about software components?

HECVAT is the EDUCAUSE questionnaire many universities send to vendors. It asks how vendors develop, test, patch and disclose, because those practices decide how fast a university learns about a problem in a product it depends on.

Which vendors should get SBOM requests first?

The ones whose failure would stop teaching, aid or research, or that hold large volumes of regulated data: typically the SIS, ERP and financial aid systems, the LMS, identity and research CUI systems.

How do we handle a vendor that refuses to provide an SBOM?

Record the refusal in the risk assessment, ask for alternatives (a HECVAT, a vulnerability disclosure policy, CSAF or VEX statements, a third-party assessment), and raise it at renewal. Keeping the vendor is a business decision; the record shows it was made knowingly.

How quickly should we answer "are we affected?" after a major advisory?

No rule sets a number. A useful internal target is a first answer for in-house and research systems, and a status request to Critical vendors, within one business day. Measure your real time in a tabletop.

Most of what this guide asks of a university is about seeing and recording risk in software it buys. For the open source dependencies and container images that campus teams, research groups and edtech companies build and ship themselves, you can also close the gap between a published fix and a deployed one, which is what the next section describes.

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 local runner. You set it up on your own machine, approve it with its device code, and then scan from the terminal. For a research group that cannot connect repositories near CUI or controlled-access data to a cloud service, this is the same flow described in step 5 above.

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, and the user asks it to fix the lodash CVE in a repository. It reads the finding and the 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. The same pattern applies to a campus portal or an edtech product with a vulnerable npm package.

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

Quick check

Related reading

• Higher education software supply chain risk in 2026
• Education sector software security guide
• The PowerSchool breach of December 2024
• FERPA school official exception: an edtech vendor checklist
• HECVAT 4 for edtech vendors
• The Shai-Hulud npm supply chain attack explained
• Higher education research security and export control

Sources

• eCFR: 34 CFR 99.31, disclosure without consent
• eCFR: 16 CFR Part 314, Standards for Safeguarding Customer Information
• eCFR: 16 CFR 312.8, COPPA confidentiality, security and integrity
• Federal Register: Children's Online Privacy Protection Rule, 22 April 2025
• Federal Student Aid: GENERAL-23-09, updates to the GLBA cybersecurity requirements
• Federal Register: CMMC Program final rule, 15 October 2024
• Federal Register: DFARS CMMC acquisition rule, 10 September 2025
• NIST: SP 800-171 Revision 3
• NIH: NOT-OD-24-157
• Emory University research administration: securing NIH controlled-access genomic data
• EDUCAUSE: Higher Education Community Vendor Assessment Toolkit
• CISA: 2026 Minimum Elements for a Software Bill of Materials
• PowerSchool: SIS cybersecurity incident
• Oracle: Security Alert for CVE-2025-61882
• CISA: Known Exploited Vulnerabilities catalog
• The Record: Harvard says limited number linked to data theft
• CISA: Reported supply chain compromise affecting XZ Utils, CVE-2024-3094
• CISA: Widespread supply chain compromise impacting npm ecosystem
• Safeguard docs: Third Party Risk Manager
• Safeguard docs: TPRM SBOM Requests
• Safeguard docs: TPRM Monitoring
• Safeguard docs: Policies and Gates
• Safeguard docs: Policy outcomes and actions
• Safeguard docs: Compliance frameworks
• Safeguard docs: FERPA framework
• Safeguard docs: GLBA framework
• Safeguard docs: COPPA framework
• Safeguard docs: NIST SP 800-171 framework
• Safeguard docs: Trust Center setup
• Safeguard docs: CLI usage
• Safeguard docs: Local Runner

To try the flows in this guide, download Safeguard at https://safeguard.sh/download and read the documentation at https://docs.safeguard.sh/docs .

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