FERPA does not name open source libraries, but it does protect personally identifiable information from education records. Any package that can read, log, or transmit that data sits inside your risk. Treat your dependency list as part of how you protect student records, and keep it current. This is general information, not legal advice.
What FERPA protects
The U.S. Department of Education's student privacy site describes FERPA as giving parents access to their children's education records, the ability to ask for changes, and some control over disclosure of personally identifiable information from those records. When a student turns 18 or enters a postsecondary institution at any age, those rights pass to the student, who becomes an "eligible student." The statute is 20 U.S.C. 1232g and the regulations are at 34 CFR Part 99.
Notice what the law is about: records and disclosure. It says nothing about npm, Maven, or PyPI. The link to your code is indirect but real.
Where dependencies touch student records
A library is not a vendor, but it runs with the same permissions as the rest of your app. If your app can read a grade, so can the code in a logging helper, a PDF generator, or an analytics package.
| Dependency role | What it can see | Question to ask |
|---|---|---|
| Web framework and auth libraries | Sessions, names, IDs | Is it on a supported version? |
| PDF, CSV, and report tools | Full record exports | Does it run on untrusted input? |
| Logging and error tracking | Request bodies, stack traces | Do logs ever contain student fields? |
| Analytics and tag scripts | Page URLs, identifiers | Do URLs carry student IDs? |
| Image and file parsers | Uploaded files | Is it patched for known flaws? |
What schools will expect from you
Schools that share records with a vendor usually want to know how the vendor protects them. Expect questions about patching, access control, and subcontractors. The Department's vendor page says its resources exist to help vendors "ensure they are properly handling FERPA-protected information," and lists webinars on incident response and breaches involving third parties and partner organizations. Your dependency practices are part of a credible answer.
Whether a given vendor arrangement fits a FERPA exception is a legal question for your counsel and your school customers. The practical part is yours: know what code you ship.
A short plan
- Generate an inventory of direct and transitive dependencies for every service that handles student data.
- Mark the packages that touch records, exports, logs, or outbound requests.
- Check those first for known vulnerabilities and end of life versions.
- Remove packages you no longer need. Fewer packages means fewer places for records to leak.
- Write down who reviews the list and how often, so you can answer a school's question with a date.
Try it yourself
Open the demo and look at how a dependency inventory separates direct packages from transitive ones, then think about which of them would see student data in your app.
Click through it at your own pace, or open it full screen.
Safeguard offers SBOM and dependency scanning, and you can run a free scan on a repository to see an inventory for yourself.
Quick check
Does FERPA require a software bill of materials?
Nothing in the FERPA pages we reviewed mentions one. A school customer might still ask for an inventory as part of vendor review, so having one ready helps.
Is a vulnerable library a FERPA violation by itself?
FERPA concerns disclosure of education records. A vulnerability is a risk, not a disclosure. If it leads to unauthorized access, your counsel and your school customers will decide what follows.
Sources
- What is FERPA? (U.S. Department of Education, Student Privacy Policy Office)
- Education Technology Vendors resources (Student Privacy Policy Office)
Last reviewed: 19 October 2026.
