Who owns what: vulnerability management, SCA and ASPM in your org

Security usually owns the vulnerability management policy, AppSec owns the SCA and ASPM tooling and triage rules, and engineering owns the fixes. Problems start when one group is assumed to own all three, or when nobody owns the handoffs between them.

Why ownership matters more than tooling

Most stalled programs have decent scanners. What they lack is a clear answer to "whose job is this finding?" NIST's patch management publication notes that business and mission owners often disagree with security and technology managers about how much patching is worth. Naming owners up front reduces that friction because the argument happens once, in policy, instead of once per ticket.

A starting ownership map

Treat this as a template. In a small company one person may hold three rows. That is fine as long as the roles are written down separately.

The handoffs that break

Detection to triage. SCA finds something. Who looks first? Agree on a first responder, often AppSec, and a time limit.

Triage to ticket. Once a finding is confirmed relevant, it needs to land in the team's own tracker, tagged with the service and a deadline. Do not ask developers to log into a security tool to find their work.

Ticket to fix. The service owner decides how to fix, such as upgrade, replace or mitigate. Security reviews only if the fix changes the risk.

Fix to verification. A rescan, not a developer's word, closes the finding.

Exception to expiry. Every accepted risk needs an end date and a named approver. When it expires, it returns to the queue.

Questions to settle in a 30 minute meeting

1. Who is the first responder for a new critical finding?
2. What is the deadline for a critical, high and medium finding, and does it differ by exposure?
3. Who can approve an exception, and for how long?
4. Where do tickets live?
5. Who reports numbers upward, and which numbers?

Write the answers on one page. If you need a framework to anchor the policy, NIST SP 800-218, the Secure Software Development Framework, offers a shared vocabulary of secure development practices that producers and buyers can both use.

What to avoid

• Making developers responsible for tuning scanner rules. They will tune for silence.
• Making security responsible for writing fixes. They lack the context and will become a bottleneck.
• Letting ASPM become a second place where ownership is decided. It should reflect your org chart, not invent one.

A worked example

A 60 person company has one security lead, one AppSec engineer and six product teams. Here is how the map plays out when a new advisory arrives.

1. The AppSec engineer sees the alert, confirms the affected versions from the maintainer notice and checks the inventory. Three services use the component.
2. The security lead checks policy: the vulnerability is on the CISA Known Exploited Vulnerabilities list, so the shortest deadline applies.
3. The AppSec engineer opens tickets in each team's tracker with the deadline, fixed version and verification step.
4. Each service owner schedules the upgrade, merges it and deploys.
5. The AppSec engineer rescans and closes the findings. One team asks for an extension, so the security lead approves a short exception with an expiry date.
6. The security lead reports time to fix at the monthly review.

Nobody was confused about who does what, because the map was written before the advisory.

Step by step: write your own map

1. List the decisions. Examples: what is the deadline, who approves exceptions, which tools are allowed, which findings block a merge.
2. List the actions. Examples: run scans, triage, create tickets, fix, verify, report.
3. Assign one accountable person or role per item. Shared accountability means no accountability.
4. Record who must be consulted. For example, the service owner for any exception.
5. Publish it where developers can find it, such as the repository wiki.
6. Review it every quarter or after any reorganization.

Where the map tends to need adjusting

Signals that ownership is unclear

• Findings are discussed in meetings but no ticket exists.
• Two teams each assume the other will fix a shared library.
• Exceptions are granted in chat with no record.
• Nobody can say who changed a scanner rule last month.

If you see two or more of these, run the 30 minute meeting described above before changing any tools.

Try it yourself

Follow one finding from detection to closure and note where a person or a policy takes over.

Click through it at your own pace, or open it full screen.

Where Safeguard fits

Safeguard supports this split with policies and gates that encode the rules AppSec sets, dependency scanning for the findings, and fix pull requests (off by default) so engineering reviews a proposed change rather than starting from scratch. Try a free scan at gold.safeguard.sh/scan.

Quick check

Sources

• NIST SP 800-40 Rev. 4, enterprise patch management
• NIST SP 800-218, Secure Software Development Framework

Last reviewed: 19 October 2026.