> It can benefit security too: no longer can "npm install" consume your private stuff. Worst case - take your source code and, given properly isolated dev env,

> It can benefit security too: no longer can "npm install" consume your private stuff. Worst case - take your source code and, given properly isolated dev env, take only development secrets and data, which must not be useful. GitLab team member here. Very good point, thanks. A different way for supply chain attacks, the local dev environment. Similar thought with install routines in extensions (and dependencies) that are scanning your local home directory, where Git/cloud/etc. secrets might be stored in plain-text. Fixable in my environment, can become a problem with teams and onboarding at scale. The limitations can also bring in new views, for example to switch to using time limited tokens instead of plain text auth (Hashicorp Vault, etc.) and evaluate more possible attack vectors, and ways to mitigate and observe security problems. A remote development environment runs in a sandbox, similar to a container in CI/CD jobs, can be limited with auth and access, and also be monitored for syscalls and other unexpected behaviour. Potentially interesting for Ops running the remote development platforms (e.g. Gitpod) - Falco, Cilium, eBPF, etc. for security observability. More updates and ideas in the eBPF day recordings from KubeCon EU last week. [0] [0] https://www.youtube.com/playlist?list=PLj6h78yzYM2PzqjM3DTYjiVZ42wXDp0Qg https://www.youtube.com/playlist?list=PLj6h78yzYM2PzqjM3DTYj...