KICS – the open source project sponsored by Checkmarx, created to help developers and organizations keep their Infrastructure as Code (IaC) projects secure – recently passed a major milestone, accumulating 15,000 downloads from DockerHub. For all of us that have been involved in the project, but in particular for the development team behind it all, this is exciting news. It’s great to see the adoption and support from the community for this project. As well as container downloads, the project on GitHub has had plenty of clones, forks, and pull requests. We’re pleased that the tool has proven useful and thrilled about the potential to grow the functionality into both new IaC platforms and into whole new areas.
Take, for example, API security. Since APIs are the way that so many of the services that work together to make complex (or in a micro services architecture, even simple) applications function, the management of APIs has become critical. If anyone has written code to use an external API, you may have experienced the frustration of inconsistent implementations or sub-par documentation. The introduction of frameworks like Swagger (now the “Open API Initiative”) are an attempt to fix this. Now API’s can be described in a standard way that anyone, or anything, can understand. API’s that adhere to the standard can be mapped and visualized for easy review by developers, product managers, or even marketing. They are also easy to parse and automate API consumption by API client processes.
With this standardization also comes the ability to parse and analyze API specifications for security best practices or misconfigurations. I’m pretty sure we have a tool that’s built to do that kind of thing.
But first, why? Why do we need to scan API definitions for security? To quote Daniella de Cruz, head of our scanning research and development, “APIs are the main entry point of modern applications.” APIs have become the receiver of user input and the gateway to backend data stores, so they are a key part of an application’s attack surface area. Taking this into account, not analyzing their design for security misconfigurations seems like a bad idea, especially when the machine-readable nature of an Open API definition lends itself to easy automated scanning.
The next logical question is “for what?” What should your security robots be looking for as they sift through your API definition files? Turns out, there are good number of errors that can have security repercussions.
Some examples I found from looking through the KICS API security queries on GitHub:
- Using HTTP instead of HTTPS in the path for server objects
- Using deprecated OAuth security settings
- Not having security schemas applied to paths (or a global security schema)
