What is semantic analysis and why should you care?
Findings that matter
You've probably come across many terraform security scanners before. Most of them work in a similar way: they iterate over all resources (S3 buckets, EC2 instances, etc), take their properties and compare them with some pre-defined value. Encryption enabled? Yes: good, no: bad. Instance type is on a the whitelist: good, if not: bad.
This is a simple approach and works well when the goal is enforcing compliance with some company policy, however this generates a lot of noise for engineers to deal with and does surprisingly little in improving security.
Let me elaborate on this latter point. The founders of semdiff collectively spent decades as professional pentesters hacking into systems of various companies. What we found is that, when it comes to actually exploitable infrastructure misconfigurations, it almost always comes down to:
- something being accessible from a network that's not supposed to be
- something or someone having permissions that they don't supposed to have
- the previous two points applied transitively (something is accessible from a network that has some permissions to, say, secrets, that in turn grants more permissions, that allows more network access, ... you get the idea)
Furthermore, the root cause rarely is that someone applied an allow-any-any rule or gave Admin permission to some lambda function. Usually it's the result of a complex interplay between counterintuitive rules and policies with surprising behaviors, spread across various systems maintained by different teams.
Despite infrastructure-as-code making all these configurations potentially machine-readable, we see surprisingly little effort in creating automated tools that help you cut through this complexity and understand your infrastructure, instead of doing a very efficient check-box exercise.
Semdiff is such a tool.
Where we're going we don't need rules
When you make a change to some terraform code, terraform plan will tell you quite accurately what changes you're about to make: create a new security group, attach it to some instances, create a new version of an IAM policy. What it doesn't tell you, what the change means. Will it make the memcached server full of personal data accessible from the internet? Will the load balancers have permissions to read financial data? Will it make the payments page inaccessible by our customers?
When we first started working on semdiff, we spent more time than I'm willing to admit trying to figure out how to make questions like these easy to formalize into rules in some symbolic temporal logic. Turns out that no one likes to write rules, especially not in some exotic, logic-oriented programming language. On the other hand, engineers are extremely diligent in reviewing changes that go to production and are perfectly capable of deciding if the meaning of a change is what they expect or if it represents a security risk - it's just difficult for humans to keep every detail in their head.
Learning from this, we've designed semdiff to be a different kind of security tool. It won't block your PR and won't find countless nit-picky issues that doesn't improve security but you must fix before you can merge. It will simply tell you what your PR means and allows you to catch mistakes before they become security incidents.
Conclusion
Semdiff is still in development, but we wanted to show it early so we can collect feedback from the devops community. Would it be useful in your daily work? Is it missing some crucial features? Are we completely stark-raving mad? Tell us, in the chat box on the bottom right corner, or on the contact us page.
Laszlo