Inside Automox’s Approach to Third-Party Software Updates

Summary

Peter Pflaster and Ben Glass team up in this episode of Product Talk to tackle the ins and outs of third-party application patching with Automox. They break down what third-party software means, where IT teams often struggle with patching, and why a centralized approach can make all the difference. With a relaxed yet informative style, the two cover everything from cross-platform patching for Windows, Mac, and Linux to the process behind counting supported titles and taking customer requests. They also touch on unique solutions like Automox Worklets™ for managing custom software and share how Automox simplifies patching for IT teams of all sizes.

Transcript

Peter Pflaster:

Hello everyone and welcome to the February 2025 edition of Product Talk. This month we're going to be covering third parties and no, I'm not talking about the night before 4th of July. We're talking about third-party application patching with Automox. Joining me as kind of our technical experts and probably one of the people responsible for growing our catalog.

more than 4X in the last couple of years is Ben Glass. Ben, why don't you give us a super quick intro of your role at Automox.

Ben Glass:

Absolutely, yeah. Hey, everybody. Ben Glass, I joined Automox a few years ago. I oversee our professional services and a couple of engineering teams here, primarily focused on content. And that includes third-party and our supportive third-party titles and adding new titles, supporting those, and making sure everybody gets those as fresh as possible.

Peter Pflaster:

Yeah. Yeah. And Ben's got a unique perspective. I believe the job before this, you were over at Rapid7. So you were kind of on the vulnerability management side of things. And you've kind of moved over to the IT side of the house now with the remediation and patching side of things.

Ben Glass:

Yeah. I did. Yeah. I was focused heavily on the professional services side, uh, for  vulnerability management products at Rapid7 and then moved over, um, to lead professional services here, but then slowly kind of took over additional responsibilities. And that now includes a lot of engineering responsibilities related to third-party and our support for third-party titles and making sure that we're able to patch those as effectively as possible.

Peter Pflaster:

Yeah. Yeah. And I think, yeah, that's probably the first thing that we should discuss today before we hop into the, the real meat of the discussion with, as far as like how we think about third parties and Automox and how we actually go about patching these. But, you know, what is, what is a third-party as it's defined in Automox, right? I think some folks may jump to like libraries for from a coding perspective or something like that. what is like a third-party? Give us a example of what that would be.

Ben Glass: 

Yeah. Yeah, the way, the way that we kind of define it here at Automox is a third-party title is software or a package that's provided by a vendor that is not natively supported within an operating system. So, you know, if I'm on a Windows device or a macOS device, those updates I get from Mac or Microsoft directly, those would be considered first-party here. Third-party could also be provided by Microsoft or Apple, but they're not natively provided through the software update means that we issue to perform those first-party updates. So good examples could be like a Google Chrome would be considered a third-party. It is not natively provided and updates to those packages are provided directly from Google. And we'll provide those patches on behalf of Google and those get set up through policies within our platform.

Peter Pflaster:

Awesome. Yeah. And it's kind of a, you know, it's been a, been a thing, third-party patching for a long time, but it seems like the last few years, it's become a much larger focus for IT teams as most models have moved away from like a perpetual licensing for those of you that remember, you know, Microsoft Word 2017, and then you'd have to go and buy the next version and now everything is just SaaS, right?

Ben Glass:

Yeah. Yeah. It's really interesting. It changes our approach to applying those patches or making those packages available to customers a little different. But for the most part, the behavior is pretty much standard. We implement a scan process. So as everyone knows, who's a customer of Automox, that your devices will go through the scan about every four to 24 hours and sometimes more frequently, depending on what policies you have implemented.

We collect in all of the software and packages installed. And we also identify the ones that we support during that collection process. So we know pretty much at the point of those scans that you might have patches that are pending for first-party and third-party. And then when you create your policies that apply patches for third-party software during that schedule, we'll actually fetch those packages directly from Automox in order to apply those to your devices. that the process is pretty much similar. But yeah, as the climate is changing around how software is distributed and how customers subscribe and purchase that, we've also adapted to tailor the needs to those customers as well.

Peter Pflaster:

