Skip to content

Security model

Every ReduceWaste container runs on an internal network with no route to the internet. The only outbound paths that exist anywhere in the system are an opt-in signed update check and an opt-in, time-boxed, fully logged remote-support connection — both off by default and both admin-initiated. Factory telemetry is never sent off-site by either path. See Architecture & isolation for the network layout.

Workflows that use the local model to take an action (rather than just answer a question) run inside a short-lived, isolated sandbox:

  • The sandbox holds no database credential. Every data read or write goes through one gateway endpoint, POST /gw/data/{op}, which runs inside its own database transaction with that site’s row-level-security role already set.
  • The sandbox reaches the gateway only through a relay that forwards /gw/* and refuses everything else, over a network created just for that sandbox’s run.
  • The sandbox has no other mounts and no other network path — not to other sandboxes, not to the broker or historian directly, not to the internet.

Each site’s rows are protected by a Postgres row-level-security policy tied to a role set inside the same transaction as the request. A bug in a query cannot cross a site boundary, because the database itself enforces the boundary, not the application code.

ReduceWaste’s adapters are read-only toward operational technology in this release:

  • Modbus write function codes are rejected in code before a write is ever attempted.
  • OPC UA connections are opened as read-only sessions.
  • The edge reader is the only component that talks to field devices at all, and it sits in a DMZ-style position relative to the plant’s control network — see OT network safety (IEC 62443) for the deployment guidance this follows.

The app distinguishes operator roles (for example: engineer-level configuration access versus day-to-day operator viewing) and keeps an audit log of gated actions such as approving a new sensor registration. Authentication supports local accounts as well as common enterprise identity providers.

  • Every release ships a software bill of materials.
  • Release images are cryptographically signed.
  • Offline install bundles (see Air-gapped install) are signed, and the installer verifies the signature and the checksum of every file before loading anything.
  • A licence-allowlist check runs in CI: only permissive licences (Apache-2.0, MIT, BSD, ISC, PSF, MPL-2.0, EPL/EDL for broker/client code, and dynamically-linked LGPL) are allowed into the core distribution. Copyleft licences like AGPL/GPL and source-available licences like SSPL/BSL are blocked by that gate, which is how components such as a GPL codec or an AGPL library are kept out even if a feature would otherwise want one.