Ask the vendor how it inventories open source code, how it handles vulnerabilities, what third parties receive student data, and how it will tell you about problems. Good answers are specific and dated. Vague answers are a signal to ask a follow up question. This is a checklist for informed conversation, not legal advice.
Why districts should ask
CISA's K-12 acquisition guidance exists to help schools buy products that are Secure by Design, and CISA presents its points as considerations districts can raise during procurement. A short set of dependency questions fits right into that conversation.
The checklist
- Do you keep an inventory of the open source and third party components in the product? Good: yes, generated on each build, reviewed on a schedule. Weak: "we use only trusted libraries."
- Can you provide a software bill of materials? Good: yes or "under NDA," with the format named. Weak: no answer.
- How do you find out when a component has a known vulnerability? Good: automated scanning plus a named owner. Weak: "we check sometimes."
- How do you decide what to fix first? Good: a rule that considers whether the code is used and whether student data is involved.
- How will you tell us if a flaw affects our data? Good: a named channel, contact roles, and a rough timeline for first notice.
- Which outside services receive student data? Good: a current list you can share, and a rule that changes are disclosed.
- Do the mobile apps or web pages include third party SDKs or scripts that collect data? Good: a list and a statement of purpose. FTC staff guidance holds operators of child-directed services responsible for what third parties collect on their property.
- What happens to end of life components? Good: a documented policy for replacing or isolating them.
- How can researchers report a vulnerability to you? Good: a monitored contact and a stated process.
- Do you align your development process to a recognized framework? Good: names it, such as NIST SP 800-218, and describes what that means in practice, without claiming certification.
How to read the answers
| Pattern | What it suggests |
|---|---|
| Specific nouns, dates, roles | The team knows its own system |
| Adjectives and slogans | Ask for an example |
| "We are working on it" with a date | Honest, and worth tracking |
| Refusal to say anything | Escalate or reconsider |
What not to expect
No vendor has zero vulnerabilities. A realistic goal is a vendor that finds problems quickly, fixes them in a sensible order, and tells you plainly. Also, be aware that a framework alignment statement is not an audit, and a signed pledge is not proof of practice.
Put it in the agreement
Where your contract allows, reference the practices the vendor described, so the answers carry weight. Ask your counsel how to word it.
Re-ask yearly
Vendors change code, owners, and providers. Repeat the key questions at renewal.
Try it yourself
Open the demo and look at the kind of component and policy evidence a vendor could show you.
Click through it at your own pace, or open it full screen.
Quick check
Is an SBOM request reasonable for a small vendor?
Yes, though a small vendor may share it under an NDA or in summary form. Ask what format they can provide.
Does a framework statement replace an audit?
No. Alignment to a framework describes practices. An audit is an independent assessment. Ask which one the vendor means.
Safeguard works with the vendor side of this conversation, with SBOM generation, dependency scanning, and compliance evidence automation.
Sources
- Cybersecurity Guidance for K-12 Technology Acquisitions (CISA)
- Complying with COPPA: Frequently Asked Questions (FTC)
- NIST SP 800-218, SSDF Version 1.1
Last reviewed: 19 October 2026.
