PeopleSoft gets hit by a zero-day. npm changes
what code is allowed to run during install. GitHub
removes long-lived personal access tokens from
agentic workflows. And Anthropic reminds everyone
that your AI dependency can disappear for reasons
that have nothing to do with uptime. The theme
this week is simple. Default trust is getting
punished. Old enterprise systems were trusted.
because they were internal. Package installs
were trusted because that is just how the ecosystem
worked. CI/CD tokens were trusted because they
were convenient. AI models were trusted because
the API worked yesterday. But production does
not care why you trusted something. It only cares
what that trust was allowed to do. I'm Brian
Teller from Teller's Tech, and this is Ship It
Weekly. Welcome back to Ship It Weekly, the show
where we look at the DevOps, SRE, cloud, platform,
and security stories that actually matter when
you are the person who eventually has to keep
the thing running. This week is about default
trust. We're starting with Oracle PeopleSoft
and a zero-day that was reportedly exploited
before Oracle released an emergency patch. Then
we'll talk npm v12. changing install-script
defaults which is great for supply-chain security
and maybe a little annoying for some CI pipelines
after that we'll get into github agentic workflows
no longer needing personal access tokens which
is the kind of boring credential change that
actually matters then we'll talk about Anthropic
disabling fable 5 and mythos 5 after a us export
control directive because AI model availability
is now also a policy-risk dependency. In the
lightning round, we'll hit Tekton CloudEvents
moving to a dedicated events controller, NVIDIA
Triton 26.04 changing inference server defaults,
AWS Nitro Isolation Engine using formal verification,
and Homebrew 6.0 requiring explicit trust for
third-party taps. The human closer this week
is about trust defaults, because a lot of incidents
start with one quiet assumption. The system is
internal. The package is fine. This token is
safe. This model will be there tomorrow. And
sometimes that assumption is the real production
dependency. So let's get into it. Oracle issued
an emergency advisory for CVE-2026-35273 in
PeopleSoft PeopleTools. And yes, I know, PeopleSoft
does not sound like the kind of shiny cloud-native
story that makes people sprint to the podcast
app. But that is exactly why it matters. A lot
of modern companies still depend on older enterprise
systems for HR, finance, payroll, student records,
supply-chain. and all the boring data that becomes
extremely exciting when attackers get it. Oracle
says that the vulnerability is remotely exploitable
without authentication and can result in remote
code execution. Public reporting says exploitation
was observed before Oracle's emergency advisory,
with ShinyHunters linked activity targeting
mostly U.S. organizations, especially higher
education. So the shape of the story is pretty
clear. Old enterprise application, sensitive
data, remote unauthenticated exploit, active
exploitation, emergency patch. That is a bad
combination. And the lesson for DevOps, SRE,
platform, and cloud teams is not just patch PeopleSoft.
Although, yes, obviously, patch PeopleSoft. The
bigger lesson... is that the enterprise app tier
is still part of your perimeter, even if everyone
emotionally moved on to Kubernetes. A lot of
teams have a weird relationship with older enterprise
platforms. They are important enough that nobody
can turn them off, but old enough that nobody
really wants to own them. They live in a special
network zone. They have a special upgrade window.
They have special vendor requirements. They have
special firewall rules. from 2017 that everyone
is afraid to touch. And somehow, because they
are enterprise apps, people stop thinking of
them like internet-exposed production systems.
Attackers do not care what generation of architecture
the system belongs to. They care whether it has
data, access, and a path in. PeopleSoft may not
be the cool part of your stack, but if it holds
HR data, finance data, student data, employee
data, or business workflow data, it is very much
part of your attack surface. This is also a good
reminder that legacy does not mean low-priority.
Sometimes legacy means high-value, hard-to-patch,
badly isolated, and full of data. That is not
low-priority. That is where an attacker brings
a shovel. The practical takeaway is simple. Know
where these systems are. Know whether they are
internet exposed. Know who owns patching. Know
who owns logs. Know what normal access looks
like. Know whether unusual agents, web shells,
or scheduled tasks would actually be noticed.
And if you are a platform or cloud team that
thinks this is someone else's problem, be careful.
Because during the incident call, someone else's
problem has a funny way of becoming why did nobody
know this existed. Your ERP systems, HR systems,
finance systems, and admin portals are production
systems. Treat them that way. Second story. npm
v12 is changing some defaults around install
scripts. And this one matters to developers,
platform teams, CI maintainers, security teams,
and anyone who has ever watched an npm install
do 12 things they did not explicitly ask it to
do. GitHub says npm v12 is expected in
July 2026. And one of the big breaking changes
is that allowScripts will default to off. That
means npm install will no longer execute pre
-install, install, or postinstall-scripts from
dependencies unless they are explicitly allowed.
Prepare scripts from git, file, and link dependencies
are blocked the same way. These settings are
already available in npm 11.16.0 for migration
testing. This is a big ecosystem shift. For years,
npm install has been more powerful than people
like to admit. You run the package install. The
package runs code. That code might build native
bindings, download binaries, generate files.
patch something, bootstrap something, do the
magic that makes everything work. But that same
install-time execution path is also a supply
chain attack surface. A malicious package does
not need your app to import it at runtime if
it can run code during install. It only needs
to land in the dependency tree. Then the CI runner,
developer laptop, or build machine does the rest.
This is why this change matters. It moves the
ecosystem from implicit trust towards explicit
trust. And yes, that is good. But some builds
are going to break. Because a lot of pipelines
have been relying on install-time magic without
documenting it. Native modules. Post install
downloads. Git dependencies. File dependencies.
Link dependencies. Internal packages. Packages
that compile. Packages that generate code. Packages
that do one tiny little install step that nobody
has looked at since the person who wrote it left
the company. Those assumptions are about to become
visible. And visibility is great. Right after
it ruins your Tuesday. The practical takeaway
is not panic about npm v12. The takeaway
is to test early. Run builds with the new behavior
before it becomes the default. Find which dependencies
need scripts. Decide which scripts you actually
trust. Document why. And do not just flip everything
back on because one pipeline failed. That defeats
the point. This is a chance to clean up dependency
trust, especially in CI. Ask what install-scripts
run today. Ask whether CI runners have secrets
available during install. Ask whether build steps
can reach internal services. Ask whether developers
are running installs on machines with cloud credentials,
SSH keys, or package publishing rights. Because
the blast radius of an install-script is not
just the package. It is whatever the install
environment can access. I like this change. It
is going to annoy people, but sometimes the annoying
default is the correct default. npm install is
finally getting less magical. And that means
that some teams are about to discover how much
magic they were depending on. Third story. GitHub
says agentic workflows no longer need a personal
access token. And yes, that sounds boring. But
boring credential changes are often the ones
that save you later. Previously, agentic workflows
needed personal access tokens in certain setups.
Now GitHub says, These workflows can use the
built-in GITHUB_TOKEN and the copilot
request write permission instead. The point is
to avoid creating and storing long-lived personal
access tokens for agentic workflows. This matters
because agentic CI/CD is already risky enough.
These workflows can read context, generate changes,
open pull requests, review code, call tools,
interact with repo state, and eventually, in
some environments, they may become part of release,
remediation, triage, or automation paths. So
the credentials they use matter a lot. A personal
access token is often tied to a person. It may
be long-lived. It may have broad permissions.
It may sit in secrets. It may get copied between
repos. It may survive longer than anyone intended.
It may still exist after the workflow changed,
the person changed teams, or everyone forgot.
why the token was created. That is not a great
pattern for agentic automation. A scoped workflow
token is not magic. You still have to configure
it correctly. You still have to review permissions.
You still have to think about which events can
trigger the workflow. You still have to worry
about untrusted input. But it is a better default
than handing an agent a long-lived personal
credential and hoping everyone remembers where
it lives. The platform takeaway is simple. If
you are experimenting with agentic workflows
in GitHub, review the whole trust model. What
repos can run it? What events can trigger them?
What permissions do they get? Can pull request
content influence the agent? Can issue comments
influence the agent? Can the agent write code?
Can it approve changes? Can it call external
tools? Can it see secrets? Can it publish artifacts?
Can it affect production? And are you still using
personal access tokens where you do not need
them? Because agents are not just assistants
once they enter CI/CD. They become automation
services. And automation surfaces need boring,
strict, reviewable credentials. So yes, use the
better GitHub auth model. But do not stop there.
If it can change code, trigger work, or spend
money, it belongs in your production automation
threat model. Fourth story. Anthropic published
a statement saying that the U.S. government
issued an export-control directive requiring
Anthropic to suspend access to Fable 5 and Mythos
5 by any foreign national, whether inside or
outside the United States, including foreign
national Anthropic employees. Anthropic said
that the net effect was that it had to abruptly
disable Fable 5 and Mythos 5 for all customers.
to ensure compliance. Access to other Anthropic
models was not affected. Now, this is not a normal
SRE outage. There was not a regional failure.
There was not a bad deploy. There was not a database
incident. There was not a capacity problem. But
for customers who depend on those models, the
effect is still operational. The dependency disappeared.
and it disappeared for policy reasons. That is
the lesson. If AI APIs are part of your production
path, dependency risk is no longer just uptime,
latency, quota, and cost. It is also model availability,
geography, export-controls, regulatory shifts,
vendor policy, safety policy, commercial access,
model deprecation, compliance interpretation,
and whatever new category we invent next quarter.
This is uncomfortable because AI dependencies
can be harder to substitute than people pretend.
You can usually swap one HTTP endpoint for another
at a code level. But can you swap the behavior,
the context window, the latency, the tool calling
behavior, the moderation behavior, the cost profile,
the prompt format, the eval results, the customer
experience, the internal workflow? The fallback
may not be use a different model. The fallback
may be a degraded mode, a smaller model, a cached
response, a human review queue, a simpler workflow,
a feature flag, a regional restriction, or a
message that says this capability is temporarily
unavailable. Boring fallback behavior is better
than waking up to discover your product path
depends on a model that is no longer available
to you. The practical takeaway is to add AI models
to your dependency register like any other production
dependency. Track which features use which model.
Track whether the model is in a critical path.
Track where your users are. Track fallback options.
Track whether you can degrade gracefully. Track
whether a vendor-side access change would be
an incident. And test the fallback. Do not just
write... Fall back to another model in a doc
and call it done. Actually try it. Because the
weird thing about AI infrastructure is that even
when the API shape looks portable, the behavior
is not. Your AI dependency can disappear for
reasons that have nothing to do with uptime.
That means your reliability plan needs to cover
more than outages. Now let's do a quick lightning
round. First, Tekton pipelines changed how cloud
events are sent. Cloud events for PipelineRuns
and TaskRuns now move through a dedicated Tekton
events controller instead of the core pipeline
run and task run controllers. That means operators
need to make sure the tekton-events-controller
deployment is actually running. Small looking
platform changes like this can have real operational
impact. If CI/CD observability, event routing,
notifications, or automation depends on Tekton
events, make sure the new controller is deployed,
monitored, and part of the upgrade checklist.
Because the pipeline ran, but the event never
showed up, is exactly the kind of thing that
sends teams into Slack archaeology. Second, NVIDIA
Triton Inference Server 26.04 has changes operators
should read before upgrading. Client shared memory
is now disabled by default and must be enabled
explicitly if you rely on the old behavior. Triton
also enforces max inflight requests as a shared
limit across ensemble requests, which is meant
to prevent unbounded queue growth in ensemble
pipelines. The short version is this. AI inference
servers are now normal platform infrastructure.
Defaults change. queue behavior changes, memory
behavior changes, model control changes. So upgrade
them like production systems, not sidecar experiments.
Third, AWS published a deep dive on the Nitro
Isolation Engine. AWS says the Nitro Isolation
Engine is generally available on Graviton5-based
instances and uses formal verification to demonstrate
isolation properties. That is interesting because
cloud isolation is usually something customers
trust, but cannot directly inspect. Formal verification
does not mean bugs are impossible, but it does
show where cloud providers are heading. Smaller
trusted components, tighter isolation boundaries,
and mathematically checked properties for the
parts that protect customer workloads. Fourth,
Homebrew 6.0 introduced tap trust. Homebrew
now requires explicit trust. for third-party
taps before evaluating or running their Ruby
code, while official taps remain trusted by default.
This is another supply-chain default, changing
from sure, run it, to are you sure you trust
this? And that is good. A third-party tap can
contain arbitrary Ruby. If your developer laptops,
CI runners, or bootstrap scripts use Homebrew,
This change is worth knowing about. Some installs
may prompt or fail until trust is explicit. That
might annoy people. But again, that is the point.
Developer tooling is part of the supply-chain.
And fewer things should get to run code just
because they were convenient. The human closer
this week is about default trust. PeopleSoft
was trusted because it was an enterprise system
that had been around forever. npm install was
trusted because package managers have always
done some magic. agentic workflows were trusted
with personal tokens because that was the easy
path. AI models were trusted because the API
was available yesterday. Tekton events were trusted
to keep flowing. Triton defaults were trusted
until they changed. Cloud isolation was trusted
because that is the cloud model. Homebrew taps
were trusted because developer tooling has historically
been pretty casual about running code. Different
stories, same pattern. Production risk often
hides inside the trust defaults nobody has revisited.
The system is internal. The install-script is
normal. The token is convenient. The model will
be available. the event will fire the tap is
probably fine those assumptions may be true until
they are not so the practical question this week
is simple what are you trusting by default which
enterprise apps are still exposed which package
installs run code in ci which agents still use
long-lived tokens which ai models sit in production
paths which developer tools can execute code
before anyone reviews it that is platform work
now not just building the shiny new thing but
revisiting the old trust assumptions before attackers
vendors regulators or outages revisit them for
you find the defaults then decide whether they
still deserve your trust That's it for this week
of Ship It Weekly. We covered the Oracle PeopleSoft
zero-day, npm v12 install-script changes,
GitHub agentic workflows moving away from personal
access tokens, Anthropic's Fable and Mythos model
suspension, and a lightning round on Tekton,
NVIDIA Triton, AWS Nitro Isolation Engine, and
Homebrew 6.0 tap trust. If this episode was
useful, follow or subscribe wherever you are
watching or listening. If you are on YouTube,
hit subscribe. If you're in a podcast app, follow
the show there. And if you know someone dealing
with enterprise app security, CI/CD supply-chain
risk, agentic workflows, AI dependency planning,
or developer tool trust, send this one to them.
It helps the show grow, and it helps me keep
making this kind of content for people who actually
live with these systems. You can find the weekly
brief at OnCallBrief.com, and more episodes
and show notes at shipitweekly.fm. I'm Brian
Teller from Teller's Tech. Thanks for listening.
And remember, production does not care why you
trusted the default. It only cares what that
default was allowed to do.