The Benefits of Eating Your Own Dog Food: RapidFort's Container Hardening Process

There’s an old saying about companies using their own products and services: “Eat your own dog food.” In fact, it’s been “verbed” as “dogfooding.” RapidFort is proud to eat our own dog food. In fact, we’ve even named part of our process the “dog food test” and it happens every time code is merged.

We’re not just SaaS providers; we’re developers and security experts making useful tools for other developers and security experts. We care about our products because we need them ourselves. We also give back to the community with free hardened container images, made possible with our products.

In the spirit of transparency, we want to share how we dogfood Rapidfort, our container hardening platform.

We trust our devs because we trust our product

RapidFort attributes its product’s technical capabilities to two primary factors: base images and complete trust in our dev teams.

Trust the devs, make them happy

Though many organizations put up walls between developers and the infrastructure, we give our dev teams complete freedom. We don’t impose strict rules and restrictions on how they use our infrastructure. They can import whatever open source libraries they need to speed up delivery of new and improved features. Traditionally, developers are given fairly tight constraints because open source software (and its dependencies) often introduces vulnerabilities.

It’s reasonable for organizations to want to protect their infrastructure and run a tight ship. The trade-offs can be well worth it: decreased velocity for increased security; reduced flexibility for higher consistency. We, on the other hand, don’t worry about these trade-offs. Our base images keep us golden.

Base images keep you secure

One of the main reasons we can offer our devs total freedom is our use of base images. We have three base images that always have the latest patches and software installed on them. Each base image provides a secure and safe context for developers to do their jobs quickly, efficiently, and with everything they need to deliver value.

Because our base images have everything pre-installed, they’re very big—over 5GB. We don’t have restrictions on tools or utilities. Our motto is: “Use what you need, develop quickly, and optimize.” When devs need something new in the base image, they file a request and the DevOps team adds it to the image.

Once the software packages are installed, devs are able to get their work done. They write code, commit, run everything through CI/CD, and deploy. Our CI/CD pipeline includes RapidFort’s hardening process, which reduces vulnerabilities by eliminating code in the containers. Let’s get into the detailed stats…

Metrics, numbers, and stats

Our three base images are the foundation for the nine microservices that compose all of our production s/w infrastructure. After these nine containers run through our dog food pipeline (which we’ll cover in more detail below), we see the following results:

We use Base Image 1 for seven application deployments, so we’re providing averages in the table above. The pre-hardened image sizes range from 4.7GB to 5.1GB. The post-hardening images range from 87MB to 904MB yielding size reductions from 82% to 98%, package reductions from 42% to 97%, and vulnerability reductions from 60% to 98%. 

Dogfooding and coverage scripts FTW

We dogfood our code as part of our CI/CD automation. The whole process looks like this:

• A dev checks in code and verifies locally that everything is good
• A smoke test runs to verify that the change doesn’t break the system
• The dev files a pull request
• A peer merges the PR to a staging branch
• Our “dog food test” runs to see the impact on all the known good containers in our workload
• Generate an instrumented (stub) container
• Run a coverage script to exercise the code
• Delete everything we don’t need from the container
• Build a new optimized container

If you’ve followed our Community Images project, you might have seen that we use coverage scripts to exercise the code in an image. A coverage script is not QA, nor is it functional testing. It doesn’t look for an output for a given input.  Instead, for every feature exercised (input), it observes the s/w components that are activated so RapidFort can see exactly what is and isn’t used by the workload.

We don’t want devs to worry about patching, so we always have the latest patched image available in a central location. Every derived container has the application logic installed on top. All of our containers go through the same dogfooding process and get individually tested, hardened, and optimized for every merge request.

RapidFort provides a solid foundation

Many organizations struggle with providing secure infrastructure for their dev teams. They resort to implementing problematic “shift left” policies, ineffective patching, and endless vulnerability whack-a-mole. We, on the other hand, provide total uncompromising flexibility to our developers.

RapidFort isn’t just a powerful tool for container security. It’s a developer enablement tool, too.

We use our software to improve our software. We increase developer efficiency by allowing them to use whatever software they need and securing it every step of the way.

You can use RapidFort for free today.