CI/CD Platform · View 15 of 22 · Runtime
The rule this view states
- Isolation does not vary by trust class. A trusted branch build is contained exactly as strictly as a fork build, because a compromised dependency in a trusted build is indistinguishable from a hostile fork.
- What varies is credentials, cache write and publish identity. Those are three columns, and they are the whole of the difference.
- The interactive reproduction session inherits the run's class and never publishes, which stops "debug it interactively" becoming a way around the gates.
Why not a separate fork runner fleet
- A second, weaker fleet for trusted builds would be cheaper and is the common design. It fails the moment a trusted build pulls a compromised package, which is now the more likely attack.
- One substrate also means one thing to harden, one cold-start number to optimise, and no capacity stranded in the wrong pool.
Risks
- Scheduled runs are trusted and unattended, which makes them the best place to hide a malicious commit. They are low priority but not low privilege, and that asymmetry deserves its own monitoring.
