Five common beliefs about dependencies in student data software are shaky: that small vendors are too minor to matter, that a lockfile equals security, that the school carries the risk, that all findings deserve equal effort, and that hygiene is a one time project. Each has a more useful version.
Myth 1: "We are too small to matter"
Fact: Open source libraries are shared by projects of every size, and a flaw in one affects everyone who uses it, not only large targets. CISA notes that a relatively small number of vendors serve thousands of districts, so vendors of any size can sit behind many schools. We do not have a figure for how often small vendors are hit, so avoid guessing. Plan for the likelihood that your code is someone's concern.
Myth 2: "A lockfile makes us secure"
Fact: A lockfile makes builds repeatable. The npm documentation describes it as recording the exact tree so later installs reproduce it. That also freezes any known flaws in that tree. You still need to scan it and update on purpose.
Myth 3: "The school is responsible for security, not us"
Fact: CISA argues that responsibility should shift upstream to vendors, and the FTC's staff guidance says operators should not state in terms of service that the school is responsible for COPPA compliance, since the operator carries it. Contracts and laws vary, so check yours with counsel, but do not assume the risk sits entirely with the district.
Myth 4: "Every finding needs a fix this week"
Fact: Scanners list every known flaw in every package. Fixing in order of use and exposure, with reasons recorded for the rest, is a sound approach. A flaw in a package your code never calls is not equal to one on your upload path.
| Finding | Likely priority |
|---|---|
| Reachable, touches student records | High |
| Present, not reachable | Plan and monitor |
| Dev tool only | Next batch |
Myth 5: "We cleaned it up last term, so we are done"
Fact: New advisories appear every week against versions you already run. Dependabot's own model is continuous: pull requests keep arriving as new releases appear. A one time cleanup ages quickly. A weekly thirty minute routine beats an annual marathon.
What to do with this
- Generate an inventory today, if you do not have one.
- Name an owner.
- Pick a weekly slot.
- Write your urgent rule.
- Review it each term.
Try it yourself
Open the demo and see how continuous checking differs from a one time scan.
Click through it at your own pace, or open it full screen.
Quick check
Where should a team with almost no time start?
Get an inventory, remove unused packages, and set a weekly thirty minute review. Those three steps cost little and remove the most guesswork.
Do these myths apply to schools as buyers?
Yes. Schools sometimes assume a signed agreement settles security. Asking about practices adds real information beyond the contract.
Safeguard offers dependency scanning, reachability analysis, and continuous monitoring, and the free scan is a no-cost first step.
Sources
- Findings and updates on CISA's collaboration with education technology vendors
- package-lock.json (npm Docs)
- Complying with COPPA: Frequently Asked Questions (FTC)
- About Dependabot version updates (GitHub Docs)
Last reviewed: 19 October 2026.
