This Is Why I Founded trackd
Today, we’re releasing something we’re calling AutoPilot (only because we couldn’t think of anything more clever). At first glance, it’s a basic upgrade to our auto-patching rules engine, offering an additional variable for IT operators to account for when determining whether or not to designate a patch for auto-update.
trackd Releases First Ever Vulnerability Remediation Rules Engine that Leverages Historical Patch Disruption Data
AutoPilot leverages patch disruption data that no other vulnerability scanning or patching product has. When a user applies a patch with trackd’s platform, trackd records whether or not that patch caused a disruption, so trackd has an ever-expanding database of applied patches and their disruption histories.
Wrestling with “Vulnerability Management”
Just as there’s no reason to make weight if you’re not going to wrestle, there’s no reason to scan for and identify vulnerabilities if you’re not going to patch them.
CPE Data and False Positives in Vulnerability Management
The problem of false positives in vulnerability management can largely be attributed to the use of CPE (Common Platform Enumeration) data in the correlation process, a critical first step in vulnerability management.
A Faster Horse
Today, those in vulnerability management often create development environments (aka sandboxes) to test whether or not new patches will cause disruptions on their networks…just like they’ve been doing for 3 decades. Which leads to only one conclusion: ARPA-H is funding an effort to build a faster horse.
Why Existing Vulnerability Management Solutions Aren’t Working
The vulnerability management market answers every question a practitioner or cybersecurity professional could want answered…except the only one that matters: will this patch break my shit.
If it Ain’t Breaking Stuff, Fix It
Tell us when patches are disruptive? Sure. But more importantly, let us know when they’re not, information that’s potentially much more actionable.
