When the Shai-Hulud v2 supply chain attack hit last week, I watched thousands of developers scramble to check their systems. Mine? I was able to mark it as safe. This was because I’d already layered in some straightforward security practices. If you’re wondering how to protect your own development environment from these kinds of attacks, I’ll walk you through the exact configurations and tools I use every day that kept me safe.

Did you know that dev containers can have their own private Visual Studio Code extensions? By understanding some of the life cycle of the container, it’s possible to create and use extensions that are designed to support a specific dev container or Codespaces environment.

The world of dev containers is constantly changing. Sometimes, even with community-driven specifications, there is a bit of room for interpretation. The initializeCommand lifecycle script is a great example of this, and the specification has been updated to align with the implementations. Learn how this affects your dev containers (and why your scripts should always be idempotent).

Sometimes you just need a little human interaction. And sometimes you need that to happen when you’re starting up a dev container so you can configure the environment. Thankfully, there is a way to get user input that works with most of the dev container implementations.

There are many ways to automate the process of marking directories as “safe” to avoid the “detected dubious ownership in repository” message. Last week, I discussed how to modify the devcontainer.json. This week, let’s see an alternative using Dotfiles.

Development Containers and Codespaces bring infrastructure-as-code to developer environments. This post walks through creating a container for editing and deploying Bicep templates to Azure.

Tired of spending your time setting up resources? It’s time to learn how to implement development environments using infrastructure-as-code with Dev Containers, Codespaces, and Gitpod!