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 Taskforce
Within 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.
Ironically enough, with these in place, the bottleneck became the approval of Pull Requests rather than the development itself. By the deadline, not only the 1K queries milestone was reached, it was surpassed (~1.2K).
KICS Core – The Open-Source Quest
The 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)
All these verifications are surprisingly fast, taking about one minute – the time needed to have KICS ready for release after each successful Pull Request.
Provided that the quality grade passes in each CI step, KICS can be released at any time. Following open-source best practices, we produce:
- One nightly release, named with the hash of the corresponding commit.
- One official release every two weeks, using the SemVer standard.
Each KICS release includes bare sources, binaries for Windows, Linux, and MacOS, as well as a docker image made available on DockerHub.
KICS Documentation – Sharing the wealth
KICS works. It has a strong core able to analyze many types of IaC files and it has thousands of security rules. It is consistently released every two weeks; it is open source, and the team is proud of it! We just need to spread the word to the world!
For that matter, we built a website, and stored it in AWS. But that is only the beautiful landing page. The documentation site is generated on the fly, via MkDocs, from markdown files, and made available via GitHub pages.
We try to make KICS documentation as crystal-clear as possible, containing everything about the project, including roadmaps, tutorials on how to use, or how to contribute. Moreover, we set up a KICS community using Gitter. Some fellows started commenting outward, asking questions, and providing feedback right away.
KICS Management – Taming the beast
The team works in an agile way, following a Kanban approach. Managing the work this way becomes easy as we can naturally take advantage of GitHub integrated management capabilities.
We divided the work into projects and defined milestones to better organize the issues and requests to handle. Labels are applied to each opened issue allowing an easy understanding of their nature: bugs, features, security, query, enhancements, you name it.
To guide and better manage contributions from KICS users, we defined templates for bugs, features, new queries, and pull requests. With templates, we require important information and ultimately standardize the quality with which work is described.
Overall, KICS involves a multidisciplinary team of architects, developers, DevOps, and managers. It already has a few followers’ contributions and many more are expected soon. And you, dear reader, are more than welcome to contribute as well. It does not matter whether it is by just following the project, providing feedback, opening issues or feature requests, submitting code changes, or just using KICS to keep your IaC secure.