Check Dockerfiles and infrastructure configuration for risks

How your application runs is often in your repository: in a Dockerfile, in Kubernetes and Helm files, in Terraform. We read those files and report configuration that opens too much. For every finding we point to the file and line.

Updated

What we look at in your configuration

Two well-known open-source scanners at a fixed version, without AI. Typical findings:

  • Dockerfiles: a base image without a fixed version, a container that runs as root, packages without a fixed version
  • Kubernetes and Helm: containers with too many privileges, missing limits
  • Terraform: parts of your infrastructure that are more open than needed

Why configuration in the repository matters

When your infrastructure is code in your repository, it changes with every commit. A setting that opens too much then arrives as fast as a new feature.

With AI assistants, teams write these files faster too. That's why the check belongs with every new version.

What we don't do

We only read the files. We don't connect to your cluster or your cloud account, don't start containers and change nothing. So this can't tell you what is live right now: only what your configuration asks for.

What you get back

For every finding: what it is, where it is and why it is a risk. For developers the file and the line, for the board a traffic light per topic. You decide what to change.

Questions we often get

Do you look into our running cluster?

No. We only read the files in your repository. You don't give access to your cluster or your cloud account.

Which files do you read?

Dockerfiles, Kubernetes files, Helm charts and Terraform. The scanners: hadolint for Dockerfiles and trivy for the rest, each at a fixed version.

Is this a penetration test?

No. A penetration test attacks a running system. We read the configuration and try nothing.

Do you change the configuration?

No. We fix nothing and write nothing into your repository. Your developers decide what to change.

Isn't this part of our CI?

Many teams run part of it themselves, and that's good. We run the scanners at a fixed version and set the result next to your tests, your documentation and your architecture.

Sign up for the pilot

The pilot is by invitation. Sign up, we check whether your application fits and email you. You connect your repository with read access only, the first check starts by itself, you see what is checked and what is proven, and then we ask what it is worth to you. Have a question first? Ask it in the message below.

Our team

Reads every sign-up and every question

Our team reads what you send and answers by email. A conversation only happens if you ask for one: with the people who do the work, not a salesperson.

We only use your details to respond to your sign-up. The website doesn't keep your request.