Terraform providers vulnerability detection

Viewed 31

Using a lot of (official and non official) terraform providers, I'm looking for a tool to perform security analysis on terraform providers before executing terraform plan/apply commands (and so executing providers code). I want to prevent malicious code from providers to be executed blindly.

I'm basically executing terraform providers mirror command to save local copies of required providers and I'm wondering if I can security scan that result.

I tested kics, checkov and tfsec but they are all looking for security issues in my terraform static code but not in providers.

Do you have any good advices regarding this topic ?

1 Answers

This is actually quite a good question. There are many other problems that can be reduced to same generic question - how to make sure that the thing you downloaded from the internet does not do anything malicious to you like e.g.:

  1. How to make sure that a minecraft plugin does not hack you?
  2. How to make sure that a spring boot dependency does not hack you?
  3. How to make sure that a library xxx you attach to your project does not do harm to you?
  4. Should you use docker image yyy in your project?

Truth is: everything you use has the potential to explode right in your face (or more correctly: right into the face of the system owner). That's why the system owner (usually a company) defines a set of rules to follow what is allowed and what is not allowed. No set of rules you are aware of? Below a set of rules we came up with ourselves when thinking about on-boarding a new library for some projects to use:

  1. Do not take random stuff from github. Take only products with longer history, small bug backlog, little to none past issues in the CVE list, actively maintained.
  2. Do static code analysis yourself. Sometimes it is possible to have tools that work on binaries level do that for you. Sometimes you can do it on source level only. In case of Java libraries, check what tools like Dependency Track think about the library and version you are about to use.
  3. Run the code and see how it works: what does it write, what does it read, what URLs does it communicate with (do a TCP dump if necessary).
  4. Document everything you have done somewhere.

This gives you no 100% confidence that things will not go terribly wrong. But this is a systematic approach that will reduce the risk of doing something stupid.

Related