Notifications
Clear all
Topic starter
19/08/2026 3:50 pm
TL;DR: As AI-driven offensive speed compresses exploitation windows to under 24 hours, vulnerability operations, or VulnOps, is the operating layer security teams need, according to Pixee. The shift matters because triage, fix generation, and auditability now have to run as one continuous pipeline, not separate queues.
NHIMG editorial — based on content published by Pixee: VulnOps: The Operational Playbook for Mythos-Ready Security Programs
By the numbers:
- The window between vulnerability disclosure and confirmed exploitation has compressed from 2.3 years in 2018 to under 24 hours in 2026.
- Ponemon Institute reports that 66% of organisations carry 100,000 or more open vulnerabilities.
- Veracode's State of Software Security 2025 reports a 252-day average time to remediate critical flaws.
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 do scanner severity disagreements become a governance problem at scale?
A: Because analysts spend time translating risk between tools instead of remediating what matters.
Q: What breaks when organisations rely on generic AI fixes for vulnerabilities?
A: Generic fixes often fail codebase conventions, introduce unfamiliar dependencies, or break tests.
Practitioner guidance
- Implement a single intake queue for all findings Normalise SAST, SCA, container, and IaC findings into one prioritisation model so analysts do not reconcile severity across tools by hand.
- Measure validated remediation, not patch volume Track how many fixes pass tests and merge with minimal edits, because raw PR counts do not show whether remediation is operationally usable.
- Bind machine-generated fixes to approval controls Require identity-bound approval, exception handling, and merge rights for automated remediation so machine actions remain accountable and reviewable.
What's in the full article
Pixee's full whitepaper covers the operational detail this post intentionally leaves for the source:
- The full VulnOps operating model, including how Pixee structures triage, fix generation, and disposition tracking.
- Examples of validated remediation workflows for SAST and SCA findings that merge cleanly into engineering pipelines.
- The paper's priority actions in full, including the governance and resolution categories not expanded here.
- Methodology notes on merge-rate measurement and how the program evaluates machine-generated fixes.
👉 Read Pixee's VulnOps whitepaper on machine-speed remediation and security operations →
VulnOps and machine-speed remediation: what should teams change now?
Explore further
19/08/2026 4:26 pm
VulnOps is becoming the governance layer that AppSec never had. Traditional vulnerability management assumes findings can be queued, reviewed, and fixed in a relatively stable cadence. That assumption fails once offensive AI compresses the time-to-exploit window into hours. The field now needs a control layer that can normalise findings, validate remediations, and preserve auditability at the same speed as discovery.
A question worth separating out:
Q: Who is accountable when machine-generated remediation changes a codebase?
A: The organisation remains accountable through the identities and roles that approve, review, and merge the change. Machine assistance does not remove the need for ownership, exception handling, and audit trails. If a team cannot trace who authorised the fix, the control model is incomplete.
👉 Read our full editorial: VulnOps is becoming the operating layer for machine-speed defense
