Inventory executables in $PATH to surface software installed outside app bundle locations

[kitzy]

• Unpacked: TODO: Head of Product Design (HPD) checks this box when the request goes through "Unpacking the why": https://fleetdm.com/handbook/product-design#unpacking-the-why
• Gong snippet: TODO
• Unthread ticket: https://fleetdm.unthread.io/dashboard/inbox/me/conversations/4d9c1c2a-3c82-43d9-bdfa-1f5aa4ba206d

Interpretation

How do you interpret the customer's words?
Fleet's application inventory currently surfaces app bundles and Homebrew-managed packages but misses standalone executables installed in non-standard $PATH directories. The customer has developer tooling — build tools, CLIs, helpers — living in directories like these that never appear in Fleet's software inventory, even though they are executable, on the system PATH, and potentially subject to compliance or shadow IT policies.

What's Fleet missing?
Fleet does not recursively scan a host's $PATH to enumerate standalone executables that exist outside of recognized app bundle or package manager locations. There is also no way to filter software inventory by type (e.g. app bundles vs. executables vs. scripts), making it hard to identify and act on software installed in unconventional places without writing a custom osquery query.

What does the customer's ideal workflow look like?

1. Fleet agent collects all directories in a host's $PATH and inventories the executables found in each, including file name, path, size, owner, and last-modified date.
2. The software inventory UI gains a filter or facet for software type: app bundles, Homebrew packages, executables, scripts, etc.
3. IT admins can filter to "executables" and quickly see binaries installed in unusual or unapproved locations across the fleet.
4. This surfaces shadow IT (e.g. developer-installed CLIs and tools in custom opt directories) without requiring custom query authorship.