How To: Fast and Secure builds with Bazel Remote Cache

For the past few months, I’ve used mainly Scala programing language. Like any other language, I needed a toolchain to compile my code into something I could run. When I started with Scala, I chose to go with SBT. It went pretty well, but I wasn’t very happy with it – it is a bit slow, dependency management is not amazing, and some other issues.
So I started to look for alternatives, and I was surprised to learn how many alternatives are out there. Of course, I could use any Java tools, like Gradle or Maven – which both support Scala. Like SBT, each has its own downside. While I was looking for other alternatives, I wanted to find something with a good support monorepo development strategy (as we are slowly moving our code to monorepo). And at this point, I found Bazel, a build tool by Google.
Bazel is amazing and it can do a lot of things, including building Scala source code. One of the coolest Bazel features is the built-in support for remote caching, which aims to speed up build time. For lazy developers like me, the coolest thing here is the native support for Google Cloud Storage – so I could have “serverless” cache deployment. This all sounds simple, right? Until you ask: how secure it is? And this is where things become interesting! Continue reading “How To: Fast and Secure builds with Bazel Remote Cache”

Do we really need threat modeling?

I’m a huge fun of threat modeling. It’s a very powerful tool, that can find a lot of security issues. If you’re not familiar with it, check out my earlier post on the subject. For the past few years, I was struggling with one simple question: when should we conduct threat modeling? After all, threat modeling has a price – it takes time to conduct it, and usually involve a few peoples. We can’t conduct a full threat model for every feature – we need to find a way to identify the “interesting” features that require a threat model.

One very interesting solution to this hard problem was proposed by Izar┬áTarandach in this talk. In short, he proposes to tag features as “threat model worthy”, and once in a while go over all the features with this tag and review them. This is a really interesting approach, and I highly recommend you to watch the entire talk. However, from my experience, it’s not a silver bullet for this problem, and I want to propose an alternative approach.

Continue reading “Do we really need threat modeling?”

Threat Modeling as Code

Infrastructure-as-code (and GitOps) extend the use of source control (git) and code (well, manifest files) into a new field. This changed radically how we create infrastructure in the cloud, by making the process more robust and less error prone, and also easier for developers. Can we do the same for threat modeling? How can threat-modeling-as-code change and improve the way we do threat modeling today?

Let’s start with a really short introduction to threat modeling. Threat modeling is a practice that help us take a system design and look for possible security issues, by asking these 4 questions:

  1. What are we building?
  2. What can go wrong?
  3. What are we doing about it?
  4. Are we doing a good job?

Conduction a threat model helps to find issues sooner – and in most cases, detect issues that are hard to find using other practices. This is why conducting a threat model is a critical part in building a secre software. If you’re not familiar with this practice, I’m highly recommending this post by Adam Shostack, one of the authorities in the field. OWASP Threat Modeling project (and channel) is also an excellent learning resource.

Continue reading “Threat Modeling as Code”