Skip to content

Snyk agrees to acquire CloudSkiff: Our commitment to keep driftctl open source

Protecting Codified
Cloud Infrastructures

Maintain reliability and security while moving at developers speed.

Track inconsistencies that were invisible so far.

Check your progress in your infrastructure automation journey with metrics that matter.

Delivering the full gains
of infrastructure automation

Infrastructure as Code is awesome, but reaching excellence in cloud infrastructure automation is super hard. You need to move at developer’s speed while ensuring security, reliability and efficiency.

Even once you’ve reached a reasonable automation level, the last mile to cover to enjoy its full gains is the longest. This level is also the hardest to maintain with so many moving parts and uncontrolled updates on the provider’s side.

At CloudSkiff, we be believe that every team should be empowered with the right tools and metrics to do so.

Infrastructure as Code coverage and drift detection

The first brick we’re building is an open source CLI that measures infrastructure as code coverage, and tracks infrastructure drift.

Infrastructure as code coverage

While the best practice would recommend to have as many resources as possible described as code, progressing in your infrastructure automation journey takes time. driftctl provides a simple infrastructure as code coverage metric, to help you assess where you stand and define areas for improvement on uncovered resources.

Drift detection

Drift can have multiple causes: from developers creating or updating infrastructure through the web console without telling anyone, to uncontrolled updates on the cloud provider side. Handling infrastructure drift vs the codebase can be challenging.

driftctl tracks, analyzes, prioritizes, and warns you about infrastructure drift.

State of infrastructure drift

What we learned asking 200 DevOps teams about infrastructure drift

As infrastructure as code (IaC) becomes widely adopted by users with heterogenous skillsets, and as IaC codebases become larger, it becomes harder to track infrastructure drift (when the actual state of infrastructure diverges from the IaC codebase). Can we define good metrics for drift and infrastructure code coverage to track how well IaC matches the actual infrastructure state? 

Drift can be driven by human input, poor configuration, applications making unwanted changes, etc. It has consequences on toil and efficiency, forces teams to put in place strict controls that decrease flexibility, and can have a security impact.

After interviewing 50+ teams to collect stories and feedback, about drift and surveying 200 teams of all size across Europe and the USA, we decided to share our findings and a few options to tackle drift in this study.