The normal assumption that package installation is the only risky moment breaks down. A transitive gem can fetch remote code, alter execution flow, and trigger persistence as soon as a library is imported. That means dependency review must extend beyond install hooks to include top-level code paths and any side effects that occur during ordinary application startup.
Why require-time execution changes the risk model
When a Ruby dependency can run code at require time, the trust boundary moves earlier than many teams expect. The risky moment is no longer limited to gem install or post-install hooks, because ordinary application startup can now become the execution path. That changes how you review dependencies, how you stage updates, and how you think about what “safe to import” really means.
The practical consequence is that dependency evaluation has to cover top-level Ruby code, not just packaging metadata or installer behavior. A library import can now perform network access, modify runtime state, register callbacks, or pull in additional behavior before the application has fully initialized. In other words, startup becomes part of the attack surface, not just a plumbing step.
For supply chain security practitioners, that is a material shift in the control objective. You are not only asking whether a package was published honestly, but also whether its load-time behavior is acceptable in your environment. Open source supply chain guidance from OpenSSF is useful here because it frames dependency trust as a lifecycle issue, including provenance, review, and operational hardening around third-party components.
What failure looks like in an import-time attack path
Require-time execution breaks the assumption that code is inert until explicitly invoked. If a transitive gem can execute at import, a developer may never call the suspicious function and still trigger the payload simply by loading the library. That makes the attack path both low-friction and easy to hide inside normal application behavior.
This pattern is especially dangerous when the payload is designed to blend into initialization. A malicious dependency can fetch remote code, rewrite process behavior, hook later execution, or establish persistence in a way that looks like normal bootstrap logic. The user experience is often just “the app started,” while the security effect is arbitrary code execution during the most trusted part of the lifecycle.
That is why build-time and install-time scanning are necessary but insufficient. A package can be clean at install and still be unsafe at import, so reviewers need to inspect side effects in load paths, transitive dependencies, and any code that runs before first request or job execution. The LiteLLM PyPI package breach is a concrete reminder that package trust and runtime behavior can diverge in ways that matter to defenders.
What to change in dependency review and startup controls
Teams should treat import-time behavior as a review gate, not a surprise edge case. Code review needs to include top-level statements, module initialization, transitive gem behavior, and any network or filesystem activity that occurs before the application reaches a known-good state. For high-trust services, the goal is to know what executes simply because the library was loaded.
Practically, that means preferring dependencies with minimal side effects, pinning versions, and testing startup in a controlled environment where outbound access and runtime changes are visible. It also means watching for libraries that perform configuration discovery, automatic registration, telemetry calls, or lazy loading that is not actually lazy. If the library can alter execution flow at require time, it deserves the same scrutiny as an installer hook or a bootstrap script.
Practitioner takeaway: The right control question is not “does this gem look safe to install?” but “what happens the moment the runtime loads it?” If a dependency can execute before your application has asserted control, treat that code path as part of your trusted computing base.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while SLSA, NIST CSF 2.0, CIS Controls v8 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| SLSA | Supply chain integrity | Require-time gem execution is a software supply-chain trust problem. |
| Recommendation — Verify dependency provenance and pin trusted build inputs before promotion. | ||
| NIST CSF 2.0 | PR.DS-01 — Data-at-rest is protected | Dependency imports can expose or alter code and configuration data during startup. |
| Recommendation — Protect startup artifacts and sensitive configuration from unauthorized modification. | ||
| CIS Controls v8 | CIS-15 — Service Provider Management | Third-party gems are external providers whose behavior must be governed. |
| Recommendation — Inventory third-party components and assess supplier risk before adoption. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | Import-time side effects are an application architecture and secure coding concern. |
| Recommendation — Review module initialization paths for unintended execution and side effects. | ||
| MITRE ATT&CK | Supply Chain Compromise | Malicious dependency code executing at load time fits supply-chain compromise patterns. |
| Recommendation — Model dependency abuse as a supply-chain intrusion and hunt for early execution paths. | ||
Related resources from NHI Mgmt Group
- What breaks when security fixes require a new container image every time?
- What breaks when a dependency can run code during build time?
- What breaks when a malicious dependency can execute on import in a build or ML pipeline?
- What breaks when a malicious dependency can execute on developer machines but skip CI?