8f64ec7416
Fixing non-sense statement "A vulnerability in a shared library can affect dozens of applications, but only if you know which devices have it installed." A vuln in a shared library affects all systems, even when you don't know where it is installed. And THAT is the risk. Can't fix what you don't know about.
9.1 KiB
Unlocking Linux productivity: securing apps and updating certificates
Links to article series:
- Part 1: Why enterprise Linux is important in 2026
- Part 2: Automated provisioning for Linux desktop in the enterprise
- Part 3: Security baselines for Linux: closing the gap on exemptions
- Part 4: Unlocking Linux productivity: securing apps and updating certificates
- Part 5: Protecting the Linux device: remote wipe, USB and sudo
- Part 6: Data and Endpoint Sovereignty: Owning Your Destiny
Computers are not intrinsically productive or secure. Their value comes from trusted applications deployed on them and the certificates that underpin connectivity. With a hardened baseline and compliance policies in place, the next layer of enterprise Linux management addresses two challenges: fragmented software distribution and shrinking certificate lifetimes. Let's look at software inventory and patching, certificate lifecycle pressures, and practical approaches to managing both.
The software distribution maze
If you manage Linux workstations, you know there's no single package format or unified app store. Debian-based systems use apt, Red Hat-based systems use dnf, and SUSE uses Zypper. Then there's Flatpak, Snap, and AppImage on top. Compare this with macOS or Windows, where software distribution is more standardized. On Linux, there's no single ecosystem, so teams that support multiple Linux distributions must manage across all of them simultaneously.
This fragmentation creates real challenges. Each package manager resolves dependencies differently. Each distribution maintains its own repositories with its own release schedules. When your team installs a library from a third-party PPA or compiles software from source, that package often falls outside any centralized tracking. A vulnerability in a shared library can affect dozens of applications, increasing risk if you don't know which devices have it installed.
The software chain of trust
The ability to distribute and install applications securely relies on a chain of trust that extends from the developer to the end user. For modern operating systems, a critical part of this chain is software notarization.
Notarization is a security process where a developer submits their application to the operating system vendor (or a trusted third party) for an automated security scan before it is distributed. The notarization service checks for known malware, signs the app with a secure ticket, and effectively "blesses" the software. This allows the OS to confidently inform the user that the software is free from common threats and comes from an identified source.
Limitations on Linux vs. macOS and Windows
In the enterprise world, macOS and Windows have established mandatory or strongly recommended notarization protocols. With macOS, Apple enforces notarization for apps distributed outside the App Store. Windows provides equivalent code signing that ensures the integrity of executables.
Linux lacks the concept of a universal security notary. Checks are instead relegated to each repository to ensure packages have not been compromised in the supply chain. Some package managers like Debian and Ubuntu rely on manifest data while others like rpm rely on individual packages being signed.
Given that the creation of Linux itself was philosophically rooted in openness, the concept of enforcing checks on software before execution may seem out of place. Apple and Microsoft have introduced safety options as a consumer benefit for enforcing checks and warnings about software that’s being downloaded and executed from unknown sources. With Linux, these checks are missing and are unlikely to be enforced from a centralized control mechanism like an App Store given the distributed & intentionally open nature of the platform.
The gap in software security based on the fragmentation of Linux software repositories means that IT administrators are required to enforce more rigorous checks on software installed on Linux endpoints. With fewer policy controls over software distribution, the need for increased vigilance is critical.
Patching at the speed of threats
Fragmentation becomes a serious problem when threats move fast. The XZ Utils backdoor detected in early 2024 showed how quickly a supply chain compromise can escalate. A malicious contributor spent years gaining trust in a widely used compression library, then inserted code that could have enabled ssh compromise on affected systems. The issue was caught before it reached most stable distributions, but the incident exposed a hard truth: when a widely-used, critical Linux package is compromised, the time between disclosure and exploitation can be very short, sometimes only hours.
That timeline doesn't leave room for manual patching. If your team of two or three engineers manages hundreds of Linux workstations, you can't ssh into each machine, verify the installed version, and deploy an update before the window closes. Even with tools like Ansible or Puppet, the process assumes you already know which machines are affected, and that assumption often fails.
Without visibility into installed packages, you can't assess exposure or prioritize remediation. Package names and version strings differ between apt, dnf, and Zypper for the same upstream project, making it harder to correlate disclosures with what's actually installed. The gap between "patch available" and "patch deployed" is where attackers operate.
Closing that gap requires knowing what's installed, where, and how to update it before the next disclosure drops.
The certificate lifecycle challenge
Software isn't the only OS asset that requires visibility. Certificates are meant to be invisible unless something is wrong. You don't notice them until Wi-Fi stops connecting, VPN tunnels drop, or internal services reject HTTPS requests. Behind the scenes, certificates form the trust chain that holds enterprise connectivity together: 802.1X authentication for Wi-Fi, mutual TLS for VPNs, HTTPS for web services, and client certificates for identity verification.
That trust chain requires maintenance. The CA/Browser Forum has approved a schedule to reduce maximum public TLS certificate validity from 398 days to 47 days by March 2029. Multi-year certificate lifetimes and manual renewal processes are largely over. As validity windows shrink, automation becomes essential. Protocols like ACME (Automated Certificate Management Environment) can handle renewal, though they're often deployed centrally on gateways or proxies rather than on every device.
On Linux, certificate management adds complexity that varies by distribution. Red Hat-based and Debian-based systems store certificates in different locations and use different commands to process them. Browsers like Firefox often maintain their own certificate stores, separate from the system trust store. A certificate you deploy to the OS may not be recognized by the browser, and vice versa.
While distributing certificates with simple scripts is often adequate for simple deployments, the lack of a centralized certificate store means that administrators will need to rely on automated tools to make sure that the certificates are injected into the relevant certificate stores on Linux workstations - from browsers, to Wi-Fi and various VPN applications.
Starting now with visibility into what's deployed and when it expires gives you the foundation to scale certificate management before additional browser-enforcement changes further compress renewal windows.
Managing Linux with Fleet
If you're evaluating ways to tighten Linux software and certificate hygiene, try Fleet on Linux to see how inventory, targeted updates, and certificate-related scripting can fit into your existing workflows.
The next article in this series will cover protecting the device itself: how remote lock and wipe for lost or stolen Linux workstations, peripheral and port governance, and local identity management (including the persistent "sudo problem") help bring Linux device security closer to what enterprises already expect from macOS and Windows.