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.
TL;DR
go get src.d10.dev/hancock/cmd/...
go doc src.d10.dev/hancock/cmd/hancock
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.
TL;DR
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.