101 Things Your Application is Doing Without Your Knowledge

The talk starts from the idea that an application often does more than its developers wrote. Code pulled in from libraries, distribution builds and the runtime environment can open files, read environment variables and reach out over the network, usually without the development team knowing. Even a two-line shell script triggers dozens of file opens once the loader and library initialization are counted.

The middle of the talk walks through behaviors the speaker's team has observed by tracing system calls and setting breakpoints on environment lookups. Examples include a tracing framework that wrote shared libraries to a temporary directory with world-writable permissions under predictable names, log and configuration files created with mode 777, and logging code that writes unsanitized input. Other cases included a leftover audit library injected through a preload variable so that every process made an outbound connection, a dashboard product that polled an update server every second against every resolved address, and a hard-coded IP connection traced back to a dependency. Weak random number functions and unbounded string handling also turned up in inherited code.

The takeaways are practical. Keep binaries lean and avoid linking features that are not needed, periodically audit process behavior, and compare current behavior against earlier baselines to catch drift. Environment variables should not be treated as a secret boundary, since same-user processes can read them. The speaker also acknowledged that whether a given behavior justifies a deep investigation depends on how critical the application is to the business.