A CommonJS bundle is the Node.js module format loaded through require() and executed when the file is imported. Because top-level code runs on load, a malicious change in the bundle can trigger immediately, even if package install scripts are clean and no explicit function call occurs.
Expanded Definition
A CommonJS bundle is a Node.js module artifact that uses the require() pattern and executes top-level code as soon as it is loaded. In NHI security terms, that means the bundle is not just a container for code, but a delivery point where trusted build outputs can still carry immediate runtime side effects.
This matters because CommonJS behavior is synchronous and load-driven, which differs from formats that defer execution until a function is called. In governance terms, the risk is not only what the code does, but when it does it. A malicious or compromised dependency can exfiltrate secrets, alter token handling, or modify agent tool access during import, before application logic has a chance to apply controls. Definitions vary across vendors when comparing CommonJS with package supply-chain risk, but the security implication is consistent: import-time execution expands the blast radius of a poisoned dependency. For broader NHI context, see Ultimate Guide to NHIs and the NIST Cybersecurity Framework 2.0.
The most common misapplication is treating a CommonJS bundle as inert build output, which occurs when security reviewers assume package installation is the only execution checkpoint.
Examples and Use Cases
Implementing CommonJS bundles rigorously often introduces inspection and testing overhead, requiring organisations to weigh faster delivery against stronger control over import-time behavior.
- A service account SDK bundle loads a dependency that reads environment variables on import, exposing API keys before the app starts.
- An AI agent tool wrapper includes a CommonJS utility that patches request headers at load time, changing outbound identity context unexpectedly.
- A CI pipeline installs a package cleanly, but the bundle executes top-level code during deployment and seeds a backdoor token into a config cache.
- A monorepo publishes an internal module that silently calls a telemetry endpoint when required, leaking host and tenant identifiers.
These scenarios are easiest to spot when teams compare dependency provenance with execution behavior, not just package hashes. NHI Mgmt Group’s Ultimate Guide to NHIs is useful for understanding why secrets sprawl and excessive privilege make import-time execution especially dangerous. For build-system context, NIST Cybersecurity Framework 2.0 helps frame the need for secure development and monitoring controls around software supply chains.
Why It Matters in NHI Security
CommonJS bundles are security-relevant because they can trigger identity abuse without an explicit function call. If a package import runs code immediately, a compromised bundle can access credentials, rewrite auth flows, or establish persistence before access reviews, secret scanning, or runtime policy checks have any effect.
This risk is amplified in NHI-heavy environments where service accounts, tokens, and automation identities already outnumber human users. NHI Mgmt Group reports that 79% of organisations have experienced secrets leaks, and 77% of those incidents caused tangible damage, which shows how quickly a small dependency issue can become a material identity event. In practice, the control problem is not just “is the code trusted,” but “what identity actions can this code perform at import time.” Teams should pair code review with dependency provenance checks, runtime monitoring, and strict secret handling. The Ultimate Guide to NHIs and NIST Cybersecurity Framework 2.0 are both relevant references for mapping that operational risk.
Organisations typically encounter the consequence only after a dependency update, at which point CommonJS bundle behavior becomes operationally unavoidable to address.
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 OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST AI RMF and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 | Import-time execution can abuse NHI credentials and trust boundaries in bundled dependencies. |
| OWASP Agentic AI Top 10 | A-04 | Agent toolchains can execute bundled code on load and alter agent behavior before checks. |
| NIST CSF 2.0 | PR.DS-6 | Software supply-chain integrity applies when bundle contents can execute immediately on import. |
| NIST AI RMF | AI risk management covers third-party code that can affect system behavior and trust at load time. | |
| NIST Zero Trust (SP 800-207) | SC-7 | Zero Trust assumes no implicit trust in code paths that execute before policy enforcement. |
Review bundles for unauthorized credential use and block top-level code that touches NHI secrets.
Related resources from NHI Mgmt Group
- What should IAM teams do when identity platforms bundle human, NHI, and AI controls?
- How should security teams evaluate an offensive security platform instead of a bundle of point tools?
- What breaks when an API key is shipped inside a mobile app bundle?
- What should organisations do when a public bundle exposes an API key?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 26, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
