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.
But, at its core, AutoPilot leverages data that only trackd has. I know vendors say this all the time, and I’m the chief skeptic of such boasts, but trust me, no one else is collecting data on whether patches have caused disruption after being deployed. Just trackd.
With AutoPilot, we’re leveraging that genuinely unique data to enable operators to set patches to be automatically deployed if they satisfy disruption criteria set not by a black-box AI tool, but by the operators themselves, the ones that incur the painful consequences of disruptions caused by patches that break things.
By way of example, those responsible for patching can easily set a rule like “if the patch has been deployed 10 times on other networks, and it has been disruptive less than 1% of the time, set it to auto-patch in xyz time window.” For some, 10 data points may satiate their risk appetite. For others, it could be 100, or 1000. trackd doesn’t make that decision; we simply provide the data.
Will all patches ever satisfy the criteria set by the IT team? Highly unlikely. But if 10%, 50%, or someday (when enough data is available), 95% of patches are applied via this set-it-and-forget mechanism, the limited patching resources available on most IT teams can focus on those that are likely to cause the most damage, resulting in sharp decreases in the time to remediate everything.
I’ve often thought that trackd’s logo should be a silhouette of me sitting in a datacenter figuratively (perhaps literally on a few occasions) crossing my fingers that servers would reboot successfully after applying the latest security updates, because those moments were precisely the inspiration for trackd. Like many founders in their inspiration origin moments, I thought there had to be a better way.
The first vulnerability scanners were introduced in the late nineties, so we’ve been chasing our tails in the community for a quarter of a century. It still takes months or quarters, on average, to patch vulnerabilities, and despite the best efforts of dozens of vendors, very little has improved over the past 25 years. Meanwhile, the risk equation of exposed vulnerabilities has been completely turned on its head. In the early part of the century, patches broke stuff all the time, and the security risk from exposed vulnerabilities was largely negligible. Today, patches very rarely cause disruptions, while the time to exploit vulnerabilities has nearly halved in just a few short years, and the number and types of threat actors has exploded. Yet, we’re still content to delay patching to test in development environments that can never perfectly simulate production environments, or wait arbitrary amounts of time scanning sub-Reddits for reports of disruptions (something we’ve done for you, btw), hoping the bad stuff will happen to others first.
Is trackd AutoPilot the panacea that puts an end to the heartache that is vulnerability management and remediation? Of course not.
But it’s a monumental step in the right direction.
Mike Starr
Founder, trackd
