WEBVTT 00:00:00.000 --> 00:00:03.419 PeopleSoft gets hit by a zero-day. npm changes 00:00:03.419 --> 00:00:07.519 what code is allowed to run during install. GitHub 00:00:07.519 --> 00:00:11.039 removes long-lived personal access tokens from 00:00:11.039 --> 00:00:14.599 agentic workflows. And Anthropic reminds everyone 00:00:14.599 --> 00:00:18.620 that your AI dependency can disappear for reasons 00:00:18.620 --> 00:00:21.440 that have nothing to do with uptime. The theme 00:00:21.440 --> 00:00:24.519 this week is simple. Default trust is getting 00:00:24.519 --> 00:00:27.820 punished. Old enterprise systems were trusted. 00:00:28.219 --> 00:00:31.140 because they were internal. Package installs 00:00:31.140 --> 00:00:33.939 were trusted because that is just how the ecosystem 00:00:33.939 --> 00:00:37.679 worked. CI/CD tokens were trusted because they 00:00:37.679 --> 00:00:41.000 were convenient. AI models were trusted because 00:00:41.000 --> 00:00:44.420 the API worked yesterday. But production does 00:00:44.420 --> 00:00:47.560 not care why you trusted something. It only cares 00:00:47.560 --> 00:00:50.920 what that trust was allowed to do. I'm Brian 00:00:50.920 --> 00:00:53.719 Teller from Teller's Tech, and this is Ship It 00:00:53.719 --> 00:01:13.900 Weekly. Welcome back to Ship It Weekly, the show 00:01:13.900 --> 00:01:18.040 where we look at the DevOps, SRE, cloud, platform, 00:01:18.200 --> 00:01:21.519 and security stories that actually matter when 00:01:21.519 --> 00:01:23.819 you are the person who eventually has to keep 00:01:23.819 --> 00:01:26.420 the thing running. This week is about default 00:01:26.420 --> 00:01:29.420 trust. We're starting with Oracle PeopleSoft 00:01:29.420 --> 00:01:32.620 and a zero-day that was reportedly exploited 00:01:32.620 --> 00:01:35.879 before Oracle released an emergency patch. Then 00:01:35.879 --> 00:01:39.290 we'll talk npm v12. changing install-script 00:01:39.290 --> 00:01:42.370 defaults which is great for supply-chain security 00:01:42.370 --> 00:01:45.969 and maybe a little annoying for some CI pipelines 00:01:45.969 --> 00:01:49.670 after that we'll get into github agentic workflows 00:01:49.670 --> 00:01:53.430 no longer needing personal access tokens which 00:01:53.430 --> 00:01:56.310 is the kind of boring credential change that 00:01:56.310 --> 00:01:59.349 actually matters then we'll talk about Anthropic 00:01:59.349 --> 00:02:04.010 disabling fable 5 and mythos 5 after a us export 00:02:04.010 --> 00:02:07.519 control directive because AI model availability 00:02:07.519 --> 00:02:11.319 is now also a policy-risk dependency. In the 00:02:11.319 --> 00:02:14.300 lightning round, we'll hit Tekton CloudEvents 00:02:14.300 --> 00:02:17.500 moving to a dedicated events controller, NVIDIA 00:02:17.500 --> 00:02:21.939 Triton 26.04 changing inference server defaults, 00:02:21.939 --> 00:02:25.759 AWS Nitro Isolation Engine using formal verification, 00:02:26.060 --> 00:02:30.629 and Homebrew 6.0 requiring explicit trust for 00:02:30.629 --> 00:02:33.469 third-party taps. The human closer this week 00:02:33.469 --> 00:02:37.150 is about trust defaults, because a lot of incidents 00:02:37.150 --> 00:02:40.490 start with one quiet assumption. The system is 00:02:40.490 --> 00:02:44.310 internal. The package is fine. This token is 00:02:44.310 --> 00:02:47.889 safe. This model will be there tomorrow. And 00:02:47.889 --> 00:02:50.990 sometimes that assumption is the real production 00:02:50.990 --> 00:02:59.259 dependency. So let's get into it. Oracle issued 00:02:59.259 --> 00:03:05.659 an emergency advisory for CVE-2026-35273 in 00:03:05.659 --> 00:03:09.699 PeopleSoft PeopleTools. And yes, I know, PeopleSoft 00:03:09.699 --> 00:03:12.379 does not sound like the kind of shiny cloud-native 00:03:12.379 --> 00:03:15.159 story that makes people sprint to the podcast 00:03:15.159 --> 00:03:18.659 app. But that is exactly why it matters. A lot 00:03:18.659 --> 00:03:21.699 of modern companies still depend on older enterprise 00:03:21.699 --> 00:03:25.900 systems for HR, finance, payroll, student records, 00:03:26.199 --> 00:03:29.610 supply-chain. and all the boring data that becomes 00:03:29.610 --> 00:03:32.930 extremely exciting when attackers get it. Oracle 00:03:32.930 --> 00:03:35.930 says that the vulnerability is remotely exploitable 00:03:35.930 --> 00:03:39.310 without authentication and can result in remote 00:03:39.310 --> 00:03:42.409 code execution. Public reporting says exploitation 00:03:42.409 --> 00:03:46.169 was observed before Oracle's emergency advisory, 00:03:46.289 --> 00:03:49.469 with ShinyHunters linked activity targeting 00:03:49.469 --> 00:03:52.469 mostly U.S. organizations, especially higher 00:03:52.469 --> 00:03:55.069 education. So the shape of the story is pretty 00:03:55.069 --> 00:03:57.740 clear. Old enterprise application, sensitive 00:03:57.740 --> 00:04:01.159 data, remote unauthenticated exploit, active 00:04:01.159 --> 00:04:04.439 exploitation, emergency patch. That is a bad 00:04:04.439 --> 00:04:07.340 combination. And the lesson for DevOps, SRE, 00:04:07.500 --> 00:04:11.159 platform, and cloud teams is not just patch PeopleSoft. 00:04:11.180 --> 00:04:14.580 Although, yes, obviously, patch PeopleSoft. The 00:04:14.580 --> 00:04:17.230 bigger lesson... is that the enterprise app tier 00:04:17.230 --> 00:04:20.269 is still part of your perimeter, even if everyone 00:04:20.269 --> 00:04:23.310 emotionally moved on to Kubernetes. A lot of 00:04:23.310 --> 00:04:26.550 teams have a weird relationship with older enterprise 00:04:26.550 --> 00:04:30.129 platforms. They are important enough that nobody 00:04:30.129 --> 00:04:33.329 can turn them off, but old enough that nobody 00:04:33.329 --> 00:04:36.389 really wants to own them. They live in a special 00:04:36.389 --> 00:04:39.589 network zone. They have a special upgrade window. 00:04:39.769 --> 00:04:42.449 They have special vendor requirements. They have 00:04:42.449 --> 00:04:46.329 special firewall rules. from 2017 that everyone 00:04:46.329 --> 00:04:49.709 is afraid to touch. And somehow, because they 00:04:49.709 --> 00:04:52.410 are enterprise apps, people stop thinking of 00:04:52.410 --> 00:04:55.050 them like internet-exposed production systems. 00:04:55.389 --> 00:04:58.430 Attackers do not care what generation of architecture 00:04:58.430 --> 00:05:01.430 the system belongs to. They care whether it has 00:05:01.430 --> 00:05:05.310 data, access, and a path in. PeopleSoft may not 00:05:05.310 --> 00:05:08.470 be the cool part of your stack, but if it holds 00:05:08.470 --> 00:05:12.529 HR data, finance data, student data, employee 00:05:12.529 --> 00:05:16.199 data, or business workflow data, it is very much 00:05:16.199 --> 00:05:19.199 part of your attack surface. This is also a good 00:05:19.199 --> 00:05:22.699 reminder that legacy does not mean low-priority. 00:05:23.000 --> 00:05:26.699 Sometimes legacy means high-value, hard-to-patch, 00:05:26.879 --> 00:05:30.899 badly isolated, and full of data. That is not 00:05:30.899 --> 00:05:33.740 low-priority. That is where an attacker brings 00:05:33.740 --> 00:05:36.779 a shovel. The practical takeaway is simple. Know 00:05:36.779 --> 00:05:39.540 where these systems are. Know whether they are 00:05:39.540 --> 00:05:42.980 internet exposed. Know who owns patching. Know 00:05:42.980 --> 00:05:46.439 who owns logs. Know what normal access looks 00:05:46.439 --> 00:05:49.800 like. Know whether unusual agents, web shells, 00:05:50.019 --> 00:05:53.620 or scheduled tasks would actually be noticed. 00:05:53.939 --> 00:05:57.000 And if you are a platform or cloud team that 00:05:57.000 --> 00:06:00.120 thinks this is someone else's problem, be careful. 00:06:00.360 --> 00:06:03.620 Because during the incident call, someone else's 00:06:03.620 --> 00:06:07.439 problem has a funny way of becoming why did nobody 00:06:07.439 --> 00:06:11.639 know this existed. Your ERP systems, HR systems, 00:06:11.939 --> 00:06:15.560 finance systems, and admin portals are production 00:06:15.560 --> 00:06:24.079 systems. Treat them that way. Second story. npm 00:06:24.079 --> 00:06:27.579 v12 is changing some defaults around install 00:06:27.579 --> 00:06:30.019 scripts. And this one matters to developers, 00:06:30.279 --> 00:06:34.000 platform teams, CI maintainers, security teams, 00:06:34.100 --> 00:06:37.139 and anyone who has ever watched an npm install 00:06:37.139 --> 00:06:40.879 do 12 things they did not explicitly ask it to 00:06:40.879 --> 00:06:44.620 do. GitHub says npm v12 is expected in 00:06:44.620 --> 00:06:48.139 July 2026. And one of the big breaking changes 00:06:48.139 --> 00:06:51.920 is that allowScripts will default to off. That 00:06:51.920 --> 00:06:55.779 means npm install will no longer execute pre 00:06:55.779 --> 00:06:59.300 -install, install, or postinstall-scripts from 00:06:59.300 --> 00:07:02.459 dependencies unless they are explicitly allowed. 00:07:02.970 --> 00:07:06.449 Prepare scripts from git, file, and link dependencies 00:07:06.449 --> 00:07:09.370 are blocked the same way. These settings are 00:07:09.370 --> 00:07:14.250 already available in npm 11.16.0 for migration 00:07:14.250 --> 00:07:18.529 testing. This is a big ecosystem shift. For years, 00:07:18.689 --> 00:07:22.230 npm install has been more powerful than people 00:07:22.230 --> 00:07:25.230 like to admit. You run the package install. The 00:07:25.230 --> 00:07:28.470 package runs code. That code might build native 00:07:28.470 --> 00:07:31.529 bindings, download binaries, generate files. 00:07:32.220 --> 00:07:35.180 patch something, bootstrap something, do the 00:07:35.180 --> 00:07:38.279 magic that makes everything work. But that same 00:07:38.279 --> 00:07:41.800 install-time execution path is also a supply 00:07:41.800 --> 00:07:45.060 chain attack surface. A malicious package does 00:07:45.060 --> 00:07:48.220 not need your app to import it at runtime if 00:07:48.220 --> 00:07:51.279 it can run code during install. It only needs 00:07:51.279 --> 00:07:54.560 to land in the dependency tree. Then the CI runner, 00:07:54.779 --> 00:07:57.970 developer laptop, or build machine does the rest. 00:07:58.189 --> 00:08:01.009 This is why this change matters. It moves the 00:08:01.009 --> 00:08:04.389 ecosystem from implicit trust towards explicit 00:08:04.389 --> 00:08:07.610 trust. And yes, that is good. But some builds 00:08:07.610 --> 00:08:10.470 are going to break. Because a lot of pipelines 00:08:10.470 --> 00:08:14.029 have been relying on install-time magic without 00:08:14.029 --> 00:08:17.370 documenting it. Native modules. Post install 00:08:17.370 --> 00:08:20.670 downloads. Git dependencies. File dependencies. 00:08:21.170 --> 00:08:24.389 Link dependencies. Internal packages. Packages 00:08:24.389 --> 00:08:27.939 that compile. Packages that generate code. Packages 00:08:27.939 --> 00:08:31.459 that do one tiny little install step that nobody 00:08:31.459 --> 00:08:34.059 has looked at since the person who wrote it left 00:08:34.059 --> 00:08:36.980 the company. Those assumptions are about to become 00:08:36.980 --> 00:08:40.059 visible. And visibility is great. Right after 00:08:40.059 --> 00:08:42.659 it ruins your Tuesday. The practical takeaway 00:08:42.659 --> 00:08:46.320 is not panic about npm v12. The takeaway 00:08:46.320 --> 00:08:49.960 is to test early. Run builds with the new behavior 00:08:49.960 --> 00:08:53.659 before it becomes the default. Find which dependencies 00:08:54.320 --> 00:08:57.539 need scripts. Decide which scripts you actually 00:08:57.539 --> 00:09:01.399 trust. Document why. And do not just flip everything 00:09:01.399 --> 00:09:05.399 back on because one pipeline failed. That defeats 00:09:05.399 --> 00:09:07.820 the point. This is a chance to clean up dependency 00:09:07.820 --> 00:09:11.500 trust, especially in CI. Ask what install-scripts 00:09:11.500 --> 00:09:14.860 run today. Ask whether CI runners have secrets 00:09:14.860 --> 00:09:18.059 available during install. Ask whether build steps 00:09:18.059 --> 00:09:21.500 can reach internal services. Ask whether developers 00:09:21.500 --> 00:09:24.419 are running installs on machines with cloud credentials, 00:09:24.779 --> 00:09:28.320 SSH keys, or package publishing rights. Because 00:09:28.320 --> 00:09:31.639 the blast radius of an install-script is not 00:09:31.639 --> 00:09:34.179 just the package. It is whatever the install 00:09:34.179 --> 00:09:37.179 environment can access. I like this change. It 00:09:37.179 --> 00:09:40.100 is going to annoy people, but sometimes the annoying 00:09:40.100 --> 00:09:43.659 default is the correct default. npm install is 00:09:43.659 --> 00:09:46.399 finally getting less magical. And that means 00:09:46.399 --> 00:09:49.000 that some teams are about to discover how much 00:09:49.000 --> 00:09:56.759 magic they were depending on. Third story. GitHub 00:09:56.759 --> 00:10:00.139 says agentic workflows no longer need a personal 00:10:00.139 --> 00:10:03.419 access token. And yes, that sounds boring. But 00:10:03.419 --> 00:10:06.019 boring credential changes are often the ones 00:10:06.019 --> 00:10:08.980 that save you later. Previously, agentic workflows 00:10:08.980 --> 00:10:12.519 needed personal access tokens in certain setups. 00:10:12.779 --> 00:10:15.940 Now GitHub says, These workflows can use the 00:10:15.940 --> 00:10:18.980 built-in GITHUB_TOKEN and the copilot 00:10:18.980 --> 00:10:21.720 request write permission instead. The point is 00:10:21.720 --> 00:10:24.779 to avoid creating and storing long-lived personal 00:10:24.779 --> 00:10:28.220 access tokens for agentic workflows. This matters 00:10:28.220 --> 00:10:32.039 because agentic CI/CD is already risky enough. 00:10:32.399 --> 00:10:35.700 These workflows can read context, generate changes, 00:10:36.120 --> 00:10:39.460 open pull requests, review code, call tools, 00:10:39.860 --> 00:10:43.100 interact with repo state, and eventually, in 00:10:43.100 --> 00:10:46.009 some environments, they may become part of release, 00:10:46.269 --> 00:10:50.029 remediation, triage, or automation paths. So 00:10:50.029 --> 00:10:53.070 the credentials they use matter a lot. A personal 00:10:53.070 --> 00:10:56.730 access token is often tied to a person. It may 00:10:56.730 --> 00:10:59.529 be long-lived. It may have broad permissions. 00:10:59.889 --> 00:11:03.090 It may sit in secrets. It may get copied between 00:11:03.090 --> 00:11:06.590 repos. It may survive longer than anyone intended. 00:11:06.909 --> 00:11:09.710 It may still exist after the workflow changed, 00:11:09.909 --> 00:11:12.889 the person changed teams, or everyone forgot. 00:11:13.480 --> 00:11:16.220 why the token was created. That is not a great 00:11:16.220 --> 00:11:19.279 pattern for agentic automation. A scoped workflow 00:11:19.279 --> 00:11:22.419 token is not magic. You still have to configure 00:11:22.419 --> 00:11:25.080 it correctly. You still have to review permissions. 00:11:25.519 --> 00:11:28.279 You still have to think about which events can 00:11:28.279 --> 00:11:30.759 trigger the workflow. You still have to worry 00:11:30.759 --> 00:11:34.080 about untrusted input. But it is a better default 00:11:34.080 --> 00:11:37.039 than handing an agent a long-lived personal 00:11:37.039 --> 00:11:40.080 credential and hoping everyone remembers where 00:11:40.080 --> 00:11:42.940 it lives. The platform takeaway is simple. If 00:11:42.940 --> 00:11:45.440 you are experimenting with agentic workflows 00:11:45.440 --> 00:11:48.840 in GitHub, review the whole trust model. What 00:11:48.840 --> 00:11:51.840 repos can run it? What events can trigger them? 00:11:52.019 --> 00:11:54.679 What permissions do they get? Can pull request 00:11:54.679 --> 00:11:58.080 content influence the agent? Can issue comments 00:11:58.080 --> 00:12:01.019 influence the agent? Can the agent write code? 00:12:01.320 --> 00:12:04.059 Can it approve changes? Can it call external 00:12:04.059 --> 00:12:07.559 tools? Can it see secrets? Can it publish artifacts? 00:12:08.000 --> 00:12:11.399 Can it affect production? And are you still using 00:12:11.399 --> 00:12:14.460 personal access tokens where you do not need 00:12:14.460 --> 00:12:17.240 them? Because agents are not just assistants 00:12:17.240 --> 00:12:20.580 once they enter CI/CD. They become automation 00:12:20.580 --> 00:12:24.159 services. And automation surfaces need boring, 00:12:24.320 --> 00:12:28.059 strict, reviewable credentials. So yes, use the 00:12:28.059 --> 00:12:31.179 better GitHub auth model. But do not stop there. 00:12:31.399 --> 00:12:34.460 If it can change code, trigger work, or spend 00:12:34.460 --> 00:12:37.340 money, it belongs in your production automation 00:12:37.340 --> 00:12:45.200 threat model. Fourth story. Anthropic published 00:12:45.200 --> 00:12:47.379 a statement saying that the U.S. government 00:12:47.379 --> 00:12:50.659 issued an export-control directive requiring 00:12:50.659 --> 00:12:54.860 Anthropic to suspend access to Fable 5 and Mythos 00:12:54.860 --> 00:12:58.559 5 by any foreign national, whether inside or 00:12:58.559 --> 00:13:01.159 outside the United States, including foreign 00:13:01.159 --> 00:13:03.840 national Anthropic employees. Anthropic said 00:13:03.840 --> 00:13:06.480 that the net effect was that it had to abruptly 00:13:06.480 --> 00:13:10.559 disable Fable 5 and Mythos 5 for all customers. 00:13:11.039 --> 00:13:14.039 to ensure compliance. Access to other Anthropic 00:13:14.039 --> 00:13:17.320 models was not affected. Now, this is not a normal 00:13:17.320 --> 00:13:20.279 SRE outage. There was not a regional failure. 00:13:20.539 --> 00:13:24.080 There was not a bad deploy. There was not a database 00:13:24.080 --> 00:13:27.220 incident. There was not a capacity problem. But 00:13:27.220 --> 00:13:30.120 for customers who depend on those models, the 00:13:30.120 --> 00:13:33.419 effect is still operational. The dependency disappeared. 00:13:33.950 --> 00:13:36.990 and it disappeared for policy reasons. That is 00:13:36.990 --> 00:13:40.190 the lesson. If AI APIs are part of your production 00:13:40.190 --> 00:13:43.669 path, dependency risk is no longer just uptime, 00:13:43.809 --> 00:13:48.210 latency, quota, and cost. It is also model availability, 00:13:48.570 --> 00:13:51.929 geography, export-controls, regulatory shifts, 00:13:52.269 --> 00:13:56.210 vendor policy, safety policy, commercial access, 00:13:56.610 --> 00:13:58.990 model deprecation, compliance interpretation, 00:13:59.409 --> 00:14:02.470 and whatever new category we invent next quarter. 00:14:02.809 --> 00:14:05.590 This is uncomfortable because AI dependencies 00:14:05.590 --> 00:14:09.190 can be harder to substitute than people pretend. 00:14:09.470 --> 00:14:13.950 You can usually swap one HTTP endpoint for another 00:14:13.950 --> 00:14:17.289 at a code level. But can you swap the behavior, 00:14:17.509 --> 00:14:21.090 the context window, the latency, the tool calling 00:14:21.090 --> 00:14:24.629 behavior, the moderation behavior, the cost profile, 00:14:24.970 --> 00:14:28.690 the prompt format, the eval results, the customer 00:14:28.690 --> 00:14:31.820 experience, the internal workflow? The fallback 00:14:31.820 --> 00:14:34.899 may not be use a different model. The fallback 00:14:34.899 --> 00:14:38.820 may be a degraded mode, a smaller model, a cached 00:14:38.820 --> 00:14:42.620 response, a human review queue, a simpler workflow, 00:14:42.919 --> 00:14:46.279 a feature flag, a regional restriction, or a 00:14:46.279 --> 00:14:49.700 message that says this capability is temporarily 00:14:49.700 --> 00:14:53.480 unavailable. Boring fallback behavior is better 00:14:53.480 --> 00:14:56.379 than waking up to discover your product path 00:14:56.379 --> 00:14:59.500 depends on a model that is no longer available 00:14:59.500 --> 00:15:03.049 to you. The practical takeaway is to add AI models 00:15:03.049 --> 00:15:06.850 to your dependency register like any other production 00:15:06.850 --> 00:15:10.269 dependency. Track which features use which model. 00:15:10.429 --> 00:15:13.389 Track whether the model is in a critical path. 00:15:13.690 --> 00:15:17.409 Track where your users are. Track fallback options. 00:15:17.690 --> 00:15:20.590 Track whether you can degrade gracefully. Track 00:15:20.590 --> 00:15:23.769 whether a vendor-side access change would be 00:15:23.769 --> 00:15:27.629 an incident. And test the fallback. Do not just 00:15:27.629 --> 00:15:30.470 write... Fall back to another model in a doc 00:15:30.470 --> 00:15:34.029 and call it done. Actually try it. Because the 00:15:34.029 --> 00:15:37.090 weird thing about AI infrastructure is that even 00:15:37.090 --> 00:15:40.269 when the API shape looks portable, the behavior 00:15:40.269 --> 00:15:43.690 is not. Your AI dependency can disappear for 00:15:43.690 --> 00:15:46.590 reasons that have nothing to do with uptime. 00:15:46.730 --> 00:15:50.129 That means your reliability plan needs to cover 00:15:50.129 --> 00:16:00.779 more than outages. Now let's do a quick lightning 00:16:00.779 --> 00:16:03.899 round. First, Tekton pipelines changed how cloud 00:16:03.899 --> 00:16:07.159 events are sent. Cloud events for PipelineRuns 00:16:07.159 --> 00:16:11.120 and TaskRuns now move through a dedicated Tekton 00:16:11.120 --> 00:16:14.200 events controller instead of the core pipeline 00:16:14.200 --> 00:16:17.700 run and task run controllers. That means operators 00:16:17.700 --> 00:16:20.600 need to make sure the tekton-events-controller 00:16:20.600 --> 00:16:23.860 deployment is actually running. Small looking 00:16:23.860 --> 00:16:26.980 platform changes like this can have real operational 00:16:26.980 --> 00:16:30.840 impact. If CI/CD observability, event routing, 00:16:31.080 --> 00:16:34.340 notifications, or automation depends on Tekton 00:16:34.340 --> 00:16:37.500 events, make sure the new controller is deployed, 00:16:37.799 --> 00:16:40.600 monitored, and part of the upgrade checklist. 00:16:41.059 --> 00:16:43.980 Because the pipeline ran, but the event never 00:16:43.980 --> 00:16:46.980 showed up, is exactly the kind of thing that 00:16:46.980 --> 00:16:50.679 sends teams into Slack archaeology. Second, NVIDIA 00:16:50.679 --> 00:16:55.840 Triton Inference Server 26.04 has changes operators 00:16:55.840 --> 00:16:59.120 should read before upgrading. Client shared memory 00:16:59.120 --> 00:17:02.600 is now disabled by default and must be enabled 00:17:02.600 --> 00:17:06.420 explicitly if you rely on the old behavior. Triton 00:17:06.420 --> 00:17:10.099 also enforces max inflight requests as a shared 00:17:10.099 --> 00:17:13.319 limit across ensemble requests, which is meant 00:17:13.319 --> 00:17:16.339 to prevent unbounded queue growth in ensemble 00:17:16.339 --> 00:17:19.700 pipelines. The short version is this. AI inference 00:17:19.700 --> 00:17:22.720 servers are now normal platform infrastructure. 00:17:23.180 --> 00:17:26.440 Defaults change. queue behavior changes, memory 00:17:26.440 --> 00:17:30.000 behavior changes, model control changes. So upgrade 00:17:30.000 --> 00:17:33.279 them like production systems, not sidecar experiments. 00:17:33.799 --> 00:17:37.680 Third, AWS published a deep dive on the Nitro 00:17:37.680 --> 00:17:41.420 Isolation Engine. AWS says the Nitro Isolation 00:17:41.420 --> 00:17:45.160 Engine is generally available on Graviton5-based 00:17:45.160 --> 00:17:49.240 instances and uses formal verification to demonstrate 00:17:49.240 --> 00:17:52.240 isolation properties. That is interesting because 00:17:52.240 --> 00:17:55.240 cloud isolation is usually something customers 00:17:55.240 --> 00:17:59.319 trust, but cannot directly inspect. Formal verification 00:17:59.319 --> 00:18:03.039 does not mean bugs are impossible, but it does 00:18:03.039 --> 00:18:06.039 show where cloud providers are heading. Smaller 00:18:06.039 --> 00:18:08.619 trusted components, tighter isolation boundaries, 00:18:08.960 --> 00:18:11.880 and mathematically checked properties for the 00:18:11.880 --> 00:18:14.480 parts that protect customer workloads. Fourth, 00:18:14.680 --> 00:18:18.180 Homebrew 6.0 introduced tap trust. Homebrew 00:18:18.180 --> 00:18:21.700 now requires explicit trust. for third-party 00:18:21.700 --> 00:18:25.039 taps before evaluating or running their Ruby 00:18:25.039 --> 00:18:28.839 code, while official taps remain trusted by default. 00:18:29.039 --> 00:18:32.000 This is another supply-chain default, changing 00:18:32.000 --> 00:18:35.200 from sure, run it, to are you sure you trust 00:18:35.200 --> 00:18:38.319 this? And that is good. A third-party tap can 00:18:38.319 --> 00:18:41.400 contain arbitrary Ruby. If your developer laptops, 00:18:41.859 --> 00:18:45.279 CI runners, or bootstrap scripts use Homebrew, 00:18:45.660 --> 00:18:48.480 This change is worth knowing about. Some installs 00:18:48.480 --> 00:18:52.539 may prompt or fail until trust is explicit. That 00:18:52.539 --> 00:18:55.559 might annoy people. But again, that is the point. 00:18:55.799 --> 00:18:58.519 Developer tooling is part of the supply-chain. 00:18:58.680 --> 00:19:01.819 And fewer things should get to run code just 00:19:01.819 --> 00:19:12.480 because they were convenient. The human closer 00:19:12.480 --> 00:19:15.599 this week is about default trust. PeopleSoft 00:19:15.599 --> 00:19:18.640 was trusted because it was an enterprise system 00:19:18.640 --> 00:19:22.099 that had been around forever. npm install was 00:19:22.099 --> 00:19:25.019 trusted because package managers have always 00:19:25.019 --> 00:19:27.880 done some magic. agentic workflows were trusted 00:19:27.880 --> 00:19:30.880 with personal tokens because that was the easy 00:19:30.880 --> 00:19:34.240 path. AI models were trusted because the API 00:19:34.240 --> 00:19:37.740 was available yesterday. Tekton events were trusted 00:19:37.740 --> 00:19:40.559 to keep flowing. Triton defaults were trusted 00:19:40.559 --> 00:19:43.740 until they changed. Cloud isolation was trusted 00:19:43.740 --> 00:19:46.940 because that is the cloud model. Homebrew taps 00:19:46.940 --> 00:19:50.480 were trusted because developer tooling has historically 00:19:50.480 --> 00:19:54.000 been pretty casual about running code. Different 00:19:54.000 --> 00:19:57.359 stories, same pattern. Production risk often 00:19:57.359 --> 00:20:00.880 hides inside the trust defaults nobody has revisited. 00:20:01.039 --> 00:20:04.039 The system is internal. The install-script is 00:20:04.039 --> 00:20:07.359 normal. The token is convenient. The model will 00:20:07.359 --> 00:20:11.099 be available. the event will fire the tap is 00:20:11.099 --> 00:20:15.359 probably fine those assumptions may be true until 00:20:15.359 --> 00:20:18.759 they are not so the practical question this week 00:20:18.759 --> 00:20:22.319 is simple what are you trusting by default which 00:20:22.319 --> 00:20:26.059 enterprise apps are still exposed which package 00:20:26.059 --> 00:20:30.670 installs run code in ci which agents still use 00:20:30.670 --> 00:20:34.849 long-lived tokens which ai models sit in production 00:20:34.849 --> 00:20:38.569 paths which developer tools can execute code 00:20:38.569 --> 00:20:42.170 before anyone reviews it that is platform work 00:20:42.170 --> 00:20:45.049 now not just building the shiny new thing but 00:20:45.049 --> 00:20:48.250 revisiting the old trust assumptions before attackers 00:20:48.250 --> 00:20:52.450 vendors regulators or outages revisit them for 00:20:52.450 --> 00:20:56.230 you find the defaults then decide whether they 00:20:56.230 --> 00:20:59.609 still deserve your trust That's it for this week 00:20:59.609 --> 00:21:02.769 of Ship It Weekly. We covered the Oracle PeopleSoft 00:21:02.769 --> 00:21:06.210 zero-day, npm v12 install-script changes, 00:21:06.690 --> 00:21:09.950 GitHub agentic workflows moving away from personal 00:21:09.950 --> 00:21:13.390 access tokens, Anthropic's Fable and Mythos model 00:21:13.390 --> 00:21:16.369 suspension, and a lightning round on Tekton, 00:21:16.589 --> 00:21:20.430 NVIDIA Triton, AWS Nitro Isolation Engine, and 00:21:20.430 --> 00:21:24.089 Homebrew 6.0 tap trust. If this episode was 00:21:24.089 --> 00:21:26.630 useful, follow or subscribe wherever you are 00:21:26.630 --> 00:21:29.079 watching or listening. If you are on YouTube, 00:21:29.319 --> 00:21:32.819 hit subscribe. If you're in a podcast app, follow 00:21:32.819 --> 00:21:35.039 the show there. And if you know someone dealing 00:21:35.039 --> 00:21:38.400 with enterprise app security, CI/CD supply-chain 00:21:38.400 --> 00:21:41.839 risk, agentic workflows, AI dependency planning, 00:21:42.079 --> 00:21:45.319 or developer tool trust, send this one to them. 00:21:45.420 --> 00:21:48.039 It helps the show grow, and it helps me keep 00:21:48.039 --> 00:21:51.039 making this kind of content for people who actually 00:21:51.039 --> 00:21:53.779 live with these systems. You can find the weekly 00:21:53.779 --> 00:21:57.200 brief at OnCallBrief.com, and more episodes 00:21:57.200 --> 00:22:00.900 and show notes at shipitweekly.fm. I'm Brian 00:22:00.900 --> 00:22:03.099 Teller from Teller's Tech. Thanks for listening. 00:22:03.279 --> 00:22:06.599 And remember, production does not care why you 00:22:06.599 --> 00:22:09.660 trusted the default. It only cares what that 00:22:09.660 --> 00:22:11.460 default was allowed to do.