Your approved software list only works if you compare it with what is installed

How to find the gap between the software you have approved and the software actually on your estate, using tools most Intune and Jamf shops already have.

Most organisations I talk to have some version of an approved software list, whether that is a proper catalogue in Intune or Company Portal, a Self Service policy list in Jamf, or a spreadsheet someone in IT built for an audit two years ago. In almost every case, the list describes what the organisation intended its devices to look like rather than what is on them now.

That gap matters more than it first appears, because it is where a lot of the unmanaged risk on an endpoint estate sits. Your patching process, whether that is Patch My PC, Jamf App Installers, Intune’s own app updates or a person with a checklist, works from the catalogue, so anything outside the catalogue is never updated by anyone. The PDF editor a finance user downloaded in 2005, the screen recorder someone needed for one training session, the browser extension that asked for permission to read every page and was granted it without a second thought: none of these are in a patching tool’s list, so none of them get patched, and they sit on the device getting older until someone finds them or something exploits them.

Why the usual tools do not close the gap

A typical mid-sized business has several sources of security information about its endpoints. The patching tool reports well on the applications it was told to manage and, by design, has nothing to say about anything else. Vulnerability scanning gives you another view, although in environments I’ve worked with its coverage has not always extended equally across every endpoint, particularly devices regularly away from the corporate network. The annual penetration test gives you a useful point-in-time view, and then the estate carries on changing for the rest of the year.

None of these is wrong, and I would keep all of them, but none of them answers whether the software on a device is software you agreed to have there.

Building a list people will actually maintain

Lists fail when they were written once for an audit and nobody owns them. A workable one records the application, who approved it, who is allowed it and how it is kept up to date. That last field is useful because if you cannot write down how something is patched, you have found a gap before looking at a device. It also needs an owner who reviews it on a schedule and a request route that answers in days, because if asking means an email that disappears, people will install things themselves.

On large endpoint estates I’ve managed, the approved list was accessible to users and integrated into the software request process. That part worked well. What an approved list cannot do on its own is tell you what has turned up without approval, because by definition it only knows about software somebody has asked for. Unless you compare it with inventory, you have no idea how closely the real estate still resembles the one you designed.

The software that never looks like an application

Most drift conversations stop at applications, meaning things with an icon in Applications or an entry in Programs and Features, and that leaves out a large part of what developers and technical staff actually install.

On macOS, Homebrew is the obvious example. Casks install ordinary application bundles and will usually show up in inventory, but formulae, which are the command-line tools, language runtimes and libraries that make up most of a developer’s Homebrew install, live under /opt/homebrew on Apple silicon or /usr/local on Intel and do not appear as applications at all. A Mac can have a couple of hundred formulae installed, several of them years out of date, and the application inventory will show a clean device.

On Windows, the equivalent is PowerShell modules installed from the PowerShell Gallery or from whatever other repositories someone has registered. Modules can be installed for the current user without any elevation, they run with whatever rights the person running them has, and they do not appear in the installed programs list that most inventory tools read. The repositories themselves are worth knowing about too, because a repository you did not expect is a finding before you have looked at a single module in it.

If your approved list does not say anything about package managers, you have effectively approved everything that can be installed through them.

Developer admin rights and elevation on demand

Developers on macOS are usually the group with the widest gap between the list and the device, and the reason is structural rather than behavioural. Most developer workflows need administrator rights at some point, and anything installed while someone is an administrator bypasses whatever the catalogue was meant to enforce.

Many organisations have moved from permanent admin rights to just-in-time elevation, where a user requests administrator rights for a short window using something like SAP Privileges or the elevation feature in Jamf Connect, and the rights are removed when the window closes. That is a real improvement, and I would recommend it over permanent admin rights, but it moves the problem rather than removing it. The software installed during those fifteen minutes stays on the device after the rights have gone. Elevation logging tells you that someone was an administrator and when; it does not tell you what they installed while they were.

If you allow elevation, the drift comparison needs to run often enough that you can connect what appeared on a device with the elevation window it appeared in.

Finding the drift with what you already have

You do not need a new product to take a first look at the gap, although the native tools were built for inventory rather than comparison, so expect some spreadsheet work.

In Intune, the discovered apps report can be exported and compared against your catalogue, though it is noisy with runtimes and components. If you have Defender for Business or Defender for Endpoint, the software inventory is usually the better start because it ties applications to known vulnerabilities and lets you start sorting unapproved software by risk.

Browser extensions are a different matter. Microsoft’s extension inventory requires additional Defender Vulnerability Management capabilities and coverage varies by platform and browser, so it is worth checking exactly what your licensing gives you rather than assuming extensions will appear alongside normal application inventory.

