A managed open source agreement should say exactly what is covered, how quickly the provider responds to new vulnerabilities, how advisory data is delivered, what happens at end of life, and how you leave. Vague language on any of these moves risk back to you without telling you.
Scope
List the packages, versions and ecosystems covered, and whether transitive dependencies are included. Ask how new packages are added and how long that takes. If you depend on a package that is not on the list, you need to know on day one.
Response commitments
Look for time targets by severity, measured from a defined starting point such as public disclosure. Be specific about what counts as a response: an advisory, a fix, or a mitigation. A promise of best efforts is not a commitment.
Also ask what happens when no upstream fix exists. A strong answer describes the provider's own patching process and when they will do it.
Advisory data
Ask for machine readable advisories. The OSV schema is one open format for this: it expresses affected ranges and the version in which a fix was introduced, and prefers a fixed marker over a last affected one because the fixed marker names the exact version with the patch. Whatever format is used, the advisory should say whether the fix is a backport or a version bump.
Provenance and verification
Ask how you can check that what you received matches what the provider built. Signed artifacts and published build records are the usual answers. Be wary of promises you cannot verify.
Support lifecycle
State how long each version is supported and how you are notified before it ends. A provider that supports versions upstream has dropped should say so explicitly.
Responsibility and remedy
CISA's Secure by Design guidance calls on producers to take ownership of security outcomes. Reflect that in the contract: what remedy applies when commitments are missed, and what does the provider do after an incident involving its packages?
Exit
- Can you export the packages, build recipes and advisory data?
- Do you get a transition period?
- Are there licence terms that stop you from keeping what you already received?
Practical advice
Ask for a sample advisory and a real changelog before you sign. Map the provider's practices to the NIST Secure Software Development Framework as a shared vocabulary, and note where claims are not backed by evidence.
Safeguard covers the inventory and prioritisation parts of this with SBOM and dependency scanning and reachability analysis, and you can try a free scan at gold.safeguard.sh/scan. Autonomous remediation with fix PRs is off by default, and every category starts on Manual, so a person approves changes.
Quick check
What is the most commonly missing term?
A defined response commitment by severity, with a clear starting point and a clear meaning of response.
Does an SLA replace my own monitoring?
No. You still need your own inventory and checks to confirm what runs and whether fixes are deployed.
Sources
Last reviewed: 19 October 2026.
