Execution-Path Review

Expanded Definition

Execution-path review is a supply chain security practice that evaluates the full set of actions a package can trigger, not just where it came from or which dependencies it declares. That includes build scripts, install hooks, post-install steps, and any other code that may execute during packaging or deployment. In the NHI and agentic AI context, this matters because a package can arrive through a trusted channel while still executing attacker-controlled logic before the application ever runs.

The concept overlaps with dependency review, but it is stricter. Dependency review asks whether a package version is approved; execution-path review asks whether the package can perform unsafe actions when tooling processes it. Definitions vary across vendors, but the security goal is consistent: inspect behavior, not just metadata. This aligns well with guidance from the NIST Cybersecurity Framework 2.0, which emphasises supply chain risk governance and change control.

The most common misapplication is treating a signed or popular package as safe by default, which occurs when teams skip script inspection during automated builds.

Examples and Use Cases

Implementing execution-path review rigorously often introduces build friction and slower release cycles, requiring organisations to weigh developer speed against the cost of deeper verification.

• A CI pipeline blocks packages that include install-time scripts unless those scripts are explicitly reviewed and approved.
• A platform team inspects post-install hooks in agent tooling to ensure no credential harvesting or unexpected network calls can occur.
• A security review compares dependency metadata with actual executable paths to detect cases where a benign package name hides risky behavior.
• Teams use lessons from the SpotBugs Token GitHub Supply Chain Attack to justify script-level controls, not just package allowlists.
• Incident responders trace a compromised package back to an install hook that executed before runtime monitoring could intervene, then update policy for future releases.

For implementation patterns, the NIST Cybersecurity Framework 2.0 provides useful language for governance, while NHIMG research on the GitHub Personal Account Breach shows how attacker access can cascade from account compromise into trusted distribution paths.

Why It Matters in NHI Security

Execution-path review matters because NHI systems often depend on packages, build agents, and automation runners that operate with broad privileges. If a malicious script executes during install or post-install, it can steal tokens, alter pipelines, or seed persistence into service accounts and agent workflows. That risk is especially severe where secrets are exposed to CI/CD systems or where packages are allowed to run with inherited environment credentials. NHIMG data shows that 96% of organisations store secrets outside secrets managers in vulnerable locations, and 79% have experienced secrets leaks, which makes execution-stage abuse a realistic route to compromise rather than a theoretical edge case.

This is also a governance issue. If teams only review source origin, they miss the point at which trust is actually consumed: when code executes inside the build or deployment path. NHI Management Group treats this as a core control boundary for preventing silent privilege abuse and for reducing the blast radius of compromised package ecosystems. Organisations typically encounter unexpected credential theft only after a build or deployment compromise, at which point execution-path review becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• What breaks when policy generation skips deny-path review?
• Who is accountable when a remote-control access path fails governance review?
• How should security teams stop fake verification lures from turning users into the execution path?
• Delegated execution path