Yeah. And this is a big one. you know, as we talked to prospects in the sales process or talk about the pains that folks have, most companies have a decent handle on operating system patching. it's been around for a long time and it's been pretty standard, but definitely seems like a lot of folks may not have any process today for patching third parties or if they do, it may just be.

reliant on the end user to go and do it themselves when they see Chrome updates available, for example.

Ben Glass: 

Yeah. Yeah. But I'd say one of the biggest challenges is, if I have 10 different third-party products installed in my device, I might have 10 different ways or the vendors providing their own unique way of applying a patch. then the, what Automox helps with it, it obviously centralizes that capability. And then customers get this singular experience as they're using Automox to provide those patches. otherwise you get 10.

Peter Pflaster:

Yeah.

Ben Glass: 

unique experiences for patching each individual package. And you end up with folks frustrated around, well, Google Chrome updated this way, Adobe updated this other way, or we're using the auto-updater for this one particular package. And you just get this wide array of implementations and it's just kind of confusing. we just simplify that, take away that pain from everybody and create this one singular experience.

Peter Pflaster: 

Yeah. And I think the, the interesting thing here is, you know, one of the, one of the things that we talk about a lot, which is, is cross platform. you know, we, we cover windows, Mac, Linux, if you could just really quick talk about the three of those at a high level and what third-party patching means for each of those.

Ben Glass: 

Yeah, no, that's a great question. So primarily we'll support Mac OS and Windows for what we consider third-party here. The caveat with Linux is interesting because most of the third-party packages provided are actually just additional repositories that you add and they're updated through the exact same means that you would update first-party. So we don't support third-party for Linux the way that we support Mac OS and Windows.

The only way that we end up supporting Linux third-party is by you just add the repository and we use the same yum dnf apt commands and we perform the updates the same way that we would for first-party.

Peter Pflaster: 

Nice. And taking a little bit of a step back, we talked about the initial scan process and some of the intervals there and flagging applications for those windows and those Mac systems with third parties that we do support from a patching perspective. Really quickly, so there's a few resources, first of all, for those of you that aren't Automox people, we've got a public.

repository if you just Google search, Automox third-party patching that has our entire catalog there for you to check out and what operating systems are supported for each of those third parties. how many do we support between Mac and Linux roughly as of, you know, we're recording this about a week before release, so February.

Ben Glass: 

Yeah, right now we're probably around mid 570s is what we support for the number of titles. And that covers both Windows and Mac. And a lot of it aligns with how we get our requests. So we'll end up receiving requests, we complete them, and then it counts towards an additional title. So in some cases, we might actually have a few additional titles that we support that just didn't align directly with the request.

But we have probably, I'd say around 350 or so for Windows that we support exclusively and then probably closer to like 220 to 230-ish for Mac OS that we support today.

Peter Pflaster: 

Nice. Yeah. And I think, you know, having a decent knowledge of, the rest of the market, the thing that I see the most is, is confusion, around third-party patching, particularly around the number of titles supported. go to some, some vendor websites and they're in like the five thousands, which I don't doubt that there are that many third parties out there, but, there are certainly different methodologies.

for counting the number of titles that you support. And I think if you're an IT buyer, it's really important to understand the nuance there. So you are thinking about it in the same way that the vendor is. So why don't you just go over like, I think you kind of touched on it briefly for how we count it, but just kind of elaborate a little bit on how we come to that final, you know, 575, 580.

Ben Glass: 

Yeah. Yeah, so we took a really simple approach and we just counted the requests really, just the difference of requests between Mac and Windows. We do know that other vendors will provide counts based on a difference of architecture within those different platforms they support. And sometimes they'll count even each version that is available to be hosted or cached to. So you could end up with a number that's in the thousands or even 10,000s, depending on how many versions of a particular title you support. For us, we just ended up counting the different requests. We get a request to support a new title. We'll add that to our intake, and then it ends up being an additional counter that we'll publish on our website. And the way that we count it is just, we support it for Mac and Windows? And if we answer yes to both, then it's two additional titles. Aside from maybe like the...

depending on the variety of architectures and you know some vendors provide at least for macOS they might provide like a universal installer so that's just one package they might provide one for Intel and Apple Silicon so that might be two different ones but for us we end up counting it as one

Peter Pflaster: 

