One of the challenging things about building a File Integrity Monitoring (FIM) product is overcoming the low credibility that FIM has with Security teams. FIM has a history of overwhelming false positives, and vendors (including OSS solutions) tend to push the responsibility for tuning onto overworked Security teams (something like: "Just tell us what you want to monitor and we'll do it"). Security teams cannot handle that workload.
I've heard rumors that there are Security teams in heavily regulated environments where (through massive human effort) they have manually configured their FIM and maintain useful alerts by keeping it up-to-date, but I haven't yet met such a team (if you are such a team, please reach out!)
The reality usually becomes that Security teams tolerate rather than value their FIM solutions. They'd rather spend that budget on something that provides more value to them, but their regulatory certifications require that they keep FIM in place. FIM starts to be perceived as "compliance theater", a dance we do to make it seem like we're doing something effective (a form of what Bruce Schneier called "security theater", here done in service to compliance requirements).
But, we wouldn't be building this company if we believed that this is the best that FIM can be.
File changes are fundamental
There's a truism in Unix: "Everything is a file." That concept extends from standard text and binary files to directories, mount points, hard and soft links, network sockets, interprocess communication, virtual files representing kernel and process states, etc. And critical parts of the system are persisted as files: the boot configuration, the kernel image itself, the systemd daemon that starts other services, all the other service binaries, the libraries that all these binaries depend on, and their configuration files.
So surely monitoring for file changes at least could be effective, right? Yes, but only if you monitor the right files and can tell which are the wrong changes. If the load for deciding what the right files falls on each individual Security team, and the identification of wrong changes is a post-alert human task, then we all lose.
Could we achieve the monitoring we need without FIM? We can operate around the edges, but there's something fundamental about files on Unix/Linux systems. We believe that we have to deal with the complexity of the system if we're going to detect persistence at a system level. Bumping up to the identity layer does not save us from this problem.
The fact that FIM is not working well is a weakness in all our Security that we believe must be remediated if we are to effectively deal with attacker persistence. If you look at how attackers persisted in Linux cloud intrusions in the Mandiant M-Trends 2026 report, 39% of those were system-level persistence, and another 10% were web shells (which frequently have a filesystem component). Attackers will use these techniques as long as they continue to work.
Data vs. code
For detecting attacker persistence, we don't care about modification of files that are purely data (including log files). Granted, some regulations (notably HIPAA) have requirements to prevent modification of data: imagine the consequences of malicious or even accidental changes to a patient record. And preserving log files is a fundamentally important property of secure systems, to detect and recover from intrusions and plain old system failures. But all of that is a different problem than FIM (in general) is trying to solve.
We're trying to catch attacker persistence, which means noticing when attacker code has become a durable part of the executing system (or at least survives a reboot). At the system level, this could be by injection into the boot or startup sequence, an existing service executable, its library dependencies, its accounts and access, its plugins or other executable code addons. Or, by leaving a remote access backdoor such as an extra SSH key controlled by the attacker.
How do we know what to monitor?
To cover detecting changes to file-based code (more on the non-file aspects in a future article), there are two ways currently used to maintain a list of the critical files:
1) We push it onto the user to define the list. This is not feasible or sustainable in modern infrastructures, but regrettably is still true for many deployed solutions.
2) The vendor maintains profiles for each application, defining what is important to monitor for each. This is better and more scalable (though users may still have to select which profiles apply to which systems), but there is a problem: First, the universe of commercial and open source software (OSS) applications that enterprises deploy in their own infrastructure is very large. The universe of internally-developed enterprise applications is 100-1000 times larger. The vendor maintaining profiles for these is difficult (for commercial/OSS) or impossible (for enterprise apps).
But there's an even bigger problem that I submit can't be solved by a vendor solution with static configurations: SaaS.
What about SaaS?
There are a large number of SaaS applications that enterprises depend upon, and only the SaaS provider knows fully what that software stack includes. SaaS customers don't need to worry about this (part of why they buy SaaS), but what about the SaaS provider? Depending on customer base, the SaaS provider may need to certify at least some of their infrastructure under compliance regimes such as PCI-DSS, HIPAA or FedRAMP, which means deploying FIM.
SaaS providers have to deploy FIM inside highly scaled cloud infrastructures, with large numbers of developers constantly pushing new code. They also depend on OSS, but at a deeper layer than FIM vendors can even consider: for example, there are more than 3 million npm libraries.
So vendor solutions based on static configurations struggle to scale to the sheer size, complexity and rate of change of SaaS provider infrastructures, and pre-configured profiles are rarely applicable to SaaS providers' needs.
Now consider again the poor Security team, frequently outnumbered by the Engineering team 10:1, trying to keep the FIM system up to date with the rapid changes being deployed. It's a losing battle. I can tell you this from my own experience, and from the experience of colleagues across other companies.
How do we get beyond theater?
Our central premises (aside from that files are important) are these: FIM systems must configure themselves, and must analyze alerts themselves. That's the only way to handle the complexity of the systems that our industry has created (not to mention the complexity that is being accelerated by AI-generated code, which soon no human will understand).
The FIM system needs to:
1) Cover the basics common to all systems, based on the OS flavor (e.g. Ubuntu vs. CentOS). This can be static as the complexity is low.
2) Observe applications as they start up and enumerate their code dependencies so that all the important components are covered. This is the fundamental improvement that makes the solution scale to the universe of commercial, OSS, and enterprise applications and their dependencies. And, importantly, to the infrastructures run by SaaS providers.
3) Enhance the above with AI so that at least for existing known applications that have documentation available or well-known behaviors, anything that might have been missed by observing the application can be added to the list (more on this in another article).
With these three layers, we have a chance of recovering the utility of FIM and making it into a tool that security teams value, not just tolerate.