An agency should treat each client as a separate owner with a shared policy. Assign a named engineer per client, apply one set of fix windows to all of them, group the same advisory across clients, and send a short monthly report. Agree in the contract who pays for upgrades.
Why agencies have a different problem
An agency may have a small team and dozens of client codebases, each at a different age, framework, and hosting arrangement. Alerts arrive from many places and belong to many clients. Unlike a product company, the agency does not always control when a client approves a release.
So the work splits in two: noticing the alert, which is the agency's job, and deploying the fix, which may need client sign-off.
A workable structure
- One owner per client. A named engineer, with a backup. GitHub's documentation notes alerts can be assigned to collaborators or teams and filtered by assignee, which makes a per-client view simple.
- One shared policy. Same windows for every client, adjusted by whether the site holds customer data or is a brochure page.
- One cross-client view. When an advisory affects a common library, find every client that uses it in a single pass.
- A client report. Monthly, one page: what was found, what was fixed, what needs approval.
The shared policy table
| Client type | Known exploited issue | Reachable issue | Other |
|---|---|---|---|
| Handles customer data | Fix this week | Fix this month | Next maintenance |
| Marketing site, no data | Fix this month | Next maintenance | Next maintenance |
| Archived, no traffic | Decide to retire or fix | Retire | Retire |
The first column follows CISA's guidance that all organizations prioritize remediation of vulnerabilities in the Known Exploited Vulnerabilities catalog. The other columns are suggestions for you to adapt.
Contract language that helps
This is not legal advice. Raise these points with your own counsel and your client:
- Who pays for dependency upgrades and emergency patches.
- How quickly the client must approve security changes.
- What the agency does if the client declines.
Having these written down turns an awkward conversation into a lookup.
Cut noise per client
Agencies feel alert noise sharply because the volume multiplies. GitHub documents that auto-triage rules run before notifications, that you can opt into a weekly digest, and that auto-dismissed alerts remain visible and can be reopened. A digest per client repository, sent to the client's owner, fits this work.
Retire dead projects. GitHub notes it does not scan archived repositories, so an abandoned client site left unarchived will keep generating alerts, while an archived one stops, which may hide a live production site. Decide deliberately which applies.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how an inventory lets you ask which projects use a given package.
Safeguard's SBOM and dependency scanning and reachability analysis can help answer that cross-client question, and the free scan at gold.safeguard.sh/scan lets you test one client's repository.
Quick check
Who is responsible when a client refuses an upgrade?
That should be settled in your agreement with the client. Record the refusal, the risk you explained, and the date.
Should clients see raw alert lists?
Usually no. A short summary with decisions needed is more useful than a feed.
Sources
- CISA, Reducing the Significant Risk of Known Exploited Vulnerabilities
- GitHub Docs, About Dependabot alerts
- GitHub Docs, Dependabot auto-triage rules
Last reviewed: 19 October 2026.
