Today, a DevOps workflow is critical to success: 92% of organizations are anticipating that half or more of their applications will be deployed in a DevOps workflow in the next two years (source: 451 Research). And tools like GitLab, GitHub, Jira, and Jenkins are the backbone of this workflow.
DevOps tools offer a range of services, from source code management to issue tracking, Continuous Integration, and Continuous Deployment. They’ve become an essential part of integrating software development and operations into one workflow, offering teams a dramatic boost in productivity.
As a result, many organizations have opted to self-host DevOps tool instances, deploying them on private servers – instead of buying into a license subscription. Self-hosting has clear advantages, including better protection of source code, customized auditing, and better compliance. However, provisioning access to self-hosted tools has often created a difficult trade-off between security and productivity.
Issues with Self-Hosting DevOps Tools
Some organizations may choose to make their self-hosted DevOps tool instance available on the public internet, which introduces several security risks. On the internet, an application has an increased attack surface: it’s susceptible to attacks and inadvertent employee errors. In fact, any error in marking a private repository as public could expose an entire enterprise’s code base. Even worse, there’s no way to ensure that only trusted users can access the code base. If credentials are compromised, then threat actors can exfiltrate sensitive source code.
The Security Problem
- A publicly available application is susceptible to attack and inadvertent exposure
- Security teams cannot ensure that only trusted devices access source code
In the name of security, organizations may also choose to grant access to only those users on a corporate network. Unfortunately, this harms productivity and collaboration. For example, if an employee wants to trigger a GitLab pipeline from a Slack slash command, they have to then IP whitelist all of Slack’s server IPs. It’s unlikely that IT and Security teams will approve such requests, given the level of risk it imposes on the organization. Using a corporate VPN also means that admins can’t easily grant access to mobile users (on personal devices) or contractors (on unmanaged devices).
The Productivity Problem
- Many DevOps and SaaS tool integrations won’t work because they require broad IP whitelists on your corporate network
- Admins cannot grant access to the different types of remote users who need it
Why you should self-host DevOps tools with Banyan Security
Banyan offers a zero trust security solution: access is based on user and device identity – not on IP addresses. This means that you can host your DevOps tools on a public domain without concern because only trusted devices will be able to access your source code. Banyan has built-in support for mobile devices and policy-based access for unregistered devices. We can also facilitate secure SaaS integrations with DevOps tools.
How to Self-host DevOps tools with Banyan
- Install the Banyan Connector
- Define your DevOps web service, and test the connection
- Update your security policy based on device identity, ensuring that only users with a High or Medium trust score can access your service
- Use Banyan to facilitate SaaS integrations
For a more detailed guide on how to protect your hosted GitLab using Banyan, check out our new cookbook.
