WEBVTT 00:00:00.000 --> 00:00:03.480 This week, Amazon EKS gets Kubernetes version 00:00:03.480 --> 00:00:06.280 rollbacks, which sounds like an undo button, 00:00:06.459 --> 00:00:09.759 but rollback is not the same thing as readiness. 00:00:09.919 --> 00:00:13.480 A new supply chain report called Cordyceps found 00:00:13.480 --> 00:00:16.980 exploitable GitHub Actions patterns across major 00:00:16.980 --> 00:00:20.160 open source projects, which is another reminder 00:00:20.160 --> 00:00:24.839 that CI/CD YAML is code with credentials. Tenet 00:00:24.839 --> 00:00:28.260 Security showed how a fake Sentry error could 00:00:28.260 --> 00:00:32.280 hijack AI coding agents into running 00:00:32.280 --> 00:00:36.420 attacker-controlled code. So logs, errors, and telemetry 00:00:36.420 --> 00:00:39.719 are not just evidence anymore. They may also 00:00:39.719 --> 00:00:43.060 be instructions. And CloudWatch can now create 00:00:43.060 --> 00:00:47.219 alarms directly from log queries. Useful, yes, 00:00:47.359 --> 00:00:51.939 but also a very fast way to turn noisy logs into 00:00:51.939 --> 00:00:55.359 noisy pages. Put those together, and the theme 00:00:55.359 --> 00:00:58.479 this week is pretty clear. The safety nets are 00:00:58.479 --> 00:01:02.000 getting better, but the blast radius is getting 00:01:02.000 --> 00:01:04.819 wider. I'm Brian Teller from Teller's Tech, and 00:01:04.819 --> 00:01:24.370 this is Ship It Weekly. Welcome back to Ship 00:01:24.370 --> 00:01:27.549 It Weekly, the show about the DevOps, SRE, cloud, 00:01:27.730 --> 00:01:30.629 platform, and security stories that actually 00:01:30.629 --> 00:01:32.989 matter when you are the person who has to keep 00:01:32.989 --> 00:01:35.670 the thing running at 3 a.m.. If you're new here, 00:01:35.769 --> 00:01:38.030 follow or subscribe wherever you are watching 00:01:38.030 --> 00:01:40.689 or listening. And if you want the weekly story 00:01:40.689 --> 00:01:43.829 list and source links, check out OnCallBrief 00:01:43.829 --> 00:01:47.109 .com. For past episodes, full show notes, and 00:01:47.109 --> 00:01:49.909 more from the show, head over to ShipItWeekly 00:01:49.909 --> 00:01:53.739 .fm. This week, we start with EKS version rollbacks 00:01:53.739 --> 00:01:57.439 because Kubernetes upgrades finally get a safety 00:01:57.439 --> 00:02:00.680 net in a place where a lot of teams have wanted 00:02:00.680 --> 00:02:04.019 one. Then, Cordyceps and why GitHub Actions workflows 00:02:04.019 --> 00:02:07.260 need to be treated like production code. After 00:02:07.260 --> 00:02:10.460 that, agentjacking, where fake telemetry can 00:02:10.460 --> 00:02:14.460 become a way to steer AI coding agents. Then, 00:02:14.620 --> 00:02:18.620 CloudWatch log query alarms and the line between 00:02:18.620 --> 00:02:22.780 better signals and easier noise in the lightning 00:02:22.780 --> 00:02:26.639 round ECS Service Connect zone-aware routing 00:02:26.639 --> 00:02:32.000 etcd 3.7, GitHub innersource advisories, secret 00:02:32.000 --> 00:02:35.060 scanning metadata and CloudWatch application 00:02:35.060 --> 00:02:38.979 signals service events and we close with a simple 00:02:38.979 --> 00:02:42.340 reminder safety nets are good but they do not 00:02:42.340 --> 00:02:49.599 replace ownership let's get into it First up, 00:02:49.599 --> 00:02:53.280 Amazon EKS now supports Kubernetes version rollbacks. 00:02:53.500 --> 00:02:57.400 And this is a big one. For a long time, Kubernetes 00:02:57.400 --> 00:03:00.539 control plane upgrades have felt like a one-way 00:03:00.539 --> 00:03:03.219 door. You do the checks, you read the release 00:03:03.219 --> 00:03:06.219 notes, you look at your add-ons, your nodes, 00:03:06.500 --> 00:03:09.379 your admission controllers, your autoscaling, 00:03:09.500 --> 00:03:12.680 your old helm charts, and whatever legacy thing 00:03:12.680 --> 00:03:15.900 nobody wants to touch. Then eventually, you upgrade. 00:03:16.360 --> 00:03:19.580 and hope the cluster is still boring. EKS is 00:03:19.580 --> 00:03:22.699 changing that with version rollback. If you upgrade 00:03:22.699 --> 00:03:26.879 an EKS cluster and hit a problem, AWS now lets 00:03:26.879 --> 00:03:30.120 you roll the Kubernetes version back to the previous 00:03:30.120 --> 00:03:33.539 version within a seven-day window. That gives 00:03:33.539 --> 00:03:37.419 teams a real recovery path when an upgrade exposes 00:03:37.419 --> 00:03:40.659 a compatibility issue. That is useful, especially 00:03:40.659 --> 00:03:44.330 if you run a lot of clusters. have strict change 00:03:44.330 --> 00:03:48.069 windows, or operate in environments where Kubernetes 00:03:48.069 --> 00:03:51.610 upgrades are already surrounded by approvals 00:03:51.610 --> 00:03:55.009 and nervous Slack threads. But this does not 00:03:55.009 --> 00:03:58.110 make upgrades free. It does not make your workloads 00:03:58.110 --> 00:04:01.370 compatible. It does not fix every add-on problem. 00:04:01.590 --> 00:04:04.310 It does not replace staging. And it does not 00:04:04.310 --> 00:04:08.110 mean your whole cluster magically goes back in 00:04:08.110 --> 00:04:12.250 time like nothing happened. AWS also added rollback 00:04:12.250 --> 00:04:14.949 readiness checks, which is important because 00:04:14.949 --> 00:04:18.350 rollback has its own requirements. Your nodes 00:04:18.350 --> 00:04:21.589 matter. Your add-ons matter. Your disruption 00:04:21.589 --> 00:04:25.089 budgets matter. And if you use EKS Auto Mode, 00:04:25.329 --> 00:04:28.389 node rollback becomes part of the story too. 00:04:28.589 --> 00:04:32.230 That means rollback can take time. And in an 00:04:32.230 --> 00:04:35.850 incident, people hear rollback and assume fast. 00:04:36.230 --> 00:04:40.089 But safe rollback is not always instant rollback. 00:04:40.310 --> 00:04:43.329 The takeaway is pretty straightforward. Use this 00:04:43.329 --> 00:04:46.529 feature. Put it in your upgrade runbook. Test 00:04:46.529 --> 00:04:49.610 the path. Know what it does and does not cover. 00:04:49.829 --> 00:04:52.990 But do not treat the rollback button like permission 00:04:52.990 --> 00:04:56.170 to skip upgrade discipline. A rollback window 00:04:56.170 --> 00:05:00.629 is a safety net. It is not a test plan. EKS got 00:05:00.629 --> 00:05:03.670 an undo button. That is great. Just make sure 00:05:03.670 --> 00:05:11.000 that someone still owns the upgrade. Second story, 00:05:11.199 --> 00:05:15.160 Novee Security published research called Cordyceps, 00:05:15.220 --> 00:05:19.379 and this one lands directly in the your CI/CD 00:05:19.379 --> 00:05:22.819 is production code bucket. The report looks at 00:05:22.819 --> 00:05:25.759 exploitable GitHub Actions workflow patterns 00:05:25.759 --> 00:05:29.560 across high impact open source repositories. 00:05:29.620 --> 00:05:33.500 Not one weird repo, not one random bad workflow. 00:05:33.980 --> 00:05:38.779 A repeated class of CI/CD mistakes. Novee says 00:05:38.779 --> 00:05:42.620 that they scanned around 30,000 high-impact 00:05:42.620 --> 00:05:47.279 repositories and confirmed more than 300 fully 00:05:47.279 --> 00:05:50.720 exploitable attack chains. The patterns include 00:05:50.720 --> 00:05:54.540 command injection, artifact poisoning, broken 00:05:54.540 --> 00:05:58.459 trust boundaries between workflows, and untrusted 00:05:58.459 --> 00:06:02.660 pull request or comment data making its way into 00:06:02.660 --> 00:06:05.779 privileged automation. That last part matters 00:06:05.779 --> 00:06:09.519 because most teams still treat workflow YAML 00:06:09.519 --> 00:06:13.600 like config. It gets copied from another repo, tweaked 00:06:13.600 --> 00:06:16.980 until the build is green. Reviewed quickly. Then 00:06:16.980 --> 00:06:21.339 forgotten. But workflow YAML can run commands, read 00:06:21.339 --> 00:06:26.079 secrets, publish packages, sign artifacts, assume 00:06:26.079 --> 00:06:29.980 cloud roles, push containers, cut releases. That 00:06:29.980 --> 00:06:32.980 is not just automation. That is a privileged 00:06:32.980 --> 00:06:36.920 execution path. The nasty part is that these 00:06:36.920 --> 00:06:40.920 problems are often not obvious from one line. 00:06:41.139 --> 00:06:44.500 A low-trust workflow produces an artifact. A 00:06:44.500 --> 00:06:47.620 high-trust workflow consumes it later. A branch 00:06:47.620 --> 00:06:51.610 name lands in shell. A pull request title becomes 00:06:51.610 --> 00:06:55.629 command input. A cache crosses a privilege boundary. 00:06:56.009 --> 00:06:59.529 Each piece looks normal enough. Together, you 00:06:59.529 --> 00:07:03.550 accidentally gave untrusted input a path into 00:07:03.550 --> 00:07:07.790 trusted automation. And now, add AI coding agents 00:07:07.790 --> 00:07:11.170 to the picture. If agents are generating CI/CD 00:07:11.170 --> 00:07:14.649 configuration, they can reproduce insecure workflow 00:07:14.649 --> 00:07:19.319 patterns very quickly across a lot of repos. 00:07:19.439 --> 00:07:23.040 The fix is not to stop using GitHub Actions. The 00:07:23.040 --> 00:07:26.699 fix is to review workflow logic like code with 00:07:26.699 --> 00:07:29.779 production authority, threat model your triggers, 00:07:30.060 --> 00:07:33.399 separate trusted and untrusted workflows, be 00:07:33.399 --> 00:07:36.759 careful with pull_request_target, watch shell 00:07:36.759 --> 00:07:40.459 interpolation, limit token scopes, treat artifacts 00:07:40.459 --> 00:07:45.220 and caches as trust boundaries, and stop assuming 00:07:45.220 --> 00:07:49.319 YAML is harmless because it looks boring. Cordyceps 00:07:49.319 --> 00:07:52.720 is a good reminder that your pipeline is part 00:07:52.720 --> 00:07:55.899 of your supply chain. And attackers already know 00:07:55.899 --> 00:08:02.579 that. Third story. Tenet Security published 00:08:02.579 --> 00:08:05.620 research on agentjacking. The short version: 00:08:05.740 --> 00:08:09.319 They showed how a fake Sentry error report could 00:08:09.319 --> 00:08:13.019 influence AI coding agents into running 00:08:13.019 --> 00:08:15.930 attacker-controlled code. That should make platform and 00:08:15.930 --> 00:08:20.009 SRE teams pause. Because this is not only about 00:08:20.009 --> 00:08:24.050 one agent or one vendor. The bigger issue is 00:08:24.050 --> 00:08:27.889 that operational context is changing. Logs, errors, 00:08:28.209 --> 00:08:31.750 stack traces, issue descriptions, pull request 00:08:31.750 --> 00:08:35.570 comments, incident notes, runbooks. That stuff 00:08:35.570 --> 00:08:39.269 used to be mostly passive. A human read it, decided 00:08:39.269 --> 00:08:42.610 what mattered, ignored the nonsense, and took 00:08:42.610 --> 00:08:46.620 action. Now, agents are reading that same material, 00:08:46.860 --> 00:08:50.419 and sometimes they are acting on it. In Tenet's 00:08:50.419 --> 00:08:53.759 example, the attacker injects a crafted error 00:08:53.759 --> 00:08:57.179 event. The event looks like normal diagnostic 00:08:57.179 --> 00:09:01.820 context. An AI coding agent is asked to investigate 00:09:01.820 --> 00:09:05.279 or fix the issue, and the agent treats malicious 00:09:05.279 --> 00:09:08.840 content like instructions. That is the trust 00:09:08.840 --> 00:09:12.120 boundary. Not did the attacker compromise the 00:09:12.120 --> 00:09:16.360 server, but can the attacker put text somewhere the 00:09:16.360 --> 00:09:20.480 agent will trust? That is a much lower bar and 00:09:20.480 --> 00:09:23.720 a pretty uncomfortable one. A lot of our systems 00:09:23.720 --> 00:09:27.179 were built assuming that logs and error text 00:09:27.179 --> 00:09:31.100 were just evidence, not instructions. Maybe we 00:09:31.100 --> 00:09:34.600 sanitize them for display. Maybe we redact secrets. 00:09:34.960 --> 00:09:38.289 But we were not always asking whether a string 00:09:38.289 --> 00:09:41.450 in telemetry could become part of an agent's 00:09:41.450 --> 00:09:44.769 decision loop that has to change if an agent 00:09:44.769 --> 00:09:48.470 can read from observability tools open repos 00:09:48.470 --> 00:09:53.009 run commands install packages access cloud credentials 00:09:53.009 --> 00:09:57.690 or modify code then untrusted context becomes 00:09:57.690 --> 00:10:01.470 a security problem the control is not the agent 00:10:01.470 --> 00:10:05.090 is smart the control is boundaries can it read 00:10:05.090 --> 00:10:08.649 without executing Can it propose without running? 00:10:08.830 --> 00:10:11.750 Can it separate trusted remediation guidance 00:10:11.750 --> 00:10:15.409 from user-controlled error content? Can you 00:10:15.409 --> 00:10:19.389 audit what it saw and what it did? And are there 00:10:19.389 --> 00:10:23.049 live credentials sitting nearby when it makes 00:10:23.049 --> 00:10:26.710 a bad decision? The takeaway is simple. Do not 00:10:26.710 --> 00:10:30.129 wire agents into developer and incident workflows 00:10:30.129 --> 00:10:34.110 and only ask about productivity. Ask about authority. 00:10:34.450 --> 00:10:37.679 What can it touch? What can it run? What does 00:10:37.679 --> 00:10:41.179 it trust? And what happens when that context 00:10:41.179 --> 00:10:45.519 is hostile? Agentjacking is not just an AI story. 00:10:45.779 --> 00:10:49.179 It is a trust boundary story. The text around 00:10:49.179 --> 00:10:53.379 your systems can now cause action. So your trust 00:10:53.379 --> 00:11:00.820 model has to include the text. Fourth story, 00:11:01.019 --> 00:11:04.419 Amazon CloudWatch now supports creating alarms 00:11:04.419 --> 00:11:07.980 directly from log queries. This is one of those 00:11:07.980 --> 00:11:11.220 features that sounds small, but it changes how 00:11:11.220 --> 00:11:14.600 teams build alerts. Before this, alerting on 00:11:14.600 --> 00:11:17.919 logs usually meant extra glue, metric filters, 00:11:18.399 --> 00:11:21.720 custom metrics, another system. Some pipeline 00:11:21.720 --> 00:11:25.659 where a log pattern turns into a metric and then 00:11:25.659 --> 00:11:28.659 the metric turns into an alarm. Now CloudWatch 00:11:29.019 --> 00:11:32.159 can create alarms from log queries directly. 00:11:32.519 --> 00:11:35.360 Those alarms can use normal CloudWatch alarm 00:11:35.360 --> 00:11:39.059 actions, including SNS and EventBridge. That 00:11:39.059 --> 00:11:42.259 is useful. A lot of incidents show up first in 00:11:42.259 --> 00:11:46.200 logs. A specific exception. A repeated auth failure. 00:11:46.480 --> 00:11:49.879 A weird timeout. A dependency error. A line that 00:11:49.879 --> 00:11:53.139 says the thing is broken before the normal metric 00:11:53.139 --> 00:11:56.740 catches up. So yes, I like this feature. But 00:11:56.740 --> 00:11:59.779 I also fear it a little. Because easier alert 00:11:59.779 --> 00:12:03.519 creation can become easier pager noise. Someone 00:12:03.519 --> 00:12:06.500 sees an error. Someone says we should alert on 00:12:06.500 --> 00:12:09.620 that. Nobody checks how often it happens. Nobody 00:12:09.620 --> 00:12:13.720 asks whether it is user impacting. Nobody asks 00:12:13.720 --> 00:12:17.340 who owns it. Nobody checks whether the log message 00:12:17.340 --> 00:12:21.100 changes every other deploy. And suddenly your 00:12:21.100 --> 00:12:24.899 on-call rotation is getting paged by a regular 00:12:24.899 --> 00:12:28.240 expression with abandonment issues. The right 00:12:28.240 --> 00:12:31.980 use case is targeted signal. Known failure mode. 00:12:32.240 --> 00:12:36.620 Clear owner. Clear threshold. Clear action. Clear 00:12:36.620 --> 00:12:40.440 reason why a human needs to be interrupted. If 00:12:40.440 --> 00:12:43.679 the alarm fires and the on-call has no idea 00:12:43.679 --> 00:12:47.179 what to do, you probably made a search shortcut, 00:12:47.379 --> 00:12:50.799 not an alert. So this is a good CloudWatch feature. 00:12:51.100 --> 00:12:54.879 It removes glue. It shortens the path from log 00:12:54.879 --> 00:12:58.940 signal to operational response. Just be careful. 00:12:59.100 --> 00:13:03.159 The fastest way to create an alarm is not always 00:13:03.159 --> 00:13:06.820 the fastest way to create reliability. Sometimes 00:13:06.820 --> 00:13:17.840 it is just the fastest way to create noise. Quick 00:13:17.840 --> 00:13:21.860 lightning round. First, ECS Service Connect now 00:13:21.860 --> 00:13:25.789 supports zone-aware routing. AWS says It is 00:13:25.789 --> 00:13:29.190 enabled by default for new and existing services. 00:13:29.450 --> 00:13:33.370 But existing services need a one-time redeployment 00:13:33.370 --> 00:13:37.210 to pick up the behavior. The idea is to prefer 00:13:37.210 --> 00:13:40.929 same-AZ traffic when possible. That can help 00:13:40.929 --> 00:13:45.149 with latency, cross-AZ cost, and failure domain 00:13:45.149 --> 00:13:48.370 behavior. Service-to -service networking is 00:13:48.370 --> 00:13:51.850 never just connectivity. It is cost, latency, 00:13:52.129 --> 00:13:55.379 and resilience. all tangled together. Second, 00:13:55.600 --> 00:13:59.500 etcd 3.7 is out. Not the flashiest headline, 00:13:59.820 --> 00:14:04.120 but etcd is still the backing store under Kubernetes. 00:14:04.500 --> 00:14:08.340 This release includes RangeStream for streaming 00:14:08.340 --> 00:14:11.940 large result sets in chunks, plus performance 00:14:11.940 --> 00:14:16.039 work, cleanup of old v2 store remnants, Protobuf 00:14:16.039 --> 00:14:19.899 updates, and dependency updates. For most managed 00:14:19.899 --> 00:14:23.360 Kubernetes users, This is not an immediate action 00:14:23.360 --> 00:14:26.860 item, but it is a good reminder that Kubernetes 00:14:26.860 --> 00:14:30.340 reliability still depends on the boring distributed 00:14:30.340 --> 00:14:33.860 database underneath it. Third, GitHub innersource 00:14:33.860 --> 00:14:36.700 security advisories are now generally available. 00:14:37.019 --> 00:14:39.500 This gives GitHub Advanced Security customers 00:14:39.500 --> 00:14:42.899 advisory workflows for internal packages and 00:14:42.899 --> 00:14:46.440 internal repos. That matters because not every 00:14:46.440 --> 00:14:49.559 vulnerable dependency is public. Internal libraries, 00:14:50.019 --> 00:14:53.320 shared actions, platform modules, and private 00:14:53.320 --> 00:14:56.559 packages need disclosure and remediation workflows 00:14:56.559 --> 00:15:00.639 too. Fourth, GitHub secret scanning added extended 00:15:00.639 --> 00:15:04.000 metadata and multipart validation. For some 00:15:04.000 --> 00:15:08.179 secrets, the token itself is not enough to validate 00:15:08.179 --> 00:15:12.059 the risk. You may need a workspace URL, host, 00:15:12.279 --> 00:15:16.019 endpoint, project, or other related field. That 00:15:16.019 --> 00:15:19.139 sounds small. But during incident response, it 00:15:19.139 --> 00:15:22.500 matters. Finding a secret is step one. Figuring 00:15:22.500 --> 00:15:25.919 out whether it is real, live, owned, expired, 00:15:26.340 --> 00:15:29.879 scoped, and safe to revoke is where the pain 00:15:29.879 --> 00:15:32.960 starts. Fifth, CloudWatch Application Signals 00:15:32.960 --> 00:15:36.720 now captures service events automatically. AWS 00:15:36.720 --> 00:15:39.659 says that it can capture exception snapshots, 00:15:39.840 --> 00:15:43.019 latency event snapshots, and deployment events. 00:15:43.480 --> 00:15:45.960 for instrumented applications that is useful 00:15:45.960 --> 00:15:48.659 because during an incident teams do not only 00:15:48.659 --> 00:15:51.440 need to know the service is slow they need to 00:15:51.440 --> 00:15:54.580 know what changed more context near the signal 00:15:54.580 --> 00:15:57.539 is good as long as it does not turn into another 00:15:57.539 --> 00:16:09.019 wall of events that nobody owns the human closer 00:16:09.019 --> 00:16:12.340 this week is about safety nets because that is 00:16:12.340 --> 00:16:15.379 the shape of the episode. EKS gets rollback. 00:16:15.620 --> 00:16:19.600 CloudWatch gets easier log-based alarms. ECS 00:16:19.600 --> 00:16:23.639 routing gets more zone-aware. GitHub gets better 00:16:23.639 --> 00:16:26.860 advisory and secret scanning workflows. etcd 00:16:26.860 --> 00:16:29.559 gets reliability and performance improvements. 00:16:30.000 --> 00:16:33.240 Even the AI agent security story is really about 00:16:33.240 --> 00:16:36.179 figuring out where the new guardrails need to 00:16:36.179 --> 00:16:39.440 go. And I like all of that. I like rollback buttons. 00:16:39.720 --> 00:16:42.700 I like better alerts. I like scoped workflows. 00:16:43.120 --> 00:16:46.360 I like dependency and secret cleanup that does 00:16:46.360 --> 00:16:49.840 not require five spreadsheets and a prayer. But 00:16:49.840 --> 00:16:53.320 safety nets can trick teams into thinking the 00:16:53.320 --> 00:16:57.360 hard part is solved. It usually is not. A rollback 00:16:57.360 --> 00:17:00.100 button does not tell you whether the rollback 00:17:00.100 --> 00:17:03.480 is safe. An alarm does not tell you whether the 00:17:03.480 --> 00:17:06.430 signal is worth waking someone up. A scanner 00:17:06.430 --> 00:17:09.730 finding a secret does not tell you how to rotate 00:17:09.730 --> 00:17:13.309 it without breaking production. An AI agent finding 00:17:13.309 --> 00:17:16.730 a fix does not mean it should run commands on 00:17:16.730 --> 00:17:20.430 your laptop. And zone-aware routing does not 00:17:20.430 --> 00:17:23.750 mean you understand your failure domains. Tools 00:17:23.750 --> 00:17:26.710 give you better options. They do not own the 00:17:26.710 --> 00:17:30.250 system for you. That part is still on us. So 00:17:30.250 --> 00:17:33.970 take the safety nets. Use them. Be glad they 00:17:33.970 --> 00:17:37.309 exist. But do not let them replace ownership. 00:17:37.690 --> 00:17:41.150 Because in production, the worst failures are 00:17:41.150 --> 00:17:44.289 usually not the ones where you had no tools. 00:17:44.529 --> 00:17:47.170 They are the ones where everyone assumed the 00:17:47.170 --> 00:17:50.569 tool meant the thinking was done. That's it for 00:17:50.569 --> 00:17:54.049 this week’s Ship It Weekly. We covered EKS version 00:17:54.049 --> 00:17:58.230 rollbacks, Cordyceps, and CI/CD supply chain risk, 00:17:58.490 --> 00:18:01.750 agentjacking through fake telemetry. CloudWatch 00:18:01.750 --> 00:18:06.369 log query alarms, ECS zone-aware routing, etcd 00:18:06.369 --> 00:18:10.910 3 .7, GitHub advisories, secret scanning, and 00:18:10.910 --> 00:18:14.190 CloudWatch Service Events. If this episode was 00:18:14.190 --> 00:18:16.710 useful, follow or subscribe wherever you are 00:18:16.710 --> 00:18:19.150 watching or listening. If you are on YouTube, 00:18:19.430 --> 00:18:23.009 hit subscribe. If you are in a podcast app, follow 00:18:23.009 --> 00:18:25.250 the show there. And if you know someone dealing 00:18:25.250 --> 00:18:28.190 with Kubernetes upgrades, GitHub Actions security, 00:18:28.609 --> 00:18:32.369 AI Coding Agents, or Alert Noise, send them this 00:18:32.369 --> 00:18:35.329 one. It genuinely helps the show grow, and it 00:18:35.329 --> 00:18:38.390 helps me keep making this for the people who actually 00:18:38.390 --> 00:18:41.250 live with these systems. You can find the weekly 00:18:41.250 --> 00:18:44.730 brief at OnCallBrief.com and the full show notes, 00:18:44.930 --> 00:18:49.049 links, and past episodes at ShipItWeekly.fm. 00:18:49.109 --> 00:18:51.690 I'm Brian Teller from Teller's Tech. Thanks for 00:18:51.690 --> 00:18:54.529 listening. And remember, safety nets are good. 00:18:54.990 --> 00:18:56.730 but they do not replace ownership.