An intake SLA for dependencies is a written promise about how fast a developer gets a yes, a no, or a conditional yes after asking to add a package. It exists so that a slow review never pushes engineers to install things directly from the public registry.
Why the clock matters more than the checklist
Most teams already have a review checklist. What they lack is a deadline. Without one, a request sits in a queue, the developer has a feature to ship, and the quickest route is to run the install command against the public registry from a laptop. Your mirror and your gates are then bypassed by the people who were trying to be careful.
An SLA turns review into a service. It also gives security a number to staff against, which is more honest than "we look at them when we can".
What the SLA should contain
Keep it to one page. Four things belong on it.
- A response time per lane. The time to first decision, not the time to finish every check.
- A definition of the clock. It starts when the request is complete, and it pauses only when the security team is waiting on the requester.
- A default on timeout. What happens if nobody answers in time.
- An escalation name. A role, not a person, who can break a tie.
Match the response time to the risk
Not every request deserves the same effort. A tiered table keeps the fast cases fast.
| Lane | Typical request | What review checks | Response target |
|---|---|---|---|
| Pre-approved | Version bump of a package already on the list | Automated scan and policy gate only | Minutes, no human |
| Standard | New package from a known ecosystem, no install scripts | Maintainer history, license, advisories, scan result | Same business day or next |
| Elevated | Native code, install scripts, network access at install | Everything above plus source skim of the install path | A few business days |
| Exception | Package that fails a policy | Written risk acceptance with an expiry | Decided by the named owner |
The numbers in the last column are yours to set. Pick figures you can actually meet, publish them, and measure against them. A promise of one hour that is missed every week teaches people to ignore it.
Decide the timeout default before you need it
When the clock runs out, one of three things happens. Each is a defensible policy, and each has a cost.
- Default allow with a flag. Developers keep moving, and the package is marked for review. Fast, but the risk lands before the check does.
- Default deny. Safe, and the most likely to trigger workarounds.
- Auto escalate. The request jumps to the named owner. This is usually a good balance for the standard lane.
Whichever you choose, write it down.
Keep the SLA honest
Publish the actual numbers each month: median time to decision per lane, and the count of requests past target. If the elevated lane keeps missing, either staff it or narrow what falls into it. A related post on what to measure in an intake queue goes deeper on the metrics.
Where Safeguard fits
Safeguard's policies and gates can automate the pre-approved lane by checking each new version against your rules, and its dependency scanning supplies the evidence a reviewer needs for the standard lane. You can try it on one repository with the free scan.
Quick check
Is an intake SLA the same as a service level in a vendor contract?
No. It is an internal commitment between the team that reviews dependencies and the developers who request them. It has no penalties, but it should be tracked and reported like any other service.
Should the SLA cover emergency security patches?
Give those their own lane with a much shorter target, since a patch for a known vulnerability should not wait behind new feature requests.
Who should own the SLA?
Whoever staffs the review queue, usually platform engineering or application security, with a named escalation role above them.
Last reviewed: 19 October 2026.
