3 ms·
Yes, sandboxing and ephemeral machines are far and away the best defense a CI system has against compiling/testing malicious code. But the vast majority of CI s
by phasmantistes 10y ago
Yes, sandboxing and ephemeral machines are far and away the best defense a CI system has against compiling/testing malicious code. But the vast majority of CI systems don't actually use ephemeral executors because imaging between runs is slow and rebuilding your whole checkout/object cache is expensive.
You don't need to own the CI server in order to own a project. You can take over all of the individual executors and replace their linker with your own version that links against an attacker-supplied backdoored fork of openssl (for an extreme and topical example). Doesn't even require constantly-running code which might be detected by a monitoring system, and naturally persists across reboots (but not reimagings).
I'm glad that GitLab is paying attention to these things. The Travis which is tightly integrated with GitHub also seems to do a good job, although I haven't looked into it extensively. But plenty of orgs run self-hosted CI that simply isn't up to proper security standards in this respect.
- sytse 10y agoRebuilding is expensive. We have several caching mechanisms but there is no silver bullet and caching itself can lead to security problems. For a deeper review of security problems we're currently focussed on please see https://gitlab.com/gitlab-org/gitlab-ce/issues/21911 https://gitlab.com/gitlab-org/gitlab-ce/issues/21911 and please feel free to contribute there.
- Snappy 10y agoFor a discussion on caching and artifacts, please see https://gitlab.com/gitlab-org/gitlab-ce/issues/21913 https://gitlab.com/gitlab-org/gitlab-ce/issues/21913.