Hello, beautiful people, and welcome back to my newsletter.
It has been a while, and I had a little think about what I want to share in this newsletter and whether and how I want to continue it.
First off, it will come back again weekly.
Secondly, it might be different every week. You see, the reason that I did not continue the newsletter and did not post regularly is that it felt like "yet another chore" at some point. So, let's change things up.
Enjoy this week's newsletter.
Sponsor i.e. the amazing people who make this newsletter possible
Rootly automates manual tasks like creating an incident channel, Jira ticket and Zoom rooms, inviting responders, creating status page updates, postmortem timelines, and more.
Want to see why companies like Canva and Grammarly are using Rootly? https://rootly.com/demo/
PS. If you are a company, financially support your content creators. Here is a little song about it.
Companies I am looking into
This month, I am looking into env0. So who and what is env0?
env0 provides Infrastructure as Code management that works with Terraform, OpenTofu, Pulumi, CloudFormation, and more. On top of your IaC definitions, users can define CI pipelines to enforce runtime policies, RBAC and provide variable management.
env0's team is also one of OpenTofu's founding members and part of its steering committee.
Subscribe to my YouTube channel to see a full demo of OpenTofu and the env0 platform!
State of Open Con – OpenUK – London
State of OpenCon 2024 is happening THIS week on the 6th and 7th of February! You can still get last-minute tickets.
I jumped on a call with OpenUK's CEO Amanda Brock to chat about the conference:
Meetups in London
Things I read into – Security
I'm a big fan of reading research papers, not necessarily to get more information but just in general because I like to see how academia thinks about the industry, tools and technologies.
So this week, I read about the use of Software Vulnerability Databases:
There are several research projects/papers whose goal was to generate a new vulnerability database. If you are familiar with vulnerability databases, you know that the main one is the NVD – National Vulnerability Database (also highlighted in the paper as the main one used in the research cited). Additionally, vendors are providing their platform-specific vulnerability databases.
What I found interesting in the paper is that multiple researchers aimed to generate “new” vulnerability databases. This has been done by combining existing databases or identifying vulnerable patterns in open-source projects and mapping vulnerabilities against them to build a new vulnerability database.
Overall, the goal is to create one database with more accurate and comprehensive information than a single database, such as NVD, could provide.
Other papers detailed the process of creating a database that can automatically identify project vulnerabilities.
The main issue that researchers had with existing vulnerability databases is the following:
People still have to piece a lot of information together when using vulnerability scanners – especially when using open-source tools. When I use Trivy, I often don't go into the details of each CVE but try to update my deprecated & vulnerable dependencies. Generally, it is enough for me to eliminate the third-party dependency/resource from my project. If you want to know the kind of code that could expose your project to attacks, you must look in detail at the vulnerability and what security researchers identified.
This leads us to last week's major vulnerability that many people discussed.
Vulnerability Leaky Vessels (runc CVE-2024-21626)
Leaky vessels (runc CVE-2024-21626) – they are container breakout or container escape vulnerabilities. "An attacker could use these container escapes to gain unauthorized access to the underlying host operating system from within the container" (Source) "The main recommended mitigations involve upgrading to runC version 1.1.12 and BuildKit version 0.12.5" (Source) At the time of writing, there are four vulnerabilities disclosed, related to the exploit. For more information, check out this open source project by Snyk.
"You will likely need to update your Docker daemons and Kubernetes deployments, as well as any container build tools that you use in CI/CD pipelines, on build servers, and on your developers' workstations." (Source)
Interview question of the week
In line with the vulnerability detailed in the section above. What is runC?
My answer:
In short, runC is a lightweight, portable container runtime. It makes use of a set of lower level system features such as “control groups”, “namespaces”, “seccomp”, “capabilities”, “apparmor” to create a sandboxing environment capable of abstracting the specifics of the underlying host. (Source)
You can use runC directly for running containers. "Unlike docker, runc doesn’t abstract tedious tasks under the hood and rather expects you to arrange whatever is it that is required for it to work." (Source) Here is a blog post on getting started working directly with runc.
Here is a deep-dive on runC by mkdev. They also have a really good weekly newsletter.
Top Meme
