Do you guys know a strategy to avoid flow tampering from the editor caused by evil plugins? I created one for NRG Sentinel that doesn't use the editor, but I want to know if you know a reliable way to do it from the editor. Right now I believe it is impossible because an editor with plugins can't b…

Sentinel’s Safe Deployment mechanism introduces a controlled review process for all flow changes. When a user deploys a flow, the server does not apply the changes immediately. Instead, the proposed deployment is placed into a Deployments Queue. To review the changes, the user opens the dedicated …

This marks the beginning of the vision for Sentinel’s Flow Diff tool. Whenever a deployment is requested—whether from the client or the server—it is not applied immediately . Instead, Sentinel intercepts the request and places it into a deployment queue . Rather than following the normal deployment…

Once all changes have been reviewed and approved, the user can proceed by clicking the Deploy button. At this point, a confirmation modal appears before the deployment is finalized. By requiring this explicit review and confirmation workflow, NRG Sentinel ensures that no flow tampering can occur wi…

NRG Sentinel can be found here NRG Sentinel — Runtime Security for Node-RED Block credential theft, monkey-patching, and 30+ attack vectors in your Node-RED installation. No core modifications. Offline license verification.

Looks like you put a lot of effort in this. What i am wondering: this is all based on the assumption that changes/deployments are done directly into production environments ? If production is airgapped and changes are tightly controlled via processes and CI/CD, how do you see this working ? I conc…

I concur with @bakman2 - however, this tool might find a place in a final test environment such as UAT. To do verification tests prior to production implementation. By the time you get to production, you should already be totally clear about what is being implemented, why and its implications on sec…

@bakman2 @TotallyInformation People routinely apply patches to production packages assuming “it’s just a patch” and won’t impact their flows. That assumption doesn’t hold in Node-RED. A patch can change node behavior, tweak defaults, or introduce side effects—and it can even directly alter existing…

[image] bakman2: i can imagine that a hash comparison/verification for dev/test > prod for deployments would make sense. That’s a solid starting point, but it doesn’t address the real risk surface. Hash comparison assumes the flow that gets deployed is exactly what the user reviewed. In Node…

[image] AllanOricil: assuming “it’s just a patch” and won’t impact their flows. That assumption doesn’t hold in Node-RED. Doesn't hold in nearly every case as it happens. However, these things sit under a risk-based management approach. You have to decide whether rapid patching is less or mor…

How to prevent Last-Mile Manipulation to Flows

General

krambriw 18 March 2026 09:40 9

I think what @AllanOricil describes here is really relevant. If you use NR in production I can image the tool can help in the verification process, especially if shared nodes are being used (for free) in the customer delivery

Topic		Replies	Views
NRG Sentinel, runtime security for Node-RED Share Your Projects	65	1209	12 April 2026
Flow Security, If, then How can it be done? Feature Requests security	71	5464	4 September 2024
More security considerations General	2	1063	6 October 2018
Do you consider it best practice to "keep flows vanilla?" General	25	1640	14 November 2019
Nodered hacked by adding invisible nodes General security	143	3109	6 March 2024

How to prevent Last-Mile Manipulation to Flows

Related topics