In KoalaLab’s endeavour to help companies solve the important and complex problem of securing their CI/CD pipelines, we are proud to introduce our 2nd OSS product BOLT, a tool for securing GitHub Actions Runtime.
GitHub Actions has quietly become the fastest growing CI platform, with it’s unique approach of YAML-based workflows, tight integration with GitHub's source-code management (SCM) and extensive marketplace of composable workflows aka actions, no wonder it’s eating the world & is now almost beating Jenkins 🙂
NIST’ securing CI/CD whitepaper and OWASP top 10 CI/CD comprehensively cover all risks which can broadly be summarised into the following buckets:
Security posture management of CI/CD pipelines, PBAC and flow control mechanism & adequate observability
Secure usage of secrets & environment variables inside the CI/CD
Best practices around 3rd-part dependencies (of both code and pipeline workflow code)
CI Runtime security
Spotlight covers the first two aspects of CI/CD security and PINNY covers some aspects of the third problem. With BOLT, we wanted to focus upon the CI runtime security.
Specific to CI runtime security, we believe there are 2 specific threat vectors:
Exfiltration of secrets
FiIe-tampering to inject code
BOLT uses transparent egress-filtering and auto-disables excessive permissions like passwordless sudo to secure GitHub Actions runtime from both the threats.
One of our pet-peeves has been that security rigor for securing SDLC or CI/CD pipelines has been lacking vis-a-vis production systems & we got inspired by some paradigms from the same to build:
Egress filtering for Build/CI environments
Observability of CI/CD systems, understanding performance & alerts for anomalous behaviour is just as critical.
Zero-trust, even for machine functions in CI environment.
BOLT is an amalgamation of above paradigms to secure GitHub CI systems.
Transparent egress filtering
a. As CI/CDs have evolved, there is download of a lot of data from registries which house open-source libraries which get utilised during builds and hence the egress traffic of build systems has become complex. Leaving it un-BOLT-ed would be a risky practice: BOLT allows you to whitelist your secure CI data sinks and block any unknown domains.
b. Architecture: In today’s world, where many sites are secured behind a WAF/CDN like cloudflare or AWS WAF, doing egress filtering at DNS level is an unreliable way to do egress filtering, hence our decision at BOLT to use an HTTP proxy.
c. Further, we understand that a more comprehensive way to do egress filtering would be to also inspect the traffic that is being routed….this is especially helpful because modern SDLC is dependent upon linux mirrors, container registries like dockerhub, github etc which themselves might be spoofed(as an attacker might have their own sub-account on such a registry)
BOLT uses eBPF techniques to allow only trusted registry accounts to be accessed.
Disabling Excessive Permission:
In terms of the other functionality, BOLT can be configured to disable passwordless sudo as the machine permission on the CI runner. This prevents any tampering of any kind of file that prevents a major way to backdoor a malware onto production systems.
BOLT is our endeavour to help organisations move towards a “secure-by-design” paradigm in terms of their CI systems. BOLT is completely open-source and covers Ubuntu runners, open-source & private repos and can be used for Github and self-hosted runners.
Please do checkout BOLT here at Github and give it a spin. Would love to hear from our readers any and all feedback.
Further, if you want to explore BOLT for other CI/CD systems and/or want to see our other products especially around workflow observability, please do contact us at
References
All images from an example BOLT run which can be seen here: https://github.com/koalalab-inc/Test/actions/runs/8972961790
Comments