The DevSecOps Talks Podcast

This time we got to talk about Lingon, an open-source project developed by Julian and Jacob who is a frequent podcast guest. Discover the motivations behind Lingon's creation and how it bridges the gap between Terraform and Kubernetes. Learn how Lingon simplifies infrastructure management, tackles frustrations with YAML and HCL, and offers greater control and automation. Connect with us on LinkedIn or Twitter (see info at https://devsecops.fm/about/). We are happy to answer any questions, hear suggestions for new episodes or hear from you, our listeners.

Diving into the world of bare-metal servers, Mattias takes the helm solo for this episode. He's accompanied by special guests Michael Wagner and Ian Evans from Metify, the company that powers Mojo - a leading platform for bare-metal provisioning automation. While we often chat about the big cloud service providers, this time we're switching gears. If you've been curious about how real-world, physical servers are set up and managed, this episode is just for you. Join Mattias, Michael, and Ian as they dive into the nuts and bolts of setting up servers - a topic that Mattias is super passionate about. Connect with us on LinkedIn or Twitter (see info at https://devsecops.fm/about/). We are happy to answer any questions, hear suggestions for new episodes or hear from you, our listeners.

In this episode, we discuss the evolution of AWS networking capabilities from EC2-classic to VPC and advanced networking features. Andrey highlights that while many companies only use VPC and VPC peerings, there are lesser-known features that can significantly change how we approach networking setups on AWS. Connect with us on LinkedIn or Twitter (see info at https://devsecops.fm/about/). We are happy to answer any questions, hear suggestions for new episodes or hear from you, our listeners.

This is a mixed bag of an episode, we chat about all sorts of digital tools and security practices that we use in our day-to-day lives. We start by talking about password managers, and why Julien still using LastPass after the recent LastPass data breach. Julien gives us the lowdown on his personal approach to handling passwords and two-factor authentication (2FA) tokens, showing us why strong security measures matter. Julien also shares his favorite email alias service and we discuss services for sharing sensitive information to keep mail inboxes cleaner and more private. We also spoke about ChatGPT, an AI language model from OpenAI - will it replace jobs? should we be using it? And how? Just a heads up, we aren't sponsored by companies we mention in this episode. We're just sharing our personal experiences and the stuff we like to use. Connect with us on LinkedIn or Twitter (see info at https://devsecops.fm/about/). We are happy to answer your questions, hear suggestions for new episodes or just hear from you, our listeners.

Julien has extensive experience building data platforms for data engineering, so we got him talking and sharing. If infra for data engineering is your cup of tea, then this episode is for you. Connect with us on LinkedIn or Twitter (see info at https://devsecops.fm/about/). We are happy to answer your questions, hear suggestions for new episodes or just hear from you, our listeners.

We discussed tracing before but never got around to explaining details such as fundamentals, terminology, etc. This time Julien goes into detail about what tracing is, what the benefits are, the basic terms you need to understand, and where to start. Great episode for those who are considering adding tracing capabilities to their systems. Connect with us on LinkedIn or Twitter (see info at https://devsecops.fm/about/). We are happy to answer your questions, hear suggestions for new episodes or just hear from you, our listeners.

We are happy to welcome back Jacob Lärfors, CEO and Senior Consultant from Verifa, to talk about software supply chain attacks. It feels important to raise this topic since those attacks start to be utilized more often by sophisticated adversaries. At the same time, software supply chain security is something that companies often overlook. We as practitioners have so many things to consider and do that, in most cases, we do not have enough cognitive capacity left when looking into our library sources. What are the things we need to be aware of, and what are the low-hanging fruits we could utilize to help developers do their job securely? Connect with us on LinkedIn or Twitter (see info at https://devsecops.fm/about/). We are happy to answer your questions, hear suggestions for new episodes or just hear from you, our listeners.

Have you heard any recent news from Docker? We haven't. That is why we decided to check up on Docker to see how it is doing and go through the tool's history and adoption. Clueless about the difference between Docker, Containerd, CRI-O? We got you covered. Also, we will highlight a couple of new handy capabilities added recently. Connect with us on LinkedIn or Twitter (see info at https://devsecops.fm/about/). We are happy to answer your questions, hear suggestions for new episodes or just hear from you, our listeners.

We are excited about the new breed of tools coming to the market. We often had to put together tools to find out what was in production and what broke it. Your monitoring tools go as far as only telling you that something isn't working as expected but not why it is so, and then you have to scramble to figure out what versions of services are in production, were there any recent deploys, etc. So you can understand what has changed to narrow down possible causes. Our good friend Mike and his team are building the tool to answer exactly such questions, so we thought you might be interested in hearing him out. Connect with us on LinkedIn or Twitter (see info at https://devsecops.fm/about/). We are happy to answer your questions, hear suggestions for new episodes or just hear from you, our listeners.

We are discussing what has happened in Terraform world since the 1.0 release last year and if there are new features worth mentioning, trends in Terraform development, etc. As well as doing a recap of the road to 1.0 and how long it took us to get there. Connect with us on LinkedIn or Twitter (see info at https://devsecops.fm/about/). We are happy to answer your questions, hear suggestions for new episodes or just hear from you, our listeners.

If you follow CloudNative hype wave, you might feel that Prometheus is the must-use monitoring tool for everything CloudNative. Plus, almost everything nowadays has a Prometheus exporter. Just get that helm chart installed, and here you go - metrics question sorted out. Want to monitor endpoints - here is BlackBox exporter for you. Want to get notifications - AlertManager got you covered. And so on and so on. But is it all rainbows and unicorns? You probably guessed that it depends. This time, Semyon is joining us to air his grievances with Prometheus and share insights on how to cook it if you decide to go down this route.

Communication in co-located teams is quite often complicated. It is even more complex and, at the same time, important in distributed teams. Have you ever got an issue report that says this thing is failing? No logs, no explanation of context, no nothing. Pretty sure we've all been in such situations. How do you step up your communication game? This episode of DevSecOps Talks is about great communication tips for DevSecOps practitioners in distributed (and not only) teams. Connect with us on LinkedIn or Twitter https://devsecops.fm/about/ and tell us about your questions, and we will answer them in the show.

web3 has gotten a lot of attention lately; thus, it is time for us to separate facts from the hype. In this episode, we are trying to understand its implications for us as DevSecOps practitioners. Connect with us on LinkedIn or Twitter https://devsecops.fm/about/ and tell us about your questions, and we will answer them in the show.

Andrey feels frustrated that he has to develop a way to configure environments for every customer. Think for yourself - you arrive at a new project or company. It is day one, and you need to get the right tools as well as the correct environment configuration. During this episode, we are trying to figure out how companies solve it. And is there a standard solution? What are the options? Connect with us on LinkedIn or Twitter https://devsecops.fm/about/ and tell us about your questions, and we will answer them in the show.

Henrik Hoegh is back to talk about his experiences working in the platform team at his new job, but before that, we are getting through the following topics: - bash is the future of automation (not really, but some people think so) - building multi-cloud solutions using k8s and service mesh solutions - Shuttle - CLI for handling shared build and deploy tools between projects no matter what technologies the projects are using https://github.com/lunarway/shuttle - when is it the time to start looking into the building application delivery platform - platform team as an enabler or evil gatekeeper - team topology Connect with us on LinkedIn or Twitter https://devsecops.fm/about/ and tell us about your questions, and we will answer them in the show.

us-east-1 will never go down, and if it would, half of the internet would go down. It is what people used to say. So, us-east-1 went down big time. What does it mean for us as practitioners? What should we consider going forward? In this episode, we talk through the incident and disaster recovery strategies you can consider to keep your company up Connect with us on LinkedIn or Twitter https://devsecops.fm/about/ and tell us about your questions, and we will answer them in the show.

We have had Git around for more than 15 years, and during that time, it has become a standard de-facto to share code and track code changes. While Git is a superior version control system to most of what we have seen before, it has been 15 years since the first release. Should we be looking for new ways to approach version control systems? Is the time right for the next generation of tools in this area? Connect with us on LinkedIn or Twitter https://devsecops.fm/about/ and tell us about your questions, and we will answer them in the show.

Our first episode was about Infrastructure as code, and we feel that it is time to revisit the topic after almost two years. Another reason is the release of the second edition of Infrastructure as Code book by Keif Morris. Thus, in this episode, we revisit the definition of Infrastructure as code and try to summarize what has changed over the years. We hope you like it! Connect with us on LinkedIn or Twitter https://devsecops.fm/about/ and tell us about your questions, and we will answer them in the show.

Julien gives his impressions of Google Cloud Next 2021, and Andrey recaps HashiConf Global 2021 as well as gives his take with the twist on why do we might need HashiCorp Waypoint Connect with us on LinkedIn or Twitter https://devsecops.fm/about/ and tell us about your questions, and we will answer them in the show.

Everyone seems to be talking about service mesh. Mattias, Julien, and Andrey are trying to separate hype and real value. Most importantly, they dig into when is the good time for the organization is to embrace service mesh and what are the prerequisites Connect with us on LinkedIn or Twitter https://devsecops.fm/about/ and tell us about your questions, and we will answer them in the show.

As a follow-up to the [last episode about hiring an infrastructure automation person](https://devsecops.fm/episodes/31-hiring/) we decided to reverse the view and talk about how do you get hired as an infrastructure automation person. This episode is full of career advice for people who are just only from university as well as people who already have experience in the industry. Connect with us on LinkedIn or Twitter https://devsecops.fm/about/ and tell us about your questions, and we will answer them in the show.

Have you ever conducted an interview to hire an infrastructure automation person? What would you ask? How do you check their skills? And what skills are essential? Tune in for our tips on hiring and finding the right person for your team! Connect with us on LinkedIn or Twitter https://devsecops.fm/about/ and tell us about your questions, and we will answer them in the show.

Logs, metrics, and traces are the three pillars of observability. Where should you start? What are the common mistakes to avoid? And if you are to pick one - which one should you do? Connect with us on LinkedIn or Twitter https://devsecops.fm/about/ and tell us about your questions, and we will answer them in the show.

This time we are talking unikernles! Ian Eyberg from NanoVMs joins us to discuss how far this technology is from prime time. And it turns out that you don't have to be a kernel developer to take advantage of unikernes. Today, there are tools available to package, distribute, and run them locally as well as in the public cloud. While talking to Ian, it felt that the state of the technology is very similar to Linux containers at the beginning of 2010x, just before Docker made Linux containers available for everyone. Connect with us on LinkedIn or Twitter https://devsecops.fm/about/ and tell us about your questions, and we will answer them in the show.

The real cloud lock-in is security! Every service/cloud provider has its own levels of granularity regarding resources. Cloud engineering is mainly about compute, storage, and networking and how to make them scale. Scaling security is often left out as it is hard to measure on so many levels. We think that it is a myth and that we can measure how many steps it takes to add, modify or remove access rights. It all starts with monitoring, knowing what is there in a cloud infrastructure is a very good first step. By making it easy to see and manage access rights, we make it easier for ourselves to keep resources secured. Connect with us on LinkedIn or Twitter https://devsecops.fm/about/ and tell us about your questions, and we will answer them in the show. Visit https://devsecops.fm to see show notes and https://gitter.im/devsecopstalks/community to join a discussion.

AWS released AWS Bottlerocket OS in March of 2020, and version 1.0.0 got released in August 2020. What is it? Should you be using it? What are the benefits? Is it ready for prime time? We answer all of those questions during this episode of DevSecOps Talks. Tune in! Connect with us on LinkedIn or Twitter https://devsecops.fm/about/ and tell us about your questions, and we will answer them in the show. Visit https://devsecops.fm to see show notes and https://gitter.im/devsecopstalks/community to join a discussion.

Johan Abildskov (@RandomSort, see episode 6) is back, and we are talking branching strategies! In particular, why you shouldn't be doing git-flow, and what are other options out there. This conversation takes us down memory lane to a more broad discussion about version control systems, mono-repositories, continuous integration, and delivery. We hope you will like it! Connect with us on LinkedIn or Twitter https://devsecops.fm/about/ and tell us about your questions, and we will answer them in the show. Visit https://devsecops.fm to see show notes and https://gitter.im/devsecopstalks/community to join a discussion.

This time we are joined by Paul Stack (@stack72, Pulumi developer, former Terraform developer) and podcast friend Jacob Lärfors to talk about - what is Pulumi is? - understand the difference between Pulumi vs. Terraform (and if we should compare them at all) - What is hard about Pulumi? - What people ask the most? What are the common confusions? - Cross-language infra libraries? How is it even possible?! - Is there a possibility of a supply chain attack via Pulumi library? Connect with us on LinkedIn or Twitter https://devsecops.fm/about/ and tell us about your questions, and we will answer them in the show. Visit https://devsecops.fm to see show notes and https://gitter.im/devsecopstalks/community to join a discussion.

Last week (week 6, 2021), seven data breaches were announced. In this episode, we discuss the possible scenarios for preventing attackers from getting a hold of your data, whether private or company data. And tips on how to mitigate the consequences of data leaks in cases when you have no control over data management (think of breach of 3rd party service). Connect with us on LinkedIn or Twitter https://devsecops.fm/about/ and tell us about your questions, and we will answer them in the show. Visit https://devsecops.fm to see show notes and https://gitter.im/devsecopstalks/community to join a discussion

How do you run Kubernetes in the cloud? Still using Kops? Or is it time to jump to the managed offerings? We go through the list of things you might be missing out on if not yet using a managed solution. Also, in this episode - what do you always configure in the k8s cluster? CNI, Ingress, IAM, and even more! Visit https://devsecops.fm to see show notes and https://gitter.im/devsecopstalks/community to join a discussion

It's been almost a year since we started the podcast, but we never took time to explain who we are and what problems we solve for our customers/employers. So in this episode, you will find more details about us and, as usual, references to useful tools, talks, and techniques. Visit https://devsecops.fm to see show notes and https://gitter.im/devsecopstalks/community to join a discussion

AWS had a severe incident at the end of November. Kinesis in us-east-1 went dark for quite some time, and a ripple effect caused degradation of other services like CloudWatch, ECS, and others. As a Cloud Engineering practitioner, how do you get yourself and your organization ready for a such turn of events? Visit https://devsecops.fm to see show notes and https://gitter.im/devsecopstalks/community to join a discussion

Andrey wants monitoring to be more magical, or does he want a wrong thing? What are the sane defaults? And why do we have to set up boilerplate monitoring again and again? Mattias shares what he does for monitoring security events. Julien explains why using logs to debug in a microservices architecture is costly and inefficient. Visit https://devsecops.fm to see show notes and https://gitter.im/devsecopstalks/community to join a discussion

How to decommission resources from your cloud environment to keep it clean? What to do when a resource is created without being in the infrastructure code? Andrey is going through a checklist he uses to delete resources and the utility serverless functions he wrote. ArgoCD is a project that does GitOps and automatically delete resources in Kubernetes namespaces if they are not defined. We talked about the different layers of abstraction for infrastructure as code and where it makes sense to have a terraform controller in a Kubernetes cluster to manage the application dependencies. Visit https://devsecops.fm to see show notes and https://gitter.im/devsecopstalks/community to join a discussion

Initially, we planned this episode as a discussion about HashiCorp Nomad and invited Jacob Lärfors. He recently published a great article about his experience working with Nomad (see link in the show notes). However, because of a few postponements, and with HashiConf that happened just a week ago, we decided to extend the podcast’s scope to go over all of the announcements that they did during the conference. So here it is - HashiConf special: all you need to know about everything that HashiCorp announced during the conference plus a discussion about Nomad! Visit https://devsecops.fm to see show notes and https://gitter.im/devsecopstalks/community to join a discussion

This is the first episode in the new format - 30 minutes short and crisp episodes, i.e., less water and side discussions, focusing on the topic, duration under (well, almost under) 30 minutes. We hope you like it! The topic of this episode is building docker images - automation, security, best practices. In this episode, we discuss: Saving money with T3a family Building Docker images locally and in CI Setting up deamonless Docker builds for CI and k8s Using multistage builds to keep your images nice and clean as well as encapsulate the build environment and make it portable Passing secrets to Docker build and inspecting image layers for secrets (ssh-agent and many more) Keeping Docker images updated with dependencies and updates Scanning Docker images for vulnerabilities Docker image layers caching - doing it right DockerHub is to delete old images stored for free, and GitHub is ready to host them for you Docker image naming so you can find all you need to debug quickly In some of the information overlaps with episode #3 but greatly extends information provided before https://devsecops.fm/episodes/docker-secure-build/ Visit https://devsecops.fm to see show notes and https://gitter.im/devsecopstalks/community to join a discussion

In this episode, we discuss options for splitting your deployment stages. We hear people coming up with all possible type of environments - dev, test/QA, integration, stage, prod, etc How many do you actually need? What is the reason for having all those stages? Maybe do you need less? Why not deploy directly to production using some fancy technique? Put it simply - stage or not to stage? Visit https://devsecops.fm to see show notes and https://gitter.im/devsecopstalks/community to join a discussion

Let's talk about security in the era of remote work. Most of us have experienced a flaky VPN connection. What are the alternatives? SSH certificates? Yubikey? We discussed various topics around security inside a cluster and outside. Visit https://devsecops.fm to see show notes and https://gitter.im/devsecopstalks/community to join a discussion

This time, we are joined by Henrik Høegh who shares his unique perspective on applying the theory of constraint to IT transformation as well as how it applies in the world of Cloud Native. We go back to the origin of DevOps, discussing the various problems companies are facing when transforming their organizations and adopting cultural changes. Visit https://devsecops.fm to see show notes and https://gitter.im/devsecopstalks/community to join a discussion

Mattias wants to setup HashiCorp Vault and quizzes Andrey how to do that. We cover a lot of ground - from basic Vault concepts to setting it up and hardening.

Julien and Andrey got together to define the scale and ways to automate the scaling of your infrastructure in response to changes in load patterns. What are the prerequisites implementing scaling? What is cooling down, warm up, horizontal and vertical scaling, scale-up, and scale in? What are the metrics that could be useful for making scaling decisions? And last but not least, the very unexpected spin that Julien gives to the conversation. Visit https://devsecops.fm to see show notes and https://gitter.im/devsecopstalks/community to join a discussion

This time we are discussing the white paper by Summit Route - AWS Security Maturity Roadmap 2020. Tune in to learn more about the white paper and recommendations that we pile up on top of it. To view show notes visit https://devsecops.fm Chat with hosts and suggest topics for upcoming episodes at our Gitter channel https://gitter.im/devsecopstalks/community

Our guest speaker is Anton Babenko he is DevSecOps Talks podcast fan, AWS Community Hero, Terraform fanatic, HashiCorp Ambassador and a prolific open source contributor. After listening to episode #9 Terraform in CI and #1 Infrastructure as code, Anton decided that enough is enough and volunteered to give his point of view on Terragrunt since he though that we are missing a few important points. In this episode, we are discussing the use cases of Terragrunt, a wrapper around Terraform for working with multiple environment and modules.

How do you start to implement a CI pipeline when dealing with infrastructure as code implemented via Terraform? What are the security concerns when the credentials to the whole kingdom are used in an automated process? In this episode, we discuss the various security and feasibility aspects of using Terraform in a CI pipeline. We start the episode by catching up with what we’ve been working on. Feel free to skip to 11:52 if you want to go directly to the topic. Having an automated process to deploy and manage infrastructure has advantages such as fast feedback and collaboration. The code for the infrastructure is treated like an application that is versioned, tested, and deployed. Show notes are available at https://devsecops.fm/episodes/terraform-in-ci/

Andrey tells us the story of how DevOps came into existence and took over the market. We discuss the marketing around it, its relationship with DevSecOps. We tried to shed a light on what is marketing strategy versus implementing DevOps in an organization. We also compared DevOps to SRE (Site Reliability Engineering)

In this episode, Mattias, Julien, and Andrey share tips and tricks on how to stay on top of what is going on in the industry, resources they use for continuous learning. Make sure to visit devsecops.fm to check out show notes that contain references to resources mentioned during discussion and more

This time Johan Abildskov, a Senior Consultant with Praqma/Eficode, joins us to talk about SemVer (Semantic Versioning), and we finally get to hear what Julien has to say about it. We get to explore different options regarding versioning and how it helps humans communicate. At the end of the podcast, everyone gets to share their approach and recommendations for versioning things.

We had a couple of possible topics for this episode but before getting started with them we decided to discuss what technological problems we were solving during the last two weeks. Well, turns out there was quite a lot to discuss. Tune in for tips on ssh session logging on the ssh server, preventing downloads from AWS S3 even if you got read access, credentials in Git repository 🤦, why you should (or should not) do K8S and more. Summary In this free-form early episode of DevSecOps Talks, a casual "what have you been up to" catch-up turns into a sharp exchange on the gap between security in theory and security in practice. One host discovers plaintext service account keys, database passwords, and a production SSH tunnel all committed straight into a Git repository — and the team walks through how to unwind that without breaking delivery. Julien Bisconti argues that security tooling is fundamentally failing developers because it is too hard to use under real delivery pressure. The episode also delivers strong opinions on why teams should not default to Kubernetes, the hidden complexity of S3 encryption with KMS keys, and why Google's BeyondCorp model makes VPNs look like a relic. Key Topics SSH session logging, bastion hosts, and compliance visibility The episode opens with a deep dive into SSH session logging for bastion hosts in AWS. One of the hosts explains how AWS Systems Manager Session Manager can be used to access instances without VPNs or direct inbound connectivity — the SSM agent on each instance calls home to AWS, and AWS proxies the connection back. That model is attractive for hybrid and on-prem environments because it removes networking complexity around NAT, port forwarding, and VPN setup. It also provides session logging, IAM-based access control, and command output recording. But the drawbacks surface quickly. Session Manager logs users in as a generic SSM agent user with /usr/bin as the working directory. Documentation is sparse, and Bash is launched in shell mode to support color interpretation, which pollutes session logs with escape characters. A bigger concern is that access control rests entirely on IAM credentials — in an environment with fully dynamic, short-lived credentials that is manageable, but it becomes risky anywhere static keys exist. The host describes trying to map Session Manager logins to individual users, only to find that it requires static IAM identities with specially named tags containing usernames — a non-starter for environments where everything is dynamic. That leads into alternative approaches. An AWS blog post describes forcing SSH connections through the Unix script utility to record sessions, then uploading logs to S3. But even that is fragile: logs are owned by the user, so technically the user can delete or overwrite them. A more robust path is tlog, a terminal I/O logger that writes session data in JSON format to the systemd journal, where it cannot be easily tampered with. From there, the CloudWatch agent can export journal data to S3 for long-term storage. The broader point is that command logging sounds simple in compliance conversations, but in practice it becomes a deep rabbit hole full of bypasses, noise, and design tradeoffs. Monitoring user activity without drowning in logs The hosts compare notes on monitoring shell activity. One host mentions using auditd to track user actions on bastion hosts in a previous environment, but the log volume was overwhelming — even Elasticsearch struggled to keep up with the ingestion rate. That sparks a discussion around anomaly detection and heuristics. The real challenge is not collecting logs but determining what is unusual and worth investigating. Failed SSH login alerts are mentioned as a useful signal, though another host pushes back: "Should you have SSH with the password at all? You should have a key." The point stands — without careful tuning, even sensible alerts generate noise faster than teams can act on them. The exchange captures a recurring DevSecOps reality: collecting telemetry is the easy part; turning it into something actionable is where most teams get stuck. S3 bucket security, public access controls, and KMS encryption surprises The conversation shifts to AWS S3 security. Public buckets remain a common source of breaches, but AWS now offers S3 Block Public Access — account- and bucket-level settings that prevent public access regardless of individual object ACLs. In Terraform, this is a dedicated resource block. The more nuanced insight is about encryption. The host explains the difference between S3 server-side encryption with the default AWS-managed key (SSE-S3) and encryption with a customer-managed KMS key (SSE-KMS). With SSE-S3, S3 decrypts objects transparently for any client with read access to the bucket. With a customer-managed KMS key, S3 cannot decrypt the object unless the requester also has kms:Decrypt permission on that specific key. This became a real problem in a cross-accoun

In this episode Mattias is trying to convince that running docker in k8s is more security then VM. Did he success ? listen and find out. Summary Mattias makes a bold claim: Docker containers are more secure than virtual machines. Andrey and Julien push back hard — and by the end, the three hosts explicitly agree to disagree. Along the way, they dig into why container breakouts are harder than people assume, how Lambda micro VMs can be exploited through warm TMP folders, why "containers do not contain" without extra kernel controls, and whether good monitoring matters more for security than any isolation technology. Recorded during COVID-19 lockdowns in 2020, the debate captures a moment when the container-vs-VM argument was far from settled. Key Topics Docker vs. VM security: technology vs. ways of working Mattias opens the main debate by arguing that Docker containers are more secure than VMs in practice. His reasoning: containers are smaller, more focused, and more ephemeral than traditional virtual machines, which reduces attack surface. In a typical VM, you find mail agents, host-based intrusion detection, syslog, monitoring tools, and other services all coexisting with the application. In a container, you ideally run only the application itself. Andrey pushes back immediately. He argues Mattias is comparing operational models, not technology. A well-run VM can also be immutable and minimal — you redeploy from a new image the same way you replace a container. Likewise, a badly built container can be long-lived, bloated, and full of unnecessary tools. Andrey has seen enterprises that run containers for months, SSH into them, and treat them like VMs. Mattias concedes the point but maintains that the standard approach differs: VMs are typically kept running longer with more tools, while the standard approach for containers in Kubernetes is to rotate them and keep a smaller footprint. Andrey counters that most Docker images run as root by default, giving attackers more privilege than they would have on a typical VM where processes run under limited service accounts. This is one of the sharpest exchanges in the episode — better tooling does not fix insecure defaults. The hosts eventually agree that both technologies can be secured well, but do not reach consensus on which is easier. Andrey summarizes it cleanly: containers make it "a little bit easier" to do the right thing because they narrow the focus to the application rather than the entire operating system, but it is absolutely possible to reach the same security level with VMs. Why container breakout is not as trivial as people imply Mattias challenges the common assumption that containers are unsafe because "you can break out of them." He points out that every container breakout CVE he has reviewed requires significant preconditions: either running an attacker-controlled image or running in privileged mode. You cannot take a standard Ubuntu container image, run a single command, and escape. The threat is real but requires chained attacks, not a single exploit. Julien and Andrey accept the premise but note that the comparison matters. VM isolation is fundamentally stronger at the hypervisor level. Container breakout may be hard, but it is architecturally easier than VM escape. The discussion reframes the question: runtime security is less about one isolation boundary and more about how many obstacles an attacker must pass through. Micro VMs, Firecracker, and Lambda attack vectors Andrey brings up an important middle ground between containers and VMs: micro VMs. AWS Lambda runs on Firecracker, an open-source micro VM monitor. Lambdas are ephemeral, have read-only file systems, minimal tooling, and no access to source code or settings — making them quite secure by design. But Andrey describes a real attack path researchers have demonstrated. The /tmp directory in Lambda is writable. If an attacker exploits a vulnerability to get code execution within the Lambda, and the Lambda is kept warm (invoked within 15 minutes so it stays in memory), the /tmp folder persists between invocations. An attacker can download tools incrementally across multiple Lambda runs, building up capability over time. From there, they can explore IAM permissions, exfiltrate data by encoding it in resource tags, or even override the Lambda function itself. The point is that even well-designed ephemeral environments have attack paths when defenders are not paying attention. Security depends on hardening and monitoring, not just on the isolation primitive. Containers do not contain: AppArmor, Seccomp, and policy controls Julien delivers the episode's sharpest technical point: "Containers do not contain." They are primarily Linux namespace isolation and need additional kernel controls — AppArmor profiles and Seccomp filters — to properly restrict what applications can do at runtime. Without those extra layers, a container running as root is effectively root on the host machine, and a c

Your docker images and build are be coming the base for our platform. But are they secure? In this episode we talk about how you can secure your docker images. Summary In this early DevSecOps Talks episode, Mattias, Andrey, and Julien dig into Docker security as a supply chain problem — and quickly dismantle the assumption that a signed container means you know what is inside. Julien pushes back sharply: signing only gives a "semantic guarantee" that an image is what it claims to be, not that it is safe. Mattias argues that containers were designed to be convenient, not secure by default, while Andrey points out that containerization has fundamentally changed the patching game — once the OS, web server, and application are packaged together, every security fix becomes a rebuild-and-redeploy exercise. The hosts make the case for layered scanning, slim runtime images, multi-stage builds, and continuous rebuilding as the practical path to running containers safely in production. Key Topics Container images vs. running containers The conversation starts by separating two distinct parts of container security: the image and the running container. Mattias explains that a container image can be treated much like any other file or archive — a zip or tar file sitting on disk. Because of that, teams can sign images cryptographically to verify origin and integrity, similar to how Node.js developers sign releases with their private keys. That gives consumers confidence that the image came from a known source and has not been tampered with. But Julien pushes back on a common misunderstanding: signing does not mean the contents are inherently safe. As he puts it, you get a "semantic guarantee that this image is what it's pretending to be" — but not proof that everything inside is secure. Authenticity is not the same as security. The hosts frame this as a trust problem. In a production cluster, teams often want to prevent engineers or workloads from pulling arbitrary images and running them without controls. Signed images and curated registries help, but they do not eliminate the need for careful validation. Trust, Docker Hub, and the container supply chain A major part of the episode focuses on how much trust teams should place in public images, including those from Docker Hub. Andrey raises the practical reality: if you are running four different languages, you cannot build and maintain base images for all of them. It is much easier to grab the latest Node.js, Python, Ruby, or Java images from Docker Hub and build from there. Julien and Mattias acknowledge that reality, but caution against treating "official" or branded images as automatically secure. Julien walks through the different trust levels on Docker Hub: Images from unknown individuals are the hardest to trust Organization-backed images (Red Hat, CloudBees, etc.) provide more accountability based on brand recognition Even reputable images can contain known vulnerabilities — scanning a Jenkins image from Docker Hub can reveal a surprising number of CVEs A trusted source can still introduce problems, whether by mistake or through malicious intent That leads into a broader discussion of supply chain attacks. Julien references real examples where Node.js libraries on npm were taken over by malicious parties after the original maintainer walked away. The same risk applies to container images. Julien points out that large organizations sometimes go as far as rebuilding all dependencies from source — he mentions having heard of teams that do not pull jar files from Maven Central but build their own from source to verify exactly what they are shipping. While that is not feasible for every team, the principle stands: reduce blind trust and increase verification where the environment demands it. Why container security is not just image signing The discussion then shifts from image authenticity to runtime security. Mattias explains that containers rely on Linux kernel primitives — namespaces for process isolation, along with controls for networking, memory, and disk. These low-level APIs are useful for resource sharing and scaling, but they were not originally designed as strong security boundaries. As he puts it, "the container does not contain things, it's just an abstraction." Container breakout vulnerabilities matter because an attacker who can exploit the runtime or host interface may reach beyond the container itself. This leads to one of the episode's sharpest observations from Mattias: containers became popular because they are efficient and convenient to operate — you can bin-pack them on the same hardware and run far more applications per server. But from a security perspective, "it was not designed to be secure by default, it was designed to be convenient." That gap between convenience and security is what teams must actively address through scanning, hardening, and runtime controls. CVE scanning: registries, dependencies, and source code The hosts spend a good