Ship It Weekly Show Notes

This is a guest conversation episode of Ship It Weekly, separate from the weekly news recaps.

In this Ship It: Conversations episode, I talk with Evan Phoenix of Miren about why deployment is still painful, what teams keep getting wrong when they try to simplify it, and why small teams may need better defaults more than more platform knobs.

Evan is the CEO of Miren. He previously worked on Terraform Enterprise and Waypoint at HashiCorp, and he also built Puma and Rubinius.

We talk about deployment as the “final boss” of software delivery. Not because teams do not know how to ship code, but because deployment is where everything collides: runtimes, registries, secrets, networking, cloud services, databases, rollbacks, and the internal platform nobody wants to touch anymore.

A big theme is opinionated tooling. Engineers often say they want flexibility, but many teams are really asking for good defaults, a clear happy path, and fewer decisions to own.

We also get into Terraform Enterprise, Terraform Cloud, Terragrunt, OpenTofu, Waypoint, Kubernetes, Heroku, ECS, container registries, and how AI changes the deployment conversation. AI can generate infrastructure code, but when that setup breaks, someone still has to understand it and be on call for it.

Highlights

• Why deployment is still painful after years of platforms and abstractions

• What Evan learned from Terraform Enterprise and Waypoint

• Why Terraform structure, state, modules, and repo layout remain hard

• Why OpenTofu gained traction beyond the Terraform licensing change

• Why Kubernetes can be too much surface area for some teams

• What small teams actually need from deployment tooling

• How AI changes infrastructure and deployment workflows

• Why generated infrastructure still needs ownership and accountability

Links

• Miren: https://miren.dev

• Miren on GitHub: https://github.com/mirendev

• Evan Phoenix: https://evanphx.dev

• Evan on Bluesky: https://bsky.app/profile/evanphx.dev

• Evan on Linkedin: https://www.linkedin.com/in/evanphoenix/

Things mentioned

• Terraform Enterprise: https://developer.hashicorp.com/terraform/enterprise

• Terraform Cloud: https://developer.hashicorp.com/terraform/cloud-docs

• Terragrunt: https://terragrunt.gruntwork.io

• OpenTofu: https://opentofu.org

• HashiCorp Waypoint: https://github.com/hashicorp/waypoint

• Knative: https://knative.dev

Our links

More episodes + show notes: https://shipitweekly.fm

On Call Brief: https://oncallbrief.com

This week on Ship It Weekly: Amazon Q Developer and the AWS language servers had a pair of trust-boundary CVEs, JFrog found hijacked npm and Go packages using hidden VS Code tasks to run malware when a workspace opens, AWS WAF had HTTP/2 request-body inspection issues, and AWS introduced Lambda MicroVMs for running user-generated and AI-generated code in isolated sandboxes.

The bigger theme: execution is the boundary now. The repo, the IDE, the AI assistant, the WAF, and the sandbox all sit at the point where something gets to run, inspect, block, or decide. Before execution, trust is a policy. After execution, trust is a blast radius.

In the lightning round, Brian covers GitHub’s record advisory volume, Git 2.55, Valkey 9.1 on Amazon ElastiCache, and a quick Fable 5 callback now that Anthropic’s Fable 5 is back online.

Links

AWS security bulletin: Amazon Q / AWS language server CVEs https://aws.amazon.com/security/security-bulletins/2026-047-aws/

JFrog: Hijacked npm packages using VS Code tasks https://research.jfrog.com/post/hijacked-npm-vscode-tasks-blockchain/

AWS security bulletin: AWS WAF HTTP/2 inspection issues https://aws.amazon.com/security/security-bulletins/2026-048-aws/

AWS Lambda MicroVMs https://aws.amazon.com/blogs/aws/run-isolated-sandboxes-with-full-lifecycle-control-aws-lambda-introduces-microvms/

GitHub Advisory Database record volume https://github.blog/security/supply-chain-security/inside-the-advisory-database-and-what-happens-when-vulnerability-volume-breaks-records/

Git 2.55 highlights https://github.blog/open-source/git/highlights-from-git-2-55/

Amazon ElastiCache Valkey 9.1 https://aws.amazon.com/blogs/database/announcing-valkey-9-1-for-amazon-elasticache/

Claude Fable 5 and Mythos 5 model docs https://platform.claude.com/docs/en/about-claude/models/introducing-claude-fable-5-and-claude-mythos-5

This week’s On Call Brief https://www.tellerstech.com/on-call-brief-news/2026-W27/

More episodes and full show notes https://shipitweekly.fm/

This is a guest conversation episode of Ship It Weekly, separate from the weekly news recaps.

In this Ship It: Conversations episode, I talk with Kat Traxler of Vectra AI about AI security, the zero-day clock, IAM, cloud risk, AI-assisted bug hunting, and why the scariest future security problems may still start with the boring fundamentals teams already struggle with today.

Kat is a Principal Security Researcher at Vectra AI focused on abuse techniques and vulnerabilities in the public cloud, especially around the intersection of cloud security, AppSec, IAM, managed identities, and insecure-by-design flaws.

We talk about the current AI security mood, from the excitement around faster research and bug hunting to the fear that AI could shrink the window between vulnerability disclosure and exploitation. Kat explains the “San Francisco Consensus,” why the zero-day clock is getting so much attention, and why she thinks the facts may be real while some of the conclusions are overextended.

The bigger theme here is that AI is absolutely changing security work, but it does not erase the fundamentals. Attackers still take the lowest-friction path that works. For most teams, that still means credentials, IAM, misconfigurations, known vulnerabilities, and systems that were never threat-modeled as deeply as people assume.

