To build secure software, we pay attention to many threats that come from outside. Malicious users attempting SQL injection, DoS techniques, and the like.

We also need to pay attention to threats from inside. By this I mean the software dependencies that we import and invoke from within our code. Malicious or compromised dependencies are not just a potent theoretical threat, successful attacks have been documented in the wild.

Given that we rely on dependencies, and that we need a streamlined process to keep them updated, how can we protect our builds from a compromised dependency?

I’ve been working on a tool to do just that, called hancock.


go get
go doc

Let’s play a quick round of word association. I say “end-to-end.”
You say …?

If you’re a cryptographer, I bet you say “encryption.” And with good reason: end-to-end encryption is a basic best practice and fundamental building block of secure communication.


Let’s apply strong authentication to our communication, even when unencrypted.

This is an update to an earlier post. Thanks to contributions on this thread and related bugfix. The Qubes operating system aims to be reasonably secure through isolation. One example of isolation: one virtual machine (“Qube”) runs the windowing environment, while other VMs run applications, which are displayed in that environment. This separation from the X11 environment means that an application, like skype or bluejeans, cannot share the screen. This is by design, and highlights the security that makes me a fan of Qubes.