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.
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)
- One nightly release, named with the hash of the corresponding commit.
- One official release every two weeks, using the SemVer standard.
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.The post KICS – How We Made It appeared first on Checkmarx.com.
Article Link: Exploitable Path – How to Solve a Static Analysis Nightmare