Without a security team, split the job into three light roles: a weekly triager who reads new alerts, repository owners who fix what is assigned, and one person who approves exceptions. In a team of three these can be the same people wearing different hats, as long as the roles are written down.
The problem with "everyone owns it"
When everyone owns security, alerts sit unread because each person assumes someone else looked. A named owner does not need to be an expert. They need a time slot and the authority to assign work.
The three roles
| Role | Does | Time per week |
|---|---|---|
| Triager | Reads new alerts, checks the exploited list, assigns each item | About 30 minutes |
| Repository owner | Fixes or upgrades, reports back | Varies, usually under an hour per repo |
| Exception approver | Signs off on anything deferred past its date | A few minutes |
Rotate the triager every month or every quarter so knowledge spreads and nobody gets resentful.
What the triager actually decides
For each new item the triager answers three questions. Is it exploited in the wild? CISA's catalog is the free reference for that. Is the affected package in production and exposed? And is a fixed version available? Then the item is assigned, deferred with a date, or closed with a reason. That is all.
Give owners a clear target
State a simple rule that people can follow without a meeting, such as "exploited and exposed this week, everything else within the month". The deadline numbers are your choice. NIST's patch management guide stresses that business and technology owners often disagree on how much patching is worth, so agree the rule in advance, once, while nothing is on fire.
Write it on one page
Put the roles, the rule and the place where alerts live on a single page in your repository. New hires then read it on day one. If you use a platform with a person directory, list the triager there too.
When to bring in outside help
Bring someone in when you have regulatory commitments, a customer demanding evidence you cannot produce, or an exploited finding you cannot assess alone.
Quick check
Can the founder be the triager?
Yes at the start. Hand it over once the team grows, because founders are the worst at protecting 30 minutes a week.
Do we need a separate security tool for this?
Not to begin. Alerts from your code host plus the exploited list are enough for a small estate. A tool helps when the number of repositories grows.
Safeguard policies, gates and compliance evidence automation can record who approved what, and the free scan at gold.safeguard.sh/scan is a low-effort way to see your current state.
Sources
- NIST SP 800-40 Rev. 4, Guide to Enterprise Patch Management Planning
- CISA Known Exploited Vulnerabilities Catalog
Last reviewed: 19 October 2026.
