Amazon S3 Files, Malicious npm Plugins, Trivy Fallout, and Kubernetes’ Gateway Shift

Transcript

A lot of infrastructure stories sound small right

up until they change how people build. S3 gets

a file system interface. A fake plugin turns

into a foothold. A security incident comes back

for a second round and gets worse. An old Kubernetes

path starts running out of runway. And the next

generation of workloads is already pushing the

platform to act differently. That's the story

this week. Not just new features. more like the

layers around the system are becoming the system

hey i'm brian teller i work in devops and sre

and i run teller's tech this is ship it weekly

where I filter the noise and focus on what actually

changes how we run infrastructure and own reliability.

Show notes and links are on shipitweekly .fm.

If the show's been useful, follow it wherever

you listen. Ratings help way more than they should.

And if you want more signal between episodes,

check out oncallbrief .com. We have five main

stories today, then the lightning round, and

we'll wrap with the human closer. we're starting

with amazon s3 files because aws just changed

the way that s3 can show up in applications and

i think people are going to oversimplify that

story really fast then we've got the malicious

npm packages pretending to be Strapi plugins

which is just a very 2026 supply chain story

after that trivia again but this time as the

uglier follow -on we talked about the earlier

incident before and now the sequel is broader

and hits the ci path even harder then we'll hit

kubernetes ingress to gateway 1 .0 and the bigger

reality that teams are going to have to migrate

towards gateway api without pretending that this

is a one -click swap and finally kubernetes agent

sandbox because the platform is already starting

to admit that agent -style workloads are different

Story one. Amazon S3 files is interesting, but

I would not call it S3 is EFS now. Let's start

there. AWS launched S3 files this week, and the

headline version is simple. You can expose an

S3 bucket as a file system and mount it from

EC2, ECS, EKS, or Lambda. AWS says it supports

NFS version 4 .1 operations, syncs changes back

to S3, and uses a high -performance active data

layer to make file access fast. What I think

is interesting here is how this compares to the

old S3FS or generic FUSE -style pattern. Because

people have been trying to make S3 feel like

a file system forever. But that old approach

usually came with the usual caveats. Weird semantics.

performance trade -offs, caching weirdness, consistency

questions. General, yes, it mounts, but should

it? Energy. This feels smarter than that. Not

because it magically turns object storage into

a perfect shared file system, but because AWS

is very clearly building and managing the translation

layer for you instead of leaving you to duct

tape it together yourself. So this is related

to the old S3FS and FUSE idea in the sense that

it solves the same human problem. which is my

app or tool wants files, not bucket APIs. But

it is not just a nicer wrapper around the same

old hack. It is AWS putting a managed service

boundary around the pattern. That said, I still

would not read this as S3 is basically EFS now.

I think the better read is that AWS put a managed

file system layer in front of S3 so file -based

tools and workloads can interact with bucket

data more naturally. especially AI and ML -style

workflows, without everybody inventing their

own copy pipeline or mount trick. Where I still

have questions is real -world behavior once this

is under pressure, multi -writer contention.

Sync behavior. What the latency story looks like

once the happy path cache assumptions stop being

happy. So for me, the takeaway is not S3 replaced

file storage. It is more like the object store

just got a much friendlier interface for workloads

that were never really written to think in buckets.

And that matters because once the interface changes,

people start building differently. Story 2. The

fake Strapi plugin story is ugly, but very believable.

Next up, the supply chain mess. Researchers found

36 malicious NPM packages disguised as Strapi

plugins. They followed the Strapi plugin naming

pattern, used post -install scripts, and came

with different payloads aimed at Redis and Postgres

SQL. credential harvesting, reverse shells, and

persistence. That is the part that I think lands.

Not just NPM had malware again, more like this

is what the modern trust problem looks like.

The package ecosystem, the install workflow,

the environment variables, the local services,

the containers, the database paths. All of that

is fair game once developers or pipelines run

something they should not have trusted. And I

think the Strapi angle is useful too. Because

it plays on something real. Developers expect

there to be plugins. They expect those plugins

to be named in ways that feel obvious. Attackers

know that. So the trick is not brilliance. It

is just getting close enough to expected behavior

that nobody slows down. That's why these stories

matter. Not because every team uses Strapi. Because

every team uses something with a plugin model,

a package manager, and a little too much trust

in what shows up during install. Story 3. Trivia

is back, and this one is the uglier sequel. Next

up, the trivia follow -up. We talked about the

earlier trivia incident back in episode 24. This

is not just the same story repeated. This is

the second chapter, and Aqua's own write -up

says that pretty clearly. On March 19th, Aqua

said a threat actor used compromised credentials

to publish malicious releases of trivia. trivia

action and set up trivia and that this was a

follow -up from the march 1st incident because

the original containment was incomplete that

matters because now we are not just talking about

repo disruption or suspicious activity around

the project now we are talking about official

releases and ci tooling being turned into a distribution

path for credential theft aqua said affected

users should treat reachable secrets as compromised

and rotate them Multiple security write -ups

also called out that the compromised actions

and releases were used to target CICD environments

directly. This is the nightmare version of security

shifted left. The scanner is not outside the

blast radius. The security tool is not outside

the blast radius. The thing scanning your code

may need the same level of paranoia as the thing

deploying it. And I think that is why this one

is worth covering even though we already talked

about Trivi before. The first story was something

is wrong. The follow -on story is the earlier

compromise turned into malicious releases and

broader CI impact because the attacker still

had a path back in. That is new enough and ugly

enough to justify a follow -up. Kubernetes' ingress

to Gateway is the kind of migration story platform

teams actually live through. Now let's get back

