Building VulnOps: From Vulnerability Detection to Remediation

How I approached the operational gap between finding vulnerabilities and reliably closing them.

These are notes from problems I have actually wrestled with in vulnerability operations, not a claim that every feature is solved or that every customer has the same environment. I built VulnOps because the everyday work between finding a vulnerability and closing it deserved better tools.

The part no scanner shows

The problem that pushed me to build VulnOps was not a shortage of vulnerability data. It was the same argument happening again and again: who owns this finding, who is doing the remediation, and why has nothing moved since last week? My manager and colleagues were struggling to distribute work among engineers and track whether anything had actually been done. We had Tenable, Intune, SCCM and Patch My PC in the picture, but none of them gave us the one operational view I wanted. We were still hoping that the next monthly patch cycle would clear a large chunk of the backlog. Hope is a terrible ticketing system.

My old workflow involved too much chasing

We would look at the findings in Tenable, export the data, split work between engineers and then chase for updates. Some people replied. Others did not. Some wanted to help but did not know how to remediate the finding safely. The status of the work lived in conversations as much as it lived in our tools. It was frustrating for engineers who actually completed their tasks too, because a finished fix could disappear into a spreadsheet until somebody manually checked it. I did not want to design a system that simply scolded people for being slow. I wanted a system that gave them enough context to act and made ownership visible.

Why I built instead of bought

I looked at existing products, and some were good at scanning, some at patch distribution and others at service management. For my MSP and MSSP use case, the combination I needed was either missing, expensive or difficult to integrate. I had studied computer science engineering and had worked with PowerShell, cloud administration and security operations. AI-assisted development helped me move faster, but I still had to decide which ideas belonged in the product and which outputs were unsafe assumptions. My first experiments were a vulnerability matrix, a Tenable CSV upload and script generation. The difficult part was making those three things describe the same finding coherently.

When it stopped feeling like a personal project

The moment that mattered most was bringing VulnOps into my office environment and seeing other people use it. Engineers and colleagues responded positively, and the platform was also hosted internally for a client. That did not mean the software was suddenly perfect. It meant I could watch someone else follow the workflow without explaining every decision myself. That was a different kind of satisfaction from getting a page to render on my laptop. The next challenge was turning positive feedback into a disciplined cycle of review, validation and improvement.

Why I built a remediation platform

Vulnerability operations rarely fail because scanners cannot identify a missing patch. They fail in the space between a finding and a safe, verified production change. A Tenable result may contain a plugin identifier, severity, affected software and remediation guidance, but an engineer still needs to establish scope, understand application dependencies, select a deployment method, arrange an approval and collect evidence that the exposure has gone. Multiply those decisions across thousands of findings and the administrative work becomes its own security problem. I built VulnOps to organise that process around an actionable remediation lifecycle rather than another dashboard of red numbers. Its central idea is straightforward: a scanner finds exposure; an engineering workflow turns that finding into a controlled, testable fix. Automation should remove repetitive effort, not bypass an operator's judgement.

Stage one: ingest and normalise

The first stage accepts vulnerability definitions from a live Tenable API integration or a Nessus-style CSV export. Ingestion has to handle inconsistent naming, optional fields and repeated plugin identifiers without mistaking every line for a unique engineering task. In the product workflow, findings are deduplicated by plugin ID within a tenant. An illustrative data set of 2,847 raw findings might reduce to 106 distinct plugin types requiring investigation. That figure illustrates the benefit of grouping, not 2,741 vulnerabilities magically fixed. A plugin affecting a domain controller and the same plugin affecting a disposable workstation may still need different priorities and rollout strategies. I keep those distinctions in the scanner or deployment context rather than treating deduplication as evidence of universal applicability. The platform's stated data-minimisation approach is to retain vulnerability definitions, not asset inventories with hostnames and network maps.

Stage two: classify before generating

A recommendation to update software is not enough information to construct a safe change. VulnOps uses eight built-in remediation patterns, including registry changes, software updates and service hardening, with scope for tenant-specific patterns. Classification determines which preconditions and recovery actions the generator should consider. For a registry-based mitigation, the candidate needs to read the original values, preserve whether each key existed and create a repeatable detection test. For a software upgrade, it needs version detection, approved download or package provenance, silent-install behaviour and a check that the desired version was actually installed. Some findings require manual assessment or compensating controls instead of scripting. A classification error should result in review, not a forced fit into the closest-looking automation template.

Stage three: generate detection, remediation and rollback

For an automatable finding, the engineering output is a trio: Detect.ps1, Remediate.ps1 and Rollback.ps1. Detection establishes whether a target is already compliant. Remediation makes the approved change, using defined exit codes, structured logging, protected backups and exception handling. Rollback attempts to return the relevant settings or package state to a known prior condition. These files are designed around Microsoft Intune Remediations conventions, but their behaviour still depends on execution identity, architecture, permissions and the endpoint's actual state. It is tempting to generate one generic PowerShell script and call the task finished. A more defensible design treats script generation as a proposed change. The script must explain its assumptions, expected side effects, restart requirements and the evidence needed to confirm success.

Stages four to six: validate, track and deploy

Static checks are a necessary barrier against obvious scripting mistakes: missing exit paths, destructive operations without backups, absent logs and commands that cannot run unattended. VulnOps presents pass, warn and fail gates, and a failing candidate should return for revision. Static analysis cannot prove that an MSI installer will behave correctly on an application server. That requires testing with representative versions, configuration and dependencies. After validation, an engineer can assign ownership, document blockers, obtain approval and track the finding through a nine-step operational workflow. The platform describes an Intune deployment integration that can publish remediation packages; authorisation and rollout rings must still govern when those packages run. Deployment should be observable and reversible, with endpoint outcomes returned to the tracking process rather than inferred from the presence of a script in the console.

Measure closure, not generated output

A scan timestamp does not prove a fix happened, and an installer's zero exit code does not prove the vulnerable component disappeared. Good evidence combines state measurements, the remediation execution log and a subsequent independent scan when one is available. Useful metrics include median time to validated remediation, re-opened findings, failed rollbacks, exception age and the share of changes requiring human intervention. VulnOps also explores MITRE ATT&CK mapping to highlight plausible sequences of weaknesses. Such a chain is a prioritisation hypothesis, not proof that a particular attacker can traverse an environment. The biggest lesson of building the platform is that security automation needs a chain of accountability just as much as it needs code. A controlled workflow can make engineers faster without making a mistake faster too.

Engineering review checklist

Before using this approach in production, document the affected versions, prerequisite access, approval owner, intended change, test evidence, rollback limitations and independent validation criteria. Revisit the outcome after the next scan cycle. These checks help distinguish a successful script execution from a defensible security decision and prevent an incomplete change from being reported as closed.