What breaks when Python cache files are not treated as trusted execution artefacts?

Source review and repository scanning stop being reliable indicators of what will actually run. An attacker who can influence cache creation or replacement can steer execution through a layer that defenders often ignore, which turns a normal optimisation feature into a supply-chain attack surface.

Why This Matters for Security Teams

Python cache files are often treated as disposable build artefacts, yet they can influence what code executes next. That matters because defenders may review source files, dependency manifests, and package signatures while overlooking bytecode caches and other runtime residues. When cache content is trusted by default, an attacker with write access, a compromised build step, or an unsafe deployment process can create a gap between what was reviewed and what is executed.

For security teams, the risk is not limited to malware hiding in plain sight. Cache misuse can undermine code integrity checks, complicate incident response, and create false confidence in source-level review. Controls for software supply chain assurance need to account for generated artefacts, not just committed code, as reflected in guidance such as the NIST SP 800-53 Rev 5 Security and Privacy Controls. The practical problem is that many monitoring and approval processes stop at the repository boundary, while execution can still be redirected downstream.

In practice, many security teams encounter cache-related compromise only after a routine deployment behaves differently from the reviewed source, rather than through intentional validation of execution artefacts.

How It Works in Practice

Python can generate cache files to speed up imports, which is useful in normal operations but dangerous when the cache lifecycle is not controlled. If a cache file is replaced, poisoned, or created in a path that the runtime trusts, the interpreter may load bytecode that does not match the reviewed source state. The result is a form of execution drift: the repository looks clean, but the runtime path no longer reflects it.

Operationally, teams should treat cache artefacts as part of the software trust boundary. That means defining where caches may exist, who may write them, how they are rebuilt, and whether they are accepted at runtime. Commonly missed controls include immutable containers that still mount writable paths, build agents that reuse workspaces between jobs, and release pipelines that sign source packages but not generated outputs. NIST guidance on integrity and configuration control is relevant here, and the same principle appears in broader software assurance practices from CISA and related supply-chain guidance.

• Rebuild caches in controlled CI or deployment steps rather than inheriting them from unknown environments.
• Restrict write access to interpreter cache locations and deployment directories.
• Detect mismatches between source timestamps, hashes, and loaded artefacts during testing and release.
• Exclude transient cache paths from trust decisions, allowlists, and review assumptions.

Where teams have stronger assurance needs, they should verify that generated artefacts are reproducible and traceable back to the reviewed source set. Current guidance suggests that cache hygiene should be folded into software integrity checks, not treated as a housekeeping issue. These controls tend to break down in shared filesystem deployments because multiple workloads can write to the same cache path without a clear ownership boundary.

Common Variations and Edge Cases

Tighter cache control often increases build and deployment overhead, requiring organisations to balance faster startup times against stronger execution assurance. That tradeoff becomes more visible in containerised systems, ephemeral CI runners, and developer workstations where local performance optimisations are common.

There is no universal standard for when every Python cache file must be deleted, but best practice is evolving toward context-based trust. In high-assurance environments, caches should be regenerated from verified source at each build or release stage. In less sensitive environments, teams may allow caches to persist, but only if they are non-authoritative and cannot override reviewed source or packaged artefacts.

The main edge cases are environments that mix trusted and untrusted execution paths. For example, notebooks, plugin-based applications, and shared automation hosts can load code from places that are hard to govern centrally. If cache files are stored alongside editable source trees, the risk increases because a simple file write can become an execution change. This is where identity intersects with code integrity: the account or service identity that can write to the cache path effectively gains influence over runtime behaviour, so access control and build provenance both matter. Guidance should therefore be paired with a review of who can create artefacts, not just who can execute them.

Authoritative software integrity programs should also align cache treatment with verification controls, signing where applicable, and runtime monitoring. For general control mapping, see the NIST SP 800-53 Rev 5 Security and Privacy Controls.

Related resources from NHI Mgmt Group

• What breaks when shared AI chats or artifacts are treated as trusted guidance?
• What breaks when MCP tools are treated as trusted by default?
• What breaks when certificates are treated as static infrastructure artefacts?
• What breaks when LLM output is treated as trusted input?