to platform work. Kubernetes announced ingress

to Gateway 1 .0, and the framing is pretty direct.

With Ingress Engine X retired as of March 2026,

the question is not really whether teams will

move towards Gateway API, but how they do it

safely. That is why I like this story. Because

it is honest. A lot of migration stories get

told like they are basically just YAML translation

and maybe a few find and replaces. But anybody

who has lived through one of these knows the

hard part is not converting manifests. The hard

part is discovering all of the weird behavior

your current setup has been carrying for years

and deciding what actually needs to survive the

move. And Gateway API is a real shift. More modular.

More expressive. Better separation of concerns.

Great. But the migration still has to happen

in environments where teams have old annotations,

old controller -specific assumptions, and production

traffic that does not care how elegant the destination

architecture looks on a blog post. So I think

this is one of those very real platform stories

where the value is not the destination alone.

It is having a safer path off the thing everybody

relied on for years. Story five. Agent Sandbox

is Kubernetes admitting the workload model is

changing. Last main story. Kubernetes also published

a piece on Agent Sandbox. And I think it is worth

paying attention to. Not because everybody needs

it tomorrow, but because it signals where the

platform sees things going. The argument is basically

that long -running AI agents do not behave like

normal short -lived stateless workloads. They

need stable identity, workspace persistence,

isolation, scale to zero behavior, and warm pulls

so they do not feel painfully cold every time

they wake up. That feels right to me. Because

even if you are not all in on agent hype, the

platform problem is real. Once you have workloads

that hold context longer, need tool access, spin

up and down differently, and may need tighter

isolation than a normal web app, the old abstractions

start feeling a little off. And that is part

of why I like this story paired with S3 Files.

S3 Files says here's a friendlier interface for

data because these newer workflows want file

semantics. Agent Sandbox says here's a friendlier

runtime shape because these newer workloads want

different lifecycle semantics. Those are different

stories, but they rhyme. the platform is getting

nudged by new usage patterns, whether we want

to call that AI, agents, or just another round

of abstraction pressure. A few quick ones before

we wrap. Fortinet customers have an actively

exploited problem on their hands. Fortinet released

an emergency update for Fortinet EMS after CVE

-2026 35616. A critical flaw was exploited in

the wild, and CISA added it to the known exploited

vulnerabilities list on April 6th. Karpathy had

one of those posts making the rounds again that

taps into the bigger conversation around how

much software work is shifting from direct coding

towards orchestration, review, and steering.

I do not think the useful takeaway there is blind

hype. I think it is that a lot of engineers are

already feeling the interface to software work

changing, even if the results are still uneven.

And then there is Proofshot, which I actually

think is a pretty fun tool mention. It is an

open -sourced CLI that tries to give AI coding

agents eyes by recording browser sessions. capturing

screenshots, collecting console and server errors,

and bundling proof artifacts for humans to review

or attach to pull requests. If agents are going

to claim they built something, they should probably

bring receipts. I think the cleanest closer for

this one is this. The interface layer is becoming

the story. Not just the database. Not just the

bucket. Not just the cluster. And not just the

scanner. The layer in front of it. The workflow

around it. The migration path off of it. The

trust assumptions baked into it. This is where

a lot of the real action is now. S3 is still

S3. But the file system interface changes who

can use it and how. Until the second incident

shows it can turn into a broader distribution

path for secret theft if the first breach was

not fully closed. Ingress is still just ingress.

Until the controller everybody built around it

starts aging out and you realize how much invisible

behavior you were carrying the whole time. And

Kubernetes is still just Kubernetes, but even

it is starting to say out loud that newer workloads

may need different shapes, different assumptions,

and different guardrails. That's the human side

of this stuff. A lot of ops pain comes from realizing

too late that the helper layer was never really

a helper layer. It was part of the system, maybe

the important part. And the teams that do well

are usually the ones that figure that out before

the incident does. All right, that's it for this

week of Ship It Weekly. Quick recap. Amazon S3

files and why I think it is more managed file

layer over S3 than S3 is EFS now, especially

compared with the old S3FS and Fuse -style approach.

Malicious Strapi flavored NPM packages, the

trivia follow -on incident, and why it was worth

revisiting. Kubernetes ingress to gateway and

the bigger gateway API migration pressure and

agent sandbox as a look at where the platform

may be headed next. Links and show notes are

on shipitweekly .fm. You can also find the video

versions on YouTube. And if you want more signal

before the episode, check out on callbrief .com.

If this episode was useful, follow or subscribe

wherever you listen, and send it to the person

on your team who keeps having to explain that

the thing everybody calls just glue is usually

sitting directly on the blast radius. Thanks

for listening, and I'll see you next week.

Amazon S3 Files, Malicious npm Plugins, Trivy Fallout, and Kubernetes’ Gateway Shift

Watch this episode here

Chapters

Transcript

Catch This Episode

Host Commentary

Show Notes

More from Ship It Weekly

EKS Rollbacks, GitHub Actions Supply Chain Attacks, AI Agentjacking, CloudWatch Log Alarms, and Why Safety Nets Don’t Replace Ownership

containerd CRI Vulnerabilities, Datadog PostgreSQL HA on Kubernetes, AWS DevOps Agent with Datadog MCP Server, EKS Control Plane Egress, and Why Users Feel the Wait

Kiro CLI Approval Bypass, Amazon Braket Pickle Risk, AWS Org Logging, KEDA Upgrades, and Automation’s Hidden Boundaries

Ship It Conversations: Jake Warner on Cycle.io, Bare Metal’s Comeback, and Why Private Cloud Is Getting Interesting Again

Get the next episode in your inbox