Yeah. And I think the reason that we did that and, why we market it that way and why, you know, I think this has been a point of, of debate, that, that we've held pretty strong on, but, you know, we really want it to be a number that makes sense to folks that are trying to evaluate us. Right. Like we, don't need to juice the numbers in any way. think, I think we went and looked at what our number would be if we counted every version.

Of each software we are supported and it was like 16,000 titles or something crazy like that,

Ben Glass: 

Yeah. Yeah, it was up there for sure. I think if we, if we wanted to count the unique architectures and operating systems, it was, it was definitely well over a thousand. If we wanted to include additional versions, then it was probably closer to the tens of thousands. And that's, you know, some, some vendors will provide an update every week. And if we cash those, like we end up with, you know, that many iterations over the course of a year or two, however long we were cashing that particular title.

Peter Pflaster:

Yeah. Yeah. And I think, you know, that would, that might make us feel better for a little bit, but it's kind of like counting your 401k in pennies instead of dollars. the, reality will for, for our buyers, right. And our customers will, it will probably come crashing down on, on all of us eventually if, if it doesn't align to, what their expectations were going in. So that's basically why we count it the way that we do.

Ben Glass:

Yeah. Yeah.

Peter Pflaster: 

Obviously we were biased, but we believe that's the most sensible way to go about it.

Ben Glass: 

Yeah. And if there's, if there's any confusion or questions, like we do populate every title on our website too. So if you're interested in, you know, what does Automox support, we actually publish all of that information out there. and it's actually a really easy process to request new titles too. You know, so we were definitely dedicated to, we carve out some time to, to support new titles and continue to grow the catalog.

Peter Pflaster: 

Yeah, that's huge. Actually. I know that I've seen it on multiple instances, right? Like we're evaluating. What's what's the most prevalent in our customer environments, of course, when we don't know what else to build. And, you know, we, we really hit most of the low hanging fruit at this point, right? Like we support most of the stuff that one would expect that we would support, but we do take requests from customers. think the other point of nuance as we take requests is.

Ben Glass: 

Yeah.

Peter Pflaster: 

is an interesting one and that's, you know, if a title's paywalled, how does a vendor go about, is that even possible to be supported out of the box?

Ben Glass: 

Yeah, I'd say it is possible to support it, although implementation might look a little different. I think our general approach to supporting new titles is if the title is publicly available and programmatically available for us to download. So we try and automate as much as possible instead of having, you know, a human sit there and evaluate every piece of software that we cash and make sure that they're available.

We like to automate as much as possible so that we could scale a lot more quickly. But paywalls are generally something that prevent us from natively supporting that within our cache. If we do have the means to automatically download, we would obviously love to support that and get that into our catalog as quickly as possible. But those are usually the first couple of things we look at is can we automatically and programmatically download and evaluate those packages?

And then is there anything that might prevent us from downloading or accepting that into our cache? Paywall being one of those could be some licensing concerns too, so that we're obviously not caching software that is licensed by Automox and distributed, but those are a couple of the options that we've got.

Peter Pflaster: 

Yep. Yeah. And that's pretty standard across the industry, right? Like everyone's trying to abide by, you know, terms and agreements and also like, you know, legal implications and paywalls, et cetera. So that's what I've seen to be standard, at least across the industry.

Ben Glass: 

Yeah. Yeah, our approach is pretty straightforward where we'll receive a request. If we could programmatically download and it's publicly accessible and we can silently install it, those are pretty good rule of thumbs that indicate that we can support it within our catalog for patching.

Peter Pflaster: 

Awesome. I think to close out the discussion, I'd like to talk at a really high level about how we handle the actual process of third-party patching with Automox. There's a lot of different approaches across the industry, right? Like some tools administrators are writing their own automations or they're going and packaging everything themselves and caching it somewhere. They're buying additional tools that do that for them.

Let's start by going over at a high level. what does that process look like for when a given, what update becomes available for a given title?

Ben Glass: 

Yeah, it all starts with the request. Requests will need to come from somewhere. It could be a customer that reaches out to support. It could be someone that reaches out to sales or their customer success manager or even their pro-serve consultant. We do have an internal intake process that first goes through what we call tech feasibility and really kind of those things I just mentioned around, can we automatically download and evaluate a package?

