CommonJS Entrypoint

The CommonJS entrypoint is the code path a Node.js application loads when it calls require(). If a package is poisoned there, the malicious code can execute during normal runtime rather than only during installation, which makes trust decisions about the package tarball and version especially important.

Expanded Definition

A CommonJS entrypoint is the first executable module a Node.js package exposes through Node.js module loading when another component calls require(). In security terms, it is the code path that determines what runs at import time, not just what is published in the package archive.

This matters because the entrypoint can do more than export functions. It can initialise network calls, load environment-dependent configuration, resolve secrets, or pull in additional modules that broaden runtime authority. For NHI and agentic systems, the entrypoint often becomes the earliest trusted execution surface for service accounts, automation jobs, and tool-using agents that consume third-party packages.

Usage in the industry is still evolving because “entrypoint” may refer to package.json metadata, the resolved main file, or a chain of re-exported modules. NHI Management Group treats the security meaning as the runtime file path that receives trust first. The most common misapplication is assuming a package is safe because installation completed cleanly, which occurs when defenders review only the tarball or lockfile and ignore code that executes on require().

Examples and Use Cases

Implementing controls around a CommonJS entrypoint rigorously often introduces release friction, requiring organisations to weigh faster dependency adoption against deeper package inspection and sandboxing.

• A service account loads a utility package during startup, and the package entrypoint immediately reads configuration from process environment variables.
• An internal agent imports a CommonJS library whose entrypoint performs a version check and then contacts a remote endpoint before any business logic runs.
• A CI/CD task requires a dependency that appears harmless in review, but the entrypoint executes file-system writes during pipeline runtime, which can alter build outputs.
• A defender compares the package’s declared main file with the actual runtime path to verify what executes when require() resolves the module.
• Teams use guidance from the NIST Cybersecurity Framework 2.0 to formalise software supply chain controls around trusted code paths.

The same risk pattern appears in published incident research from Ultimate Guide to NHIs, where package trust and credential exposure are repeatedly linked to runtime compromise rather than only install-time exposure. In practice, the entrypoint becomes the decisive review point when a package’s behaviour changes after it has already been accepted into a build or deployment pipeline.

Why It Matters in NHI Security

CommonJS entrypoints matter because many NHI workflows depend on unattended execution. Service accounts, workload identities, and automation agents often load libraries without human oversight, which means any malicious logic in the entrypoint inherits the runtime privileges of that identity. When an entrypoint is poisoned, the issue is not limited to the package itself; it can become a secret-exfiltration path, a persistence mechanism, or a bridge into downstream systems.

This is especially dangerous in environments where secrets are embedded in code paths or configuration. NHIMG reports that 30.9% of organisations store long-term credentials directly in code, which increases the blast radius if a loaded module can inspect memory, environment variables, or local files. Entry-point review should therefore sit alongside dependency pinning, publisher verification, and runtime restrictions recommended by NIST Cybersecurity Framework 2.0. The most common operational failure is assuming the package manager is the control boundary, when the actual risk is what executes after require() resolves.

Organisations typically encounter the consequences only after a secrets leak, suspicious outbound traffic, or an unexpected privilege escalation, at which point the CommonJS entrypoint becomes operationally unavoidable to address.