In Jamf Pro, an advanced computer search on application title and version gives you much the same raw material. Browser extensions are not part of standard application inventory and need additional collection or management, which makes them a good example of how difficult it can be to answer the apparently simple question of what is actually installed across an estate.

Automatic updating in Jamf does not remove this work, because it only acts on titles you have already set up. Finding what has appeared since you last looked, deciding what to do with it and building the smart groups and policies is still manual, and it happens only as often as someone sits down to do it. On a busy estate, that can mean new software sits on devices for weeks before anyone notices it.

Homebrew formulae and PowerShell modules appear in none of these normal application reports, so you will need your own scripts to collect them.

The comparison itself is simple: take the inventory, remove everything approved and the components you have decided not to govern, and sort what is left by how many devices have it and whether it is vulnerable. On an estate that has never been checked, that list is usually longer than anyone expected.

Doing something about it

I have seen plenty of drift reports produced, filed and never acted on, usually because nobody agreed in advance what should happen when unapproved software turned up, so decide that before you run the first one. For each item you find, the answer is one of three things: approve it and bring it under patching, replace it with something already approved, or remove it.

Removal should be authorised by someone with the standing to make that call for the business, tested on a small group first, and checked afterwards, because an uninstall that reports success and leaves the application behind is common enough that you should assume it will happen to you at least once.

The part that most organisations skip is doing it again. Drift comes back because people change roles, projects bring in new tools and the list falls behind, so a comparison run once gives you a clean estate for a few weeks and very little after that. Running it monthly, and treating a growing remainder as a sign that the request process is not working, is what turns the approved list into something that reduces risk rather than something that satisfies an auditor.

The part I have not solved

The hardest case is the pinned version, where the business needs a specific old release of something because a developer workflow depends on it, and upgrading would break a build, a toolchain or an integration that nobody has the time to rework. At that point the software is approved in practice and known to be vulnerable, and the honest way to handle it is to record the risk, have someone with the authority to accept it sign it off, and review that decision on a date.

I’ve seen versions of the same organisational problem more than once. The engineering lead does not want to own a security risk, the security lead does not want to approve a known vulnerability, and the business owner may not understand the question well enough to answer it. The danger is that the application gets excluded from the patching policy because it cannot be updated, then excluded from vulnerability reporting because everybody already knows about it, and eventually the only record that it exists and why is in the heads of the two or three people who know the estate. When one of them leaves, the exclusion stays and the reason goes with them.

The technical staff in the middle get the worst of it. They can see the risk, they know the right thing is to write it down and get someone to accept it, and they are also likely to be the people asked why it was missed if it is ever exploited, but they do not necessarily have the authority to make the business accept it. They end up doing the diligent thing quietly, keeping their own notes and checking versions by hand, which works for as long as they stay.

I do not have a clean answer to the people problem. What I would do differently now is refuse to create an exclusion without a record attached to it, even if the record only says who asked for it, what depends on it, and that nobody has yet accepted the risk. I would keep that unaccepted status visible in the same report as everything else rather than removing the item from it. A known exception that nobody has signed is still a finding, and it should look like one, because the alternative is an estate where the most dangerous software is the software nobody can see in any report.

Try it on ten devices

If you want to know whether you have this problem, you do not need to redesign anything. Pick ten representative devices, export the inventory you already have and compare it with your approved list. Look separately at browser extensions and, where relevant, Homebrew or PowerShell modules. Remove the operating-system components and other things you have consciously decided not to govern, then look at what is left.

For each item, ask who approved it, who needs it, how it is patched and who owns the risk if it cannot be. I would be surprised if the first ten devices did not give you something worth investigating.

Why I built Patched

Patched is the tool I wanted when I was running endpoint estates and never had, so I am not a neutral party here. The idea is to continuously compare what is actually installed with what has been approved, rather than relying on someone remembering to run an inventory report and work through a spreadsheet every few weeks.

Patched picks up new software as devices check in and compares it with the approved list across Windows and macOS. Homebrew packages and PowerShell modules are on the roadmap for the same reason: if software can run on an endpoint, I want it to be part of the same conversation regardless of whether the operating system considers it an “application”.

The other part I care about is exceptions. When software is pinned or a risk is accepted, suppressing the finding is the easy bit. The useful information is who accepted it, why they accepted it and when that decision needs to be reviewed. If nobody has accepted it, I would rather the system continue showing that awkward fact than make the problem disappear.

You can do a version of all of this yourself with the tools above, and if you have not looked at the gap on your own estate before, I would start there before buying anything.

← Writing · Andy Bridson