TL;DR: The March 2026 LiteLLM incident showed how compromised package releases and .pth execution can let code run during Python startup outside the import path developers expect, according to Testifysec, making hashes, secret scanners, and narrow runtime checks insufficient on their own. Trusted installation review, constrained credentials, and egress controls remain separate governance problems.
At a glance
What this is: Testifysec examines the March 2026 LiteLLM incident and shows that Python package code can execute during interpreter startup through .pth processing, not just through explicit imports.
Why it matters: This matters because dependency review, secret scanning, and hash checking do not by themselves govern what actually executes in a build or runtime environment, which is an important control gap for software supply chain and NHI-adjacent credential exposure.
Context
Python dependency trust is not limited to what a developer imports explicitly. Startup-time execution, package release integrity, and lockfile handling can all change what code runs before the application reaches its own logic. The LiteLLM incident matters because it shows how a dependency can cross from packaging into execution without a simple import-path review catching it.
For identity and access teams, the governance question is whether the environment that installs or runs code is allowed to trust package metadata, hashes, and scanner output without validating the full execution boundary. That boundary matters for machine identities, CI credentials, and secrets that can be exposed before application controls ever engage.
Key questions
Q: What breaks when a trusted Python package can execute before import-time controls see it?
A: Import-time execution breaks the assumption that code only runs after deliberate application logic starts. When a package can execute through module import or a .pth file at interpreter start-up, secret access happens before many monitoring, review and containment steps can intervene. That turns dependency trust into immediate runtime risk, especially where environment variables and service credentials are already present.
Q: Why do hashes and lockfiles not make a package release trustworthy?
A: Hashes and lockfiles prove that installed bytes match a chosen record, but they do not prove the release is benign. If the record itself comes from a malicious or compromised release, integrity is preserved while trust is still broken. Practitioners need provenance review, not just repeatable installs, before they treat a dependency as safe.
Q: What should security teams measure to know secrets scanning is working?
A: Measure coverage, context quality, and time to remediation. If findings lack ownership, rotation age, or access scope, the scanner is generating alerts without enough information to drive action. Effective scanning makes secrets easier to find and easier to prioritise.
Q: Should organisations treat CI credentials as part of software supply chain security?
A: Yes. If a malicious package can run during startup, CI tokens and other machine credentials become part of the same attack surface as the dependency itself. Constraining those credentials to short-lived, narrow-scope access reduces the blast radius when a release turns hostile, especially in hosted build and test environments.
Technical breakdown
Why .pth files expand the execution boundary
Python’s site module can process .pth files at startup, and those files may contain executable import lines. That means code can run before the application’s own imports are reached, so a review that only inspects explicit dependency imports misses part of the execution surface. Whether a file is processed depends on interpreter configuration and site directory handling, which makes environment assumptions especially risky in packaged or shared runtime contexts.
Practical implication: Review startup-time execution paths, not just application imports, when validating dependency trust.
Why hashes and lockfiles do not neutralise malicious releases
A package hash only proves that the installed bytes match a known record. If the approved record itself came from a malicious release, the hash confirms integrity, not benign intent. Lockfiles help with repeatability, but they do not replace review of the release source, the change set, or the installation step that brings code into the environment.
Practical implication: Treat hash verification as an integrity control, not as a substitute for release review and trusted provenance.
Why scanner results are evidence, not verdicts
Secret scanning and runtime observation tools are bounded by what they inspect, what they can decode, and what activity their support matrix can actually see. A missed detection does not prove safety, and a rejected run does not undo secrets already transmitted. This is especially important where malware reads secrets at runtime rather than embedding them in source text or obvious output.
Practical implication: Use scanner output as one signal inside a larger containment and validation model.
Threat narrative
Attacker objective: The likely objective is to execute code early enough to access secrets or influence the runtime before defenders can rely on normal application import boundaries.
- Entry occurred through compromised package releases that introduced code able to run during Python startup.
- Credential exposure risk arose because malicious runtime behaviour could access secrets before application-level controls or explicit imports constrained execution.
- Impact is the possibility of stolen credentials, contaminated CI environments, and deceptive evidence that makes a compromised release look safe.
Breaches seen in the wild
- LiteLLM PyPI package breach: LiteLLM PyPI supply chain attack, credentials stolen from users.
- reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Package provenance has become an execution-control problem, not just a dependency-management problem. When code can run during interpreter startup, the security question shifts from what the application imports to what the environment executes before the application begins. That makes startup paths, installer trust, and repository hygiene part of the same governance boundary. Practitioners should treat package provenance as an operational control, not a documentation exercise.
Secret scanners are useful only when their detection boundary matches the threat boundary. Runtime secret theft does not need to leave obvious tokens in source text, captured output, or decoded artefacts. This creates a verification gap where teams mistake tool coverage for security coverage. The named concept here is runtime evidence gap: the mismatch between what a tool can observe and what an attacker can actually do. Practitioners should validate that their inspection boundary matches the attack path they are claiming to control.
Machine identity governance is implicated wherever build systems and hosted runners hold credentials. A malicious package that executes during startup can target CI tokens, cloud credentials, and service account material that should never be available beyond the narrowest scope. That means NHI controls such as short-lived credentials, restricted issuance, and environment isolation are part of software supply chain defence, not separate programmes. Practitioners should align package trust decisions with machine identity containment.
Evidence discipline matters because good-looking output can hide a bad execution path. The article’s emphasis on retaining the exact artifact, producer identity, observations, and decision reflects a deeper control need: security review must stay attached to the specific release and environment that were actually tested. That is a governance requirement, not just an incident-response habit. Practitioners should require reproducible evidence before accepting a dependency as safe to deploy.
From our research library:
- Software supply chain attacks were projected to cost organisations $60 billion in 2025.
- Read next: AI Supply Chain Security and AI-BOM Guide
What this signals
Runtime evidence gap: software supply chain governance fails when teams trust scanner output more than the code paths that can run before the application starts. The practical shift is to validate startup behaviour, installer trust, and runner credentials as one control surface rather than separate concerns. That is the only way to avoid overclaiming coverage from a tool that cannot see the full execution boundary.
For readers managing NHI and build-system exposure, the decision point is not whether a package is merely signed or hashed. The question is whether the environment still allows long-lived machine credentials to be present when unreviewed code can execute. Tight credential scope and environment isolation should be treated as supply chain controls, not optional hardening.
For practitioners
- Inspect startup-time execution paths Review .pth processing, site directory behaviour, and any interpreter startup hooks before you approve a dependency as safe in your environment.
- Separate integrity from trust Use hashes to confirm package integrity, but require release review, maintainer validation, and lockfile scrutiny before installation.
- Contain machine credentials in build and runtime Limit CI tokens, cloud credentials, and service account access so package code that runs early cannot reach long-lived secrets.
- Test the miss path as well as the hit path Use synthetic credentials to confirm what your scanners detect, then document the cases they miss and the control that compensates for each miss.
Key takeaways
- The incident shows that package trust must include interpreter startup behaviour, not only explicit imports or application code paths.
- Hashing, lockfiles, and secret scanning each answer a narrow question, but none of them alone proves a release is safe to execute.
- The control gap is around early execution and credential exposure, so teams should focus on provenance, containment, and evidence quality together.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Runtime code can expose secrets before application controls see the release. |
| NHI-07 — Long-Lived Secrets | The incident shows why long-lived CI and runtime secrets raise the blast radius of hostile package execution. | |
| Recommendation — Scan package installation paths for secret exposure and revoke any credential found in compromised runtime context. Shorten machine credential lifetimes so startup-time code cannot reach durable secrets. | ||
| MITRE ATT&CK | TA0006;TA0010 — Credential Access; Exfiltration | The attack pattern centres on runtime credential access and possible secret exfiltration. |
| Recommendation — Map package-execution abuse to credential access and hunt for exfiltration in build and startup telemetry. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is about constraining what machine credentials can reach during package execution. |
| Recommendation — Restrict entitlements for build and runtime identities so early-executing code cannot access sensitive resources. | ||
| CIS Controls v8 | CIS-5 — Account Management | Account lifecycle and scope matter when package compromise can touch CI and service accounts. |
| Recommendation — Audit account scope and disable persistent access for build and test identities that packages can reach. | ||
Key terms
- Install-Time Execution: Install-time execution is code that runs while dependencies are being installed rather than when an application is launched. In supply chain attacks, this matters because the install phase often has access to the richest secrets in developer and CI environments, making it a high-value privilege boundary.
- Package provenance: Package provenance is the ability to prove where software came from, who published it, and whether it has been modified before installation. In MCP sprawl, weak provenance means installation can happen faster than trust can be established, which increases secret exposure risk.
- Runtime evidence: Cryptographic proof collected from the environment a workload is using, such as image hashes, cloud-signed metadata, boot measurements or code signatures. It is the material a verifier checks to decide whether an identity should be trusted.
- Machine Credential: A machine credential is a secret or identity artifact used by software rather than a person. It includes service account credentials, API keys, tokens, and certificates. In practice, the main risk is not just exposure, but unmanaged lifecycle, unclear ownership, and overbroad access.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. It is designed for practitioners who need to connect machine identity controls to broader security and governance programmes.
Published by the NHIMG editorial team on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org