Reviewed Tug v2.0.0 (4923f0332df4a390ea0797a96752d5a1af7ef76b) and the upgrade branch through e6f5071004c791e6a0c0d2a0fbd42043ca500132. The review covered the control listener and API, operator and node credentials, WebSockets, deployment and artifact handling, ingress, secret delivery, backups and restore, CLI bootstrap and upgrades, dependencies, and release workflows. Findings below describe source-reviewed paths and scanner results. Severity reflects the privileges and conditions each finding requires.

Tug assumes trusted deployment authors with administrator-equivalent access to eligible workload hosts. Mutual TLS protects control traffic. Workload traffic, shared backup storage and runtime images have separate trust boundaries.

The remediation fixes SEC-11, SEC-12, SEC-14, SEC-15 and SEC-17, accepts SEC-13 as a property of trusted nodes, and fixes SEC-16 with the upgrade commands. None of it changes the wire protocol or a persisted format, so it ships as a patch and 2.x control, CLI and agents keep working together.

• Control egress and registry credentials. src/images/registry.ts resolves deployer-selected image registries from control’s network. A registry’s Bearer challenge can also select a different HTTPS origin and receive the registry’s configured Basic credentials. Registry redirects are blocked, manifest bodies are bounded, and digests are checked, but token response bodies are read without a byte cap. Treat private registries and their token issuers as explicit trust relationships. Restrict control and build-worker egress to authorized destinations, bind credential forwarding to approved token issuers, and cap token response bodies.
• Backup recovery remains a shared availability boundary. A node running a backup receives the shared destination credentials and its project’s repository password. When that storage identity can modify sibling prefixes, a compromised node can destroy other projects’ backups and control backups. Repository passwords protect contents independently. Separate control storage credentials and enforce prefix-specific workload grants and retention at the storage layer. Add an absolute server-side lifetime for agent jobs so heartbeats alone cannot keep an old authorization alive (remaining work from SEC-03). See Backups.
• Build snapshots can contain unrecognized secrets (SEC-06). Tug excludes known credential files and resolved credential paths, but a secret it cannot identify can still enter a local or remote build snapshot. Review the source context and its ignore rules before building. See CLI source snapshot rules.
• Upload and build resource limits remain incomplete (SEC-09). Multipart requests can write up to 64 files at 5 GiB per file by default, subject to disk and request time limits. Disk staging happens before project admission and before the writer queue. Per-file and archive expansion checks help, but there is no deployment-wide byte budget or concurrent upload budget. Build preparation can still delay unrelated writes while holding the global writer. Use a bounded staging volume, enforce aggregate size and concurrency limits, and move preparation out of the global writer. Remote builds execute on the control Docker daemon. An isolated builder reduces the scope of build failures and control-side egress.
• Install and release provenance. Publish jobs use npm OIDC and request npm provenance. The workflows use mutable action tags, the runtime base and Caddy image are tag-based, and the installer accepts an already-cached image by tag. Pin privileged release actions by commit, record and verify image digests and attestations at install and upgrade, and refresh helper digests through scanned updates. GitHub Actions secure use reference

The Tug lockfile had zero production advisories from npm audit --omit=dev. A full npm audit reported ten moderate package entries, all tracing to one minimatch advisory in lint tooling. minimatch advisory

Example dependency checks were separate from Tug’s runtime. The Node example had zero production npm advisories. Composer reported seven advisories across four Symfony packages in the Laravel example. OSV flagged the Django example’s direct Django==5.2.8 pin. Refresh those example dependencies before using them in production. Django 5.2.19 security release

Trivy 0.76.2 scanned the published Linux amd64 and arm64 image variants. Both architectures had the same counts. Each count is a package-advisory match per architecture, so one CVE can appear for more than one package.

The remediation adds regression tests for each fix: a raw malformed WebSocket upgrade (//[) that crashed control before the fix and now gets a 404 while control keeps serving, the event limit clamp, the role-based redaction of one-off commands over the events API and the watch stream, the loopback management ports in both the agent's allocator and control's endpoint resolution (and that a node's custom range is not filtered), hostname conflicts across scoped credentials, and escape stripping in human output. The full Node test suite (995 tests), type checking, lint and the formatting check passed on the remediation branch. The Docker integration suites were not rerun for this change.

New source findings were assessed by tracing the affected code and existing tests. Gitleaks 8.30.1 reported no matches across 388 commits reachable from local refs. A tracked-file scan for common private-key and provider-token markers also found no matches. Deployed firewall rules, branch protections, cloud IAM and backup-bucket policies, and production host patch levels were outside the available evidence.

This table summarizes the findings from 1 November 2026. The cleanup reran 101 existing regression tests covering the controls below. The dependency entry uses the resolved package versions and the 10 November audit results.