An edtech company can start a software supply chain security program in three moves: know what software and vendors you rely on, put basic checks on dependencies and builds, and tie decisions to the student data each system touches. Anchor the work in NIST's SSDF and CISA's Secure by Design principles, and keep scope small.
Why does edtech need its own lens?
Schools and parents hand edtech vendors data about children. In the United States the Family Educational Rights and Privacy Act governs education records, and the Department of Education's student privacy site hosts the regulation text, which covers conditions for disclosure and what counts as directory information. Your own obligations depend on your customers, your state and your product, so ask counsel what applies. For the program, the point is simpler: a vulnerable library in a gradebook or learning app is a student data problem, not only an engineering one.
Edtech is also an unusual shape. Many products are a web app, a mobile app, a pile of integrations with learning management systems and rostering tools, and a long tail of embedded third-party widgets. Each is a supply chain edge.
What do the frameworks give you?
NIST describes the SSDF (SP 800-218) as a set of fundamental, secure software development practices drawn from sources such as BSA, OWASP and SAFECode, noting that few development life cycle models explicitly address software security in detail. It is written so you can pick practices that match your size.
CISA's Secure by Design guidance, updated in October 2023 with international partners, builds on three principles: take ownership of customer security outcomes, embrace radical transparency and accountability, and lead from the top. For a small company the third one matters first. Someone with authority has to own the program, or it becomes a backlog of good intentions.
What does the first ninety days look like?
A constructed example: a ten-person company sells a reading practice app to districts. Nobody can list the third-party libraries in the web app, the mobile app or the grading service. A customer security questionnaire asks, and the answer takes three weeks.
Days 1 to 30: inventory. List every repository, deployable, third-party service and SaaS tool that touches student data. Generate an SBOM per application so you can answer what is in each build. Name one owner.
Days 31 to 60: gates. Add dependency scanning to the pull request check, secrets scanning to the repository, and a rule that production builds come from CI, not laptops. Pin dependencies and commit lockfiles.
Days 61 to 90: vendors and response. Rank vendors by the data they hold and the access they have. Ask the top five for their security documents and incident contacts. Write a one-page runbook for when a library you use is reported as compromised: who checks the SBOM, who decides, who tells customers.
Where does Safeguard fit?
Safeguard offers SBOM and dependency scanning, reachability analysis to separate vulnerable code you call from code you do not, secrets scanning, policy gates for pull requests and a free in-browser scan at gold.safeguard.sh/scan for up to 100 dependencies, which suits a first look on one app. None of that replaces the ownership and vendor work above.
What to do
- Name an owner with authority and report progress to leadership monthly.
- Inventory repositories, apps, integrations and vendors. Mark which touch student data.
- Generate an SBOM for each shipped application and store it with each release.
- Turn on dependency and secrets scanning in pull requests, and commit lockfiles.
- Build releases in CI and restrict who can publish.
- Review the top vendors by data sensitivity and collect incident contacts.
- Write and rehearse a short compromised-dependency runbook.
- Map your practices to SSDF practice groups to see gaps and report to customers.
Quick check
Do I need to adopt the whole SSDF at once?
No. Pick the practices that match your size and risk, document what you do, and extend over time.
What is the first deliverable?
A current inventory with an SBOM per application. Without it you cannot answer customer or incident questions quickly.
Sources
- NIST: Secure Software Development Framework
- CISA: Secure by Design
- U.S. Department of Education: Student Privacy, FERPA
Last reviewed: 18 October 2026.
