At GitGuardian, as cybersecurity experts, we understand there are a variety of reasons our customers might not want a cloud-based solution, but still want the services we have to offer. The issue for them is that the bulk of our products analyze source code, meaning our cloud-based offering requires passing their data through our servers via the internet. For some of these customers, having that data leave their premises is not an option.
It may be any combination of the following leading to this decision:
We understand and respect that. Providing them with a self-hosted offering not only makes it possible for us to offer a solution meeting their requirements, but furthers our mission of helping developers create more secure software. We believe our tools and services have positive ripple effects that extend well beyond our customers. Every time we help one of our customers secure their code, it makes their customers more secure too.
Deciding to do something and achieving it are two different things, though. Once we decided to provide our customers with this option, we had to focus on some main issues to make this something we considered worthy of offering.
Our GitGuardian self-hosting documentation addresses this issue head-on. As our tools use multiple services, creating a container-based service cluster with Kubernetes allowed us to standardize the self hosted model.
We followed that by offering a variety of ways to create that cluster using well-known DevOps tools. The first and easiest option is to create an "embedded" Kubernetes cluster on a system that meets our hardware requirements. If your team is not well-versed in Kubernetes and you don't have an existing Kubernetes cluster with which you want to integrate, this is an easily deployed self-contained option with a gentle learning curve.
To integrate our cluster into your existing Kubernetes cluster, we chose to offer options using the KOTS, a plugin and admin console to help manage Kubernetes Off-The-Shelf software or Helm, an open-source tool for installing and managing Kubernetes applications that has broad industry adoption. We provide detailed documentation s for both KOTS-based installation or Helm-based installation.
Once installed, you can use the graphical user interface KOTS or directly Helm to manage the application and perform updates.
It's also possible to create an airgapped installation using KOTS or Helm if you need to completely isolate the cluster from the internet.
While we do everything we can to secure our own software, it has open-source dependencies like most modern applications. Making sure we shipped installation packages with zero CVEs required a lot of examination of our software supply chain and chasing down a number of issues. To help us do that efficiently and successfully, we chose to use Chainguard. As a matter of fact, they've produced a case study on why GitGuardian chose Chainguard.
Using Chainguard not only helped us reach our zero-CVE goal, it reduced our image size by 33% and the time savings help us deliver product and security updates quickly. It provides additional benefits for our customers with sigstore cryptographic signing of our images to verify authenticity and a software bill of materials (SBOM) created at build time for those customers who need to comply with customer or governmental mandates requiring insight into their supply chains. Chainguard also helps us achieve FIPS and SLSA compliance, meeting the needs of customers with high compliance bars to clear.
With these tools, both we and our customers can have peace of mind… backed up by evidence and data. You'll probably agree that evidence is the best and most reliable foundation for peace of mind. We believe we should earn your trust every single release with proof you can verify and validate.
No software gets shipped without at least a few customers running into an issue. And as the old saying goes, "it's always five o'clock somewhere." That also means that there's always a business open somewhere. We optimized our support desk scheduling to ensure that no matter what time of day (or night), we'd have a mix of support reps with Full Stack and DevOps skills to help customers around the world diagnose and fix their issues in a timely manner.
Our installation process runs multiple checks to ensure compatibility with the host system. Once running, the service has monitoring functions to alert customers to problems. To enable informed diagnosis, we provide a tool for our customers to package up system monitoring and operational data on demand and send it to us when they need support.
"GitGuardian self-hosted empowers us to stay compliant with privacy and security regulations. The OpenShift setup streamlines automated scaling and installation management, all while keeping our data inside the perimeters of our company. Moreover, GitGuardian consistently provided us with prompt and competent support throughout the setup and update phases, further solidifying our trust in their capabilities."
— Fedor Gamper, Project Owner Application Security at Swiss Federal Railways (SBB)
GitGuardian's self-hosted offering allows us to meet our customers where they are and provide our services how they need. We make it easy for them to install, manage, update, and get help with the self-hosted offering. And we provide peace of mind through security mechanisms and transparency that help them not only reassure internal stakeholders, but meet the needs and/or requirements of their customers.
If you've been curious about GitGuardian, but the cloud-based service was a non-starter, book a demo with our engineers to see how our self-hosted option can meet your needs.
*** This is a Security Bloggers Network syndicated blog from GitGuardian Blog - Code Security for the DevOps generation authored by Greg Bulmash. Read the original post at: https://blog.gitguardian.com/gitguardian-self-hosted/