Highlights

• Why AI security feels exciting and unsettling at the same time

• What the “San Francisco Consensus” means and why people are talking about the zero-day clock

• How AI may shrink the time between vulnerability disclosure and exploitation

• Why Kat is skeptical of the full “zero-day apocalypse” narrative

• Why credentials, IAM, misconfigurations, and known vulnerabilities still matter most for many teams

• How AI helps narrow the search space in bug hunting and security research

• Where AI is useful for code-level bugs, and where it still struggles with context and threat modeling

• Why human expertise still matters when using AI for writing, research, and cloud security analysis

• Why IAM remains hard because it sits at the intersection of people, access, and technology

• What insecure-by-design flaws are, and why AI may not solve those anytime soon

Kat / Vectra AI links

• Kat Traxler at Vectra AI: https://www.vectra.ai/about/author/kat-traxler

• Kat’s site: https://kattraxler.cloud/

• The San Francisco Consensus: https://kattraxler.cloud/the-san-francisco-consensus/

• Kat on X: https://x.com/NightmareJS

• Vectra AI: https://www.vectra.ai/

Our links

More episodes + show notes + links: https://shipitweekly.fm

On Call Brief: https://oncallbrief.com

This week on Ship It Weekly: containerd disclosed a batch of CRI plugin vulnerabilities, Datadog tested PostgreSQL high availability on Kubernetes and found that failover is not useful if it cannot happen safely, AWS DevOps Agent and Datadog MCP Server moved AI incident response closer to real production workflows, and Amazon EKS added customer-routed control-plane egress.

The bigger theme: the control plane keeps getting wider. Runtimes, databases, incident agents, API-server egress, credentials, the cloud console, and object metadata are all becoming part of the production blast radius. And when something breaks, users do not experience your architecture diagram. They experience waiting.

In the lightning round, Brian covers GitHub self-service credential revocation for incident response, AWS Management Console Private Access without internet connectivity, Vercel Connect and short-lived agent credentials, and Amazon S3 annotations.

Links

containerd CRI plugin vulnerabilities / AWS security bulletin https://aws.amazon.com/security/security-bulletins/2026-046-aws/

Datadog: PostgreSQL high availability on Kubernetes https://www.datadoghq.com/blog/engineering/postgresql-ha-kubernetes/

AWS DevOps Agent and Datadog MCP Server https://aws.amazon.com/blogs/devops/production-ready-autonomous-incident-resolution-with-aws-devops-agent-now-ga-and-datadog-mcp-server/

Amazon EKS customer-routed control-plane egress https://aws.amazon.com/blogs/containers/amazon-eks-now-supports-control-plane-egress-through-your-vpc/

GitHub self-service credential revocation for incident response https://github.blog/changelog/2026-06-24-self-service-credential-revocation-for-incident-response/

AWS Management Console Private Access https://aws.amazon.com/about-aws/whats-new/2026/06/aws-management-console-private/

Vercel Connect https://vercel.com/blog/introducing-vercel-connect

Amazon S3 annotations https://aws.amazon.com/blogs/aws/amazon-s3-annotations-attach-rich-queryable-context-directly-to-your-objects/

Marc Brooker: Waiting, latency, MTTR, and the inspection paradox https://brooker.co.za/blog/2026/06/19/waiting.html

This week’s On Call Brief https://www.tellerstech.com/on-call-brief-news/2026-W26/

More episodes and full show notes https://www.shipitweekly.fm

This is a guest conversation episode of Ship It Weekly, separate from the weekly news recaps.

In this Ship It: Conversations episode, I talk with Joel DeStefano from Guardsquare about mobile app security, why it is different from backend and cloud security, and why scanning alone is not enough once an app is shipped into the real world.

We talk about the shift in trust model that happens with mobile apps. In backend and cloud systems, teams usually have more control over the runtime, infrastructure, policies, and monitoring. With mobile, the app becomes a public artifact running on someone else’s device, in an environment you do not fully control.

The bigger theme here is that mobile security is not just “scan it before release.” Scanning matters, but teams also need to think about app hardening, obfuscation, runtime protection, monitoring, and whether the app connecting back to their APIs is genuine and uncompromised.

Highlights

• Why mobile changes the trust model compared to backend and cloud systems

• What DevOps, SRE, and platform teams should understand about mobile app risk

• Why scanning is useful, but not enough by itself

• The danger of assuming app store approval means an app is secure

• Why “we do not store sensitive data in the app” can be a misleading security argument

• How attackers can reverse engineer apps, inspect workflows, and learn how the app talks to backend APIs

• What code hardening and obfuscation actually help protect against

• Why runtime checks matter for rooted devices, compromised environments, debuggers, hooking frameworks, overlays, and accessibility abuse

• The difference between Android and iOS security assumptions

• Why the OS is not responsible for protecting your app’s business logic

• How mobile security should fit into CI/CD without destroying release velocity

• What should block a release versus what should become tracked risk

• Why testing, hardening, runtime protection, and monitoring should work together as one strategy

• How AI may speed up attackers without fundamentally changing the need for strong security fundamentals

• Joel’s advice for improving mobile security posture: start with the app’s critical workflows, backend interactions, and real business risk

Joel / Guardsquare links

• Guardsquare: https://hubs.ly/Q04fJgkJ0

• Guardsquare Blog: https://www.guardsquare.com/blog

OWASP mobile security links

• OWASP Mobile Application Security: https://owasp.org/www-project-mobile-app-security/

• OWASP MASVS: https://mas.owasp.org/MASVS/

Our links

More episodes + show notes + links: https://shipitweekly.fm

On Call Brief: https://oncallbrief.com