Notifications
Clear all
Topic starter
19/08/2026 3:43 pm
TL;DR: VulnOps reframes AppSec as a resolution discipline, not just a detection pipeline, by treating vulnerability intake, triage, fix generation, and auditable merge decisions as one operating layer, according to Pixee. The practical implication is that backlog pressure now depends less on scanner volume than on how quickly teams can disposition findings and get validated fixes merged.
NHIMG editorial — based on content published by Pixee: What Is VulnOps? Vulnerability Operations, Defined
By the numbers:
- The average time to close a flaw has risen 47% over five years, reaching 252 days industry-wide.
- A typical application generates about 17 new vulnerabilities a month while teams remediate roughly 6.
- The average company carries 795 critical findings out of 865,398 total alerts.
Questions worth separating out
Q: How should security teams implement VulnOps without creating another noisy workflow?
A: Start by normalising findings into a single severity and exploitability model, then define one disposition path for dropped, deferred, fixed, and escalated issues.
Q: Why does remediation capacity matter more than scanner coverage?
A: Scanner coverage only tells you what exists; remediation capacity determines whether known issues are actually reduced before attackers can use them.
Q: What do security teams get wrong about vulnerability remediation automation?
A: They often automate ticket creation but not end-to-end closure.
Practitioner guidance
- Map every finding to one disposition path Define a single, audited path for findings that are dropped, deferred, fixed, or escalated so scanners do not create parallel queues.
- Measure remediation throughput against intake Track how many findings arrive per week versus how many are validated and merged in the same period.
- Keep human approval at the merge checkpoint Allow automation to draft fixes, run tests, and prepare pull requests, but require human review before merge for any change that affects production code paths or compensating controls.
What's in the full article
Pixee's full article covers the operational detail this post intentionally leaves for the source:
- The full definition boundaries between VulnOps, vulnerability management, ASPM, DevSecOps, and SOC/SOAR workflows.
- The five-step operating model for intake, triage, fix generation, audit logging, and human merge authority.
- The article's own examples of how machine-generated remediation is validated against codebase conventions.
- The broader rationale for why the function is emerging now, including the find-versus-fix backlog problem.
👉 Read Pixee's full explanation of what VulnOps means for AppSec operations →
VulnOps and the remediation backlog: what teams need now?
Explore further
19/08/2026 4:21 pm
VulnOps is the missing governance layer between detection and remediation. AppSec programmes often invest heavily in finding flaws, then rely on fragmented human workflows to decide what happens next. That split creates a control gap because resolution is where risk is actually reduced. For identity programmes, the parallel is obvious: discovery without lifecycle action does not govern access, and vulnerability discovery without governed remediation does not govern code.
A question worth separating out:
Q: How do organisations know if a VulnOps function is actually working?
A: Look for three signs: findings are normalised into one queue, triage outcomes are recorded consistently, and validated fixes are merged faster than new vulnerabilities arrive. If any of those signals is missing, the function is still a reporting layer rather than a true resolution capability.
👉 Read our full editorial: VulnOps is emerging as the missing resolution layer in AppSec
