{"version":"https://jsonfeed.org/version/1.1","title":"Straight-up tech talk by practitioners, for practitioners on Podcast about DevSecOps","description":"Recent content in Straight-up tech talk by practitioners, for practitioners on Podcast about DevSecOps","home_page_url":"https://deploy-preview-67--devsecopstalks.netlify.app/","feed_url":"https://deploy-preview-67--devsecopstalks.netlify.app/index.json","language":"en-us","icon":"https://deploy-preview-67--devsecopstalks.netlify.app/apple-touch-icon.png","favicon":"https://deploy-preview-67--devsecopstalks.netlify.app/apple-touch-icon.png","authors":[{"name":"DevSecOps Talks","url":"https://devsecops.fm/about","avatar":"https://deploy-preview-67--devsecopstalks.netlify.app/path/to/some-image.jpg"}],"items":[{"title":"#100 - 100 Episodes Later: What Still Matters in DevSecOps","date_published":"2026-05-07T12:36:44+01:00","date_modified":"2026-05-07T12:36:44+01:00","id":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/100-100-episodes-later-what-still-matters-in-devsecops/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/100-100-episodes-later-what-still-matters-in-devsecops/","authors":[{"name":"DevSecOps Talks"}],"content_html":"\u003cp\u003eWhat changed between episode 1 and episode 100, and what stayed surprisingly constant? The hosts revisit infrastructure as code, observability, incident response, secrets, compliance, and supply chain security through the lens of six years of conversations. It is part retrospective, part editorial reset for what the next 100 episodes should focus on.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/company/devsecops-talks/\"\u003eDiscuss the episode or ask us anything on LinkedIn\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"single_player_container\"\u003e\n   \u003ciframe\n     title=\"DEVSECOPS Talks #100 - 100 Episodes Later: What Still Matters in DevSecOps\"\n     height=\"122\"\n     width=\"100%\"\n     style=\"border: none;\"\n     scrolling=\"no\"\n     data-name=\"pb-iframe-player\"\n     src=\"https://www.podbean.com/media/player/ncyen-1ab9b57-pb?from=yiiadmin\u0026download=1\u0026version=1\u0026skin=1\u0026btn-skin=107\u0026auto=0\u0026download=1\u0026pbad=1\"\n   \u003e\u003c/iframe\u003e\n \u003c/div\u003e\n\n\u003chr\u003e\n\u003cdiv style=\"position: relative; padding-bottom: 56.25%; height: 0; overflow: hidden;\"\u003e\n      \u003ciframe allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share; fullscreen\" loading=\"eager\" referrerpolicy=\"strict-origin-when-cross-origin\" src=\"https://www.youtube.com/embed/Zhkv7kauxTw?autoplay=0\u0026amp;controls=1\u0026amp;end=0\u0026amp;loop=0\u0026amp;mute=0\u0026amp;start=0\" style=\"position: absolute; top: 0; left: 0; width: 100%; height: 100%; border:0;\" title=\"YouTube video\"\u003e\u003c/iframe\u003e\n    \u003c/div\u003e\n\n\u003ch2 id=\"summary\"\u003eSummary\u003c/h2\u003e\n\u003cp\u003eSix years, 100 episodes, three hosts (and one alumni) — the DevSecOps Talks crew uses the milestone to look back at what stuck, what faded, and what to do next. Andrey argues the show\u0026rsquo;s biggest mistake to avoid in the next 100 episodes is mutating into \u0026ldquo;yet another AI podcast,\u0026rdquo; even as he admits AI is genuinely hard to ignore now that supply chain attacks and people shipping half-baked code quickly under AI assistance are real. Paulina frames AI as just another hype cycle in the lineage of containers and Kubernetes — and notes that the boring fundamentals look more relevant than ever because \u0026ldquo;machines can\u0026rsquo;t understand what makes good software or good infra.\u0026rdquo; Mattias points to Security Now\u0026rsquo;s 20-year run as the north star, and the hosts commit to revisiting the evergreen topics — IaC, observability, incident response, secrets, compliance — with sharper preparation for 2026.\u003c/p\u003e\n\u003ch2 id=\"key-topics\"\u003eKey Topics\u003c/h2\u003e\n\u003ch3 id=\"100-episodes\"\u003e100 episodes, six years, and the math of consistency\u003c/h3\u003e\n\u003cp\u003eThe hosts open with the basic arithmetic of doing a podcast: at a weekly cadence, 100 episodes is two years; at the cadence DevSecOps Talks actually keeps, it took roughly six. Andrey points out that scaling the show is not about doing more — it is about distributing the load. Adding hosts means not everyone has to be in every recording, and rotating guests turns the burden into community participation rather than a publishing treadmill.\u003c/p\u003e\n\u003cp\u003eThe conversation revisits how the hosting bench has shifted over the years. Julien Bisconti co-hosted episodes 1–68 (\u003ca href=\"/episodes/068-julien-s-last-episode-/\"\u003eepisode #68 was his last\u003c/a\u003e). Paulina joined starting from \u003ca href=\"/episodes/069-who-is-paulina-/\"\u003eepisode #69\u003c/a\u003e, bringing a new voice and her own outside podcast. Andrey reveals he has now started a second podcast focused on agentic AI in DevOps — \u0026ldquo;if you don\u0026rsquo;t have enough Andrey in your life, there is more\u0026rdquo; — explicitly to keep that material out of DevSecOps Talks.\u003c/p\u003e\n\u003ch3 id=\"stay-on-topic\"\u003eThe commitment for the next 100: don\u0026rsquo;t become \u0026ldquo;yet another AI podcast\u0026rdquo;\u003c/h3\u003e\n\u003cp\u003eThe clearest editorial decision in the episode: stay true to the show\u0026rsquo;s topic. Andrey is blunt — the temptation to mutate everything into an AI podcast is real, because that is what is happening across the industry, but the hosts want to resist it. AI will appear when it is genuinely relevant — supply chain risk, AI-enabled phishing, people shipping half-baked code quickly under AI assistance — not as the default frame for every episode.\u003c/p\u003e\n\u003cp\u003ePaulina reframes the AI moment as a hype cycle — first containers, then Kubernetes, now AI — and finds that pattern reassuring rather than threatening. The base principles the hosts have championed for years (good software practice, organizational design for change, CI/CD that fits the team) are arguably \u003cem\u003emore\u003c/em\u003e important now, because agents cannot infer them on their own. As she puts it, CI/CD is hard precisely because \u0026ldquo;it depends on your organization — how do humans organize to make change to the system. Well, guess what? The AI cannot see that.\u0026rdquo;\u003c/p\u003e\n\u003ch3 id=\"preparation\"\u003eThe north star: Security Now and better preparation\u003c/h3\u003e\n\u003cp\u003eMattias names the bar the show is aiming for: Steve Gibson\u0026rsquo;s Security Now, which has been running for 20 years. \u0026ldquo;If we can get like 20% as good as Steve is, that would be an achievement.\u0026rdquo; Reaching for that bar means investing more in preparation rather than relying on conversational instinct alone.\u003c/p\u003e\n\u003cp\u003eAndrey describes the episode-prep workflow he is now using: every prior episode, with descriptions, sits in a local repository; Claude with a 1M-context window summarizes themes across the entire back catalog; Claude Code and Codex compete to produce the best article description. The goal is \u0026ldquo;less babbling,\u0026rdquo; more concise delivery, while keeping the conversational feel that makes the show different from a polished briefing — the meet-up energy of \u0026ldquo;I heard about this tool at a conference, how do I actually try it?\u0026rdquo;\u003c/p\u003e\n\u003ch3 id=\"evergreen\"\u003eThe six-year topic ledger: what stuck\u003c/h3\u003e\n\u003cp\u003eAndrey walks through the topics that have proven durable across six years of the show. \u003cstrong\u003eInfrastructure as code\u003c/strong\u003e is the founding subject (\u003ca href=\"/episodes/001-infrastructure-as-code/\"\u003eepisode #1\u003c/a\u003e, \u003ca href=\"/episodes/035-iac-revisited-2021/\"\u003e#35 IaC Revisited\u003c/a\u003e, \u003ca href=\"/episodes/043-terraform-one-year-recap/\"\u003e#43 Terraform one-year recap\u003c/a\u003e) and remains evergreen. \u003cstrong\u003eKubernetes\u003c/strong\u003e is now baseline. \u003cstrong\u003ePlatform engineering\u003c/strong\u003e has been covered in at least four dedicated episodes (\u003ca href=\"/episodes/038-platform-teams-with-henrik/\"\u003e#38\u003c/a\u003e, \u003ca href=\"/episodes/056-backstage/\"\u003e#56 Backstage\u003c/a\u003e, \u003ca href=\"/episodes/095-from-platform-theater-to-golden-guardrails/\"\u003e#95\u003c/a\u003e, \u003ca href=\"/episodes/096-keeping-platforms-simple-and-fast-with-joachim-hill-grannec/\"\u003e#96\u003c/a\u003e) with more on the way. \u003cstrong\u003eGitOps\u003c/strong\u003e appeared as the second episode ever (\u003ca href=\"/episodes/002-gitops/\"\u003e#2\u003c/a\u003e) — and Andrey cites an AI-generated statistic that 93% of organizations using a platform leverage GitOps in 2026, while flagging on-air that the number came from research done by AI and may not be accurate.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eContinuous topics\u003c/strong\u003e that keep returning: immutable infrastructure, the three pillars of observability (\u003ca href=\"/episodes/030-observability/\"\u003e#30\u003c/a\u003e), Git branching strategy (\u003ca href=\"/episodes/026-git-branching-strategies/\"\u003e#26\u003c/a\u003e), incident response (\u003ca href=\"/episodes/073-incident-response-key-preparations-you-need/\"\u003e#73\u003c/a\u003e, \u003ca href=\"/episodes/074-from-preparation-to-execution-handling-an-active-incident/\"\u003e#74\u003c/a\u003e, \u003ca href=\"/episodes/075-learning-from-the-crisis-post-incident-actions/\"\u003e#75\u003c/a\u003e), hiring and career growth (\u003ca href=\"/episodes/031-hiring/\"\u003e#31\u003c/a\u003e, \u003ca href=\"/episodes/032-getting-hired/\"\u003e#32\u003c/a\u003e), distributed-team communication, secrets management (\u003ca href=\"/episodes/081-keeping-secrets-safe/\"\u003e#81\u003c/a\u003e), and multi-account landing zones (\u003ca href=\"/episodes/066-multi-account-strategy-and-landing-zones-account-segmentation-approaches-for-security-and-efficiency-on-aws/\"\u003e#66\u003c/a\u003e).\u003c/p\u003e\n\u003ch3 id=\"faded\"\u003eWhat faded: unikernels, Nomad, service mesh defaults, and Waypoint\u003c/h3\u003e\n\u003cp\u003eNot everything aged well. Andrey runs through the topics that did not deliver on early promise:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eUnikernels\u003c/strong\u003e (\u003ca href=\"/episodes/029-unikernels/\"\u003e#29\u003c/a\u003e) — collapsed as a hype, still niche; might find a niche again in AI workloads where boot speed matters.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eNomad\u003c/strong\u003e — never lost interest from a small base of users, but lost the orchestration war to Kubernetes definitively.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eService mesh\u003c/strong\u003e (\u003ca href=\"/episodes/033-service-mesh/\"\u003e#33\u003c/a\u003e) — the \u0026ldquo;Istio as default\u0026rdquo; future never arrived; simpler ingress patterns won.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eHashiCorp Waypoint\u003c/strong\u003e — discussed a couple of times on the show, has since been discontinued.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eSturdy\u003c/strong\u003e (\u003ca href=\"/episodes/036-sturdy/\"\u003e#36\u003c/a\u003e) — the Git successor the hosts interviewed; the hosts have not heard much about it since.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eAndrey also notes how his own usage shifted: HashiCorp Vault was a frequent topic in early episodes (\u003ca href=\"/episodes/013-all-you-need-to-know-about-setting-up-hashicorp-vault/\"\u003e#13\u003c/a\u003e), but he stopped using it professionally once it became clear it is built for big-organization problems that do not match his consulting work at FivexL.\u003c/p\u003e\n\u003ch3 id=\"compliance\"\u003eCompliance went from a footnote to the main event\u003c/h3\u003e\n\u003cp\u003eIn 2020 the compliance conversation was largely HIPAA and PCI DSS. Six years later, the hosts have dedicated entire episodes to the EU regulatory wave — \u003ca href=\"/episodes/087-eu-compliance-101-ai-act-dora-nis2-explained/\"\u003e#87 on AI Act, DORA, and NIS2\u003c/a\u003e and \u003ca href=\"/episodes/088-eu-compliance-101-dsa-mica-explained/\"\u003e#88 on DSA and MiCA\u003c/a\u003e. The shift from \u0026ldquo;compliance is a checkbox for finance and healthcare\u0026rdquo; to \u0026ldquo;compliance is a daily concern for practitioners\u0026rdquo; mirrors the rise of \u003cstrong\u003econtinuous compliance\u003c/strong\u003e tooling: the hosts interviewed Kosli (\u003ca href=\"/episodes/044-kosli/\"\u003e#44\u003c/a\u003e) early, and tools like Vanta, Drata, and SecureFrame have built a category.\u003c/p\u003e\n\u003ch3 id=\"supply-chain\"\u003eSupply chain security: theoretical to operational\u003c/h3\u003e\n\u003cp\u003eSupply chain security has been a recurring beat — \u003ca href=\"/episodes/046-supply-chain/\"\u003e#46\u003c/a\u003e, \u003ca href=\"/episodes/053-supply-chain-again/\"\u003e#53 Supply chain again\u003c/a\u003e, and most recently \u003ca href=\"/episodes/097-shift-left-get-hacked-supply-chain-attacks-hit-devs/\"\u003e#97 Shift left, get hacked\u003c/a\u003e. Andrey marks the current moment as the inflection point where supply chain attacks went from theoretical risk to the kind of news that forces real prioritization in budgets and roadmaps. Expect this thread to continue in 2026.\u003c/p\u003e\n\u003ch3 id=\"next-100\"\u003eThe plan for the next 100\u003c/h3\u003e\n\u003cp\u003eConcretely: revisit the evergreen topics — IaC, observability, incident response, secrets, hiring — for a 2026 audience, and bring in guests who have spent serious time thinking about each. Frequent collaborators get a nod: Paul Stack (\u0026ldquo;he is a frequent offender\u0026rdquo;) joined for \u003ca href=\"/episodes/092-from-system-initiative-to-swamp-agent-native-infra-with-paul-stack/\"\u003e#92 on agent-native infra\u003c/a\u003e, and Helga is fondly remembered. The improved preparation pipeline, with Claude Code and Codex generating show notes, is the production upgrade that should make the next stretch tighter and more useful.\u003c/p\u003e\n\u003ch2 id=\"highlights\"\u003eHighlights\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eAndrey on resisting the AI-podcast drift:\u003c/strong\u003e \u0026ldquo;We should stick to the topic, try not to mutate everything into an AI podcast, because that\u0026rsquo;s what\u0026rsquo;s happening right now with industry. AI brings relevance to the topics we discuss — but we shouldn\u0026rsquo;t become the AI-first thingy like as many other shows mutated.\u0026rdquo; A clear editorial line in a year where every show is being pulled toward the same frame. Listen to episode #100 for the hosts\u0026rsquo; commitment to keep DevSecOps Talks about DevSecOps practitioners first.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003ePaulina on the AI hype cycle:\u003c/strong\u003e \u0026ldquo;First it was containers, then it was Kubernetes, and I feel we\u0026rsquo;re going exactly in a similar fashion with AI. The base principles that we used — that were considered good practice — are even more relevant today, because those machines can\u0026rsquo;t understand what makes good software or good infra.\u0026rdquo; A grounding take from a self-described builder. Tune in to hear why CI/CD being hard is exactly why agents won\u0026rsquo;t replace senior judgment any time soon.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eMattias on the north star:\u003c/strong\u003e \u0026ldquo;Steve Gibson with Security Now is doing an amazing job. If we can get like 20% as good as Steve is, that would be an achievement. But for him, it took a long professional career — he has something to say.\u0026rdquo; Setting the bar at 20 years of consistent, opinionated security commentary. Listen for the hosts\u0026rsquo; commitment to better preparation in the next 100.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eAndrey on what didn\u0026rsquo;t age well:\u003c/strong\u003e \u0026ldquo;Unikernels — the hype collapsed, still kind of niche, might be quite applicable with AI workloads. Nomad stayed niche, never went anywhere — it lost the orchestration war to Kubernetes. Service mesh — Istio as default never happened. HashiCorp Waypoint got discontinued.\u0026rdquo; A frank scorecard from six years of covering infrastructure trends. Catch the full episode for what the hosts think will fade from today\u0026rsquo;s hype list next.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eAndrey on supply chain going operational:\u003c/strong\u003e \u0026ldquo;Supply chain security — we spoke about that, but now with the latest news, it\u0026rsquo;s becoming an issue. It\u0026rsquo;s going from theoretical threat to a real thing that requires action and prioritization.\u0026rdquo; If you have been treating supply chain as a 2026 problem, you are already late. Listen to hear which themes the hosts will revisit with new urgency.\u003c/p\u003e\n\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"resources\"\u003eResources\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\n\u003cp\u003e\u003ca href=\"https://devsecops.fm/episodes/\"\u003eDevSecOps Talks — Episode Archive\u003c/a\u003e — The full back catalog of 100 episodes, useful for tracing how the topics in this retrospective evolved over six years.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003ca href=\"https://www.grc.com/securitynow.htm\"\u003eSecurity Now Podcast (Steve Gibson, GRC)\u003c/a\u003e — The 20-year-running security podcast Mattias names as the north star for DevSecOps Talks. A masterclass in long-form, opinionated technical commentary.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003ca href=\"https://www.gartner.com/en/research/methodologies/gartner-hype-cycle\"\u003eHype Cycle — Gartner Research\u003c/a\u003e — The framework Paulina invokes when comparing AI to the earlier container and Kubernetes waves; useful for putting current AI excitement in historical context.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003ca href=\"https://discuss.hashicorp.com/t/hashicorp-waypoint-end-of-maintenance/68597\"\u003eHashiCorp Waypoint — Discontinued (HashiCorp Discuss)\u003c/a\u003e — Confirmation of the Waypoint discontinuation Andrey mentions, for listeners tracking which tools to remove from their evaluation lists.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003ca href=\"https://opengitops.dev/\"\u003eOpenGitOps Principles (CNCF)\u003c/a\u003e — The OpenGitOps working group\u0026rsquo;s reference site covering GitOps principles and project resources; useful background for the GitOps thread that started in episode #2.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003ca href=\"https://www.anthropic.com/news/disrupting-AI-espionage\"\u003eAnthropic Threat Intelligence Report — November 2025\u003c/a\u003e — Anthropic\u0026rsquo;s disclosure of an AI-orchestrated cyber espionage campaign; relevant background for the broader point about AI-assisted offensive operations the hosts argue a DevSecOps show cannot fully ignore.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003ca href=\"https://sre.google/sre-book/postmortem-culture/\"\u003ePostmortem Culture: Learning from Failure (Google SRE Book)\u003c/a\u003e — Foundational reading on the incident-response practice the hosts have returned to across episodes #73, #74, #75, and #99 — and plan to revisit again in the next 100.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/company/devsecops-talks/\"\u003eDevSecOps Talks on LinkedIn\u003c/a\u003e — Where the hosts continue conversations from the show and where listeners can suggest topics for the next 100 episodes.\u003c/p\u003e\n\u003c/li\u003e\n\u003c/ul\u003e"},{"title":"#99 - AI SRE and the End of 3 AM On-Call","date_published":"2026-04-27T23:12:33+01:00","date_modified":"2026-04-27T23:12:33+01:00","id":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/099-ai-sre-and-the-end-of-3-am-on-call/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/099-ai-sre-and-the-end-of-3-am-on-call/","authors":[{"name":"DevSecOps Talks"}],"content_html":"\u003cp\u003eCould AI handle the worst parts of incident response before you even join the call? Mattias and Paulina talk with Birol Yildiz about AI-written status updates, fast root cause analysis, and the path from read-only help to autonomous fixes. They also explore why post-mortems and documentation may be some of the best places to start.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/company/devsecops-talks/\"\u003eDiscuss the episode or ask us anything on LinkedIn\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"single_player_container\"\u003e\n   \u003ciframe\n     title=\"DEVSECOPS Talks #99 - AI SRE and the End of 3 AM On-Call\"\n     height=\"122\"\n     width=\"100%\"\n     style=\"border: none;\"\n     scrolling=\"no\"\n     data-name=\"pb-iframe-player\"\n     src=\"https://www.podbean.com/media/player/b6jn6-1aac738-pb?from=yiiadmin\u0026download=1\u0026version=1\u0026skin=1\u0026btn-skin=107\u0026auto=0\u0026download=1\u0026pbad=1\"\n   \u003e\u003c/iframe\u003e\n \u003c/div\u003e\n\n\u003chr\u003e\n\u003ch2 id=\"summary\"\u003eSummary\u003c/h2\u003e\n\u003cp\u003eBirol Yildiz, Co-founder and CEO of ilert, predicts that AI SRE agents will reach the same maturity as coding agents by the end of 2026 — meaning on-call engineers will only get paged when the agent cannot fix the problem itself. In this episode, Mattias and Paulina sit down with Birol to explore what modern incident response looks like when AI enters the loop: from drafting customer-facing status updates in firefighting mode, to delivering a full root cause analysis before you even open your laptop at 3 AM. Birol argues it is \u0026ldquo;irresponsible not to use\u0026rdquo; AI for post-mortems, while the hosts make the case that adopting agents for operations is no longer a nice-to-have — because if defenders do not use them to find vulnerabilities first, attackers will.\u003c/p\u003e\n\u003ch2 id=\"key-topics\"\u003eKey Topics\u003c/h2\u003e\n\u003ch3 id=\"alerts-vs-incidents-start-with-actionability-not-labels\"\u003eAlerts vs. Incidents: Start with Actionability, Not Labels\u003c/h3\u003e\n\u003cp\u003eBirol pushes back on the common impulse to draw a sharp line between alerts and incidents up front. At ilert, the starting point is simpler: does this require immediate human attention? An alert is anything that does — even if there is no business impact yet. A database disk at 95% capacity has no customer-visible effect right now, but ignoring it for two hours could take down a central service. An incident, by contrast, is declared when there is already business impact or when the response needs to scale beyond a single responder — it becomes a \u0026ldquo;coordination anchor\u0026rdquo; for mobilizing cross-department teams.\u003c/p\u003e\n\u003cp\u003eThe practical takeaway: instead of debating taxonomy, limit paging to things that are actionable. Informational signals belong in low-priority alerts that wait for the next business day rather than waking someone at 3 AM. Mattias connects this to the old Nagios and Icinga world, where warning-level alerts were arguably the most important ones to watch: \u0026ldquo;Those are the ones that tell you things are about to go wrong. You should check this now before they go critical — because they will.\u0026rdquo; The hosts frame this as yet another instance of shifting left — this time applied to alerting itself.\u003c/p\u003e\n\u003ch3 id=\"incident-response-at-3-am-building-situational-awareness\"\u003eIncident Response at 3 AM: Building Situational Awareness\u003c/h3\u003e\n\u003cp\u003eWhen a page fires in the middle of the night, Birol describes a structured triage sequence that applies regardless of tooling. The first job is to create situational awareness: Is there business impact already? Do customers or internal stakeholders need an update? The second question is whether the on-call responder can resolve this alone or needs to mobilize additional people.\u003c/p\u003e\n\u003cp\u003eGood alerts help with the first question by embedding context — backlinks to dashboards, ongoing metric updates, and source references — so the responder does not start from a blank screen. For the second question, modern incident response platforms eliminate the manual lookup of who is on call. Instead of consulting a spreadsheet to find which database engineer is covering the Tuesday night rotation, the responder simply requests \u0026ldquo;the database person,\u0026rdquo; and the platform handles routing, escalation, and automatic fallback to a secondary if the primary does not respond.\u003c/p\u003e\n\u003ch3 id=\"ai-drafted-incident-updates-the-low-hanging-fruit\"\u003eAI-Drafted Incident Updates: The Low-Hanging Fruit\u003c/h3\u003e\n\u003cp\u003eOne of ilert\u0026rsquo;s first generative AI use cases was drafting customer-facing incident communications. During active firefighting, the last thing a responder wants to think about is how to phrase a professional status-page update that aligns with the organization\u0026rsquo;s communication standards. Birol describes a workflow where the responder types a few keywords — \u0026ldquo;payment API is broken\u0026rdquo; or even just \u0026ldquo;nothing works\u0026rdquo; — and the platform produces a polished message. It saves only a few minutes per update, but those minutes matter when you are simultaneously diagnosing and mitigating a live incident.\u003c/p\u003e\n\u003cp\u003eThis resonates with Paulina\u0026rsquo;s observation that developers have always hated writing reports and documentation. Incident communication was one of the first places teams started trusting AI, precisely because the stakes of a slightly imperfect status update are much lower than the stakes of an incorrect remediation action — making it a natural entry point for building organizational trust in AI tooling.\u003c/p\u003e\n\u003ch3 id=\"building-the-ai-sre-root-cause-analysis-in-under-four-minutes\"\u003eBuilding the AI SRE: Root Cause Analysis in Under Four Minutes\u003c/h3\u003e\n\u003cp\u003eBirol\u0026rsquo;s boldest claim: by the end of 2026, AI SRE agents will reach the maturity level that coding agents achieved, and on-call engineers will only be paged when the agent cannot resolve the issue itself. The path there starts with automated root cause analysis.\u003c/p\u003e\n\u003cp\u003eWhen an alert fires, ilert\u0026rsquo;s agent begins triage immediately — clustering 50 alerts into two or three distinct problem groups, then running a root cause investigation on each cluster. The target is to have a complete RCA ready within three to four minutes, roughly the time it takes a human to register the notification, get out of bed, and open a laptop. By the time the responder is ready to look, they see a structured assessment rather than raw alerts.\u003c/p\u003e\n\u003cp\u003eThe investigation follows the same reasoning a human would apply: Where is the problem located? What has changed recently? Since the number-one cause of incidents is change — deployments, configuration updates, new releases, feature flags — the agent checks logs, metrics, and recent releases to build a complete picture. As Mattias puts it from years of late-night firefighting: \u0026ldquo;You try to go into logs, figure out what changed, look in Slack messages — but the agent is really good at finding these things. When I open the alert, it\u0026rsquo;s already filled with all this information.\u0026rdquo;\u003c/p\u003e\n\u003ch3 id=\"from-analysis-to-autonomous-remediation-the-trust-ladder\"\u003eFrom Analysis to Autonomous Remediation: The Trust Ladder\u003c/h3\u003e\n\u003cp\u003eMattias asks the critical question: where is the threshold where the agent should stop trying to fix things and wake up a human? Birol frames this as a progression — a trust ladder that organizations climb at their own pace.\u003c/p\u003e\n\u003cp\u003eThe first rung is read-only analysis: the agent investigates and presents findings, but takes no action. This is where teams gain confidence by observing the quality of the agent\u0026rsquo;s reasoning without risk. As discussed in \u003ca href=\"/episodes/098-beyond-ai-sre/\"\u003eepisode #98\u003c/a\u003e, where Andrey described a similar trust-building approach for Boris, the key is starting with tasks where the agent cannot do much harm.\u003c/p\u003e\n\u003cp\u003eThe next step is supervised action — the agent proposes remediation steps (increase a load balancer timeout, roll back a deployment) and a human approves or rejects. Eventually, for well-understood failure modes with high-confidence diagnoses, the agent acts autonomously. ilert\u0026rsquo;s governance model moves progressively from read-only to supervised to fully autonomous, with audit trails and human-in-the-loop controls at every stage.\u003c/p\u003e\n\u003ch3 id=\"closing-the-loop-ai-powered-post-mortems-and-documentation\"\u003eClosing the Loop: AI-Powered Post-Mortems and Documentation\u003c/h3\u003e\n\u003cp\u003eThe hosts and Birol agree that AI\u0026rsquo;s biggest impact on incident management may be after the incident is over. A well-prepared post-mortem meeting requires hours of manual reconstruction — building a timeline, correlating logs, identifying contributing factors, drafting remediation proposals. Without that preparation, Birol argues, the meeting is \u0026ldquo;wasted time.\u0026rdquo; With an AI agent that has already observed the entire incident lifecycle, the reconstruction comes for free.\u003c/p\u003e\n\u003cp\u003eBut the agent can go further: it can suggest concrete remediation measures — timeout adjustments, architectural changes, code-level fixes — and even integrate with source code management tools to propose specific changes. Mattias sees this as closing the learning circle: the incident feeds back into the left side of the development lifecycle, preventing the next occurrence rather than just documenting the last one.\u003c/p\u003e\n\u003cp\u003ePaulina raises a broader point about documentation debt. Code is changing faster than ever thanks to AI-assisted development, but documentation is not keeping pace — and she notes that this was already a problem before AI. She recalls Azure courses being taught on outdated documentation because features shipped faster than docs could follow. If AI can handle the documentation work that engineers consistently avoid, the hosts argue, that alone justifies adoption.\u003c/p\u003e\n\u003ch3 id=\"adopting-agents-is-not-a-nice-to-have\"\u003eAdopting Agents Is Not a Nice-to-Have\u003c/h3\u003e\n\u003cp\u003eThe episode closes with a strong call to action from all three participants. Birol acknowledges that senior, highly skilled engineers tend to be the most cautious about deploying agents in production — but his advice is to start with risk-free tasks where an agent cannot do much harm and build from there.\u003c/p\u003e\n\u003cp\u003eHe addresses the concern that over-reliance on agents will erode engineering skills, comparing it to the relationship between high-level programming languages and memory management: \u0026ldquo;It\u0026rsquo;s always good to have a good understanding of at least one abstraction layer below.\u0026rdquo; The current generation of engineers may be the last to have written significant code entirely by hand, but that foundational knowledge makes them better at directing and evaluating agents — not worse.\u003c/p\u003e\n\u003cp\u003eThe business case is straightforward: organizations that reduce cycle times and respond faster than their peers gain a competitive advantage that matters to customers. The guest frames agent adoption as something that applies equally to software development and to operations, arguing it is becoming the new standard rather than an optional enhancement.\u003c/p\u003e\n\u003cp\u003ePaulina draws a parallel to security: just as security must be embedded at every step of the process, AI integration follows the same pattern. And Birol delivers the sharpest version of the argument: if you choose not to use agents to detect vulnerabilities in your software stack, attackers will use agents to find those same vulnerabilities first. Speed is not just an efficiency metric — it is a security imperative.\u003c/p\u003e\n\u003ch2 id=\"highlights\"\u003eHighlights\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eBirol on the future of on-call:\u003c/strong\u003e \u0026ldquo;We\u0026rsquo;re heading to a future where you won\u0026rsquo;t be paged anymore. You will only be paged if your agent is not able to fix the problem for you. My prediction is by the end of this year, AI SRE will reach the same level of maturity that we experienced with coding agents.\u0026rdquo; A bold timeline from the CEO of an incident management platform — and a concrete vision of what on-call looks like when the first responder is not human. Listen to the full episode to hear how ilert is building toward that goal.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eBirol on post-mortem preparation:\u003c/strong\u003e \u0026ldquo;If you just go to a post-mortem meeting without preparation, it\u0026rsquo;s wasted time. But if you go prepared and have the full post-mortem document ready, it saves you hours — and that\u0026rsquo;s why it\u0026rsquo;s irresponsible not to use it.\u0026rdquo; Strong words: not using AI for post-mortems is not just leaving value on the table, it is irresponsible. Tune in to hear what an AI-prepared post-mortem actually includes — from incident reconstruction to architectural change proposals.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eMattias on 3 AM firefighting:\u003c/strong\u003e \u0026ldquo;Waking up a lot of nights, sitting at your laptop in the dark trying to fix things — you try to go into logs, figure out what changed, look in Slack messages. But the agent is really good at finding these things. When I open the alert, it\u0026rsquo;s already filled with all this information. That\u0026rsquo;s a big step.\u0026rdquo; Anyone who has done on-call knows this pain. Listen to the episode to hear how automated RCA in under four minutes changes the experience.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eBirol on agents and the security arms race:\u003c/strong\u003e \u0026ldquo;If you think \u0026lsquo;I\u0026rsquo;m not going to trust an agent to detect my vulnerabilities,\u0026rsquo; then an attacker will use agents to detect vulnerabilities in your software. If you don\u0026rsquo;t use agents to detect the vulnerabilities before a potential attacker detects them — that\u0026rsquo;s why it\u0026rsquo;s not a nice-to-have.\u0026rdquo; The strongest argument for agent adoption is not efficiency — it is that the adversary is already using them. Give this episode a listen for the full case on why waiting is a risk, not a strategy.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eBirol on being the last generation:\u003c/strong\u003e \u0026ldquo;We\u0026rsquo;re the last generation of engineers who knows how to code by hand and have hopefully written a significant piece of code by hand. But now we need to adopt agents — for software development, but also for operations. It\u0026rsquo;s not a nice-to-have. It\u0026rsquo;s becoming the new standard.\u0026rdquo; A reflective moment from a founder who has watched the industry evolve from Nagios alerts to autonomous remediation. Listen to hear why he thinks understanding \u0026ldquo;one abstraction layer below\u0026rdquo; still matters even as agents take over.\u003c/p\u003e\n\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"resources\"\u003eResources\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\n\u003cp\u003e\u003ca href=\"https://www.ilert.com/\"\u003eilert — AI-First Incident Management Platform\u003c/a\u003e — The incident management platform Birol co-founded, built around the principle that you should only get paged when the AI cannot safely proceed on its own.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003ca href=\"https://www.ilert.com/product/ilert-ai\"\u003eilert AI SRE — Secure Incident Investigation and Resolution\u003c/a\u003e — ilert\u0026rsquo;s AI SRE product page detailing the agent that investigates alerts, performs root cause analysis, and proposes or executes remediation actions with human-in-the-loop governance.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003ca href=\"https://www.harness.io/blog/birol-yildiz-on-autonomous-incident-response-and-the-future-of-ai-sre\"\u003eBirol Yildiz on Autonomous Incident Response and the Future of AI SRE (Harness / ShipTalk)\u003c/a\u003e — An in-depth conversation with Birol about how AI is transforming reliability engineering from diagnosis assistance to autonomous outage resolution.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003ca href=\"https://sre.google/sre-book/postmortem-culture/\"\u003ePostmortem Culture: Learning from Failure (Google SRE Book)\u003c/a\u003e — Google\u0026rsquo;s foundational chapter on blameless post-mortems — the manual process that AI-generated post-mortem documents are now accelerating.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003ca href=\"https://www.ilert.com/blog/postmortem-template-to-optimize-your-incident-response\"\u003eilert Postmortem Template to Optimize Your Incident Response\u003c/a\u003e — ilert\u0026rsquo;s guide to structuring post-mortem documents, providing context for the AI-generated post-mortems discussed in the episode.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003ca href=\"https://metoro.io/blog/top-ai-sre-tools\"\u003eTop AI SRE Tools in 2026 (Metoro)\u003c/a\u003e — A comprehensive comparison of the emerging AI SRE category including ilert, incident.io, PagerDuty, and others — useful for teams evaluating where to start with AI-powered incident response.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003ca href=\"https://www.jamesridgway.co.uk/mastering-alert-fatigue-avoiding-the-monitoring-and-alerting-pitfalls/\"\u003eMastering Alert Fatigue: Avoiding the Monitoring and Alerting Pitfalls\u003c/a\u003e — A practical guide to the alert fatigue problem the hosts discuss, covering the distinction between actionable alerts and informational noise.\u003c/p\u003e\n\u003c/li\u003e\n\u003c/ul\u003e"},{"title":"#98 - Beyond AI SRE","date_published":"2026-04-21T12:46:53+01:00","date_modified":"2026-04-21T12:46:53+01:00","id":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/098-beyond-ai-sre/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/098-beyond-ai-sre/","authors":[{"name":"DevSecOps Talks"}],"content_html":"\u003cp\u003eAndrey shares the thinking behind Boris and the idea of going beyond AI SRE. The conversation covers the DevOps talent shortage, the coming squeeze on AI costs, why repeatable operational tasks are a strong fit for agents, and why customer data should stay in the customer\u0026rsquo;s own AWS account.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/company/devsecops-talks/\"\u003eDiscuss the episode or ask us anything on LinkedIn\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"single_player_container\"\u003e\n   \u003ciframe\n     title=\"DEVSECOPS Talks #98 - Beyond AI SRE\"\n     height=\"122\"\n     width=\"100%\"\n     style=\"border: none;\"\n     scrolling=\"no\"\n     data-name=\"pb-iframe-player\"\n     src=\"https://www.podbean.com/media/player/8qpfq-1aa42b3-pb?from=yiiadmin\u0026download=1\u0026version=1\u0026skin=1\u0026btn-skin=107\u0026auto=0\u0026download=1\u0026pbad=1\"\n   \u003e\u003c/iframe\u003e\n \u003c/div\u003e\n\n\u003chr\u003e\n\u003cdiv style=\"position: relative; padding-bottom: 56.25%; height: 0; overflow: hidden;\"\u003e\n      \u003ciframe allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share; fullscreen\" loading=\"eager\" referrerpolicy=\"strict-origin-when-cross-origin\" src=\"https://www.youtube.com/embed/VGmyXiptRhQ?autoplay=0\u0026amp;controls=1\u0026amp;end=0\u0026amp;loop=0\u0026amp;mute=0\u0026amp;start=0\" style=\"position: absolute; top: 0; left: 0; width: 100%; height: 100%; border:0;\" title=\"YouTube video\"\u003e\u003c/iframe\u003e\n    \u003c/div\u003e\n\n\u003ch2 id=\"summary\"\u003eSummary\u003c/h2\u003e\n\u003cp\u003eMost tools in the emerging \u0026ldquo;AI SRE\u0026rdquo; category focus squarely on incident response — something breaks, the bot investigates. Andrey argues that is only scratching the surface: the real drain on DevOps teams is the unglamorous day-two work nobody wants to do — cost reports, health-event triage, maintenance tasks — and that is where an AI teammate should live. In this episode, Andrey and Paulina discuss why 2026 is shaping up to be the year of the \u0026ldquo;big squeeze\u0026rdquo; as AI subsidies dry up, why the DevOps talent shortage makes agentic AI a necessity rather than a luxury, and how Boris — Andrey\u0026rsquo;s AI DevOps teammate — is architected to go beyond incident response while letting customers keep ownership of their own data.\u003c/p\u003e\n\u003ch2 id=\"key-topics\"\u003eKey Topics\u003c/h2\u003e\n\u003ch3 id=\"the-big-squeeze-ai-economics-are-changing-fast\"\u003eThe Big Squeeze: AI Economics Are Changing Fast\u003c/h3\u003e\n\u003cp\u003eAndrey opens with a macro observation: while the \u0026ldquo;is AI taking over our jobs?\u0026rdquo; question persists, the economic ground beneath it is shifting. Hyperscalers are cutting workforce expecting AI-driven efficiency gains — Block eliminated over 4,000 positions in an AI-driven restructuring, as discussed in \u003ca href=\"/episodes/094-small-tasks-big-wins-the-ai-dev-loop-at-system-initiative/\"\u003eepisode #94\u003c/a\u003e — yet actual demand for computer science professionals remains higher than ever. Everyone is a developer with a $20 subscription, but Andrey questions how long that lasts.\u003c/p\u003e\n\u003cp\u003eThe core argument: AI infrastructure providers face astronomical capital expenditure. Oracle is reportedly going cash-flow negative to build out data centers. Someone has to pay for it, and the subscription model is not sustainable at current price points. Claude Code, Cursor, and similar tools have already started cutting their subscription allowances — after a few heavy sessions with a good model, the flat-rate plan \u0026ldquo;becomes a pumpkin\u0026rdquo; and users pay API rates.\u003c/p\u003e\n\u003cp\u003eAndrey calls 2026 \u0026ldquo;the year of the big squeeze.\u0026rdquo; As subsidies dry up, leaders will think harder about where to deploy AI. A $5,000–$10,000 monthly AI bill that makes a team of six or seven people twice as productive is still a clear win — but the days of throwing tokens at everything with an unlimited plan are ending. Paulina adds that smaller organizations will feel this disproportionately, raising the entry barrier for companies without deep pockets. The hosts expect increasing focus on open-source models as organizations seek sustainable alternatives.\u003c/p\u003e\n\u003ch3 id=\"the-devops-talent-shortage-is-the-real-driver\"\u003eThe DevOps Talent Shortage Is the Real Driver\u003c/h3\u003e\n\u003cp\u003eWhy build an AI DevOps teammate at all? Andrey points to a straightforward market reality: good DevOps engineers are extremely hard to find. If that were not true, neither his consulting firm FivexL nor Paulina\u0026rsquo;s Dubas Consulting would have customers. The talent shortage leads to developers waiting for answers, projects stalling for lack of resources, and the people who are hired spending half their time as a help desk for developers, security teams, and managers — leaving little capacity for value-add work.\u003c/p\u003e\n\u003cp\u003eAgentic coding tools help to some extent — developers can self-serve on small infrastructure tasks. But Andrey cautions that you still need expertise to tell when the LLM is giving you good answers versus nonsense, and you need grounding and sophistication to validate outputs. For genuinely new architectural work, humans remain essential: \u0026ldquo;LLMs are regurgitators — they will regurgitate what they\u0026rsquo;ve seen before. If you need to come up with something generally new, that\u0026rsquo;s where you need humans.\u0026rdquo;\u003c/p\u003e\n\u003cp\u003ePaulina reinforces this point by noting that architecture needs to account for scale from the start. Doing a little thinking upfront saves significant refactoring pain later — and that kind of forward-looking judgment is not something LLMs reliably provide.\u003c/p\u003e\n\u003ch3 id=\"day-two-operations-the-unsexy-work-that-hurts-you\"\u003eDay-Two Operations: The Unsexy Work That Hurts You\u003c/h3\u003e\n\u003cp\u003eBeyond the help-desk drain, Andrey identifies a category of work that consistently falls through the cracks: predictable, repeatable tasks that nobody wants to do. Cost reports that get skipped because engineers are focused on higher-value work. Maintenance tasks that get deferred because people are too busy or simply forget. AWS health events that go unreviewed. New AWS service announcements that nobody maps to their actual infrastructure.\u003c/p\u003e\n\u003cp\u003eThe consequences are real: a missed cost report means surprise spend; deferred maintenance surfaces as a production incident; an unread health advisory becomes an outage followed by days of post-mortem. These are exactly the tasks where LLMs shine — not because they require creativity, but because they require consistency. They are predictable, repeatable, and can be triggered on a schedule or in response to a signal.\u003c/p\u003e\n\u003ch3 id=\"the-ai-sre-category--and-why-it-is-not-enough\"\u003eThe AI SRE Category — And Why It Is Not Enough\u003c/h3\u003e\n\u003cp\u003eAndrey notes that a new product category called \u0026ldquo;AI SRE\u0026rdquo; has emerged, with tools like Cleric, Resolve.ai, and incident.io\u0026rsquo;s AI features focused primarily on incident response — connecting to monitoring data, logs, and cloud APIs to diagnose problems when something breaks. Boris can do the same.\u003c/p\u003e\n\u003cp\u003eBut Andrey argues the category is misnamed. Actual SRE work is about building systems and optimizing software so incidents do not happen in the first place. Most \u0026ldquo;AI SRE\u0026rdquo; tools address only the reactive side. Boris aims to go beyond incident response into proactive operations: generating cost reports, analyzing AWS health events before monitoring raises an alert, mapping AWS announcements to the customer\u0026rsquo;s actual infrastructure, and serving as the team\u0026rsquo;s operational knowledge layer.\u003c/p\u003e\n\u003cp\u003ePaulina quips about the ever-expanding title situation in the industry — DevOps, platform engineering, SRE, cloud engineering, infrastructure engineering — and Andrey laughs that he usually just tells people \u0026ldquo;I do computers.\u0026rdquo;\u003c/p\u003e\n\u003ch3 id=\"boris-lives-in-slack--and-that-changes-everything\"\u003eBoris Lives in Slack — And That Changes Everything\u003c/h3\u003e\n\u003cp\u003eA key architectural choice: Boris lives in Slack rather than requiring a separate interface. Andrey argues this matters because today\u0026rsquo;s AI interactions are almost entirely one-to-one — you talk to your terminal, to Cursor, to ChatGPT — and then you have to relay the results to your team or copy them over. When a team is discussing an incident in a Slack thread, switching to another tool to get AI help breaks the flow and scatters context.\u003c/p\u003e\n\u003cp\u003eWith Boris in the thread, you can ask it to summarize the discussion, build a post-mortem, or execute a standard operating procedure (SOP) with all the thread context already available. The team communication aspect is a differentiator: instead of an AI that talks to one person, Boris participates in the team conversation.\u003c/p\u003e\n\u003cp\u003eThe workflow Andrey sees emerging: Boris has access to Slack, GitHub, and AWS. Teams describe work in Slack, Boris creates detailed GitHub issues with full context from all connected sources, and engineers feed those issues to their local coding agents (like Claude Code). The team is also building an MCP server so coding agents can query Boris directly for additional context — avoiding the need for every developer to individually configure access to Slack, AWS, and other services locally.\u003c/p\u003e\n\u003ch3 id=\"data-sovereignty-you-own-your-data\"\u003eData Sovereignty: You Own Your Data\u003c/h3\u003e\n\u003cp\u003eAndrey addresses a trust problem head-on. Many AI SRE tools promise to \u0026ldquo;preserve tribal knowledge,\u0026rdquo; but the hosts ask: where does that knowledge go? It goes to a SaaS provider. Disconnect the tool, and the knowledge vanishes with it.\u003c/p\u003e\n\u003cp\u003eBoris takes a different approach. When a customer sets up Boris, they provide an AWS account. Boris creates S3 buckets, DynamoDB tables, and other serverless resources in the customer\u0026rsquo;s own account. All structured data is stored at rest on the customer side. Boris only loads data into memory for inference — nothing from the data perspective is stored on Boris\u0026rsquo;s side.\u003c/p\u003e\n\u003cp\u003eAndrey acknowledges this was a deliberately self-inflicted architectural hurdle. Building a system where all data lives on the customer side while the inference engine runs separately requires significant engineering gymnastics — no local database, careful memory management, a fundamentally different system design. But the team made this choice from day one because they have seen what happens when knowledge gets siloed in third-party tools: \u0026ldquo;We don\u0026rsquo;t want to create a new silo of communication with AI on top of the existing silos between people.\u0026rdquo;\u003c/p\u003e\n\u003cp\u003eHe also notes the irony: while they believe data sovereignty matters, plenty of organizations are \u0026ldquo;yoloing\u0026rdquo; their sensitive data into ChatGPT without a second thought. History may prove them wrong — but that is their bet.\u003c/p\u003e\n\u003ch3 id=\"model-independence-and-sustainable-ai\"\u003eModel Independence and Sustainable AI\u003c/h3\u003e\n\u003cp\u003eAnother deliberate architectural constraint: Boris is designed to not depend on any particular model. Today it primarily uses Anthropic\u0026rsquo;s Claude, but the architecture allows swapping to self-hosted or open-source models. This ties back to the \u0026ldquo;big squeeze\u0026rdquo; thesis — as AI costs evolve and open-source models improve, customers should not be locked into a single provider\u0026rsquo;s pricing and availability.\u003c/p\u003e\n\u003ch3 id=\"pricing-by-the-hour-not-by-the-token\"\u003ePricing by the Hour, Not by the Token\u003c/h3\u003e\n\u003cp\u003eThe hosts discuss how to make AI pricing understandable, especially for customers who are still getting used to automation itself — let alone AI. Boris bills at $25 per hour of agent work time. Andrey argues this is far easier to reason about than token-based pricing: you can see how many hours the agent spent, compare it to what a human would cost, and decide if the economics work. Twenty hours a month at $25 is $500 — an additional resource with no commitment that you can \u0026ldquo;fire anytime.\u0026rdquo;\u003c/p\u003e\n\u003cp\u003eThis model also gives the Boris team room to optimize tokenomics on the backend without passing complexity to the customer. Andrey notes that figuring out sustainable AI business models is something every company in the space is still working through.\u003c/p\u003e\n\u003ch2 id=\"highlights\"\u003eHighlights\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eAndrey on the big squeeze:\u003c/strong\u003e \u0026ldquo;2026 will be the year of the big squeeze. All of the companies that host LLMs have astronomical capex — Oracle is set to go cash negative. Someone\u0026rsquo;s got to pay for it, and the subscription model is not sustainable.\u0026rdquo; With AI coding tools already cutting allowances, the era of unlimited $20 plans is ending — and that will reshape how every organization thinks about AI ROI. Listen to the full episode to hear how Andrey connects this macro shift to the case for building an AI DevOps teammate.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eAndrey on the AI SRE misnomer:\u003c/strong\u003e \u0026ldquo;Those AI SRE tools — their primary focus is incident response. The actual work of SRE is building systems so incidents don\u0026rsquo;t happen. We came up with a new niche and misnamed it, as we usually do in this industry.\u0026rdquo; Most tools labeled \u0026ldquo;AI SRE\u0026rdquo; only address the reactive half of the job. The proactive half — cost management, health-event triage, maintenance — is where the real value lies. Tune in to hear what going beyond AI SRE actually looks like in practice.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003ePaulina on the title treadmill:\u003c/strong\u003e After listing DevOps, platform engineering, SRE, cloud engineering, and infrastructure engineering, Paulina notes: \u0026ldquo;My mother keeps asking, what are you doing at work? You go to a bank asking for a loan and they\u0026rsquo;re like, what do you do for work?\u0026rdquo; Andrey\u0026rsquo;s answer: \u0026ldquo;I usually say computers. I do computers.\u0026rdquo; Give the episode a listen for more laughs and sharp takes on where the industry is headed.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eAndrey on LLMs and creativity:\u003c/strong\u003e \u0026ldquo;LLMs are regurgitators. They will regurgitate what they\u0026rsquo;ve seen before — repeating the same patterns. But if you need to come up with something generally new, that\u0026rsquo;s where you need humans.\u0026rdquo; AI is great for predictable, repeatable work. For architectural innovation, do not expect it to replace your senior engineers anytime soon. Listen to the episode for the full argument on where AI helps and where it falls short.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eAndrey on data sovereignty:\u003c/strong\u003e \u0026ldquo;All those AI tools will tell you they preserve your tribal knowledge. But where does this knowledge go? They store it on their side. You disconnect the tool, the knowledge is gone.\u0026rdquo; Boris stores all customer data in the customer\u0026rsquo;s own AWS account — a deliberate architectural constraint that adds engineering complexity but prevents yet another knowledge silo. Hear the full breakdown of why they chose this path and what it cost them architecturally.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eAndrey on pricing simplicity:\u003c/strong\u003e \u0026ldquo;We bill $25 per hour. You can see how much time the agent takes. You can compare it — 20 hours a month is $500, an additional resource you can fire anytime. That\u0026rsquo;s easier than tokens.\u0026rdquo; When your customers are still figuring out what AI even is, the last thing they need is tokenomics. Listen to the episode to hear how the hosts think about sustainable AI business models.\u003c/p\u003e\n\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"resources\"\u003eResources\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\n\u003cp\u003e\u003ca href=\"https://www.getboris.ai/\"\u003eB.O.R.I.S. — Your AI DevOps Teammate\u003c/a\u003e — Andrey\u0026rsquo;s AI-powered DevOps agent that lives in Slack, connects to AWS and GitHub, and goes beyond incident response into day-to-day operations and knowledge preservation.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003ca href=\"https://metoro.io/blog/top-ai-sre-tools\"\u003eTop AI SRE Tools in 2026: A Comprehensive Comparison (Metoro)\u003c/a\u003e — A comparison of the emerging AI SRE category, covering tools like Resolve.ai, Cleric, incident.io, and PagerDuty\u0026rsquo;s AI features — the landscape Boris is positioning beyond.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003ca href=\"https://cleric.ai/\"\u003eCleric: AI SRE Teammate\u003c/a\u003e — One of the AI SRE tools focused on autonomous incident investigation and root cause analysis, representative of the category Andrey describes as \u0026ldquo;squarely focused on incident response.\u0026rdquo;\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003ca href=\"https://fortune.com/2026/03/10/oracle-best-quarter-negative-free-cash-flow-ai-spending/\"\u003eOracle\u0026rsquo;s Free Cash Flow Hits Negative $24.7 Billion Amid AI Spending (Fortune)\u003c/a\u003e — The numbers behind Andrey\u0026rsquo;s \u0026ldquo;big squeeze\u0026rdquo; thesis: Oracle\u0026rsquo;s capex rocketed to $50 billion for AI data center buildout while free cash flow went deeply negative.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003ca href=\"https://github.com/modelcontextprotocol/servers\"\u003eModel Context Protocol (MCP) Servers\u003c/a\u003e — The open standard Boris is building on so coding agents like Claude Code can query Boris directly for infrastructure context without each developer configuring access individually.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003ca href=\"https://github.com/aws-samples/aws-health-aware\"\u003eAWS Health Aware (AHA)\u003c/a\u003e — AWS\u0026rsquo;s open-source framework for automated health event notifications — the kind of proactive operational task Boris aims to handle with AI-powered analysis rather than simple forwarding.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003ca href=\"https://the-decoder.com/anthropic-cuts-off-third-party-tools-like-openclaw-for-claude-subscribers-citing-unsustainable-demand/\"\u003eAnthropic Cuts Off Third-Party Tools, Citing Unsustainable Demand (The Decoder)\u003c/a\u003e — Coverage of AI providers pulling back subsidies as real per-user compute costs dwarf subscription revenue, illustrating the \u0026ldquo;big squeeze\u0026rdquo; dynamic the hosts discuss.\u003c/p\u003e\n\u003c/li\u003e\n\u003c/ul\u003e"},{"title":"#97 - Shift Left, Get Hacked: Supply Chain Attacks Hit Devs","date_published":"2026-04-16T00:14:45+01:00","date_modified":"2026-04-16T00:14:45+01:00","id":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/097-shift-left-get-hacked-supply-chain-attacks-hit-devs/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/097-shift-left-get-hacked-supply-chain-attacks-hit-devs/","authors":[{"name":"DevSecOps Talks"}],"content_html":"\u003cp\u003eMarch 2026 made supply chain attacks feel a lot less theoretical, but what made these incidents different? The hosts discuss compromised publishing credentials, automatic execution hooks like post-install scripts and Python \u003ccode\u003e.pth\u003c/code\u003e files, and how both humans and security tools caught the malicious releases. They also talk through concrete ways to make developer environments harder to abuse.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/company/devsecops-talks/\"\u003eDiscuss the episode or ask us anything on LinkedIn\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"single_player_container\"\u003e\n   \u003ciframe\n     title=\"DEVSECOPS Talks #97 - Shift Left, Get Hacked: Supply Chain Attacks Hit Devs\"\n     height=\"122\"\n     width=\"100%\"\n     style=\"border: none;\"\n     scrolling=\"no\"\n     data-name=\"pb-iframe-player\"\n     src=\"https://www.podbean.com/media/player/sb67i-1a9d44e-pb?from=yiiadmin\u0026download=1\u0026version=1\u0026skin=1\u0026btn-skin=107\u0026auto=0\u0026download=1\u0026pbad=1\"\n   \u003e\u003c/iframe\u003e\n \u003c/div\u003e\n\n\u003chr\u003e\n\u003cdiv style=\"position: relative; padding-bottom: 56.25%; height: 0; overflow: hidden;\"\u003e\n      \u003ciframe allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share; fullscreen\" loading=\"eager\" referrerpolicy=\"strict-origin-when-cross-origin\" src=\"https://www.youtube.com/embed/Vz-i7xodtlA?autoplay=0\u0026amp;controls=1\u0026amp;end=0\u0026amp;loop=0\u0026amp;mute=0\u0026amp;start=0\" style=\"position: absolute; top: 0; left: 0; width: 100%; height: 100%; border:0;\" title=\"YouTube video\"\u003e\u003c/iframe\u003e\n    \u003c/div\u003e\n\n\u003ch2 id=\"summary\"\u003eSummary\u003c/h2\u003e\n\u003cp\u003eAttackers are now shifting left faster than defenders — and they are going straight for the developers. In this full-squad episode, Andrey, Mattias, and Paulina unpack the March 2026 supply chain attack chain that started with Aqua Security\u0026rsquo;s Trivy scanner, cascaded into LiteLLM on PyPI, and was made glaringly obvious to human engineers when the attackers\u0026rsquo; own coding mistake turned their credential stealer into a fork bomb — though automated detection tools like Sonatype\u0026rsquo;s also flagged the malicious releases within seconds. The hosts also cover the North Korean-attributed Axios NPM compromise and lay out practical remediation steps — from dev containers and version delays to disabling post-install scripts — arguing that the old advice of \u0026ldquo;just check if the package looks legit\u0026rdquo; no longer holds when the attackers are compromising the publishers themselves.\u003c/p\u003e\n\u003ch2 id=\"key-topics\"\u003eKey Topics\u003c/h2\u003e\n\u003ch3 id=\"supply-chain-attacks-have-shifted-left--past-the-scanners\"\u003eSupply Chain Attacks Have Shifted Left — Past the Scanners\u003c/h3\u003e\n\u003cp\u003eThe hosts observe that supply chain attacks have fundamentally changed direction. Previously, the main concern was malicious code slipping into production through compromised dependencies. Now, attackers are targeting developers and their workstations before code even reaches the CI/CD pipeline. As Mattias puts it, the attackers are \u0026ldquo;shifting left even more\u0026rdquo; — striking earlier in the process than the security tools that are supposed to catch them. Andrey agrees that March 2026 felt like the moment supply chain attacks moved \u0026ldquo;from theoretical to actual danger zone.\u0026rdquo;\u003c/p\u003e\n\u003cp\u003eThis is not the first time DevSecOps Talks has covered supply chain security — episodes \u003ca href=\"/episodes/46-supply-chain/\"\u003e#46\u003c/a\u003e and \u003ca href=\"/episodes/53-supply-chain-again/\"\u003e#53\u003c/a\u003e explored attack vectors and mitigation frameworks. But what is different now is the sophistication: attackers are not creating suspicious-looking typosquatting packages; they are compromising the signing keys and publishing credentials of legitimate, widely trusted projects.\u003c/p\u003e\n\u003ch3 id=\"the-trivy-to-litellm-attack-chain\"\u003eThe Trivy-to-LiteLLM Attack Chain\u003c/h3\u003e\n\u003cp\u003eOn March 1, Aqua Security disclosed that its open-source Trivy vulnerability scanner had been compromised. The attacker group TeamPCP gained access to credentials used by the Trivy GitHub Actions workflow. Aqua initiated credential rotation, but the rotation was not atomic — according to their own post-incident analysis, the attackers may have obtained the refreshed credentials before the old ones were fully revoked.\u003c/p\u003e\n\u003cp\u003eOn March 19, TeamPCP used still-valid credentials to force-push 76 of 77 release tags in the \u003ccode\u003etrivy-action\u003c/code\u003e repository and all seven tags in \u003ccode\u003esetup-trivy\u003c/code\u003e, redirecting trusted references to malicious commits containing a multi-stage credential stealer. Because many CI/CD pipelines reference version tags rather than pinned commit SHAs, organizations unknowingly ran the compromised code.\u003c/p\u003e\n\u003cp\u003eThe Trivy foothold gave TeamPCP the keys to publish arbitrary versions of LiteLLM — a popular Python gateway to multiple LLM providers, downloaded 3.4 million times per day — to PyPI. Compromised versions 1.82.7 and 1.82.8 appeared on March 24, containing a malicious \u003ccode\u003e.pth\u003c/code\u003e file that executed automatically on every Python process startup. The payload harvested SSH keys, cloud tokens, Kubernetes secrets, and \u003ccode\u003e.env\u003c/code\u003e files, attempted lateral movement across Kubernetes clusters, and installed a persistent backdoor.\u003c/p\u003e\n\u003cp\u003eThe hosts highlight the irony: the attackers\u0026rsquo; own code contained a bug. A flawed conditional in the credential stealer effectively turned it into a fork bomb, crashing systems with out-of-memory errors. This made the compromise immediately visible to human engineers — runaway processes and CPU pegged at 100% — while automated detection tools like Sonatype\u0026rsquo;s flagged the malicious releases within seconds of publication. As Andrey notes, \u0026ldquo;we actually got lucky there.\u0026rdquo; The compromised packages were caught within hours before PyPI quarantined them.\u003c/p\u003e\n\u003ch3 id=\"the-axios-npm-compromise-and-state-sponsored-actors\"\u003eThe Axios NPM Compromise and State-Sponsored Actors\u003c/h3\u003e\n\u003cp\u003eThe episode also covers the Axios NPM supply chain attack, where malicious versions of the extremely popular HTTP client library (over 100 million weekly downloads) were published to the NPM registry on March 31. Google Threat Intelligence Group attributed this attack to UNC1069, a North Korean-nexus, financially motivated threat actor active since at least 2018.\u003c/p\u003e\n\u003cp\u003eThe malicious versions deployed the WAVESHAPER.V2 backdoor across Windows, macOS, and Linux. The versions were live for approximately three hours before being removed.\u003c/p\u003e\n\u003cp\u003ePaulina notes this makes the old heuristics obsolete — looking at star counts, maintainer reputation, and project age no longer protects you when attackers are going directly after the maintainers themselves.\u003c/p\u003e\n\u003ch3 id=\"automatic-execution-hooks-a-low-hanging-attack-vector\"\u003eAutomatic Execution Hooks: A Low-Hanging Attack Vector\u003c/h3\u003e\n\u003cp\u003eThe hosts identify automatic code execution during package installation or startup as a common mechanism in these attacks. In the NPM ecosystem, packages can define lifecycle scripts — \u003ccode\u003epostinstall\u003c/code\u003e, \u003ccode\u003epreinstall\u003c/code\u003e, and others — that run automatically after installation. The LiteLLM attack on PyPI used a different mechanism: a malicious \u003ccode\u003e.pth\u003c/code\u003e file, which Python executes automatically on interpreter startup, combined with build-time execution paths. In both cases, malicious code runs before any scanner or manual review can catch it.\u003c/p\u003e\n\u003cp\u003eMattias recommends switching to pnpm, which as of version 10 disables lifecycle scripts (postinstall, preinstall, etc.) by default, requiring explicit opt-in via an allowlist. This is a concrete, low-effort step that blocks one of the most commonly exploited attack vectors in the NPM ecosystem. For Python, the hosts note that UV and pip pull from the same PyPI registry but offer different configuration options that may help limit automatic execution.\u003c/p\u003e\n\u003ch3 id=\"remediation-what-can-teams-actually-do\"\u003eRemediation: What Can Teams Actually Do?\u003c/h3\u003e\n\u003cp\u003eThe hosts go through a practical list of defensive measures:\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eDelay version updates.\u003c/strong\u003e Do not install the latest version the moment it drops. NPM supports a \u003ccode\u003emin-release-age\u003c/code\u003e setting in \u003ccode\u003e.npmrc\u003c/code\u003e that refuses to install any package version published less than a specified number of days ago. pnpm 10.16 added \u003ccode\u003eminimumReleaseAge\u003c/code\u003e for the same purpose. A seven-day delay would have blocked both the LiteLLM and Axios attacks, where malicious versions were caught within hours to days.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003ePin versions and review updates.\u003c/strong\u003e Dependabot and similar tools are valuable but should not be set to auto-merge on the latest version without review. The hosts caution that automated dependency updates can pull in compromised packages before anyone notices.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eRotate credentials — and know how to.\u003c/strong\u003e Mattias shares a recent experience where his team had to rotate 500 passwords and tokens, with no documentation on how to do it. Credential rotation took weeks. Having documented, tested rotation procedures is essential.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eIsolate development environments.\u003c/strong\u003e Mattias advocates strongly for dev containers with temporary tokens as his preferred mitigation. If a compromised package runs inside a container, the blast radius is limited to that container — no host-level SSH keys, no persistent cloud credentials, nothing valuable to steal. The container can simply be destroyed. With AI coding tools able to generate dev container configurations quickly, the hosts argue there is no excuse not to use them.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eProtect credentials on developer machines.\u003c/strong\u003e Andrey recommends storing SSH keys in the Mac Secure Enclave or a password manager like 1Password, using temporary credentials for cloud access via AWS SSO or similar tools, and never storing production keys in the development environment.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eUse DNS filtering.\u003c/strong\u003e Solutions like NextDNS or Cloudflare Warp can block resolution of known malicious command-and-control domains. When an attacker\u0026rsquo;s payload tries to phone home, DNS filtering can prevent the connection — and these services update their blocklists quickly.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eWatch AI code reviewers as a new vector.\u003c/strong\u003e Andrey raises a newer concern: if organizations run LLM-based code reviewers on pull requests — including those from external contributors — attackers can craft prompt injection payloads in their code. The code reviewer, running with a GitHub token potentially scoped beyond the target repository, becomes a vector for lateral movement.\u003c/p\u003e\n\u003ch3 id=\"security-now-episode-1072-the-detailed-breakdown\"\u003eSecurity Now Episode 1072: The Detailed Breakdown\u003c/h3\u003e\n\u003cp\u003eAndrey recommends Steve Gibson\u0026rsquo;s Security Now episode 1072 for anyone wanting a thorough technical breakdown of how the Trivy-to-LiteLLM attack chain unfolded, including the Trend Micro analysis and the timeline of credential rotation failures. At over 1,000 episodes, Security Now has been covering security far longer than DevSecOps Talks — \u0026ldquo;we are approaching 100, they already did 1,000,\u0026rdquo; Andrey quips.\u003c/p\u003e\n\u003ch2 id=\"highlights\"\u003eHighlights\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eAndrey:\u003c/strong\u003e \u0026ldquo;March felt like we are moving supply chain attacks from theoretical to actual danger zone.\u0026rdquo; The Trivy breach proved that even security tools — the scanners meant to protect you — can become the attack vector. If your security scanner is compromised, who watches the watchers?\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eMattias:\u003c/strong\u003e \u0026ldquo;The attackers are really shifting left even more. The attacks are happening before the code hits the CI/CD pipelines.\u0026rdquo; While defenders talk about shifting security left, attackers are already there — targeting developer workstations and package publishers, not production systems.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003ePaulina:\u003c/strong\u003e \u0026ldquo;We said the official packages maintained by a large crowd are safe to use. But what we\u0026rsquo;re seeing here is that they\u0026rsquo;re going for the maintainer itself.\u0026rdquo; The old heuristics — stars, downloads, active maintenance — no longer protect you when the publisher\u0026rsquo;s own credentials are compromised.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eAndrey on the LiteLLM bug:\u003c/strong\u003e The credential stealer had a coding mistake that turned it into a fork bomb, crashing systems with out-of-memory errors — which made the compromise immediately obvious to engineers on the ground, even as automated tooling was also flagging it. \u0026ldquo;We actually got lucky there.\u0026rdquo; When your attacker\u0026rsquo;s own bug is one of the loudest alarms, that should worry you about the attacks that don\u0026rsquo;t have bugs.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eMattias on dev containers:\u003c/strong\u003e \u0026ldquo;If something happens, it\u0026rsquo;s isolated in the dev container. Anything you can get hold of is only temporary. I can just kill a container and I\u0026rsquo;m good again.\u0026rdquo; Dev containers with temporary tokens are his top recommendation for containing supply chain damage on developer machines.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eOn the Axios attack:\u003c/strong\u003e Google Threat Intelligence attributed the Axios NPM compromise to a North Korean-nexus threat actor. State-sponsored groups are now investing in supply chain attacks targeting the JavaScript and Python ecosystems at scale.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eAndrey on AI code reviewers:\u003c/strong\u003e If you run an LLM-based code reviewer on pull requests from external contributors, you have a new attack surface — crafted prompt injections in the code can hijack the reviewer\u0026rsquo;s GitHub token and poke around your other repositories.\u003c/p\u003e\n\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"resources\"\u003eResources\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://www.aquasec.com/blog/trivy-supply-chain-attack-what-you-need-to-know/\"\u003eAqua Security: Trivy Supply Chain Attack — What You Need to Know\u003c/a\u003e — Aqua\u0026rsquo;s own disclosure and post-incident analysis of the Trivy GitHub Actions compromise, including the credential rotation timeline.\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://www.crowdstrike.com/en-us/blog/from-scanner-to-stealer-inside-the-trivy-action-supply-chain-compromise/\"\u003eCrowdStrike: From Scanner to Stealer — Inside the trivy-action Supply Chain Compromise\u003c/a\u003e — Detailed technical breakdown of how TeamPCP weaponized the Trivy scanner to steal CI/CD secrets.\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://www.sonatype.com/blog/compromised-litellm-pypi-package-delivers-multi-stage-credential-stealer\"\u003eSonatype: Compromised litellm PyPI Package Delivers Multi-Stage Credential Stealer\u003c/a\u003e — Analysis of the malicious \u003ccode\u003e.pth\u003c/code\u003e file in LiteLLM versions 1.82.7 and 1.82.8, including the credential harvesting and lateral movement stages.\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://cloud.google.com/blog/topics/threat-intelligence/north-korea-threat-actor-targets-axios-npm-package\"\u003eGoogle Cloud Blog: North Korea-Nexus Threat Actor Compromises Axios NPM Package\u003c/a\u003e — Google Threat Intelligence Group\u0026rsquo;s attribution of the Axios compromise to UNC1069 and the WAVESHAPER.V2 backdoor.\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://twit.tv/shows/security-now/episodes/1072\"\u003eSecurity Now #1072: LiteLLM\u003c/a\u003e — Steve Gibson\u0026rsquo;s detailed breakdown of the Trivy-to-LiteLLM attack chain, recommended by the hosts for anyone wanting the full technical timeline.\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://pnpm.io/supply-chain-security\"\u003epnpm: Mitigating Supply Chain Attacks\u003c/a\u003e — How pnpm v10 blocks lifecycle scripts by default and its approach to supply chain security.\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://www.nodejs-security.com/blog/npm-ignore-scripts-best-practices-as-security-mitigation-for-malicious-packages\"\u003eNPM Ignore Scripts Best Practices\u003c/a\u003e — Practical guide to disabling post-install scripts in NPM as a security mitigation.\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://www.nodejs-security.com/blog/mitigate-supply-chain-security-with-devcontainers-and-1password-for-nodejs-local-development\"\u003eMitigate Supply Chain Security with DevContainers and 1Password\u003c/a\u003e — Walkthrough of using dev containers with short-lived credentials to isolate developer workstations from supply chain attacks.\u003c/li\u003e\n\u003c/ul\u003e"},{"title":"#96 - Keeping Platforms Simple and Fast with Joachim Hill-Grannec","date_published":"2026-04-01T21:54:54+01:00","date_modified":"2026-04-01T21:54:54+01:00","id":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/096-keeping-platforms-simple-and-fast-with-joachim-hill-grannec/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/096-keeping-platforms-simple-and-fast-with-joachim-hill-grannec/","authors":[{"name":"DevSecOps Talks"}],"content_html":"\u003cp\u003eThis episode with Joachim Hill-Grannec asks: How do platforms bloat, and how do you keep them simple and fast with trunk-based dev and small batches? Which metrics prove it works—cycle time, uptime, or developer experience? Can security act as a partner that speeds delivery instead of a gate?\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/company/devsecops-talks/\"\u003eDiscuss the episode or ask us anything on LinkedIn\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"single_player_container\"\u003e\n   \u003ciframe\n     title=\"DEVSECOPS Talks #96 - Keeping Platforms Simple and Fast with Joachim Hill-Grannec\"\n     height=\"122\"\n     width=\"100%\"\n     style=\"border: none;\"\n     scrolling=\"no\"\n     data-name=\"pb-iframe-player\"\n     src=\"https://www.podbean.com/media/player/g4amm-1a8a8ee-pb?from=yiiadmin\u0026download=1\u0026version=1\u0026skin=1\u0026btn-skin=107\u0026auto=0\u0026download=1\u0026pbad=1\"\n   \u003e\u003c/iframe\u003e\n \u003c/div\u003e\n\n\u003chr\u003e\n\u003cdiv style=\"position: relative; padding-bottom: 56.25%; height: 0; overflow: hidden;\"\u003e\n      \u003ciframe allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share; fullscreen\" loading=\"eager\" referrerpolicy=\"strict-origin-when-cross-origin\" src=\"https://www.youtube.com/embed/6o8q6g9cbOY?autoplay=0\u0026amp;controls=1\u0026amp;end=0\u0026amp;loop=0\u0026amp;mute=0\u0026amp;start=0\" style=\"position: absolute; top: 0; left: 0; width: 100%; height: 100%; border:0;\" title=\"YouTube video\"\u003e\u003c/iframe\u003e\n    \u003c/div\u003e\n\n\u003ch2 id=\"summary\"\u003eSummary\u003c/h2\u003e\n\u003cp\u003eIn this episode of DevSecOps Talks, Mattias speaks with Joachim Hill-Grannec, co-founder of Peltek, a boutique consulting firm specializing in high-availability, cloud-native infrastructure. Following up on a previous episode where Steve discussed cleaning up bloated platforms, Mattias and Joachim dig into \u003cem\u003ewhy\u003c/em\u003e platforms get bloated in the first place and how platform teams should think when building from scratch. Their conversation spans cloud provider preferences, the primacy of cycle time, the danger of adding process in response to failure, and a strong argument for treating security and quality as enablers rather than gatekeepers.\u003c/p\u003e\n\u003ch2 id=\"key-topics\"\u003eKey Topics\u003c/h2\u003e\n\u003ch3 id=\"platform-teams-should-serve-delivery-teams\"\u003ePlatform Teams Should Serve Delivery Teams\u003c/h3\u003e\n\u003cp\u003eJoachim frames the core question of platform engineering around who the platform is actually for. His answer is clear: the delivery teams are the client. Platform engineers should focus on making it easier for developers to ship products, not on making their own work more convenient.\u003c/p\u003e\n\u003cp\u003eHe connects this directly to platform bloat. In his experience, many platforms grow uncontrollably because platform engineers keep adding tools that help the platform team itself: \u0026ldquo;Look, I spent this week to make my job this much faster.\u0026rdquo; But Joachim pushes back on this instinct — the platform team is an amplifier for the organization, and every addition should be evaluated by whether it helps a product get to production faster and gives developers better visibility into what they are working on.\u003c/p\u003e\n\u003ch3 id=\"choosing-a-cloud-provider-preferences-vs-reality\"\u003eChoosing a Cloud Provider: Preferences vs. Reality\u003c/h3\u003e\n\u003cp\u003eThe conversation briefly explores cloud provider choices. Joachim says GCP is his personal favorite from a developer perspective because of cleaner APIs and faster response times, though he acknowledges Google\u0026rsquo;s tendency to discontinue services unexpectedly. He describes AWS as the market workhorse — mature, solid, and widely adopted, comparing it to \u0026ldquo;the Java of the land.\u0026rdquo; Azure gets the coldest reception; both acknowledge it has improved over time, but Joachim says he still struggles whenever he is forced to use it.\u003c/p\u003e\n\u003cp\u003eThey observe that cloud choices are frequently made outside engineering. Finance teams, investors, and existing enterprise agreements often drive the decision more than technical fit. Joachim notes a common pairing: organizations using Google Workspace for productivity but AWS for cloud infrastructure, partly because the Entra ID (formerly Azure AD) integration with AWS Identity Center works more smoothly via SCIM than the equivalent Google Workspace setup, which requires a Lambda function to sync groups.\u003c/p\u003e\n\u003ch3 id=\"measuring-platform-success-cycle-time-above-all\"\u003eMeasuring Platform Success: Cycle Time Above All\u003c/h3\u003e\n\u003cp\u003eWhen Mattias asks how a team can tell whether a platform is actually successful, Joachim separates subjective and objective measures.\u003c/p\u003e\n\u003cp\u003eOn the subjective side, he points to developer happiness and developer experience (DX). Feedback from delivery teams matters, even if surveys are imperfect.\u003c/p\u003e\n\u003cp\u003eOn the objective side, his favorite metric is cycle time — specifically, the time from when code is ready to when it reaches production. He also mentions uptime and availability, but keeps returning to cycle time as the clearest indicator that a platform is helping teams deliver faster. This aligns with DORA research, which has consistently shown that deployment frequency and lead time for changes are strong predictors of overall software delivery performance.\u003c/p\u003e\n\u003ch3 id=\"start-with-a-highway-to-production\"\u003eStart With a Highway to Production\u003c/h3\u003e\n\u003cp\u003eA major theme of the episode is that platforms should begin with the shortest possible route to production. Mattias calls this a \u0026ldquo;highway to production,\u0026rdquo; and Joachim strongly agrees.\u003c/p\u003e\n\u003cp\u003eFor greenfield projects, Joachim favors extremely fast delivery at first — commit goes to production, commit goes to production — even with minimal process. As usage and risk increase, teams can gradually add automation, testing, and safeguards. The critical thing is to keep the flow and then ask \u0026ldquo;how do we make those steps faster?\u0026rdquo; as you add them, rather than letting each new step slow down the pipeline unchallenged.\u003c/p\u003e\n\u003cp\u003eHe also makes a strong case for tags and promotions over branch-based deployment, noting his instinctive reaction when someone asks \u0026ldquo;which branch are we deploying from?\u0026rdquo; is: \u0026ldquo;No branches — tags and promotions.\u0026rdquo;\u003c/p\u003e\n\u003ch3 id=\"the-trap-of-slowing-down-after-failure\"\u003eThe Trap of Slowing Down After Failure\u003c/h3\u003e\n\u003cp\u003eJoachim warns about a common and dangerous pattern: when a bug reaches production, the natural organizational reaction is not to fix the pipeline, but to add gates. A QA team does a full pass, a security audit is inserted, a manual review step appears. Each gate slows delivery, which leads to larger batches, which increases risk, which triggers even more controls.\u003c/p\u003e\n\u003cp\u003eHe sees this as a vicious cycle. Organizations that respond to incidents by slowing delivery actually get worse security, worse quality, and worse throughput over time. He references a study — likely the research behind the book \u003cem\u003eAccelerate\u003c/em\u003e by Nicole Forsgren, Jez Humble, and Gene Kim — showing that faster delivery correlates with better security and quality outcomes. The organizations adding Engineering Review Boards (ERBs) and Architecture Review Boards (ARBs) in the name of safety often do not measure the actual impact, so they never see that the controls are making things worse.\u003c/p\u003e\n\u003cp\u003eMattias connects this to AI-assisted development, where developers can now produce changes faster than ever. If the pipeline cannot keep up, the pile of unreleased changes grows, making each release riskier.\u003c/p\u003e\n\u003ch3 id=\"getting-buy-in-start-with-small-experiments\"\u003eGetting Buy-In: Start With Small Experiments\u003c/h3\u003e\n\u003cp\u003eJoachim does not recommend that a slow, process-heavy organization throw everything out overnight. Instead, he suggests starting with small experiments. Code promotions are a good entry point: teams can start producing artifacts more rapidly without changing how those artifacts are deployed. Once that works, the conversation shifts to delivering those artifacts faster.\u003c/p\u003e\n\u003cp\u003eHe finds starting on the artifact pipeline side produces quicker wins and more organizational buy-in than starting with the platform deployment side, which tends to be more intertwined and higher-risk to change.\u003c/p\u003e\n\u003ch3 id=\"guiding-principles-over-a-rigid-golden-path\"\u003eGuiding Principles Over a Rigid Golden Path\u003c/h3\u003e\n\u003cp\u003eMattias questions the idea of a single \u0026ldquo;golden path,\u0026rdquo; saying the term implies one rigid way of working. Joachim leans toward guiding principles instead.\u003c/p\u003e\n\u003cp\u003eHis strongest principle is simplicity — specifically, simplicity to \u003cem\u003eunderstand\u003c/em\u003e, not necessarily simplicity to \u003cem\u003ecreate\u003c/em\u003e. He references Rich Hickey\u0026rsquo;s influential talk \u003cem\u003eSimple Made Easy\u003c/em\u003e (from Strange Loop 2011), which distinguishes between things that are simple (not intertwined) and things that are easy (familiar or close at hand). Creating simple systems is hard work, but the payoff is systems that are easy to reason about, easy to change, and easy to secure.\u003c/p\u003e\n\u003cp\u003eHis second guiding principle is replaceability. When evaluating any tool in the platform, he asks: \u0026ldquo;How hard would it be to yank this out and replace it?\u0026rdquo; If swapping a component would be extremely difficult, that is a smell — it means the system has become too intertwined. Even with a tool as established as Argo CD, his team thinks about what it would look like to switch it out.\u003c/p\u003e\n\u003ch3 id=\"tooling-choices-and-platform-foundations\"\u003eTooling Choices and Platform Foundations\u003c/h3\u003e\n\u003cp\u003eJoachim outlines the patterns his team typically uses when building platforms, organized into two paths:\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eDelivery pipeline (artifact creation):\u003c/strong\u003e\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eTrunk-based development over GitFlow\u003c/li\u003e\n\u003cli\u003eRelease tags and promotions rather than branch-based deployment\u003c/li\u003e\n\u003cli\u003eContainerization early in the pipeline\u003c/li\u003e\n\u003cli\u003eRelease Please for automated release management and changelogs\u003c/li\u003e\n\u003cli\u003eRenovate for dependency updates (used for production environment promotions from Helm charts and container images)\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e\u003cstrong\u003ePlatform side (environment management):\u003c/strong\u003e\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eKubernetes-heavy, typically EKS on AWS\u003c/li\u003e\n\u003cli\u003eKarpenter for node scaling\u003c/li\u003e\n\u003cli\u003eAWS Load Balancer Controller only as a backing service for a separate ingress controller (not using ALB Ingress directly, due to its rough edges)\u003c/li\u003e\n\u003cli\u003eArgo CD for GitOps synchronization and deployment\u003c/li\u003e\n\u003cli\u003eArgo Image Updater for lower environments to pull latest images automatically\u003c/li\u003e\n\u003cli\u003eHelm for packaging, despite its learning curve\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eHe notes that NGINX Ingress Controller has been deprecated, so teams need to evaluate alternatives for their ingress layer.\u003c/p\u003e\n\u003ch3 id=\"developers-should-not-be-fully-shielded-from-operations\"\u003eDevelopers Should Not Be Fully Shielded From Operations\u003c/h3\u003e\n\u003cp\u003eOne of the more nuanced parts of the conversation is how much operational responsibility developers should have. Joachim rejects both extremes. He does not think every developer needs to know everything about infrastructure, but he has seen too many cases where developers completely isolated from runtime concerns make poor decisions — missing simple code changes that would make a system dramatically easier to deploy and operate.\u003c/p\u003e\n\u003cp\u003eHe advocates for transparency and collaboration. Platform repos should be open for anyone on the dev team to submit pull requests. When the platform team makes a change, they should pull in developers to work alongside them. This way, the delivery team gradually builds a deeper understanding of how the whole system works.\u003c/p\u003e\n\u003cp\u003eJoachim loves the open-source maintainer model applied inside organizations: platform teams are maintainers of their areas, but anyone in the organization should be able to introduce change. He warns against building custom CLIs or heavy abstractions that create dependencies — if a developer wants to do something the CLI does not support, the platform team becomes a bottleneck.\u003c/p\u003e\n\u003cp\u003eMattias adds that opening up the platform to contributions also exposes assumptions. What feels easy to the person who built it may not be easy at all; it is just familiar. Outside contributors reveal where the system is actually hard to understand.\u003c/p\u003e\n\u003ch3 id=\"designers-not-artists-detaching-ego-from-code\"\u003eDesigners, Not Artists: Detaching Ego From Code\u003c/h3\u003e\n\u003cp\u003eJoachim shares an analogy he prefers over the common \u0026ldquo;developers as artists\u0026rdquo; framing. He sees developers more like designers than artists, because an artist\u0026rsquo;s work is tied to their identity — they want it to endure. A designer, by contrast, creates something to serve a purpose and expects it to be replaced when something better comes along.\u003c/p\u003e\n\u003cp\u003eHe applies this to platforms and infrastructure: \u0026ldquo;I want my thing to get wiped out. If I build something, I want it to get removed eventually and have something better replace it.\u0026rdquo; Organizations where ego is tied to specific systems or tools tend to resist change, which leads to the kind of dysfunction that keeps platforms bloated and brittle.\u003c/p\u003e\n\u003ch3 id=\"complexity-is-the-enemy-of-security\"\u003eComplexity Is the Enemy of Security\u003c/h3\u003e\n\u003cp\u003eMattias raises the difficulty of maintaining complex security setups over time, especially when the original experts leave. Joachim responds firmly: complexity is anti-security.\u003c/p\u003e\n\u003cp\u003eIf people cannot comprehend a system, they cannot secure it well. He acknowledges that some problems are genuinely hard, but argues that much of the complexity engineers create is unnecessary — driven by ego rather than need. \u0026ldquo;The really smart people are the ones that create simple things,\u0026rdquo; he says, wishing the industry would redirect its narrative from admiring complicated systems to admiring simple ones.\u003c/p\u003e\n\u003ch3 id=\"security-and-qa-as-internal-consulting-not-gatekeeping\"\u003eSecurity and QA as Internal Consulting, Not Gatekeeping\u003c/h3\u003e\n\u003cp\u003eJoachim draws a parallel between security and QA. He dislikes calling a team \u0026ldquo;the quality team,\u0026rdquo; preferring \u0026ldquo;verification\u0026rdquo; — they are one component of quality, not the entirety of it. Similarly, security is not one team\u0026rsquo;s responsibility; it spans product design, development practices, tooling, and operations.\u003c/p\u003e\n\u003cp\u003eHis ideal model is for security and QA teams to operate as internal consultants whose goal is to reduce risk and improve the overall system — not to catch every possible issue at any cost. The framing matters: if a security team\u0026rsquo;s mandate is simply \u0026ldquo;block all security issues,\u0026rdquo; the logical conclusion is to stop shipping or delete the product entirely. That may be technically secure, but it is useless.\u003c/p\u003e\n\u003cp\u003eHe frames security as risk management: \u0026ldquo;Security is a risk management process, not just security for the sake of security. You\u0026rsquo;re managing the risk to the business.\u0026rdquo; The goal should be to deliver faster \u003cem\u003eand\u003c/em\u003e more securely — an \u0026ldquo;and,\u0026rdquo; not an \u0026ldquo;or.\u0026rdquo;\u003c/p\u003e\n\u003cp\u003eMattias recalls a PCI DSS consultant joking over drinks that a system being down is perfectly compliant — no one can steal card numbers if the system is unavailable. The joke lands because it exposes exactly the broken incentive Joachim describes.\u003c/p\u003e\n\u003ch3 id=\"business-value-as-the-unifying-frame\"\u003eBusiness Value as the Unifying Frame\u003c/h3\u003e\n\u003cp\u003eThe episode closes by tying everything back to business outcomes. Joachim argues that speed and security are not opposites; both contribute to business value. Fast delivery creates value directly, while security reduces business risk — and risk management is itself a business operation.\u003c/p\u003e\n\u003cp\u003eHe explains why focusing on the highest-impact business bottleneck first builds trust. When you hit the big items first, you earn credibility, and subsequent changes become easier to justify. For example, one of his clients has a security group that is the slowest part of their organization. Speeding up that security process would have a massive impact on business delivery — more than optimizing the artifact pipeline.\u003c/p\u003e\n\u003cp\u003eMattias reflects that he used to see platform work as separate from business concerns — \u0026ldquo;I don\u0026rsquo;t care about the business, I\u0026rsquo;m here to build a platform for developers.\u0026rdquo; Looking back, he would reframe that: using business impact as the measure of platform success does not mean abandoning the focus on developers, it means having a clearer way to prioritize and demonstrate value.\u003c/p\u003e\n\u003ch2 id=\"highlights\"\u003eHighlights\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eJoachim on platform bloat:\u003c/strong\u003e \u0026ldquo;Your job is not to make your job faster and easier — you\u0026rsquo;re an amplifier to the organization.\u0026rdquo;\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eJoachim on his favorite metric:\u003c/strong\u003e \u0026ldquo;Cycle time is my favorite metric. I love cycle time metrics.\u0026rdquo;\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eJoachim on deployment strategy:\u003c/strong\u003e \u0026ldquo;No branches, no branches — tags and promotions.\u0026rdquo;\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eMattias on platform design:\u003c/strong\u003e He calls the ideal early setup a \u0026ldquo;highway to production.\u0026rdquo;\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eJoachim on simplicity vs. ease:\u003c/strong\u003e He references Rich Hickey\u0026rsquo;s \u003cem\u003eSimple Made Easy\u003c/em\u003e talk — \u0026ldquo;It\u0026rsquo;s very hard to create simple systems that are easy to reason about. And it\u0026rsquo;s very easy to create systems that are very hard to reason about.\u0026rdquo;\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eJoachim on replaceability:\u003c/strong\u003e \u0026ldquo;If swapping a tool out would be extremely hard, that\u0026rsquo;s a pretty big smell.\u0026rdquo;\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eJoachim on complexity and security:\u003c/strong\u003e \u0026ldquo;If it\u0026rsquo;s complicated, you just can\u0026rsquo;t keep all the context together. Simple systems are much easier to be secure.\u0026rdquo;\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eJoachim on engineering ego:\u003c/strong\u003e \u0026ldquo;I don\u0026rsquo;t particularly like the aspect of [developers as] artists\u0026hellip; I want my thing to get wiped out. I want it to get removed eventually and have something better replace it.\u0026rdquo; He prefers the analogy of designers over artists, because artists tie their identity to their creations.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eJoachim on security as a blocker:\u003c/strong\u003e \u0026ldquo;If their goal is we are going to block every security issue, the best way to do that is delete your product.\u0026rdquo;\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eSpicy cloud takes:\u003c/strong\u003e Joachim calls GCP his favorite cloud for developers, compares AWS to \u0026ldquo;the Java of the land,\u0026rdquo; and says he still struggles every time he is forced to use Azure.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePCI DSS dark humor:\u003c/strong\u003e Mattias recalls a consultant joking that a downed system is perfectly compliant — you cannot steal card numbers from a system that is not running.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eJoachim on the slow-down trap:\u003c/strong\u003e Organizations add ERBs, ARBs, and manual security gates after incidents, but \u0026ldquo;the faster you can deliver, you actually get better security, better quality, and better throughput — and the more you slow it down, you go the opposite.\u0026rdquo;\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"resources\"\u003eResources\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://www.infoq.com/presentations/Simple-Made-Easy/\"\u003eSimple Made Easy by Rich Hickey (InfoQ)\u003c/a\u003e — The influential 2011 talk Joachim references on distinguishing simplicity from ease in system design.\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://dora.dev/guides/dora-metrics-four-keys/\"\u003eDORA Metrics: The Four Keys\u003c/a\u003e — The research framework behind cycle time, deployment frequency, and the finding that speed and stability are not tradeoffs.\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://trunkbaseddevelopment.com/\"\u003eTrunk Based Development\u003c/a\u003e — A comprehensive guide to the branching strategy Joachim recommends over GitFlow.\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://argo-cd.readthedocs.io/en/stable/\"\u003eArgo CD — Declarative GitOps for Kubernetes\u003c/a\u003e — The GitOps tool Joachim\u0026rsquo;s team uses for cluster synchronization and deployment.\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://github.com/googleapis/release-please\"\u003eRelease Please (GitHub)\u003c/a\u003e — Google\u0026rsquo;s tool for automated release management based on conventional commits, used by Joachim\u0026rsquo;s team for tag-based promotions.\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://karpenter.sh/\"\u003eKarpenter — Kubernetes Node Autoscaler\u003c/a\u003e — The node autoscaler Joachim\u0026rsquo;s team uses with EKS for fast, flexible scaling.\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://docs.renovatebot.com/\"\u003eRenovate — Automated Dependency Updates\u003c/a\u003e — The dependency management bot Joachim uses for both build dependencies and production environment promotions.\u003c/li\u003e\n\u003c/ul\u003e"},{"title":"#95 - From Platform Theater to Golden Guardrails with Steve Wade","date_published":"2026-03-23T23:08:52Z","date_modified":"2026-03-23T23:08:52Z","id":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/095-from-platform-theater-to-golden-guardrails/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/095-from-platform-theater-to-golden-guardrails/","authors":[{"name":"DevSecOps Talks"}],"content_html":"\u003cp\u003eIs your Kubernetes stack bloated, slow, and hard to explain? Steve Wade shares simple checks—the hiring treadmill, onboarding time, and the acronym test—to spot platform theater fast. What would a 30-day deletion sprint cut, save, and secure?\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/company/devsecops-talks/\"\u003eDiscuss the episode or ask us anything on LinkedIn\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"single_player_container\"\u003e\n   \u003ciframe\n     title=\"DEVSECOPS Talks #95 - From Platform Theater to Golden Guardrails with Steve Wade\"\n     height=\"122\"\n     width=\"100%\"\n     style=\"border: none;\"\n     scrolling=\"no\"\n     data-name=\"pb-iframe-player\"\n     src=\"https://www.podbean.com/media/player/d4uwv-1a7d5a7-pb?from=yiiadmin\u0026download=1\u0026version=1\u0026skin=1\u0026btn-skin=107\u0026auto=0\u0026download=1\u0026pbad=1\"\n   \u003e\u003c/iframe\u003e\n \u003c/div\u003e\n\n\u003chr\u003e\n\u003cdiv style=\"position: relative; padding-bottom: 56.25%; height: 0; overflow: hidden;\"\u003e\n      \u003ciframe allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share; fullscreen\" loading=\"eager\" referrerpolicy=\"strict-origin-when-cross-origin\" src=\"https://www.youtube.com/embed/4stB_XSc9ok?autoplay=0\u0026amp;controls=1\u0026amp;end=0\u0026amp;loop=0\u0026amp;mute=0\u0026amp;start=0\" style=\"position: absolute; top: 0; left: 0; width: 100%; height: 100%; border:0;\" title=\"YouTube video\"\u003e\u003c/iframe\u003e\n    \u003c/div\u003e\n\n\u003ch2 id=\"summary\"\u003eSummary\u003c/h2\u003e\n\u003cp\u003eIn this episode of DevSecOps Talks, Mattias and Paulina speak with Steve Wade, founder of Platform Fix, about why so many Kubernetes and platform initiatives become overcomplicated, expensive, and painful for developers. Steve has helped simplify over 50 cloud-native platforms and estimates he has removed around $100 million in complexity waste. The conversation covers how to spot a bloated platform, why \u0026ldquo;free\u0026rdquo; tools are never really free, how to systematically delete what you don\u0026rsquo;t need, and why the best platform engineering is often about subtraction rather than addition.\u003c/p\u003e\n\u003ch2 id=\"key-topics\"\u003eKey Topics\u003c/h2\u003e\n\u003ch3 id=\"steves-background-from-complexity-creator-to-strategic-deleter\"\u003eSteve\u0026rsquo;s Background: From Complexity Creator to Strategic Deleter\u003c/h3\u003e\n\u003cp\u003eSteve introduces himself as the founder of Platform Fix — the person companies call when their Kubernetes migration is 18 months in, millions over budget, and their best engineers are leaving. He has done this over 50 times, and he is candid about why it matters so much to him: he used to be this problem.\u003c/p\u003e\n\u003cp\u003eYears ago, Steve led a migration that was supposed to take six months. Eighteen months later, the team had 70 microservices, three service meshes (they kept starting new ones without finishing the old), and monitoring tools that needed their own monitoring. Two senior engineers quit. The VP of Engineering gave Steve 90 days or the team would be replaced.\u003c/p\u003e\n\u003cp\u003eThose 90 days changed everything. The team deleted roughly 50 of the 70 services, ripped out all the service meshes, and cut deployment time from three weeks of chaos to three days, consistently. Six months later, one of the engineers who had left came back. That experience became the foundation for Platform Fix.\u003c/p\u003e\n\u003cp\u003eAs Steve puts it: \u0026ldquo;While everyone\u0026rsquo;s collecting cloud native tools like Pokemon cards, I\u0026rsquo;m trying to help teams figure out which ones to throw away and which ones to keep.\u0026rdquo;\u003c/p\u003e\n\u003ch3 id=\"why-platform-complexity-happens\"\u003eWhy Platform Complexity Happens\u003c/h3\u003e\n\u003cp\u003eSteve explains that organizations fall into a complexity trap by continuously adding tools without questioning whether they are actually needed. He describes walking into companies where the platform team spends 65–70% of their time explaining their own platform to the people using it. His verdict: \u0026ldquo;That\u0026rsquo;s not a team, that\u0026rsquo;s a help desk with infrastructure access.\u0026rdquo;\u003c/p\u003e\n\u003cp\u003ePeople inside the complexity normalize it. They cannot see the problem because they have been living in it for months or years. Steve identifies several drivers: conference-fueled recency bias (someone sees a shiny tool at KubeCon and adopts it without evaluating the need), resume-driven architecture (engineers choosing tools to pad their CVs), and a culture where everyone is trained to add but nobody asks \u0026ldquo;what if we remove something instead?\u0026rdquo;\u003c/p\u003e\n\u003cp\u003eHe illustrates the resume-driven pattern with a story from a 200-person fintech. A senior hire — \u0026ldquo;Mark\u0026rdquo; — proposed a full stack: Kubernetes, Istio, Argo, Crossplane, Backstage, Vault, Prometheus, Loki, Tempo, and more. The CTO approved it because \u0026ldquo;Spotify uses it, so it must be best practice.\u0026rdquo; Eighteen months and $2.3 million later, six engineers were needed just to keep it running, developers waited weeks to deploy, and Mark left — with \u0026ldquo;led Kubernetes migration\u0026rdquo; on his CV. When Steve asked what Istio was actually solving, nobody could answer. It was costing around $250,000 to run, for a problem that could have been fixed with network policies.\u003c/p\u003e\n\u003cp\u003eHe also highlights a telling sign: he asked three people in the same company how many Kubernetes clusters they needed and got three completely different answers. \u0026ldquo;That\u0026rsquo;s not a technical disagreement. That\u0026rsquo;s a sign that nobody\u0026rsquo;s aligned on what the platform is actually for.\u0026rdquo;\u003c/p\u003e\n\u003ch3 id=\"the-ai-layer-tool-fatigue-gets-worse\"\u003eThe AI Layer: Tool Fatigue Gets Worse\u003c/h3\u003e\n\u003cp\u003ePaulina observes that the same tool-sprawl pattern is now being repeated with AI tooling — an additional layer of fatigue on top of what already exists in the cloud-native space. Steve agrees and adds three dimensions to the AI complexity problem: choosing which LLM to use, learning how to write effective prompts, and figuring out who is accountable when AI-written code does not work as expected. Mattias notes that AI also enables anyone to build custom tools for their specific needs, which further expands the toolbox and potential for sprawl.\u003c/p\u003e\n\u003ch3 id=\"how-leaders-can-spot-a-bloated-platform\"\u003eHow Leaders Can Spot a Bloated Platform\u003c/h3\u003e\n\u003cp\u003eOne of the most practical segments is Steve\u0026rsquo;s framework for helping leaders who are not hands-on with engineering identify platform bloat. He gives them three things to watch for:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eThe hiring treadmill:\u003c/strong\u003e headcount keeps growing but shipping speed stays flat, because all new capacity is absorbed by maintenance.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eThe onboarding test:\u003c/strong\u003e ask the newest developer how long it took from their first day to their first production deployment. If it is more than a week, \u0026ldquo;it\u0026rsquo;s a swamp.\u0026rdquo; Steve\u0026rsquo;s benchmark: can a developer who has been there two weeks deploy without asking anyone? If yes, you have a platform. If no, \u0026ldquo;you have platform theater.\u0026rdquo;\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eThe acronym test:\u003c/strong\u003e ask the platform team to explain any tool of their choosing without using a single acronym. If they cannot, it is likely resume-driven architecture rather than genuine problem-solving.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3 id=\"the-sagrada-familia-problem\"\u003eThe Sagrada Familia Problem\u003c/h3\u003e\n\u003cp\u003eSteve uses a memorable analogy: many platforms are like the Sagrada Familia in Barcelona — they look incredibly impressive and intricate, but they are never actually finished. The question leaders should ask is: what does an MVP platform look like, what tools does it need, and how do we start delivering business value to the developers who use it? Because, as Steve says, \u0026ldquo;if we\u0026rsquo;re not building any business value, we\u0026rsquo;re just messing around.\u0026rdquo;\u003c/p\u003e\n\u003ch3 id=\"who-the-platform-is-really-for\"\u003eWho the Platform Is Really For\u003c/h3\u003e\n\u003cp\u003eMattias asks the fundamental question: who is the platform actually for? Steve\u0026rsquo;s answer is direct — the platform\u0026rsquo;s customers are the developers deploying workloads to it. A platform without applications running on it is useless.\u003c/p\u003e\n\u003cp\u003eHe distinguishes three stages:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eVanilla Kubernetes:\u003c/strong\u003e the out-of-the-box cluster\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePlatform Kubernetes:\u003c/strong\u003e the foundational workloads the platform needs to function (secret management, observability, perhaps a service mesh)\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eThe actual platform:\u003c/strong\u003e only real once applications are being deployed and business value is delivered\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eThe hosts discuss how some teams build platforms for themselves rather than for application developers or the business, which is a fast track to unnecessary complexity.\u003c/p\u003e\n\u003ch3 id=\"kubernetes-standard-tool-or-premature-choice\"\u003eKubernetes: Standard Tool or Premature Choice?\u003c/h3\u003e\n\u003cp\u003eThe episode explores when Kubernetes is the right answer and when it is overkill. Steve emphasizes that he loves Kubernetes — he has contributed to the Flux project and other CNCF projects — but only when it is earned. He gives an example of a startup with three microservices, ten users, and five engineers that chose Kubernetes because \u0026ldquo;Google uses it\u0026rdquo; and the CTO went to KubeCon. Six months later, they had infrastructure that could handle ten million users while serving about 97.\u003c/p\u003e\n\u003cp\u003e\u0026ldquo;Google needs Kubernetes, but your Series B startup needs to ship features.\u0026rdquo;\u003c/p\u003e\n\u003cp\u003eSteve also shares a recent on-site engagement where he ran the unit economics on day two: the proposed architecture needed four times the CPU and double the RAM for identical features. One spreadsheet saved the company from a migration that would have destroyed the business model. \u0026ldquo;That\u0026rsquo;s the question nobody asks before a Kubernetes migration — does the maths actually work?\u0026rdquo;\u003c/p\u003e\n\u003cp\u003eMattias pushes back slightly, noting that a small Kubernetes cluster can still provide real benefits if the team already has the knowledge and tooling. Paulina adds an important caveat: even if a consultant can deploy and maintain Kubernetes, the question is whether the customer\u0026rsquo;s own team can realistically support it afterward. The entry skill set for Kubernetes is significantly higher than, say, managed Docker or ECS.\u003c/p\u003e\n\u003ch3 id=\"managed-services-and-boring-is-beautiful\"\u003eManaged Services and \u0026ldquo;Boring Is Beautiful\u0026rdquo;\u003c/h3\u003e\n\u003cp\u003eSteve\u0026rsquo;s recommendation for many teams is straightforward: managed platforms, managed databases, CI/CD that just works, deploy on push, and go home at 5 p.m. \u0026ldquo;Boring is beautiful, especially when you call me at 3 a.m.\u0026rdquo;\u003c/p\u003e\n\u003cp\u003eHe illustrates this with a company that spent 18 months and roughly $850,000 in engineering time building a custom deployment system using well-known CNCF tools. The result was about 80–90% as good as GitHub Actions. The migration to GitHub Actions cost around $30,000, and the ongoing maintenance cost was zero.\u003c/p\u003e\n\u003cp\u003ePaulina adds that managed services are not completely zero maintenance either, but the operational burden is orders of magnitude less than self-managed infrastructure, and the cloud provider takes on a share of the responsibility.\u003c/p\u003e\n\u003ch3 id=\"the-new-tool-tax-why-free-tools-are-never-free\"\u003eThe New Tool Tax: Why \u0026ldquo;Free\u0026rdquo; Tools Are Never Free\u003c/h3\u003e\n\u003cp\u003eA central theme is that open-source tools carry hidden costs far exceeding their license fee. Steve introduces the \u003cstrong\u003enew tool tax\u003c/strong\u003e framework with four components, using Vault (at a $40,000 license) as an example:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eLearning tax (~$45,000):\u003c/strong\u003e three engineers, two weeks each for training, documentation, and mistakes\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eIntegration tax (~$20,000):\u003c/strong\u003e CI/CD pipelines, Kubernetes operators, secret migration, monitoring of Vault itself\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eOperational tax (~$50,000/year):\u003c/strong\u003e on-call, upgrades, tickets, patching\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eOpportunity tax (~$80,000):\u003c/strong\u003e while engineers work on Vault, they are not building things that could save hundreds of hours per month\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eTotal year-one cost: roughly $243,000 — a 6x multiplier over the $40,000 budget. And as Steve points out, most teams never present this full picture to leadership.\u003c/p\u003e\n\u003cp\u003eMattias extends the point to tool documentation complexity, noting that anyone who has worked with Envoy\u0026rsquo;s configuration knows how complicated it can be. Steve adds that Envoy is written in C — \u0026ldquo;How many C developers do you have in your organization? Probably zero.\u0026rdquo; — yet teams adopt it because it offers 15 to 20 features that may or may not be useful.\u003c/p\u003e\n\u003cp\u003eThis is the same total cost of ownership concept the industry has used for on-premises hardware, but applied to the seemingly \u0026ldquo;free\u0026rdquo; cloud-native landscape. The tools are free to install, but they are not free to manage and maintain.\u003c/p\u003e\n\u003ch3 id=\"why-service-meshes-are-often-the-first-to-go\"\u003eWhy Service Meshes Are Often the First to Go\u003c/h3\u003e\n\u003cp\u003eWhen Mattias asks which tool type Steve most often deletes, the answer is service meshes. Steve does not name a specific product but says six or seven times out of ten, service meshes exist because someone thought they were cool, not because the team genuinely needed mutual TLS, rate limiting, or canary deploys at the mesh level.\u003c/p\u003e\n\u003cp\u003eMattias agrees: in his experience, he has never seen an environment that truly required a service mesh. The demos at KubeCon are always compelling, but the implementation reality is different. Steve adds a self-deprecating note — this was him in the past, running three service meshes simultaneously because none of them worked perfectly and he kept starting new ones in test mode.\u003c/p\u003e\n\u003ch3 id=\"a-framework-for-deleting-tools\"\u003eA Framework for Deleting Tools\u003c/h3\u003e\n\u003cp\u003eSteve outlines three frameworks he uses to systematically simplify platforms.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eThe Simplicity Test\u003c/strong\u003e is a diagnostic that scores platform complexity across ten dimensions on a scale of 0 to 50: tool sprawl, deployment complexity, cognitive load, operational burden, documentation debt, knowledge silos, incident frequency, time to production, self-service capability, and team satisfaction. A score of 0–15 is sustainable, 16–25 is manageable, 26–35 is a warning, and 36–50 is crisis. Over 400 engineers have taken it; the average score is around 34. Companies that call Steve typically score 38 to 45.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eThe Four Buckets\u003c/strong\u003e categorize every tool: Essential (keep it), Redundant (duplicates something else — delete immediately), Over-engineered (solves a real problem but is too complicated — simplify it), or Premature (future-scale you don\u0026rsquo;t have yet — delete for now).\u003c/p\u003e\n\u003cp\u003eFrom one engagement with 47 tools: 12 were essential, 19 redundant, 11 over-engineered, and 5 premature — meaning 35 were deletable.\u003c/p\u003e\n\u003cp\u003eHe then prioritizes by \u003cstrong\u003eimpact versus risk\u003c/strong\u003e, tackling high-impact, low-risk items first. For example, a large customer had Datadog, Prometheus, and New Relic running simultaneously with no clear rationale. Deleting New Relic took three hours, saved $30,000, and nobody noticed. Seventeen abandoned databases with zero connections in 30 days were deprecated by email, then deleted — zero responses, zero impact.\u003c/p\u003e\n\u003cp\u003eThe security angle matters here too: one of those abandoned databases was an unpatched attack surface sitting in production with no one monitoring it. Paulina adds a related example — her team once found a Flyway instance that had gone unpatched for seven or eight years because each team assumed the other was maintaining it. As she puts it, lack of ownership creates the same kind of hidden risk.\u003c/p\u003e\n\u003ch3 id=\"the-30-day-cleanup-sprint\"\u003eThe 30-Day Cleanup Sprint\u003c/h3\u003e\n\u003cp\u003eSteve structures platform simplification as a focused 30-day effort:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eWeek 1: Audit.\u003c/strong\u003e Discover what is actually running — not what the team thinks is running, because those are usually different.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eWeek 2: Categorize.\u003c/strong\u003e Apply the four buckets and prioritize quick wins. During this phase, Steve tells the team: \u0026ldquo;For 30 days, you\u0026rsquo;re not building anything — you\u0026rsquo;re only deleting things.\u0026rdquo;\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eWeek 3: Delete.\u003c/strong\u003e Remove redundant tools and simplify over-engineered ones.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eWeek 4: Systemize.\u003c/strong\u003e Document everything — how decisions were made, why tools were removed, and how new tool decisions should be evaluated going forward. Build governance dashboards to prevent complexity from creeping back.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eHe illustrates this with a company whose VP of Engineering — \u0026ldquo;Sarah\u0026rdquo; — told him: \u0026ldquo;This isn\u0026rsquo;t a technical problem anymore. This is a people problem.\u0026rdquo; Two senior engineers had quit on the same day with the same exit interview: \u0026ldquo;I\u0026rsquo;m tired of fighting the platform.\u0026rdquo; One said he had not had dinner with his kids on a weekend in six months. The team\u0026rsquo;s morale score was 3.2 out of 10.\u003c/p\u003e\n\u003cp\u003eThe critical insight: the team already knew what was wrong. They had known for months. But nobody had been given permission to delete anything. \u0026ldquo;That\u0026rsquo;s not a cultural problem and it\u0026rsquo;s not a knowledge problem. It\u0026rsquo;s a permissions problem. And I gave them the permission.\u0026rdquo;\u003c/p\u003e\n\u003cp\u003eResults: complexity score dropped from 42 to 26, monthly costs fell from $150,000 to $80,000 (roughly $840,000 in annual savings), and deployment time improved from two weeks to one day.\u003c/p\u003e\n\u003cp\u003eBut Steve emphasizes the human outcome. A developer told him afterward: \u0026ldquo;Steve, I went home at 5 p.m. yesterday. It\u0026rsquo;s the first time in eight months. And my daughter said, \u0026lsquo;Daddy, you\u0026rsquo;re home.\u0026rsquo;\u0026rdquo; That, Steve says, is what this work is really about.\u003c/p\u003e\n\u003ch3 id=\"golden-paths-guardrails-and-developer-experience\"\u003eGolden Paths, Guardrails, and Developer Experience\u003c/h3\u003e\n\u003cp\u003eMattias says he wants the platform he builds to compete with the easiest external options — Vercel, Netlify, and the like. If developers would rather go elsewhere, the internal platform has failed.\u003c/p\u003e\n\u003cp\u003eSteve agrees and describes a pattern he sees constantly: developers do not complain when the platform is painful — they route around it. He gives an example from a fintech where a lead developer (\u0026ldquo;James\u0026rdquo;) needed a test environment for a Friday customer demo. The official process required a JIRA ticket, a two-day wait, YAML files, and a pipeline. Instead, James spun up a Render instance on his personal credit card: 12 minutes, deployed, did the demo, got the deal. Nobody knew for three months, until finance found the charges.\u003c/p\u003e\n\u003cp\u003eSteve\u0026rsquo;s view: that is not shadow IT or irresponsibility — it is a rational response to poor platform usability. \u0026ldquo;The fastest path to business value went around the platform, not through it.\u0026rdquo;\u003c/p\u003e\n\u003cp\u003eThe solution is what Steve calls the \u003cstrong\u003egolden path\u003c/strong\u003e — or, as he reframes it using a bowling alley analogy, \u003cstrong\u003egolden guardrails\u003c/strong\u003e. Like the bumpers that keep the ball heading toward the pins regardless of how it is thrown, the guardrails keep developers on a safe path without dictating exactly how they get there. The goal is hitting the pins — delivering business value.\u003c/p\u003e\n\u003cp\u003eMattias extends the guardrails concept to security: the easiest path should also be the most secure and compliant one. If security is harder than the workaround, the workaround wins every time. He aims to make the platform so seamless that developers do not have to think separately about security — it is built into the default experience.\u003c/p\u003e\n\u003ch3 id=\"measuring-outcomes-not-features\"\u003eMeasuring Outcomes, Not Features\u003c/h3\u003e\n\u003cp\u003eSteve argues that platform teams should measure developer outcomes, not platform features: time to first deploy, time to fix a broken deployment, overall developer satisfaction, and how secure and compliant the default deployment paths are.\u003c/p\u003e\n\u003cp\u003eHe recommends monthly platform retrospectives where developers can openly share feedback. In these sessions, Steve goes around the room and insists that each person share their own experience rather than echoing the previous speaker. This builds a backlog of improvements directly tied to real developer pain.\u003c/p\u003e\n\u003cp\u003ePaulina agrees that feedback is essential but notes a practical challenge: in many organizations, only a handful of more active developers provide feedback, while the majority say they do not have time and just want to write code. Collecting representative feedback requires deliberate effort.\u003c/p\u003e\n\u003cp\u003eShe also raises the business and management perspective. In her consulting experience, she has seen assessments include a third dimension beyond the platform team and developers: business leadership, who focus on compliance, security, and cost. Sometimes the platform enables fast development, but management processes still block frequent deployment to production — a mindset gap, not a technical one. Steve agrees and points to value stream mapping as a technique for surfacing these bottlenecks with data.\u003c/p\u003e\n\u003ch3 id=\"translating-engineering-work-into-business-value\"\u003eTranslating Engineering Work Into Business Value\u003c/h3\u003e\n\u003cp\u003eSteve makes a forceful case that engineering leaders must express technical work in business terms. \u0026ldquo;The uncomfortable truth is that engineering is a cost center. We exist to support profit centers. The moment we forget that, we optimize for architectural elegance instead of business outcomes — and we lose the room.\u0026rdquo;\u003c/p\u003e\n\u003cp\u003eHe illustrates this with a story: a CFO asked seven engineering leaders one question — \u0026ldquo;How long to rebuild production if we lost everything tomorrow?\u0026rdquo; Five seconds of silence. Ninety-four years of combined experience, and nobody could answer. \u0026ldquo;That\u0026rsquo;s where engineering careers die.\u0026rdquo;\u003c/p\u003e\n\u003cp\u003eThe translation matters at every level. Saying \u0026ldquo;we deleted a Jenkins server\u0026rdquo; means nothing to a CFO. Saying \u0026ldquo;we removed $40,000 in annual costs and cut deployment failures by 60%\u0026rdquo; gets attention.\u003c/p\u003e\n\u003cp\u003eSteve challenges listeners to take their last three technical achievements and rewrite each one with a currency figure, a percentage, and a timeframe. \u0026ldquo;If you can\u0026rsquo;t, you\u0026rsquo;re speaking engineering, not business.\u0026rdquo;\u003c/p\u003e\n\u003ch3 id=\"closing-advice-start-deleting-this-week\"\u003eClosing Advice: Start Deleting This Week\u003c/h3\u003e\n\u003cp\u003eSteve\u0026rsquo;s parting advice is concrete: pick one tool you suspect nobody is using, check the logs, and if nothing has happened in 30 days, deprecate it. In 60 days, delete it. He also offers the simplicity test for free — it takes eight minutes, produces a 0-to-50 score with specific recommendations, and is available by reaching out to him directly.\u003c/p\u003e\n\u003cp\u003e\u0026ldquo;Your platform\u0026rsquo;s biggest risk isn\u0026rsquo;t technical — it\u0026rsquo;s political. Platforms die when the CFO asks you a question you can\u0026rsquo;t answer, when your best engineer leaves, or when the team builds for their CV instead of the business.\u0026rdquo;\u003c/p\u003e\n\u003ch2 id=\"highlights\"\u003eHighlights\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eSteve Wade:\u003c/strong\u003e \u0026ldquo;While everyone\u0026rsquo;s collecting cloud native tools like Pokemon cards, I\u0026rsquo;m trying to help teams figure out which ones to throw away and which ones to keep.\u0026rdquo;\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eSteve Wade:\u003c/strong\u003e \u0026ldquo;That\u0026rsquo;s not a team, that\u0026rsquo;s a help desk with infrastructure access.\u0026rdquo; — on platform teams spending most of their time explaining their own platform\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eSteve Wade:\u003c/strong\u003e \u0026ldquo;If the answer is yes, it means you have a platform. And if it\u0026rsquo;s no, it means you have platform theater.\u0026rdquo;\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eSteve Wade:\u003c/strong\u003e \u0026ldquo;So many platforms are like the Sagrada Familia — they look super impressive, but they\u0026rsquo;re never finished yet.\u0026rdquo;\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eSteve Wade:\u003c/strong\u003e \u0026ldquo;Boring is beautiful, especially when you call me at 3 a.m.\u0026rdquo;\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eSteve Wade:\u003c/strong\u003e \u0026ldquo;Google needs Kubernetes, but your Series B startup needs to ship features.\u0026rdquo;\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eSteve Wade:\u003c/strong\u003e \u0026ldquo;One spreadsheet saved them from a migration that would have just simply destroyed the business model.\u0026rdquo;\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eSteve Wade:\u003c/strong\u003e \u0026ldquo;They knew what was wrong. They\u0026rsquo;d known for months. But nobody was given the permission to delete anything.\u0026rdquo;\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eSteve Wade:\u003c/strong\u003e \u0026ldquo;They\u0026rsquo;re not really free. They\u0026rsquo;re just free to install.\u0026rdquo; — on open-source CNCF tools\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eSteve Wade:\u003c/strong\u003e \u0026ldquo;Your platform\u0026rsquo;s power doesn\u0026rsquo;t come from what you add. It comes from what you have the courage to delete.\u0026rdquo;\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eMattias:\u003c/strong\u003e Argues that an internal platform should compete with the easiest external alternatives — if developers would rather use Vercel, the platform has failed. Also extends the guardrails concept to security: the easiest path should always be the most secure path.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePaulina:\u003c/strong\u003e Highlights the ownership gap — tools can go unpatched for years when each team assumes another team maintains them. Also raises the management dimension: sometimes it is not the platform that is slow, but organizational processes that block deployment.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"resources\"\u003eResources\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://www.pragmatic-cncf.com/\"\u003eThe Pragmatic CNCF Manifesto\u003c/a\u003e — Steve Wade\u0026rsquo;s guide to cloud-native sanity, with six principles, pragmatic stack recommendations, and anti-patterns to avoid, drawn from 50+ enterprise migrations.\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://newsletter.platformfix.com/\"\u003eThe Deletion Digest\u003c/a\u003e — Steve\u0026rsquo;s weekly newsletter for platform leaders, delivering one actionable lesson on deleting platform complexity every Saturday morning.\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://landscape.cncf.io/\"\u003eCNCF Cloud Native Landscape\u003c/a\u003e — the full interactive map of cloud-native tools that Steve references when talking about needing to zoom out on your browser just to see everything.\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://www.infoq.com/articles/service-mesh-unnecessary-complexity/\"\u003eHow Unnecessary Complexity Gave the Service Mesh a Bad Name (InfoQ)\u003c/a\u003e — a detailed analysis of why service meshes became the poster child for over-engineering in cloud-native environments.\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://platformengineering.org/blog/what-are-golden-paths-a-guide-to-streamlining-developer-workflows\"\u003eWhat Are Golden Paths? A Guide to Streamlining Developer Workflows\u003c/a\u003e — a practical guide to designing the \u0026ldquo;path of least resistance\u0026rdquo; that makes the right way the easy way.\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://dora.dev/guides/value-stream-management/\"\u003eValue Stream Mapping for Software Delivery (DORA)\u003c/a\u003e — the DORA team\u0026rsquo;s guide to the value stream mapping technique Steve mentions for surfacing bottlenecks between engineering and business.\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://octopus.com/blog/inside-platform-engineering-steve-wade\"\u003eInside Platform Engineering with Steve Wade (Octopus Deploy)\u003c/a\u003e — a longer conversation with Steve about platform engineering philosophy and practical approaches.\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://www.linkedin.com/in/stevendavidwade/\"\u003eSteve Wade on LinkedIn\u003c/a\u003e — where Steve regularly posts about platform simplification and can be reached directly.\u003c/li\u003e\n\u003c/ul\u003e"},{"title":"#94 - Small Tasks, Big Wins: The AI Dev Loop at System Initiative","date_published":"2026-03-11T23:16:24Z","date_modified":"2026-03-11T23:16:24Z","id":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/094-small-tasks-big-wins-the-ai-dev-loop-at-system-initiative/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/094-small-tasks-big-wins-the-ai-dev-loop-at-system-initiative/","authors":[{"name":"DevSecOps Talks"}],"content_html":"\u003cp\u003eWe bring Paul Stack back to cover the parts we skipped last time. What changed when the models got better and we moved from one-shot Gen AI to agentic, human-in-the-loop work? How do plan mode and tight prompts stop AI from going rogue? Want to hear how six branches, git worktrees, and a TypeScript CLI came together?\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/company/devsecops-talks/\"\u003eDiscuss the episode or ask us anything on LinkedIn\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"single_player_container\"\u003e\n   \u003ciframe\n     title=\"DEVSECOPS Talks #94 - Small Tasks, Big Wins: The AI Dev Loop at System Initiative\"\n     height=\"122\"\n     width=\"100%\"\n     style=\"border: none;\"\n     scrolling=\"no\"\n     data-name=\"pb-iframe-player\"\n     src=\"https://www.podbean.com/media/player/xnuqq-1a6b211-pb?from=yiiadmin\u0026download=1\u0026version=1\u0026skin=1\u0026btn-skin=107\u0026auto=0\u0026download=1\u0026pbad=1\"\n   \u003e\u003c/iframe\u003e\n \u003c/div\u003e\n\n\u003chr\u003e\n\u003cdiv style=\"position: relative; padding-bottom: 56.25%; height: 0; overflow: hidden;\"\u003e\n      \u003ciframe allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share; fullscreen\" loading=\"eager\" referrerpolicy=\"strict-origin-when-cross-origin\" src=\"https://www.youtube.com/embed/R6DExMI8iVw?autoplay=0\u0026amp;controls=1\u0026amp;end=0\u0026amp;loop=0\u0026amp;mute=0\u0026amp;start=0\" style=\"position: absolute; top: 0; left: 0; width: 100%; height: 100%; border:0;\" title=\"YouTube video\"\u003e\u003c/iframe\u003e\n    \u003c/div\u003e\n\n\u003ch2 id=\"summary\"\u003eSummary\u003c/h2\u003e\n\u003cp\u003eIn this episode, Mattias, Andrey, and Paulina welcome back returning guest Paul from System Initiative to continue a conversation that started in the previous episode about their project Swamp. The discussion digs into how AI-assisted software development has changed over the past year, and why the real shift is not \u0026ldquo;AI writes code\u0026rdquo; but humans orchestrating multiple specialized agents with strong guardrails. Paul walks through the practical workflows, multi-layered testing, architecture-first thinking, cost discipline, and security practices his team has adopted — while the hosts push on how this applies across enterprise environments, mentoring newcomers, and the uncomfortable question of who is responsible when AI-built software fails.\u003c/p\u003e\n\u003ch2 id=\"key-topics\"\u003eKey Topics\u003c/h2\u003e\n\u003ch3 id=\"the-industry-crossroads-layoffs-fear-and-a-new-reality\"\u003eThe industry crossroads: layoffs, fear, and a new reality\u003c/h3\u003e\n\u003cp\u003eBefore diving into technical specifics, Paul acknowledges that the industry is at \u0026ldquo;a real crazy crossroads.\u0026rdquo; He references Block (formerly Square) cutting roughly 40% of their workforce, citing uncertainty about what AI means for their teams. He wants to be transparent that System Initiative also shrank — but clarifies the company did not cut people because of AI. The decision to reduce headcount came before they even knew what they were going to build next, let alone how they would build it. AI entered the picture only after they started prototyping the next version of their product.\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003eBlock\u0026rsquo;s February 2026 layoffs, announced by CEO Jack Dorsey, eliminated over 4,000 positions. The move was framed as an AI-driven restructuring, making it one of the most visible examples of AI anxiety playing out in real corporate decisions.\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003ch3 id=\"from-genai-hype-to-agentic-collaboration\"\u003eFrom GenAI hype to agentic collaboration\u003c/h3\u003e\n\u003cp\u003ePaul explains that AI coding quality shifted significantly around October–November of the previous year. Before that, results were inconsistent — sometimes impressive, often garbage. Then the models improved dramatically in both reasoning and code generation.\u003c/p\u003e\n\u003cp\u003eBut the bigger breakthrough, in his view, was not the models themselves. It was the industry\u0026rsquo;s shift from \u0026ldquo;Gen AI\u0026rdquo; — one-shot prompting where you hand over a spec and accept whatever comes back — to \u003cstrong\u003eagentic AI\u003c/strong\u003e, where the model acts more like a pair programmer. In that setup, the human stays in the loop, challenges the plan, adds constraints, and steers the result toward something that fits the codebase.\u003c/p\u003e\n\u003cp\u003eHe gives a concrete early example: System Initiative had a CLI written in \u003cstrong\u003eDeno\u003c/strong\u003e (a TypeScript runtime). Because the models were well-trained on TypeScript libraries and the Deno ecosystem, they started producing decent code. Not beautiful, not perfectly architected — but functional. When Paul began feeding the agent patterns, conventions, and existing code to follow, the output became coherent with their codebase.\u003c/p\u003e\n\u003cp\u003eThis led to a workflow where Paul would open six Claude Code sessions at once in separate \u003cstrong\u003eGit worktrees\u003c/strong\u003e — isolated copies of the repository on different branches — each building a small feature in parallel, feeding them bug reports and data, and continuously interacting with the results rather than one-shotting them.\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e\u003cstrong\u003eGit worktrees\u003c/strong\u003e let you check out multiple branches of the same repository simultaneously in separate directories. Each worktree is independent, so you can work on several features at once and merge them back via pull requests.\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003eHe later expanded this by running longer tasks on a \u003cstrong\u003eMac Mini\u003c/strong\u003e accessible via \u003cstrong\u003eTailscale\u003c/strong\u003e (a mesh VPN), while handling shorter tasks on his laptop — effectively distributing AI workloads across machines.\u003c/p\u003e\n\u003ch3 id=\"why-architecture-matters-more-than-ever\"\u003eWhy architecture matters more than ever\u003c/h3\u003e\n\u003cp\u003eOne of Paul\u0026rsquo;s strongest themes is that AI shifts engineering attention away from syntax and back toward architecture. He argues that AI can generate plenty of code, but without design principles and boundaries it will produce spaghetti on top of existing spaghetti.\u003c/p\u003e\n\u003cp\u003eHe introduces the idea of \u0026ldquo;the first thousand lines\u0026rdquo; — an anecdote he read recently claiming that the first thousand lines of code an agent helps write determine its path forward. If those lines are well-structured and follow clear design principles, the agent will build coherently on top of them. If they are messy and unprincipled, everything after will compound the mess.\u003c/p\u003e\n\u003cp\u003ePaul breaks software development into three layers:\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eArchitecture\u003c/strong\u003e — design patterns like DDD (Domain-Driven Design), CQRS (Command Query Responsibility Segregation)\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePatterns\u003c/strong\u003e — principles like DRY (Don\u0026rsquo;t Repeat Yourself), YAGNI (You Aren\u0026rsquo;t Gonna Need It), KISS (Keep It Simple)\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eTaste\u003c/strong\u003e — naming conventions, module layout, project structure, Terraform module organization\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003eHe argues the industry spent the last decade obsessing over \u0026ldquo;taste\u0026rdquo; while often mocking \u003cstrong\u003e\u0026ldquo;ivory tower architects\u0026rdquo;\u003c/strong\u003e — the people who designed systems but didn\u0026rsquo;t write code. In an AI-driven world, those architectural concerns become critical again because the agent needs clear boundaries, domain structure, and intent to produce coherent output.\u003c/p\u003e\n\u003cp\u003ePaulina agrees and observes that this trend may also blur traditional specialization lines, pushing engineers toward becoming more general \u0026ldquo;software people\u0026rdquo; rather than narrowly front-end, back-end, or DevOps specialists.\u003c/p\u003e\n\u003ch3 id=\"encoding-design-docs-rules-and-constraints-into-the-repo\"\u003eEncoding design docs, rules, and constraints into the repo\u003c/h3\u003e\n\u003cp\u003ePaul describes how his team makes architecture actionable for AI by encoding system knowledge directly into the repository. Their approach has several layers:\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eDesign documents\u003c/strong\u003e — Detailed docs covering the model layer (the actual objects, their purposes, how they relate), workflow construction (how models connect and pass data), and expression language behavior. These live in a \u003ccode\u003e/design\u003c/code\u003e folder in the open-source repo and describe the intent of every part of the system.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eArchitectural rules\u003c/strong\u003e — The agent is explicitly told to follow Domain-Driven Design: proper separation between domains, infrastructure, repositories, and output layers. The DDD skill is loaded so the agent understands and maintains bounded contexts.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eCode standards\u003c/strong\u003e — TypeScript strict mode, no \u003ccode\u003eany\u003c/code\u003e types, named exports, passing lint and format checks. License compliance is also enforced: because the project is \u003cstrong\u003eAGPL v3\u003c/strong\u003e, the agent cannot pull in dependencies with incompatible licenses.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSkills\u003c/strong\u003e — A newer mechanism for \u003cstrong\u003elazy-loading\u003c/strong\u003e contextual information into the AI agent. Rather than stuffing everything into one enormous prompt, skills are loaded on demand when the agent encounters a specific type of task. This keeps context windows lean and focused.\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e\u003cstrong\u003eAGPL v3\u003c/strong\u003e (GNU Affero General Public License) is a copyleft license that requires anyone who runs modified software over a network to make the source code available. This creates strict constraints on what dependencies can be used.\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003ch3 id=\"multi-agent-development-the-full-chain\"\u003eMulti-agent development: the full chain\u003c/h3\u003e\n\u003cp\u003eA major part of the discussion centers on how Paul\u0026rsquo;s team works with multiple specialized AI agents rather than a single all-knowing assistant. The chain looks like this:\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eIssue triage agent\u003c/strong\u003e — When a user opens a GitHub issue, an agent evaluates whether it is a legitimate feature request or bug report. The agent\u0026rsquo;s summary is posted back to the issue immediately, creating context for later stages.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003ePlanning agent\u003c/strong\u003e — If the issue is legitimate, the system enters plan mode. A specification is generated and posted for the user to review. Users can push back (\u0026ldquo;that\u0026rsquo;s not how I think it should work\u0026rdquo;), and the plan is revised until everyone agrees.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eImplementation agent\u003c/strong\u003e — The code is written based on the approved plan, with all the design docs, architectural rules, and skills loaded as context.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eHappy-path reviewer\u003c/strong\u003e — A separate agent reviews the code against standards, checking that it loads correctly and appears to function.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eAdversarial reviewer\u003c/strong\u003e — Added just days before the recording, this agent is told: \u003cem\u003e\u0026ldquo;You are a grumpy DevOps engineer and I want you to pull this code apart.\u0026rdquo;\u003c/em\u003e It looks for security injection points, failure modes, and anything the happy-path reviewer might miss.\u003c/p\u003e\n\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003eBoth review agents write their findings as comments on the pull request, creating a visible audit trail. The PR only merges when both agents approve. If the adversarial agent flags a security vulnerability, the implementation goes back for changes.\u003c/p\u003e\n\u003cp\u003ePaul says this \u0026ldquo;Jekyll and Hyde\u0026rdquo; review setup caught a \u003cstrong\u003epath traversal bug\u003c/strong\u003e in their CLI during its first week. While the CLI runs locally and the risk was limited, it proved the value of adversarial review.\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e\u003cstrong\u003ePath traversal\u003c/strong\u003e is a vulnerability where an attacker can access files outside the intended directory by manipulating file paths (e.g., using \u003ccode\u003e../\u003c/code\u003e sequences). Even in CLI tools, this can expose sensitive files on a user\u0026rsquo;s machine.\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003eMattias compares the overall process to a modernized CI/CD pipeline — the same stages exist (commit, test, review, promote, release), but AI replaces some of the manual implementation steps while humans stay focused on architecture, review, and acceptance.\u003c/p\u003e\n\u003ch3 id=\"why-external-pull-requests-are-disabled\"\u003eWhy external pull requests are disabled\u003c/h3\u003e\n\u003cp\u003eOne of the more provocative decisions Paul describes: the open-source Swamp project \u003cstrong\u003edoes not accept external pull requests\u003c/strong\u003e. GitHub recently added a feature to disable PR creation from non-collaborators entirely, and the team turned it on immediately.\u003c/p\u003e\n\u003cp\u003eThe reasoning is supply chain control. Because the project\u0026rsquo;s code is 100% AI-generated within a tightly controlled context — design docs, architectural rules, skills, adversarial review — they want to ensure that all code entering the system passes through the same pipeline. External PRs would bypass that chain of custody.\u003c/p\u003e\n\u003cp\u003eContributors are instead directed to open issues. The team will work through the design collaboratively, plan it together, and then have their agents implement it. Paul frames this not as rejecting collaboration but as controlling the process: \u0026ldquo;We love contributions, but in the AI world, we cannot control where that code is from or what that code is doing.\u0026rdquo;\u003c/p\u003e\n\u003ch3 id=\"self-reporting-bugs-ai-filing-its-own-issues\"\u003eSelf-reporting bugs: AI filing its own issues\u003c/h3\u003e\n\u003cp\u003eThe team built a skill into Swamp itself so that when the tool encounters a bug during use, it can check out the version of the source code the binary was built against, analyze the problem, and \u003cstrong\u003eopen a GitHub issue automatically\u003c/strong\u003e with detailed context.\u003c/p\u003e\n\u003cp\u003eThis creates high-quality bug reports that already contain the information needed to reason about a fix. When the implementation agent later picks up that issue, it has precise context — where the bug is, what triggered it, and what the expected behavior should be. Paul says the quality of issues generated this way is significantly higher than typical user-filed bugs.\u003c/p\u003e\n\u003ch3 id=\"testing-the-favorite-part\"\u003eTesting: the favorite part\u003c/h3\u003e\n\u003cp\u003eAlthough the conversation starts with code generation, Paul says testing is actually his favorite part of the workflow. The team runs multiple layers:\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eProduct-level tests:\u003c/strong\u003e\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eUnit and integration tests\u003c/strong\u003e — standard code-level verification\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eArchitectural fitness tests\u003c/strong\u003e — contract tests, property tests, and DDD boundary checks that verify the domain doesn\u0026rsquo;t leak and the agent followed its instructions\u003c/li\u003e\n\u003c/ul\u003e\n\u003cblockquote\u003e\n\u003cp\u003e\u003cstrong\u003eArchitectural fitness tests\u003c/strong\u003e are automated checks that verify a system\u0026rsquo;s structure conforms to its intended architecture. In DDD, this means ensuring bounded contexts don\u0026rsquo;t leak dependencies across domain boundaries.\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e\u003cstrong\u003eUser-level tests\u003c/strong\u003e (separate repo):\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eUser flow tests\u003c/strong\u003e — written from the user\u0026rsquo;s perspective against compiled binaries, not source code. These live in a different repository specifically so they are not influenced by how the code is written. They test scenarios like: create a repository, extend the system, create a workflow, run a model, handle wrong inputs.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e\u003cstrong\u003eAdversarial tests\u003c/strong\u003e (multiple tiers):\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eSecurity boundary tests\u003c/strong\u003e — path traversal, environment variable exposure, supply chain attack vectors. Paul references the recent Trivy incident, where a bot stole an API key and used it to delete all of Trivy\u0026rsquo;s GitHub releases and publish a poisoned VS Code extension.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eState corruption\u003c/strong\u003e — what happens when someone tampers with the state layer\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eConcurrency\u003c/strong\u003e — multiple writes, lock failures, race conditions\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eResource exhaustion\u003c/strong\u003e — handling pathological inputs like a 100MB stdout message injected into a workflow\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003eOnly after all these layers pass does a build get promoted from nightly to stable. Paul can download and manually test any nightly build that maps back to a specific commit.\u003c/p\u003e\n\u003cp\u003ePaulina points out that if AI is a force multiplier, there is now even less excuse not to write tests. Paul agrees: \u0026ldquo;We were scraping the barrel before at coming up with reasons why there shouldn\u0026rsquo;t be any tests. Now that\u0026rsquo;s eliminated.\u0026rdquo;\u003c/p\u003e\n\u003ch3 id=\"plan-mode-as-a-safety-rail\"\u003ePlan mode as a safety rail\u003c/h3\u003e\n\u003cp\u003ePaul repeatedly emphasizes \u0026ldquo;plan mode,\u0026rdquo; particularly in Claude Code. Before the agent changes anything, it produces a detailed plan describing what it intends to do and why, and waits for human approval.\u003c/p\u003e\n\u003cp\u003eThe hosts immediately draw a parallel to \u003ccode\u003eterraform plan\u003c/code\u003e — the value is not just automation, but the chance to inspect intended changes before applying them. Paul says this was one of the biggest improvements in AI-assisted development because it reduces horror-story scenarios where an agent goes off and deletes a database or rewrites an application.\u003c/p\u003e\n\u003cp\u003eHe notes that other tools are starting to adopt plan mode because it produces better results across the board. But he also warns that plan mode only helps if people actually read the plan — just like Terraform, the safeguard depends on human discipline. \u0026ldquo;If there\u0026rsquo;s a big line in the middle that says \u0026lsquo;I\u0026rsquo;m going to delete a database\u0026rsquo; and you haven\u0026rsquo;t read it — it\u0026rsquo;s the same thing.\u0026rdquo;\u003c/p\u003e\n\u003ch3 id=\"practical-lessons-for-getting-good-results\"\u003ePractical lessons for getting good results\u003c/h3\u003e\n\u003cp\u003ePaul shares several tactical lessons:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eDon\u0026rsquo;t give mega-prompts\u003c/strong\u003e — \u0026ldquo;Don\u0026rsquo;t write \u0026lsquo;rebuild me Slack\u0026rsquo; and expect an AI agent to do it. You\u0026rsquo;d be shocked at the amount of people who try this.\u0026rdquo;\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAlways provide design docs\u003c/strong\u003e — Specifications produce dramatically better output than vague instructions.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eDon\u0026rsquo;t skip straight to code\u003c/strong\u003e — Start with design and planning, not \u0026ldquo;code me this method.\u0026rdquo;\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eSmall tasks\u003c/strong\u003e — Don\u0026rsquo;t attempt project-wide rewrites with a single agent. Context loss is the new \u0026ldquo;restart your machine.\u0026rdquo;\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eNever trust the first plan\u003c/strong\u003e — Paul routinely asks the agent: \u0026ldquo;Are you sure this is the right plan? Explain it to me like a five-year-old. Does this fulfill what the user needed?\u0026rdquo;\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eCompare implementation to plan\u003c/strong\u003e — After implementation, ask the agent to map what it actually did against the original plan and explain any deviations.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eHe also notes that the generated TypeScript is not always how a human would write it — but that matters less if the result is well-tested, secure, and respects domain boundaries. \u0026ldquo;The actual syntax of the code itself can change 12 times a day. It doesn\u0026rsquo;t really matter as long as it adheres to the product.\u0026rdquo;\u003c/p\u003e\n\u003ch3 id=\"human-oversight-at-every-stage\"\u003eHuman oversight at every stage\u003c/h3\u003e\n\u003cp\u003eDespite all the automation, Paul is adamant that humans remain involved at every stage. Plans are reviewed, implementations are questioned, pull request comments are inspected, binaries are tested before reaching stable release. He describes it as \u0026ldquo;continually interacting with Claude Code\u0026rdquo; rather than just letting things happen.\u003c/p\u003e\n\u003cp\u003eWhen Paulina pushes on whether a human still checks things before production, Paul makes clear: yes, always. The release pipeline goes from commit to nightly to manual verification to stable promotion. \u0026ldquo;I will always download something before it goes to stable.\u0026rdquo;\u003c/p\u003e\n\u003ch3 id=\"the-context-switching-tax\"\u003eThe context-switching tax\u003c/h3\u003e\n\u003cp\u003ePaul acknowledges that running multiple agents in parallel is not for everyone. Context switching has always been expensive for engineers, and commanding multiple agents simultaneously is a new form of it. His advice: if you work best focusing on a single task, don\u0026rsquo;t force the multi-agent style. \u0026ldquo;It\u0026rsquo;ll be such a context switching killer and it\u0026rsquo;ll cause you to lose focus.\u0026rdquo;\u003c/p\u003e\n\u003cp\u003eThe key shift is that instead of writing code, you are \u0026ldquo;commanding architecture and commanding design.\u0026rdquo; But that still requires focus and judgment.\u003c/p\u003e\n\u003ch3 id=\"ai-as-a-force-multiplier-not-a-replacement\"\u003eAI as a force multiplier, not a replacement\u003c/h3\u003e\n\u003cp\u003ePaulina captures the dynamic bluntly: \u0026ldquo;It\u0026rsquo;s a multiplier. If there is a good thing, you\u0026rsquo;ll get a lot of good thing. If it\u0026rsquo;s a shit, you\u0026rsquo;re going to get a lot of shit.\u0026rdquo;\u003c/p\u003e\n\u003cp\u003ePaul argues that experienced software and operations people are still essential because they understand architecture, security, constraints, and tradeoffs. AI amplifies whatever is already there — good engineering or bad engineering alike.\u003c/p\u003e\n\u003cp\u003eHe believes engineers who learn to use these tools well become \u0026ldquo;even more important to your company than you already are.\u0026rdquo; But he also acknowledges that some people will not want to work this way, and that friction between AI-forward and AI-resistant teams is already happening in organizations.\u003c/p\u003e\n\u003ch3 id=\"the-challenge-for-juniors-and-newcomers\"\u003eThe challenge for juniors and newcomers\u003c/h3\u003e\n\u003cp\u003ePaulina raises this personally — she was recently asked to mentor someone entering IT and struggled with how to approach it. She doesn\u0026rsquo;t have a formal IT education (she has an engineering background) and learned on the go. The skills she built through manual work — understanding when code needs refactoring as scale changes, knowing how to structure projects at different sizes — are hard to teach when AI handles so much of the writing.\u003c/p\u003e\n\u003cp\u003ePaul agrees this is an open question and says the industry is still figuring out the patterns. He believes teaching \u003cstrong\u003eprinciples, architecture, and core engineering fundamentals\u003c/strong\u003e becomes even more important, because tool-specific syntax is increasingly handled by AI. \u0026ldquo;Do you need to know how to write a Terraform module? Do you need to know how to write a Pulumi provider?\u0026rdquo; — these are becoming less essential as individual skills, while understanding how systems fit together matters more.\u003c/p\u003e\n\u003cp\u003eHe frames this as an opportunity: \u0026ldquo;We are now in control of helping shape how this moves forward in the industry.\u0026rdquo; As innovators and early adopters, current practitioners can set the patterns. If they don\u0026rsquo;t, someone else will.\u003c/p\u003e\n\u003ch3 id=\"security-responsibility-and-the-risk-of-low-code-ai\"\u003eSecurity, responsibility, and the risk of low-code AI\u003c/h3\u003e\n\u003cp\u003ePaulina raises a concrete example from Poland: someone built an app using AI to upload receipts to a centralized accounting system, released it publicly, and exposed all their customers\u0026rsquo; data.\u003c/p\u003e\n\u003cp\u003eThis leads to a deeper question from Mattias about responsibility: if someone with no engineering background builds an insecure app using an AI tool, who is accountable? The user? The platform? The model provider? The episode doesn\u0026rsquo;t settle this, but Paul argues it reinforces why skilled engineers remain essential. The AI doesn\u0026rsquo;t know the security boundary unless someone explicitly teaches it — \u0026ldquo;it probably wasn\u0026rsquo;t fed that information that it had to think about the security context.\u0026rdquo;\u003c/p\u003e\n\u003cp\u003eHe expects more specialized skills and agents focused on security, accessibility, and compliance to emerge — calling out the example of loading a security skill and an accessibility skill when you know an app will be public-facing. But he says the ecosystem is not fully there yet.\u003c/p\u003e\n\u003ch3 id=\"cost-discipline-structure-beats-vibe-coding\"\u003eCost discipline: structure beats vibe coding\u003c/h3\u003e\n\u003cp\u003ePaul addresses economics directly. His five-person team at System Initiative all use \u003cstrong\u003eClaude Max Pro\u003c/strong\u003e at $200 per person per month. They do not exceed that cost for the full AI workflow — code generation, reviews, planning, and adversarial testing.\u003c/p\u003e\n\u003cp\u003eIn contrast, he has seen other organizations spend $10,000–$12,000 per month per developer on AI tokens because they let tools roam with huge context windows and vague instructions. His conclusion: tightly scoped tasks are not just better for quality — they are far cheaper.\u003c/p\u003e\n\u003cp\u003eThis maps directly to classic engineering wisdom. Tightly defined stories and tasks were always more efficient to push through a system than \u0026ldquo;go rebuild this thing and I\u0026rsquo;ll see you in six months.\u0026rdquo; The same principle applies to AI agents.\u003c/p\u003e\n\u003ch3 id=\"how-to-introduce-ai-in-cautious-organizations\"\u003eHow to introduce AI in cautious organizations\u003c/h3\u003e\n\u003cp\u003eFor teams in companies that ban or restrict AI, Paul suggests a pragmatic entry point: \u003cstrong\u003euse agents to analyze, not to write code.\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eHe describes a conversation with someone in London who asked how to get started. Paul\u0026rsquo;s advice: if you already know roughly where a bug lives, ask the agent to analyze the same bug report. If it identifies the same area and the same root cause, you have evidence that the tool can accelerate diagnosis. Show your CTO: \u0026ldquo;I\u0026rsquo;m diagnosing bugs 50% faster with this agent. It\u0026rsquo;s not writing code — it\u0026rsquo;s helping me understand where the issue is.\u0026rdquo;\u003c/p\u003e\n\u003cp\u003eSimilar analysis-first use cases work for accessibility reviews, security scans, or code quality assessments. The point is to build trust before expanding scope. Paul notes this approach works faster in the private sector than the public sector, where technology adoption has always been slower.\u003c/p\u003e\n\u003ch3 id=\"the-pace-of-change-is-accelerating\"\u003eThe pace of change is accelerating\u003c/h3\u003e\n\u003cp\u003ePaul believes the conversation has shifted dramatically in the past six months — from AI horror stories and commiserating over drinks to genuine success stories and conferences forming around agentic engineering practices. He points to two upcoming events:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eAn \u003cstrong\u003eAgentic conference in Stockholm\u003c/strong\u003e organized by Robert Westin, who Paulina mentions meeting just the day before\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAgentic Conf in Hamburg\u003c/strong\u003e at the end of March\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eHis prediction: the pace is not linear. \u0026ldquo;We\u0026rsquo;re honestly exponential at this moment in time.\u0026rdquo; He sidesteps the ethics of AI companies (referencing tensions between Anthropic and OpenAI) to focus on the practical reality that models, reasoning, and tooling are all improving at a compounding rate.\u003c/p\u003e\n\u003ch2 id=\"highlights\"\u003eHighlights\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003ePaul on the industry mood:\u003c/strong\u003e \u0026ldquo;We\u0026rsquo;re at this real crazy crossroads in the industry.\u0026rdquo;\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePaul on model quality:\u003c/strong\u003e Around late last year, \u0026ldquo;the models got really good, like really, really good. Really, really, really incredible.\u0026rdquo;\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePaul on running six agents at once:\u003c/strong\u003e \u0026ldquo;I had my terminal open. I had six Claude Codes going at once, building like six different small features at a time.\u0026rdquo;\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePaulina\u0026rsquo;s blunt summary:\u003c/strong\u003e \u0026ldquo;It\u0026rsquo;s a multiplier. If there is a good thing, you\u0026rsquo;ll get a lot of good thing. If it\u0026rsquo;s a shit, you\u0026rsquo;re going to get a lot of shit.\u0026rdquo;\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePaul\u0026rsquo;s spicy take on architecture:\u003c/strong\u003e The industry spent years mocking \u0026ldquo;ivory tower architects,\u0026rdquo; but now AI is pushing engineers back into \u0026ldquo;the architecture lab.\u0026rdquo;\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePaul on plan mode:\u003c/strong\u003e It is the AI equivalent of \u003ccode\u003eterraform plan\u003c/code\u003e — useful, but only if people actually read it.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePaul\u0026rsquo;s unusual open-source policy:\u003c/strong\u003e External pull requests are disabled entirely so the team can control the supply chain.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eMost memorable workflow detail:\u003c/strong\u003e Paul\u0026rsquo;s adversarial reviewer is instructed, \u0026ldquo;You are a grumpy DevOps engineer and I want you to pull this code apart.\u0026rdquo;\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePractical win:\u003c/strong\u003e That grumpy reviewer caught a path traversal bug in its first week.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePaul on testing excuses:\u003c/strong\u003e \u0026ldquo;We were scraping the barrel before at coming up with reasons why there shouldn\u0026rsquo;t be any tests. Now that\u0026rsquo;s eliminated.\u0026rdquo;\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePaul\u0026rsquo;s warning against mega-prompts:\u003c/strong\u003e Asking an agent to \u0026ldquo;rebuild me Slack\u0026rdquo; with no context is a great way to conclude, incorrectly, that \u0026ldquo;AI is garbage.\u0026rdquo;\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePaul on context loss:\u003c/strong\u003e \u0026ldquo;Compact your conversation\u0026rdquo; is the new \u0026ldquo;restart your machine.\u0026rdquo;\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePaul on cost:\u003c/strong\u003e Five people, $200/month each, covering the full AI workflow — versus orgs spending $10K+ per developer per month on unfocused vibe coding.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePaul on adoption strategy:\u003c/strong\u003e Start by letting AI analyze bugs and accessibility issues — build trust before asking it to write code.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"resources\"\u003eResources\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://code.claude.com/docs/en/common-workflows\"\u003eClaude Code Documentation — Common Workflows\u003c/a\u003e — Official Anthropic docs covering plan mode, extended thinking, and agentic workflows in Claude Code.\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://github.com/anthropics/skills\"\u003eAnthropic Skills Repository\u003c/a\u003e — Public repository of modular Markdown-based skill packages that extend Claude\u0026rsquo;s capabilities for specialized tasks like security review or accessibility checking.\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://github.com/systeminit/si\"\u003eSystem Initiative on GitHub\u003c/a\u003e — The open-source repository for System Initiative\u0026rsquo;s infrastructure automation platform, including the design documents Paul references.\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://git-scm.com/docs/git-worktree\"\u003eGit Worktree Documentation\u003c/a\u003e — Official docs for \u003ccode\u003egit worktree\u003c/code\u003e, the feature that enables Paul\u0026rsquo;s multi-branch parallel development workflow.\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://socket.dev/blog/unauthorized-ai-agent-execution-code-published-to-openvsx-in-aqua-trivy-vs-code-extension\"\u003eTrivy Supply Chain Attack Analysis (Socket)\u003c/a\u003e — Detailed writeup of the incident Paul references where a bot stole credentials, deleted GitHub releases, and published a poisoned VS Code extension.\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://evolutionaryarchitecture.com/\"\u003eBuilding Evolutionary Architectures — Fitness Functions\u003c/a\u003e — The book and concepts behind architectural fitness tests that Paul\u0026rsquo;s team uses to verify DDD boundaries and prevent domain leakage.\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://github.blog/changelog/2026-02-13-new-repository-settings-for-configuring-pull-request-access/\"\u003eGitHub: New Repository Settings for Pull Request Access\u003c/a\u003e — The GitHub feature Paul mentions for disabling external pull requests at the repository level.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"summary-1\"\u003eSummary\u003c/h2\u003e\n\u003cp\u003eIn this episode, Mattias, Andre, and Paulina welcome back returning guest Paul from System Initiative to continue a conversation that started in the previous episode about their project Swamp. The discussion digs into how AI-assisted software development has changed over the past year, and why the real shift is not \u0026ldquo;AI writes code\u0026rdquo; but humans orchestrating multiple specialized agents with strong guardrails. Paul walks through the practical workflows, multi-layered testing, architecture-first thinking, cost discipline, and security practices his team has adopted — while the hosts push on how this applies across enterprise environments, mentoring newcomers, and the uncomfortable question of who is responsible when AI-built software fails.\u003c/p\u003e\n\u003ch2 id=\"key-topics-1\"\u003eKey Topics\u003c/h2\u003e\n\u003ch3 id=\"the-industry-crossroads-layoffs-fear-and-a-new-reality-1\"\u003eThe industry crossroads: layoffs, fear, and a new reality\u003c/h3\u003e\n\u003cp\u003eBefore diving into technical specifics, Paul acknowledges that the industry is at \u0026ldquo;a real crazy crossroads.\u0026rdquo; He references Block (formerly Square) cutting roughly 40% of their workforce, citing uncertainty about what AI means for their teams. He wants to be transparent that System Initiative also shrank — but clarifies the company did not cut people because of AI. The decision to reduce headcount came before they even knew what they were going to build next, let alone how they would build it. AI entered the picture only after they started prototyping the next version of their product.\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003eBlock\u0026rsquo;s February 2026 layoffs, announced by CEO Jack Dorsey, eliminated over 4,000 positions. The move was framed as an AI-driven restructuring, making it one of the most visible examples of AI anxiety playing out in real corporate decisions.\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003ch3 id=\"from-genai-hype-to-agentic-collaboration-1\"\u003eFrom GenAI hype to agentic collaboration\u003c/h3\u003e\n\u003cp\u003ePaul explains that AI coding quality shifted significantly around October–November of the previous year. Before that, results were inconsistent — sometimes impressive, often garbage. Then the models improved dramatically in both reasoning and code generation.\u003c/p\u003e\n\u003cp\u003eBut the bigger breakthrough, in his view, was not the models themselves. It was the industry\u0026rsquo;s shift from \u0026ldquo;Gen AI\u0026rdquo; — one-shot prompting where you hand over a spec and accept whatever comes back — to \u003cstrong\u003eagentic AI\u003c/strong\u003e, where the model acts more like a pair programmer. In that setup, the human stays in the loop, challenges the plan, adds constraints, and steers the result toward something that fits the codebase.\u003c/p\u003e\n\u003cp\u003eHe gives a concrete early example: System Initiative had a CLI written in \u003cstrong\u003eDeno\u003c/strong\u003e (a TypeScript runtime). Because the models were well-trained on TypeScript libraries and the Deno ecosystem, they started producing decent code. Not beautiful, not perfectly architected — but functional. When Paul began feeding the agent patterns, conventions, and existing code to follow, the output became coherent with their codebase.\u003c/p\u003e\n\u003cp\u003eThis led to a workflow where Paul would open six Claude Code sessions at once in separate \u003cstrong\u003eGit worktrees\u003c/strong\u003e — isolated copies of the repository on different branches — each building a small feature in parallel, feeding them bug reports and data, and continuously interacting with the results rather than one-shotting them.\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e\u003cstrong\u003eGit worktrees\u003c/strong\u003e let you check out multiple branches of the same repository simultaneously in separate directories. Each worktree is independent, so you can work on several features at once and merge them back via pull requests.\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003eHe later expanded this by running longer tasks on a \u003cstrong\u003eMac Mini\u003c/strong\u003e accessible via \u003cstrong\u003eTailscale\u003c/strong\u003e (a mesh VPN), while handling shorter tasks on his laptop — effectively distributing AI workloads across machines.\u003c/p\u003e\n\u003ch3 id=\"why-architecture-matters-more-than-ever-1\"\u003eWhy architecture matters more than ever\u003c/h3\u003e\n\u003cp\u003eOne of Paul\u0026rsquo;s strongest themes is that AI shifts engineering attention away from syntax and back toward architecture. He argues that AI can generate plenty of code, but without design principles and boundaries it will produce spaghetti on top of existing spaghetti.\u003c/p\u003e\n\u003cp\u003eHe introduces the idea of \u0026ldquo;the first thousand lines\u0026rdquo; — an anecdote he read recently claiming that the first thousand lines of code an agent helps write determine its path forward. If those lines are well-structured and follow clear design principles, the agent will build coherently on top of them. If they are messy and unprincipled, everything after will compound the mess.\u003c/p\u003e\n\u003cp\u003ePaul breaks software development into three layers:\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eArchitecture\u003c/strong\u003e — design patterns like DDD (Domain-Driven Design), CQRS (Command Query Responsibility Segregation)\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePatterns\u003c/strong\u003e — principles like DRY (Don\u0026rsquo;t Repeat Yourself), YAGNI (You Aren\u0026rsquo;t Gonna Need It), KISS (Keep It Simple)\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eTaste\u003c/strong\u003e — naming conventions, module layout, project structure, Terraform module organization\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003eHe argues the industry spent the last decade obsessing over \u0026ldquo;taste\u0026rdquo; while often mocking \u003cstrong\u003e\u0026ldquo;ivory tower architects\u0026rdquo;\u003c/strong\u003e — the people who designed systems but didn\u0026rsquo;t write code. In an AI-driven world, those architectural concerns become critical again because the agent needs clear boundaries, domain structure, and intent to produce coherent output.\u003c/p\u003e\n\u003cp\u003ePaulina agrees and observes that this trend may also blur traditional specialization lines, pushing engineers toward becoming more general \u0026ldquo;software people\u0026rdquo; rather than narrowly front-end, back-end, or DevOps specialists.\u003c/p\u003e\n\u003ch3 id=\"encoding-design-docs-rules-and-constraints-into-the-repo-1\"\u003eEncoding design docs, rules, and constraints into the repo\u003c/h3\u003e\n\u003cp\u003ePaul describes how his team makes architecture actionable for AI by encoding system knowledge directly into the repository. Their approach has several layers:\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eDesign documents\u003c/strong\u003e — Detailed docs covering the model layer (the actual objects, their purposes, how they relate), workflow construction (how models connect and pass data), and expression language behavior. These live in a \u003ccode\u003e/design\u003c/code\u003e folder in the open-source repo and describe the intent of every part of the system.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eArchitectural rules\u003c/strong\u003e — The agent is explicitly told to follow Domain-Driven Design: proper separation between domains, infrastructure, repositories, and output layers. The DDD skill is loaded so the agent understands and maintains bounded contexts.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eCode standards\u003c/strong\u003e — TypeScript strict mode, no \u003ccode\u003eany\u003c/code\u003e types, named exports, passing lint and format checks. License compliance is also enforced: because the project is \u003cstrong\u003eAGPL v3\u003c/strong\u003e, the agent cannot pull in dependencies with incompatible licenses.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSkills\u003c/strong\u003e — A newer mechanism for \u003cstrong\u003elazy-loading\u003c/strong\u003e contextual information into the AI agent. Rather than stuffing everything into one enormous prompt, skills are loaded on demand when the agent encounters a specific type of task. This keeps context windows lean and focused.\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e\u003cstrong\u003eAGPL v3\u003c/strong\u003e (GNU Affero General Public License) is a copyleft license that requires anyone who runs modified software over a network to make the source code available. This creates strict constraints on what dependencies can be used.\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003ch3 id=\"multi-agent-development-the-full-chain-1\"\u003eMulti-agent development: the full chain\u003c/h3\u003e\n\u003cp\u003eA major part of the discussion centers on how Paul\u0026rsquo;s team works with multiple specialized AI agents rather than a single all-knowing assistant. The chain looks like this:\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eIssue triage agent\u003c/strong\u003e — When a user opens a GitHub issue, an agent evaluates whether it is a legitimate feature request or bug report. The agent\u0026rsquo;s summary is posted back to the issue immediately, creating context for later stages.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003ePlanning agent\u003c/strong\u003e — If the issue is legitimate, the system enters plan mode. A specification is generated and posted for the user to review. Users can push back (\u0026ldquo;that\u0026rsquo;s not how I think it should work\u0026rdquo;), and the plan is revised until everyone agrees.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eImplementation agent\u003c/strong\u003e — The code is written based on the approved plan, with all the design docs, architectural rules, and skills loaded as context.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eHappy-path reviewer\u003c/strong\u003e — A separate agent reviews the code against standards, checking that it loads correctly and appears to function.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eAdversarial reviewer\u003c/strong\u003e — Added just days before the recording, this agent is told: \u003cem\u003e\u0026ldquo;You are a grumpy DevOps engineer and I want you to pull this code apart.\u0026rdquo;\u003c/em\u003e It looks for security injection points, failure modes, and anything the happy-path reviewer might miss.\u003c/p\u003e\n\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003eBoth review agents write their findings as comments on the pull request, creating a visible audit trail. The PR only merges when both agents approve. If the adversarial agent flags a security vulnerability, the implementation goes back for changes.\u003c/p\u003e\n\u003cp\u003ePaul says this \u0026ldquo;Jekyll and Hyde\u0026rdquo; review setup caught a \u003cstrong\u003epath traversal bug\u003c/strong\u003e in their CLI during its first week. While the CLI runs locally and the risk was limited, it proved the value of adversarial review.\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e\u003cstrong\u003ePath traversal\u003c/strong\u003e is a vulnerability where an attacker can access files outside the intended directory by manipulating file paths (e.g., using \u003ccode\u003e../\u003c/code\u003e sequences). Even in CLI tools, this can expose sensitive files on a user\u0026rsquo;s machine.\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003eMattias compares the overall process to a modernized CI/CD pipeline — the same stages exist (commit, test, review, promote, release), but AI replaces some of the manual implementation steps while humans stay focused on architecture, review, and acceptance.\u003c/p\u003e\n\u003ch3 id=\"why-external-pull-requests-are-disabled-1\"\u003eWhy external pull requests are disabled\u003c/h3\u003e\n\u003cp\u003eOne of the more provocative decisions Paul describes: the open-source Swamp project \u003cstrong\u003edoes not accept external pull requests\u003c/strong\u003e. GitHub recently added a feature to disable PR creation from non-collaborators entirely, and the team turned it on immediately.\u003c/p\u003e\n\u003cp\u003eThe reasoning is supply chain control. Because the project\u0026rsquo;s code is 100% AI-generated within a tightly controlled context — design docs, architectural rules, skills, adversarial review — they want to ensure that all code entering the system passes through the same pipeline. External PRs would bypass that chain of custody.\u003c/p\u003e\n\u003cp\u003eContributors are instead directed to open issues. The team will work through the design collaboratively, plan it together, and then have their agents implement it. Paul frames this not as rejecting collaboration but as controlling the process: \u0026ldquo;We love contributions, but in the AI world, we cannot control where that code is from or what that code is doing.\u0026rdquo;\u003c/p\u003e\n\u003ch3 id=\"self-reporting-bugs-ai-filing-its-own-issues-1\"\u003eSelf-reporting bugs: AI filing its own issues\u003c/h3\u003e\n\u003cp\u003eThe team built a skill into Swamp itself so that when the tool encounters a bug during use, it can check out the version of the source code the binary was built against, analyze the problem, and \u003cstrong\u003eopen a GitHub issue automatically\u003c/strong\u003e with detailed context.\u003c/p\u003e\n\u003cp\u003eThis creates high-quality bug reports that already contain the information needed to reason about a fix. When the implementation agent later picks up that issue, it has precise context — where the bug is, what triggered it, and what the expected behavior should be. Paul says the quality of issues generated this way is significantly higher than typical user-filed bugs.\u003c/p\u003e\n\u003ch3 id=\"testing-the-favorite-part-1\"\u003eTesting: the favorite part\u003c/h3\u003e\n\u003cp\u003eAlthough the conversation starts with code generation, Paul says testing is actually his favorite part of the workflow. The team runs multiple layers:\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eProduct-level tests:\u003c/strong\u003e\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eUnit and integration tests\u003c/strong\u003e — standard code-level verification\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eArchitectural fitness tests\u003c/strong\u003e — contract tests, property tests, and DDD boundary checks that verify the domain doesn\u0026rsquo;t leak and the agent followed its instructions\u003c/li\u003e\n\u003c/ul\u003e\n\u003cblockquote\u003e\n\u003cp\u003e\u003cstrong\u003eArchitectural fitness tests\u003c/strong\u003e are automated checks that verify a system\u0026rsquo;s structure conforms to its intended architecture. In DDD, this means ensuring bounded contexts don\u0026rsquo;t leak dependencies across domain boundaries.\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e\u003cstrong\u003eUser-level tests\u003c/strong\u003e (separate repo):\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eUser flow tests\u003c/strong\u003e — written from the user\u0026rsquo;s perspective against compiled binaries, not source code. These live in a different repository specifically so they are not influenced by how the code is written. They test scenarios like: create a repository, extend the system, create a workflow, run a model, handle wrong inputs.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e\u003cstrong\u003eAdversarial tests\u003c/strong\u003e (multiple tiers):\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eSecurity boundary tests\u003c/strong\u003e — path traversal, environment variable exposure, supply chain attack vectors. Paul references the recent Trivy incident, where a bot stole an API key and used it to delete all of Trivy\u0026rsquo;s GitHub releases and publish a poisoned VS Code extension.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eState corruption\u003c/strong\u003e — what happens when someone tampers with the state layer\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eConcurrency\u003c/strong\u003e — multiple writes, lock failures, race conditions\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eResource exhaustion\u003c/strong\u003e — handling pathological inputs like a 100MB stdout message injected into a workflow\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003eOnly after all these layers pass does a build get promoted from nightly to stable. Paul can download and manually test any nightly build that maps back to a specific commit.\u003c/p\u003e\n\u003cp\u003ePaulina points out that if AI is a force multiplier, there is now even less excuse not to write tests. Paul agrees: \u0026ldquo;We were scraping the barrel before at coming up with reasons why there shouldn\u0026rsquo;t be any tests. Now that\u0026rsquo;s eliminated.\u0026rdquo;\u003c/p\u003e\n\u003ch3 id=\"plan-mode-as-a-safety-rail-1\"\u003ePlan mode as a safety rail\u003c/h3\u003e\n\u003cp\u003ePaul repeatedly emphasizes \u0026ldquo;plan mode,\u0026rdquo; particularly in Claude Code. Before the agent changes anything, it produces a detailed plan describing what it intends to do and why, and waits for human approval.\u003c/p\u003e\n\u003cp\u003eThe hosts immediately draw a parallel to \u003ccode\u003eterraform plan\u003c/code\u003e — the value is not just automation, but the chance to inspect intended changes before applying them. Paul says this was one of the biggest improvements in AI-assisted development because it reduces horror-story scenarios where an agent goes off and deletes a database or rewrites an application.\u003c/p\u003e\n\u003cp\u003eHe notes that other tools are starting to adopt plan mode because it produces better results across the board. But he also warns that plan mode only helps if people actually read the plan — just like Terraform, the safeguard depends on human discipline. \u0026ldquo;If there\u0026rsquo;s a big line in the middle that says \u0026lsquo;I\u0026rsquo;m going to delete a database\u0026rsquo; and you haven\u0026rsquo;t read it — it\u0026rsquo;s the same thing.\u0026rdquo;\u003c/p\u003e\n\u003ch3 id=\"practical-lessons-for-getting-good-results-1\"\u003ePractical lessons for getting good results\u003c/h3\u003e\n\u003cp\u003ePaul shares several tactical lessons:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eDon\u0026rsquo;t give mega-prompts\u003c/strong\u003e — \u0026ldquo;Don\u0026rsquo;t write \u0026lsquo;rebuild me Slack\u0026rsquo; and expect an AI agent to do it. You\u0026rsquo;d be shocked at the amount of people who try this.\u0026rdquo;\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAlways provide design docs\u003c/strong\u003e — Specifications produce dramatically better output than vague instructions.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eDon\u0026rsquo;t skip straight to code\u003c/strong\u003e — Start with design and planning, not \u0026ldquo;code me this method.\u0026rdquo;\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eSmall tasks\u003c/strong\u003e — Don\u0026rsquo;t attempt project-wide rewrites with a single agent. Context loss is the new \u0026ldquo;restart your machine.\u0026rdquo;\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eNever trust the first plan\u003c/strong\u003e — Paul routinely asks the agent: \u0026ldquo;Are you sure this is the right plan? Explain it to me like a five-year-old. Does this fulfill what the user needed?\u0026rdquo;\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eCompare implementation to plan\u003c/strong\u003e — After implementation, ask the agent to map what it actually did against the original plan and explain any deviations.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eHe also notes that the generated TypeScript is not always how a human would write it — but that matters less if the result is well-tested, secure, and respects domain boundaries. \u0026ldquo;The actual syntax of the code itself can change 12 times a day. It doesn\u0026rsquo;t really matter as long as it adheres to the product.\u0026rdquo;\u003c/p\u003e\n\u003ch3 id=\"human-oversight-at-every-stage-1\"\u003eHuman oversight at every stage\u003c/h3\u003e\n\u003cp\u003eDespite all the automation, Paul is adamant that humans remain involved at every stage. Plans are reviewed, implementations are questioned, pull request comments are inspected, binaries are tested before reaching stable release. He describes it as \u0026ldquo;continually interacting with Claude Code\u0026rdquo; rather than just letting things happen.\u003c/p\u003e\n\u003cp\u003eWhen Paulina pushes on whether a human still checks things before production, Paul makes clear: yes, always. The release pipeline goes from commit to nightly to manual verification to stable promotion. \u0026ldquo;I will always download something before it goes to stable.\u0026rdquo;\u003c/p\u003e\n\u003ch3 id=\"the-context-switching-tax-1\"\u003eThe context-switching tax\u003c/h3\u003e\n\u003cp\u003ePaul acknowledges that running multiple agents in parallel is not for everyone. Context switching has always been expensive for engineers, and commanding multiple agents simultaneously is a new form of it. His advice: if you work best focusing on a single task, don\u0026rsquo;t force the multi-agent style. \u0026ldquo;It\u0026rsquo;ll be such a context switching killer and it\u0026rsquo;ll cause you to lose focus.\u0026rdquo;\u003c/p\u003e\n\u003cp\u003eThe key shift is that instead of writing code, you are \u0026ldquo;commanding architecture and commanding design.\u0026rdquo; But that still requires focus and judgment.\u003c/p\u003e\n\u003ch3 id=\"ai-as-a-force-multiplier-not-a-replacement-1\"\u003eAI as a force multiplier, not a replacement\u003c/h3\u003e\n\u003cp\u003ePaulina captures the dynamic bluntly: \u0026ldquo;It\u0026rsquo;s a multiplier. If there is a good thing, you\u0026rsquo;ll get a lot of good thing. If it\u0026rsquo;s a shit, you\u0026rsquo;re going to get a lot of shit.\u0026rdquo;\u003c/p\u003e\n\u003cp\u003ePaul argues that experienced software and operations people are still essential because they understand architecture, security, constraints, and tradeoffs. AI amplifies whatever is already there — good engineering or bad engineering alike.\u003c/p\u003e\n\u003cp\u003eHe believes engineers who learn to use these tools well become \u0026ldquo;even more important to your company than you already are.\u0026rdquo; But he also acknowledges that some people will not want to work this way, and that friction between AI-forward and AI-resistant teams is already happening in organizations.\u003c/p\u003e\n\u003ch3 id=\"the-challenge-for-juniors-and-newcomers-1\"\u003eThe challenge for juniors and newcomers\u003c/h3\u003e\n\u003cp\u003ePaulina raises this personally — she was recently asked to mentor someone entering IT and struggled with how to approach it. She doesn\u0026rsquo;t have a formal IT education (she has an engineering background) and learned on the go. The skills she built through manual work — understanding when code needs refactoring as scale changes, knowing how to structure projects at different sizes — are hard to teach when AI handles so much of the writing.\u003c/p\u003e\n\u003cp\u003ePaul agrees this is an open question and says the industry is still figuring out the patterns. He believes teaching \u003cstrong\u003eprinciples, architecture, and core engineering fundamentals\u003c/strong\u003e becomes even more important, because tool-specific syntax is increasingly handled by AI. \u0026ldquo;Do you need to know how to write a Terraform module? Do you need to know how to write a Pulumi provider?\u0026rdquo; — these are becoming less essential as individual skills, while understanding how systems fit together matters more.\u003c/p\u003e\n\u003cp\u003eHe frames this as an opportunity: \u0026ldquo;We are now in control of helping shape how this moves forward in the industry.\u0026rdquo; As innovators and early adopters, current practitioners can set the patterns. If they don\u0026rsquo;t, someone else will.\u003c/p\u003e\n\u003ch3 id=\"security-responsibility-and-the-risk-of-low-code-ai-1\"\u003eSecurity, responsibility, and the risk of low-code AI\u003c/h3\u003e\n\u003cp\u003ePaulina raises a concrete example from Poland: someone built an app using AI to upload receipts to a centralized accounting system, released it publicly, and exposed all their customers\u0026rsquo; data.\u003c/p\u003e\n\u003cp\u003eThis leads to a deeper question from Mattias about responsibility: if someone with no engineering background builds an insecure app using an AI tool, who is accountable? The user? The platform? The model provider? The episode doesn\u0026rsquo;t settle this, but Paul argues it reinforces why skilled engineers remain essential. The AI doesn\u0026rsquo;t know the security boundary unless someone explicitly teaches it — \u0026ldquo;it probably wasn\u0026rsquo;t fed that information that it had to think about the security context.\u0026rdquo;\u003c/p\u003e\n\u003cp\u003eHe expects more specialized skills and agents focused on security, accessibility, and compliance to emerge — calling out the example of loading a security skill and an accessibility skill when you know an app will be public-facing. But he says the ecosystem is not fully there yet.\u003c/p\u003e\n\u003ch3 id=\"cost-discipline-structure-beats-vibe-coding-1\"\u003eCost discipline: structure beats vibe coding\u003c/h3\u003e\n\u003cp\u003ePaul addresses economics directly. His five-person team at System Initiative all use \u003cstrong\u003eClaude Max Pro\u003c/strong\u003e at $200 per person per month. They do not exceed that cost for the full AI workflow — code generation, reviews, planning, and adversarial testing.\u003c/p\u003e\n\u003cp\u003eIn contrast, he has seen other organizations spend $10,000–$12,000 per month per developer on AI tokens because they let tools roam with huge context windows and vague instructions. His conclusion: tightly scoped tasks are not just better for quality — they are far cheaper.\u003c/p\u003e\n\u003cp\u003eThis maps directly to classic engineering wisdom. Tightly defined stories and tasks were always more efficient to push through a system than \u0026ldquo;go rebuild this thing and I\u0026rsquo;ll see you in six months.\u0026rdquo; The same principle applies to AI agents.\u003c/p\u003e\n\u003ch3 id=\"how-to-introduce-ai-in-cautious-organizations-1\"\u003eHow to introduce AI in cautious organizations\u003c/h3\u003e\n\u003cp\u003eFor teams in companies that ban or restrict AI, Paul suggests a pragmatic entry point: \u003cstrong\u003euse agents to analyze, not to write code.\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eHe describes a conversation with someone in London who asked how to get started. Paul\u0026rsquo;s advice: if you already know roughly where a bug lives, ask the agent to analyze the same bug report. If it identifies the same area and the same root cause, you have evidence that the tool can accelerate diagnosis. Show your CTO: \u0026ldquo;I\u0026rsquo;m diagnosing bugs 50% faster with this agent. It\u0026rsquo;s not writing code — it\u0026rsquo;s helping me understand where the issue is.\u0026rdquo;\u003c/p\u003e\n\u003cp\u003eSimilar analysis-first use cases work for accessibility reviews, security scans, or code quality assessments. The point is to build trust before expanding scope. Paul notes this approach works faster in the private sector than the public sector, where technology adoption has always been slower.\u003c/p\u003e\n\u003ch3 id=\"the-pace-of-change-is-accelerating-1\"\u003eThe pace of change is accelerating\u003c/h3\u003e\n\u003cp\u003ePaul believes the conversation has shifted dramatically in the past six months — from AI horror stories and commiserating over drinks to genuine success stories and conferences forming around agentic engineering practices. He points to two upcoming events:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eAn \u003cstrong\u003eAgentic conference in Stockholm\u003c/strong\u003e organized by Robert Westin, who Paulina mentions meeting just the day before\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAgentic Conf in Hamburg\u003c/strong\u003e at the end of March\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eHis prediction: the pace is not linear. \u0026ldquo;We\u0026rsquo;re honestly exponential at this moment in time.\u0026rdquo; He sidesteps the ethics of AI companies (referencing tensions between Anthropic and OpenAI) to focus on the practical reality that models, reasoning, and tooling are all improving at a compounding rate.\u003c/p\u003e\n\u003ch2 id=\"highlights-1\"\u003eHighlights\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003ePaul on the industry mood:\u003c/strong\u003e \u0026ldquo;We\u0026rsquo;re at this real crazy crossroads in the industry.\u0026rdquo;\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePaul on model quality:\u003c/strong\u003e Around late last year, \u0026ldquo;the models got really good, like really, really good. Really, really, really incredible.\u0026rdquo;\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePaul on running six agents at once:\u003c/strong\u003e \u0026ldquo;I had my terminal open. I had six Claude Codes going at once, building like six different small features at a time.\u0026rdquo;\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePaulina\u0026rsquo;s blunt summary:\u003c/strong\u003e \u0026ldquo;It\u0026rsquo;s a multiplier. If there is a good thing, you\u0026rsquo;ll get a lot of good thing. If it\u0026rsquo;s a shit, you\u0026rsquo;re going to get a lot of shit.\u0026rdquo;\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePaul\u0026rsquo;s spicy take on architecture:\u003c/strong\u003e The industry spent years mocking \u0026ldquo;ivory tower architects,\u0026rdquo; but now AI is pushing engineers back into \u0026ldquo;the architecture lab.\u0026rdquo;\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePaul on plan mode:\u003c/strong\u003e It is the AI equivalent of \u003ccode\u003eterraform plan\u003c/code\u003e — useful, but only if people actually read it.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePaul\u0026rsquo;s unusual open-source policy:\u003c/strong\u003e External pull requests are disabled entirely so the team can control the supply chain.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eMost memorable workflow detail:\u003c/strong\u003e Paul\u0026rsquo;s adversarial reviewer is instructed, \u0026ldquo;You are a grumpy DevOps engineer and I want you to pull this code apart.\u0026rdquo;\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePractical win:\u003c/strong\u003e That grumpy reviewer caught a path traversal bug in its first week.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePaul on testing excuses:\u003c/strong\u003e \u0026ldquo;We were scraping the barrel before at coming up with reasons why there shouldn\u0026rsquo;t be any tests. Now that\u0026rsquo;s eliminated.\u0026rdquo;\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePaul\u0026rsquo;s warning against mega-prompts:\u003c/strong\u003e Asking an agent to \u0026ldquo;rebuild me Slack\u0026rdquo; with no context is a great way to conclude, incorrectly, that \u0026ldquo;AI is garbage.\u0026rdquo;\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePaul on context loss:\u003c/strong\u003e \u0026ldquo;Compact your conversation\u0026rdquo; is the new \u0026ldquo;restart your machine.\u0026rdquo;\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePaul on cost:\u003c/strong\u003e Five people, $200/month each, covering the full AI workflow — versus orgs spending $10K+ per developer per month on unfocused vibe coding.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePaul on adoption strategy:\u003c/strong\u003e Start by letting AI analyze bugs and accessibility issues — build trust before asking it to write code.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"resources-1\"\u003eResources\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://code.claude.com/docs/en/common-workflows\"\u003eClaude Code Documentation — Common Workflows\u003c/a\u003e — Official Anthropic docs covering plan mode, extended thinking, and agentic workflows in Claude Code.\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://github.com/anthropics/skills\"\u003eAnthropic Skills Repository\u003c/a\u003e — Public repository of modular Markdown-based skill packages that extend Claude\u0026rsquo;s capabilities for specialized tasks like security review or accessibility checking.\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://github.com/systeminit/si\"\u003eSystem Initiative on GitHub\u003c/a\u003e — The open-source repository for System Initiative\u0026rsquo;s infrastructure automation platform, including the design documents Paul references.\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://git-scm.com/docs/git-worktree\"\u003eGit Worktree Documentation\u003c/a\u003e — Official docs for \u003ccode\u003egit worktree\u003c/code\u003e, the feature that enables Paul\u0026rsquo;s multi-branch parallel development workflow.\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://socket.dev/blog/unauthorized-ai-agent-execution-code-published-to-openvsx-in-aqua-trivy-vs-code-extension\"\u003eTrivy Supply Chain Attack Analysis (Socket)\u003c/a\u003e — Detailed writeup of the incident Paul references where a bot stole credentials, deleted GitHub releases, and published a poisoned VS Code extension.\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://evolutionaryarchitecture.com/\"\u003eBuilding Evolutionary Architectures — Fitness Functions\u003c/a\u003e — The book and concepts behind architectural fitness tests that Paul\u0026rsquo;s team uses to verify DDD boundaries and prevent domain leakage.\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://github.blog/changelog/2026-02-13-new-repository-settings-for-configuring-pull-request-access/\"\u003eGitHub: New Repository Settings for Pull Request Access\u003c/a\u003e — The GitHub feature Paul mentions for disabling external pull requests at the repository level.\u003c/li\u003e\n\u003c/ul\u003e"},{"title":"#93 - The DevSecOps Perspective: Key Takeaways From Re:Invent 2025","date_published":"2026-03-05T22:59:07Z","date_modified":"2026-03-05T22:59:07Z","id":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/093-the-devsecops-perspective-key-takeaways-from-re-invent-2025/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/093-the-devsecops-perspective-key-takeaways-from-re-invent-2025/","authors":[{"name":"DevSecOps Talks"}],"content_html":"\u003cp\u003eAndrey and Mattias share a fast re:Invent roundup focused on AWS security. What do VPC Encryption Controls, post-quantum TLS, and org-level S3 block public access change for you? Which features should you switch on now, like ECR image signing, JWT checks at ALB, and air-gapped AWS Backup? Want simple wins you can use today?\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/company/devsecops-talks/\"\u003eDiscuss the episode or ask us anything on LinkedIn\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"single_player_container\"\u003e\n   \u003ciframe\n     title=\"DEVSECOPS Talks #93 - The DevSecOps Perspective: Key Takeaways From Re:Invent 2025\"\n     height=\"122\"\n     width=\"100%\"\n     style=\"border: none;\"\n     scrolling=\"no\"\n     data-name=\"pb-iframe-player\"\n     src=\"https://www.podbean.com/media/player/hkvh9-1a62a54-pb?from=yiiadmin\u0026download=1\u0026version=1\u0026skin=1\u0026btn-skin=107\u0026auto=0\u0026download=1\u0026pbad=1\"\n   \u003e\u003c/iframe\u003e\n \u003c/div\u003e\n\n\u003chr\u003e\n\u003cdiv style=\"position: relative; padding-bottom: 56.25%; height: 0; overflow: hidden;\"\u003e\n      \u003ciframe allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share; fullscreen\" loading=\"eager\" referrerpolicy=\"strict-origin-when-cross-origin\" src=\"https://www.youtube.com/embed/YtQ2svENQzk?autoplay=0\u0026amp;controls=1\u0026amp;end=0\u0026amp;loop=0\u0026amp;mute=0\u0026amp;start=0\" style=\"position: absolute; top: 0; left: 0; width: 100%; height: 100%; border:0;\" title=\"YouTube video\"\u003e\u003c/iframe\u003e\n    \u003c/div\u003e\n\n\u003ch2 id=\"summary\"\u003eSummary\u003c/h2\u003e\n\u003cp\u003eIn this episode, Andrey and Mattias deliver a security-heavy recap of AWS re:Invent 2025 announcements, while noting that Paulina is absent and wishing her a speedy recovery. Out of more than 500 releases surrounding the event, the hosts narrow the list to roughly 20 features they consider immediately actionable for security-conscious teams. The discussion covers encryption enforcement, post-quantum readiness, access control, backup resilience, detection tooling, and organization-wide guardrails, with a recurring theme that many of these features are simple \u0026ldquo;turn it on and forget it\u0026rdquo; wins.\u003c/p\u003e\n\u003ch2 id=\"key-topics\"\u003eKey Topics\u003c/h2\u003e\n\u003ch3 id=\"aws-reinvent-through-a-security-lens\"\u003eAWS re:Invent Through a Security Lens\u003c/h3\u003e\n\u003cp\u003eThe hosts frame the episode as the DevSecOps Talks version of a re:Invent recap. Andrey, who also led a re:Invent recap webinar at his consultancy 5XL, jokes that despite the podcast covering development, security, and operations, this episode\u0026rsquo;s selection of announcements \u0026ldquo;smells more like security only.\u0026rdquo; He warns listeners that if security is not their thing, they may be slightly disappointed, but encourages them to stay tuned anyway.\u003c/p\u003e\n\u003cp\u003eDuring the 5XL webinar, AI was the most popular topic among attendees, with particular interest in Amazon S3 Vectors, a new storage option that lets teams store vector embeddings (numerical representations of data used by large language models) directly in S3. Andrey notes it is cost-efficient as a backbone for RAG (Retrieval-Augmented Generation) architectures, though it currently lacks hybrid search capabilities.\u003c/p\u003e\n\u003ch3 id=\"vpc-encryption-control\"\u003eVPC Encryption Control\u003c/h3\u003e\n\u003cp\u003eOne of the first announcements discussed is VPC encryption control for Amazon VPC, a pre-re:Invent release that lets teams audit and enforce encryption in transit within and across VPCs in a region. Andrey highlights how painful it has traditionally been to verify internal traffic encryption: teams had to set up traffic mirroring sessions, deploy instances, and use tools like Wireshark to inspect packets manually. This new feature supports two modes, monitor (to audit encryption status via VPC flow logs) and enforce (to require hardware-based AES-256 encryption), making compliance proof dramatically easier for frameworks like HIPAA, PCI DSS, and FedRAMP.\u003c/p\u003e\n\u003cp\u003eMattias adds that compliance expectations are expanding beyond just public endpoints. Encryption inside the VPC is increasingly becoming the baseline expectation. Andrey points out a common pattern where teams terminate TLS at the load balancer but leave traffic between the load balancer and backend targets unencrypted, creating a security gap that this feature can now detect and enforce against.\u003c/p\u003e\n\u003ch3 id=\"post-quantum-cryptography\"\u003ePost-Quantum Cryptography\u003c/h3\u003e\n\u003cp\u003eThe hosts discuss the rapid expansion of post-quantum TLS support across AWS services, now covering S3, ALB, NLB, Private CA, and others. These services use ML-KEM (Module Lattice-Based Key Encapsulation Mechanism), one of NIST\u0026rsquo;s first standardized post-quantum algorithms.\u003c/p\u003e\n\u003cp\u003eAndrey explains the urgency behind this: state-level actors and other adversaries are already collecting encrypted traffic today, banking on future quantum computers being powerful enough to break current encryption standards, a strategy known as \u0026ldquo;Harvest Now, Decrypt Later.\u0026rdquo; He notes that operational quantum computing appears closer than ever, with multiple perspectives suggesting it may be \u0026ldquo;around the corner.\u0026rdquo; Enabling post-quantum ciphers today protects traffic against that future decryption risk, and the hosts recommend enabling it everywhere, especially for sensitive data crossing the public internet.\u003c/p\u003e\n\u003ch3 id=\"s3-security-controls-and-access-management\"\u003eS3 Security Controls and Access Management\u003c/h3\u003e\n\u003cp\u003eSeveral S3-related updates stand out. Andrey calls out attribute-based access control (ABAC) for S3 buckets, which was previously unavailable for S3 specifically. ABAC allows access decisions based on resource tags rather than only enumerating specific IAM actions, making policies more flexible and easier to maintain. The limitation is that it must be enabled bucket by bucket, which Andrey acknowledges is necessary to avoid breaking existing security models, even if organization-wide default would be preferable.\u003c/p\u003e\n\u003cp\u003eThe hosts spend particular time on S3 Block Public Access at the organization level. Previously, teams could block public access per bucket or per account. Now this can be enforced across an entire AWS Organization via an organizational policy. Andrey calls this \u0026ldquo;well overdue\u0026rdquo; and states bluntly that in 2026, there is no good reason to have a public S3 bucket. Both hosts present this as a definitive \u0026ldquo;turn it on and forget it\u0026rdquo; control.\u003c/p\u003e\n\u003ch3 id=\"backups-air-gapping-and-ransomware-resilience\"\u003eBackups, Air-Gapping, and Ransomware Resilience\u003c/h3\u003e\n\u003cp\u003eAWS Backup receives significant attention. The hosts discuss the ability to use logically air-gapped AWS Backup Vault as a primary backup target, meaning organizations can send initial backups directly to isolated vaults without needing a secondary copy operation. This is especially relevant for teams where ransomware is on the threat model. Mattias strongly recommends enabling AWS Backup for anyone running workloads on AWS, regardless of the air-gapping feature.\u003c/p\u003e\n\u003cp\u003eAndrey emphasizes the importance of keeping backups in a separate account from production workloads, so that a compromised workload account cannot reach the recovery data. Additional backup-related announcements include KMS customer-managed key support for air-gapped vaults (providing better policy flexibility) and GuardDuty malware protection for backup artifacts, which can now scan EC2, EBS, and S3 backups for malware.\u003c/p\u003e\n\u003ch3 id=\"managed-container-image-signing-from-amazon-ecr\"\u003eManaged Container Image Signing from Amazon ECR\u003c/h3\u003e\n\u003cp\u003eAmazon ECR now offers managed image signing, which the hosts welcome as a significant simplification. Previously, teams had to set up their own signing infrastructure (often using tools like AWS Signer or Notation). Andrey notes this requires AWS Signer availability in your region, so teams should verify regional support before relying on it.\u003c/p\u003e\n\u003ch3 id=\"dynamic-data-masking-in-aurora-postgresql\"\u003eDynamic Data Masking in Aurora PostgreSQL\u003c/h3\u003e\n\u003cp\u003eAurora PostgreSQL now supports dynamic data masking through the \u003ccode\u003epg_columnmask\u003c/code\u003e extension, allowing teams to configure column-level masking policies so that queries return masked values instead of raw sensitive data. Mattias compares it to similar capabilities in databases like Snowflake and highlights its value when integrating with external partners who need data access without seeing PII.\u003c/p\u003e\n\u003cp\u003eWhen the idea of using masked production data for testing comes up, Andrey\u0026rsquo;s response is direct: \u0026ldquo;Maybe don\u0026rsquo;t do that.\u0026rdquo; Still, both hosts agree that masking at the database layer is a strong defense-in-depth control because it prevents accidental data exposure at the API or frontend layers, where leaks more commonly occur.\u003c/p\u003e\n\u003ch3 id=\"jwt-verification-in-alb-and-network-firewall-proxy\"\u003eJWT Verification in ALB and Network Firewall Proxy\u003c/h3\u003e\n\u003cp\u003eThe hosts review two updates aimed at securing service-to-service communication and outbound traffic. JWT verification is now supported natively in AWS Application Load Balancer for machine-to-machine authentication, eliminating the need for custom Lambda-based solutions that teams previously had to build and maintain.\u003c/p\u003e\n\u003cp\u003eAWS Network Firewall has also gained a web proxy capability (in public preview). Andrey has not explored it in depth yet, but reads it as an extension that could help inspect both internet-bound traffic and traffic heading toward internal corporate data centers, potentially useful for organizations with complex hybrid network architectures.\u003c/p\u003e\n\u003ch3 id=\"rest-api-streaming-in-api-gateway\"\u003eREST API Streaming in API Gateway\u003c/h3\u003e\n\u003cp\u003eAlthough the episode is security-focused, the hosts include one developer-oriented announcement at Mattias\u0026rsquo;s request: REST API streaming support in Amazon API Gateway. This enables progressive response payload streaming, which is particularly relevant for LLM integration where responses are generated token by token. Mattias notes that modern applications increasingly need to stream larger payloads rather than returning small JSON responses in a single shot.\u003c/p\u003e\n\u003ch3 id=\"centralized-observability-with-cloudwatch\"\u003eCentralized Observability with CloudWatch\u003c/h3\u003e\n\u003cp\u003eCloudWatch\u0026rsquo;s unified management for operational, security, and compliance data is discussed as a potentially powerful cross-account aggregation feature. Mattias sees value in having all data sources visible in one place without building custom log aggregation pipelines through Lambdas. However, he immediately warns about CloudWatch data ingest costs, noting that access logs alone generate massive data volumes and the pricing can add up quickly. The feature is in public preview.\u003c/p\u003e\n\u003ch3 id=\"control-tower-organizations-and-guardrails-at-scale\"\u003eControl Tower, Organizations, and Guardrails at Scale\u003c/h3\u003e\n\u003cp\u003eA batch of updates centers on making governance easier to adopt. These include: dedicated controls for AWS Control Tower that can be applied without a full Control Tower deployment, automatic enrollment in Control Tower, required tags via organization stack policies, Amazon Inspector organization-wide management, and billing transfer across multiple AWS Organizations (which Andrey believes is primarily aimed at AWS resellers).\u003c/p\u003e\n\u003cp\u003eMattias states directly that everyone should use Control Tower. Andrey notes that several of these features feel like capabilities teams would have expected to exist already, but welcomes their arrival nonetheless.\u003c/p\u003e\n\u003ch3 id=\"detection-and-threat-response\"\u003eDetection and Threat Response\u003c/h3\u003e\n\u003cp\u003eDetection emerges as a recurring theme throughout the episode. Specific announcements include CloudTrail Insights for data events (which requires logging data events, itself an expensive proposition), extended threat detection for EC2 and ECS in GuardDuty using AI-powered analysis, and the public preview of an AWS Security Agent designed to continuously secure applications from design to deployment.\u003c/p\u003e\n\u003cp\u003eAndrey recommends GuardDuty as a baseline \u0026ldquo;gap stopper\u0026rdquo; that works out of the box with minimal setup. He acknowledges it can become noisy over time and that teams may eventually want more sophisticated tooling, but for getting started, it delivers immediate value.\u003c/p\u003e\n\u003cp\u003eMattias frames the broader trend well: incidents are inevitable, so what matters is how quickly teams can detect and respond. He notes that the majority of AWS\u0026rsquo;s recent security announcements are focused on exactly this, adding more inspection, alerting, and detection capabilities to cloud environments.\u003c/p\u003e\n\u003ch3 id=\"identity-and-iam-improvements\"\u003eIdentity and IAM Improvements\u003c/h3\u003e\n\u003cp\u003eSeveral IAM-related features round out the announcements. The AWS source VPC ARN condition key for IAM policies allows teams to scope permissions based on the originating VPC, which Andrey calls \u0026ldquo;super duper useful\u0026rdquo; for attribute-based policy enforcement. AWS IAM outbound identity federation lets organizations use AWS identities to authenticate against external services via JWT, essentially using AWS as an identity platform. Mattias compares it to how teams already connect GitHub and other services to AWS in the other direction.\u003c/p\u003e\n\u003cp\u003eThe new \u003ccode\u003eaws login\u003c/code\u003e CLI command provides short-lived credentials for IAM users, but Andrey questions whether teams should be using IAM users at all when AWS IAM Identity Center (formerly AWS SSO) is available. He frames \u003ccode\u003eaws login\u003c/code\u003e as better than storing static credentials locally, but still a second-best option.\u003c/p\u003e\n\u003cp\u003eAWS Secrets Manager also announced managed external secrets, allowing teams to manage secrets from external providers alongside AWS-native secrets, which the hosts flag as a useful operational convenience.\u003c/p\u003e\n\u003ch3 id=\"mcp-servers-and-ai-on-aws\"\u003eMCP Servers and AI on AWS\u003c/h3\u003e\n\u003cp\u003eThe public preview of the AWS MCP (Model Context Protocol) server takes a different architectural approach from traditional locally-hosted MCP servers. Rather than running a local proxy that translates LLM requests into API calls, AWS provides remote endpoints that agents can call directly over HTTPS. This means AI agents can interact with AWS services without hosting anything locally.\u003c/p\u003e\n\u003cp\u003eAndrey notes that the IAM model is currently complex: teams need separate permissions to call the MCP server itself and additional permissions to perform the underlying AWS actions. AWS is actively working to streamline this. The hosts also mention the AWS Knowledge MCP server, which provides documentation access via the same remote pattern.\u003c/p\u003e\n\u003ch3 id=\"boris-ai-for-aws-change-awareness\"\u003eBoris: AI for AWS Change Awareness\u003c/h3\u003e\n\u003cp\u003eToward the end of the episode, Andrey reveals a personal project he had planned to keep under wraps for a few more weeks. Boris (getboris.ai) is an AI-driven product built to solve a problem Andrey faces daily as an AWS consultant: keeping up with the constant stream of AWS announcements and figuring out which ones matter for specific customers.\u003c/p\u003e\n\u003cp\u003eBoris connects to an organization\u0026rsquo;s AWS environment, understands what services and configurations are in use, and then filters the daily AWS RSS feed to surface only the announcements relevant to that particular organization, along with explanations of how each feature could benefit them. Mattias calls the concept \u0026ldquo;brilliant\u0026rdquo; and connects it to the same challenge in security, where teams are overwhelmed by a constant firehose of news and feature updates.\u003c/p\u003e\n\u003cp\u003eAndrey also announces that Boris has been accepted into the Tehnopol AI Accelerator in Tallinn, Estonia, selected from more than 100 applicants. Tehnopol is one of Estonia\u0026rsquo;s leading technology parks and startup support organizations. The hosts tease a future dedicated episode about Boris now that it is out of stealth mode.\u003c/p\u003e\n\u003ch2 id=\"highlights\"\u003eHighlights\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eAndrey setting expectations:\u003c/strong\u003e \u0026ldquo;The selection of announcements smells more like security only. If security is your thing, stay tuned in. If it\u0026rsquo;s not really, well, it\u0026rsquo;s still interesting, but I\u0026rsquo;m just trying to manage your possible disappointment.\u0026rdquo;\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAndrey on VPC encryption:\u003c/strong\u003e Proving internal encryption used to require traffic mirroring, Wireshark, and manual inspection. The new VPC encryption control replaces all of that with a toggle.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAndrey on public S3 buckets:\u003c/strong\u003e \u0026ldquo;In 2026 there is no good reason to have a public S3 bucket. Just turn it on, forget about it.\u0026rdquo;\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAndrey on masked data for testing:\u003c/strong\u003e When the idea comes up, his response is blunt: \u0026ldquo;Maybe don\u0026rsquo;t do that.\u0026rdquo;\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eMattias on detection:\u003c/strong\u003e \u0026ldquo;What you can control is how you react when it\u0026rsquo;s going to happen. Detection is really where I put effort.\u0026rdquo; He argues teams should enable detection features \u0026ldquo;as fast as possible.\u0026rdquo;\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eMattias on Control Tower:\u003c/strong\u003e \u0026ldquo;Everybody should use Control Tower.\u0026rdquo; No hedging.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAndrey on Boris:\u003c/strong\u003e Reveals that his AI startup watches the AWS release feed and tells each customer which announcements actually matter to their environment. Mattias\u0026rsquo;s reaction: \u0026ldquo;This is brilliant.\u0026rdquo;\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAccelerator news:\u003c/strong\u003e Boris accepted into the Tehnopol AI Accelerator in Tallinn, selected from more than 100 companies, announced live on the episode.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"resources\"\u003eResources\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://aws.amazon.com/blogs/aws/introducing-vpc-encryption-controls-enforce-encryption-in-transit-within-and-across-vpcs-in-a-region/\"\u003eAWS VPC Encryption Controls announcement\u003c/a\u003e — AWS blog post detailing the monitor and enforce modes for VPC encryption in transit.\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://aws.amazon.com/security/post-quantum-cryptography/\"\u003eAWS Post-Quantum Cryptography overview\u003c/a\u003e — AWS\u0026rsquo;s landing page explaining their post-quantum strategy and which services support ML-KEM.\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://www.paloaltonetworks.com/cyberpedia/harvest-now-decrypt-later-hndl\"\u003eHarvest Now, Decrypt Later explained (Palo Alto Networks)\u003c/a\u003e — Clear explanation of the HNDL threat model that motivates post-quantum adoption.\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://www.hanabyte.com/aws-reinvent-2025-security-announcements/\"\u003eAWS re:Invent 2025 Security Announcements (HanaByte)\u003c/a\u003e — Comprehensive third-party recap of all security-related re:Invent 2025 announcements.\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://www.chrisfarris.com/post/reinvent2025/\"\u003ere:Invent 2025 Security Recap (Chris Farris)\u003c/a\u003e — Independent security-focused re:Invent recap with commentary on practical implications.\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://aws.amazon.com/blogs/database/protect-sensitive-data-with-dynamic-data-masking-for-amazon-aurora-postgresql/\"\u003eDynamic Data Masking for Aurora PostgreSQL\u003c/a\u003e — AWS blog on setting up \u003ccode\u003epg_columnmask\u003c/code\u003e for column-level data masking.\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://aws.amazon.com/blogs/security/understanding-iam-for-managed-aws-mcp-servers/\"\u003eUnderstanding IAM for Managed AWS MCP Servers\u003c/a\u003e — AWS Security blog explaining the dual-permission model for MCP server access.\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://ai.tehnopol.ee/en/\"\u003eTehnopol AI Accelerator\u003c/a\u003e — The AI Accelerator program in Tallinn, Estonia, that accepted Boris into its latest batch.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eNow I have enough research. Let me write the improved article.\u003c/p\u003e\n\u003ch2 id=\"summary-1\"\u003eSummary\u003c/h2\u003e\n\u003cp\u003eIn this episode, Andrey and Mattias deliver a security-heavy recap of AWS re:Invent 2025 announcements, while noting that Paulina is absent and wishing her a speedy recovery. Out of the 500+ releases surrounding re:Invent, they narrow the list down to roughly 20 features that security-conscious teams can act on today — covering encryption, access control, detection, backups, container security, and organization-wide guardrails. Along the way, Andrey reveals a new AI-powered product called Boris that watches the AWS release firehose so you don\u0026rsquo;t have to.\u003c/p\u003e\n\u003ch2 id=\"key-topics-1\"\u003eKey Topics\u003c/h2\u003e\n\u003ch3 id=\"aws-reinvent-through-a-security-lens-1\"\u003eAWS re:Invent Through a Security Lens\u003c/h3\u003e\n\u003cp\u003eThe hosts frame the episode as the DevSecOps Talks version of a re:Invent recap, complementing a FivexL webinar held the previous month. Despite the podcast\u0026rsquo;s name covering development, security, and operations, the selected announcements lean heavily toward security. Andrey is upfront about it: if security is your thing, stay tuned; otherwise, manage your expectations.\u003c/p\u003e\n\u003cp\u003eAt the FivexL webinar, attendees were asked to prioritize areas of interest across compute, security, and networking. AI dominated the conversation, and people were also curious about Amazon S3 Vectors — a new S3 storage class purpose-built for vector embeddings used in RAG (Retrieval-Augmented Generation) architectures that power LLM applications. It is cost-efficient but lacks hybrid search at this stage.\u003c/p\u003e\n\u003ch3 id=\"vpc-encryption-and-post-quantum-readiness\"\u003eVPC Encryption and Post-Quantum Readiness\u003c/h3\u003e\n\u003cp\u003eOne of the first and most praised announcements is \u003cstrong\u003eVPC Encryption Control for Amazon VPC\u003c/strong\u003e, a pre-re:Invent release that lets teams audit and enforce encryption in transit within and across VPCs. The hosts highlight how painful it used to be to verify internal traffic encryption — typically requiring traffic mirroring, spinning up instances, and inspecting packets with tools like Wireshark. This feature offers two modes: \u003cem\u003emonitor\u003c/em\u003e mode to audit encryption status via VPC flow logs, and \u003cem\u003eenforce\u003c/em\u003e mode to block unencrypted resources from attaching to the VPC.\u003c/p\u003e\n\u003cp\u003eMattias adds that compliance expectations are expanding. It used to be enough to encrypt traffic over public endpoints, but the bar is moving toward encryption everywhere, including inside the VPC. The hosts also call out a common pattern: offloading SSL at the load balancer and leaving traffic to targets unencrypted. VPC encryption control helps catch exactly this kind of blind spot.\u003c/p\u003e\n\u003cp\u003eThe discussion then shifts to \u003cstrong\u003epost-quantum cryptography (PQC)\u003c/strong\u003e support rolling out across AWS services including S3, ALB, NLB, AWS Private CA, KMS, ACM, and Secrets Manager. AWS now supports ML-KEM (Module Lattice-Based Key Encapsulation Mechanism), a NIST-standardized post-quantum algorithm, along with ML-DSA (Module Lattice-Based Digital Signature Algorithm) for Private CA certificates.\u003c/p\u003e\n\u003cp\u003eThe rationale: state-level actors are already recording encrypted traffic today in a \u0026ldquo;harvest now, decrypt later\u0026rdquo; strategy, betting that future quantum computers will crack current encryption. Andrey notes that operational quantum computing feels closer than ever, making it worthwhile to enable post-quantum protections now — especially for sensitive data traversing public networks.\u003c/p\u003e\n\u003ch3 id=\"s3-security-controls-and-access-management-1\"\u003eS3 Security Controls and Access Management\u003c/h3\u003e\n\u003cp\u003eSeveral S3-related updates stand out. \u003cstrong\u003eAttribute-Based Access Control (ABAC) for S3\u003c/strong\u003e allows access decisions based on resource tags rather than only enumerating specific actions in policies. This is a powerful way to scope permissions — for example, granting access to all buckets tagged with a specific project — though it must be enabled on a per-bucket basis, which the hosts note is a drawback even if necessary to avoid breaking existing security models.\u003c/p\u003e\n\u003cp\u003eThe bigger crowd-pleaser is \u003cstrong\u003eS3 Block Public Access at the organization level\u003c/strong\u003e. Previously available at the bucket and account level, this control can now be applied across an entire AWS Organization. The hosts call it well overdue and present it as the ultimate \u0026ldquo;turn it on and forget it\u0026rdquo; control: in 2026, there is no good reason to have a public S3 bucket.\u003c/p\u003e\n\u003ch3 id=\"container-image-signing\"\u003eContainer Image Signing\u003c/h3\u003e\n\u003cp\u003e\u003cstrong\u003eAmazon ECR Managed Image Signing\u003c/strong\u003e is a welcome addition. ECR now provides a managed service for signing container images, leveraging AWS Signer for key management and certificate lifecycle. Once configured with a signing rule, ECR automatically signs images as they are pushed. This eliminates the operational overhead of setting up and maintaining container image signing infrastructure — previously a significant barrier for teams wanting to verify image provenance in their supply chains.\u003c/p\u003e\n\u003ch3 id=\"backups-air-gapping-and-ransomware-resilience-1\"\u003eBackups, Air-Gapping, and Ransomware Resilience\u003c/h3\u003e\n\u003cp\u003eAWS Backup gets significant attention. The hosts discuss \u003cstrong\u003eair-gapped AWS Backup Vault support as a primary backup target\u003c/strong\u003e, positioning it as especially relevant for teams where ransomware is on the threat list. These logically air-gapped vaults live in an Amazon-owned account and are locked by default with a compliance vault lock to ensure immutability.\u003c/p\u003e\n\u003cp\u003eThe strong recommendation: enable AWS Backup for any important data, and keep backups isolated in a separate account from your workloads. If an attacker compromises your production account, they should not be able to reach your recovery copies. Related updates include \u003cstrong\u003eKMS customer-managed key support for air-gapped vaults\u003c/strong\u003e for better encryption flexibility, and \u003cstrong\u003eGuardDuty Malware Protection for AWS Backup\u003c/strong\u003e, which can scan backup artifacts for malware before restoration.\u003c/p\u003e\n\u003ch3 id=\"data-protection-in-databases\"\u003eData Protection in Databases\u003c/h3\u003e\n\u003cp\u003e\u003cstrong\u003eDynamic data masking in Aurora PostgreSQL\u003c/strong\u003e draws praise from both hosts. Using the new \u003ccode\u003epg_columnmask\u003c/code\u003e extension, teams can configure column-level masking policies so that queries return masked data instead of actual values — for example, replacing credit card numbers with wildcards. The data in the database remains unmodified; masking happens at query time based on user roles.\u003c/p\u003e\n\u003cp\u003eMattias compares it to capabilities already present in databases like Snowflake and highlights how useful it is when sharing data with external partners or other teams. When the idea of using masked production data for testing comes up, the hosts gently push back — don\u0026rsquo;t do that — but both agree that masking at the database layer is a strong control because it reduces the risk of accidental data exposure through APIs or front-end applications.\u003c/p\u003e\n\u003ch3 id=\"identity-iam-and-federation-improvements\"\u003eIdentity, IAM, and Federation Improvements\u003c/h3\u003e\n\u003cp\u003eThe episode covers several IAM-related features. \u003cstrong\u003eAWS IAM Outbound Identity Federation\u003c/strong\u003e allows federating AWS identities to external services via JWT, effectively letting you use AWS identity as a platform for authenticating to third-party services — similar to how you connect GitHub or other services to AWS today, but in the other direction.\u003c/p\u003e\n\u003cp\u003eThe \u003cstrong\u003eAWS Login CLI command\u003c/strong\u003e provides short-lived credentials for IAM users who don\u0026rsquo;t have AWS IAM Identity Center (SSO) configured. The hosts see it as a better alternative than storing static IAM credentials locally, but also question whether teams should still be relying on IAM users at all — their recommendation is to set up IAM Identity Center and move on.\u003c/p\u003e\n\u003cp\u003eThe \u003cstrong\u003eAWS Source VPC ARN condition key\u003c/strong\u003e gets particular enthusiasm. It allows IAM policies to check which VPC a request originated from, enabling conditions like \u0026ldquo;allow this action only if the request comes from this VPC.\u0026rdquo; For teams doing attribute-based access control in IAM, this is a significant addition.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAWS Secrets Manager Managed External Secrets\u003c/strong\u003e is another useful feature that removes a common operational burden. Previously, rotating third-party SaaS credentials required writing and maintaining custom Lambda functions. Managed external secrets provides built-in rotation for partner integrations — Salesforce, BigID, and Snowflake at launch — with no Lambda functions needed.\u003c/p\u003e\n\u003ch3 id=\"better-security-at-the-network-and-service-layer\"\u003eBetter Security at the Network and Service Layer\u003c/h3\u003e\n\u003cp\u003e\u003cstrong\u003eJWT verification in AWS Application Load Balancer\u003c/strong\u003e simplifies machine-to-machine and service-to-service authentication. Teams previously had to roll their own Lambda-based JWT verification; now it is supported out of the box. The recommendation is straightforward: drop the Lambda and use the built-in capability.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAWS Network Firewall Proxy\u003c/strong\u003e is in public preview. While the hosts have not explored it deeply, their read is that it could help with more advanced network inspection scenarios — not just outgoing internet traffic through NAT gateways, but potentially also traffic heading toward internal corporate data centers.\u003c/p\u003e\n\u003ch3 id=\"developer-oriented-rest-api-streaming\"\u003eDeveloper-Oriented: REST API Streaming\u003c/h3\u003e\n\u003cp\u003eAlthough the episode is mainly security-focused, the hosts include \u003cstrong\u003eREST API streaming in Amazon API Gateway\u003c/strong\u003e as a nod to developers. This enables progressive response payload streaming, which is especially relevant for LLM use cases where streaming tokens to clients is the expected interaction pattern. Mattias notes that applications are moving beyond small JSON payloads — streaming is becoming table stakes as data volumes grow.\u003c/p\u003e\n\u003ch3 id=\"centralized-observability-and-detection\"\u003eCentralized Observability and Detection\u003c/h3\u003e\n\u003cp\u003e\u003cstrong\u003eCloudWatch unified management\u003c/strong\u003e for operational, security, and compliance data promises cross-account visibility from a single pane of glass, without requiring custom log aggregation pipelines built from Lambdas and glue code. The hosts are optimistic but immediately flag the cost: CloudWatch data ingest pricing can escalate quickly when dealing with high-volume sources like access logs. Deep pockets may be required.\u003c/p\u003e\n\u003cp\u003eDetection is a recurring theme throughout the episode. The hosts discuss \u003cstrong\u003eCloudTrail Insights for data events\u003c/strong\u003e (useful if you are already logging data-plane events — another deep-pockets feature), \u003cstrong\u003eextended threat detection for EC2 and ECS in GuardDuty\u003c/strong\u003e using AI-powered analysis to correlate security signals across network activity, runtime behavior, and API calls, and the \u003cstrong\u003epublic preview of AWS Security Agent\u003c/strong\u003e for automated security investigation.\u003c/p\u003e\n\u003cp\u003eOn GuardDuty specifically, the recommendation is clear: if you don\u0026rsquo;t have it enabled, go enable it — it gives you a good baseline that works out of the box across your services with minimal setup. You can always graduate to more sophisticated tooling later, but GuardDuty is the gap-stopper you start with.\u003c/p\u003e\n\u003cp\u003eMattias drives the broader point home: incidents are inevitable, and what you can control is how fast you detect and respond. AWS is clearly investing heavily in the detection side, and teams should enable these capabilities as fast as possible.\u003c/p\u003e\n\u003ch3 id=\"control-tower-organizations-and-guardrails-at-scale-1\"\u003eControl Tower, Organizations, and Guardrails at Scale\u003c/h3\u003e\n\u003cp\u003eSeveral updates make governance easier to adopt at scale:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eDedicated controls for AWS Control Tower\u003c/strong\u003e without requiring a full Control Tower deployment — you can now use Control Tower guardrails à la carte.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAutomatic enrollment in Control Tower\u003c/strong\u003e — a feature the hosts feel should have existed already.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eRequired tags in Organizations stack policies\u003c/strong\u003e — enforcing tagging standards at the organization level.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAmazon Inspector organization-wide management\u003c/strong\u003e — centralized vulnerability scanning across all accounts.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eBilling transfer for AWS Organizations\u003c/strong\u003e — useful for AWS resellers managing multiple organizations.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eDelete protection for CloudWatch Log Groups\u003c/strong\u003e — a small but important safeguard.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eMattias says plainly: everyone should use Control Tower.\u003c/p\u003e\n\u003ch3 id=\"mcp-servers-and-awss-evolving-ai-approach\"\u003eMCP Servers and AWS\u0026rsquo;s Evolving AI Approach\u003c/h3\u003e\n\u003cp\u003eThe conversation shifts to the \u003cstrong\u003epublic preview of AWS MCP (Model Context Protocol) servers\u003c/strong\u003e. Unlike traditional locally-hosted MCP servers that proxy LLM requests to API calls, AWS is taking a different approach with remote, fully managed MCP servers hosted on AWS infrastructure. These allow AI agents and AI-native IDEs to interact with AWS services over HTTPS without running anything locally.\u003c/p\u003e\n\u003cp\u003eAWS launched four managed MCP servers — AWS, EKS, ECS, and SageMaker — that consolidate capabilities like AWS documentation access, API execution across 15,000+ AWS APIs, and pre-built agent workflows. However, the IAM model is still being worked out: you currently need separate permissions to call the MCP server and to perform the underlying AWS actions it invokes. The hosts treat this as interesting but still evolving.\u003c/p\u003e\n\u003ch3 id=\"boris-ai-for-aws-change-awareness-1\"\u003eBoris: AI for AWS Change Awareness\u003c/h3\u003e\n\u003cp\u003eToward the end of the episode, Andrey reveals a personal project: \u003cstrong\u003eBoris\u003c/strong\u003e (\u003ca href=\"https://www.getboris.ai/\"\u003egetboris.ai\u003c/a\u003e), an AI-powered DevOps teammate he has been building. Boris connects to the systems an engineering team already uses and provides evidence-based answers and operational automation.\u003c/p\u003e\n\u003cp\u003eThe specific feature Andrey has been working on takes the AWS RSS feed — where new announcements land daily — and cross-references it against what a customer actually has running in their AWS Organization. Instead of manually sifting through hundreds of releases, Boris sends a digest highlighting only the announcements relevant to your environment and explaining how you would benefit.\u003c/p\u003e\n\u003cp\u003eMattias immediately connects this to the same problem in security: teams are overwhelmed by the constant flow of feature updates and vulnerability news. Having an AI that filters and contextualizes that information is, in his words, \u0026ldquo;brilliant.\u0026rdquo;\u003c/p\u003e\n\u003cp\u003eAndrey also announces that Boris has been accepted into the \u003cstrong\u003eTehnopol AI Accelerator\u003c/strong\u003e in Tallinn, Estonia — a program run by the Tehnopol Science and Business Park that supports early-stage AI startups — selected from more than 100 companies.\u003c/p\u003e\n\u003ch2 id=\"highlights-1\"\u003eHighlights\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eSetting expectations:\u003c/strong\u003e \u0026ldquo;The selection of announcements smells more like security only. If security is your thing, stay tuned in. If it\u0026rsquo;s not really, well, it\u0026rsquo;s still interesting, but I\u0026rsquo;m just trying to manage your possible disappointment.\u0026rdquo;\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eOn VPC encryption control:\u003c/strong\u003e The hosts describe how proving internal encryption used to require traffic mirroring, Wireshark, and significant pain — this feature makes it a configuration toggle.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eOn public S3 buckets:\u003c/strong\u003e \u0026ldquo;In 2026 there is no good reason to have a public S3 bucket. Just turn it on and forget about it.\u0026rdquo;\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eOn production data for testing:\u003c/strong\u003e When someone floats using masked production data for testing — \u0026ldquo;Maybe don\u0026rsquo;t do that.\u0026rdquo;\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eOn detection over prevention:\u003c/strong\u003e \u0026ldquo;You cannot really prevent something from happening in your environment. What you can control is how you react when it\u0026rsquo;s going to happen. Detection is really where I put effort.\u0026rdquo;\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eOn Boris:\u003c/strong\u003e When Andrey describes how Boris watches the AWS release feed and tells you which announcements actually matter for your environment, Mattias\u0026rsquo;s reaction: \u0026ldquo;This is brilliant.\u0026rdquo;\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eOn getting started with AWS security:\u003c/strong\u003e \u0026ldquo;If you are a startup building on AWS and compliance is important, it\u0026rsquo;s quite easy to get it working. All the building blocks and tools are available for you to do the right things.\u0026rdquo;\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"resources-1\"\u003eResources\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://aws.amazon.com/blogs/aws/introducing-vpc-encryption-controls-enforce-encryption-in-transit-within-and-across-vpcs-in-a-region/\"\u003eIntroducing VPC Encryption Controls\u003c/a\u003e — AWS blog post explaining monitor and enforce modes for VPC encryption in transit.\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://aws.amazon.com/security/post-quantum-cryptography/\"\u003eAWS Post-Quantum Cryptography\u003c/a\u003e — AWS overview of post-quantum cryptography migration, including ML-KEM support across S3, ALB, NLB, KMS, and Private CA.\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://aws.amazon.com/about-aws/whats-new/2025/11/amazon-s3-block-public-access-organization-level-enforcement/\"\u003eS3 Block Public Access Organization-Level Enforcement\u003c/a\u003e — Announcement for enforcing S3 public access blocks across an entire AWS Organization.\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://aws.amazon.com/blogs/containers/streamline-container-image-signatures-with-amazon-ecr-managed-signing/\"\u003eAmazon ECR Managed Container Image Signing\u003c/a\u003e — Guide to setting up managed image signing with ECR and AWS Signer.\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://aws.amazon.com/blogs/aws/amazon-guardduty-adds-extended-threat-detection-for-amazon-ec2-and-amazon-ecs/\"\u003eGuardDuty Extended Threat Detection for EC2 and ECS\u003c/a\u003e — How GuardDuty uses AI/ML to correlate security signals and detect multi-stage attacks on compute workloads.\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://aws.amazon.com/blogs/database/protect-sensitive-data-with-dynamic-data-masking-for-amazon-aurora-postgresql/\"\u003eDynamic Data Masking for Aurora PostgreSQL\u003c/a\u003e — How to configure column-level data masking with the pg_columnmask extension.\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://aws.amazon.com/blogs/security/understanding-iam-for-managed-aws-mcp-servers/\"\u003eUnderstanding IAM for Managed AWS MCP Servers\u003c/a\u003e — AWS Security Blog post explaining the IAM permission model for remote MCP servers.\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://www.getboris.ai/\"\u003eB.O.R.I.S — Your AI DevOps Teammate\u003c/a\u003e — The AI-powered product discussed in the episode that tracks AWS announcements and matches them to your environment.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eNow I have enough research. Let me write the improved article.\u003c/p\u003e\n\u003ch2 id=\"summary-2\"\u003eSummary\u003c/h2\u003e\n\u003cp\u003eIn this episode, Andrey and Mattias deliver a security-heavy recap of AWS re:Invent 2025 announcements, while noting that Paulina is absent and wishing her a speedy recovery. Out of the 500+ releases surrounding re:Invent, they narrow the list down to roughly 20 features that security-conscious teams can act on today — covering encryption, access control, detection, backups, container security, and organization-wide guardrails. Along the way, Andrey reveals a new AI-powered product called Boris that watches the AWS release firehose so you don\u0026rsquo;t have to.\u003c/p\u003e\n\u003ch2 id=\"key-topics-2\"\u003eKey Topics\u003c/h2\u003e\n\u003ch3 id=\"aws-reinvent-through-a-security-lens-2\"\u003eAWS re:Invent Through a Security Lens\u003c/h3\u003e\n\u003cp\u003eThe hosts frame the episode as the DevSecOps Talks version of a re:Invent recap, complementing a FivexL webinar held the previous month. Despite the podcast\u0026rsquo;s name covering development, security, and operations, the selected announcements lean heavily toward security. Andrey is upfront about it: if security is your thing, stay tuned; otherwise, manage your expectations.\u003c/p\u003e\n\u003cp\u003eAt the FivexL webinar, attendees were asked to prioritize areas of interest across compute, security, and networking. AI dominated the conversation, and people were also curious about Amazon S3 Vectors — a new S3 storage class purpose-built for vector embeddings used in RAG (Retrieval-Augmented Generation) architectures that power LLM applications. It is cost-efficient but lacks hybrid search at this stage.\u003c/p\u003e\n\u003ch3 id=\"vpc-encryption-and-post-quantum-readiness-1\"\u003eVPC Encryption and Post-Quantum Readiness\u003c/h3\u003e\n\u003cp\u003eOne of the first and most praised announcements is \u003cstrong\u003eVPC Encryption Control for Amazon VPC\u003c/strong\u003e, a pre-re:Invent release that lets teams audit and enforce encryption in transit within and across VPCs. The hosts highlight how painful it used to be to verify internal traffic encryption — typically requiring traffic mirroring, spinning up instances, and inspecting packets with tools like Wireshark. This feature offers two modes: \u003cem\u003emonitor\u003c/em\u003e mode to audit encryption status via VPC flow logs, and \u003cem\u003eenforce\u003c/em\u003e mode to block unencrypted resources from attaching to the VPC.\u003c/p\u003e\n\u003cp\u003eMattias adds that compliance expectations are expanding. It used to be enough to encrypt traffic over public endpoints, but the bar is moving toward encryption everywhere, including inside the VPC. The hosts also call out a common pattern: offloading SSL at the load balancer and leaving traffic to targets unencrypted. VPC encryption control helps catch exactly this kind of blind spot.\u003c/p\u003e\n\u003cp\u003eThe discussion then shifts to \u003cstrong\u003epost-quantum cryptography (PQC)\u003c/strong\u003e support rolling out across AWS services including S3, ALB, NLB, AWS Private CA, KMS, ACM, and Secrets Manager. AWS now supports ML-KEM (Module Lattice-Based Key Encapsulation Mechanism), a NIST-standardized post-quantum algorithm, along with ML-DSA (Module Lattice-Based Digital Signature Algorithm) for Private CA certificates.\u003c/p\u003e\n\u003cp\u003eThe rationale: state-level actors are already recording encrypted traffic today in a \u0026ldquo;harvest now, decrypt later\u0026rdquo; strategy, betting that future quantum computers will crack current encryption. Andrey notes that operational quantum computing feels closer than ever, making it worthwhile to enable post-quantum protections now — especially for sensitive data traversing public networks.\u003c/p\u003e\n\u003ch3 id=\"s3-security-controls-and-access-management-2\"\u003eS3 Security Controls and Access Management\u003c/h3\u003e\n\u003cp\u003eSeveral S3-related updates stand out. \u003cstrong\u003eAttribute-Based Access Control (ABAC) for S3\u003c/strong\u003e allows access decisions based on resource tags rather than only enumerating specific actions in policies. This is a powerful way to scope permissions — for example, granting access to all buckets tagged with a specific project — though it must be enabled on a per-bucket basis, which the hosts note is a drawback even if necessary to avoid breaking existing security models.\u003c/p\u003e\n\u003cp\u003eThe bigger crowd-pleaser is \u003cstrong\u003eS3 Block Public Access at the organization level\u003c/strong\u003e. Previously available at the bucket and account level, this control can now be applied across an entire AWS Organization. The hosts call it well overdue and present it as the ultimate \u0026ldquo;turn it on and forget it\u0026rdquo; control: in 2026, there is no good reason to have a public S3 bucket.\u003c/p\u003e\n\u003ch3 id=\"container-image-signing-1\"\u003eContainer Image Signing\u003c/h3\u003e\n\u003cp\u003e\u003cstrong\u003eAmazon ECR Managed Image Signing\u003c/strong\u003e is a welcome addition. ECR now provides a managed service for signing container images, leveraging AWS Signer for key management and certificate lifecycle. Once configured with a signing rule, ECR automatically signs images as they are pushed. This eliminates the operational overhead of setting up and maintaining container image signing infrastructure — previously a significant barrier for teams wanting to verify image provenance in their supply chains.\u003c/p\u003e\n\u003ch3 id=\"backups-air-gapping-and-ransomware-resilience-2\"\u003eBackups, Air-Gapping, and Ransomware Resilience\u003c/h3\u003e\n\u003cp\u003eAWS Backup gets significant attention. The hosts discuss \u003cstrong\u003eair-gapped AWS Backup Vault support as a primary backup target\u003c/strong\u003e, positioning it as especially relevant for teams where ransomware is on the threat list. These logically air-gapped vaults live in an Amazon-owned account and are locked by default with a compliance vault lock to ensure immutability.\u003c/p\u003e\n\u003cp\u003eThe strong recommendation: enable AWS Backup for any important data, and keep backups isolated in a separate account from your workloads. If an attacker compromises your production account, they should not be able to reach your recovery copies. Related updates include \u003cstrong\u003eKMS customer-managed key support for air-gapped vaults\u003c/strong\u003e for better encryption flexibility, and \u003cstrong\u003eGuardDuty Malware Protection for AWS Backup\u003c/strong\u003e, which can scan backup artifacts for malware before restoration.\u003c/p\u003e\n\u003ch3 id=\"data-protection-in-databases-1\"\u003eData Protection in Databases\u003c/h3\u003e\n\u003cp\u003e\u003cstrong\u003eDynamic data masking in Aurora PostgreSQL\u003c/strong\u003e draws praise from both hosts. Using the new \u003ccode\u003epg_columnmask\u003c/code\u003e extension, teams can configure column-level masking policies so that queries return masked data instead of actual values — for example, replacing credit card numbers with wildcards. The data in the database remains unmodified; masking happens at query time based on user roles.\u003c/p\u003e\n\u003cp\u003eMattias compares it to capabilities already present in databases like Snowflake and highlights how useful it is when sharing data with external partners or other teams. When the idea of using masked production data for testing comes up, the hosts gently push back — don\u0026rsquo;t do that — but both agree that masking at the database layer is a strong control because it reduces the risk of accidental data exposure through APIs or front-end applications.\u003c/p\u003e\n\u003ch3 id=\"identity-iam-and-federation-improvements-1\"\u003eIdentity, IAM, and Federation Improvements\u003c/h3\u003e\n\u003cp\u003eThe episode covers several IAM-related features. \u003cstrong\u003eAWS IAM Outbound Identity Federation\u003c/strong\u003e allows federating AWS identities to external services via JWT, effectively letting you use AWS identity as a platform for authenticating to third-party services — similar to how you connect GitHub or other services to AWS today, but in the other direction.\u003c/p\u003e\n\u003cp\u003eThe \u003cstrong\u003eAWS Login CLI command\u003c/strong\u003e provides short-lived credentials for IAM users who don\u0026rsquo;t have AWS IAM Identity Center (SSO) configured. The hosts see it as a better alternative than storing static IAM credentials locally, but also question whether teams should still be relying on IAM users at all — their recommendation is to set up IAM Identity Center and move on.\u003c/p\u003e\n\u003cp\u003eThe \u003cstrong\u003eAWS Source VPC ARN condition key\u003c/strong\u003e gets particular enthusiasm. It allows IAM policies to check which VPC a request originated from, enabling conditions like \u0026ldquo;allow this action only if the request comes from this VPC.\u0026rdquo; For teams doing attribute-based access control in IAM, this is a significant addition.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAWS Secrets Manager Managed External Secrets\u003c/strong\u003e is another useful feature that removes a common operational burden. Previously, rotating third-party SaaS credentials required writing and maintaining custom Lambda functions. Managed external secrets provides built-in rotation for partner integrations — Salesforce, BigID, and Snowflake at launch — with no Lambda functions needed.\u003c/p\u003e\n\u003ch3 id=\"better-security-at-the-network-and-service-layer-1\"\u003eBetter Security at the Network and Service Layer\u003c/h3\u003e\n\u003cp\u003e\u003cstrong\u003eJWT verification in AWS Application Load Balancer\u003c/strong\u003e simplifies machine-to-machine and service-to-service authentication. Teams previously had to roll their own Lambda-based JWT verification; now it is supported out of the box. The recommendation is straightforward: drop the Lambda and use the built-in capability.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAWS Network Firewall Proxy\u003c/strong\u003e is in public preview. While the hosts have not explored it deeply, their read is that it could help with more advanced network inspection scenarios — not just outgoing internet traffic through NAT gateways, but potentially also traffic heading toward internal corporate data centers.\u003c/p\u003e\n\u003ch3 id=\"developer-oriented-rest-api-streaming-1\"\u003eDeveloper-Oriented: REST API Streaming\u003c/h3\u003e\n\u003cp\u003eAlthough the episode is mainly security-focused, the hosts include \u003cstrong\u003eREST API streaming in Amazon API Gateway\u003c/strong\u003e as a nod to developers. This enables progressive response payload streaming, which is especially relevant for LLM use cases where streaming tokens to clients is the expected interaction pattern. Mattias notes that applications are moving beyond small JSON payloads — streaming is becoming table stakes as data volumes grow.\u003c/p\u003e\n\u003ch3 id=\"centralized-observability-and-detection-1\"\u003eCentralized Observability and Detection\u003c/h3\u003e\n\u003cp\u003e\u003cstrong\u003eCloudWatch unified management\u003c/strong\u003e for operational, security, and compliance data promises cross-account visibility from a single pane of glass, without requiring custom log aggregation pipelines built from Lambdas and glue code. The hosts are optimistic but immediately flag the cost: CloudWatch data ingest pricing can escalate quickly when dealing with high-volume sources like access logs. Deep pockets may be required.\u003c/p\u003e\n\u003cp\u003eDetection is a recurring theme throughout the episode. The hosts discuss \u003cstrong\u003eCloudTrail Insights for data events\u003c/strong\u003e (useful if you are already logging data-plane events — another deep-pockets feature), \u003cstrong\u003eextended threat detection for EC2 and ECS in GuardDuty\u003c/strong\u003e using AI-powered analysis to correlate security signals across network activity, runtime behavior, and API calls, and the \u003cstrong\u003epublic preview of AWS Security Agent\u003c/strong\u003e for automated security investigation.\u003c/p\u003e\n\u003cp\u003eOn GuardDuty specifically, the recommendation is clear: if you don\u0026rsquo;t have it enabled, go enable it — it gives you a good baseline that works out of the box across your services with minimal setup. You can always graduate to more sophisticated tooling later, but GuardDuty is the gap-stopper you start with.\u003c/p\u003e\n\u003cp\u003eMattias drives the broader point home: incidents are inevitable, and what you can control is how fast you detect and respond. AWS is clearly investing heavily in the detection side, and teams should enable these capabilities as fast as possible.\u003c/p\u003e\n\u003ch3 id=\"control-tower-organizations-and-guardrails-at-scale-2\"\u003eControl Tower, Organizations, and Guardrails at Scale\u003c/h3\u003e\n\u003cp\u003eSeveral updates make governance easier to adopt at scale:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eDedicated controls for AWS Control Tower\u003c/strong\u003e without requiring a full Control Tower deployment — you can now use Control Tower guardrails à la carte.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAutomatic enrollment in Control Tower\u003c/strong\u003e — a feature the hosts feel should have existed already.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eRequired tags in Organizations stack policies\u003c/strong\u003e — enforcing tagging standards at the organization level.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAmazon Inspector organization-wide management\u003c/strong\u003e — centralized vulnerability scanning across all accounts.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eBilling transfer for AWS Organizations\u003c/strong\u003e — useful for AWS resellers managing multiple organizations.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eDelete protection for CloudWatch Log Groups\u003c/strong\u003e — a small but important safeguard.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eMattias says plainly: everyone should use Control Tower.\u003c/p\u003e\n\u003ch3 id=\"mcp-servers-and-awss-evolving-ai-approach-1\"\u003eMCP Servers and AWS\u0026rsquo;s Evolving AI Approach\u003c/h3\u003e\n\u003cp\u003eThe conversation shifts to the \u003cstrong\u003epublic preview of AWS MCP (Model Context Protocol) servers\u003c/strong\u003e. Unlike traditional locally-hosted MCP servers that proxy LLM requests to API calls, AWS is taking a different approach with remote, fully managed MCP servers hosted on AWS infrastructure. These allow AI agents and AI-native IDEs to interact with AWS services over HTTPS without running anything locally.\u003c/p\u003e\n\u003cp\u003eAWS launched four managed MCP servers — AWS, EKS, ECS, and SageMaker — that consolidate capabilities like AWS documentation access, API execution across 15,000+ AWS APIs, and pre-built agent workflows. However, the IAM model is still being worked out: you currently need separate permissions to call the MCP server and to perform the underlying AWS actions it invokes. The hosts treat this as interesting but still evolving.\u003c/p\u003e\n\u003ch3 id=\"boris-ai-for-aws-change-awareness-2\"\u003eBoris: AI for AWS Change Awareness\u003c/h3\u003e\n\u003cp\u003eToward the end of the episode, Andrey reveals a personal project: \u003cstrong\u003eBoris\u003c/strong\u003e (\u003ca href=\"https://www.getboris.ai/\"\u003egetboris.ai\u003c/a\u003e), an AI-powered DevOps teammate he has been building. Boris connects to the systems an engineering team already uses and provides evidence-based answers and operational automation.\u003c/p\u003e\n\u003cp\u003eThe specific feature Andrey has been working on takes the AWS RSS feed — where new announcements land daily — and cross-references it against what a customer actually has running in their AWS Organization. Instead of manually sifting through hundreds of releases, Boris sends a digest highlighting only the announcements relevant to your environment and explaining how you would benefit.\u003c/p\u003e\n\u003cp\u003eMattias immediately connects this to the same problem in security: teams are overwhelmed by the constant flow of feature updates and vulnerability news. Having an AI that filters and contextualizes that information is, in his words, \u0026ldquo;brilliant.\u0026rdquo;\u003c/p\u003e\n\u003cp\u003eAndrey also announces that Boris has been accepted into the \u003cstrong\u003eTehnopol AI Accelerator\u003c/strong\u003e in Tallinn, Estonia — a program run by the Tehnopol Science and Business Park that supports early-stage AI startups — selected from more than 100 companies.\u003c/p\u003e\n\u003ch2 id=\"highlights-2\"\u003eHighlights\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eSetting expectations:\u003c/strong\u003e \u0026ldquo;The selection of announcements smells more like security only. If security is your thing, stay tuned in. If it\u0026rsquo;s not really, well, it\u0026rsquo;s still interesting, but I\u0026rsquo;m just trying to manage your possible disappointment.\u0026rdquo;\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eOn VPC encryption control:\u003c/strong\u003e The hosts describe how proving internal encryption used to require traffic mirroring, Wireshark, and significant pain — this feature makes it a configuration toggle.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eOn public S3 buckets:\u003c/strong\u003e \u0026ldquo;In 2026 there is no good reason to have a public S3 bucket. Just turn it on and forget about it.\u0026rdquo;\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eOn production data for testing:\u003c/strong\u003e When someone floats using masked production data for testing — \u0026ldquo;Maybe don\u0026rsquo;t do that.\u0026rdquo;\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eOn detection over prevention:\u003c/strong\u003e \u0026ldquo;You cannot really prevent something from happening in your environment. What you can control is how you react when it\u0026rsquo;s going to happen. Detection is really where I put effort.\u0026rdquo;\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eOn Boris:\u003c/strong\u003e When Andrey describes how Boris watches the AWS release feed and tells you which announcements actually matter for your environment, Mattias\u0026rsquo;s reaction: \u0026ldquo;This is brilliant.\u0026rdquo;\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eOn getting started with AWS security:\u003c/strong\u003e \u0026ldquo;If you are a startup building on AWS and compliance is important, it\u0026rsquo;s quite easy to get it working. All the building blocks and tools are available for you to do the right things.\u0026rdquo;\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"resources-2\"\u003eResources\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://aws.amazon.com/blogs/aws/introducing-vpc-encryption-controls-enforce-encryption-in-transit-within-and-across-vpcs-in-a-region/\"\u003eIntroducing VPC Encryption Controls\u003c/a\u003e — AWS blog post explaining monitor and enforce modes for VPC encryption in transit.\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://aws.amazon.com/security/post-quantum-cryptography/\"\u003eAWS Post-Quantum Cryptography\u003c/a\u003e — AWS overview of post-quantum cryptography migration, including ML-KEM support across S3, ALB, NLB, KMS, and Private CA.\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://aws.amazon.com/about-aws/whats-new/2025/11/amazon-s3-block-public-access-organization-level-enforcement/\"\u003eS3 Block Public Access Organization-Level Enforcement\u003c/a\u003e — Announcement for enforcing S3 public access blocks across an entire AWS Organization.\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://aws.amazon.com/blogs/containers/streamline-container-image-signatures-with-amazon-ecr-managed-signing/\"\u003eAmazon ECR Managed Container Image Signing\u003c/a\u003e — Guide to setting up managed image signing with ECR and AWS Signer.\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://aws.amazon.com/blogs/aws/amazon-guardduty-adds-extended-threat-detection-for-amazon-ec2-and-amazon-ecs/\"\u003eGuardDuty Extended Threat Detection for EC2 and ECS\u003c/a\u003e — How GuardDuty uses AI/ML to correlate security signals and detect multi-stage attacks on compute workloads.\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://aws.amazon.com/blogs/database/protect-sensitive-data-with-dynamic-data-masking-for-amazon-aurora-postgresql/\"\u003eDynamic Data Masking for Aurora PostgreSQL\u003c/a\u003e — How to configure column-level data masking with the pg_columnmask extension.\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://aws.amazon.com/blogs/security/understanding-iam-for-managed-aws-mcp-servers/\"\u003eUnderstanding IAM for Managed AWS MCP Servers\u003c/a\u003e — AWS Security Blog post explaining the IAM permission model for remote MCP servers.\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://www.getboris.ai/\"\u003eB.O.R.I.S — Your AI DevOps Teammate\u003c/a\u003e — The AI-powered product discussed in the episode that tracks AWS announcements and matches them to your environment.\u003c/li\u003e\n\u003c/ul\u003e"},{"title":"#92 - From System Initiative to SWAMP: Agent-Native Infra with Paul Stack","date_published":"2026-02-20T20:34:25Z","date_modified":"2026-02-20T20:34:25Z","id":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/092-from-system-initiative-to-swamp-agent-native-infra-with-paul-stack/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/092-from-system-initiative-to-swamp-agent-native-infra-with-paul-stack/","authors":[{"name":"DevSecOps Talks"}],"content_html":"\u003cp\u003eWhat can you automate with SWAMP today, from AWS to a Proxmox home lab? How do skills, scripts, and reusable workflows plug into your stack? Could this be your agent’s missing guardrails?\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/company/devsecops-talks/\"\u003eDiscuss the episode or ask us anything on LinkedIn\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"single_player_container\"\u003e\n   \u003ciframe\n     title=\"DEVSECOPS Talks #92 - From System Initiative to SWAMP: Agent-Native Infra with Paul Stack\"\n     height=\"122\"\n     width=\"100%\"\n     style=\"border: none;\"\n     scrolling=\"no\"\n     data-name=\"pb-iframe-player\"\n     src=\"https://www.podbean.com/media/player/egzxx-1a4fe21-pb?from=yiiadmin\u0026download=1\u0026version=1\u0026skin=1\u0026btn-skin=107\u0026auto=0\u0026download=1\u0026pbad=1\"\n   \u003e\u003c/iframe\u003e\n \u003c/div\u003e\n\n\u003chr\u003e\n\u003cdiv style=\"position: relative; padding-bottom: 56.25%; height: 0; overflow: hidden;\"\u003e\n      \u003ciframe allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share; fullscreen\" loading=\"eager\" referrerpolicy=\"strict-origin-when-cross-origin\" src=\"https://www.youtube.com/embed/XTM__-Ai4Zw?autoplay=0\u0026amp;controls=1\u0026amp;end=0\u0026amp;loop=0\u0026amp;mute=0\u0026amp;start=0\" style=\"position: absolute; top: 0; left: 0; width: 100%; height: 100%; border:0;\" title=\"YouTube video\"\u003e\u003c/iframe\u003e\n    \u003c/div\u003e\n\n\u003ch2 id=\"summary\"\u003eSummary\u003c/h2\u003e\n\u003cp\u003eSystem Initiative has undergone a dramatic transformation: from a visual SaaS infrastructure platform with 17 employees to \u003cstrong\u003eSwamp\u003c/strong\u003e, a fully open-source CLI built for AI agents, maintained by a five-person team whose initials literally spell the product name. Paul Stack returns for his third appearance on the show to explain why the old model failed — and why handing an AI agent raw CLI access to your cloud is, as Andrey puts it, just \u0026ldquo;console-clicking in the terminal.\u0026rdquo; The conversation gets sharp when the hosts push on what problem Swamp actually solves, whether ops teams are becoming the next bottleneck in AI-era delivery, and why Paul believes the right move is not replacing Terraform but giving AI a structured system it can reason about. Paul also drops a parting bombshell: he hasn\u0026rsquo;t written a single line of code in four weeks.\u003c/p\u003e\n\u003ch2 id=\"key-topics\"\u003eKey Topics\u003c/h2\u003e\n\u003ch3 id=\"system-initiatives-pivot-from-visual-editor-to-ai-first-cli\"\u003eSystem Initiative\u0026rsquo;s pivot from visual editor to AI-first CLI\u003c/h3\u003e\n\u003cp\u003ePaul Stack explains that System Initiative spent over five years iterating on a visual infrastructure tool where users could drag, drop, and connect systems. Despite the ambition, the team eventually concluded that visual composition was too slow, too cumbersome, and too alien for practitioners accustomed to code, artifacts, and reviewable changes.\u003c/p\u003e\n\u003cp\u003eThe shift started in summer 2025 when Paul spiked a public OpenAPI-spec API. A customer then built an early MCP (Model Context Protocol) server on top of it — a prototype that worked but had no thought given to token usage or tool abstraction. System Initiative responded by building its own official MCP server and pairing it with a CLI. The results were dramatically better: customers could iterate easily from the command line or through AI coding tools like Claude Code.\u003c/p\u003e\n\u003cp\u003eBy Christmas 2025 the writing was on the wall. The CLI-plus-agent approach was producing better outcomes, while the company was still carrying hundreds of thousands of lines of code for a distributed SaaS platform built for a previous product direction. In mid-January 2026, the company made the call to rethink everything from first principles.\u003c/p\u003e\n\u003ch3 id=\"the-team-behind-the-name\"\u003eThe team behind the name\u003c/h3\u003e\n\u003cp\u003eThe restructuring was painful. System Initiative went from 17 people to five. Paul explains the reasoning candidly: when you don\u0026rsquo;t know what the tool is going to be, keeping a large team around is unfair to them, bad for their careers, and expensive. The five who stayed were the CEO, VP of Business, COO, Paul (who ran product), and Nick Steinmetz, the head of infrastructure — who also happened to be System Initiative\u0026rsquo;s most active internal user, having used the platform to build System Initiative itself.\u003c/p\u003e\n\u003cp\u003eThose five people\u0026rsquo;s initials spell \u003cstrong\u003eSWAMP\u003c/strong\u003e. The name was unintentional but stuck — and Paul notes with a grin that if they ever remove the \u0026ldquo;P,\u0026rdquo; it becomes \u0026ldquo;SWAM,\u0026rdquo; so he\u0026rsquo;s safe even if he leaves. Beyond the joke, the name fits: Swamp stores operational data in a local \u003ccode\u003e.swamp/\u003c/code\u003e directory — not a neatly formatted data lake, but a structured store that AI agents can pull from to reason about infrastructure state and history.\u003c/p\u003e\n\u003ch3 id=\"why-raw-ai-agent-access-to-infrastructure-is-dangerous\"\u003eWhy raw AI agent access to infrastructure is dangerous\u003c/h3\u003e\n\u003cp\u003eA major theme in the conversation is that letting an AI agent operate infrastructure directly — through the AWS CLI or raw API calls — is fundamentally unreliable. Andrey lays out the problem clearly: this kind of interaction is equivalent to clicking around the cloud console, just automated through a terminal. It is not repeatable, not reviewable, and inherits the non-deterministic behavior of LLMs. If the agent\u0026rsquo;s context window fills up, it starts to forget earlier decisions and improvises — a terrifying prospect for production infrastructure.\u003c/p\u003e\n\u003cp\u003eWhat made System Initiative\u0026rsquo;s earlier MCP-based direction compelling, in Andrey\u0026rsquo;s view, was the combination of \u003cstrong\u003eguardrails, repeatability, and human review\u003c/strong\u003e. The agent generates a structured specification, a human reviews it, and only then is it applied. Paul agrees and calls this the \u0026ldquo;agentic loop with the human loop\u0026rdquo; — the strongest pattern they found.\u003c/p\u003e\n\u003ch3 id=\"token-costs-and-the-case-for-local-first-architecture\"\u003eToken costs and the case for local-first architecture\u003c/h3\u003e\n\u003cp\u003ePaul shares a hard-won lesson from building MCP integrations: a poorly designed MCP server burns enormous amounts of tokens and creates unnecessary costs for users. He spent three weeks in December reworking the server to use progressive context reveal rather than flooding the model with data. Even so, the fundamental problem with a SaaS-first architecture remained — constantly transmitting context between a central API and the user\u0026rsquo;s agent was expensive regardless of optimization.\u003c/p\u003e\n\u003cp\u003eThat experience pushed the team toward a local-first design. Swamp keeps data on the user\u0026rsquo;s machine, close to where the agent operates, giving AI the context it needs without the round-trip overhead and cost of a remote service.\u003c/p\u003e\n\u003ch3 id=\"what-swamp-actually-is\"\u003eWhat Swamp actually is\u003c/h3\u003e\n\u003cp\u003eSwamp is a \u003cstrong\u003egeneral-purpose, open-source CLI automation tool\u003c/strong\u003e — not just another infrastructure-as-code framework. Its core building blocks are:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eModels\u003c/strong\u003e: typed schemas with explicit inputs, outputs, and methods. Unlike traditional IaC resource definitions limited to CRUD operations, Swamp models can have methods like \u003ccode\u003eanalyze\u003c/code\u003e or \u003ccode\u003edo_next\u003c/code\u003e, with the procedural logic living inside the method itself.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eWorkflows\u003c/strong\u003e: the orchestration layer that interacts with APIs, CLIs, or any external system. Workflows take inputs, can be composed (a workflow can orchestrate other workflows), and produce artifacts that the AI agent can inspect over time.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eSkills\u003c/strong\u003e: Claude Code markdown files and shell scripts that teach the AI agent how to build models and workflows within Swamp\u0026rsquo;s architecture.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eCritically, Swamp ships with \u003cstrong\u003ezero built-in models\u003c/strong\u003e — no pre-packaged AWS EC2, VPC, or GCP resource definitions. Instead, the AI agent uses installed skills to generate models on the fly. Paul describes a user who joined the Discord that very morning, asked Swamp to create a schema for managing Let\u0026rsquo;s Encrypt certificates, and it worked on the first attempt without writing any code.\u003c/p\u003e\n\u003cp\u003eNick Steinmetz provides another example: he manages his homelab Proxmox hypervisor entirely through Swamp — creating and starting VMs, inspecting hypervisor state, and monitoring utilization. He recently connected it to Discord so friends can run commands like \u003ccode\u003e@swamp create vm\u003c/code\u003e to spin up Minecraft and gaming servers on demand.\u003c/p\u003e\n\u003ch3 id=\"how-swamp-fits-with-ai-coding-tools\"\u003eHow Swamp fits with AI coding tools\u003c/h3\u003e\n\u003cp\u003eThe hosts spend significant time pinning down where Swamp sits relative to tools like Claude Code, bash access, and existing automation. Paul is clear: Swamp is \u003cstrong\u003enot\u003c/strong\u003e an AI wrapper or chatbot. It is a structured runtime that gives agents guardrails and reusable patterns.\u003c/p\u003e\n\u003cp\u003eMattias works through several analogies to help frame it — is it like n8n or Zapier for the CLI? A CLI-based Jenkins where jobs are agents? Paul settles on this: it is a workflow engine driven by typed models, where data can be chained between steps using \u003ca href=\"https://cel.dev/\"\u003eCEL (Common Expression Language)\u003c/a\u003e expressions — the same dot-notation referencing used in Kubernetes API declarations. A simple example: create a VPC in step one, then reference \u003ccode\u003eVPC.resource.attributes.vpcid\u003c/code\u003e as input to a subnet model in step two.\u003c/p\u003e\n\u003cp\u003eIn Paul\u0026rsquo;s personal workflow, he uses Claude Code to generate models and workflows, checks them into Git for peer review, and then runs them manually or through CI at a time of his choosing. He has explicitly configured Claude with a permission deny on \u003ccode\u003eworkflow run\u003c/code\u003e — the agent helps build automation but never executes it. The same CLI works whether a person or an agent runs it; the difference is timing and approval.\u003c/p\u003e\n\u003ch3 id=\"reusability-composition-and-terraform-interop\"\u003eReusability, composition, and Terraform interop\u003c/h3\u003e\n\u003cp\u003eSwamp workflows are parameterized and reusable across environments. If they grow unwieldy, workflows can orchestrate other workflows, collect outputs, and manage success conditions — similar to GitHub Actions calling other actions.\u003c/p\u003e\n\u003cp\u003ePaul also demonstrates that Swamp can sit alongside existing tooling rather than replacing it. In a live Discord session, he built infrastructure models in Swamp and then asked the AI agent to generate the equivalent Terraform configuration. Because the agent had typed models with explicit relationships, it produced correct Terraform with proper resource dependencies. This positions Swamp less as a replacement mandate and more as a reasoning and control layer that can output to whatever format teams already use.\u003c/p\u003e\n\u003cp\u003eWhen one of the hosts compares Swamp to general build systems like Gradle, Paul draws a key distinction: traditional tools were designed for humans to write, review, and debate. Swamp is designed for AI agents to inspect and operate within. He references Anton Babenko\u0026rsquo;s widely-used \u003ccode\u003eterraform-aws-vpc\u003c/code\u003e module — with its 237+ input variables — as an example of a human-centric design that agents struggle with due to version dependencies, module structure complexity, and stylistic decisions baked in over years. Swamp instead provides the agent with structured context, explicit typing, and historical artifacts it can query.\u003c/p\u003e\n\u003ch3 id=\"open-source-agpl-v3-and-monetization\"\u003eOpen source, AGPL v3, and monetization\u003c/h3\u003e\n\u003cp\u003ePaulina asks the natural question: if Swamp is fully open source under AGPL v3, how does the company make money?\u003c/p\u003e\n\u003cp\u003ePaul is candid that monetization is not the immediate priority — the focus is building a tool that resonates with users first. But he outlines a potential model: a marketplace-style ecosystem where users can publish their own models and workflows, while System Initiative offers supported, maintained, and paid-for versions of commonly needed building blocks. He draws a loose comparison to Docker Hub\u0026rsquo;s model of community images alongside official ones.\u003c/p\u003e\n\u003cp\u003eThe deeper argument is strategic: Paul believes there is \u003cstrong\u003eno longer a durable moat in software\u003c/strong\u003e. If users dislike a tool today, AI makes it increasingly feasible to build their own. Rather than trying to control all schemas and code, the team wants to make Swamp so extensible that users build on top of it rather than walking away from it.\u003c/p\u003e\n\u003ch3 id=\"are-ops-teams-becoming-the-next-bottleneck\"\u003eAre ops teams becoming the next bottleneck?\u003c/h3\u003e\n\u003cp\u003ePaul argues that software development productivity is accelerating so fast with AI that ops teams risk becoming the next bottleneck — echoing earlier industry transitions from physical servers to cloud and from manual provisioning to infrastructure as code. Development teams can now move at a pace that traditional infrastructure workflows cannot match.\u003c/p\u003e\n\u003cp\u003eAndrey agrees with the premise but pushes back on where the bottleneck actually sits today. In his experience — spending \u0026ldquo;day and night burning tokens\u0026rdquo; on AI-assisted development — the real constraint is \u003cstrong\u003etesting\u003c/strong\u003e, not deployment. He describes pipelines that can go from idea to pull request automatically, but stall without a strong test harness and end-to-end validation. Without sufficient tests, you never even reach the deployment phase.\u003c/p\u003e\n\u003cp\u003ePaul accepts the framing and says the goal of Swamp is to strip away lower-value friction — fighting with file layouts, naming conventions, writing boilerplate models — so teams can invest their time where engineering rigor still matters most: testing, validation, and production safety.\u003c/p\u003e\n\u003ch3 id=\"swamp-as-an-addition-not-a-forced-replacement\"\u003eSwamp as an addition, not a forced replacement\u003c/h3\u003e\n\u003cp\u003ePaul closes with an important positioning point: Swamp does not require teams to discard their Terraform, Pulumi, or existing infrastructure investments. It can be introduced alongside current tooling to interrogate infrastructure, validate what existing IaC does, and extend automation in AI-native ways. The extensibility is the point — users control when things run, what models to build, and how to integrate with their existing stack.\u003c/p\u003e\n\u003ch2 id=\"highlights\"\u003eHighlights\u003c/h2\u003e\n\u003ch3 id=\"giving-an-agent-raw-cli-access-to-your-cloud-is-basically-console-clicking-in-the-terminal--andrey\"\u003e\u0026ldquo;Giving an agent raw CLI access to your cloud is basically console-clicking in the terminal.\u0026rdquo; — Andrey\u003c/h3\u003e\n\u003cp\u003eAndrey challenges the assumption that AI-driven infrastructure is automatically safer. If an agent is just shelling out to the AWS CLI, the result may be fast — but it is non-deterministic, non-repeatable, and forget-prone once the context window fills up.\u003c/p\u003e\n\u003cp\u003eThe future of infra automation needs guardrails before it needs speed. Listen to hear why structured workflows beat flashy demos.\u003c/p\u003e\n\u003ch3 id=\"the-best-loop-was-the-agentic-loop-with-the-human-loop--paul-stack\"\u003e\u0026ldquo;The best loop was the agentic loop with the human loop.\u0026rdquo; — Paul Stack\u003c/h3\u003e\n\u003cp\u003eThe breakthrough was not autonomous infrastructure execution. It was letting the AI generate structured specs while humans stay in charge of review and execution. Paul even blocks Claude Code from running workflows directly on his machine.\u003c/p\u003e\n\u003cp\u003eIf \u0026ldquo;human in the loop\u0026rdquo; sounds conservative, this episode makes the case that it is the only production-safe pattern we have. Listen for the full argument.\u003c/p\u003e\n\u003ch3 id=\"there-is-no-longer-a-moat-in-software--paul-stack\"\u003e\u0026ldquo;There is no longer a moat in software.\u0026rdquo; — Paul Stack\u003c/h3\u003e\n\u003cp\u003ePaul argues that AI has changed the economics of building software so fundamentally that no team can rely on implementation complexity as a competitive advantage. If users dislike your tool, they can build their own — faster than ever before.\u003c/p\u003e\n\u003cp\u003eThat belief is why Swamp is open source, extensible, and ships with zero built-in models. Listen for a candid take on product strategy when anyone can clone your work.\u003c/p\u003e\n\u003ch3 id=\"ops-teams-are-going-to-become-the-bottlenecks-that-we-once-were--paul-stack\"\u003e\u0026ldquo;Ops teams are going to become the bottlenecks that we once were.\u0026rdquo; — Paul Stack\u003c/h3\u003e\n\u003cp\u003eAs development velocity explodes with AI, Paul warns that infrastructure teams risk slowing everything down — the same pattern that played out in the shifts from physical servers to cloud and from cloud to IaC.\u003c/p\u003e\n\u003cp\u003eAndrey fires back: the real bottleneck today is testing, not deployment. Listen for a sharp debate on where delivery pipelines are actually stuck.\u003c/p\u003e\n\u003ch3 id=\"i-havent-written-a-single-line-of-code-in-four-weeks--paul-stack\"\u003e\u0026ldquo;I haven\u0026rsquo;t written a single line of code in four weeks.\u0026rdquo; — Paul Stack\u003c/h3\u003e\n\u003cp\u003ePaul reveals that the entire Swamp repository is AI-generated, with four machines running in parallel to churn out plans and implementations — including customer feature requests. The team teases a future episode to compare notes on AI-driven development workflows.\u003c/p\u003e\n\u003cp\u003eIf that claim doesn\u0026rsquo;t make you want to hear the follow-up, nothing will.\u003c/p\u003e\n\u003ch2 id=\"resources\"\u003eResources\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003e\u003ca href=\"https://github.com/systeminit/swamp\"\u003eSwamp CLI on GitHub\u003c/a\u003e\u003c/strong\u003e — The open-source, AGPL v3 licensed CLI tool discussed in the episode. Models, workflows, and a local \u003ccode\u003e.swamp/\u003c/code\u003e data directory designed for AI agent interaction.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003e\u003ca href=\"https://www.systeminit.com/\"\u003eSystem Initiative\u003c/a\u003e\u003c/strong\u003e — The company behind Swamp, originally known for its visual infrastructure platform, now pivoted to AI-native CLI automation.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003e\u003ca href=\"https://modelcontextprotocol.io/\"\u003eModel Context Protocol (MCP)\u003c/a\u003e\u003c/strong\u003e — Anthropic\u0026rsquo;s open protocol for connecting AI models to external tools and data sources. Paul discusses the challenges of building MCP servers that are token-efficient.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003e\u003ca href=\"https://claude.ai/download\"\u003eClaude Code\u003c/a\u003e\u003c/strong\u003e — Anthropic\u0026rsquo;s agentic coding tool that runs in the terminal. Used throughout the episode as the primary AI agent interface for Swamp workflows.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003e\u003ca href=\"https://cel.dev/\"\u003eCEL — Common Expression Language\u003c/a\u003e\u003c/strong\u003e — The expression language Swamp uses for chaining data between workflow steps, similar to how Kubernetes uses it for API declarations and validation policies.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003e\u003ca href=\"https://www.proxmox.com/\"\u003eProxmox Virtual Environment\u003c/a\u003e\u003c/strong\u003e — The open-source hypervisor platform that Nick Steinmetz manages entirely through Swamp in his homelab, including Discord-driven VM creation.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003e\u003ca href=\"https://github.com/terraform-aws-modules/terraform-aws-vpc\"\u003eterraform-aws-modules/vpc\u003c/a\u003e\u003c/strong\u003e — Anton Babenko\u0026rsquo;s widely-used Terraform VPC module, referenced by Paul as an example of human-centric IaC design with 237+ inputs that agents struggle to navigate.\u003c/p\u003e\n\u003c/li\u003e\n\u003c/ul\u003e"},{"title":"#91 - January security roundup: CVSS 10 in n8n, self-hosted AI scares, and nonstop patching","date_published":"2026-02-04T22:41:06Z","date_modified":"2026-02-04T22:41:06Z","id":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/091-january-security-roundup-cvss-10-in-n8n-self-hosted-ai-scares-and-nonstop-patching/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/091-january-security-roundup-cvss-10-in-n8n-self-hosted-ai-scares-and-nonstop-patching/","authors":[{"name":"DevSecOps Talks"}],"content_html":"\u003cp\u003eWe kick off with a CVSS 10 in n8n, then look at self-hosted AI assistants with weak defaults and prompt injection risks. Are your API keys, inbox, and drives safe if a bot is open to the web? What should you rotate, patch, and hide behind a VPN?\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/company/devsecops-talks/\"\u003eDiscuss the episode or ask us anything on LinkedIn\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"single_player_container\"\u003e\n   \u003ciframe\n     title=\"DEVSECOPS Talks #91 - January security roundup: CVSS 10 in n8n, self-hosted AI scares, and nonstop patching\"\n     height=\"122\"\n     width=\"100%\"\n     style=\"border: none;\"\n     scrolling=\"no\"\n     data-name=\"pb-iframe-player\"\n     src=\"https://www.podbean.com/media/player/tngzd-1a39323-pb?from=yiiadmin\u0026download=1\u0026version=1\u0026skin=1\u0026btn-skin=107\u0026auto=0\u0026download=1\u0026pbad=1\"\n   \u003e\u003c/iframe\u003e\n \u003c/div\u003e\n\n\u003chr\u003e\n\u003cdiv style=\"position: relative; padding-bottom: 56.25%; height: 0; overflow: hidden;\"\u003e\n      \u003ciframe allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share; fullscreen\" loading=\"eager\" referrerpolicy=\"strict-origin-when-cross-origin\" src=\"https://www.youtube.com/embed/IknJjyL4A6c?autoplay=0\u0026amp;controls=1\u0026amp;end=0\u0026amp;loop=0\u0026amp;mute=0\u0026amp;start=0\" style=\"position: absolute; top: 0; left: 0; width: 100%; height: 100%; border:0;\" title=\"YouTube video\"\u003e\u003c/iframe\u003e\n    \u003c/div\u003e\n\n\u003ch2 id=\"notes\"\u003eNotes\u003c/h2\u003e"},{"title":"#90 - K8s vs Managed Services: Cost, Lock-In, and Reality","date_published":"2025-12-08T15:40:03Z","date_modified":"2025-12-08T15:40:03Z","id":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/090-k8s-vs-managed-services-cost-lock-in-and-reality/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/090-k8s-vs-managed-services-cost-lock-in-and-reality/","authors":[{"name":"DevSecOps Talks"}],"content_html":"\u003cp\u003eWe get into K8s vs native orchestrators. Do you still need Kubernetes when managed services cover most needs? How do cost, lock-in, and team skills change the choice? Expect a heated debate.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/company/devsecops-talks/\"\u003eDiscuss the episode or ask us anything on LinkedIn\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"single_player_container\"\u003e\n   \u003ciframe\n     title=\"DEVSECOPS Talks #90 - K8s vs Managed Services: Cost, Lock-In, and Reality\"\n     height=\"122\"\n     width=\"100%\"\n     style=\"border: none;\"\n     scrolling=\"no\"\n     data-name=\"pb-iframe-player\"\n     src=\"https://www.podbean.com/media/player/zeq99-19e4e41-pb?from=yiiadmin\u0026download=1\u0026version=1\u0026skin=1\u0026btn-skin=107\u0026auto=0\u0026download=1\u0026pbad=1\"\n   \u003e\u003c/iframe\u003e\n \u003c/div\u003e\n\n\u003chr\u003e\n\u003cdiv style=\"position: relative; padding-bottom: 56.25%; height: 0; overflow: hidden;\"\u003e\n      \u003ciframe allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share; fullscreen\" loading=\"eager\" referrerpolicy=\"strict-origin-when-cross-origin\" src=\"https://www.youtube.com/embed/MC9WIvJcQdY?autoplay=0\u0026amp;controls=1\u0026amp;end=0\u0026amp;loop=0\u0026amp;mute=0\u0026amp;start=0\" style=\"position: absolute; top: 0; left: 0; width: 100%; height: 100%; border:0;\" title=\"YouTube video\"\u003e\u003c/iframe\u003e\n    \u003c/div\u003e\n\n\u003ch2 id=\"notes\"\u003eNotes\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://www.linkedin.com/in/markshine/\"\u003eMark Shine\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e"},{"title":"#88 - EU Compliance 101: DSA, MiCA explained","date_published":"2025-12-08T15:15:15Z","date_modified":"2025-12-08T15:15:15Z","id":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/088-eu-compliance-101-dsa-mica-explained/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/088-eu-compliance-101-dsa-mica-explained/","authors":[{"name":"DevSecOps Talks"}],"content_html":"\u003cp\u003eWhich parts of AI Act, NIS2, DORA, and DSA overlap so you can cover more with less? What basics raise your baseline fast: central logs, backups, risk assessments, and human-in-the-loop governance? Could a simple mailing list make incident comms painless?\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/company/devsecops-talks/\"\u003eDiscuss the episode or ask us anything on LinkedIn\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"single_player_container\"\u003e\n   \u003ciframe\n     title=\"DEVSECOPS Talks #88 - EU Compliance 101: DSA, MiCA explained\"\n     height=\"122\"\n     width=\"100%\"\n     style=\"border: none;\"\n     scrolling=\"no\"\n     data-name=\"pb-iframe-player\"\n     src=\"https://www.podbean.com/media/player/figd3-19e4d92-pb?from=yiiadmin\u0026download=1\u0026version=1\u0026skin=1\u0026btn-skin=107\u0026auto=0\u0026download=1\u0026pbad=1\"\n   \u003e\u003c/iframe\u003e\n \u003c/div\u003e\n\n\u003chr\u003e\n\u003cdiv style=\"position: relative; padding-bottom: 56.25%; height: 0; overflow: hidden;\"\u003e\n      \u003ciframe allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share; fullscreen\" loading=\"eager\" referrerpolicy=\"strict-origin-when-cross-origin\" src=\"https://www.youtube.com/embed/yIRMOKuVFYc?autoplay=0\u0026amp;controls=1\u0026amp;end=0\u0026amp;loop=0\u0026amp;mute=0\u0026amp;start=0\" style=\"position: absolute; top: 0; left: 0; width: 100%; height: 100%; border:0;\" title=\"YouTube video\"\u003e\u003c/iframe\u003e\n    \u003c/div\u003e\n\n\u003ch2 id=\"notes\"\u003eNotes\u003c/h2\u003e"},{"title":"#87 - EU Compliance 101: AI Act, DORA, NIS2 explained","date_published":"2025-12-08T13:29:39Z","date_modified":"2025-12-08T13:29:39Z","id":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/087-eu-compliance-101-ai-act-dora-nis2-explained/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/087-eu-compliance-101-ai-act-dora-nis2-explained/","authors":[{"name":"DevSecOps Talks"}],"content_html":"\u003cp\u003eWant a quick map of EU compliance for engineers? How do you classify AI by risk and tell users when AI is used? When do you send a 24-hour heads-up and a one-month report after an incident? Does NIS2 make your board liable and your logs mandatory?\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/company/devsecops-talks/\"\u003eDiscuss the episode or ask us anything on LinkedIn\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"single_player_container\"\u003e\n   \u003ciframe\n     title=\"DEVSECOPS Talks #87 - EU Compliance 101: AI Act, DORA, NIS2 explained\"\n     height=\"122\"\n     width=\"100%\"\n     style=\"border: none;\"\n     scrolling=\"no\"\n     data-name=\"pb-iframe-player\"\n     src=\"https://www.podbean.com/media/player/ccd9d-19e4b0f-pb?from=yiiadmin\u0026download=1\u0026version=1\u0026skin=1\u0026btn-skin=107\u0026auto=0\u0026download=1\u0026pbad=1\"\n   \u003e\u003c/iframe\u003e\n \u003c/div\u003e\n\n\u003chr\u003e\n\u003cdiv style=\"position: relative; padding-bottom: 56.25%; height: 0; overflow: hidden;\"\u003e\n      \u003ciframe allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share; fullscreen\" loading=\"eager\" referrerpolicy=\"strict-origin-when-cross-origin\" src=\"https://www.youtube.com/embed/hMigUBdEeho?autoplay=0\u0026amp;controls=1\u0026amp;end=0\u0026amp;loop=0\u0026amp;mute=0\u0026amp;start=0\" style=\"position: absolute; top: 0; left: 0; width: 100%; height: 100%; border:0;\" title=\"YouTube video\"\u003e\u003c/iframe\u003e\n    \u003c/div\u003e\n\n\u003ch2 id=\"notes\"\u003eNotes\u003c/h2\u003e"},{"title":"#86 - MCP plugins: your next security blind spot?","date_published":"2025-11-21T15:49:41Z","date_modified":"2025-11-21T15:49:41Z","id":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/086-mcp-plugins-your-next-security-blind-spot-/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/086-mcp-plugins-your-next-security-blind-spot-/","authors":[{"name":"DevSecOps Talks"}],"content_html":"\u003cp\u003eIs MCP just another server you need to threat model, patch, and monitor? How do you keep users from over-privileged access, block LLM injection, and stop blind spots? We unpack the VentureBeat article - MCP stacks have a 92% exploit probability: How 10 plugins became enterprise security\u0026rsquo;s biggest blind spot\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/company/devsecops-talks/\"\u003eDiscuss the episode or ask us anything on LinkedIn\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"single_player_container\"\u003e\n   \u003ciframe\n     title=\"DEVSECOPS Talks #86 - MCP plugins: your next security blind spot?\"\n     height=\"122\"\n     width=\"100%\"\n     style=\"border: none;\"\n     scrolling=\"no\"\n     data-name=\"pb-iframe-player\"\n     src=\"https://www.podbean.com/media/player/6hszg-19cc7b0-pb?from=yiiadmin\u0026download=1\u0026version=1\u0026skin=1\u0026btn-skin=107\u0026auto=0\u0026download=1\u0026pbad=1\"\n   \u003e\u003c/iframe\u003e\n \u003c/div\u003e\n\n\u003chr\u003e\n\u003cdiv style=\"position: relative; padding-bottom: 56.25%; height: 0; overflow: hidden;\"\u003e\n      \u003ciframe allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share; fullscreen\" loading=\"eager\" referrerpolicy=\"strict-origin-when-cross-origin\" src=\"https://www.youtube.com/embed/YkHx3y2N5FI?autoplay=0\u0026amp;controls=1\u0026amp;end=0\u0026amp;loop=0\u0026amp;mute=0\u0026amp;start=0\" style=\"position: absolute; top: 0; left: 0; width: 100%; height: 100%; border:0;\" title=\"YouTube video\"\u003e\u003c/iframe\u003e\n    \u003c/div\u003e\n\n\u003ch2 id=\"notes\"\u003eNotes\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://venturebeat.com/security/mcp-stacks-have-a-92-exploit-probability-how-10-plugins-became-enterprise\"\u003eArticle\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e"},{"title":"#85 - Is It Time for OpenTofu? Our HashiConf Takeaways","date_published":"2025-10-23T15:33:11+02:00","date_modified":"2025-10-23T15:33:11+02:00","id":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/085-is-it-time-for-opentofu-our-hashiconf-takeaways/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/085-is-it-time-for-opentofu-our-hashiconf-takeaways/","authors":[{"name":"DevSecOps Talks"}],"content_html":"\u003cp\u003eWe break down 10 years of HashiConf and this year\u0026rsquo;s Terraform-heavy news. What do Terraform Actions with Ansible, Stacks GA, and HCP-only features mean for day two work? Is open source getting left behind, and is OpenTofu worth a look?\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/company/devsecops-talks/\"\u003eDiscuss the episode or ask us anything on LinkedIn\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"single_player_container\"\u003e\n   \u003ciframe\n     title=\"DEVSECOPS Talks #85 - Is It Time for OpenTofu? Our HashiConf Takeaways\"\n     height=\"122\"\n     width=\"100%\"\n     style=\"border: none;\"\n     scrolling=\"no\"\n     data-name=\"pb-iframe-player\"\n     src=\"https://www.podbean.com/media/player/qan6d-19a0636-pb?from=yiiadmin\u0026download=1\u0026version=1\u0026skin=1\u0026btn-skin=107\u0026auto=0\u0026download=1\u0026pbad=1\"\n   \u003e\u003c/iframe\u003e\n \u003c/div\u003e\n\n\u003chr\u003e\n\u003cdiv style=\"position: relative; padding-bottom: 56.25%; height: 0; overflow: hidden;\"\u003e\n      \u003ciframe allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share; fullscreen\" loading=\"eager\" referrerpolicy=\"strict-origin-when-cross-origin\" src=\"https://www.youtube.com/embed/UmETTDsiZ5c?autoplay=0\u0026amp;controls=1\u0026amp;end=0\u0026amp;loop=0\u0026amp;mute=0\u0026amp;start=0\" style=\"position: absolute; top: 0; left: 0; width: 100%; height: 100%; border:0;\" title=\"YouTube video\"\u003e\u003c/iframe\u003e\n    \u003c/div\u003e\n\n\u003ch2 id=\"notes\"\u003eNotes\u003c/h2\u003e"},{"title":"#84 - AI for DevSecOps: Current Wins and Ongoing Gaps","date_published":"2025-09-30T11:29:28+01:00","date_modified":"2025-09-30T11:29:28+01:00","id":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/084-ai-for-devsecops-current-wins-and-ongoing-gaps/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/084-ai-for-devsecops-current-wins-and-ongoing-gaps/","authors":[{"name":"DevSecOps Talks"}],"content_html":"\u003cp\u003eCan AI really help us build more secure software? What’s working in practice right now, and where do the tools still fall short? Mattias and Paulina share their views.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/company/devsecops-talks/\"\u003eDiscuss the episode or ask us anything on LinkedIn\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"single_player_container\"\u003e\n   \u003ciframe\n     title=\"DEVSECOPS Talks #84 - AI for DevSecOps: Current Wins and Ongoing Gaps\"\n     height=\"122\"\n     width=\"100%\"\n     style=\"border: none;\"\n     scrolling=\"no\"\n     data-name=\"pb-iframe-player\"\n     src=\"https://www.podbean.com/media/player/3dpp6-197cc5a-pb?from=yiiadmin\u0026download=1\u0026version=1\u0026skin=1\u0026btn-skin=107\u0026auto=0\u0026download=1\u0026pbad=1\"\n   \u003e\u003c/iframe\u003e\n \u003c/div\u003e\n\n\u003chr\u003e\n\u003cdiv style=\"position: relative; padding-bottom: 56.25%; height: 0; overflow: hidden;\"\u003e\n      \u003ciframe allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share; fullscreen\" loading=\"eager\" referrerpolicy=\"strict-origin-when-cross-origin\" src=\"https://www.youtube.com/embed/QhHKA5t03zI?autoplay=0\u0026amp;controls=1\u0026amp;end=0\u0026amp;loop=0\u0026amp;mute=0\u0026amp;start=0\" style=\"position: absolute; top: 0; left: 0; width: 100%; height: 100%; border:0;\" title=\"YouTube video\"\u003e\u003c/iframe\u003e\n    \u003c/div\u003e\n\n\u003ch2 id=\"notes\"\u003eNotes\u003c/h2\u003e"},{"title":"#83 - Opentofu Vs Terraform: Where We Are Now With Cole Bittel","date_published":"2025-09-17T14:21:34+01:00","date_modified":"2025-09-17T14:21:34+01:00","id":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/083-opentofu-vs-terraform-where-we-are-now-with-cole-bittel/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/083-opentofu-vs-terraform-where-we-are-now-with-cole-bittel/","authors":[{"name":"DevSecOps Talks"}],"content_html":"\u003cp\u003eIt’s been a while since OpenTofu was released to the public, so we wanted to check in on where it stands today. How is the community adopting it? What’s the public sentiment? And how does it differ from Terraform in terms of features?\u003c/p\u003e\n\u003cp\u003eThis time we’re joined by Cole Bittel, an experienced SRE, platform engineer, and contributor to OpenTofu. He shares his hands-on experience migrating to OpenTofu, and we look into the problems teams face with infrastructure as code and how both Terraform and OpenTofu approach solving them.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/company/devsecops-talks/\"\u003eDiscuss the episode or ask us anything on LinkedIn\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"single_player_container\"\u003e\n   \u003ciframe\n     title=\"DEVSECOPS Talks #83 - Opentofu Vs Terraform: Where We Are Now With Cole Bittel\"\n     height=\"122\"\n     width=\"100%\"\n     style=\"border: none;\"\n     scrolling=\"no\"\n     data-name=\"pb-iframe-player\"\n     src=\"https://www.podbean.com/media/player/6bymu-1969d33-pb?from=yiiadmin\u0026download=1\u0026version=1\u0026skin=1\u0026btn-skin=107\u0026auto=0\u0026download=1\u0026pbad=1\"\n   \u003e\u003c/iframe\u003e\n \u003c/div\u003e\n\n\u003chr\u003e\n\u003cdiv style=\"position: relative; padding-bottom: 56.25%; height: 0; overflow: hidden;\"\u003e\n      \u003ciframe allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share; fullscreen\" loading=\"eager\" referrerpolicy=\"strict-origin-when-cross-origin\" src=\"https://www.youtube.com/embed/SGtzE3YFjqg?autoplay=0\u0026amp;controls=1\u0026amp;end=0\u0026amp;loop=0\u0026amp;mute=0\u0026amp;start=0\" style=\"position: absolute; top: 0; left: 0; width: 100%; height: 100%; border:0;\" title=\"YouTube video\"\u003e\u003c/iframe\u003e\n    \u003c/div\u003e\n\n\u003ch2 id=\"notes\"\u003eNotes\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://www.linkedin.com/in/bittelc/\"\u003eCole Bittel\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e"},{"title":"#82 - Tools, Mcps, And Attack Scenarios","date_published":"2025-08-25T09:43:35+02:00","date_modified":"2025-08-25T09:43:35+02:00","id":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/082-tools-mcps-and-attack-scenarios/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/082-tools-mcps-and-attack-scenarios/","authors":[{"name":"DevSecOps Talks"}],"content_html":"\u003cp\u003eThis time we talk about how LLMs use tools and what the Model Context Protocol (MCP) brings to the table. What are the risks? How can an attacker exploit MCPs? And why are LLMs a bit like grandpas — helpful but forgetful?\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/company/devsecops-talks/\"\u003eDiscuss the episode or ask us anything on LinkedIn\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"single_player_container\"\u003e\n   \u003ciframe\n     title=\"DEVSECOPS Talks #82 - Tools, Mcps, And Attack Scenarios\"\n     height=\"122\"\n     width=\"100%\"\n     style=\"border: none;\"\n     scrolling=\"no\"\n     data-name=\"pb-iframe-player\"\n     src=\"https://www.podbean.com/media/player/xi8uh-1943693-pb?from=yiiadmin\u0026download=1\u0026version=1\u0026skin=1\u0026btn-skin=107\u0026auto=0\u0026download=1\u0026pbad=1\"\n   \u003e\u003c/iframe\u003e\n \u003c/div\u003e\n\n\u003chr\u003e\n\u003cdiv style=\"position: relative; padding-bottom: 56.25%; height: 0; overflow: hidden;\"\u003e\n      \u003ciframe allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share; fullscreen\" loading=\"eager\" referrerpolicy=\"strict-origin-when-cross-origin\" src=\"https://www.youtube.com/embed/uUdUy7BcnW0?autoplay=0\u0026amp;controls=1\u0026amp;end=0\u0026amp;loop=0\u0026amp;mute=0\u0026amp;start=0\" style=\"position: absolute; top: 0; left: 0; width: 100%; height: 100%; border:0;\" title=\"YouTube video\"\u003e\u003c/iframe\u003e\n    \u003c/div\u003e\n\n\u003ch2 id=\"notes\"\u003eNotes\u003c/h2\u003e"},{"title":"#81 - Keeping Secrets Safe","date_published":"2025-06-30T14:43:52+01:00","date_modified":"2025-06-30T14:43:52+01:00","id":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/081-keeping-secrets-safe/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/081-keeping-secrets-safe/","authors":[{"name":"DevSecOps Talks"}],"content_html":"\u003cp\u003eStill pasting tokens into Slack? What types of secrets are at risk, and which tools fit which consumer—humans, CI/CD, or workloads? Where do most teams stumble, and how do you fix it fast? Hear our no-nonsense checklist.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/company/devsecops-talks/\"\u003eDiscuss the episode or ask us anything on LinkedIn\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"single_player_container\"\u003e\n   \u003ciframe\n     title=\"DEVSECOPS Talks #81 - Keeping Secrets Safe\"\n     height=\"122\"\n     width=\"100%\"\n     style=\"border: none;\"\n     scrolling=\"no\"\n     data-name=\"pb-iframe-player\"\n     src=\"https://www.podbean.com/media/player/5426h-18f0719-pb?from=yiiadmin\u0026download=1\u0026version=1\u0026skin=1\u0026btn-skin=107\u0026auto=0\u0026download=1\u0026pbad=1\"\n   \u003e\u003c/iframe\u003e\n \u003c/div\u003e\n\n\u003ch2 id=\"notes\"\u003eNotes\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"\"\u003eVideo version\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e"},{"title":"#80 - Understanding Passkeys: Benefits And Limitations","date_published":"2025-05-21T14:55:39+01:00","date_modified":"2025-05-21T14:55:39+01:00","id":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/080-understanding-passkeys-benefits-and-limitations/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/080-understanding-passkeys-benefits-and-limitations/","authors":[{"name":"DevSecOps Talks"}],"content_html":"\u003cp\u003ePasskeys are gaining attention as a new way to log in without passwords. How do they work, and how do they compare to traditional multi-factor authentication (MFA)? In this episode, we explore the history of passwords, the strengths and weaknesses of common MFA methods, and the potential of passkeys to enhance security. What threats do passkeys mitigate, and what still remain?\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/company/devsecops-talks/\"\u003eDiscuss the episode or ask us anything on LinkedIn\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"single_player_container\"\u003e\n   \u003ciframe\n     title=\"DEVSECOPS Talks #80 - Understanding Passkeys: Benefits And Limitations\"\n     height=\"122\"\n     width=\"100%\"\n     style=\"border: none;\"\n     scrolling=\"no\"\n     data-name=\"pb-iframe-player\"\n     src=\"https://www.podbean.com/media/player/j4puc-18b5381-pb?from=yiiadmin\u0026download=1\u0026version=1\u0026skin=1\u0026btn-skin=107\u0026auto=0\u0026download=1\u0026pbad=1\"\n   \u003e\u003c/iframe\u003e\n \u003c/div\u003e\n\n\u003chr\u003e\n\u003cdiv style=\"position: relative; padding-bottom: 56.25%; height: 0; overflow: hidden;\"\u003e\n      \u003ciframe allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share; fullscreen\" loading=\"eager\" referrerpolicy=\"strict-origin-when-cross-origin\" src=\"https://www.youtube.com/embed/96_P1N1hwZQ?autoplay=0\u0026amp;controls=1\u0026amp;end=0\u0026amp;loop=0\u0026amp;mute=0\u0026amp;start=0\" style=\"position: absolute; top: 0; left: 0; width: 100%; height: 100%; border:0;\" title=\"YouTube video\"\u003e\u003c/iframe\u003e\n    \u003c/div\u003e\n\n\u003ch2 id=\"notes\"\u003eNotes\u003c/h2\u003e"},{"title":"#79 - Going Local: What’S Driving The Move?","date_published":"2025-04-23T21:52:08+01:00","date_modified":"2025-04-23T21:52:08+01:00","id":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/079-going-local-what-s-driving-the-move-/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/079-going-local-what-s-driving-the-move-/","authors":[{"name":"DevSecOps Talks"}],"content_html":"\u003cp\u003eAndrey, Paulina, and Mattias kick off a miniseries on European infrastructure. We talk about infrastructure providers\u0026rsquo; options across Europe, ask what really drives the move away from hyperscalers, and wonder whether the trade-offs make sense for most teams.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/company/devsecops-talks/\"\u003eDiscuss the episode or ask us anything on LinkedIn\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"single_player_container\"\u003e\n   \u003ciframe\n     title=\"DEVSECOPS Talks #79 - Going Local: What’S Driving The Move?\"\n     height=\"122\"\n     width=\"100%\"\n     style=\"border: none;\"\n     scrolling=\"no\"\n     data-name=\"pb-iframe-player\"\n     src=\"https://www.podbean.com/media/player/pd32s-188c305-pb?from=yiiadmin\u0026download=1\u0026version=1\u0026skin=1\u0026btn-skin=107\u0026auto=0\u0026download=1\u0026pbad=1\"\n   \u003e\u003c/iframe\u003e\n \u003c/div\u003e\n\n\u003chr\u003e\n\u003cdiv style=\"position: relative; padding-bottom: 56.25%; height: 0; overflow: hidden;\"\u003e\n      \u003ciframe allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share; fullscreen\" loading=\"eager\" referrerpolicy=\"strict-origin-when-cross-origin\" src=\"https://www.youtube.com/embed/kjDs5ee2YO8?autoplay=0\u0026amp;controls=1\u0026amp;end=0\u0026amp;loop=0\u0026amp;mute=0\u0026amp;start=0\" style=\"position: absolute; top: 0; left: 0; width: 100%; height: 100%; border:0;\" title=\"YouTube video\"\u003e\u003c/iframe\u003e\n    \u003c/div\u003e\n\n\u003ch2 id=\"notes\"\u003eNotes\u003c/h2\u003e"},{"title":"#78 - Building AI Tools For IaC Compliance","date_published":"2025-04-09T17:18:17+01:00","date_modified":"2025-04-09T17:18:17+01:00","id":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/078-building-ai-tools-for-iac-compliance/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/078-building-ai-tools-for-iac-compliance/","authors":[{"name":"DevSecOps Talks"}],"content_html":"\u003cp\u003eIn this guest episode, we chat with Davlet Dzhakishev, co-founder of Cloudgeni, who’s working on an AI-powered approach to fixing compliance issues in IaC. What’s the state of tools in this space? Where does his idea fit in? And how should we think about the relationship between compliance and security?\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/company/devsecops-talks/\"\u003eDiscuss the episode or ask us anything on LinkedIn\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"single_player_container\"\u003e\n   \u003ciframe\n     title=\"DEVSECOPS Talks #78 - Building AI Tools For IaC Compliance\"\n     height=\"122\"\n     width=\"100%\"\n     style=\"border: none;\"\n     scrolling=\"no\"\n     data-name=\"pb-iframe-player\"\n     src=\"https://www.podbean.com/media/player/bu2ah-187708b-pb?from=yiiadmin\u0026download=1\u0026version=1\u0026skin=1\u0026btn-skin=107\u0026auto=0\u0026download=1\u0026pbad=1\"\n   \u003e\u003c/iframe\u003e\n \u003c/div\u003e\n\n\u003ch2 id=\"notes\"\u003eNotes\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://youtu.be/BxkpT7Oiezs\"\u003eYouTube version\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://cloudgeni.ai/\"\u003eCloudgeni\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e"},{"title":"#77 - Chaos Engineering Explained: Part 2","date_published":"2025-03-26T16:35:38Z","date_modified":"2025-03-26T16:35:38Z","id":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/077-chaos-engineering-explained-part-2/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/077-chaos-engineering-explained-part-2/","authors":[{"name":"DevSecOps Talks"}],"content_html":"\u003cp\u003ePart two of our chaos engineering series is here! Join Andrey, Mattias, and Paulina as they talk through practical strategies for chaos engineering. Who should do it? How can you start? And what are the essential prerequisites?\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/company/devsecops-talks/\"\u003eDiscuss the episode or ask us anything on LinkedIn\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"single_player_container\"\u003e\n   \u003ciframe\n     title=\"DEVSECOPS Talks #77 - Chaos Engineering Explained: Part 2\"\n     height=\"122\"\n     width=\"100%\"\n     style=\"border: none;\"\n     scrolling=\"no\"\n     data-name=\"pb-iframe-player\"\n     src=\"https://www.podbean.com/media/player/fwejy-1861ed4-pb?from=yiiadmin\u0026download=1\u0026version=1\u0026skin=1\u0026btn-skin=107\u0026auto=0\u0026download=1\u0026pbad=1\"\n   \u003e\u003c/iframe\u003e\n \u003c/div\u003e\n\n\u003ch2 id=\"notes\"\u003eNotes\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://youtu.be/NQeXLz3ogfs\"\u003eYoutube version\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://github.com/alexei-led/pumba\"\u003ePumba Docker Container\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e"},{"title":"#76 - Chaos Engineering Explained: Part 1","date_published":"2025-03-11T21:46:53Z","date_modified":"2025-03-11T21:46:53Z","id":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/076-chaos-engineering-explained-part-1/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/076-chaos-engineering-explained-part-1/","authors":[{"name":"DevSecOps Talks"}],"content_html":"\u003cp\u003eChaos engineering—is it really chaos, or something more structured? Andrey, Paulina, and Mattias talk about what chaos engineering means, how it started, and why you might already be using it unintentionally.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/company/devsecops-talks/\"\u003eDiscuss the episode or ask us anything on LinkedIn\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"single_player_container\"\u003e\n   \u003ciframe\n     title=\"DEVSECOPS Talks #76 - Chaos Engineering Explained: Part 1\"\n     height=\"122\"\n     width=\"100%\"\n     style=\"border: none;\"\n     scrolling=\"no\"\n     data-name=\"pb-iframe-player\"\n     src=\"https://www.podbean.com/media/player/6xzd4-183a017-pb?from=yiiadmin\u0026download=1\u0026version=1\u0026skin=1\u0026btn-skin=107\u0026auto=0\u0026download=1\u0026pbad=1\"\n   \u003e\u003c/iframe\u003e\n \u003c/div\u003e\n\n\u003chr\u003e\n\u003cdiv style=\"position: relative; padding-bottom: 56.25%; height: 0; overflow: hidden;\"\u003e\n      \u003ciframe allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share; fullscreen\" loading=\"eager\" referrerpolicy=\"strict-origin-when-cross-origin\" src=\"https://www.youtube.com/embed/rcVDIV76b8k?autoplay=0\u0026amp;controls=1\u0026amp;end=0\u0026amp;loop=0\u0026amp;mute=0\u0026amp;start=0\" style=\"position: absolute; top: 0; left: 0; width: 100%; height: 100%; border:0;\" title=\"YouTube video\"\u003e\u003c/iframe\u003e\n    \u003c/div\u003e\n\n\u003ch2 id=\"notes\"\u003eNotes\u003c/h2\u003e"},{"title":"#75 - Learning from the Crisis: Post-Incident Actions","date_published":"2025-02-27T20:43:37Z","date_modified":"2025-02-27T20:43:37Z","id":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/075-learning-from-the-crisis-post-incident-actions/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/075-learning-from-the-crisis-post-incident-actions/","authors":[{"name":"DevSecOps Talks"}],"content_html":"\u003cp\u003eThis is the final episode of our three-part series on incident response. We focus on what happens after the dust settles. How do you learn from what went wrong and avoid repeating it? Tune in to hear our top recommendations.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/company/devsecops-talks/\"\u003eDiscuss the episode or ask us anything on LinkedIn\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"single_player_container\"\u003e\n   \u003ciframe\n     title=\"DEVSECOPS Talks #75 - Learning from the Crisis: Post-Incident Actions\"\n     height=\"122\"\n     width=\"100%\"\n     style=\"border: none;\"\n     scrolling=\"no\"\n     data-name=\"pb-iframe-player\"\n     src=\"https://www.podbean.com/media/player/gapwx-181f3aa-pb?from=yiiadmin\u0026download=1\u0026version=1\u0026skin=1\u0026btn-skin=107\u0026auto=0\u0026download=1\u0026pbad=1\"\n   \u003e\u003c/iframe\u003e\n \u003c/div\u003e\n\n\u003ch2 id=\"notes\"\u003eNotes\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eTBD youtube_id: \u0026ldquo;9T7rWtNiR54\u0026rdquo;\u003c/li\u003e\n\u003c/ul\u003e"},{"title":"#74 - From Preparation To Execution: Handling An Active Incident","date_published":"2025-02-10T16:57:50Z","date_modified":"2025-02-10T16:57:50Z","id":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/074-from-preparation-to-execution-handling-an-active-incident/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/074-from-preparation-to-execution-handling-an-active-incident/","authors":[{"name":"DevSecOps Talks"}],"content_html":"\u003cp\u003eWhat keeps an incident from spiraling out of control? How can you organize your team on the spot? We continue our series on incident response, moving from preparation to real-time actions. Mattias shares key points from his course. Listen to learn how we handle incidents step by step.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/company/devsecops-talks/\"\u003eDiscuss the episode or ask us anything on LinkedIn\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"single_player_container\"\u003e\n   \u003ciframe\n     title=\"DEVSECOPS Talks #74 - From Preparation To Execution: Handling An Active Incident\"\n     height=\"122\"\n     width=\"100%\"\n     style=\"border: none;\"\n     scrolling=\"no\"\n     data-name=\"pb-iframe-player\"\n     src=\"https://www.podbean.com/media/player/nb6sr-17f18c0-pb?from=yiiadmin\u0026download=1\u0026version=1\u0026skin=1\u0026btn-skin=107\u0026auto=0\u0026download=1\u0026pbad=1\"\n   \u003e\u003c/iframe\u003e\n \u003c/div\u003e\n\n\u003chr\u003e\n\u003cdiv style=\"position: relative; padding-bottom: 56.25%; height: 0; overflow: hidden;\"\u003e\n      \u003ciframe allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share; fullscreen\" loading=\"eager\" referrerpolicy=\"strict-origin-when-cross-origin\" src=\"https://www.youtube.com/embed/IJ544d5mZt4?autoplay=0\u0026amp;controls=1\u0026amp;end=0\u0026amp;loop=0\u0026amp;mute=0\u0026amp;start=0\" style=\"position: absolute; top: 0; left: 0; width: 100%; height: 100%; border:0;\" title=\"YouTube video\"\u003e\u003c/iframe\u003e\n    \u003c/div\u003e\n\n\u003ch2 id=\"notes\"\u003eNotes\u003c/h2\u003e"},{"title":"#73 - Incident Response: Key Preparations You Need","date_published":"2025-01-22T15:58:53Z","date_modified":"2025-01-22T15:58:53Z","id":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/073-incident-response-key-preparations-you-need/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/073-incident-response-key-preparations-you-need/","authors":[{"name":"DevSecOps Talks"}],"content_html":"\u003cp\u003eIncident response can be complex, but where do you start? Andrey, Mattias, and Paulina dive into the preparation steps you need to take. Mattias shares his expertise from teaching an incident response course. What’s their top recommendation? Listen and find out!\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/company/devsecops-talks/\"\u003eDiscuss the episode or ask us anything on LinkedIn\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"single_player_container\"\u003e\n   \u003ciframe\n     title=\"DEVSECOPS Talks #73 - Incident Response: Key Preparations You Need\"\n     height=\"122\"\n     width=\"100%\"\n     style=\"border: none;\"\n     scrolling=\"no\"\n     data-name=\"pb-iframe-player\"\n     src=\"https://www.podbean.com/media/player/5hcwg-17c23fc-pb?from=yiiadmin\u0026download=1\u0026version=1\u0026skin=1\u0026btn-skin=107\u0026auto=0\u0026download=1\u0026pbad=1\"\n   \u003e\u003c/iframe\u003e\n \u003c/div\u003e\n\n\u003ch2 id=\"notes\"\u003eNotes\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://www.youtube.com/watch?v=vNu_zPuucGc\"\u003eThis episode on YouTube\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e"},{"title":"#72 - AWS Resource Control Policies (RCPs)","date_published":"2025-01-14T11:38:44Z","date_modified":"2025-01-14T11:38:44Z","id":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/072-aws-rcp/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/072-aws-rcp/","authors":[{"name":"DevSecOps Talks"}],"content_html":"\u003cp\u003eWe are looking into recently announced AWS Resource Control Policies. What are they? How are they different from Service Control Policies? What is a Data Perimeter? Tune in to find out!\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/company/devsecops-talks/\"\u003eDiscuss the episode or ask us anything on LinkedIn\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"single_player_container\"\u003e\n   \u003ciframe\n     title=\"DEVSECOPS Talks #72 - AWS Resource Control Policies (RCPs)\"\n     height=\"122\"\n     width=\"100%\"\n     style=\"border: none;\"\n     scrolling=\"no\"\n     data-name=\"pb-iframe-player\"\n     src=\"https://www.podbean.com/media/player/kh8r7-17ae0de-pb?from=yiiadmin\u0026download=1\u0026version=1\u0026skin=1\u0026btn-skin=107\u0026auto=0\u0026download=1\u0026pbad=1\"\n   \u003e\u003c/iframe\u003e\n \u003c/div\u003e\n\n\u003ch2 id=\"notes\"\u003eNotes\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html\"\u003eRCPs\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://aws.amazon.com/identity/data-perimeters-on-aws/\"\u003eData Perimiter\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e"},{"title":"#71 - Unpacking The Dora Accelerate State Of Devops Report","date_published":"2024-12-20T13:55:37Z","date_modified":"2024-12-20T13:55:37Z","id":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/071-unpacking-the-dora-accelerate-state-of-devops-report/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/071-unpacking-the-dora-accelerate-state-of-devops-report/","authors":[{"name":"DevSecOps Talks"}],"content_html":"\u003cp\u003eIn this episode, Andrey, Mattias, and Paulina break down the new DORA Accelerate State of DevOps report. What’s changed since the last report? What do these insights mean for your team? Tune in for our insightful conversation!\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/company/devsecops-talks/\"\u003eDiscuss the episode or ask us anything on LinkedIn\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"single_player_container\"\u003e\n   \u003ciframe\n     title=\"DEVSECOPS Talks #71 - Unpacking The Dora Accelerate State Of Devops Report\"\n     height=\"122\"\n     width=\"100%\"\n     style=\"border: none;\"\n     scrolling=\"no\"\n     data-name=\"pb-iframe-player\"\n     src=\"https://www.podbean.com/media/player/tumhu-177c46f-pb?from=yiiadmin\u0026download=1\u0026version=1\u0026skin=1\u0026btn-skin=107\u0026auto=0\u0026download=1\u0026pbad=1\"\n   \u003e\u003c/iframe\u003e\n \u003c/div\u003e\n\n\u003ch2 id=\"notes\"\u003eNotes\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://cloud.google.com/devops/state-of-devops\"\u003eDORA report\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e"},{"title":"#70 - System Initiative Goes Ga","date_published":"2024-11-28T21:30:25Z","date_modified":"2024-11-28T21:30:25Z","id":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/070-system-initiative-goes-ga/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/070-system-initiative-goes-ga/","authors":[{"name":"DevSecOps Talks"}],"content_html":"\u003cp\u003eAndrey, Mattias, and Paulina are joined by Paul Stack, an IaC tools developer and a frequent guest on the show. He’s back to discuss the general availability of System Initiative and share what has changed since his last visit when they talked about the early beta of the tool. Will this be a revolution or evolution in Infrastructure as Code tooling? Do we really need collaborative infrastructure management tools? Tune in to find out!\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/company/devsecops-talks/\"\u003eDiscuss the episode or ask us anything on LinkedIn\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"single_player_container\"\u003e\n   \u003ciframe\n     title=\"DEVSECOPS Talks #70 - System Initiative Goes Ga\"\n     height=\"122\"\n     width=\"100%\"\n     style=\"border: none;\"\n     scrolling=\"no\"\n     data-name=\"pb-iframe-player\"\n     src=\"https://www.podbean.com/media/player/9e2gf-1754254-pb?from=yiiadmin\u0026download=1\u0026version=1\u0026skin=1\u0026btn-skin=107\u0026auto=0\u0026download=1\u0026pbad=1\"\n   \u003e\u003c/iframe\u003e\n \u003c/div\u003e\n\n\u003ch2 id=\"notes\"\u003eNotes\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://www.linkedin.com/in/stack72/\"\u003ePaul Stack\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://www.systeminit.com/\"\u003eSystem Initiative\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e"},{"title":"#69 - Who Is Paulina?","date_published":"2024-11-08T19:36:09Z","date_modified":"2024-11-08T19:36:09Z","id":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/069-who-is-paulina-/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/069-who-is-paulina-/","authors":[{"name":"DevSecOps Talks"}],"content_html":"\u003cp\u003eJoin Andrey and Mattias as they sit down with Paulina Dubas, an independent DevOps consultant and public speaker. Who is Paulina, and what experiences does she bring to the table? What topics particularly resonate with her? Tune in to learn more about Paulina since we have a feeling that she is here to stay\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/company/devsecops-talks/\"\u003eDiscuss the episode or ask us anything on LinkedIn\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"single_player_container\"\u003e\n   \u003ciframe\n     title=\"DEVSECOPS Talks #69 - Who Is Paulina?\"\n     height=\"122\"\n     width=\"100%\"\n     style=\"border: none;\"\n     scrolling=\"no\"\n     data-name=\"pb-iframe-player\"\n     src=\"https://www.podbean.com/media/player/xdba3-1733582-pb?from=yiiadmin\u0026download=1\u0026version=1\u0026skin=1\u0026btn-skin=107\u0026auto=0\u0026download=1\u0026pbad=1\"\n   \u003e\u003c/iframe\u003e\n \u003c/div\u003e\n\n\u003ch2 id=\"notes\"\u003eNotes\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://www.linkedin.com/in/paulinadubas/\"\u003ePaulina on LinkedIn\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e"},{"title":"#68 - Julien’s Last Episode?","date_published":"2024-10-17T21:23:38+01:00","date_modified":"2024-10-17T21:23:38+01:00","id":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/068-julien-s-last-episode-/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/068-julien-s-last-episode-/","authors":[{"name":"DevSecOps Talks"}],"content_html":"\u003cp\u003eJulien shares big news with co-hosts Mattias and Andrey. What led to his decision to step down? And what does the future hold for him? Tune in for the off-boarding interview as we look back at the past four years and 60+ episodes we did together!\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/company/devsecops-talks/\"\u003eDiscuss the episode or ask us anything on LinkedIn\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"single_player_container\"\u003e\n   \u003ciframe\n     title=\"DEVSECOPS Talks #68 - Julien’s Last Episode?\"\n     height=\"122\"\n     width=\"100%\"\n     style=\"border: none;\"\n     scrolling=\"no\"\n     data-name=\"pb-iframe-player\"\n     src=\"https://www.podbean.com/media/player/jntgc-170e4c2-pb?from=yiiadmin\u0026download=1\u0026version=1\u0026skin=1\u0026btn-skin=107\u0026auto=0\u0026download=1\u0026pbad=1\"\n   \u003e\u003c/iframe\u003e\n \u003c/div\u003e\n\n\u003ch2 id=\"notes\"\u003eNotes\u003c/h2\u003e"},{"title":"#67 - Building MVP On AWS","date_published":"2024-10-03T21:16:11+01:00","date_modified":"2024-10-03T21:16:11+01:00","id":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/067-building-mvp-on-aws/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/067-building-mvp-on-aws/","authors":[{"name":"DevSecOps Talks"}],"content_html":"\u003cp\u003eJoin Andrey, Julien, and Mattias in this episode of DevSecOps Talks as they delve into building Minimum Viable Products (MVPs) and selecting the best solutions for them. Andrey goes first and, as an AWS consultant, kicks off the discussion by outlining his preferred AWS services for MVP development.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/company/devsecops-talks/\"\u003eDiscuss the episode or ask us anything on LinkedIn\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"single_player_container\"\u003e\n   \u003ciframe\n     title=\"DEVSECOPS Talks #67 - Building MVP On AWS\"\n     height=\"122\"\n     width=\"100%\"\n     style=\"border: none;\"\n     scrolling=\"no\"\n     data-name=\"pb-iframe-player\"\n     src=\"https://www.podbean.com/media/player/phf2p-16f2caf-pb?from=yiiadmin\u0026download=1\u0026version=1\u0026skin=1\u0026btn-skin=107\u0026auto=0\u0026download=1\u0026pbad=1\"\n   \u003e\u003c/iframe\u003e\n \u003c/div\u003e\n\n\u003ch2 id=\"notes\"\u003eNotes\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://www.youtube.com/watch?v=doZ680s5E1g\"\u003eMore detailed video version from FivexL\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e"},{"title":"#66 - Multi-Account Strategy And Landing Zones:  Account Segmentation Approaches For Security And Efficiency On AWS","date_published":"2024-05-27T12:47:53+01:00","date_modified":"2024-05-27T12:47:53+01:00","id":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/066-multi-account-strategy-and-landing-zones-account-segmentation-approaches-for-security-and-efficiency-on-aws/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/066-multi-account-strategy-and-landing-zones-account-segmentation-approaches-for-security-and-efficiency-on-aws/","authors":[{"name":"DevSecOps Talks"}],"content_html":"\u003cp\u003eIn this episode of DevSecOps Talks, co-hosts Andrey, Julien, and Mattias are joined by AWS Consultant Fernando Gonçalves to explore the complexities of AWS organization and account segmentation. Get insights into the debate over development, stage, and production accounts versus micro-segmentation. Don’t miss Julien\u0026rsquo;s take on why he believes staging is a waste of time and money, as well as Fernando’s explanation of what the AWS Landing Zone is. Learn about the tools provided by AWS for multi-account management and the pros and cons of various account segmentation approaches.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/company/devsecops-talks/\"\u003eDiscuss the episode or ask us anything on LinkedIn\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"single_player_container\"\u003e\n   \u003ciframe\n     title=\"DEVSECOPS Talks #66 - Multi-Account Strategy And Landing Zones:  Account Segmentation Approaches For Security And Efficiency On Aws\"\n     height=\"122\"\n     width=\"100%\"\n     style=\"border: none;\"\n     scrolling=\"no\"\n     data-name=\"pb-iframe-player\"\n     src=\"https://www.podbean.com/media/player/6qeyc-16229bb-pb?from=yiiadmin\u0026download=1\u0026version=1\u0026skin=1\u0026btn-skin=107\u0026auto=0\u0026download=1\u0026pbad=1\"\n   \u003e\u003c/iframe\u003e\n \u003c/div\u003e\n\n\u003ch2 id=\"notes\"\u003eNotes\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://www.linkedin.com/in/fernandogoncalves-me/\"\u003eFernando on LinkedIn\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://www.youtube.com/c/CloudnaPr%C3%A1tica\"\u003eFernando on YouTube\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html\"\u003eMulti-account strategies on AWS whitepaper\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e"},{"title":"#65 - Understanding Nats: An Explainer Of Its Features And Capabilities","date_published":"2024-05-07T21:59:46+02:00","date_modified":"2024-05-07T21:59:46+02:00","id":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/065-nats/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/065-nats/","authors":[{"name":"DevSecOps Talks"}],"content_html":"\u003cp\u003eJoin Andrey, Julien, and Mattias in this episode of DevSecOps Talks as they discuss Nats.io, a messaging system popular among people building on top of Kubernetes. Julien explains how Nats is different from Kafka and shares his personal experience with the product. The hosts discuss the various use cases of Nats and explore its features and capabilities. Tune in to find out if Nats is the right messaging system for you!\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/company/devsecops-talks/\"\u003eDiscuss the episode or ask us anything on LinkedIn\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"single_player_container\"\u003e\n   \u003ciframe\n     title=\"DEVSECOPS Talks #65 - Understanding Nats: An Explainer Of Its Features And Capabilities\"\n     height=\"122\"\n     width=\"100%\"\n     style=\"border: none;\"\n     scrolling=\"no\"\n     data-name=\"pb-iframe-player\"\n     src=\"https://www.podbean.com/media/player/62vvg-160779d-pb?from=yiiadmin\u0026download=1\u0026version=1\u0026skin=1\u0026btn-skin=107\u0026auto=0\u0026download=1\u0026pbad=1\"\n   \u003e\u003c/iframe\u003e\n \u003c/div\u003e\n\n\u003ch2 id=\"notes\"\u003eNotes\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eTBD\u003c/li\u003e\n\u003c/ul\u003e"},{"title":"#64 - From Terraform to OpenTofu: Story From the Trenches","date_published":"2024-04-11T11:08:36+01:00","date_modified":"2024-04-11T11:08:36+01:00","id":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/064-terraform-to-opentofu/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/064-terraform-to-opentofu/","authors":[{"name":"DevSecOps Talks"}],"content_html":"\u003cp\u003eIn this episode of DevSecOps Talks, Andrey and Mattias are joined by Timur Bublik, Platform Engineering Lead at TIER Mobility. As always, it\u0026rsquo;s practitioners for practitioners as they discuss the migration from Terraform to OpenTofu, TACOS tools, and how SpaceLift is used in Timur\u0026rsquo;s organization. Listen in as they dive into their three favorite features of SpaceLift and how TACOS tools like SpaceLift fit into the classic CI/CD pipeline.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/company/devsecops-talks/\"\u003eDiscuss the episode or ask us anything on LinkedIn\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"single_player_container\"\u003e\n  \u003ciframe\n    title=\"DEVSECOPS Talks #64 - From Terraform to OpenTofu: Story From the Trenches\"\n    height=\"122\"\n    width=\"100%\"\n    style=\"border: none;\"\n    scrolling=\"no\"\n    data-name=\"pb-iframe-player\"\n    src=\"https://www.podbean.com/media/player/e6h53-15db91d-pb?from=yiiadmin\u0026download=1\u0026version=1\u0026skin=1\u0026btn-skin=107\u0026auto=0\u0026download=1\u0026pbad=1\"\n  \u003e\u003c/iframe\u003e\n\u003c/div\u003e\n\n\u003ch2 id=\"notes\"\u003eNotes\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://www.linkedin.com/in/timur-bublik/\"\u003eTimur Bublik LinkedIn\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e"},{"title":"#63 - Yet Another AI Episode","date_published":"2024-03-14T11:08:36+01:00","date_modified":"2024-03-14T11:08:36+01:00","id":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/063-yet-another-ai-episode/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/063-yet-another-ai-episode/","authors":[{"name":"DevSecOps Talks"}],"content_html":"\u003cp\u003eJulien has returned with some exciting AI news. A startup has made the bold claim that they are capable of building AI software engineer. Andrey shares details about another startup that generates infrastructure based on application source code. He also mentions his upcoming talk on the use of LLM-based tools. We also discuss how individuals can stay ahead of the curve and be prepared for changes in their work life.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/company/devsecops-talks/\"\u003eDiscuss the episode or ask us anything on LinkedIn\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"single_player_container\"\u003e\n  \u003ciframe\n    title=\"DEVSECOPS Talks #63 - Yet Another AI Episode\"\n    height=\"122\"\n    width=\"100%\"\n    style=\"border: none;\"\n    scrolling=\"no\"\n    data-name=\"pb-iframe-player\"\n    src=\"https://www.podbean.com/media/player/fg6ku-15ad801-pb?from=yiiadmin\u0026download=1\u0026version=1\u0026skin=1\u0026btn-skin=107\u0026auto=0\u0026download=1\u0026pbad=1\"\n  \u003e\u003c/iframe\u003e\n\u003c/div\u003e\n\n\u003ch2 id=\"notes\"\u003eNotes\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://venturebeat.com/ai/cognition-emerges-from-stealth-to-launch-ai-software-engineer-devin/\"\u003eCognition emerges from stealth to launch AI software engineer\nDevin\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://appcd.com\"\u003eappCD Launches Generative Infrastructure from Code\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://catalog.us-east-1.prod.workshops.aws/workshops/6838a1a5-4516-4153-90ce-ac49ca8e1357/en-US\"\u003eAmazon CodeWhisperer Workshop\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e"},{"title":"#62 - The DevSecOps Perspective: Key Takeaways From Re:Invent 2023","date_published":"2024-03-02T11:08:36+01:00","date_modified":"2024-03-02T11:08:36+01:00","id":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/062-reinvent-2023-highlights/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/062-reinvent-2023-highlights/","authors":[{"name":"DevSecOps Talks"}],"content_html":"\u003cp\u003eIn this episode of DevSecOps Talks, Andrey and Mattias discuss the latest announcements from re:Invent 2023 that are most relevant to DevSecOps practitioners. Which announcements are worth paying attention to? What are the implications for the DevSecOps community? Join us as we dive into the latest developments from AWS.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/company/devsecops-talks/\"\u003eDiscuss the episode or ask us anything on LinkedIn\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"single_player_container\"\u003e\n  \u003ciframe\n    title=\"DEVSECOPS Talks #62 - The DevSecOps Perspective: Key Takeaways From Re:Invent 2023\"\n    height=\"122\"\n    width=\"100%\"\n    style=\"border: none;\"\n    scrolling=\"no\"\n    data-name=\"pb-iframe-player\"\n    src=\"https://www.podbean.com/media/player/9uhgs-159ae94-pb?from=yiiadmin\u0026download=1\u0026version=1\u0026skin=1\u0026btn-skin=107\u0026auto=0\u0026download=1\u0026pbad=1\"\n  \u003e\u003c/iframe\u003e\n\u003c/div\u003e\n\n\u003ch2 id=\"notes\"\u003eNotes\u003c/h2\u003e"},{"title":"#61 - GitHub Actions And Evolution Of CI/CD Tools","date_published":"2024-02-08T11:08:36+01:00","date_modified":"2024-02-08T11:08:36+01:00","id":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/061-github-actions-and-evolution-of-ci-cd/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/061-github-actions-and-evolution-of-ci-cd/","authors":[{"name":"DevSecOps Talks"}],"content_html":"\u003cp\u003eAndrey has been exploring GitHub Actions and has some insights to share. How have CI/CD solutions transformed over time, and what innovations do GitHub Actions bring to the table? Julien drops a few tools that could be useful for GitHub Actions users.\nWe explored a bit history of CI/CD, we started with Jenkins and its DSL in Groovy.\nWe compared that to the current DSL in YAML (GitHub Actions, Google Cloud Build, Azure DevOps, AWS CloudBuild).\nAndrey gave his tips on using Bash inside YAML and pipeline management. Mattias shared his experience on building pipeline.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/company/devsecops-talks/\"\u003eDiscuss the episode or ask us anything on LinkedIn\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"single_player_container\"\u003e\n  \u003ciframe\n    title=\"DEVSECOPS Talks #61 - GitHub Actions And Evolution Of CI/CD Tools\"\n    height=\"122\"\n    width=\"100%\"\n    style=\"border: none;\"\n    scrolling=\"no\"\n    data-name=\"pb-iframe-player\"\n    src=\"https://www.podbean.com/media/player/fa3p9-15758c0-pb?from=yiiadmin\u0026download=1\u0026version=1\u0026skin=1\u0026btn-skin=107\u0026auto=0\u0026download=1\u0026pbad=1\"\n  \u003e\u003c/iframe\u003e\n\u003c/div\u003e\n\n\u003ch2 id=\"notes\"\u003eNotes\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://github.com/nektos/act\"\u003eACT\u003c/a\u003e to run github actions locally\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://codeberg.org/\"\u003eCodeberg\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://github.com/go-gitea/gitea\"\u003egitea\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://sourcehut.org/\"\u003esourcehut\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://codeberg.org/forgejo/forgejo\"\u003eforgejo\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://www.jenkins.io/\"\u003ejenkins\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e"},{"title":"#60 - ChatGPT Anniversary: Where Are We With AI In Our Everyday Work","date_published":"2024-01-25T11:08:36+01:00","date_modified":"2024-01-25T11:08:36+01:00","id":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/060-one-year-since-chatgpt/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/060-one-year-since-chatgpt/","authors":[{"name":"DevSecOps Talks"}],"content_html":"\u003cp\u003eWelcome to the first DevSecOps Talks episode of the new year! It\u0026rsquo;s been a whole year since ChatGPT hit the scene – but how has AI adoption shaped our world since then? Join Julien, Mattias, and Andrey as they dive into the impact of AI on their workflows. How have their daily tech tools and practices evolved with AI integration? Plus, Julien gives us an insider\u0026rsquo;s look at running models locally. Are these AI tools enhancing our efficiency? Tune in to find out how these advancements are reshaping the landscape of DevSecOps.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/company/devsecops-talks/\"\u003eDiscuss the episode or ask us anything on LinkedIn\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"single_player_container\"\u003e\n  \u003ciframe\n    title=\"DEVSECOPS Talks #60 - ChatGPT Anniversary: Where Are We With AI In Our Everyday Work\"\n    height=\"122\"\n    width=\"100%\"\n    style=\"border: none;\"\n    scrolling=\"no\"\n    data-name=\"pb-iframe-player\"\n    src=\"https://www.podbean.com/media/player/ungec-1560268-pb?from=yiiadmin\u0026download=1\u0026version=1\u0026skin=1\u0026btn-skin=107\u0026auto=0\u0026download=1\u0026pbad=1\"\n  \u003e\u003c/iframe\u003e\n\u003c/div\u003e\n\n\u003ch2 id=\"notes\"\u003eNotes\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://ollama.ai\"\u003eollama.ai\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://perkeep.org\"\u003eperkeep.org\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://deepmind.google/technologies/gemini/#introduction\"\u003eGoogle Cloud Gemini\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e"},{"title":"#59 - Migration Off The Cloud: To Leave or Not to Leave?","date_published":"2024-01-16T11:08:36+01:00","date_modified":"2024-01-16T11:08:36+01:00","id":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/059-move-off-the-cloud-and-cost-optimization/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/059-move-off-the-cloud-and-cost-optimization/","authors":[{"name":"DevSecOps Talks"}],"content_html":"\u003cp\u003eIs the grass greener outside the cloud? This episode dives into the trend of companies (notably Hey and Dropbox) migrating away from cloud services. Why are they leaving, and who would benefit from such a move? We also scrutinize the common belief that public clouds are overly expensive. Join us as we dissect various cloud cost optimization tools and techniques.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/company/devsecops-talks/\"\u003eDiscuss the episode or ask us anything on LinkedIn\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"single_player_container\"\u003e\n  \u003ciframe\n    title=\"DEVSECOPS Talks #59 - Migration Off The Cloud: To Leave or Not to Leave?\"\n    height=\"122\"\n    width=\"100%\"\n    style=\"border: none;\"\n    scrolling=\"no\"\n    data-name=\"pb-iframe-player\"\n    src=\"https://www.podbean.com/media/player/gx4sd-154fb30-pb?from=yiiadmin\u0026download=1\u0026version=1\u0026skin=1\u0026btn-skin=107\u0026auto=0\u0026download=1\u0026pbad=1\"\n  \u003e\u003c/iframe\u003e\n\u003c/div\u003e\n\n\u003ch2 id=\"notes\"\u003eNotes\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://github.com/fivexl/aws-cost-and-usage-report-generator\"\u003eFivexL\u0026rsquo;s AWS cost analysis tool\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://world.hey.com/dhh/why-we-re-leaving-the-cloud-654b47e0\"\u003eDHH - Why we\u0026rsquo;re leaving the cloud\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://www.wired.com/2016/03/epic-story-dropboxs-exodus-amazon-cloud-empire/\"\u003eDropbox leaving the cloud\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e"},{"title":"#58 - AWS CDK with Igor Soroka","date_published":"2023-12-28T11:08:36+01:00","date_modified":"2023-12-28T11:08:36+01:00","id":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/058-cdk-with-igor-soroka/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/058-cdk-with-igor-soroka/","authors":[{"name":"DevSecOps Talks"}],"content_html":"\u003cp\u003eYou know our fondness for Terraform, but we are also open to exploring other tools. This episode is no different. We are joined by Igor Soroka, an expert in AWS serverless technology whose tool of choice is AWS CDK, but at the same time, he is no stranger to Terraform. We ask him practical questions about the tool and get answers based on his experience applying it to real-life projects. If you have been curious about CDK, how it functions, and if it\u0026rsquo;s appropriate for you, then tune in to learn more.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/company/devsecops-talks/\"\u003eDiscuss the episode or ask us anything on LinkedIn\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"single_player_container\"\u003e\n  \u003ciframe\n    title=\"DEVSECOPS Talks #58 - AWS CDK with Igor Soroka\"\n    height=\"122\"\n    width=\"100%\"\n    style=\"border: none;\"\n    scrolling=\"no\"\n    data-name=\"pb-iframe-player\"\n    src=\"https://www.podbean.com/media/player/5vpk2-153715a-pb?from=yiiadmin\u0026download=1\u0026version=1\u0026skin=1\u0026btn-skin=107\u0026auto=0\u0026download=1\u0026pbad=1\"\n  \u003e\u003c/iframe\u003e\n\u003c/div\u003e\n\n\u003ch2 id=\"notes\"\u003eNotes\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://www.linkedin.com/in/igor-soroka/\"\u003eIgor on LinkedIn\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e"},{"title":"#57 - Terraform Best Practices with Ben Goodman","date_published":"2023-11-23T11:08:36+01:00","date_modified":"2023-11-23T11:08:36+01:00","id":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/057-tf-best-practices-with-ben/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/057-tf-best-practices-with-ben/","authors":[{"name":"DevSecOps Talks"}],"content_html":"\u003cp\u003eIn this episode, Mattias is joined by Ben Goodman, the founder of dragondrop.cloud, a platform that offers Terraform Best Practices as a Pull Request. They discuss the best workflows for Terraform, open-source tools that can be used in conjunction with Terraform, the most effective best practices, and common pitfalls to avoid when implementing infrastructure as code using Terraform.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/company/devsecops-talks/\"\u003eDiscuss the episode or ask us anything on LinkedIn\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"single_player_container\"\u003e\n  \u003ciframe\n    title=\"DEVSECOPS Talks #57 - Terraform Best Practices with Ben Goodman\"\n    height=\"122\"\n    width=\"100%\"\n    style=\"border: none;\"\n    scrolling=\"no\"\n    data-name=\"pb-iframe-player\"\n    src=\"https://www.podbean.com/media/player/5azq5-1507fe8-pb?from=yiiadmin\u0026download=1\u0026version=1\u0026skin=1\u0026btn-skin=107\u0026auto=0\u0026download=1\u0026pbad=1\"\n  \u003e\u003c/iframe\u003e\n\u003c/div\u003e\n\n\u003ch2 id=\"notes\"\u003eNotes\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://dragondrop.cloud/\"\u003eDragondrop Cloud\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://github.com/dragondrop-cloud/cloud-concierge\"\u003eDragondrop Cloud GitHub\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://www.linkedin.com/in/ben-g-382141212/\"\u003eBen on LinkedIn\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e"},{"title":"#56 - Backstage and Internal Development Platforms (IDP)","date_published":"2023-11-08T11:08:36+01:00","date_modified":"2023-11-08T11:08:36+01:00","id":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/056-backstage/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/056-backstage/","authors":[{"name":"DevSecOps Talks"}],"content_html":"\u003cp\u003eIn this episode of DevSecOps Talks, join Andrey, Julien, and Mattias as they dive into the world of Backstage, the notable internal development platform. Mattias is keen to peel back the layers and understand what makes people think of Backstage as a must-have in modern DevOps toolchains. Andrey highlights the platform\u0026rsquo;s core feature: a comprehensive registry that keeps track of every software service running within a company. Could this signify a revival of IT change management, but with a twist? We\u0026rsquo;ve moved on from the days of cumbersome ticketing systems to streamlined internal development platforms. The team also ponders the future role of infrastructure engineers as they navigate the rising tides of AI—will AI become the new face behind these developer portals? Tune in to find out!\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/company/devsecops-talks/\"\u003eDiscuss the episode or ask us anything on LinkedIn\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"single_player_container\"\u003e\n  \u003ciframe\n    title=\"DEVSECOPS Talks #56 - Backstage and Internal Development Platforms (IDP)\"\n    height=\"122\"\n    width=\"100%\"\n    style=\"border: none;\"\n    scrolling=\"no\"\n    data-name=\"pb-iframe-player\"\n    src=\"https://www.podbean.com/media/player/nj8vb-14f23eb-pb?from=yiiadmin\u0026download=1\u0026version=1\u0026skin=1\u0026btn-skin=107\u0026auto=0\u0026download=1\u0026pbad=1\"\n  \u003e\u003c/iframe\u003e\n\u003c/div\u003e\n\n\u003ch2 id=\"notes\"\u003eNotes\u003c/h2\u003e"},{"title":"#55 - Unpacking System Initiative with Paul Stack","date_published":"2023-10-17T11:08:36+01:00","date_modified":"2023-10-17T11:08:36+01:00","id":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/055-system-init/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/055-system-init/","authors":[{"name":"DevSecOps Talks"}],"content_html":"\u003cp\u003eOur dialogue with Paul Stack resumes on DevSecOps Talks, almost two years after our initial podcast about his work on Pulumi (episode 25). As a warm-up, we talk about what prompted his move from Pulumi and his take on Open Terraform drama. The main topic of the episode is Paul\u0026rsquo;s current focus, System Initiative; we probe into its purpose, the progress so far, and the promise it holds for redefining how we think of doing Infrastructure as Code and DevSecOps workflows in general.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/company/devsecops-talks/\"\u003eDiscuss the episode or ask us anything on LinkedIn\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"single_player_container\"\u003e\n  \u003ciframe\n    title=\"DEVSECOPS Talks #55 - Unpacking System Initiative with Paul Stack\"\n    height=\"122\"\n    width=\"100%\"\n    style=\"border: none;\"\n    scrolling=\"no\"\n    data-name=\"pb-iframe-player\"\n    src=\"https://www.podbean.com/media/player/cuq32-14d2ea0-pb?from=yiiadmin\u0026download=1\u0026version=1\u0026skin=1\u0026btn-skin=107\u0026auto=0\u0026download=1\u0026pbad=1\"\n  \u003e\u003c/iframe\u003e\n\u003c/div\u003e\n\n\u003ch2 id=\"notes\"\u003eNotes\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://www.systeminit.com/\"\u003eSystem Initative\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://www.linkedin.com/in/stack72\"\u003ePaul Stack on LinkedIn\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://twitter.com/stack72\"\u003ePaul Stack on Twitter or whatever it is being called now\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://devsecops.fm/episodes/25-all-the-things-you-wanted-to-know-about-pulumi-explained/\"\u003eOur previous discussion with Paul\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e"},{"title":"#54 - HashiCorp’s BSL Move and OpenTF: What DevSecOps Practitioners Need to Know","date_published":"2023-09-13T11:08:36+01:00","date_modified":"2023-09-13T11:08:36+01:00","id":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/054-opentf/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/054-opentf/","authors":[{"name":"DevSecOps Talks"}],"content_html":"\u003cp\u003eIn this episode of DevSecOps Talks, we dive deep into HashiCorp\u0026rsquo;s recent shift to the Business Source License and its implications. Join Andrey, Julien, and Mattias as they unpack what this means for practitioners and explore the timeline of OpenTF initiative. Stay informed about what comes ahead with our latest discussion. Tune in!\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/company/devsecops-talks/\"\u003eDiscuss the episode or ask us anything on LinkedIn\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"single_player_container\"\u003e\n  \u003ciframe\n    title=\"DEVSECOPS Talks #54 - HashiCorp’s BSL Move and OpenTF: What DevSecOps Practitioners Need to Know\"\n    height=\"122\"\n    width=\"100%\"\n    style=\"border: none;\"\n    scrolling=\"no\"\n    data-name=\"pb-iframe-player\"\n    src=\"https://www.podbean.com/media/player/8s2f2-14a681d-pb?from=yiiadmin\u0026download=1\u0026version=1\u0026skin=1\u0026btn-skin=107\u0026auto=0\u0026download=1\u0026pbad=1\"\n  \u003e\u003c/iframe\u003e\n\u003c/div\u003e\n\n\u003ch2 id=\"notes\"\u003eNotes\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://www.hashicorp.com/blog/hashicorp-adopts-business-source-license\"\u003eHashiCorp BSL announcement\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://www.reddit.com/r/Terraform/comments/166am6t/hashicorp_updates_terraform_registry_tos_for/\"\u003eHashiCorp update of Registery TOC\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://opentf.org/\"\u003eOpenTF\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://github.com/opentffoundation/opentf\"\u003eOpenTF repo\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://github.com/opentffoundation/opentf/issues/258\"\u003eDiscussion about replacing registery\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://github.com/opentffoundation/opentf/milestones\"\u003eOpenTF milestones\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://thenewstack.io/opentf-disgruntled-hashicorp-rivals-threaten-to-fork-terraform/\"\u003eThe New Stack take on OpenTF\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://spacelift.io/blog/announcing-opentf\"\u003eSpacelift announcing OpenTF\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e"},{"title":"#53 - Open Software Supply Chain Attack Reference Framework with Neatsun","date_published":"2023-08-01T11:08:36+01:00","date_modified":"2023-08-01T11:08:36+01:00","id":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/053-supply-chain-again/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/053-supply-chain-again/","authors":[{"name":"DevSecOps Talks"}],"content_html":"\u003cp\u003eWe had the opportunity to talk with Neatsun Ziv, one of the founders of Ox Security, about the Open Source Software Supply Chain Attack Reference Framework (\u003ca href=\"https://pbom.dev\"\u003ehttps://pbom.dev\u003c/a\u003e). We delved deeper into possible attack vectors and explored ways to mitigate some of them. During our discussions, we also had a couple of unusual takes on supply chain security. If you are looking to understand the Open Source Software Supply Chain, then this episode is perfect for you.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/company/devsecops-talks/\"\u003eDiscuss the episode or ask us anything on LinkedIn\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"single_player_container\"\u003e\n  \u003ciframe\n    title=\"DEVSECOPS Talks #53 - Open Software Supply Chain Attack Reference Framework with Neatsun\"\n    height=\"122\"\n    width=\"100%\"\n    style=\"border: none;\"\n    scrolling=\"no\"\n    data-name=\"pb-iframe-player\"\n    src=\"https://www.podbean.com/media/player/d3qwg-146d5f9-pb?from=yiiadmin\u0026download=1\u0026version=1\u0026skin=1\u0026btn-skin=107\u0026auto=0\u0026download=1\u0026pbad=1\"\n  \u003e\u003c/iframe\u003e\n\u003c/div\u003e\n\n\u003ch2 id=\"notes\"\u003eNotes\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://www.ox.security/open-software-supply-chain-attack-reference-framework/\"\u003eOpen Software Supply Chain Attack Reference Framework\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e"},{"title":"#52 - Lingon a.k.a Juliens and Jacobs open source project","date_published":"2023-07-13T11:08:36+01:00","date_modified":"2023-07-13T11:08:36+01:00","id":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/052-lingon/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/052-lingon/","authors":[{"name":"DevSecOps Talks"}],"content_html":"\u003cp\u003eThis 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\u0026rsquo;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.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/company/devsecops-talks/\"\u003eDiscuss the episode or ask us anything on LinkedIn\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"single_player_container\"\u003e\n  \u003ciframe\n    title=\"DEVSECOPS Talks #52 - Lingon a.k.a Juliens and Jacobs open source project\"\n    height=\"122\"\n    width=\"100%\"\n    style=\"border: none;\"\n    scrolling=\"no\"\n    data-name=\"pb-iframe-player\"\n    src=\"https://www.podbean.com/media/player/v6k6j-14562ed-pb?from=yiiadmin\u0026download=1\u0026version=1\u0026skin=1\u0026btn-skin=107\u0026auto=0\u0026download=1\u0026pbad=1\"\n  \u003e\u003c/iframe\u003e\n\u003c/div\u003e\n\n\u003ch2 id=\"notes\"\u003eNotes\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://github.com/volvo-cars/lingon\"\u003eLingon Github\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e"},{"title":"#51 - Provisioning bare-metal servers","date_published":"2023-06-30T11:08:36+01:00","date_modified":"2023-06-30T11:08:36+01:00","id":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/051-bare-metal-servers/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/051-bare-metal-servers/","authors":[{"name":"DevSecOps Talks"}],"content_html":"\u003cp\u003eDiving into the world of bare-metal servers, Mattias takes the helm solo for this episode. He\u0026rsquo;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.\u003c/p\u003e\n\u003cp\u003eWhile we often chat about the big cloud service providers, this time we\u0026rsquo;re switching gears. If you\u0026rsquo;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.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/company/devsecops-talks/\"\u003eDiscuss the episode or ask us anything on LinkedIn\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"single_player_container\"\u003e\n  \u003ciframe\n    title=\"DEVSECOPS Talks #51 - Provisioning bare-metal servers\"\n    height=\"122\"\n    width=\"100%\"\n    style=\"border: none;\"\n    scrolling=\"no\"\n    data-name=\"pb-iframe-player\"\n    src=\"https://www.podbean.com/media/player/wt57f-1446a7d-pb?from=yiiadmin\u0026download=1\u0026version=1\u0026skin=1\u0026btn-skin=107\u0026auto=0\u0026download=1\u0026pbad=1\"\n  \u003e\u003c/iframe\u003e\n\u003c/div\u003e\n\n\u003ch2 id=\"notes\"\u003eNotes\u003c/h2\u003e"},{"title":"#50 - History of AWS networking and new ways to design your VPC setup","date_published":"2023-05-18T11:08:36+01:00","date_modified":"2023-05-18T11:08:36+01:00","id":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/050-aws-networking/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/050-aws-networking/","authors":[{"name":"DevSecOps Talks"}],"content_html":"\u003cp\u003eIn 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.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/company/devsecops-talks/\"\u003eDiscuss the episode or ask us anything on LinkedIn\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"single_player_container\"\u003e\n  \u003ciframe\n    title=\"DEVSECOPS Talks #50 - History of AWS networking and new ways to design your VPC setup\"\n    height=\"122\"\n    width=\"100%\"\n    style=\"border: none;\"\n    scrolling=\"no\"\n    data-name=\"pb-iframe-player\"\n    src=\"https://www.podbean.com/media/player/dd4t7-1410ec8-pb?from=yiiadmin\u0026download=1\u0026version=1\u0026skin=1\u0026btn-skin=107\u0026auto=0\u0026download=1\u0026pbad=1\"\n  \u003e\u003c/iframe\u003e\n\u003c/div\u003e\n\n\u003ch2 id=\"notes\"\u003eNotes\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://aws.amazon.com/ram/\"\u003eAWS RAM\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://aws.amazon.com/blogs/networking-and-content-delivery/vpc-sharing-a-new-approach-to-multiple-accounts-and-vpc-management/\"\u003eVPC Sharing - A new approach to multiple accounts and vpc management\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://www.grammarly.com/blog/engineering/scaling-aws-infrastructure/\"\u003eScaling AWS infra at Grammarly\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/architecture.html\"\u003eAWS Security Reference Architecture\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://ably.com/blog/aws-vpc-peering-vs-transit-gateway-and-beyond\"\u003eAWS VPC Peering VS Transit Gateway and beyond\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e"},{"title":"#49 - Password managers, ways to share sensitive info, email aliases, ChatGPT and much more","date_published":"2023-04-12T11:08:36+01:00","date_modified":"2023-04-12T11:08:36+01:00","id":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/049-tools/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/049-tools/","authors":[{"name":"DevSecOps Talks"}],"content_html":"\u003cp\u003eThis 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.\u003c/p\u003e\n\u003cp\u003eJulien also shares his favorite email alias service and we discuss services for sharing sensitive information to keep mail inboxes cleaner and more private.\u003c/p\u003e\n\u003cp\u003eWe also spoke about ChatGPT, an AI language model from OpenAI - will it replace jobs? should we be using it? And how?\u003c/p\u003e\n\u003cp\u003eJust a heads up, we aren\u0026rsquo;t sponsored by companies we mention in this episode. We\u0026rsquo;re just sharing our personal experiences and the stuff we like to use.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/company/devsecops-talks/\"\u003eDiscuss the episode or ask us anything on LinkedIn\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"single_player_container\"\u003e\n  \u003ciframe\n    title=\"DEVSECOPS Talks #49 - Password managers, ways to share sensitive info, email aliases, ChatGPT and much more\"\n    height=\"122\"\n    width=\"100%\"\n    style=\"border: none;\"\n    scrolling=\"no\"\n    data-name=\"pb-iframe-player\"\n    src=\"https://www.podbean.com/media/player/26mf2-13df1d8-pb?from=yiiadmin\u0026download=1\u0026version=1\u0026skin=1\u0026btn-skin=107\u0026auto=0\u0026download=1\u0026pbad=1\"\n  \u003e\u003c/iframe\u003e\n\u003c/div\u003e\n\n\u003ch2 id=\"notes\"\u003eNotes\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://yopass.se/\"\u003eYoPass\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://send.vis.ee/\"\u003eSendVis\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://simplelogin.io/\"\u003eSimpleLogin\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://1password.com/\"\u003e1Password\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://www.lastpass.com/\"\u003eLastPass\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://bitwarden.com/\"\u003eBitWarden\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e"},{"title":"#48 - Building Data Platforms","date_published":"2023-03-08T11:08:36+01:00","date_modified":"2023-03-08T11:08:36+01:00","id":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/048-data-platform/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/048-data-platform/","authors":[{"name":"DevSecOps Talks"}],"content_html":"\u003cp\u003eJulien 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.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/company/devsecops-talks/\"\u003eDiscuss the episode or ask us anything on LinkedIn\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"single_player_container\"\u003e\n  \u003ciframe\n    title=\"DEVSECOPS Talks #48 - Building Data Platforms\"\n    height=\"122\"\n    width=\"100%\"\n    style=\"border: none;\"\n    scrolling=\"no\"\n    data-name=\"pb-iframe-player\"\n    src=\"https://www.podbean.com/media/player/989d8-13af684-pb?from=yiiadmin\u0026download=1\u0026version=1\u0026skin=1\u0026btn-skin=107\u0026auto=0\u0026download=1\u0026pbad=1\"\n  \u003e\u003c/iframe\u003e\n\u003c/div\u003e\n\n\u003ch2 id=\"notes\"\u003eNotes\u003c/h2\u003e"},{"title":"#47 - Tracing explained","date_published":"2023-01-07T11:08:36+01:00","date_modified":"2023-01-07T11:08:36+01:00","id":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/047-tracing/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/047-tracing/","authors":[{"name":"DevSecOps Talks"}],"content_html":"\u003cp\u003eWe 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.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/company/devsecops-talks/\"\u003eDiscuss the episode or ask us anything on LinkedIn\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"single_player_container\"\u003e\n  \u003ciframe\n    title=\"DEVSECOPS Talks #47 - Tracing explained\"\n    height=\"122\"\n    width=\"100%\"\n    style=\"border: none;\"\n    scrolling=\"no\"\n    data-name=\"pb-iframe-player\"\n    src=\"https://www.podbean.com/media/player/tht9r-1384174-pb?from=yiiadmin\u0026download=1\u0026version=1\u0026skin=1\u0026btn-skin=107\u0026auto=0\u0026download=1\u0026pbad=1\"\n  \u003e\u003c/iframe\u003e\n\u003c/div\u003e\n\n\u003ch2 id=\"notes\"\u003eNotes\u003c/h2\u003e"},{"title":"#46 - Software supply chain attacks","date_published":"2022-12-01T11:08:36+01:00","date_modified":"2022-12-01T11:08:36+01:00","id":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/046-supply-chain/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/046-supply-chain/","authors":[{"name":"DevSecOps Talks"}],"content_html":"\u003cp\u003eWe 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?\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/company/devsecops-talks/\"\u003eDiscuss the episode or ask us anything on LinkedIn\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"single_player_container\"\u003e\n  \u003ciframe\n    title=\"DEVSECOPS Talks #46 - Software supply chain attacks\"\n    height=\"122\"\n    width=\"100%\"\n    style=\"border: none;\"\n    scrolling=\"no\"\n    data-name=\"pb-iframe-player\"\n    src=\"https://www.podbean.com/media/player/irn3r-132a3fa-pb?from=yiiadmin\u0026download=1\u0026version=1\u0026skin=1\u0026btn-skin=107\u0026auto=0\u0026download=1\u0026pbad=1\"\n  \u003e\u003c/iframe\u003e\n\u003c/div\u003e\n\n\u003ch2 id=\"notes\"\u003eNotes\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://osv.dev/\"\u003eA distributed vulnerability database for Open Source\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://github.com/goharbor/harbor\"\u003eHarbor\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e"},{"title":"#45 - What is happening with Docker?","date_published":"2022-11-01T11:08:36+01:00","date_modified":"2022-11-01T11:08:36+01:00","id":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/045-docker/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/045-docker/","authors":[{"name":"DevSecOps Talks"}],"content_html":"\u003cp\u003eHave you heard any recent news from Docker? We haven\u0026rsquo;t. That is why we decided to check up on Docker to see how it is doing and go through the tool\u0026rsquo;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.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/company/devsecops-talks/\"\u003eDiscuss the episode or ask us anything on LinkedIn\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"single_player_container\"\u003e\n  \u003ciframe\n    title=\"DEVSECOPS Talks #45 - What is happening with Docker?\"\n    height=\"122\"\n    width=\"100%\"\n    style=\"border: none;\"\n    scrolling=\"no\"\n    data-name=\"pb-iframe-player\"\n    src=\"https://www.podbean.com/media/player/m7rfe-13027d7-pb?from=yiiadmin\u0026download=1\u0026version=1\u0026skin=1\u0026btn-skin=107\u0026auto=0\u0026download=1\u0026pbad=1\"\n  \u003e\u003c/iframe\u003e\n\u003c/div\u003e\n\n\u003ch2 id=\"notes\"\u003eNotes\u003c/h2\u003e"},{"title":"#44 - Kosli with Mike Long. From compliance to answering questions about the production environment","date_published":"2022-09-01T11:08:36+01:00","date_modified":"2022-09-01T11:08:36+01:00","id":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/044-kosli/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/044-kosli/","authors":[{"name":"DevSecOps Talks"}],"content_html":"\u003cp\u003eWe 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\u0026rsquo;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.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/company/devsecops-talks/\"\u003eDiscuss the episode or ask us anything on LinkedIn\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"single_player_container\"\u003e\n  \u003ciframe\n    title=\"DEVSECOPS Talks #44 - Kosli with Mike Long. From compliance to answering questions about the production environment\"\n    height=\"122\"\n    width=\"100%\"\n    style=\"border: none;\"\n    scrolling=\"no\"\n    data-name=\"pb-iframe-player\"\n    src=\"https://www.podbean.com/media/player/cyduk-12b21fa-pb?from=yiiadmin\u0026download=1\u0026version=1\u0026skin=1\u0026btn-skin=107\u0026auto=0\u0026download=1\u0026pbad=1\"\n  \u003e\u003c/iframe\u003e\n\u003c/div\u003e\n\n\u003ch2 id=\"notes\"\u003eNotes\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://www.linkedin.com/in/mikelongoslo/\"\u003eMike Long\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://www.kosli.com/\"\u003eKosli\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://www.devopsctl.com/\"\u003eDevOpsCtl\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://slsa.dev/\"\u003eSLSA\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://in-toto.io/\"\u003ein-toto\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://spdx.dev/\"\u003eSPDX\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://www.sigstore.dev/\"\u003eSigstore\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e"},{"title":"#43 - Terraform 1.0 to 1.3.0. One year in review","date_published":"2022-06-28T11:08:36+01:00","date_modified":"2022-06-28T11:08:36+01:00","id":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/043-terraform-one-year-recap/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/043-terraform-one-year-recap/","authors":[{"name":"DevSecOps Talks"}],"content_html":"\u003cp\u003eWe 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.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/company/devsecops-talks/\"\u003eDiscuss the episode or ask us anything on LinkedIn\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"single_player_container\"\u003e\n  \u003ciframe\n    title=\"DEVSECOPS Talks #43 - Terraform 1.0 to 1.3.0. One year in review\"\n    height=\"122\"\n    width=\"100%\"\n    style=\"border: none;\"\n    scrolling=\"no\"\n    data-name=\"pb-iframe-player\"\n    src=\"https://www.podbean.com/media/player/88rw5-125edf2-pb?from=yiiadmin\u0026download=1\u0026version=1\u0026skin=1\u0026btn-skin=107\u0026auto=0\u0026download=1\u0026pbad=1\"\n  \u003e\u003c/iframe\u003e\n\u003c/div\u003e\n\n\u003ch2 id=\"notes\"\u003eNotes\u003c/h2\u003e"},{"title":"#42 - Prometheus - a practitioner take","date_published":"2022-05-19T11:08:36+01:00","date_modified":"2022-05-19T11:08:36+01:00","id":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/042-prom/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/042-prom/","authors":[{"name":"DevSecOps Talks"}],"content_html":"\u003cp\u003eIf 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.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/company/devsecops-talks/\"\u003eDiscuss the episode or ask us anything on LinkedIn\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"single_player_container\"\u003e\n  \u003ciframe\n    title=\"DEVSECOPS Talks #42 - Prometheus - a practitioner take\"\n    height=\"122\"\n    width=\"100%\"\n    style=\"border: none;\"\n    scrolling=\"no\"\n    data-name=\"pb-iframe-player\"\n    src=\"https://www.podbean.com/media/player/y87mq-122d839-pb?from=yiiadmin\u0026download=1\u0026version=1\u0026skin=1\u0026btn-skin=107\u0026auto=0\u0026download=1\u0026pbad=1\"\n  \u003e\u003c/iframe\u003e\n\u003c/div\u003e\n\n\u003ch2 id=\"notes\"\u003eNotes\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://www.linkedin.com/in/semyon-novikov/\"\u003eSemyon Novikov\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://www.amazon.com/Prometheus-Infrastructure-Application-Performance-Monitoring/dp/1492034142\"\u003ePrometheus: Up \u0026amp; Running: Infrastructure and Application Performance Monitoring by Brian Brazil\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://grafana.com/oss/mimir/\"\u003eMimir by Grafana Labs\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://github.com/prometheus/prometheus/issues/3780\"\u003ePrometheus OOM GitHub issue\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://victoriametrics.com/products/open-source/\"\u003eVictoriaMetrics\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e"},{"title":"#41 - Great communication FTW","date_published":"2022-04-26T11:08:36+01:00","date_modified":"2022-04-26T11:08:36+01:00","id":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/041-com/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/041-com/","authors":[{"name":"DevSecOps Talks"}],"content_html":"\u003cp\u003eCommunication 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\u0026rsquo;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.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/company/devsecops-talks/\"\u003eDiscuss the episode or ask us anything on LinkedIn\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"single_player_container\"\u003e\n  \u003ciframe\n    title=\"DEVSECOPS Talks #41 - Great communication FTW\"\n    height=\"122\"\n    width=\"100%\"\n    style=\"border: none;\"\n    scrolling=\"no\"\n    data-name=\"pb-iframe-player\"\n    src=\"https://www.podbean.com/media/player/xdhk2-120e124-pb?from=yiiadmin\u0026download=1\u0026version=1\u0026skin=1\u0026btn-skin=107\u0026auto=0\u0026download=1\u0026pbad=1\"\n  \u003e\u003c/iframe\u003e\n\u003c/div\u003e\n\n\u003ch2 id=\"notes\"\u003eNotes\u003c/h2\u003e"},{"title":"#40 - Web3 and its implications for DevSecOps practitioners","date_published":"2022-03-23T11:08:36+01:00","date_modified":"2022-03-23T11:08:36+01:00","id":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/040-web3/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/040-web3/","authors":[{"name":"DevSecOps Talks"}],"content_html":"\u003cp\u003eweb3 has gotten a lot of attention lately; thus, it is time for us to separate facts from the hype.\nIn this episode, we are trying to understand its implications for us as DevSecOps practitioners.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/company/devsecops-talks/\"\u003eDiscuss the episode or ask us anything on LinkedIn\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"single_player_container\"\u003e\n  \u003ciframe\n    title=\"DEVSECOPS Talks #40 - web3 and its implications for DevSecOps practitioners\"\n    height=\"122\"\n    width=\"100%\"\n    style=\"border: none;\"\n    scrolling=\"no\"\n    data-name=\"pb-iframe-player\"\n    src=\"https://www.podbean.com/media/player/4sndt-11dccf3-pb?from=yiiadmin\u0026download=1\u0026version=1\u0026skin=1\u0026btn-skin=107\u0026auto=0\u0026download=1\u0026pbad=1\"\n  \u003e\u003c/iframe\u003e\n\u003c/div\u003e\n\n\u003ch2 id=\"notes\"\u003eNotes\u003c/h2\u003e"},{"title":"#39 - Setting up tools and environments","date_published":"2022-02-07T11:08:36+01:00","date_modified":"2022-02-07T11:08:36+01:00","id":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/039-local-env/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/039-local-env/","authors":[{"name":"DevSecOps Talks"}],"content_html":"\u003cp\u003eAndrey 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?\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/company/devsecops-talks/\"\u003eDiscuss the episode or ask us anything on LinkedIn\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"single_player_container\"\u003e\n  \u003ciframe\n    title=\"DevSecOps Talks #39 - Setting up tools and environments\"\n    height=\"122\"\n    width=\"100%\"\n    style=\"border: none;\"\n    scrolling=\"no\"\n    data-name=\"pb-iframe-player\"\n    src=\"https://www.podbean.com/media/player/39sn6-1198339-pb?from=yiiadmin\u0026download=1\u0026version=1\u0026skin=1\u0026btn-skin=107\u0026auto=0\u0026download=1\u0026pbad=1\"\n  \u003e\u003c/iframe\u003e\n\u003c/div\u003e\n\n\u003ch2 id=\"notes\"\u003eNotes\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://cuelang.org/\"\u003eCUE language\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://bazel.build/\"\u003eBazel\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://gradle.org/\"\u003eGradle\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e"},{"title":"#38 - Platform teams with Henrik","date_published":"2022-01-24T11:08:36+01:00","date_modified":"2022-01-24T11:08:36+01:00","id":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/038-platform-teams-with-henrik/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/038-platform-teams-with-henrik/","authors":[{"name":"DevSecOps Talks"}],"content_html":"\u003cp\u003eHenrik 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:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003ebash is the future of automation (not really, but some people think so)\u003c/li\u003e\n\u003cli\u003ebuilding multi-cloud solutions using k8s and service mesh solutions\u003c/li\u003e\n\u003cli\u003eShuttle - CLI for handling shared build and deploy tools between projects no matter what technologies the projects are using \u003ca href=\"https://github.com/lunarway/shuttle\"\u003ehttps://github.com/lunarway/shuttle\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003ewhen is it the time to start looking into the building application delivery platform\u003c/li\u003e\n\u003cli\u003eplatform team as an enabler or evil gatekeeper\u003c/li\u003e\n\u003cli\u003eteam topology\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/company/devsecops-talks/\"\u003eDiscuss the episode or ask us anything on LinkedIn\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"single_player_container\"\u003e\n  \u003ciframe\n    title=\"DevSecOps Talks #38 - Platform teams with Henrik\"\n    height=\"122\"\n    width=\"100%\"\n    style=\"border: none;\"\n    scrolling=\"no\"\n    data-name=\"pb-iframe-player\"\n    src=\"https://www.podbean.com/media/player/hzuhc-1189d16-pb?from=yiiadmin\u0026download=1\u0026version=1\u0026skin=1\u0026btn-skin=107\u0026auto=0\u0026download=1\u0026pbad=1\"\n  \u003e\u003c/iframe\u003e\n\u003c/div\u003e\n\n\u003ch2 id=\"notes\"\u003eNotes\u003c/h2\u003e"},{"title":"#37 - Surviving AWS outage (revised for 2021)","date_published":"2022-01-07T11:08:36+01:00","date_modified":"2022-01-07T11:08:36+01:00","id":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/037-aws-outage/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/037-aws-outage/","authors":[{"name":"DevSecOps Talks"}],"content_html":"\u003cp\u003eus-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\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/company/devsecops-talks/\"\u003eDiscuss the episode or ask us anything on LinkedIn\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"single_player_container\"\u003e\n  \u003ciframe\n    title=\"DevSecOps Talks #37 - Surviving AWS outage (revised for 2021)\"\n    height=\"122\"\n    width=\"100%\"\n    style=\"border: none;\"\n    scrolling=\"no\"\n    data-name=\"pb-iframe-player\"\n    src=\"https://www.podbean.com/media/player/ipy64-1172a39-pb?from=yiiadmin\u0026download=1\u0026version=1\u0026skin=1\u0026btn-skin=107\u0026auto=0\u0026download=1\u0026pbad=1\"\n  \u003e\u003c/iframe\u003e\n\u003c/div\u003e\n\n\u003ch2 id=\"notes\"\u003eNotes\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://aws.amazon.com/message/12721/\"\u003eAWS outage postmortem\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://devsecops.fm/episodes/21-surviving-aws-outage/\"\u003eSurviving AWS Outage, episode from 2020\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://github.com/gosuri/aws-outages\"\u003eaws-outages script\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://log4jmemes.com/\"\u003elog4jmemes\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e"},{"title":"#36 - Sturdy. Is it time for a new version control tool?","date_published":"2021-12-07T18:23:24+02:00","date_modified":"2021-12-07T18:48:24+02:00","id":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/036-sturdy/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/036-sturdy/","authors":[{"name":"DevSecOps Talks"}],"content_html":"\u003cp\u003eWe 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?\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/company/devsecops-talks/\"\u003eDiscuss the episode or ask us anything on LinkedIn\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"single_player_container\"\u003e\n  \u003ciframe\n    title=\"DevSecOps Talks #36 - Sturdy. Is it time for a new version control tool?\"\n    height=\"122\"\n    width=\"100%\"\n    style=\"border: none;\"\n    scrolling=\"no\"\n    data-name=\"pb-iframe-player\"\n    src=\"https://www.podbean.com/media/player/h8fzc-114cc81-pb?from=yiiadmin\u0026download=1\u0026version=1\u0026skin=1\u0026btn-skin=107\u0026auto=0\u0026download=1\u0026pbad=1\"\n  \u003e\u003c/iframe\u003e\n\u003c/div\u003e\n\n\u003ch2 id=\"notes\"\u003eNotes\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://getsturdy.com/\"\u003eSturdy\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003eKiril\u0026rsquo;s \u003ca href=\"https://www.linkedin.com/in/kirilv/\"\u003eLinkedIn\u003c/a\u003e and \u003ca href=\"https://twitter.com/krlvi\"\u003eTwitter\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e"},{"title":"#35 - Infrastructure as code (IAC) revisited 2021","date_published":"2021-11-16T18:23:24+02:00","date_modified":"2021-11-16T18:48:24+02:00","id":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/035-iac-revisited-2021/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/035-iac-revisited-2021/","authors":[{"name":"DevSecOps Talks"}],"content_html":"\u003cp\u003eOur 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!\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/company/devsecops-talks/\"\u003eDiscuss the episode or ask us anything on LinkedIn\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"single_player_container\"\u003e\n  \u003ciframe\n    title=\"DevSecOps Talks #35 - Infrastructure as code (IAC) revisited 2021\"\n    height=\"122\"\n    width=\"100%\"\n    style=\"border: none;\"\n    scrolling=\"no\"\n    data-name=\"pb-iframe-player\"\n    src=\"https://www.podbean.com/media/player/m6szn-1132370-pb?from=yiiadmin\u0026download=1\u0026version=1\u0026skin=1\u0026btn-skin=107\u0026auto=0\u0026download=1\u0026pbad=1\"\n  \u003e\u003c/iframe\u003e\n\u003c/div\u003e\n\n\u003ch2 id=\"notes\"\u003eNotes\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://www.amazon.com/Infrastructure-Code-Dynamic-Systems-Cloud/dp/1098114671\"\u003eInfrastructure as Code: Dynamic Systems for the Cloud Age 2nd Edition\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e"},{"title":"#34 - Google Next and HashiConf recap","date_published":"2021-10-21T18:23:24+02:00","date_modified":"2021-10-21T18:48:24+02:00","id":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/034-google-cloud-next-hashiconf/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/034-google-cloud-next-hashiconf/","authors":[{"name":"DevSecOps Talks"}],"content_html":"\u003cp\u003eJulien 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.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/company/devsecops-talks/\"\u003eDiscuss the episode or ask us anything on LinkedIn\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"single_player_container\"\u003e\n  \u003ciframe\n    title=\"DevSecOps Talks #34 - Google Next and HashiConf recap\"\n    height=\"122\"\n    width=\"100%\"\n    style=\"border: none;\"\n    scrolling=\"no\"\n    data-name=\"pb-iframe-player\"\n    src=\"https://www.podbean.com/media/player/5rws4-111e692-pb?from=yiiadmin\u0026download=1\u0026version=1\u0026skin=1\u0026btn-skin=107\u0026auto=0\u0026download=1\u0026pbad=1\"\n  \u003e\u003c/iframe\u003e\n\u003c/div\u003e\n\n\u003ch2 id=\"notes\"\u003eNotes\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://youtu.be/hDkAfjCCXRc\"\u003eAndrey\u0026rsquo;s recap of HashiConf in Russian\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://www.youtube.com/watch?v=g3lR7xPI9EI\u0026amp;amp;list=PL81sUbsFNc5arDZYNn3i8N_I7ZeCe02ve\"\u003eHashiConf 2021 Global playlist\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://www.youtube.com/watch?v=zMN56phAyns\"\u003eGoogle Cloud Next Day 1 livestream\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e"},{"title":"#33 - Do I need a service mesh?","date_published":"2021-09-30T18:23:24+02:00","date_modified":"2021-09-30T18:48:24+02:00","id":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/033-service-mesh/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/033-service-mesh/","authors":[{"name":"DevSecOps Talks"}],"content_html":"\u003cp\u003eEveryone 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.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/company/devsecops-talks/\"\u003eDiscuss the episode or ask us anything on LinkedIn\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"single_player_container\"\u003e\n  \u003ciframe\n    title=\"DevSecOps Talks #33 - Do I need a service mesh?\"\n    height=\"122\"\n    width=\"100%\"\n    style=\"border: none;\"\n    scrolling=\"no\"\n    data-name=\"pb-iframe-player\"\n    src=\"https://www.podbean.com/media/player/ckw39-10f1d56-pb?from=yiiadmin\u0026download=1\u0026version=1\u0026skin=1\u0026btn-skin=107\u0026auto=0\u0026download=1\u0026pbad=1\"\n  \u003e\u003c/iframe\u003e\n\u003c/div\u003e\n\n\u003ch2 id=\"notes\"\u003eNotes\u003c/h2\u003e"},{"title":"#32 - Getting hired as an infrastructure automation person","date_published":"2021-09-13T18:23:24+02:00","date_modified":"2021-09-13T18:48:24+02:00","id":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/032-getting-hired/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/032-getting-hired/","authors":[{"name":"DevSecOps Talks"}],"content_html":"\u003cp\u003eAs a follow-up to the \u003ca href=\"https://devsecops.fm/episodes/31-hiring/\"\u003elast episode about hiring an infrastructure automation person\u003c/a\u003e 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.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/company/devsecops-talks/\"\u003eDiscuss the episode or ask us anything on LinkedIn\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"single_player_container\"\u003e\n  \u003ciframe\n    title=\"DevSecOps Talks #32 - Getting hired as an infrastructure automation person\"\n    height=\"122\"\n    width=\"100%\"\n    style=\"border: none;\"\n    scrolling=\"no\"\n    data-name=\"pb-iframe-player\"\n    src=\"https://www.podbean.com/media/player/b4hw5-10db269-pb?from=yiiadmin\u0026download=1\u0026version=1\u0026skin=1\u0026btn-skin=107\u0026auto=0\u0026download=1\u0026pbad=1\"\n  \u003e\u003c/iframe\u003e\n\u003c/div\u003e\n\n\u003ch2 id=\"notes\"\u003eNotes\u003c/h2\u003e"},{"title":"#31 - Hiring an infrastructure automation person","date_published":"2021-08-24T18:48:24+02:00","date_modified":"2021-08-24T18:48:24+02:00","id":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/031-hiring/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/031-hiring/","authors":[{"name":"DevSecOps Talks"}],"content_html":"\u003cp\u003eHave 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!\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/company/devsecops-talks/\"\u003eDiscuss the episode or ask us anything on LinkedIn\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"single_player_container\"\u003e\n  \u003ciframe\n    title=\"DevSecOps Talks #31 - Hiring an infrastructure automation person\"\n    height=\"122\"\n    width=\"100%\"\n    style=\"border: none;\"\n    scrolling=\"no\"\n    data-name=\"pb-iframe-player\"\n    src=\"https://www.podbean.com/media/player/sy9pc-10c12ef-pb?from=yiiadmin\u0026download=1\u0026version=1\u0026skin=1\u0026btn-skin=107\u0026auto=0\u0026download=1\u0026pbad=1\"\n  \u003e\u003c/iframe\u003e\n\u003c/div\u003e\n\n\u003ch2 id=\"notes\"\u003eNotes\u003c/h2\u003e"},{"title":"#30 - three pillars of observability","date_published":"2021-06-23T18:48:24+02:00","date_modified":"2021-06-12T18:48:24+02:00","id":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/030-observability/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/030-observability/","authors":[{"name":"DevSecOps Talks"}],"content_html":"\u003cp\u003eLogs, 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?\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/company/devsecops-talks/\"\u003eDiscuss the episode or ask us anything on LinkedIn\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"single_player_container\"\u003e\n  \u003ciframe\n    title=\"DevSecOps Talks #30 - Logs, metrics and traces\"\n    height=\"122\"\n    width=\"100%\"\n    style=\"border: none;\"\n    scrolling=\"no\"\n    data-name=\"pb-iframe-player\"\n    src=\"https://www.podbean.com/media/player/hr7vs-1069ebe-pb?from=yiiadmin\u0026download=1\u0026version=1\u0026skin=1\u0026btn-skin=107\u0026auto=0\u0026download=1\u0026pbad=1\"\n  \u003e\u003c/iframe\u003e\n\u003c/div\u003e\n\n\u003ch2 id=\"notes\"\u003eNotes\u003c/h2\u003e"},{"title":"#29 - Unikernels","date_published":"2021-05-19T18:48:24+02:00","date_modified":"2021-05-19T18:48:24+02:00","id":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/029-unikernels/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/029-unikernels/","authors":[{"name":"DevSecOps Talks"}],"content_html":"\u003cp\u003eThis time we are talking unikernles! \u003ca href=\"https://www.linkedin.com/in/ianeyberg/\"\u003eIan Eyberg\u003c/a\u003e from \u003ca href=\"https://nanovms.com/\"\u003eNanoVMs\u003c/a\u003e joins us to discuss how far this technology is from prime time. And it turns out that you don\u0026rsquo;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.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/company/devsecops-talks/\"\u003eDiscuss the episode or ask us anything on LinkedIn\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"single_player_container\"\u003e\n  \u003ciframe\n    title=\"DevSecOps Talks #29 - Unikernels\"\n    height=\"122\"\n    width=\"100%\"\n    style=\"border: none;\"\n    scrolling=\"no\"\n    data-name=\"pb-iframe-player\"\n    src=\"https://www.podbean.com/media/player/uqywg-103e85e-pb?from=yiiadmin\u0026download=1\u0026version=1\u0026skin=1\u0026btn-skin=107\u0026auto=0\u0026download=1\u0026pbad=1\"\n  \u003e\u003c/iframe\u003e\n\u003c/div\u003e\n\n\u003ch2 id=\"notes\"\u003eNotes\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://ops.city\"\u003eOps - tool for managing unikernels\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://nanovms.gitbook.io/ops/aws\"\u003eRunning unikernels on AWS\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e"},{"title":"#28 - Scaling Security","date_published":"2021-04-30T18:48:24+02:00","date_modified":"2021-04-30T18:48:24+02:00","id":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/028-scaling-security/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/028-scaling-security/","authors":[{"name":"DevSecOps Talks"}],"content_html":"\u003cp\u003eThe 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.\u003c/p\u003e\n\u003cp\u003eWe 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.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/company/devsecops-talks/\"\u003eDiscuss the episode or ask us anything on LinkedIn\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"single_player_container\"\u003e\n  \u003ciframe\n    title=\"DevSecOps Talks #28 - Scaling Security\"\n    height=\"122\"\n    width=\"100%\"\n    style=\"border: none;\"\n    scrolling=\"no\"\n    data-name=\"pb-iframe-player\"\n    src=\"https://www.podbean.com/media/player/bcps9-102839d-pb?from=yiiadmin\u0026download=1\u0026version=1\u0026skin=1\u0026btn-skin=107\u0026auto=0\u0026download=1\u0026pbad=1\"\n  \u003e\u003c/iframe\u003e\n\u003c/div\u003e\n\n\u003ch2 id=\"notes\"\u003eNotes\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://cloud.google.com/resource-manager/docs/cloud-platform-resource-hierarchy\"\u003eResource hierarchy on GCP\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://cloud.google.com/files/shifting-left-on-security.pdf\"\u003ePAPER: shifting left on security\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://bisconti.cloud/slides/2021-05-gcp-overview/\"\u003eScale on GCP\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://forsetisecurity.org/\"\u003eForseti security - open source security tools for GCP\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e"},{"title":"#27 - AWS Bottlerocket - Open Source Contrainer OS from AWS. Explained","date_published":"2021-04-11T22:21:20Z","date_modified":"2021-04-11T22:21:20Z","id":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/027-aws-bottlerocket/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/027-aws-bottlerocket/","authors":[{"name":"DevSecOps Talks"}],"content_html":"\u003cp\u003eAWS released AWS Bottlerocket OS in March of 2020, and version 1.0.0 got released in August 2020.\nWhat is it? Should you be using it? What are the benefits?\nIs it ready for prime time? We answer all of those questions during this episode of DevSecOps Talks. Tune in!\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/company/devsecops-talks/\"\u003eDiscuss the episode or ask us anything on LinkedIn\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"single_player_container\"\u003e\n  \u003ciframe\n    title=\"DevSecOps Talks #27 - AWS Bottlerocket - Open Source Contrainer OS from AWS. Explained\"\n    height=\"122\"\n    width=\"100%\"\n    style=\"border: none;\"\n    scrolling=\"no\"\n    data-name=\"pb-iframe-player\"\n    src=\"https://www.podbean.com/media/player/2wvqe-1005fe6-pb?from=yiiadmin\u0026download=1\u0026version=1\u0026skin=1\u0026btn-skin=107\u0026auto=0\u0026download=1\u0026pbad=1\"\n  \u003e\u003c/iframe\u003e\n\u003c/div\u003e\n\n\u003ch2 id=\"notes\"\u003eNotes\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://github.com/bottlerocket-os/bottlerocket\"\u003eAWS Bottlerocket GitHub repo\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://github.com/bottlerocket-os/bottlerocket/blob/develop/SECURITY_FEATURES.md\"\u003eAWS Bottlerocket security features\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://github.com/bottlerocket-os/bottlerocket/blob/develop/SECURITY_GUIDANCE.md\"\u003eAWS Bottlerocket hardening guidelines\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://github.com/terraform-aws-modules/terraform-aws-eks/pull/1296\"\u003eAWS Bottlerocket with Terraform using EKS module\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e"},{"title":"#26 - Git Branching Strategies. Do's and Don'ts","date_published":"2021-03-29T22:21:20Z","date_modified":"2021-03-29T22:21:20Z","id":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/026-git-branching-strategies/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/026-git-branching-strategies/","authors":[{"name":"DevSecOps Talks"}],"content_html":"\u003cp\u003e\u003ca href=\"https://twitter.com/RandomSort\"\u003eJohan Abildskov\u003c/a\u003e(\u003ca href=\"https://devsecops.fm/episodes/semver-or-not-to-semver/\"\u003esee episode 6\u003c/a\u003e) is back,\nand we are talking branching strategies! In particular, why you shouldn\u0026rsquo;t be doing git-flow,\nand what are other options out there. This conversation takes us down memory lane to a more\nbroad discussion about version control systems, mono-repositories, continuous integration,\nand delivery. We hope you will like it!\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/company/devsecops-talks/\"\u003eDiscuss the episode or ask us anything on LinkedIn\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"single_player_container\"\u003e\n  \u003ciframe\n    title=\"DevSecOps Talks #26 - Git Branching Strategies. Do\u0026#39;s and Don\u0026#39;ts\"\n    height=\"122\"\n    width=\"100%\"\n    style=\"border: none;\"\n    scrolling=\"no\"\n    data-name=\"pb-iframe-player\"\n    src=\"https://www.podbean.com/media/player/g723p-ff114e-pb?from=yiiadmin\u0026download=1\u0026version=1\u0026skin=1\u0026btn-skin=107\u0026auto=0\u0026download=1\u0026pbad=1\"\n  \u003e\u003c/iframe\u003e\n\u003c/div\u003e\n\n\u003ch2 id=\"notes\"\u003eNotes\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eJohan Abildskov \u003ca href=\"https://twitter.com/RandomSort\"\u003etwitter\u003c/a\u003e, \u003ca href=\"https://www.linkedin.com/in/johanabildskov/\"\u003elinkedin\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://www.amazon.com/Practical-Git-Confident-Through-Practice/dp/1484262697\"\u003eJohan\u0026rsquo;s book - Practical Git\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://nvie.com/posts/a-successful-git-branching-model/\"\u003eGit-flow\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://trunkbaseddevelopment.com/\"\u003eTrunk Based Development\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://commonflow.org/\"\u003eCommon flow\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://githubflow.github.io\"\u003eGitHub flow\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://about.gitlab.com/topics/version-control/what-is-gitlab-workflow\"\u003eGitLab flow\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e"},{"title":"#25 - All the Things You Wanted to Know About Pulumi.Explained","date_published":"2021-03-11T22:21:20Z","date_modified":"2021-03-11T22:21:20Z","id":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/025-all-the-things-you-wanted-to-know-about-pulumi-explained/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/025-all-the-things-you-wanted-to-know-about-pulumi-explained/","authors":[{"name":"DevSecOps Talks"}],"content_html":"\u003cp\u003eThis time we are joined by \u003ca href=\"https://twitter.com/stack72\"\u003ePaul Stack\u003c/a\u003e (Pulumi developer, former Terraform developer) and podcast friend \u003ca href=\"https://twitter.com/jlarfors\"\u003eJacob Lärfors\u003c/a\u003e to talk about\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eWhat is Pulumi?\u003c/li\u003e\n\u003cli\u003eWhat and who is it for?\u003c/li\u003e\n\u003cli\u003eThe difference between Pulumi and Terraform (and if we should compare them at all)\u003c/li\u003e\n\u003cli\u003eWhat is hard about Pulumi?\u003c/li\u003e\n\u003cli\u003eWhat people ask the most? What are the common confusions?\u003c/li\u003e\n\u003cli\u003eCross-language infra libraries? How is it even possible?!\u003c/li\u003e\n\u003cli\u003eIs there a possibility of a supply chain attack via Pulumi library?\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/company/devsecops-talks/\"\u003eDiscuss the episode or ask us anything on LinkedIn\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"single_player_container\"\u003e\n  \u003ciframe\n    title=\"DevSecOps Talks #25 - All the Things You Wanted to Know About Pulumi.Explained\"\n    height=\"122\"\n    width=\"100%\"\n    style=\"border: none;\"\n    scrolling=\"no\"\n    data-name=\"pb-iframe-player\"\n    src=\"https://www.podbean.com/media/player/mtz9e-fd5eaa?from=yiiadmin\u0026download=1\u0026version=1\u0026skin=1\u0026btn-skin=107\u0026auto=0\u0026download=1\u0026pbad=1\"\n  \u003e\u003c/iframe\u003e\n\u003c/div\u003e\n\n\u003ch2 id=\"notes\"\u003eNotes\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003ePaul Stack \u003ca href=\"https://twitter.com/stack72\"\u003etwitter\u003c/a\u003e, \u003ca href=\"https://www.linkedin.com/in/stack72/\"\u003elinkedin\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003eJacob Lärfors \u003ca href=\"https://twitter.com/jlarfors\"\u003etwitter\u003c/a\u003e, \u003ca href=\"https://www.linkedin.com/in/jlarfors/\"\u003elinkedin\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://www.pulumi.com/\"\u003ePulumi\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://www.youtube.com/watch?v=6UN2aVvIShc\u0026amp;amp;list=PLKxa4AIfm4pXYg8NG50wftI_jzSSQK3ZR\u0026amp;amp;index=13\"\u003ePaul\u0026rsquo;s talk at DevOpsDays Madrid\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://github.com/cnunciato/pulumitron\"\u003ePulumitron\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://github.com/jaxxstorm/ploy\"\u003ePloy\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://pkg.go.dev/github.com/pulumi/pulumi/sdk/v2/go/x/auto\"\u003ePulumi Automation API\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e"},{"title":"#24 - Ways To Protect Yourself From Data Breaches And Mitigate Consequences","date_published":"2021-02-19T13:16:17+01:00","date_modified":"2021-02-19T13:16:17+01:00","id":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/024-data-breaches/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/024-data-breaches/","authors":[{"name":"DevSecOps Talks"}],"content_html":"\u003cp\u003eLast 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).\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/company/devsecops-talks/\"\u003eDiscuss the episode or ask us anything on LinkedIn\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003eWe discuss\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003etips and services to mask your email and fight spam with random emails via catch-all feature\u003c/li\u003e\n\u003cli\u003eimportance of disk encryption\u003c/li\u003e\n\u003cli\u003erecover from ransomware by using backups.\u003c/li\u003e\n\u003cli\u003ewhat to pay attention to avoid phishing emails.\u003c/li\u003e\n\u003cli\u003ecovering your phone number by buying a phone number and forward it to yours.\u003c/li\u003e\n\u003cli\u003euse a credit card generator to avoid giving your real credit card to website that could get hacked.\t\nWe outline workflows on using password managers, activate 2FA, YubiKeys, and encrypting sensitive information.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eWe also tell stories from the trenches about data breaches.\u003c/p\u003e\n\u003cdiv class=\"single_player_container\"\u003e\n  \u003ciframe\n    title=\"DevSecOps Talks #24 - Ways To Protect Yourself From Data Breaches And Mitigate Consequences\"\n    height=\"122\"\n    width=\"100%\"\n    style=\"border: none;\"\n    scrolling=\"no\"\n    data-name=\"pb-iframe-player\"\n    src=\"https://www.podbean.com/media/player/6dpdb-fb863f?from=yiiadmin\u0026download=1\u0026version=1\u0026skin=1\u0026btn-skin=107\u0026auto=0\u0026download=1\u0026pbad=1\"\n  \u003e\u003c/iframe\u003e\n\u003c/div\u003e\n\n\u003ch2 id=\"notes\"\u003eNotes\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://lifeandshell.com/blog/k8s-logs-to-elastic-with-dynamic-ilm-from-annotations/\"\u003eMattias blog post - K8s logs to Elastic\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://github.com/fivexl/kubernetes-events-to-slack/\"\u003eK8S events streamer\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://twitter.com/eey0re/status/970144255745212416\"\u003eTweet about the 3 questions for privacy\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://www.bleepingcomputer.com/\"\u003eBleeping computer - news about security\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://securitynewsletter.co/\"\u003eA security newsletter\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://inteltechniques.com/podcast.html\"\u003eThe privacy, security \u0026amp; OSINT Show\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e"},{"title":"#23 - How Do We Run Kubernetes In The Cloud?","date_published":"2021-02-04T13:16:17+01:00","date_modified":"2021-02-04T13:16:17+01:00","id":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/023-run-kubernetes-cloud/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/023-run-kubernetes-cloud/","authors":[{"name":"DevSecOps Talks"}],"content_html":"\u003cp\u003eHow do you run Kubernetes in the cloud? Still using Kops? Or is it time to jump to the managed offerings?\nWe go through the list of things you might be missing out on if not yet using a managed solution.\nAlso, in this episode - what do you always configure in the k8s cluster? CNI, Ingress, IAM, and even more!\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/company/devsecops-talks/\"\u003eDiscuss the episode or ask us anything on LinkedIn\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"single_player_container\"\u003e\n  \u003ciframe\n    title=\"DevSecOps Talks #23 - How Do We Run Kubernetes In The Cloud?\"\n    height=\"122\"\n    width=\"100%\"\n    style=\"border: none;\"\n    scrolling=\"no\"\n    data-name=\"pb-iframe-player\"\n    src=\"https://www.podbean.com/media/player/jaq7t-f9c73e?from=yiiadmin\u0026download=1\u0026version=1\u0026skin=1\u0026btn-skin=107\u0026auto=0\u0026download=1\u0026pbad=1\"\n  \u003e\u003c/iframe\u003e\n\u003c/div\u003e\n\n\u003ch2 id=\"notes\"\u003eNotes\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://github.com/fivexl/terraform-aws-cloudtrail-to-slack\"\u003eParse AWS CloudTrail events and send alerts to Slack for events that match pre-configured rules\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://github.com/fivexl/terraform-aws-ec2-spot-price\"\u003eAn easy way to always have a fresh Spot Instance price\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://cilium.io\"\u003eCilium\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://cloud.google.com/blog/products/containers-kubernetes/bringing-ebpf-and-cilium-to-google-kubernetes-engine\"\u003eBringing ebpf and cilium to GKE\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://docs.aws.amazon.com/eks/latest/userguide/pod-networking.html\"\u003eAWS VPC CNI ip addresses limitation\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/data-protection.html#encryption-transit\"\u003eList of AWS EC2 families that provide encryption in transit\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://twitter.com/stack72/status/1354894273041342468\"\u003ePulumi cross-language library\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e"},{"title":"#22 - Who are Mattias, Julien and Andrey?","date_published":"2021-01-22T09:15:59Z","date_modified":"2021-01-22T09:15:59Z","id":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/022-who-are-mattias-julien-and-andrey/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/022-who-are-mattias-julien-and-andrey/","authors":[{"name":"DevSecOps Talks"}],"content_html":"\u003cp\u003eIt\u0026rsquo;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.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/company/devsecops-talks/\"\u003eDiscuss the episode or ask us anything on LinkedIn\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"single_player_container\"\u003e\n   \u003ciframe\n     title=\"DevSecOps Talks #22 - Who are Mattias, Julien and Andrey\"\n     height=\"122\"\n     width=\"100%\"\n     style=\"border: none;\"\n     scrolling=\"no\"\n     data-name=\"pb-iframe-player\"\n     src=\"https://www.podbean.com/media/player/8sjgr-f84b81?from=yiiadmin\u0026download=1\u0026version=1\u0026skin=1\u0026btn-skin=107\u0026auto=0\u0026download=1\u0026pbad=1\"\n   \u003e\u003c/iframe\u003e\n \u003c/div\u003e\n\n\u003ch2 id=\"notes\"\u003eNotes\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://www.youtube.com/watch?v=ZSRHeXYDLko\"\u003ePreventing the Collapse of Civilization - Jonathan Blow\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://www.booli.se\"\u003eMattias\u0026rsquo;s employer\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://lifeandshell.com\"\u003eMattias\u0026rsquo;s website\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://bisconti.cloud\"\u003eJulien\u0026rsquo;s website\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://andreydevyatkin.com\"\u003eAndrey\u0026rsquo;s website\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://fivexl.io\"\u003eAndrey\u0026rsquo;s company\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://github.com/fivexl/terraform-aws-ec2-spot-price\"\u003eSpot instances pricing Terraform module\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e"},{"title":"#21 - Surviving AWS Outage","date_published":"2021-01-04T14:20:37+01:00","date_modified":"2021-01-04T14:20:37+01:00","id":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/021-surviving-aws-outage/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/021-surviving-aws-outage/","authors":[{"name":"DevSecOps Talks"}],"content_html":"\u003cp\u003eAWS 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.\nAs a Cloud Engineering practitioner, how do you get yourself and your organization ready for a such turn of events?\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/company/devsecops-talks/\"\u003eDiscuss the episode or ask us anything on LinkedIn\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"single_player_container\"\u003e\n  \u003ciframe\n    title=\"DevSecOps Talks #21 - Surviving AWS Outage\"\n    height=\"122\"\n    width=\"100%\"\n    style=\"border: none;\"\n    scrolling=\"no\"\n    data-name=\"pb-iframe-player\"\n    src=\"https://www.podbean.com/media/player/mpett-f6bc38?from=yiiadmin\u0026download=1\u0026version=1\u0026skin=1\u0026btn-skin=107\u0026auto=0\u0026download=1\u0026pbad=1\"\n  \u003e\u003c/iframe\u003e\n\u003c/div\u003e\n\n\u003ch2 id=\"notes\"\u003eNotes\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://aws.amazon.com/message/11201/\"\u003eAWS postmortem\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://thenewstack.io/chaos-engineering-now-part-of-aws-well-architected-framework/\"\u003eChaos Engineering as a part of AWS Well Architected Framework\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://chaostoolkit.org/\"\u003eChaos Tool Kit\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://katacoda.com/chaostoolkit\"\u003eChaos Tool Kit interactive tutorials\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e"},{"title":"#20 - Monitoring Done Wrong or Dreaming for a Better Monitoring","date_published":"2020-12-07T11:15:59Z","date_modified":"2020-12-07T11:15:59Z","id":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/020-monitoring-done-wrong/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/020-monitoring-done-wrong/","authors":[{"name":"DevSecOps Talks"}],"content_html":"\u003cp\u003eAndrey 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.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/company/devsecops-talks/\"\u003eDiscuss the episode or ask us anything on LinkedIn\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"single_player_container\"\u003e\n  \u003ciframe\n    title=\"DEVSECOPS Talks #20 - Monitoring Done Wrong or Dreaming for a Better Monitoring\"\n    height=\"122\"\n    width=\"100%\"\n    style=\"border: none;\"\n    scrolling=\"no\"\n    data-name=\"pb-iframe-player\"\n    src=\"https://www.podbean.com/media/player/s2m56-f44df9?from=yiiadmin\u0026download=1\u0026version=1\u0026skin=1\u0026btn-skin=107\u0026auto=0\u0026download=1\u0026pbad=1\"\n  \u003e\u003c/iframe\u003e\n\u003c/div\u003e\n\n\u003ch2 id=\"notes\"\u003eNotes\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://wazuh.com/\"\u003eWazuh\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e"},{"title":"#19 - Deleting Resources in the Cloud","date_published":"2020-11-23T12:53:39+02:00","date_modified":"2020-11-23T12:53:39+02:00","id":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/019-deleting-resources-in-the-cloud/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/019-deleting-resources-in-the-cloud/","authors":[{"name":"DevSecOps Talks"}],"content_html":"\u003cp\u003eHow 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. Argo CD is a project that does GitOps and automatically deletes 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.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/company/devsecops-talks/\"\u003eDiscuss the episode or ask us anything on LinkedIn\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"single_player_container\"\u003e\n  \u003ciframe\n    title=\"DEVSECOPS Talks #19 - Deleting Resources in the Cloud\"\n    height=\"122\"\n    width=\"100%\"\n    style=\"border: none;\"\n    scrolling=\"no\"\n    data-name=\"pb-iframe-player\"\n    src=\"https://www.podbean.com/media/player/3i6g8-f31893?from=yiiadmin\u0026download=1\u0026version=1\u0026skin=1\u0026btn-skin=107\u0026auto=0\u0026download=1\u0026pbad=1\"\n  \u003e\u003c/iframe\u003e\n\u003c/div\u003e\n\n\u003ch2 id=\"notes\"\u003eNotes\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://www.elastic.co/beats/auditbeat\"\u003eAuditD\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://graphql-mesh.com/\"\u003eGraphQL-mesh\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://argoproj.github.io/argo-cd/\"\u003eArgo CD for GitOps\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e"},{"title":"#18 - HashiConf Special","date_published":"2020-10-26T13:07:45+02:00","date_modified":"2020-10-26T13:07:45+02:00","id":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/018-hashiconf-special/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/018-hashiconf-special/","authors":[{"name":"DevSecOps Talks"}],"content_html":"\u003cp\u003eInitially, 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\u0026rsquo;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!\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/company/devsecops-talks/\"\u003eDiscuss the episode or ask us anything on LinkedIn\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"single_player_container\"\u003e\n  \u003ciframe\n    title=\"DEVSECOPS Talks #18 - HashiConf Special\"\n    height=\"122\"\n    width=\"100%\"\n    style=\"border: none;\"\n    scrolling=\"no\"\n    data-name=\"pb-iframe-player\"\n    src=\"https://www.podbean.com/media/player/rgphy-f050e0?from=yiiadmin\u0026download=1\u0026version=1\u0026skin=1\u0026btn-skin=107\u0026auto=0\u0026download=1\u0026pbad=1\"\n  \u003e\u003c/iframe\u003e\n\u003c/div\u003e\n\n\u003ch2 id=\"notes\"\u003eNotes\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://www.linkedin.com/in/jlarfors/\"\u003eJacob\u0026rsquo;s LinkedIn\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://verifa.io/insights/nomad-the-workload-orchestrator-you-may-have-missed/\"\u003eJacob\u0026rsquo;s article about Nomad\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://docs.google.com/presentation/d/1_v-Tq2Cz2Yj6n7yaKMr0MSfXTAv5u76ERzFVurK8mNE/edit#slide=id.ga3fa500c4c_0_0\"\u003eHashiConf recap slides\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://blog.cloudflare.com/introducing-cloudflare-one/\"\u003eZero Trust Solution from Cloudflare\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://www.youtube.com/watch?v=JL0Qeq4A6So\"\u003eIntroduction to HashiCorp Waypoint with Armon Dadgar\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://www.youtube.com/watch?v=tUMe7EsXYBQ\"\u003eIntroduction to HashiCorp Boundary with Armon Dadgar\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://youtu.be/YkOOCyK6Yak\"\u003eTGI Kubernetes 137: Waypoint\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e"},{"title":"#17 - Best Practices for Building Docker Images","date_published":"2020-10-12T13:18:01+02:00","date_modified":"2020-10-12T13:18:01+02:00","id":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/017-best-practices-for-building-docker-images/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/017-best-practices-for-building-docker-images/","authors":[{"name":"DevSecOps Talks"}],"content_html":"\u003cp\u003eThis 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!\u003c/p\u003e\n\u003cp\u003eThe topic of this episode is building Docker images — automation, security, best practices.\u003c/p\u003e\n\u003cp\u003eIn this episode, we discuss: saving money with T3a family, building Docker images locally and in CI, setting up daemonless 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.\u003c/p\u003e\n\u003cp\u003eSome of the information overlaps with \u003ca href=\"https://devsecops.fm/episodes/003-docker-secure-build/\"\u003eepisode #3\u003c/a\u003e but greatly extends the information provided before.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/company/devsecops-talks/\"\u003eDiscuss the episode or ask us anything on LinkedIn\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"single_player_container\"\u003e\n  \u003ciframe\n    title=\"DEVSECOPS Talks #17 - Best Practices for Building Docker Images\"\n    height=\"122\"\n    width=\"100%\"\n    style=\"border: none;\"\n    scrolling=\"no\"\n    data-name=\"pb-iframe-player\"\n    src=\"https://www.podbean.com/media/player/w79in-ef1a02?from=yiiadmin\u0026download=1\u0026version=1\u0026skin=1\u0026btn-skin=107\u0026auto=0\u0026download=1\u0026pbad=1\"\n  \u003e\u003c/iframe\u003e\n\u003c/div\u003e\n\n\u003ch2 id=\"notes\"\u003eNotes\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://github.com/moby/buildkit/blob/master/frontend/dockerfile/docs/experimental.md\"\u003eDocker BuildKit\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://github.com/genuinetools/img\"\u003eimg\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://github.com/GoogleContainerTools/kaniko\"\u003ekaniko\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://github.com/containers/buildah\"\u003ebuildah\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://docs.docker.com/develop/develop-images/build_enhancements/#new-docker-build-secret-information\"\u003eUsing Secrets in build\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://github.com/docker-slim/docker-slim\"\u003eDocker Slim\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://github.com/GoogleContainerTools/distroless\"\u003edistroless\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://www.docker.com/pricing/resource-consumption-updates\"\u003eDocker resource consumption\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://github.com/docker/distribution\"\u003eContainer registry to self-host\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://awesome-docker.netlify.app/\"\u003eAwesome Docker\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e"},{"title":"#16 - Do You Need a Staging Environment?","date_published":"2020-09-29T12:33:07+01:00","date_modified":"2020-09-29T12:33:07+01:00","id":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/016-do-you-need-a-staging-environment/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/016-do-you-need-a-staging-environment/","authors":[{"name":"DevSecOps Talks"}],"content_html":"\u003cp\u003eIn this episode, we discuss options for splitting your deployment stages. We hear people coming up with all possible types 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 you need less? Why not deploy directly to production using some fancy technique? Put it simply — stage or not to stage?\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/company/devsecops-talks/\"\u003eDiscuss the episode or ask us anything on LinkedIn\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"single_player_container\"\u003e\n  \u003ciframe\n    title=\"DEVSECOPS Talks #16 - Do You Need a Staging Environment?\"\n    height=\"122\"\n    width=\"100%\"\n    style=\"border: none;\"\n    scrolling=\"no\"\n    data-name=\"pb-iframe-player\"\n    src=\"https://www.podbean.com/media/player/3amzg-ed3906?from=yiiadmin\u0026download=1\u0026version=1\u0026skin=1\u0026btn-skin=107\u0026auto=0\u0026download=1\u0026pbad=1\"\n  \u003e\u003c/iframe\u003e\n\u003c/div\u003e"},{"title":"#15 - Remote Work Security","date_published":"2020-08-31T13:18:21+02:00","date_modified":"2020-08-31T13:18:21+02:00","id":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/015-remote-work-security/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/015-remote-work-security/","authors":[{"name":"DevSecOps Talks"}],"content_html":"\u003cp\u003eLet\u0026rsquo;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.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/company/devsecops-talks/\"\u003eDiscuss the episode or ask us anything on LinkedIn\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"single_player_container\"\u003e\n  \u003ciframe\n    title=\"DEVSECOPS Talks #15 - Remote Work Security\"\n    height=\"122\"\n    width=\"100%\"\n    style=\"border: none;\"\n    scrolling=\"no\"\n    data-name=\"pb-iframe-player\"\n    src=\"https://www.podbean.com/media/player/yyb4u-ebec47?from=yiiadmin\u0026download=1\u0026version=1\u0026skin=1\u0026btn-skin=107\u0026auto=0\u0026download=1\u0026pbad=1\"\n  \u003e\u003c/iframe\u003e\n\u003c/div\u003e\n\n\u003ch2 id=\"notes\"\u003eNotes\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://cloud.google.com/beyondcorp/#researchPapers\"\u003eBeyondCorp paper from Google\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://www.zdnet.com/article/china-is-now-blocking-all-encrypted-https-traffic-using-tls-1-3-and-esni/\"\u003eChina is now blocking all encrypted HTTPS traffic that uses TLS 1.3 and ESNI\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://linkerd.io/2/features/automatic-mtls/\"\u003eLinkerd mutual TLS\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://docs.cilium.io/en/v1.8/intro/\"\u003eCilium\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://smallstep.com/blog/use-ssh-certificates/\"\u003eSSH certificates\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://www.wireguard.com/\"\u003eWireGuard VPN\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://www.yubico.com/\"\u003eYubiKey\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e"},{"title":"#14 - Theory of Constraint","date_published":"2020-08-30T19:08:55+02:00","date_modified":"2020-08-30T19:08:55+02:00","id":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/014-theory-of-constraint/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/014-theory-of-constraint/","authors":[{"name":"DevSecOps Talks"}],"content_html":"\u003cp\u003eThis 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.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/company/devsecops-talks/\"\u003eDiscuss the episode or ask us anything on LinkedIn\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"single_player_container\"\u003e\n  \u003ciframe\n    title=\"DEVSECOPS Talks #14 - Theory of Constraint\"\n    height=\"122\"\n    width=\"100%\"\n    style=\"border: none;\"\n    scrolling=\"no\"\n    data-name=\"pb-iframe-player\"\n    src=\"https://www.podbean.com/media/player/sd8ex-e96dd2?from=yiiadmin\u0026download=1\u0026version=1\u0026skin=1\u0026btn-skin=107\u0026auto=0\u0026download=1\u0026pbad=1\"\n  \u003e\u003c/iframe\u003e\n\u003c/div\u003e\n\n\u003ch2 id=\"notes\"\u003eNotes\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://www.linkedin.com/in/henrikrenehoegh/\"\u003eHenrik Høegh\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://en.wikipedia.org/wiki/The_Goal_(novel)\"\u003eThe Goal by Eliyahu Goldratt\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://agilemanifesto.org/\"\u003eManifesto for Agile Software Development\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://itrevolution.com/book/the-phoenix-project/\"\u003eThe Phoenix Project\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://www.audible.co.uk/pd/Beyond-the-Phoenix-Project-Audiobook/B07B7CH7FQ\"\u003eBeyond The Phoenix Project\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e"},{"title":"#13 - All You Need to Know About Setting Up HashiCorp Vault","date_published":"2020-08-17T10:13:03+02:00","date_modified":"2020-08-17T10:13:03+02:00","id":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/013-all-you-need-to-know-about-setting-up-hashicorp-vault/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/013-all-you-need-to-know-about-setting-up-hashicorp-vault/","authors":[{"name":"DevSecOps Talks"}],"content_html":"\u003cp\u003eMattias wants to set up HashiCorp Vault and quizzes Andrey on how to do that. We cover a lot of ground — from basic Vault concepts to setting it up and hardening.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/company/devsecops-talks/\"\u003eDiscuss the episode or ask us anything on LinkedIn\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"single_player_container\"\u003e\n  \u003ciframe\n    title=\"DEVSECOPS Talks #13 - All You Need to Know About Setting Up HashiCorp Vault\"\n    height=\"122\"\n    width=\"100%\"\n    style=\"border: none;\"\n    scrolling=\"no\"\n    data-name=\"pb-iframe-player\"\n    src=\"https://www.podbean.com/media/player/byvek-e76ab5?from=yiiadmin\u0026download=1\u0026version=1\u0026skin=1\u0026btn-skin=107\u0026auto=0\u0026download=1\u0026pbad=1\"\n  \u003e\u003c/iframe\u003e\n\u003c/div\u003e\n\n\u003ch2 id=\"notes\"\u003eNotes\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://www.hashicorp.com/resources/vault-configuration-as-code-via-terraform-stories-from-the-trenches/\"\u003eAndrey\u0026rsquo;s presentation at HashiConf EU Digital 2020\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://www.youtube.com/watch?v=VYfl-DpZ5wM\"\u003eIntroduction to HashiCorp Vault\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://learn.hashicorp.com/tutorials/vault/production-hardening\"\u003eHashiCorp Vault hardening guide\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://learn.hashicorp.com/tutorials/vault/reference-architecture\"\u003eHashiCorp Vault reference architecture\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e"},{"title":"#12 - Scale vs Scaling","date_published":"2020-08-01T14:12:15+02:00","date_modified":"2020-08-01T14:12:15+02:00","id":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/012-scale-vs-scaling/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/012-scale-vs-scaling/","authors":[{"name":"DevSecOps Talks"}],"content_html":"\u003cp\u003eJulien 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 for 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.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/company/devsecops-talks/\"\u003eDiscuss the episode or ask us anything on LinkedIn\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"single_player_container\"\u003e\n  \u003ciframe\n    title=\"DEVSECOPS Talks #12 - Scale vs Scaling\"\n    height=\"122\"\n    width=\"100%\"\n    style=\"border: none;\"\n    scrolling=\"no\"\n    data-name=\"pb-iframe-player\"\n    src=\"https://www.podbean.com/media/player/4agzz-e53fad?from=yiiadmin\u0026download=1\u0026version=1\u0026skin=1\u0026btn-skin=107\u0026auto=0\u0026download=1\u0026pbad=1\"\n  \u003e\u003c/iframe\u003e\n\u003c/div\u003e\n\n\u003ch2 id=\"notes\"\u003eNotes\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://bisconti.cloud/posts/what-scale-means/\"\u003eJulien\u0026rsquo;s blog post about scale\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://en.wikipedia.org/wiki/C10k_problem\"\u003ec10k problem\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e"},{"title":"#11 - AWS Security Maturity Roadmap","date_published":"2020-07-09T14:12:15+02:00","date_modified":"2020-07-09T14:12:15+02:00","id":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/011-aws-security-maturity-roadmap/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/011-aws-security-maturity-roadmap/","authors":[{"name":"DevSecOps Talks"}],"content_html":"\u003cp\u003eThis 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.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/company/devsecops-talks/\"\u003eDiscuss the episode or ask us anything on LinkedIn\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"single_player_container\"\u003e\n  \u003ciframe\n    title=\"DEVSECOPS Talks #11 - AWS Security Maturity Roadmap\"\n    height=\"122\"\n    width=\"100%\"\n    style=\"border: none;\"\n    scrolling=\"no\"\n    data-name=\"pb-iframe-player\"\n    src=\"https://www.podbean.com/media/player/89fur-e2a0ad?from=yiiadmin\u0026download=1\u0026version=1\u0026skin=1\u0026btn-skin=107\u0026auto=0\u0026download=1\u0026pbad=1\"\n  \u003e\u003c/iframe\u003e\n\u003c/div\u003e\n\n\u003ch2 id=\"notes\"\u003eNotes\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://summitroute.com/blog/2020/05/21/aws_security_maturity_roadmap_2020\"\u003eAWS Security Maturity Roadmap 2020 by SummitRoute\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e"},{"title":"#10 - Are We Wrong About Terragrunt?","date_published":"2020-06-18T11:10:29+02:00","date_modified":"2020-06-18T11:10:29+02:00","id":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/010-are-we-wrong-about-terragrunt/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/010-are-we-wrong-about-terragrunt/","authors":[{"name":"DevSecOps Talks"}],"content_html":"\u003cp\u003eOur guest speaker is \u003ca href=\"https://www.linkedin.com/in/antonbabenko/\"\u003eAnton Babenko\u003c/a\u003e, he is a DevSecOps Talks podcast fan, AWS Community Hero, Terraform fanatic, HashiCorp Ambassador and a prolific open source contributor. After listening to episode \u003ca href=\"https://devsecops.fm/episodes/009-terraform-in-ci/\"\u003e#9 Terraform in CI\u003c/a\u003e and \u003ca href=\"https://devsecops.fm/episodes/001-infrastructure-as-code/\"\u003e#1 Infrastructure as Code\u003c/a\u003e, Anton decided that enough is enough and volunteered to give his point of view on Terragrunt since he thought that we are missing a few important points. In this episode, we are discussing the use cases of \u003ca href=\"https://terragrunt.gruntwork.io/\"\u003eTerragrunt\u003c/a\u003e, a wrapper around Terraform for working with multiple environments and modules.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/company/devsecops-talks/\"\u003eDiscuss the episode or ask us anything on LinkedIn\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"single_player_container\"\u003e\n  \u003ciframe\n    title=\"DEVSECOPS Talks #10 - Are We Wrong About Terragrunt?\"\n    height=\"122\"\n    width=\"100%\"\n    style=\"border: none;\"\n    scrolling=\"no\"\n    data-name=\"pb-iframe-player\"\n    src=\"https://www.podbean.com/media/player/xxhih-e13125?from=yiiadmin\u0026download=1\u0026version=1\u0026skin=1\u0026btn-skin=107\u0026auto=0\u0026download=1\u0026pbad=1\"\n  \u003e\u003c/iframe\u003e\n\u003c/div\u003e\n\n\u003ch2 id=\"notes\"\u003eNotes\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://github.com/antonbabenko/terraform-aws-devops\"\u003eAnton Babenko\u0026rsquo;s projects and social links\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://github.com/antonbabenko/tfvars-annotations\"\u003etfvars-annotations\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://github.com/antonbabenko/terragrunt-reference-architecture\"\u003eTerragrunt Reference Architecture\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://github.com/terraform-aws-modules/meta\"\u003eMeta-configurations for terraform-aws-modules\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://serverless.tf\"\u003eDoing serverless with Terraform\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e"},{"title":"#9 - Terraform in CI","date_published":"2020-06-05T08:24:41+02:00","date_modified":"2020-06-05T08:24:41+02:00","id":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/009-terraform-in-ci/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/009-terraform-in-ci/","authors":[{"name":"DevSecOps Talks"}],"content_html":"\u003cp\u003eHow 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.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/company/devsecops-talks/\"\u003eDiscuss the episode or ask us anything on LinkedIn\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003eWe start the episode by catching up with what we\u0026rsquo;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.\u003c/p\u003e\n\u003cdiv class=\"single_player_container\"\u003e\n  \u003ciframe\n    title=\"DEVSECOPS Talks #9 - Terraform in CI\"\n    height=\"122\"\n    width=\"100%\"\n    style=\"border: none;\"\n    scrolling=\"no\"\n    data-name=\"pb-iframe-player\"\n    src=\"https://www.podbean.com/media/player/nt2wv-ded704?from=yiiadmin\u0026download=1\u0026version=1\u0026skin=1\u0026btn-skin=107\u0026auto=0\u0026download=1\u0026pbad=1\"\n  \u003e\u003c/iframe\u003e\n\u003c/div\u003e\n\n\u003ch2 id=\"notes\"\u003eNotes\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://www.runatlantis.io/\"\u003eAtlantis - Terraform Pull Request Automation\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://www.hashicorp.com/resources/hashicorp-announces-terraform-saas-free-tier/\"\u003eHashiCorp Announces Free Tier for Terraform SaaS\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://www.terraform.io/docs/backends/types/index.html\"\u003eTerraform Backend Types\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://www.terraform.io/docs/extend/best-practices/sensitive-state.html\"\u003eHandling Secrets in Terraform state\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e"},{"title":"#8 - DevOps What","date_published":"2020-05-23T11:32:29+02:00","date_modified":"2020-05-23T11:32:29+02:00","id":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/008-devops-what/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/008-devops-what/","authors":[{"name":"DevSecOps Talks"}],"content_html":"\u003cp\u003eAndrey 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).\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/company/devsecops-talks/\"\u003eDiscuss the episode or ask us anything on LinkedIn\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"single_player_container\"\u003e\n  \u003ciframe\n    title=\"DEVSECOPS Talks #8 - DevOps What\"\n    height=\"122\"\n    width=\"100%\"\n    style=\"border: none;\"\n    scrolling=\"no\"\n    data-name=\"pb-iframe-player\"\n    src=\"https://www.podbean.com/media/player/7i4k8-dd9d32?from=yiiadmin\u0026download=1\u0026version=1\u0026skin=1\u0026btn-skin=107\u0026auto=0\u0026download=1\u0026pbad=1\"\n  \u003e\u003c/iframe\u003e\n\u003c/div\u003e\n\n\u003ch2 id=\"notes\"\u003eNotes\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://www.youtube.com/watch?v=LdOe18KhtT4\"\u003e\u0026ldquo;10+ Deploys Per Day: Dev and Ops Cooperation at Flickr\u0026rdquo;\u003c/a\u003e: Velocity Conference 2009 - talk by John Allspaw and Paul Hammond\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-programmer/\"\u003eDon\u0026rsquo;t Call Yourself A Programmer, And Other Career Advice\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"http://www.jedi.be/blog/2008/07/23/agile-infrastructure-and-operations-how-infragile-are-you-2/\"\u003eBlog post: Agile Infrastructure and Operations: How Infragile are you?\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"http://www.jedi.be/blog/2009/03/05/2009-the-year-of-the-agile-sysadmin/\"\u003eBlog post: 2009: The year of the Agile Sysadmin?\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"http://www.jedi.be/blog/2009/12/22/charting-out-devops-ideas/\"\u003eBlog post: Charting out devops ideas\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://legacy.devopsdays.org/events/2009-ghent/program\"\u003eFirst DevOpsDays conference program\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://www.infoq.com/interviews/debois-devops/\"\u003eInterview(video): Patrick Debois on the State of DevOps\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://cloud.google.com/devops/state-of-devops/\"\u003eState of DevOps 2019 by DORA\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://landing.google.com/sre/\"\u003eWhat is SRE?\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://teamtopologies.com/key-concepts\"\u003eWhat is Enabling Team (based on Team Topologies)\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e"},{"title":"#7 - How Do We Learn","date_published":"2020-05-04T20:40:06+01:00","date_modified":"2020-05-04T20:40:06+01:00","id":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/007-how-do-we-learn/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/007-how-do-we-learn/","authors":[{"name":"DevSecOps Talks"}],"content_html":"\u003cp\u003eIn 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.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/company/devsecops-talks/\"\u003eDiscuss the episode or ask us anything on LinkedIn\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"single_player_container\"\u003e\n  \u003ciframe\n    title=\"DEVSECOPS Talks #7 - How Do We Learn\"\n    height=\"122\"\n    width=\"100%\"\n    style=\"border: none;\"\n    scrolling=\"no\"\n    data-name=\"pb-iframe-player\"\n    src=\"https://www.podbean.com/media/player/3hv89-db5d56?from=yiiadmin\u0026download=1\u0026version=1\u0026skin=1\u0026btn-skin=107\u0026auto=0\u0026download=1\u0026pbad=1\"\n  \u003e\u003c/iframe\u003e\n\u003c/div\u003e\n\n\u003ch2 id=\"notes\"\u003eNotes\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://acloud.guru/\"\u003eA Cloud Guru\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://linuxacademy.com/\"\u003eLinux Academy\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://www.oreilly.com/\"\u003eO\u0026rsquo;Reilly Safari\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e"},{"title":"#6 - SemVer or Not to SemVer","date_published":"2020-04-20T00:00:00Z","date_modified":"2020-04-20T00:00:00Z","id":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/006-semver-or-not-to-semver/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/006-semver-or-not-to-semver/","authors":[{"name":"DevSecOps Talks"}],"content_html":"\u003cp\u003eThis time \u003ca href=\"https://twitter.com/randomsort\"\u003eJohan Abildskov\u003c/a\u003e, a Senior Consultant with \u003ca href=\"https://www.praqma.com\"\u003ePraqma/Eficode\u003c/a\u003e, 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.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/company/devsecops-talks/\"\u003eDiscuss the episode or ask us anything on LinkedIn\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"single_player_container\"\u003e\n  \u003ciframe\n    title=\"DEVSECOPS Talks #6 - SemVer or Not to SemVer\"\n    height=\"122\"\n    width=\"100%\"\n    style=\"border: none;\"\n    scrolling=\"no\"\n    data-name=\"pb-iframe-player\"\n    src=\"https://www.podbean.com/media/player/6bbm3-db5d30?from=yiiadmin\u0026download=1\u0026version=1\u0026skin=1\u0026btn-skin=107\u0026auto=0\u0026download=1\u0026pbad=1\"\n  \u003e\u003c/iframe\u003e\n\u003c/div\u003e\n\n\u003chr\u003e\n\u003cdiv style=\"position: relative; padding-bottom: 56.25%; height: 0; overflow: hidden;\"\u003e\n      \u003ciframe allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share; fullscreen\" loading=\"eager\" referrerpolicy=\"strict-origin-when-cross-origin\" src=\"https://www.youtube.com/embed/oyLBGkS5ICk?autoplay=0\u0026amp;controls=1\u0026amp;end=0\u0026amp;loop=0\u0026amp;mute=0\u0026amp;start=0\" style=\"position: absolute; top: 0; left: 0; width: 100%; height: 100%; border:0;\" title=\"YouTube video\"\u003e\u003c/iframe\u003e\n    \u003c/div\u003e\n\n\u003ch2 id=\"notes\"\u003eNotes\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://gohugo.io\"\u003eHugo web site generator\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://semver.org\"\u003eSemVer specification\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003eJohan\u0026rsquo;s contact:\n\u003cul\u003e\n\u003cli\u003eTwitter: \u003ca href=\"https://twitter.com/randomsort\"\u003erandomsort\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003eLinkedIn: \u003ca href=\"https://www.linkedin.com/in/johanabildskov\"\u003eJohan\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003eOpinionated Git by Johan: \u003ca href=\"https://opinionatedgit.com\"\u003ewebsite\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e"},{"title":"#5 - What Are We Working On","date_published":"2020-04-06T00:00:00Z","date_modified":"2020-04-06T00:00:00Z","id":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/005-what-are-we-working-on/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/005-what-are-we-working-on/","authors":[{"name":"DevSecOps Talks"}],"content_html":"\u003cp\u003eWe had a few potential 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. As it turns out there were quite a lot to discuss. Tune in for tips on auditing SSH sessions through a jump host, preventing downloads from AWS S3 even if you got read access, credentials in Git repository, why you should (or should not) use Kubernetes and more.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/company/devsecops-talks/\"\u003eDiscuss the episode or ask us anything on LinkedIn\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"single_player_container\"\u003e\n  \u003ciframe\n    title=\"DEVSECOPS Talks #5 - What Are We Working On\"\n    height=\"122\"\n    width=\"100%\"\n    style=\"border: none;\"\n    scrolling=\"no\"\n    data-name=\"pb-iframe-player\"\n    src=\"https://www.podbean.com/media/player/w35eg-d87a2b?from=yiiadmin\u0026download=1\u0026version=1\u0026skin=1\u0026btn-skin=107\u0026auto=0\u0026download=1\u0026pbad=1\"\n  \u003e\u003c/iframe\u003e\n\u003c/div\u003e\n\n\u003ch2 id=\"summary\"\u003eSummary\u003c/h2\u003e\n\u003cp\u003eIn this free-form early episode of DevSecOps Talks, a casual \u0026ldquo;what have you been up to\u0026rdquo; 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\u0026rsquo;s BeyondCorp model makes VPNs look like a relic.\u003c/p\u003e\n\u003ch2 id=\"key-topics\"\u003eKey Topics\u003c/h2\u003e\n\u003ch3 id=\"ssh-session-logging-bastion-hosts-and-compliance-visibility\"\u003eSSH session logging, bastion hosts, and compliance visibility\u003c/h3\u003e\n\u003cp\u003eThe 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.\u003c/p\u003e\n\u003cp\u003eBut the drawbacks surface quickly. Session Manager logs users in as a generic SSM agent user with \u003ccode\u003e/usr/bin\u003c/code\u003e 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.\u003c/p\u003e\n\u003cp\u003eThe 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.\u003c/p\u003e\n\u003cp\u003eThat leads into alternative approaches. An AWS blog post describes forcing SSH connections through the Unix \u003ccode\u003escript\u003c/code\u003e 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 \u003ca href=\"https://github.com/Scribery/tlog\"\u003etlog\u003c/a\u003e, 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.\u003c/p\u003e\n\u003cp\u003eThe 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.\u003c/p\u003e\n\u003ch3 id=\"monitoring-user-activity-without-drowning-in-logs\"\u003eMonitoring user activity without drowning in logs\u003c/h3\u003e\n\u003cp\u003eThe 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.\u003c/p\u003e\n\u003cp\u003eThat 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: \u0026ldquo;Should you have SSH with the password at all? You should have a key.\u0026rdquo; The point stands — without careful tuning, even sensible alerts generate noise faster than teams can act on them.\u003c/p\u003e\n\u003cp\u003eThe exchange captures a recurring DevSecOps reality: collecting telemetry is the easy part; turning it into something actionable is where most teams get stuck.\u003c/p\u003e\n\u003ch3 id=\"s3-bucket-security-public-access-controls-and-kms-encryption-surprises\"\u003eS3 bucket security, public access controls, and KMS encryption surprises\u003c/h3\u003e\n\u003cp\u003eThe conversation shifts to AWS S3 security. Public buckets remain a common source of breaches, but AWS now offers \u003ca href=\"https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-control-block-public-access.html\"\u003eS3 Block Public Access\u003c/a\u003e — account- and bucket-level settings that prevent public access regardless of individual object ACLs. In Terraform, this is a dedicated resource block.\u003c/p\u003e\n\u003cp\u003eThe 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 \u003ccode\u003ekms:Decrypt\u003c/code\u003e permission on that specific key.\u003c/p\u003e\n\u003cp\u003eThis became a real problem in a cross-account, cross-region workflow involving Go Lambda binaries. Go Lambdas require the deployment artifact to reside in the same region as the function. The team was copying artifacts between accounts and regions, had granted S3 read permissions, but downloads kept failing. CloudTrail logs revealed the real culprit: \u0026ldquo;I cannot decrypt.\u0026rdquo; The consumers lacked KMS key access. In that case, the fix was switching to SSE-S3 since the artifacts did not require the stronger protection of a customer-managed key.\u003c/p\u003e\n\u003cp\u003eThe host is careful to note that AWS documentation on cross-account S3 access does not prominently flag this encryption interaction — a gap that can cost teams hours of debugging.\u003c/p\u003e\n\u003ch3 id=\"plaintext-secrets-in-git-a-frighteningly-common-anti-pattern\"\u003ePlaintext secrets in Git: a frighteningly common anti-pattern\u003c/h3\u003e\n\u003cp\u003eOne of the most memorable segments comes when a host describes reviewing an application stack and finding service account keys committed in cleartext in the repository root. The repository also contained a large configuration file with usernames, passwords, API credentials for mail services, login providers, and multiple environments (dev, prod) — all in plain text.\u003c/p\u003e\n\u003cp\u003eBut the worst part: for local development, the team SSH-tunneled into the production SQL server, mapping remote port 3306 to local port 3307. An SSH key providing direct access to the production database was sitting right there in the repo.\u003c/p\u003e\n\u003cp\u003eThe reaction is immediate — this is exactly the kind of setup that accumulates when convenience wins over security for too long. But rather than proposing a risky teardown, the host outlines an incremental migration plan:\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eDockerize the local development stack\u003c/strong\u003e so developers can run everything locally without production keys\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eMove secrets into the CI/CD pipeline\u003c/strong\u003e, injecting them only at build and deploy time\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eSeparate environments\u003c/strong\u003e so test clusters get test credentials and production secrets never touch developer machines\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003eAndrey pushes the thinking further: injecting secrets at build time is still risky because anyone who gets the Docker image gets the secrets. The better model is \u003cstrong\u003eruntime secret retrieval\u003c/strong\u003e — workloads authenticate dynamically at startup and fetch only the secrets they need. HashiCorp Vault is the concrete example: in a Kubernetes environment, a pod uses its Kubernetes service account to authenticate to Vault, obtains a short-lived token, and retrieves static or dynamic secrets. If someone steals the image and runs it outside the cluster, they cannot authenticate and get nothing.\u003c/p\u003e\n\u003ch3 id=\"vault-versus-cloud-native-secret-management\"\u003eVault versus cloud-native secret management\u003c/h3\u003e\n\u003cp\u003eThe secrets discussion expands into a broader comparison. Andrey, who has been doing public speaking about Vault and fielding consulting requests around it, frames the choice pragmatically.\u003c/p\u003e\n\u003cp\u003eFor \u003cstrong\u003ehybrid-cloud or multi-cloud\u003c/strong\u003e environments, Vault is likely the best option because it provides a unified interface for secret management, dynamic credentials, and synchronization across providers.\u003c/p\u003e\n\u003cp\u003eFor \u003cstrong\u003esingle-cloud commitments\u003c/strong\u003e — say, all-in on AWS — native services can cover many of the same use cases: AWS STS for temporary credentials, RDS IAM authentication for database logins, AWS Secrets Manager (which may even be running Vault underneath, as one host speculates), and AWS Certificate Manager for TLS certificates. If the organization is not going multi-cloud, the overhead of running Vault may not be justified.\u003c/p\u003e\n\u003cp\u003eThe recommendation is not ideological. It depends on architecture, portability needs, and operational complexity.\u003c/p\u003e\n\u003ch3 id=\"when-vault-works-technically-but-fails-organizationally\"\u003eWhen Vault works technically but fails organizationally\u003c/h3\u003e\n\u003cp\u003eJulien Bisconti adds an important caveat from experience. He describes deploying Vault in a multi-availability-zone setup with full redundancy — technically solid. But the project \u0026ldquo;went to a halt completely\u0026rdquo; when it hit governance questions: who should access what, under which rules, and who owns the policies. It became a political war, and the entire deployment had to be rolled back.\u003c/p\u003e\n\u003cp\u003eThe lesson: security tools are good at automating technical workflows, but if the underlying organizational process is broken, you automate a broken process. Security, monitoring, deployment, and access control are deeply entangled, and tooling alone cannot untangle them.\u003c/p\u003e\n\u003ch3 id=\"security-tooling-fails-because-developers-cannot-use-it\"\u003eSecurity tooling fails because developers cannot use it\u003c/h3\u003e\n\u003cp\u003eJulien brings the strongest developer-empathy argument of the episode. Developers do not ignore security because they are careless — they bypass it because secure workflows are too awkward under delivery pressure. A manager does not understand why the developer is blocked, pressure mounts, and the result is \u003ccode\u003e// just hardcode that here, I don't care, it works\u003c/code\u003e.\u003c/p\u003e\n\u003cp\u003eEven simple tasks illustrate the problem. Julien asks: can you generate an SSL certificate with OpenSSL from memory right now? Most engineers cannot — it is something they do every few months and have to look up each time. He references the famous \u003ca href=\"https://xkcd.com/1168/\"\u003eXKCD comic\u003c/a\u003e about entering the correct \u003ccode\u003etar\u003c/code\u003e command with ten seconds left.\u003c/p\u003e\n\u003cp\u003eThis evolves into a philosophical observation. One host identifies as a \u0026ldquo;tool builder\u0026rdquo; rather than a \u0026ldquo;product builder\u0026rdquo; — someone who enjoys building mechanisms but does not always think deeply about end-user experience. That mindset, common among infrastructure and security engineers, may explain why so many DevSecOps tools are powerful but painful to adopt. The gap is not in capability but in usability.\u003c/p\u003e\n\u003ch3 id=\"vpns-zero-trust-and-the-beyondcorp-model\"\u003eVPNs, zero trust, and the BeyondCorp model\u003c/h3\u003e\n\u003cp\u003eJulien argues that VPNs are an increasingly painful abstraction. Even Cisco — the company that essentially built enterprise VPN technology — had to raise capacity limits during the COVID-19 pandemic because their own infrastructure could not handle the load. Split tunneling introduces its own vulnerabilities, and full-tunnel VPN creates a bottleneck for everything.\u003c/p\u003e\n\u003cp\u003eHe points to Google\u0026rsquo;s \u003ca href=\"https://research.google/pubs/pub43231/\"\u003eBeyondCorp\u003c/a\u003e model, published in 2014, which established the principle that network location should not determine access. The analogy: do you build a castle with walls where anyone inside has full access, or do you put a guard in every room checking credentials? The latter — zero trust — is harder to implement, but it limits blast radius and removes the binary \u0026ldquo;in or out\u0026rdquo; problem.\u003c/p\u003e\n\u003cp\u003eAndrey connects this to the emerging service mesh ecosystem. Technologies like \u003ca href=\"https://developer.hashicorp.com/consul/docs/connect\"\u003eConsul Connect\u003c/a\u003e implement zero-trust networking at the application level with mutual TLS and identity-based authorization. The hosts note that the service mesh space is still fragmented — just as there was a \u0026ldquo;war of orchestrators\u0026rdquo; before Kubernetes emerged as the default, there is now a \u0026ldquo;war of service meshes\u0026rdquo; still playing out.\u003c/p\u003e\n\u003ch3 id=\"kubernetes-hype-versus-simpler-orchestration\"\u003eKubernetes hype versus simpler orchestration\u003c/h3\u003e\n\u003cp\u003eA significant portion of the episode is a productive debate about orchestration choices. Andrey argues strongly against defaulting to Kubernetes. He describes a hybrid-cloud project in Africa running the full HashiCorp stack: Consul for service discovery, configuration, and networking; Nomad for workload scheduling. A team member with relatively little experience got the stack up and running in days.\u003c/p\u003e\n\u003cp\u003eAndrey outlines the operational weight of Kubernetes: cluster version upgrades where in-place upgrades may skip new security defaults (making full cluster recreation the recommended path), autoscaler configuration layers (pod autoscaler, cluster autoscaler, resource limits), ingress management, YAML sprawl from Helm charts, and a platform that evolves so rapidly it demands continuous learning. He especially warns against running databases in Kubernetes — the statefulness adds pain.\u003c/p\u003e\n\u003cp\u003eFor single-cloud AWS, he argues that ECS is often the better choice: the control plane is free (or nearly so), the per-node overhead is minimal compared to Kubernetes, and AWS handles the operational burden.\u003c/p\u003e\n\u003cp\u003eMattias pushes back with a practical counterpoint. Kubernetes provides a consistent platform for diverse workloads — containers, databases, monitoring, custom jobs — all managed through the same interface. Helm charts for common components like nginx-ingress, cert-manager, and external-dns make the ecosystem approachable. The value is in standardization and adaptability.\u003c/p\u003e\n\u003cp\u003eThe hosts also note GKE\u0026rsquo;s pricing evolution: Google introduced a per-cluster management fee (roughly $0.10/hour per control plane) to discourage sprawl and encourage consolidation — a signal that even managed Kubernetes has real costs.\u003c/p\u003e\n\u003cp\u003eThe disagreement is honest but constructive. The shared conclusion: start with what the business needs, then pick the simplest tool that gets you there. \u0026ldquo;The best battle is the battle you don\u0026rsquo;t fight.\u0026rdquo; And as Julien notes, teams that avoid the Kubernetes default often demonstrate deeper architectural thinking — choosing based on the hype is an insurance policy, but it is not the same as choosing based on needs.\u003c/p\u003e\n\u003ch3 id=\"slack-bots-workflow-automation-and-the-security-surface\"\u003eSlack bots, workflow automation, and the security surface\u003c/h3\u003e\n\u003cp\u003eNear the end, Mattias raises the topic of Slack bots for operational tasks — deployment reporting, status checks, and interactive queries. Andrey reframes the conversation around security: if Slack becomes part of a privileged control plane — for example, a bot that handles privilege escalation by requesting approvals through Slack messages — then request spoofing, account compromise, and weak isolation become serious concerns.\u003c/p\u003e\n\u003cp\u003eThe idea of a privilege-escalation bot is interesting (request access via Slack, get approval from designated approvers, receive time-limited credentials with full audit logging), but the attack surface is real. Slack provides a powerful collaboration platform for building workflows without custom UIs, but once it handles access decisions, security design matters as much as convenience.\u003c/p\u003e\n\u003ch2 id=\"highlights\"\u003eHighlights\u003c/h2\u003e\n\u003ch3 id=\"all-the-service-account-keys-were-in-clear-text-in-the-repo\"\u003e\u0026ldquo;All the service account keys were in clear text. In the repo.\u0026rdquo;\u003c/h3\u003e\n\u003cp\u003eA host describes opening up a client\u0026rsquo;s application stack and finding cloud service keys, usernames, passwords, API credentials, and an SSH key that tunnels directly into the production SQL server — all committed to Git in plain text. It is the kind of discovery that instantly explains years of hidden risk.\u003c/p\u003e\n\u003cp\u003eHow do you unwind that without breaking delivery? The hosts walk through an incremental migration plan in this episode of DevSecOps Talks.\u003c/p\u003e\n\u003ch3 id=\"security-tooling-is-actually-not-that-usable\"\u003e\u0026ldquo;Security tooling is actually not that usable.\u0026rdquo;\u003c/h3\u003e\n\u003cp\u003eJulien Bisconti delivers a sharp truth: developers do not bypass security because they are careless. They do it because secure workflows are too slow, too confusing, and too far removed from how they actually work. When the pressure comes from a manager who does not understand the blocker, the shortcut wins every time.\u003c/p\u003e\n\u003cp\u003eA candid take on why hardcoded secrets keep showing up in real codebases. Listen to the full discussion on DevSecOps Talks.\u003c/p\u003e\n\u003ch3 id=\"i-really-applaud-people-who-dont-choose-kubernetes--that-means-they-actually-know-what-theyre-doing\"\u003e\u0026ldquo;I really applaud people who don\u0026rsquo;t choose Kubernetes — that means they actually know what they\u0026rsquo;re doing.\u0026rdquo;\u003c/h3\u003e\n\u003cp\u003eOne of the spicier platform takes of the episode. The argument is not that Kubernetes is bad, but that defaulting to it without analyzing your actual needs is a sign of hype-driven architecture. If a simpler stack solves the problem, picking the biggest platform just creates more operational burden.\u003c/p\u003e\n\u003cp\u003eHear the full Kubernetes-versus-Nomad-versus-ECS debate on DevSecOps Talks.\u003c/p\u003e\n\u003ch3 id=\"if-your-process-is-not-good-youre-going-to-automate-a-bad-process\"\u003e\u0026ldquo;If your process is not good, you\u0026rsquo;re going to automate a bad process.\u0026rdquo;\u003c/h3\u003e\n\u003cp\u003eJulien recounts deploying Vault with full HA and multi-AZ redundancy, only to have the project grind to a halt over organizational politics — who should access what, and who decides. The tooling worked perfectly. The organization did not.\u003c/p\u003e\n\u003cp\u003eA reminder that DevSecOps maturity is not just about picking better tools. Catch the full story on DevSecOps Talks.\u003c/p\u003e\n\u003ch3 id=\"once-somebody-is-inside-they-have-the-keys-to-the-kingdom\"\u003e\u0026ldquo;Once somebody is inside, they have the keys to the kingdom.\u0026rdquo;\u003c/h3\u003e\n\u003cp\u003eThe VPN and zero-trust discussion delivers one of the strongest security arguments of the episode. Julien explains why broad network access — the castle-and-moat model — is the wrong abstraction for modern systems, and why identity-based, fine-grained access control is worth the implementation cost.\u003c/p\u003e\n\u003cp\u003eIf the old perimeter model still shapes how your team thinks about infrastructure security, this part of the episode will resonate. Listen on DevSecOps Talks.\u003c/p\u003e\n\u003ch2 id=\"resources\"\u003eResources\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003e\u003ca href=\"https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html\"\u003eAWS Systems Manager Session Manager\u003c/a\u003e\u003c/strong\u003e — AWS documentation for Session Manager, which provides secure instance access without SSH keys, open ports, or bastion hosts, with built-in session logging.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003e\u003ca href=\"https://github.com/Scribery/tlog\"\u003etlog — Terminal I/O Logger\u003c/a\u003e\u003c/strong\u003e — Open-source terminal session recording tool that logs to systemd journal in JSON format, making sessions searchable and tamper-resistant. Discussed in the episode as a more robust alternative to the Unix \u003ccode\u003escript\u003c/code\u003e command.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003e\u003ca href=\"https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-control-block-public-access.html\"\u003eAWS S3 Block Public Access\u003c/a\u003e\u003c/strong\u003e — AWS documentation on account- and bucket-level settings to prevent public access to S3 resources, regardless of individual object ACLs or bucket policies.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003e\u003ca href=\"https://repost.aws/knowledge-center/cross-account-access-denied-error-s3\"\u003eTroubleshooting Cross-Account Access to KMS-Encrypted S3 Buckets\u003c/a\u003e\u003c/strong\u003e — AWS guidance on the exact issue discussed in the episode: S3 downloads failing because the requester lacks KMS key permissions, even when bucket-level access is granted.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003e\u003ca href=\"https://research.google/pubs/pub43231/\"\u003eBeyondCorp: A New Approach to Enterprise Security\u003c/a\u003e\u003c/strong\u003e — Google\u0026rsquo;s foundational 2014 paper on zero-trust networking, which established the principle that network location should not determine access. Referenced by Julien in the VPN discussion.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003e\u003ca href=\"https://developer.hashicorp.com/nomad\"\u003eHashiCorp Nomad\u003c/a\u003e\u003c/strong\u003e — A lightweight workload orchestrator with native Consul and Vault integrations. Discussed as a simpler alternative to Kubernetes, especially for hybrid-cloud and small-team environments.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003e\u003ca href=\"https://developer.hashicorp.com/consul/docs/connect\"\u003eConsul Service Mesh (Consul Connect)\u003c/a\u003e\u003c/strong\u003e — HashiCorp\u0026rsquo;s service mesh solution providing zero-trust networking through mutual TLS and identity-based authorization. Mentioned as the networking layer in the Africa hybrid-cloud project.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003e\u003ca href=\"https://xkcd.com/1168/\"\u003eXKCD 1168: tar\u003c/a\u003e\u003c/strong\u003e — The comic Julien references about the impossibility of remembering command-line flags — a humorous illustration of why security tooling needs better usability.\u003c/p\u003e\n\u003c/li\u003e\n\u003c/ul\u003e"},{"title":"#4 - Docker Runtime Security","date_published":"2020-03-24T12:00:00Z","date_modified":"2020-03-24T12:00:00Z","id":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/004-docker-runtime-security/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/004-docker-runtime-security/","authors":[{"name":"DevSecOps Talks"}],"content_html":"\u003cp\u003eIn this episode, Mattias is trying to convince Andrey and Julien that running Docker containers in Kubernetes is more secure than virtual machines. How did it go? We agreed to disagree.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/company/devsecops-talks/\"\u003eDiscuss the episode or ask us anything on LinkedIn\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"single_player_container\"\u003e\n  \u003ciframe\n    title=\"DEVSECOPS Talks #4 - Docker Runtime Security\"\n    height=\"122\"\n    width=\"100%\"\n    style=\"border: none;\"\n    scrolling=\"no\"\n    data-name=\"pb-iframe-player\"\n    src=\"https://www.podbean.com/media/player/ycpvc-d7494b?from=yiiadmin\u0026download=1\u0026version=1\u0026skin=1\u0026btn-skin=107\u0026auto=0\u0026download=1\u0026pbad=1\"\n  \u003e\u003c/iframe\u003e\n\u003c/div\u003e\n\n\u003ch2 id=\"summary\"\u003eSummary\u003c/h2\u003e\n\u003cp\u003eMattias 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 \u0026ldquo;containers do not contain\u0026rdquo; 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.\u003c/p\u003e\n\u003ch2 id=\"key-topics\"\u003eKey Topics\u003c/h2\u003e\n\u003ch3 id=\"docker-vs-vm-security-technology-vs-ways-of-working\"\u003eDocker vs. VM security: technology vs. ways of working\u003c/h3\u003e\n\u003cp\u003eMattias 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.\u003c/p\u003e\n\u003cp\u003eAndrey 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.\u003c/p\u003e\n\u003cp\u003eMattias 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.\u003c/p\u003e\n\u003cp\u003eThe 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 \u0026ldquo;a little bit easier\u0026rdquo; 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.\u003c/p\u003e\n\u003ch3 id=\"why-container-breakout-is-not-as-trivial-as-people-imply\"\u003eWhy container breakout is not as trivial as people imply\u003c/h3\u003e\n\u003cp\u003eMattias challenges the common assumption that containers are unsafe because \u0026ldquo;you can break out of them.\u0026rdquo; 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.\u003c/p\u003e\n\u003cp\u003eJulien 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.\u003c/p\u003e\n\u003ch3 id=\"micro-vms-firecracker-and-lambda-attack-vectors\"\u003eMicro VMs, Firecracker, and Lambda attack vectors\u003c/h3\u003e\n\u003cp\u003eAndrey 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.\u003c/p\u003e\n\u003cp\u003eBut Andrey describes a real attack path researchers have demonstrated. The \u003ccode\u003e/tmp\u003c/code\u003e 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 \u003ccode\u003e/tmp\u003c/code\u003e 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.\u003c/p\u003e\n\u003cp\u003eThe 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.\u003c/p\u003e\n\u003ch3 id=\"containers-do-not-contain-apparmor-seccomp-and-policy-controls\"\u003eContainers do not contain: AppArmor, Seccomp, and policy controls\u003c/h3\u003e\n\u003cp\u003eJulien delivers the episode\u0026rsquo;s sharpest technical point: \u0026ldquo;Containers do not contain.\u0026rdquo; 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 container with host network access is the same as running directly on the server.\u003c/p\u003e\n\u003cp\u003eThis shifts security responsibility in uncomfortable ways. In VM environments, operations and security teams traditionally handle access controls. In containerized environments, developers are often expected to define security profiles for their workloads — but they may not know which system calls or privileges their applications need. Julien describes this as a fundamental organizational gap: the people writing the workload and the people securing the workload are rarely working hand in hand.\u003c/p\u003e\n\u003cp\u003eMattias suggests that platform teams can solve this by enforcing policies centrally. He references tools like Open Policy Agent to set standards for what gets deployed into a cluster, rather than relying on every developer to configure security correctly.\u003c/p\u003e\n\u003ch3 id=\"kubernetes-makes-monitoring-and-response-easier\"\u003eKubernetes makes monitoring and response easier\u003c/h3\u003e\n\u003cp\u003eMattias makes a strong case for container platforms as detection and response environments. He describes working with Falco, a runtime security tool, and highlights a powerful capability: if someone opens a shell inside a container, Falco can detect that behavior and the container is killed automatically. That kind of automated response is natural in an environment built around disposable workloads. On a VM, shells are a normal part of operations, making the same detection much harder to act on.\u003c/p\u003e\n\u003cp\u003eJulien extends this into a broader argument about monitoring and security being inseparable. He argues that when monitoring is poor, access control becomes chaotic — developers need broad production access just to debug issues. But with strong observability, teams can use feature flags, targeted routing, and centralized logging instead of SSH-ing into production. Good monitoring reduces the need for risky access patterns.\u003c/p\u003e\n\u003cp\u003eJulien offers a practical example: instead of blocking developers from opening shells in containers, observe that they are doing it and ask why. If they need logs, build a secure log access API. If they need to debug, improve the observability tooling. Monitoring turns security violations into product requirements.\u003c/p\u003e\n\u003ch3 id=\"minimizing-container-images\"\u003eMinimizing container images\u003c/h3\u003e\n\u003cp\u003eJulien mentions using DockerSlim (now SlimToolkit) to strip unnecessary components from container images, reducing attack surface without requiring deep knowledge of every dependency. It is not a complete security solution, but it is an easy first step that removes much of the bloat containers inherit from their base images.\u003c/p\u003e\n\u003cp\u003eFor organizations with compliance requirements, Julien notes that third-party security vendors provide validated runtime solutions — useful for audit purposes where you need a third party to confirm that the running workload matches what was built internally.\u003c/p\u003e\n\u003ch3 id=\"bundling-dependencies-with-the-application\"\u003eBundling dependencies with the application\u003c/h3\u003e\n\u003cp\u003eMattias raises a concern about how containerization changes dependency management. In older models, operations maintained the web server (Apache, Nginx) separately from the application. In containers, the web server, runtime, and application are bundled together. That means patching the web server requires rebuilding and redeploying the entire container, even when the application code has not changed.\u003c/p\u003e\n\u003cp\u003eAndrey reframes this as a different packaging model, not a new problem. With Java WAR files deployed to Tomcat, you already had dependency coupling — you just managed it differently. Containers actually improve the situation in one way: each application owns its own dependency lifecycle instead of sharing an application server. One application can upgrade independently without affecting others on the same host.\u003c/p\u003e\n\u003cp\u003eBoth hosts note that dedicated application servers are fading. Modern applications in Go, Python, and Node.js often handle HTTP directly, removing the need for a separate web server entirely. The ingress controller in Kubernetes handles routing at the cluster level, which is a separate concern from the application.\u003c/p\u003e\n\u003ch3 id=\"the-hosts-agree-to-disagree\"\u003eThe hosts agree to disagree\u003c/h3\u003e\n\u003cp\u003eThe episode ends without consensus. Mattias remains firmly convinced that containers, run properly in Kubernetes, are more secure than VMs. Julien\u0026rsquo;s final position: \u0026ldquo;Containers can be as secure as VMs, but they need more work to get there.\u0026rdquo; Andrey advocates for a layered approach — use both VMs and containers, with container security focused on application concerns and VM security focused on operational and resource isolation. He also notes that CoreOS, once the go-to minimal container OS, had recently been discontinued by IBM, leaving teams to find alternatives like Fedora CoreOS.\u003c/p\u003e\n\u003ch2 id=\"highlights\"\u003eHighlights\u003c/h2\u003e\n\u003ch3 id=\"containers-do-not-contain\"\u003e\u0026ldquo;Containers do not contain.\u0026rdquo;\u003c/h3\u003e\n\u003cp\u003eJulien delivers the episode\u0026rsquo;s most quotable line, reminding listeners that containers are mostly Linux namespacing — not real isolation boundaries. Without AppArmor, Seccomp, and careful configuration, a container is far less restrictive than people assume. A sharp reality check for anyone treating \u0026ldquo;containerized\u0026rdquo; as synonymous with \u0026ldquo;secure.\u0026rdquo;\nListen to the full episode on \u003ca href=\"https://devsecops.fm/\"\u003eDevSecOps Talks\u003c/a\u003e to hear why container security is never just about packaging.\u003c/p\u003e\n\u003ch3 id=\"if-somebody-pops-a-shell-in-a-container-that-container-is-killed\"\u003e\u0026ldquo;If somebody pops a shell in a container, that container is killed.\u0026rdquo;\u003c/h3\u003e\n\u003cp\u003eMattias describes working with Falco and highlights a capability that captures the strongest pro-container argument: disposable workloads change the incident response model entirely. On a VM, a shell is normal. In a container, it is an alarm — and the platform can act on it automatically.\nListen to the episode to hear how the hosts connect runtime detection, monitoring, and automated response.\u003c/p\u003e\n\u003ch3 id=\"most-of-the-docker-images-out-there-are-running-as-root\"\u003e\u0026ldquo;Most of the Docker images out there are running as root.\u0026rdquo;\u003c/h3\u003e\n\u003cp\u003eJust when the debate leans in Docker\u0026rsquo;s favor, Mattias himself brings it crashing back. On VMs, running as root is rare. In containers, it is the default. Better tooling does not fix insecure defaults — and this remains one of the most practical risks in container environments.\nHear the full back-and-forth on \u003ca href=\"https://devsecops.fm/\"\u003eDevSecOps Talks\u003c/a\u003e.\u003c/p\u003e\n\u003ch3 id=\"we-have-to-separate-apples-from-bananas--the-technology-from-the-ways-of-working\"\u003e\u0026ldquo;We have to separate apples from bananas — the technology from the ways of working.\u0026rdquo;\u003c/h3\u003e\n\u003cp\u003eMattias draws a sharp line that reframes the entire debate. Are containers actually more secure, or are teams comparing modern container practices against outdated VM operations? A useful reminder that architecture arguments often hide workflow arguments underneath.\nListen to the full conversation for the spirited disagreement that follows.\u003c/p\u003e\n\u003ch3 id=\"monitoring-very-much-goes-hand-in-hand-with-security\"\u003e\u0026ldquo;Monitoring very much goes hand in hand with security.\u0026rdquo;\u003c/h3\u003e\n\u003cp\u003eJulien makes the case that bad observability leads directly to bad access control. When developers cannot see what is happening in production safely, they need more privileges, more access, and more risky workarounds. Fix the monitoring, and many security problems solve themselves.\nListen to the episode on \u003ca href=\"https://devsecops.fm/\"\u003eDevSecOps Talks\u003c/a\u003e to hear why observability might be the most underrated security control.\u003c/p\u003e\n\u003ch3 id=\"containers-can-be-as-secure-as-vms-but-they-need-more-work\"\u003e\u0026ldquo;Containers can be as secure as VMs, but they need more work.\u0026rdquo;\u003c/h3\u003e\n\u003cp\u003eJulien\u0026rsquo;s final verdict — delivered over Mattias\u0026rsquo;s loud objections — perfectly captures the episode\u0026rsquo;s unresolved tension. The hosts explicitly agree to disagree, making this one of the more honest security debates you will hear on a podcast.\nCatch the full exchange on \u003ca href=\"https://devsecops.fm/\"\u003eDevSecOps Talks\u003c/a\u003e.\u003c/p\u003e\n\u003ch2 id=\"resources\"\u003eResources\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003e\u003ca href=\"https://falco.org/\"\u003eFalco\u003c/a\u003e\u003c/strong\u003e — CNCF-graduated runtime security tool that detects anomalous behavior in containers and Kubernetes using eBPF. Mentioned by Mattias for its ability to automatically kill containers when suspicious activity like shell access is detected.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003e\u003ca href=\"https://firecracker-microvm.github.io/\"\u003eFirecracker\u003c/a\u003e\u003c/strong\u003e — Open-source micro VM monitor built by AWS, powering Lambda and Fargate. Discussed by Andrey as an example of ephemeral, hardened execution environments and their attack surfaces.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003e\u003ca href=\"https://slimtoolkit.org/\"\u003eSlimToolkit (formerly DockerSlim)\u003c/a\u003e\u003c/strong\u003e — Tool for analyzing and minimizing container images, automatically generating AppArmor and Seccomp profiles. Mentioned by Julien as a practical way to reduce attack surface without deep security expertise.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003e\u003ca href=\"https://www.openpolicyagent.org/\"\u003eOpen Policy Agent (OPA)\u003c/a\u003e\u003c/strong\u003e — General-purpose policy engine for enforcing security and operational policies across Kubernetes clusters. Referenced by Mattias for centrally enforcing deployment standards.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003e\u003ca href=\"https://gitlab.com/apparmor/apparmor/-/wikis/home\"\u003eAppArmor\u003c/a\u003e\u003c/strong\u003e — Linux kernel security module that restricts application capabilities through mandatory access control profiles. Discussed by Julien as an essential add-on for meaningful container isolation.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003e\u003ca href=\"https://docs.kernel.org/userspace-api/seccomp_filter.html\"\u003eSeccomp (Secure Computing Mode)\u003c/a\u003e\u003c/strong\u003e — Linux kernel facility that restricts which system calls a process can make. Used by Docker and Kubernetes to reduce the container attack surface by blocking unnecessary syscalls.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003e\u003ca href=\"https://fedoraproject.org/coreos/\"\u003eFedora CoreOS\u003c/a\u003e\u003c/strong\u003e — Successor to CoreOS Container Linux (discontinued 2020), a minimal, auto-updating operating system designed for running containerized workloads. Relevant context for Andrey\u0026rsquo;s mention of CoreOS being killed by IBM.\u003c/p\u003e\n\u003c/li\u003e\n\u003c/ul\u003e"},{"title":"#3 - Docker Secure Build","date_published":"2020-03-24T00:00:00Z","date_modified":"2020-03-24T00:00:00Z","id":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/003-docker-secure-build/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/003-docker-secure-build/","authors":[{"name":"DevSecOps Talks"}],"content_html":"\u003cp\u003eBuilding Docker images is not as straightforward as one would like sometimes. In this episode we talk about how you can build more secure and lightweight container images, ready-made for production.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/company/devsecops-talks/\"\u003eDiscuss the episode or ask us anything on LinkedIn\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"single_player_container\"\u003e\n  \u003ciframe\n    title=\"DEVSECOPS Talks #3 - Docker Secure Build\"\n    height=\"122\"\n    width=\"100%\"\n    style=\"border: none;\"\n    scrolling=\"no\"\n    data-name=\"pb-iframe-player\"\n    src=\"https://www.podbean.com/media/player/cffda-d6b1a4?from=yiiadmin\u0026download=1\u0026version=1\u0026skin=1\u0026btn-skin=107\u0026auto=0\u0026download=1\u0026pbad=1\"\n  \u003e\u003c/iframe\u003e\n\u003c/div\u003e\n\n\u003ch2 id=\"summary\"\u003eSummary\u003c/h2\u003e\n\u003cp\u003eIn 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 \u0026ldquo;semantic guarantee\u0026rdquo; 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.\u003c/p\u003e\n\u003ch2 id=\"key-topics\"\u003eKey Topics\u003c/h2\u003e\n\u003ch3 id=\"container-images-vs-running-containers\"\u003eContainer images vs. running containers\u003c/h3\u003e\n\u003cp\u003eThe conversation starts by separating two distinct parts of container security: the image and the running container.\u003c/p\u003e\n\u003cp\u003eMattias 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.\u003c/p\u003e\n\u003cp\u003eBut Julien pushes back on a common misunderstanding: signing does not mean the contents are inherently safe. As he puts it, you get a \u0026ldquo;semantic guarantee that this image is what it\u0026rsquo;s pretending to be\u0026rdquo; — but not proof that everything inside is secure. Authenticity is not the same as security.\u003c/p\u003e\n\u003cp\u003eThe 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.\u003c/p\u003e\n\u003ch3 id=\"trust-docker-hub-and-the-container-supply-chain\"\u003eTrust, Docker Hub, and the container supply chain\u003c/h3\u003e\n\u003cp\u003eA major part of the episode focuses on how much trust teams should place in public images, including those from Docker Hub.\u003c/p\u003e\n\u003cp\u003eAndrey 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 \u0026ldquo;official\u0026rdquo; or branded images as automatically secure.\u003c/p\u003e\n\u003cp\u003eJulien walks through the different trust levels on Docker Hub:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eImages from unknown individuals are the hardest to trust\u003c/li\u003e\n\u003cli\u003eOrganization-backed images (Red Hat, CloudBees, etc.) provide more accountability based on brand recognition\u003c/li\u003e\n\u003cli\u003eEven reputable images can contain known vulnerabilities — scanning a Jenkins image from Docker Hub can reveal a surprising number of CVEs\u003c/li\u003e\n\u003cli\u003eA trusted source can still introduce problems, whether by mistake or through malicious intent\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eThat 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.\u003c/p\u003e\n\u003cp\u003eJulien 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.\u003c/p\u003e\n\u003ch3 id=\"why-container-security-is-not-just-image-signing\"\u003eWhy container security is not just image signing\u003c/h3\u003e\n\u003cp\u003eThe discussion then shifts from image authenticity to runtime security.\u003c/p\u003e\n\u003cp\u003eMattias 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, \u0026ldquo;the container does not contain things, it\u0026rsquo;s just an abstraction.\u0026rdquo; Container breakout vulnerabilities matter because an attacker who can exploit the runtime or host interface may reach beyond the container itself.\u003c/p\u003e\n\u003cp\u003eThis leads to one of the episode\u0026rsquo;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, \u0026ldquo;it was not designed to be secure by default, it was designed to be convenient.\u0026rdquo; That gap between convenience and security is what teams must actively address through scanning, hardening, and runtime controls.\u003c/p\u003e\n\u003ch3 id=\"cve-scanning-registries-dependencies-and-source-code\"\u003eCVE scanning: registries, dependencies, and source code\u003c/h3\u003e\n\u003cp\u003eThe hosts spend a good amount of time discussing scanning tools and where each fits in the security pipeline.\u003c/p\u003e\n\u003cp\u003eMattias notes that most container registries now offer built-in vulnerability scanning, sometimes called container analysis APIs. Julien suggests a practical AWS-based pattern: if you do not want to pay for Docker Hub premium but still want to use public images, you can pull from Docker Hub, push into AWS Elastic Container Registry (ECR), and take advantage of its built-in CVE scanning. Then you restrict your production orchestrators to pull only from ECR.\u003c/p\u003e\n\u003cp\u003eJulien draws an important distinction between types of scanning:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eRegistry scanning\u003c/strong\u003e examines what packages are installed in the image at the OS level. The registry unpacks the image, identifies installed packages, and flags known CVEs.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eDependency scanning\u003c/strong\u003e tools like Snyk, Dependabot, and similar platforms check application dependency manifests (package.json, requirements.txt, pom.xml) against CVE databases. They are protecting against supply chain vulnerabilities in libraries, not scanning custom application code.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eStatic analysis and linters\u003c/strong\u003e can catch some obvious security issues in application source code, but as Andrey notes, they mainly catch \u0026ldquo;easy targets\u0026rdquo; and default patterns.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eJulien initially states that registry scans do not cover source code, then corrects himself to clarify the distinction more precisely: registries scan installed OS packages, while separate tools scan programming language dependencies. Neither deeply analyzes your own custom code. That leaves an unknown component in the stack that teams need to address through other means — code review, testing, and secure development practices.\u003c/p\u003e\n\u003cp\u003eAndrey also mentions using Anchore, which he describes as the foundation for many of these CVE scanning capabilities.\u003c/p\u003e\n\u003ch3 id=\"the-shift-from-os-patching-to-image-rebuilding\"\u003eThe shift from OS patching to image rebuilding\u003c/h3\u003e\n\u003cp\u003eOne of the most practical insights comes from Andrey, who compares containers to older operational models.\u003c/p\u003e\n\u003cp\u003eIn traditional environments, teams could patch the operating system or update components like Nginx independently of the application. With containers, those layers are packaged together. If a new Nginx vulnerability is disclosed, the team needs to rebuild and redeploy the entire image that contains both the web server and the application code.\u003c/p\u003e\n\u003cp\u003eThis changes patching from an infrastructure task into an application delivery task. Security updates are no longer something ops handles in isolation — they flow through the same build-and-deploy pipeline as feature code.\u003c/p\u003e\n\u003cp\u003eThe hosts argue that this is why security must be a concern from the earliest stages. As Andrey puts it, referencing Julien\u0026rsquo;s earlier point: security belongs in the first commit, because that is when it is cheapest and easiest to get right. A green build today does not guarantee a safe deployment tomorrow if new CVEs are published against the packages already running in production.\u003c/p\u003e\n\u003ch3 id=\"slim-images-distroless-approaches-and-dockerslim\"\u003eSlim images, distroless approaches, and DockerSlim\u003c/h3\u003e\n\u003cp\u003eMattias argues strongly for reducing container contents to the bare minimum. He highlights DockerSlim (now SlimToolkit), a project he uses frequently that strips images down to only the components essential for the application. In his example, a Maven-based application image dropped from roughly 600 MB to 140 MB — with no bash shell or other standard OS tooling left in the result.\u003c/p\u003e\n\u003cp\u003eJulien reinforces the security rationale: \u0026ldquo;the less code you have, the less vulnerability you have, and that\u0026rsquo;s what you want in production.\u0026rdquo; He mentions Alpine Linux and Google\u0026rsquo;s distroless images as complementary approaches that aim for the same goal — minimal OS footprint in production containers.\u003c/p\u003e\n\u003cp\u003eThe common theme is that production containers should not carry build tools, shells, package managers, or debugging utilities. Every unnecessary binary is a potential attack surface. The best production image is not the one easiest to build, but the one that contains the least unnecessary code.\u003c/p\u003e\n\u003ch3 id=\"multi-stage-builds-and-separate-build-vs-runtime-images\"\u003eMulti-stage builds and separate build vs. runtime images\u003c/h3\u003e\n\u003cp\u003eThe hosts spend considerable time on one of the most practical Docker security patterns: multi-stage builds.\u003c/p\u003e\n\u003cp\u003eJulien explains the concept of build stages — using an intermediate container with all build dependencies to compile the application, then copying only the final artifact into a much smaller production image. This separation means the production image does not need compilers, package managers, or the full dependency tree.\u003c/p\u003e\n\u003cp\u003eAndrey confirms this maps directly to Docker\u0026rsquo;s multi-stage build feature: \u0026ldquo;You just build your Docker build in one stage and then just copy build results to the next stage.\u0026rdquo; He also points out the developer experience benefit — since the build environment is defined inside the Dockerfile itself, developers do not need to set up different language toolchains on their local machines when working across multiple microservices.\u003c/p\u003e\n\u003cp\u003eJulien adds a performance angle: pulling a pre-built container image with cached dependencies is often much faster than resolving and fetching all dependencies from scratch. He has seen Maven builds that took 20 minutes purely because they had to re-fetch all artifacts every time. Pre-building and caching the dependency layer can dramatically improve total build-to-production time.\u003c/p\u003e\n\u003ch3 id=\"continuous-rebuilding-and-reducing-attacker-persistence\"\u003eContinuous rebuilding and reducing attacker persistence\u003c/h3\u003e\n\u003cp\u003eAndrey recommends reducing the lifetime of deployed images by rebuilding base images and all derived containers regularly — potentially every week — pulling in the latest patches each time. While this adds operational overhead, it shortens the window of exposure and makes it significantly harder for attackers to maintain persistence in stale environments.\u003c/p\u003e\n\u003cp\u003eJulien frames this as a recurring maintenance budget that every engineering team must accept. As he puts it, \u0026ldquo;if you don\u0026rsquo;t spend at least one day per week updating the stuff, it\u0026rsquo;s going to accumulate over a year or something. And then you have to spend two weeks fixing all that.\u0026rdquo; The compound interest on security debt is steep.\u003c/p\u003e\n\u003ch3 id=\"tags-digests-signing-and-private-registries\"\u003eTags, digests, signing, and private registries\u003c/h3\u003e\n\u003cp\u003eNear the end of the episode, Mattias raises a practical deployment question: how should teams store and reference images securely? He contrasts mutable tags (which can be overwritten on Docker Hub) with immutable SHA-based digests, image signing, and private registries — and admits there are so many options it is hard to know where to start.\u003c/p\u003e\n\u003cp\u003eJulien recommends implementing all of these controls, but not all at once. He advocates for an incremental approach: define your security objectives, then build toward them layer by layer. Start with what gives the most immediate protection and expand from there.\u003c/p\u003e\n\u003cp\u003eThe hosts do not present a single silver bullet. Instead, they emphasize defense in depth: scanning at every level (code dependencies, container base images, production images), signing for authenticity, private registries for access control, and infrastructure-level enforcement.\u003c/p\u003e\n\u003ch3 id=\"build-pipeline-security-and-handling-secrets\"\u003eBuild pipeline security and handling secrets\u003c/h3\u003e\n\u003cp\u003eThe episode closes by touching on a problem the hosts agree deserves its own dedicated discussion: securing the build system itself.\u003c/p\u003e\n\u003cp\u003eMattias points out that the build server has access to source code, credentials, signing keys, registries, and deployment systems. If an attacker compromises it, they can inject malicious code during the build process — effectively poisoning everything downstream.\u003c/p\u003e\n\u003cp\u003eThe hosts then discuss the challenge of passing credentials into container builds for private dependencies. Andrey notes that recent Docker versions support passing SSH agents and secrets more safely during builds. He recommends using short-lived credentials (like AWS STS tokens with 15-minute expiration) so that even if credentials leak into image layers, they are already expired by the time anyone could exploit them. He also mentions using IMG, a daemonless image builder, as an alternative to Docker that avoids the need for a Docker daemon during builds.\u003c/p\u003e\n\u003cp\u003eJulien takes a different approach to runtime secrets: encrypting them with KMS and storing them in a cloud bucket, then fetching them only at container startup. He observes that the real cloud vendor lock-in is never the runtime — \u0026ldquo;it\u0026rsquo;s always the IAM\u0026rdquo; — because authorization and access control mechanisms are deeply cloud-specific and difficult to migrate.\u003c/p\u003e\n\u003cp\u003eJulien adds that handling build secrets often becomes an awkward \u0026ldquo;dance\u0026rdquo; of fetching credentials, granting temporary access, and cleaning up afterward. It works, but it remains operationally clumsy.\u003c/p\u003e\n\u003cp\u003eThe hosts agree that build server hardening and the connection between security and cost management (which Julien briefly mentions as natural partners, since understanding who has access to what benefits both) are topics worthy of their own future episodes.\u003c/p\u003e\n\u003ch2 id=\"highlights\"\u003eHighlights\u003c/h2\u003e\n\u003ch3 id=\"you-dont-know-whats-inside--you-only-have-a-semantic-guarantee\"\u003e\u0026ldquo;You don\u0026rsquo;t know what\u0026rsquo;s inside — you only have a semantic guarantee.\u0026rdquo;\u003c/h3\u003e\n\u003cp\u003eJulien cuts through a common assumption in container security: signing an image proves origin, not safety. That distinction shapes the entire episode, as the hosts explore why authenticity, trust, and actual security are three separate problems.\nListen to this episode of DevSecOps Talks for a grounded discussion on what image signing can — and cannot — guarantee.\u003c/p\u003e\n\u003ch3 id=\"containers-were-designed-to-be-convenient-not-secure-by-default\"\u003e\u0026ldquo;Containers were designed to be convenient, not secure by default.\u0026rdquo;\u003c/h3\u003e\n\u003cp\u003eMattias makes one of the sharpest points of the episode: containers became popular because they are efficient and easy to operate, not because they provide strong isolation. The container \u0026ldquo;does not contain things, it\u0026rsquo;s just an abstraction.\u0026rdquo; That is why runtime hardening and vulnerability management still matter so much.\nListen to DevSecOps Talks to hear why container adoption created as many security questions as it solved.\u003c/p\u003e\n\u003ch3 id=\"official-on-docker-hub-doesnt-mean-secure--scan-a-jenkins-image-and-youd-be-surprised\"\u003e\u0026ldquo;Official on Docker Hub doesn\u0026rsquo;t mean secure — scan a Jenkins image and you\u0026rsquo;d be surprised.\u0026rdquo;\u003c/h3\u003e\n\u003cp\u003eJulien challenges the idea that a branded or official image should be trusted blindly. Even well-known organization-backed images can contain a surprising number of CVEs, and reputable sources can still introduce malicious changes — intentionally or by mistake.\nListen to this DevSecOps Talks episode for a practical conversation about defining trust in your container supply chain.\u003c/p\u003e\n\u003ch3 id=\"the-less-code-you-have-the-less-vulnerability-you-have\"\u003e\u0026ldquo;The less code you have, the less vulnerability you have.\u0026rdquo;\u003c/h3\u003e\n\u003cp\u003eJulien sums up a recurring theme: smaller runtime images are not just cleaner — they are fundamentally safer. From DockerSlim shrinking a 600 MB Maven image to 140 MB, to Alpine and distroless approaches, the hosts argue for removing everything production does not absolutely need.\nListen to DevSecOps Talks to hear why image size and security are more connected than many teams realize.\u003c/p\u003e\n\u003ch3 id=\"nginx-gets-a-cve-now-you-have-to-rebuild-your-entire-app\"\u003e\u0026ldquo;Nginx gets a CVE? Now you have to rebuild your entire app.\u0026rdquo;\u003c/h3\u003e\n\u003cp\u003eAndrey highlights how containerization merged the OS patching cycle with the application delivery cycle. In the old world, ops could patch Nginx without touching the app. In the container world, every security update means a full image rebuild and redeploy — making security an application delivery concern, not just an infrastructure one.\nListen to this DevSecOps Talks episode for a practical take on why modern patching must flow through the CI/CD pipeline.\u003c/p\u003e\n\u003ch3 id=\"if-you-dont-spend-one-day-a-week-updating-youll-spend-two-weeks-fixing-it-later\"\u003e\u0026ldquo;If you don\u0026rsquo;t spend one day a week updating, you\u0026rsquo;ll spend two weeks fixing it later.\u0026rdquo;\u003c/h3\u003e\n\u003cp\u003eJulien describes dependency and image maintenance as a non-negotiable recurring budget. Skip the updates and the security debt compounds fast — turning routine maintenance into an emergency remediation project.\nListen to DevSecOps Talks for an honest take on the operational cost of staying secure in containerized environments.\u003c/p\u003e\n\u003ch3 id=\"the-real-lock-in-is-never-the-runtime--its-always-the-iam\"\u003e\u0026ldquo;The real lock-in is never the runtime — it\u0026rsquo;s always the IAM.\u0026rdquo;\u003c/h3\u003e\n\u003cp\u003eIn a brief but pointed aside about handling secrets in containers, Julien observes that authorization and access control are the truly cloud-specific parts of any architecture. Runtime workloads can move; IAM policies cannot.\nListen to this DevSecOps Talks episode for a candid discussion on where the real complexity lies in cloud-native security.\u003c/p\u003e\n\u003ch2 id=\"resources\"\u003eResources\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003e\u003ca href=\"https://slimtoolkit.org/\"\u003eSlimToolkit (formerly DockerSlim)\u003c/a\u003e\u003c/strong\u003e — Open-source tool that minifies container images by removing non-essential components, reducing image size and attack surface without code changes. Mentioned by Mattias in the episode.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003e\u003ca href=\"https://github.com/GoogleContainerTools/distroless\"\u003eGoogle Distroless Container Images\u003c/a\u003e\u003c/strong\u003e — Minimal container base images from Google that contain only the application and its runtime dependencies, stripping out shells, package managers, and OS utilities.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003e\u003ca href=\"https://docs.docker.com/build/building/multi-stage/\"\u003eDocker Multi-Stage Builds\u003c/a\u003e\u003c/strong\u003e — Official Docker documentation on using multiple build stages to produce smaller, cleaner production images by separating the build environment from the runtime image.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003e\u003ca href=\"https://docs.docker.com/engine/security/trust/\"\u003eDocker Content Trust\u003c/a\u003e\u003c/strong\u003e — Docker\u0026rsquo;s built-in mechanism for cryptographic signing and verification of image integrity and publisher identity using Notary.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003e\u003ca href=\"https://docs.aws.amazon.com/AmazonECR/latest/userguide/image-scanning.html\"\u003eAmazon ECR Image Scanning\u003c/a\u003e\u003c/strong\u003e — AWS documentation on scanning container images for OS and language package vulnerabilities in Elastic Container Registry, mentioned by Julien as a practical alternative to paid Docker Hub scanning.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003e\u003ca href=\"https://docs.snyk.io/scan-with-snyk/snyk-container\"\u003eSnyk Container\u003c/a\u003e\u003c/strong\u003e — Developer security tool for scanning container images and application dependencies for known vulnerabilities, with remediation guidance and base image upgrade recommendations.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003e\u003ca href=\"https://anchore.com/container-vulnerability-scanning/\"\u003eAnchore Container Scanning\u003c/a\u003e\u003c/strong\u003e — SBOM-powered container vulnerability scanning platform, referenced by Andrey as the engine behind many registry-level CVE scanning capabilities.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003e\u003ca href=\"https://hub.docker.com/_/alpine\"\u003eAlpine Linux Docker Image\u003c/a\u003e\u003c/strong\u003e — Minimal 5 MB base image built on musl libc and BusyBox, widely used as a lightweight, security-conscious alternative to full Linux distribution base images.\u003c/p\u003e\n\u003c/li\u003e\n\u003c/ul\u003e"},{"title":"#2 - GitOps","date_published":"2020-03-09T00:00:00Z","date_modified":"2020-03-09T00:00:00Z","id":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/002-gitops/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/002-gitops/","authors":[{"name":"DevSecOps Talks"}],"content_html":"\u003cp\u003eWhat is GitOps and how to use it? Here we try to sort out the concept and how you can use it.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/company/devsecops-talks/\"\u003eDiscuss the episode or ask us anything on LinkedIn\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"single_player_container\"\u003e\n  \u003ciframe\n    title=\"DEVSECOPS Talks #2 - GitOps\"\n    height=\"122\"\n    width=\"100%\"\n    style=\"border: none;\"\n    scrolling=\"no\"\n    data-name=\"pb-iframe-player\"\n    src=\"https://www.podbean.com/media/player/6k6ub-d6b123?from=yiiadmin\u0026download=1\u0026version=1\u0026skin=1\u0026btn-skin=107\u0026auto=0\u0026download=1\u0026pbad=1\"\n  \u003e\u003c/iframe\u003e\n\u003c/div\u003e\n\n\u003ch2 id=\"summary\"\u003eSummary\u003c/h2\u003e\n\u003cp\u003eGitOps sounds simple — put Kubernetes manifests in Git and let the cluster pull changes — but the episode quickly reveals the real debate is not about Git at all. Andrey argues the only genuinely novel thing about GitOps is the pull-based model where an in-cluster agent reconciles state, while Julien questions whether GitOps is good for day-2 operations or just for bootstrapping clusters. The spiciest moment: Andrey declares \u0026ldquo;life is too short to do pull requests\u0026rdquo; and advocates pushing straight to master with strong CI/CD guardrails instead.\u003c/p\u003e\n\u003ch2 id=\"key-topics\"\u003eKey Topics\u003c/h2\u003e\n\u003ch3 id=\"what-gitops-actually-is--and-what-it-is-not\"\u003eWhat GitOps actually is — and what it is not\u003c/h3\u003e\n\u003cp\u003eAndrey frames the discussion by separating what is genuinely new about GitOps from what teams have already been doing for years. Storing deployment specifications in Git, he argues, is just version control — teams have done that for a decade. The meaningful difference is the deployment model: instead of an external CI/CD server pushing changes into Kubernetes by calling the cluster API, GitOps places an agent \u003cem\u003einside\u003c/em\u003e the cluster that either receives a webhook or polls a Git repository, pulls in the desired state, and applies it from within.\u003c/p\u003e\n\u003cp\u003eThat pull-based model is what Andrey identifies as the core innovation. It eliminates the need to expose the Kubernetes API externally — a real concern when using hosted CI services like CircleCI, which would otherwise need network access to the cluster. As Andrey puts it, exposing the API externally is risky \u0026ldquo;unless you want someone mining bitcoin on your cluster.\u0026rdquo;\u003c/p\u003e\n\u003cp\u003eHe references the tooling landscape at the time: \u003ca href=\"https://www.weave.works/\"\u003eWeaveworks\u003c/a\u003e (the company that coined the term \u0026ldquo;GitOps\u0026rdquo; and created \u003ca href=\"https://www.weave.works/oss/net/\"\u003eWeaveNet\u003c/a\u003e, a Kubernetes CNI driver), \u003ca href=\"https://fluxcd.io/\"\u003eFlux\u003c/a\u003e, \u003ca href=\"https://argo-cd.readthedocs.io/\"\u003eArgo\u003c/a\u003e, and \u003ca href=\"https://jenkins-x.io/\"\u003eJenkins X\u003c/a\u003e. He notes that Flux and Argo were joining forces at the time of recording. He also mentions Jenkins X as a potential GitOps tool, since it runs CI/CD jobs natively in Kubernetes, but expresses skepticism about using Kubernetes for build workloads — Kubernetes is declarative about desired state, but \u0026ldquo;you cannot declare my build is successful because you have no idea how your build gonna go.\u0026rdquo;\u003c/p\u003e\n\u003cp\u003e\u003cem\u003eEditor\u0026rsquo;s note: Weaveworks, the company that originated the term \u0026ldquo;GitOps,\u0026rdquo; \u003ca href=\"https://techcrunch.com/2024/02/05/cloud-native-container-management-platform-weaveworks-shuts-its-doors/\"\u003eshut down in February 2024\u003c/a\u003e. Flux continues as a \u003ca href=\"https://fluxcd.io/\"\u003eCNCF graduated project\u003c/a\u003e. The GitOps principles have since been formalized by the \u003ca href=\"https://opengitops.dev/\"\u003eOpenGitOps\u003c/a\u003e project under the CNCF.\u003c/em\u003e\u003c/p\u003e\n\u003ch3 id=\"the-weaveworks-definition-read-straight-from-the-source\"\u003eThe Weaveworks definition, read straight from the source\u003c/h3\u003e\n\u003cp\u003eAndrey reads Weaveworks\u0026rsquo; concise GitOps definition from their blog and walks through its key points:\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eThe desired state of the whole system is described declaratively\u003c/strong\u003e — Git is the single source of truth for every environment.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAll changes to desired state are Git commits\u003c/strong\u003e — operations are driven through version control.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eThe cluster state is observable\u003c/strong\u003e — so teams can detect when desired and observed states have converged or diverged.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eA convergence mechanism brings the system back\u003c/strong\u003e — when states diverge, the cluster automatically reconciles, either triggered immediately by a webhook or on a configurable polling interval. Rollback is simply convergence to an earlier desired state.\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003eAndrey also raises a nuance about Helm: since Helm templates can produce different output depending on input variables, true GitOps implies committing not only the Helm charts but also the rendered manifests — because the generated output is what actually represents the declarative desired state.\u003c/p\u003e\n\u003cp\u003eHe draws a comparison to GitHub\u0026rsquo;s earlier promotion of \u003ca href=\"https://github.com/exAspArk/awesome-chatops\"\u003eChatOps\u003c/a\u003e, noting that many of the same ideas — observable, verifiable changes driven through a central workflow — were already part of GitHub\u0026rsquo;s operational philosophy, just with a different interface.\u003c/p\u003e\n\u003ch3 id=\"two-layers-infrastructure-as-code-and-in-cluster-gitops\"\u003eTwo layers: infrastructure-as-code and in-cluster GitOps\u003c/h3\u003e\n\u003cp\u003eJulien offers a more practical framing, splitting the problem into two distinct layers:\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eInfrastructure as code\u003c/strong\u003e — setting up the underlying infrastructure (VPCs, clusters, networking)\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eGitOps\u003c/strong\u003e — managing what runs \u003cem\u003einside\u003c/em\u003e the Kubernetes cluster: applications, operational tooling like monitoring (he mentions FluentD as an example), and supporting services\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003eIn Julien\u0026rsquo;s model, a Git repository becomes the authoritative inventory of everything that should exist in the cluster. He describes the ideal: \u0026ldquo;if anything else is running here, alert me or kill it.\u0026rdquo; That gives teams confidence that the observed cluster state matches the intended one, and helps prevent configuration drift — a problem the hosts discussed in their earlier infrastructure-as-code episode.\u003c/p\u003e\n\u003ch3 id=\"day-2-operations-where-the-model-gets-tested\"\u003eDay-2 operations: where the model gets tested\u003c/h3\u003e\n\u003cp\u003eWhile Julien appreciates GitOps for defining and bootstrapping cluster state, he is openly skeptical about its effectiveness for long-running operations. He distinguishes between two very different challenges: \u0026ldquo;setting up things\u0026rdquo; versus \u0026ldquo;running things for a long time — they\u0026rsquo;re not the same.\u0026rdquo;\u003c/p\u003e\n\u003cp\u003eReal environments drift. People intervene manually during incidents. Urgent fixes happen outside the normal workflow. The clean desired-state model becomes harder to maintain once the messiness of day-2 operations enters the picture. Julien frames this as an open question rather than a settled answer: GitOps may be excellent for establishing a clean baseline, but whether it holds up as a complete long-term operating model remains to be proven.\u003c/p\u003e\n\u003ch3 id=\"who-controls-changes-developers-operators-or-both\"\u003eWho controls changes: developers, operators, or both?\u003c/h3\u003e\n\u003cp\u003eAndrey raises a governance concern: GitOps can look like a direct developer-to-cluster pathway. If a developer changes a YAML file, commits it, and the cluster automatically applies the change, operations staff are effectively bypassed — \u0026ldquo;there is nowhere an operation person can interfere with this.\u0026rdquo;\u003c/p\u003e\n\u003cp\u003eJulien pushes back, arguing that the workflow — not the tooling — determines who has control. If changes go through pull requests with review and approval, it does not matter whether the author is a developer or an operator. Both participate in the same process. The mechanism is the same one used for application code: propose a change, review it, merge it.\u003c/p\u003e\n\u003ch3 id=\"pull-requests-compliance-and-push-to-master\"\u003ePull requests, compliance, and \u0026ldquo;push to master\u0026rdquo;\u003c/h3\u003e\n\u003cp\u003eThe conversation takes its most opinionated turn when the topic shifts to pull requests.\u003c/p\u003e\n\u003cp\u003eAndrey is blunt: \u0026ldquo;Life is too short to do pull requests. You never get anything done. You do a pull request, you ask for review and then you hunt the person for two days.\u0026rdquo; His preference is to push directly to master and build CI/CD pipelines strong enough to catch mistakes — \u0026ldquo;you build your system to defend yourself from the fools.\u0026rdquo;\u003c/p\u003e\n\u003cp\u003eHe does acknowledge an important exception: regulated industries where every production deployment must be peer-reviewed or approved. In those environments, formal review is not just a process preference but a compliance mechanism that can significantly reduce legal exposure when something goes wrong.\u003c/p\u003e\n\u003cp\u003eAndrey also shares a personal practice: because he frequently switches between projects and loses context, the first thing he does is document every verification step as part of the CI/CD pipeline. That way, when he returns to a project months later, the pipeline already encodes everything he would need to remember. \u0026ldquo;There is no guarantee that someone else has a better understanding of what I did.\u0026rdquo;\u003c/p\u003e\n\u003ch3 id=\"observability-gaps-in-gitops-pipelines\"\u003eObservability gaps in GitOps pipelines\u003c/h3\u003e\n\u003cp\u003eAndrey identifies a practical developer-experience problem with GitOps: the visibility gap.\u003c/p\u003e\n\u003cp\u003eIn a traditional pipeline, a developer can trace a change end-to-end — build, test, deploy — in one place. With GitOps, the CI pipeline ends when it commits changes to a repository. The actual deployment happens later, inside the cluster, through a separate reconciliation process. \u0026ldquo;My pipeline stops at the place where I do commit, push, done. Since then, pipeline doesn\u0026rsquo;t have much to absorb.\u0026rdquo;\u003c/p\u003e\n\u003cp\u003eTo understand whether a deployment succeeded, the developer needs to inspect cluster state rather than the original pipeline. Bridging that gap requires additional tooling and represents a real paradigm shift in how teams observe deployments.\u003c/p\u003e\n\u003cp\u003eHe also flags a repository-structure problem: if source code and deployment manifests live in the same repository, updating manifests can trigger the source-code pipeline again — requiring conditional logic to prevent unnecessary rebuilds.\u003c/p\u003e\n\u003ch3 id=\"deployment-ordering-and-full-system-validation\"\u003eDeployment ordering and full-system validation\u003c/h3\u003e\n\u003cp\u003eJulien closes the discussion with a practical concern: deployment order matters in real systems. A proxy may need a backend to exist first. Some components cannot be rolled out in arbitrary order without causing failures.\u003c/p\u003e\n\u003cp\u003eHe also questions the validation model. In a software build pipeline, teams rebuild and test the entire application from the main branch to verify the whole system works. But with GitOps, a change to one part of the cluster may be applied incrementally without validating the full cluster state end-to-end. \u0026ldquo;I will never test the full master branch and rebuild the full cluster from it, except everything goes.\u0026rdquo;\u003c/p\u003e\n\u003cp\u003eThat leaves an open question the hosts do not fully resolve: how can teams preserve the elegance of declarative Git-driven deployment while managing sequencing, dependencies, and whole-system confidence?\u003c/p\u003e\n\u003ch2 id=\"highlights\"\u003eHighlights\u003c/h2\u003e\n\u003ch3 id=\"unless-you-want-someone-mining-bitcoin-on-your-cluster\"\u003e\u0026ldquo;Unless you want someone mining bitcoin on your cluster\u0026rdquo;\u003c/h3\u003e\n\u003cp\u003eAndrey explains the security motivation behind the pull-based GitOps model — if you use an external CI system, you need to expose your Kubernetes API, which is not exactly ideal. His colorful warning about cryptocurrency miners makes the point memorable.\u003c/p\u003e\n\u003cp\u003e\u003cem\u003eListen to the episode for Andrey\u0026rsquo;s full breakdown of why the pull-vs-push distinction is the real heart of GitOps.\u003c/em\u003e\u003c/p\u003e\n\u003ch3 id=\"life-is-too-short-to-do-pull-requests\"\u003e\u0026ldquo;Life is too short to do pull requests.\u0026rdquo;\u003c/h3\u003e\n\u003cp\u003eThe spiciest take of the episode. Andrey argues that pull requests slow teams to a crawl — you open one, ask for review, then spend two days hunting the reviewer. His alternative: push to master and build pipelines strong enough to protect against mistakes. He does carve out an exception for regulated industries where peer review is legally required.\u003c/p\u003e\n\u003cp\u003e\u003cem\u003eListen to the episode and decide whether you agree or strongly disagree.\u003c/em\u003e\u003c/p\u003e\n\u003ch3 id=\"gitops-is-a-nice-way-to-set-up-your-kubernetes-cluster--but-is-it-a-good-tool-to-keep-it-running-im-not-sure\"\u003e\u0026ldquo;GitOps is a nice way to set up your Kubernetes cluster — but is it a good tool to keep it running? I\u0026rsquo;m not sure.\u0026rdquo;\u003c/h3\u003e\n\u003cp\u003eJulien draws a sharp line between bootstrapping a cluster and operating it long-term. Setting up things and running things for a long time are \u0026ldquo;not the same.\u0026rdquo; It is a refreshingly honest admission that a clean architecture pattern does not automatically solve the messy reality of day-2 operations.\u003c/p\u003e\n\u003cp\u003e\u003cem\u003eListen to the episode for a take that many GitOps advocates skip over.\u003c/em\u003e\u003c/p\u003e\n\u003ch3 id=\"you-build-your-system-to-defend-yourself-from-the-fools\"\u003e\u0026ldquo;You build your system to defend yourself from the fools.\u0026rdquo;\u003c/h3\u003e\n\u003cp\u003eAndrey\u0026rsquo;s philosophy in one sentence. Rather than relying on human review processes, invest in CI/CD pipelines and automated guardrails that prevent mistakes regardless of who pushes the change. He backs this up with a personal habit: encoding every verification step into the pipeline so future-him does not have to remember anything.\u003c/p\u003e\n\u003cp\u003e\u003cem\u003eListen to the episode for a practical argument in favor of automation over process.\u003c/em\u003e\u003c/p\u003e\n\u003ch3 id=\"if-anything-else-is-running-here--alert-me-or-kill-it\"\u003e\u0026ldquo;If anything else is running here — alert me or kill it.\u0026rdquo;\u003c/h3\u003e\n\u003cp\u003eJulien describes the appeal of GitOps as an authoritative inventory of what should exist in a cluster. If the Git repository defines the desired state and the cluster enforces it, anything unauthorized can be flagged or removed. It is one of the clearest expressions of why teams are drawn to the GitOps model.\u003c/p\u003e\n\u003cp\u003e\u003cem\u003eListen to the episode for a practical view of GitOps as cluster hygiene.\u003c/em\u003e\u003c/p\u003e\n\u003ch3 id=\"the-daughter-interruption\"\u003eThe daughter interruption\u003c/h3\u003e\n\u003cp\u003eMid-argument about observability gaps, Andrey\u0026rsquo;s daughter walks in wanting to share something exciting. It is a charming reminder that even deep infrastructure debates happen in real life with real interruptions.\u003c/p\u003e\n\u003cp\u003e\u003cem\u003eListen to the episode for the unscripted moment — and Andrey\u0026rsquo;s smooth recovery.\u003c/em\u003e\u003c/p\u003e\n\u003ch2 id=\"resources\"\u003eResources\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://fluxcd.io/\"\u003eFlux — the GitOps family of projects\u003c/a\u003e — The CNCF-graduated GitOps toolkit originally created by Weaveworks. Continuously reconciles Kubernetes cluster state with Git repositories.\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://argo-cd.readthedocs.io/en/stable/\"\u003eArgo CD — Declarative GitOps CD for Kubernetes\u003c/a\u003e — A declarative, GitOps continuous delivery tool for Kubernetes with a rich web UI for visualizing application state and deployments.\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://jenkins-x.io/\"\u003eJenkins X — Cloud Native CI/CD Built On Kubernetes\u003c/a\u003e — An opinionated CI/CD platform for Kubernetes that automates pipelines, preview environments, and promotion using GitOps principles.\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://opengitops.dev/\"\u003eOpenGitOps — CNCF Sandbox Project\u003c/a\u003e — The vendor-neutral, CNCF-backed project that formalizes GitOps principles: declarative, versioned and immutable, pulled automatically, and continuously reconciled.\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://www.weave.works/blog/what-is-gitops-really\"\u003eWhat is GitOps Really? — Weaveworks Blog\u003c/a\u003e — The original Weaveworks blog post defining GitOps that Andrey reads from during the episode. Weaveworks coined the term before \u003ca href=\"https://techcrunch.com/2024/02/05/cloud-native-container-management-platform-weaveworks-shuts-its-doors/\"\u003eshutting down in February 2024\u003c/a\u003e.\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://www.gitops.tech/\"\u003egitops.tech\u003c/a\u003e — A community resource explaining GitOps concepts, principles, and the ecosystem of tools that implement the pattern.\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://github.com/exAspArk/awesome-chatops\"\u003eAwesome ChatOps\u003c/a\u003e — A curated list of ChatOps resources and tools, relevant to Andrey\u0026rsquo;s comparison between GitOps and GitHub\u0026rsquo;s earlier ChatOps movement driven by Hubot.\u003c/li\u003e\n\u003c/ul\u003e"},{"title":"About","date_published":"2020-03-01T00:00:00Z","date_modified":"2020-03-01T00:00:00Z","id":"https://deploy-preview-67--devsecopstalks.netlify.app/about/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/about/","content_html":"\u003ch2 id=\"this-podcast-is-brought-to-you-by-mattias-paulina-and-andrey\"\u003eThis podcast is brought to you by Mattias, Paulina and Andrey\u003c/h2\u003e\n\u003ch3 id=\"paulina-dubas\"\u003ePaulina Dubas\u003c/h3\u003e\n\u003cdiv style=\"display: flex; justify-content: center;\"\u003e\n  \u003cimg src=\"/images/paulina.jpeg\" alt=\"Paulina Dubas\" /\u003e\n\u003c/div\u003e\n\n\u003cblockquote\u003e\n\u003cp\u003eIndependent Lead DevOps Engineer/Architect, who has been working in the engineering field for the past 10 years across multiple projects and with various technologies.\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cblockquote\u003e\n\u003cp\u003ePaulina is a co-founder of Code Club Copenhagen and The Better Software Initiative creating community and educational events for software professionals.\u003c/p\u003e\n\u003c/blockquote\u003e\n\n\u003cdiv style=\"display: flex; flex-direction: row; justify-content: flex-end; padding-right: 4rem; \"\u003e\n    \n      \u003ca style=\"padding-left: 1rem\" href=\"https://twitter.com/PaulaDubas\"\u003e\n        \u003csvg xmlns=\"http://www.w3.org/2000/svg\" width=\"32\" height=\"32\" viewBox=\"0 0 24 24\" fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linecap=\"round\" stroke-linejoin=\"round\" class=\"feather feather-twitter\"\u003e\u003cpath d=\"M23 3a10.9 10.9 0 0 1-3.14 1.53 4.48 4.48 0 0 0-7.86 3v1A10.66 10.66 0 0 1 3 4s-4 9 5 13a11.64 11.64 0 0 1-7 2c9 5 20 0 20-11.5a4.5 4.5 0 0 0-.08-.83A7.72 7.72 0 0 0 23 3z\"\u003e\u003c/path\u003e\u003c/svg\u003e\n      \u003c/a\u003e\n     \n      \u003ca style=\"padding-left: 1rem\" href=\"https://www.linkedin.com/in/paulinadubas\"\u003e\n        \u003csvg xmlns=\"http://www.w3.org/2000/svg\" width=\"32\" height=\"32\" viewBox=\"0 0 24 24\" fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linecap=\"round\" stroke-linejoin=\"round\" class=\"feather feather-linkedin\"\u003e\u003cpath d=\"M16 8a6 6 0 0 1 6 6v7h-4v-7a2 2 0 0 0-2-2 2 2 0 0 0-2 2v7h-4v-7a6 6 0 0 1 6-6z\"\u003e\u003c/path\u003e\u003crect x=\"2\" y=\"9\" width=\"4\" height=\"12\"\u003e\u003c/rect\u003e\u003ccircle cx=\"4\" cy=\"4\" r=\"2\"\u003e\u003c/circle\u003e\u003c/svg\u003e\n      \u003c/a\u003e\n     \n      \u003ca style=\"padding-left: 1rem\" href=\"https://github.com/paulinadubas\"\u003e\n        \u003csvg xmlns=\"http://www.w3.org/2000/svg\" width=\"32\" height=\"32\" viewBox=\"0 0 24 24\" fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linecap=\"round\" stroke-linejoin=\"round\" class=\"feather feather-github\"\u003e\u003cpath d=\"M9 19c-5 1.5-5-2.5-7-3m14 6v-3.87a3.37 3.37 0 0 0-.94-2.61c3.14-.35 6.44-1.54 6.44-7A5.44 5.44 0 0 0 20 4.77 5.07 5.07 0 0 0 19.91 1S18.73.65 16 2.48a13.38 13.38 0 0 0-7 0C6.27.65 5.09 1 5.09 1A5.07 5.07 0 0 0 5 4.77a5.44 5.44 0 0 0-1.5 3.78c0 5.42 3.3 6.61 6.44 7A3.37 3.37 0 0 0 9 18.13V22\"\u003e\u003c/path\u003e\u003c/svg\u003e\n      \u003c/a\u003e\n     \n      \u003ca style=\"padding-left: 1rem\" href=\"https://dubascon.com\"\u003e\n        \u003csvg xmlns=\"http://www.w3.org/2000/svg\" width=\"32\" height=\"32\" viewBox=\"0 0 24 24\" fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linecap=\"round\" stroke-linejoin=\"round\" class=\"feather feather-link\"\u003e\u003cpath d=\"M10 13a5 5 0 0 0 7.54.54l3-3a5 5 0 0 0-7.07-7.07l-1.72 1.71\"\u003e\u003c/path\u003e\u003cpath d=\"M14 11a5 5 0 0 0-7.54-.54l-3 3a5 5 0 0 0 7.07 7.07l1.71-1.71\"\u003e\u003c/path\u003e\u003c/svg\u003e\n      \u003c/a\u003e\n    \n\u003c/div\u003e\n\n\n\u003ch3 id=\"andrey-devyatkin\"\u003eAndrey Devyatkin\u003c/h3\u003e\n\u003cdiv style=\"display: flex; justify-content: center;\"\u003e\n  \u003cimg src=\"/images/andrey.webp\" alt=\"Andrey Devyatkin\" /\u003e\n\u003c/div\u003e\n\n\u003cblockquote\u003e\n\u003cp\u003eAndrey is an accomplished Principal Cloud Engineering Consultant who specializes in creating cloud-native application delivery platforms for startups. These platforms facilitate quick iteration, experimentation, and data-driven decision-making, which are essential for the fast-paced, innovative environments of startup companies.\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cblockquote\u003e\n\u003cp\u003eAs a co-founder of FivexL, a Cloud Engineering Specialist firm (\u003ca href=\"https://fivexl.io\"\u003ehttps://fivexl.io\u003c/a\u003e), Andrey and his team provide expert guidance and services in cloud infrastructure, helping businesses achieve their objectives through cutting-edge technology solutions.\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cblockquote\u003e\n\u003cp\u003eBeyond his professional work, Andrey is actively involved in the tech community as an organizer of meetups and a public speaker, sharing his knowledge and experience with others. He is passionate about fostering collaboration and learning among professionals in the field.\u003c/p\u003e\n\u003c/blockquote\u003e\n\n\u003cdiv style=\"display: flex; flex-direction: row; justify-content: flex-end; padding-right: 4rem; \"\u003e\n    \n      \u003ca style=\"padding-left: 1rem\" href=\"https://twitter.com/Andrey9kin\"\u003e\n        \u003csvg xmlns=\"http://www.w3.org/2000/svg\" width=\"32\" height=\"32\" viewBox=\"0 0 24 24\" fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linecap=\"round\" stroke-linejoin=\"round\" class=\"feather feather-twitter\"\u003e\u003cpath d=\"M23 3a10.9 10.9 0 0 1-3.14 1.53 4.48 4.48 0 0 0-7.86 3v1A10.66 10.66 0 0 1 3 4s-4 9 5 13a11.64 11.64 0 0 1-7 2c9 5 20 0 20-11.5a4.5 4.5 0 0 0-.08-.83A7.72 7.72 0 0 0 23 3z\"\u003e\u003c/path\u003e\u003c/svg\u003e\n      \u003c/a\u003e\n     \n      \u003ca style=\"padding-left: 1rem\" href=\"https://www.linkedin.com/in/andreydevyatkin\"\u003e\n        \u003csvg xmlns=\"http://www.w3.org/2000/svg\" width=\"32\" height=\"32\" viewBox=\"0 0 24 24\" fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linecap=\"round\" stroke-linejoin=\"round\" class=\"feather feather-linkedin\"\u003e\u003cpath d=\"M16 8a6 6 0 0 1 6 6v7h-4v-7a2 2 0 0 0-2-2 2 2 0 0 0-2 2v7h-4v-7a6 6 0 0 1 6-6z\"\u003e\u003c/path\u003e\u003crect x=\"2\" y=\"9\" width=\"4\" height=\"12\"\u003e\u003c/rect\u003e\u003ccircle cx=\"4\" cy=\"4\" r=\"2\"\u003e\u003c/circle\u003e\u003c/svg\u003e\n      \u003c/a\u003e\n     \n      \u003ca style=\"padding-left: 1rem\" href=\"https://github.com/Andrey9kin\"\u003e\n        \u003csvg xmlns=\"http://www.w3.org/2000/svg\" width=\"32\" height=\"32\" viewBox=\"0 0 24 24\" fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linecap=\"round\" stroke-linejoin=\"round\" class=\"feather feather-github\"\u003e\u003cpath d=\"M9 19c-5 1.5-5-2.5-7-3m14 6v-3.87a3.37 3.37 0 0 0-.94-2.61c3.14-.35 6.44-1.54 6.44-7A5.44 5.44 0 0 0 20 4.77 5.07 5.07 0 0 0 19.91 1S18.73.65 16 2.48a13.38 13.38 0 0 0-7 0C6.27.65 5.09 1 5.09 1A5.07 5.07 0 0 0 5 4.77a5.44 5.44 0 0 0-1.5 3.78c0 5.42 3.3 6.61 6.44 7A3.37 3.37 0 0 0 9 18.13V22\"\u003e\u003c/path\u003e\u003c/svg\u003e\n      \u003c/a\u003e\n     \n      \u003ca style=\"padding-left: 1rem\" href=\"https://andreydevyatkin.com\"\u003e\n        \u003csvg xmlns=\"http://www.w3.org/2000/svg\" width=\"32\" height=\"32\" viewBox=\"0 0 24 24\" fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linecap=\"round\" stroke-linejoin=\"round\" class=\"feather feather-link\"\u003e\u003cpath d=\"M10 13a5 5 0 0 0 7.54.54l3-3a5 5 0 0 0-7.07-7.07l-1.72 1.71\"\u003e\u003c/path\u003e\u003cpath d=\"M14 11a5 5 0 0 0-7.54-.54l-3 3a5 5 0 0 0 7.07 7.07l1.71-1.71\"\u003e\u003c/path\u003e\u003c/svg\u003e\n      \u003c/a\u003e\n    \n\u003c/div\u003e\n\n\n\u003ch3 id=\"mattias-hemmingsson\"\u003eMattias Hemmingsson\u003c/h3\u003e\n\u003cdiv style=\"display: flex; justify-content: center;\"\u003e\n  \u003cimg src=\"/images/mattias.webp\" alt=\"Mattias Hemmingsson\" /\u003e\n\u003c/div\u003e\n\n\u003cblockquote\u003e\n\u003cp\u003ePodcast host, former CISO at car rental company, certified pentester and cloud engineering enthusiast.\u003c/p\u003e\n\u003c/blockquote\u003e\n\n\u003cdiv style=\"display: flex; flex-direction: row; justify-content: flex-end; padding-right: 4rem; \"\u003e\n    \n      \u003ca style=\"padding-left: 1rem\" href=\"https://twitter.com/LifeAndShell\"\u003e\n        \u003csvg xmlns=\"http://www.w3.org/2000/svg\" width=\"32\" height=\"32\" viewBox=\"0 0 24 24\" fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linecap=\"round\" stroke-linejoin=\"round\" class=\"feather feather-twitter\"\u003e\u003cpath d=\"M23 3a10.9 10.9 0 0 1-3.14 1.53 4.48 4.48 0 0 0-7.86 3v1A10.66 10.66 0 0 1 3 4s-4 9 5 13a11.64 11.64 0 0 1-7 2c9 5 20 0 20-11.5a4.5 4.5 0 0 0-.08-.83A7.72 7.72 0 0 0 23 3z\"\u003e\u003c/path\u003e\u003c/svg\u003e\n      \u003c/a\u003e\n     \n      \u003ca style=\"padding-left: 1rem\" href=\"https://www.linkedin.com/in/matte-hemmingsson\"\u003e\n        \u003csvg xmlns=\"http://www.w3.org/2000/svg\" width=\"32\" height=\"32\" viewBox=\"0 0 24 24\" fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linecap=\"round\" stroke-linejoin=\"round\" class=\"feather feather-linkedin\"\u003e\u003cpath d=\"M16 8a6 6 0 0 1 6 6v7h-4v-7a2 2 0 0 0-2-2 2 2 0 0 0-2 2v7h-4v-7a6 6 0 0 1 6-6z\"\u003e\u003c/path\u003e\u003crect x=\"2\" y=\"9\" width=\"4\" height=\"12\"\u003e\u003c/rect\u003e\u003ccircle cx=\"4\" cy=\"4\" r=\"2\"\u003e\u003c/circle\u003e\u003c/svg\u003e\n      \u003c/a\u003e\n     \n      \u003ca style=\"padding-left: 1rem\" href=\"https://github.com/mattiashem\"\u003e\n        \u003csvg xmlns=\"http://www.w3.org/2000/svg\" width=\"32\" height=\"32\" viewBox=\"0 0 24 24\" fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linecap=\"round\" stroke-linejoin=\"round\" class=\"feather feather-github\"\u003e\u003cpath d=\"M9 19c-5 1.5-5-2.5-7-3m14 6v-3.87a3.37 3.37 0 0 0-.94-2.61c3.14-.35 6.44-1.54 6.44-7A5.44 5.44 0 0 0 20 4.77 5.07 5.07 0 0 0 19.91 1S18.73.65 16 2.48a13.38 13.38 0 0 0-7 0C6.27.65 5.09 1 5.09 1A5.07 5.07 0 0 0 5 4.77a5.44 5.44 0 0 0-1.5 3.78c0 5.42 3.3 6.61 6.44 7A3.37 3.37 0 0 0 9 18.13V22\"\u003e\u003c/path\u003e\u003c/svg\u003e\n      \u003c/a\u003e\n     \n      \u003ca style=\"padding-left: 1rem\" href=\"https://lifeandshell.com\"\u003e\n        \u003csvg xmlns=\"http://www.w3.org/2000/svg\" width=\"32\" height=\"32\" viewBox=\"0 0 24 24\" fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linecap=\"round\" stroke-linejoin=\"round\" class=\"feather feather-link\"\u003e\u003cpath d=\"M10 13a5 5 0 0 0 7.54.54l3-3a5 5 0 0 0-7.07-7.07l-1.72 1.71\"\u003e\u003c/path\u003e\u003cpath d=\"M14 11a5 5 0 0 0-7.54-.54l-3 3a5 5 0 0 0 7.07 7.07l1.71-1.71\"\u003e\u003c/path\u003e\u003c/svg\u003e\n      \u003c/a\u003e\n    \n\u003c/div\u003e\n\n\n\u003ch3 id=\"license\"\u003eLicense\u003c/h3\u003e\n\u003cp\u003eDevSecOps Talks podcast is released under a Creative Commons Attribution Non-Commercial No-Derivatives 4.0 International license.\u003c/p\u003e\n\u003cp\u003eWe encourage you to distribute any episodes freely as long as you attribute them to the stated above authors and give a link to \u003ca href=\"https://devsecops.fm\"\u003ehttps://devsecops.fm\u003c/a\u003e.\nYou may not distribute our podcast for monetary gain of any kind. Nor may you create derivatives of it written consent from authors stated above.\u003c/p\u003e\n\u003cp\u003eFor more information and the full text of the license visit the Creative Commons site: \u003ca href=\"https://creativecommons.org/licenses/by-nc-nd/4.0/\"\u003ehttps://creativecommons.org/licenses/by-nc-nd/4.0/\u003c/a\u003e\u003c/p\u003e\n"},{"title":"#1 - Infrastructure as Code","date_published":"2020-02-24T00:00:00Z","date_modified":"2020-02-24T00:00:00Z","id":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/001-infrastructure-as-code/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/episodes/001-infrastructure-as-code/","authors":[{"name":"DevSecOps Talks"}],"content_html":"\u003cp\u003eWhen should you start using infrastructure as code and when not. What tools are there to help and how can you use them. Follow us in our first talk.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/company/devsecops-talks/\"\u003eDiscuss the episode or ask us anything on LinkedIn\u003c/a\u003e\u003c/p\u003e\n\u003cdiv class=\"single_player_container\"\u003e\n  \u003ciframe\n    title=\"DEVSECOPS Talks #1 - Infrastructure as Code\"\n    height=\"122\"\n    width=\"100%\"\n    style=\"border: none;\"\n    scrolling=\"no\"\n    data-name=\"pb-iframe-player\"\n    src=\"https://www.podbean.com/media/player/d7x4q-d53cd6?from=yiiadmin\u0026download=1\u0026version=1\u0026skin=1\u0026btn-skin=107\u0026auto=0\u0026download=1\u0026pbad=1\"\n  \u003e\u003c/iframe\u003e\n\u003c/div\u003e\n\n\u003chr\u003e\n\u003ch2 id=\"summary\"\u003eSummary\u003c/h2\u003e\n\u003cp\u003eIn this inaugural episode, Mattias, Andrey, and Julien discuss what infrastructure as code really means, why teams adopt it, and where it can go wrong. They explore the evolution from manual server management to declarative infrastructure, the differences between configuration management and infrastructure provisioning, the growing complexity of tools like Terraform and CloudFormation, and why culture, process, and operational discipline matter as much as the tooling itself.\u003c/p\u003e\n\u003ch2 id=\"key-topics\"\u003eKey Topics\u003c/h2\u003e\n\u003ch3 id=\"what-infrastructure-as-code-actually-solves\"\u003eWhat Infrastructure as Code Actually Solves\u003c/h3\u003e\n\u003cp\u003eThe discussion starts with Mattias describing the shift from manually editing Apache configs over SSH to defining cloud environments in code. He recalls the progression: first managing individual servers by hand, then adopting configuration management tools like Puppet, Chef, and Ansible, and finally arriving at cloud-native tools like AWS CloudFormation that can provision entire environments declaratively.\u003c/p\u003e\n\u003cp\u003eAndrey pushes the conversation toward first principles, arguing that it is important to separate the \u0026ldquo;what\u0026rdquo; from the \u0026ldquo;how.\u0026rdquo; He explains that infrastructure as code depends on having APIs — software-defined interfaces that allow infrastructure to be created and managed programmatically. Without that kind of interface, teams are limited to SSH and the manual tools they had before. The rise of public cloud providers and platforms like OpenStack finally gave teams the APIs they needed to describe infrastructure declaratively in definition files.\u003c/p\u003e\n\u003ch3 id=\"configuration-management-vs-infrastructure-as-code\"\u003eConfiguration Management vs Infrastructure as Code\u003c/h3\u003e\n\u003cp\u003eA key distinction in the episode is the difference between server configuration tools and true infrastructure as code. Andrey notes that tools like Puppet, Chef, and Ansible were originally conceived as server configuration management tools — designed to automate the provisioning and configuration of servers, not to define infrastructure itself.\u003c/p\u003e\n\u003cp\u003eHe acknowledges this is a gray area, since tools like Ansible can now call AWS APIs and manage infrastructure directly. But historically, the configuration management era was about fighting configuration drift on existing servers, while the cloud era introduced the ability to declare entire environments as code. If you asked the vendors selling Chef, they would tell you Chef is \u0026ldquo;all about infrastructure as code\u0026rdquo; — but the original intent was different.\u003c/p\u003e\n\u003ch3 id=\"when-to-automate--and-when-not-to\"\u003eWhen to Automate — and When Not To\u003c/h3\u003e\n\u003cp\u003eThe hosts caution against automating too early. Andrey says he tends not to automate things until they genuinely need automation. If creating one cluster with a few nodes and one database is all you need, full automation may be premature. But if you know you will eventually manage hundreds or thousands, starting early makes sense.\u003c/p\u003e\n\u003cp\u003eJulien reinforces this point with a memorable gym analogy: \u0026ldquo;You go to the gym, you see Arnold Schwarzenegger lifting 200 kilos from the ground and you say, he does it, I can do it. And then you pick up the little weight and find out that if you start with 200 kilos, you\u0026rsquo;re gonna break your back.\u0026rdquo; His point is that infrastructure as code tools get you up and running fast — that is what they are designed for — but day two operations always come knocking. The automation itself can become a burden if you are not careful about what you automate and when.\u003c/p\u003e\n\u003ch3 id=\"infrastructure-as-documentation-and-source-of-truth\"\u003eInfrastructure as Documentation and Source of Truth\u003c/h3\u003e\n\u003cp\u003eMattias describes one of his main reasons for using infrastructure as code: knowing what is actually running. He sees the codebase as documentation and as proof of the intended state of the environment — a way to verify that what he thinks is deployed matches what is actually in the cloud.\u003c/p\u003e\n\u003cp\u003eThe hosts agree with that idea, but they also point out the tension between declared state and reality. If people still make manual changes in the cloud console, the code drifts away from what is actually running. Andrey notes the problem: if undocumented manual changes are not reflected back into code, the next infrastructure deployment could recreate the original broken state — \u0026ldquo;you\u0026rsquo;re back to the fire state, basically.\u0026rdquo;\u003c/p\u003e\n\u003ch3 id=\"the-terraform-complexity-problem\"\u003eThe Terraform Complexity Problem\u003c/h3\u003e\n\u003cp\u003eJulien brings up Terraform as \u0026ldquo;the elephant in the room\u0026rdquo; and argues that it has become significantly more complex over time. He says the language started out as purely descriptive, but newer features in HCL2 — such as for loops, conditionals, and sequencing logic — have pushed it closer to a general-purpose programming language.\u003c/p\u003e\n\u003cp\u003eHis concern is that this makes infrastructure definitions harder to read and reason about. Instead of simply describing desired state, users now have to mentally execute the code to understand what it will produce. Andrey agrees there is a legitimate need for this evolution — once a declarative setup grows large enough, you genuinely want loops and conditionals — but acknowledges it creates a tension between readability and expressiveness.\u003c/p\u003e\n\u003ch3 id=\"declarative-vs-imperative-approaches\"\u003eDeclarative vs Imperative Approaches\u003c/h3\u003e\n\u003cp\u003eThe episode explores the difference between declarative and imperative models. Andrey explains that shell scripts are imperative — you tell the system exactly what to do, step by step — while a declarative tool lets a team state the desired outcome and rely on the platform to converge on that state.\u003c/p\u003e\n\u003cp\u003eKubernetes is presented as a strong example of the declarative model. You submit manifests that declare what you want, and operators work to make reality match that intent — not necessarily immediately, but as soon as all requirements are fulfilled. Andrey suggests infrastructure tooling may evolve in this direction, with systems that continuously enforce declared state rather than only applying changes on demand. He gives a security example: an intruder stops AWS CloudTrail, but a reactive system — like a Kubernetes operator — detects the deviation and turns it back on automatically.\u003c/p\u003e\n\u003cp\u003eJulien adds that this is already happening. He mentions that a Kubernetes operator exists to bridge the gap to cloud APIs, allowing teams to define infrastructure resources inside Kubernetes YAML manifests and have the operator create them in the cloud. Google Cloud\u0026rsquo;s Config Connector is a concrete example of this pattern, letting teams manage GCP resources as native Kubernetes objects.\u003c/p\u003e\n\u003ch3 id=\"immutable-infrastructure-and-emergency-changes\"\u003eImmutable Infrastructure and Emergency Changes\u003c/h3\u003e\n\u003cp\u003eAndrey strongly advocates for immutable infrastructure: baking golden images using tools like Packer, deploying them as-is, and replacing systems rather than patching them in place. In that model, people should not be logging into systems or making changes manually. If you need a change, you burn a new image and roll it out. SSH should not even be enabled in a proper cloud setup.\u003c/p\u003e\n\u003cp\u003eMattias raises a practical challenge: in real incidents, people with admin access to the cloud console often need to click a button to resolve the problem quickly. He describes his own experience — the team started with read-only production access but had to grant write access once on-call responsibilities kicked in. Andrey agrees that teams should not be dogmatic when production is on fire: \u0026ldquo;You go and do whatever it takes to put fire down.\u0026rdquo; But those emergency fixes must be reflected back into code, and the team must know exactly what was changed. Otherwise, the next deployment may recreate the original problem.\u003c/p\u003e\n\u003ch3 id=\"culture-and-process-matter-more-than-tools\"\u003eCulture and Process Matter More Than Tools\u003c/h3\u003e\n\u003cp\u003eOne of the clearest themes in the conversation is that infrastructure as code is not just a tooling choice. Julien argues that it does not matter what technology you use if your process and culture are not aligned with security and best practices: \u0026ldquo;You can fix the technology only so much, but it\u0026rsquo;s mainly about people.\u0026rdquo;\u003c/p\u003e\n\u003cp\u003eMattias describes a setup where Jenkins applies all CloudFormation changes, and every modification to the cloud goes through pull requests, code review, and change management — the same workflow used for application code. This means infrastructure changes become auditable, reviewable, and easier to track. Andrey sees this as applying development principles to infrastructure: version history, visibility into who changed what, the ability to ask someone why they made a change, and code review before changes are applied.\u003c/p\u003e\n\u003ch3 id=\"guardrails-for-manual-changes\"\u003eGuardrails for Manual Changes\u003c/h3\u003e\n\u003cp\u003eAndrey shares a practical example from a previous engagement where developers had near-admin access to the AWS console and would create EC2 instances, S3 buckets, and other resources outside of Terraform or CloudFormation. To control cost and reduce unmanaged resources, the team built a system using specific tags generated by a Terraform module.\u003c/p\u003e\n\u003cp\u003eA Lambda function ran every night, scanned for resources without the required tags, posted a Slack notification saying \u0026ldquo;I found these, gonna delete them next day,\u0026rdquo; and tagged them for deletion. The following night, anything still tagged for deletion was removed. This gave developers flexibility for experimentation — they could spin up resources manually and try things out — while preventing forgotten resources from becoming permanent, invisible infrastructure. It also helped keep costs under control.\u003c/p\u003e\n\u003ch3 id=\"tooling-is-only-the-start\"\u003eTooling Is Only the Start\u003c/h3\u003e\n\u003cp\u003eJulien stresses that adopting infrastructure as code does not automatically make systems reliable, immutable, or resilient. In his view, it is \u0026ldquo;just the beginning of the journey.\u0026rdquo; He warns against the myth that infrastructure as code equals immutable infrastructure — you can absolutely build stateful, mutable systems with code if you choose to.\u003c/p\u003e\n\u003cp\u003eHe also pushes back on the assumption that automation always saves time, admitting with self-awareness: \u0026ldquo;I automated a task, it took me two days to automate it, and I saved barely 10 seconds of my life.\u0026rdquo; His advice is to measure the actual benefit rather than being seduced by the marketing brochure. Data will tell you more about a tool\u0026rsquo;s real value than excitement will.\u003c/p\u003e\n\u003ch3 id=\"abstraction-code-generation-and-developer-experience\"\u003eAbstraction, Code Generation, and Developer Experience\u003c/h3\u003e\n\u003cp\u003eThe hosts discuss the challenge of making infrastructure easy for developers who just want a database and a connection string, not a deep understanding of DBA work and security configuration. Andrey argues that abstracting best practices away from developers saves enormous organizational time, since developer time is expensive and holds back feature delivery.\u003c/p\u003e\n\u003cp\u003eHe describes a third approach beyond declarative and imperative: code generators. Large companies with resources sometimes build internal generators that take simplified YAML inputs and output fully declarative specs. This creates another level of abstraction on top of existing tools, allowing developers to be productive without needing to understand infrastructure details. It is controversial — in some ways it takes power away from people — but it can dramatically simplify the developer experience.\u003c/p\u003e\n\u003ch3 id=\"pulumi-vs-terraform-and-community-support\"\u003ePulumi vs Terraform and Community Support\u003c/h3\u003e\n\u003cp\u003eAndrey introduces Pulumi as an interesting new branch of infrastructure tooling that lets teams describe infrastructure in general-purpose languages like TypeScript, Python, or Go instead of domain-specific languages like HCL. He notes that while it feels familiar to developers — you stay in your comfort zone — you still need to learn a new DSL embedded in that language. It is \u0026ldquo;not entirely like you just described infrastructure in the language you know.\u0026rdquo;\u003c/p\u003e\n\u003cp\u003eJulien says he tried Pulumi and found it appealing for developers who want consistency across their codebase. But he remains cautious, arguing that \u0026ldquo;code is a liability\u0026rdquo; — referencing Kelsey Hightower\u0026rsquo;s satirical GitHub project \u003cem\u003enocode\u003c/em\u003e (\u0026ldquo;write nothing, deploy nowhere, run securely\u0026rdquo;) to make the point that less code means fewer problems. For beginners, Julien recommends starting with Terraform or the native tooling from cloud providers, mainly because the community is larger, tutorials are more abundant, and there are meetup groups where people can learn from each other. His advice is pragmatic: \u0026ldquo;Just make sure that you ditch Terraform the minute it gets in your way.\u0026rdquo;\u003c/p\u003e\n\u003ch3 id=\"start-with-the-problem-not-the-tool\"\u003eStart With the Problem, Not the Tool\u003c/h3\u003e\n\u003cp\u003eAndrey repeatedly returns to the same question: what problem is being solved? He argues that teams should choose tools based on business needs and existing team capabilities, not because a tool is fashionable. \u0026ldquo;A lot of people and developers, they like shiny tools — and there\u0026rsquo;s nothing wrong about that — but you always have to ask, what is the problem we are solving?\u0026rdquo;\u003c/p\u003e\n\u003cp\u003eAndrey\u0026rsquo;s framing connects tool selection to team dynamics: if your team already has knowledge of a particular tool, relearning a new one just because it is trendy does not make sense. What you need is not a fancy tool but to deliver business value with the capabilities you have.\u003c/p\u003e\n\u003ch3 id=\"migration-legacy-and-incremental-adoption\"\u003eMigration, Legacy, and Incremental Adoption\u003c/h3\u003e\n\u003cp\u003eThe hosts acknowledge that many teams are not starting from a clean slate. Andrey points out that legacy infrastructure exists for a reason: it helped the business survive and grow. As Mattias puts it bluntly: \u0026ldquo;Legacy pays the bills.\u0026rdquo;\u003c/p\u003e\n\u003cp\u003eFor organizations with years of manually built systems and hybrid environments, Andrey suggests doing value stream mapping to identify the biggest pain point and tackling that first. A greenfield project can serve as a success story to demonstrate the approach before trying to transform everything. He emphasizes that coming into an organization with a shiny idea and telling people \u0026ldquo;whatever you did before was crap\u0026rdquo; is a sure way to lose allies. Technology boils down to working with people — the tools are fine, but they do not replace the people running them.\u003c/p\u003e\n\u003ch3 id=\"the-templating-dilemma\"\u003eThe Templating Dilemma\u003c/h3\u003e\n\u003cp\u003eMattias raises a specific frustration with infrastructure as code: templating. He likes looking at his Git repository and seeing exactly what is running, but heavy use of variables and templates means he sees placeholder names instead of actual values. This tension — between reusable, DRY templates and readable, concrete definitions — is a real challenge that the hosts acknowledge without a clean resolution.\u003c/p\u003e\n\u003ch3 id=\"resilience-and-recovery\"\u003eResilience and Recovery\u003c/h3\u003e\n\u003cp\u003eNear the end of the episode, Andrey gives a concrete example of losing a Kubernetes cluster in production. Because the environment had been defined as code, the team was able to recreate it and recover in about one to two hours. Some things that were not properly documented slowed them down; with complete documentation the recovery could have been as fast as 15 to 20 minutes — mostly just waiting for AWS to provision the resources after the API calls.\u003c/p\u003e\n\u003cp\u003eJulien adds context to this: he argues that even with infrastructure as code, recreating a Kubernetes cluster and failing over traffic while maintaining service is genuinely hard. The concept is sound, but having the safety net to actually do it takes time, practice, and a lot of work. His advice for building confidence is to adopt the mentality of immutable infrastructure and get into the habit of regularly recreating things and practicing failovers.\u003c/p\u003e\n\u003ch3 id=\"final-advice\"\u003eFinal Advice\u003c/h3\u003e\n\u003cp\u003eAndrey recommends education first. He specifically mentions the book \u003cem\u003eInfrastructure as Code\u003c/em\u003e by Kief Morris (published by O\u0026rsquo;Reilly, now in its third edition) as a strong foundation. His broader advice: understand the domain, define the problem clearly, ask yourself what outcome you want to deliver for the business, and let the answers to those questions guide your tool decisions.\u003c/p\u003e\n\u003cp\u003eJulien\u0026rsquo;s closing thought is that in a large organization, a dedicated infrastructure team using infrastructure as code can manage everything — on-prem or cloud — with a single workflow. That team can abstract complexity so developers do not need to learn Terraform, CloudFormation, or any other tool. The specialization pays off by reducing onboarding friction and letting each team focus on what they do best.\u003c/p\u003e\n\u003ch2 id=\"highlights\"\u003eHighlights\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eJulien\u0026rsquo;s gym analogy:\u003c/strong\u003e \u0026ldquo;You go to the gym, you see Arnold Schwarzenegger lifting 200 kilos from the ground and you say, he does it, I can do it. And then you pick up the little weight and find out that if you start with 200 kilos, you\u0026rsquo;re gonna break your back.\u0026rdquo; His point: infrastructure as code tools make the start easy, but day two operations will humble you.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eJulien on Terraform:\u003c/strong\u003e He calls it \u0026ldquo;the elephant in the room\u0026rdquo; and argues that it has drifted from a descriptive language toward something more like a programming language, making it harder to reason about.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eJulien on coding overhead:\u003c/strong\u003e \u0026ldquo;Code is a liability\u0026rdquo; — referencing Kelsey Hightower\u0026rsquo;s \u003cem\u003enocode\u003c/em\u003e project to argue that every line of infrastructure code carries long-term maintenance costs.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eJulien on no silver bullets:\u003c/strong\u003e \u0026ldquo;There is no silver bullets. Stop dreaming. Just see how much work it takes, how complicated it is.\u0026rdquo;\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eJulien on automation ROI:\u003c/strong\u003e \u0026ldquo;I automated a task, it took me two days to automate it, and I saved barely 10 seconds of my life.\u0026rdquo;\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAndrey on incidents:\u003c/strong\u003e Teams should not be dogmatic — \u0026ldquo;If your production is on fire, you go and do whatever it takes to put fire down\u0026rdquo; — then put the fix back into code afterward.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAndrey on manual cloud resources:\u003c/strong\u003e He describes a Lambda-based cleanup system that scanned for untagged AWS resources nightly, posted to Slack, and deleted them the next day if no one claimed them.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAndrey on shiny tools:\u003c/strong\u003e \u0026ldquo;A lot of people and developers, they like shiny tools — and there\u0026rsquo;s nothing wrong about that — but you always have to ask, what is the problem we are solving?\u0026rdquo;\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eMattias on legacy:\u003c/strong\u003e \u0026ldquo;Legacy pays the bills\u0026rdquo; — a reminder that existing infrastructure made the business successful, and it deserves respect during any modernization effort.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAndrey\u0026rsquo;s recovery story:\u003c/strong\u003e After losing a production Kubernetes cluster, the team recreated everything in one to two hours because it was defined as code — and could have done it in 15-20 minutes with better documentation.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"resources\"\u003eResources\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://www.oreilly.com/library/view/infrastructure-as-code/9781098150341/\"\u003eInfrastructure as Code by Kief Morris (O\u0026rsquo;Reilly)\u003c/a\u003e — The book Andrey recommends as essential reading for practitioners. Now in its third edition, it covers patterns and practices for building and evolving infrastructure as code.\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://www.pulumi.com/\"\u003ePulumi — Infrastructure as Code in Any Programming Language\u003c/a\u003e — The tool discussed in the episode that lets teams define infrastructure using TypeScript, Python, Go, and other general-purpose languages instead of domain-specific languages like HCL.\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://aws.amazon.com/cloudformation/\"\u003eAWS CloudFormation\u003c/a\u003e — AWS\u0026rsquo;s native infrastructure as code service using declarative YAML/JSON templates, which Mattias and the team use with Jenkins for their deployment pipeline.\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://cloud.google.com/config-connector/docs/overview\"\u003eGCP Config Connector\u003c/a\u003e — The Google Cloud Kubernetes operator mentioned in the episode that lets teams manage GCP resources as native Kubernetes objects, bridging the gap between Kubernetes and cloud APIs.\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://github.com/forseti-security/forseti-security\"\u003eForseti Security (archived)\u003c/a\u003e — The GCP security scanning tool Julien describes that could detect policy violations (like open ports) and automatically revert changes. Originally developed by Spotify and Google, it was archived in January 2025.\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://github.com/kelseyhightower/nocode\"\u003eKelsey Hightower\u0026rsquo;s nocode\u003c/a\u003e — The satirical GitHub project Julien references: \u0026ldquo;The best way to write secure and reliable applications. Write nothing; deploy nowhere.\u0026rdquo; A humorous reminder that code is a liability.\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://www.terraform.io/\"\u003eHashiCorp Terraform\u003c/a\u003e — The infrastructure as code tool the hosts discuss extensively, including its evolution from a simple declarative language to the more complex HCL2 with loops and conditionals.\u003c/li\u003e\n\u003c/ul\u003e"},{"title":"Search","date_published":"0001-01-01T00:00:00Z","date_modified":"0001-01-01T00:00:00Z","id":"https://deploy-preview-67--devsecopstalks.netlify.app/search/","url":"https://deploy-preview-67--devsecopstalks.netlify.app/search/","content_html":"\u003cp class=\"error message js-hidden\"\u003eYou must have Javascript enabled to use this function.\u003c/p\u003e\n\u003cp class=\"info message hidden\" data-search-loading\u003eLoading search index…\u003c/p\u003e\n\n\u003cdiv data-search-input class=\"hidden\"\u003e\n  \u003cform data-search-form id=\"search-form\" action=\"#\" method=\"post\" accept-charset=\"UTF-8\" role=\"search\"\u003e\n    \u003clabel for=\"query\" class=\"visually-hidden\"\u003eSearch\u003c/label\u003e\n    \u003cinput data-search-text type=\"search\" id=\"query\" name=\"query\" placeholder=\"Enter the terms you wish to search for.\" maxlength=\"128\"\u003e\n  \u003c/form\u003e\n\u003c/div\u003e\n\n\u003cdiv data-search-results aria-live=\"polite\"\u003e\u003c/div\u003e\n\n\u003ctemplate\u003e\n  \u003carticle data-search-result class=\"list-view\"\u003e\n    \u003cheader\u003e\n      \u003ch2 class=\"title mt--s mb--xxs\"\u003e\u003ca href=\"#\"\u003eTitle here\u003c/a\u003e\u003c/h2\u003e\n      \u003cdiv class=\"submitted\"\u003e\u003ctime class=\"created-date\"\u003eDate here\u003c/time\u003e\u003c/div\u003e\n    \u003c/header\u003e\n    \u003cp class=\"content\"\u003eSummary here\u003c/p\u003e\n  \u003c/article\u003e\n\u003c/template\u003e\n\n"}]}