Why I Started Calethia

As I’ve shifted more and more time and thought into building up Calethia, I wanted to take a step back and remind myself why I was pushing so hard to make it a reality. My goal in writing this is to inform you of my goals and motivations, but also to give myself a reminder I can turn to from time to time.

I can distinctly remember three key events during my time at Snowflake that served as a key motivation. The first was during another one of our yearly scheduled audits. The auditor had asked for proof of certain detections we had in our SIEM. So I built a really nifty app where internal audit could use an LLM to search for rules and it would provide a link to our internal GitHub. And it worked really well. I turned it over to them, they used it, and then said that they still needed us to get screenshots with timestamp for them. I felt the wind go right out of my sails.

In an unrelated event, I was working with our corporate security team to build out some internal monitoring. They had asked me to write a detection to alert anytime someone did some particular action (the specifics of which are irrelevant). I said, “Ok cool, please link me the policy where we forbid users from doing this.” And I was met with confusion. “If we’re going to alert on something, we need to clearly tie it back to a policy saying the action is forbidden. Otherwise, when we engage with the employees, they’re going to reasonable ask ‘Why?’” And then after a bit of searching, it turned out we never had such a policy in the first place.

And then again, in another kerfuffle, we were updating policy regarding some kind of retention of sensitive data. In doing our due diligence to find and update existing references, we identified multiple different older policies, each with different requirements for how long certain types of data should be retained. We then had to spend weeks understanding what the actual source policies required and why certain requirements were interpreted one way vs another essentially redoing old work that was left underdocumented.

As someone who's spent most of their security career in security operations and offensive security, these events were both frustrating and confusing. I was so used to having tooling managed in code, with strong testing, deployment mechanisms, and version management. I realized that our GRC team, which sits at the root of so much of our security program, lacked the tooling to express and enforce their vision. It was then that I decided to build a true compliance-as-code platform to mirror the modern detection-as-code paradigm.

Policies would be expressed as code, so every detection or control could point back to the actual policy that justified it, instead of getting built first and questioned later. The platform would check for conflicting policies, so nobody spends weeks untangling which of five old documents actually governs how long you keep sensitive data. Git-ops would handle version tracking and require two party signoff, so a policy's history was as trustworthy as the policy itself. And I'd be able to define how those policies were enforced as code and automatically collect evidence, rather than rely on engineering or security teams to ship timestamped screenshots. It would all be extensible too, so as environments, tooling, and frameworks changed, the platform could evolve with them.

At too many organizations, GRC is begrudgingly done to achieve some certificate so a team can make sales. While Calethia can help these teams (for cheaper than other black-box systems), it’s also built with the vision that compliance can be engineering driven and truly deliver more secure systems and companies in a frictionless way.