Is it a valid package format for us to distribute and serve to our customers? Can we silently and programmatically install that package without doing like a lot of random pop-ups or interruptions to our end users? Those are a few of the first things we look at. The second phase is focused on caching those titles. So once we've determined that we can support it, we'll move into a, what we call a scanning and caching phase.

And what that really encompasses is the automation around being able to fetch that package, scanning that package to make sure it's free of any known malware or vulnerabilities. And then it gets placed into our catalog. The third phase is implementing it and supporting that particular title for patching. So just because we cache it doesn't mean it's immediately supported for patching. We do have that final step.

That just allows us to apply those patches and mark that title as supported within the catalog. then the next time you scan your device, we'll, we'll inventory those packages and software, and you could create policies that align directly with the new third-party title. And then we ended up publishing that and updating our website. So that's kind of that full circle, full cycle of where a third-party title starts with a request and goes through a couple of workflows and ends up being available for you to apply patches directly within a policy.

Peter Pflaster: 

Awesome. Yeah, and I think some of the key differentiators for us, right, are centered around what we do from a security perspective with new updates and then where we store those updates and how we distribute them. Is that correct?

Ben Glass: 

Yeah. Yeah. So one of the things I'd say, like one of the pain points that we take away from customers is we end up hosting the third-party titles in our own catalog and cash. And what this transparently ends up providing is that you no longer have to whitelist outbound, you know, firewall ports or, or access to different websites. There, there might be a couple of nuances with titles we support where there's a requirement of using an auto update or functionality out. However, majority of our titles, we end up hosting ourselves. Otherwise you end up having to poke in poke out like firewall rules to access each and every individual title you might support. that, that management of your firewall rules ends up becoming a pain. ended up hosting ourselves and we perform security scans before we end up caching those titles as well. when you run your policy that's scheduled to apply the patch, it'll fetch directly from the Automox cache and catalog and then we apply those updates directly to those devices in scope.

Peter Pflaster: 

Awesome. Yeah. I guess lastly, just for those of you that have been listening the whole time and are like, well, what about my weird, you know, custom made software that we created at my business specifically that I have to go in and deploy? mean, what's the answer there for a customer that's looking to distribute or patch that at scale?

Ben Glass: 

Yeah. I mean, to right now, the best option would be to leverage worklets and required software policies and product. You could support just about anything in those. And you could also access your own internal cash and store with the use of those worklets. you might have to create a template or work with Automox to professional services, maybe to create a template that works for your business. But yeah, you could definitely store.

the payloads or the packages themselves, you could use a worklet to distribute and apply those patches to affected devices in your environment. And that process is actually really, really simple and straightforward to do as well.

Peter Pflaster: 

Awesome. Well, folks, that's pretty much, I mean, I'm sure there's more nuance, but that is a really comprehensive overview of what third parties are in Automox, what we cover, how we cover them, and why a cloud native solution might make sense to look at from a third-party patching perspective. Any closing thoughts that you'd like to add, Ben?

Ben Glass: 

I mean, keeping it high level, definitely kind of the focus. We could really dig deep into each individual title. Some of them have really interesting nuances that change the behavior or change our strategy for applying a patch. But we like to take that complexity away from customers. we.

Peter Pflaster: 

Yeah. I think that's my favorite thing, right? It's like you and your team can deal with that. And then like myself, when I use Automox at my house or a customer, when they're using Automox at their business, they can, they can, you know, scope what they want to patch or patch all the third parties that are available and run with it without having to worry about that nuance.

Ben Glass: 

Yeah, for sure. Yeah. It's the fun part for the team for sure. Like, you know, how do we support this new title that we don't have necessarily a solid strategy for today? And how do we take that pain or, or, you know, take, take a lot of that nuance away from what a customer or an end user more specifically will see as their third-party titles on their workstation get updated.

Peter Pflaster: 

Excellent. Well, thank you so much, Ben, for joining us. We're looking forward to seeing the catalog surpass 600 in the near future here and beyond, hopefully. Really appreciate your time today and thanks for listening all. If you made it to the end, we will talk to you in March.

Ben Glass: 

Awesome. Take care y'all.