Tooling: Testing IaC for security flaws

TL;DR

I made a Github Action that enables you to easily scan infrastructure code for security mistakes. Grab it on Github's Marketplace!

Overview

So, static code analysis for infrastructure code is hot! A few tools have appeared recently, and Checkov looks pretty good.

I tested it locally (as a command line tool on my laptop) against my aws-student-lab project. This terraform code just sets up a simple student lab on AWS, and I like to use it for testing new tools, since it's both simple and realistic. Checkov found no problems, and showed a nice green "PASSED":

The next step after local analysis, of course, is continuous integration, so I used Github Actions to run Checkov each time there's a commit. This involved writing a small yaml snippet.


To avoid having to do this setup on each repository, I decided to make a new Github Action and publish it on the Github Marketplace. This way, other people can easily integrate Checkov in their CI with minimal configuration!

Deep-dive test-drive

To test out Checkov and my new Github Action, I added the definition for an S3 bucket in my terraform code and gradually removed security features, to see if Checkov complains.

Starting with a nice secure bucket:

This bucket is pretty ok: it has encryption, versioning, logging and MFA confirmation for deletions.

As expected, Checkov checks everything and is happy, so the build passes:

Then, I decided to remove most of the nice features and options. Checkov breaks the build and complains:


The output is very helpful in determining how to fix this:

• Ensure all data stored in the S3 bucket is securely encrypted at rest
• Ensure the S3 bucket has access logging enabled
• Ensure all data stored in the S3 bucket have versioning enabled
• Ensure S3 bucket has MFA delete enabled

Nice! Working backwards, someone who sees these errors can look up cloud provider (AWS in this case) and terraform documentation and enable the missing features, reaching a more secure configuration.

Overall I'm happy and will be using this on all my future cloud code.

Pull requests are welcome!

Asynchronous communication

For years now I've lived with email notifications turned off. Both at work and home accounts. It's never caused a problem, since people know how to reach me for emergencies, and I believe it has helped me be calmer and more productive.

Doist explains why asynchronous communication leads to increased productivity.
The article is great, and here are some highlights:

Real-time communication comes with a few downsides:

• Leads to constant interruptions,
• prioritizes being connected over being productive,
• creates unnecessary stress,
• leads to lower quality discussions and suboptimal solutions.

Having a more asynchronous way of working is better because of:

• Control over the workday = happier and more productive employees,
• high-quality communication versus knee-jerk responses,
• better planning leads to less stress,
• deep work becomes the default,
• automatic documentation and greater transparency,
• time zone equality.

And here's how to get there:

• Plan ahead to give people time to consider your message,
• after meetings, document discussions, and outcomes,
• turn off notifications,
• evaluate people based on their output and results, not how responsive they are or the number of hours they work,
• emphasize trust, organization, independence, and accountability,
• adopt a Direct Responsible Individual (DRI) model for management and decision-making,
• make transparency a priority,
• use tools that promote transparency, deep work, and async communication.

Meta: Managing engineers

Dear engineering managers, here’s an excellent 17' talk of a Github manager on “How to grow emotionally intelligent engineering teams”.
It’s really to the point imho. Highly recommended to watch!