Cloud Native implies a complete change in philosophy on how modern applications are designed, developed, and deployed. Finally, monoliths are broken into small and self-contained microservices, independent and unaware of their context. Orchestration glues them together in applications that become more scalable, reliable, and utterly resilient. Orchestration, in this context, deals not only with the way microservices communicate or are composed, but also with infrastructural needs or specific configurations. While not long ago the provisioning of infrastructure and configuration was mostly a manual process, nowadays, and with the advent of the DevOps mindset, automation is pervasive and defined in code. Welcome to the era of Infrastructure as Code (IaC). IaC establishes a methodology with tools and technology for infrastructure configuration and provisioning through code. It brings advantages such as: automation, idempotence (e.g., replication of infrastructure for testing and production), consistency, self-documentation, cost-reduction, to mention but a few. However, similarly to traditional software development, it is prone to issues like misconfigurations or security vulnerabilities which may jeopardize not just a specific application, but on a much larger scale, the entire business and its underlaying infrastructure.
Did anybody mention code and vulnerabilities?Introducing KICS (Keeping Infrastructure as Code Secure): An open-source standalone engine powered by Checkmarx – a market leader in static code analysis – for detecting vulnerabilities, compliance issues, or misconfigurations from IaC in the context of cloud-native applications. As of its launch date, KICS comes with 1000+ security rules (queries in Cx language), supporting Terraform, Kubernetes, Docker, AWS CloudFormation, and Ansible across multiple cloud providers (e.g., AWS, Google Cloud or Microsoft Azure).
How we made KICS!In the beginning, KICS had only 50 queries, resided in a private repository, and existed as a standalone engine. At this time, the engine was able to read just a few IaC file types, convert them into an internal representation, and produce results in a JSON format. To make it a product, an ambitious goal was set with the objective of reaching 1K REGO/OPA queries in less than three months, and making it completely open source in less than two. It could have been easy if the full team were already on board, but we were far from it.
KICS Rules – the Students TaskforceWithin two weeks we were able to recruit a group of talented students to join the team and focus on creating more rules developed using REGO. REGO/OPA is a high-level declarative language for querying structured documents. For this reason, it was chosen to be the method for obtaining the IaC scan rules. The students picked up the development with ease using REGO and in less than a week of training, they were crafting rules and IaC samples – one true-positive and one true-negative per query –, following the recommended list of vulnerabilities and descriptions provided by the Checkmarx application security research team.
- Our target of creating 1000 rules was a major challenge. We adapted our processes and designs and created reusable libraries to avoid replication in our REGO code.
KICS Core – The Open-Source QuestThe initial focus of the core team was to make KICS completely open source. With the close supervision and valuable pieces of advice from our OSS consultant, Lior Kaplan, who accompanied the project, we broke the dependencies with the private repository, rewrote the commit history to make it agreeable, and moved it to the public GitHub repository https://github.com/Checkmarx/kics, under Apache 2.0 license. During this process, we created CI pipelines with GitHub Actions, keeping all KICS infrastructure within the Github environment. In no time, a battery of verifications was running, per Pull Request, in the pipeline. It addresses several quality aspects:
- Test coverage (with Codecov)
- Code quality (with SonarCloud and Codacy)
- Security (with CxSAST by Checkmarx and KICS itself, via KICS GitHub action)
- One nightly release, named with the hash of the corresponding commit.
- One official release every two weeks, using the SemVer standard.