This week's episode kept circling the same question from different directions:
Do you actually know what you're running?
Not what you think you're running. Not what the YAML says. Not what the dashboard says. What actually executed, what state the system is really in, and whether anyone on the team can explain it.
Start with GitHub Actions lockfiles.
For years, the normal way to use a third-party action has been to reference a tag. Readable. Easy to update. Everybody does it.
But a tag is a pointer, and pointers move.
If someone compromises an action's repository and moves the tag, your workflow picks up the new code the next time it runs. Nobody on your team changed anything. Your pull request was approved. Your review was real. And the code that actually ran was not the code anyone reviewed.
That's what lockfiles fix. The workflow YAML keeps the readable tag, and a separate actions.lock file records the exact commit, including transitive dependencies and reusable workflows. Actions runs that commit, not whatever the tag points to today.
It's easy to underrate because it's boring. I think it's one of the more important changes GitHub has made to Actions this year.
But here's the part I wouldn't skip:
A lockfile pins what you reviewed. It doesn't review it for you.
If you lock a compromised version, you've locked a compromised version. Lockfiles move the problem from "something changed underneath me" to "I need to be deliberate about what I accept." That's a better problem to have. It's still a problem.
The GitLab story is the same idea one layer down.
CVE-2026-97229 is a CVSS 10 integer overflow in how GitLab compiles regular expressions in CI/CD configuration. Under certain conditions, a crafted regex could let an unauthenticated attacker run code on the GitLab server.
Think about where that sits.
Your CI platform holds your source code, your pipeline definitions, your runners, your deploy credentials, and usually a pile of variables that are only as protected as the platform itself.
We spend a lot of energy securing what runs inside the pipeline. This is a reminder that the platform parsing the pipeline is part of the attack surface too.
If you self-manage GitLab, upgrade to 19.4.2, 19.3.5, or 19.2.8. GitLab.com is already patched, and Dedicated customers don't need to do anything.
Last week I said developer tooling is production infrastructure. This week reinforced it.
Google's Cloud Storage incident report is the one I keep thinking about.
Two incidents in us-central1, more than eighteen hours of impact across both. The first came from a traffic-sorting optimization in the load-balancing layer that bypassed capacity-aware routing, so writes piled onto a small set of lower-capacity nodes. And Google couldn't simply add emergency capacity, because of regional capacity limits.
Then the second incident: a recurrence caused by an incomplete rollback.
That's the part every on-call engineer should sit with.
We talk about rollback like it's a button.
It's not a button.
A rollback is a claim about state. It says: I put the system back the way it was. That claim is only as good as your understanding of everything the change touched.
If a change spans multiple components, feature flags, or a second feature that shipped alongside it, "rolled back" can quietly mean "rolled back the part I remembered."
So when you write a rollback plan, the question isn't just "how do I revert this?"
It's "how do I prove the revert worked?"
Then there's Linus.
Torvalds pushed an experimental branch of eight page-cache patches built with Claude Code, with roughly a 3x improvement on one cached small-read benchmark on his laptop. Not merged. Experimental.
What I find interesting isn't that Linus used an AI tool. Plenty of very good engineers do.
It's how it was framed. The tests, the review, and a first draft of the cover letter came from the tool, working under his direction. He ran the measurements himself.
He owns it.
At the same time, kernel maintainers are discussing dropping the mandatory Assisted-by commit tag and keeping the disclosure guidance in the cover letter instead. That revised patch hasn't landed.
Disclosure tags are useful. I don't want to dismiss them.
But a tag tells you a tool was involved. It doesn't tell you whether anyone understands the change.
That's the thread Paul LaPosta pulled on in the human closer.
His piece, "Your error budgets don't know AI exists," argues that AI has split shipping a change from understanding it. Understanding used to build up as a side effect of doing the work. Now you can ship working changes without it, so output can grow a lot faster than understanding.
He calls it comprehension debt.
The uncomfortable part is that our usual reliability signals won't catch it. The SLO holds. The rollback is fast. The dashboard says everything worked.
But ask the team why a change failed, and nobody can explain it. They can tell you what changed, when, and who approved it.
Not why.
His test is simple, and I like it a lot: talk to the owning team without the key engineer in the room. Can they explain the change and its risks?
And watch for the warning signs. Merge requests that keep getting reopened. Rollbacks that turn into debates.
That's where all four stories met for me this week.
A lockfile tells you what ran.
A patch tells you the parser is safe, today.
A rollback tells you what you think you undid.
A disclosure tag tells you AI was involved.
None of them tell you whether anyone understands the system.
That part is still our job.
Your SLO can tell you the service is up.
It cannot tell you whether anyone still understands it.
This week on Ship It Weekly, GitHub Actions workflow lockfiles land in public preview, pinning actions and their dependencies to exact commits. GitLab shipped a critical patch release for CVE-2026-97229, a CVSS 10 CI/CD regex flaw that could let an unauthenticated attacker run code on the server. Google published its final report on two Cloud Storage incidents in us-central1, including a recurrence caused by an incomplete rollback. And Linus Torvalds pushed an experimental kernel branch with page-cache patches built using Claude Code, as maintainers debate dropping the mandatory AI attribution tag.
The thread this week: know what you're actually running, from the commit you reviewed to the state a rollback really left behind and code someone can still explain.
In the lightning round: a record Patch Tuesday with more than 1,400 CVEs and an actively exploited Windows Shell bypass, GitHub AI Scan for pull requests and agentic autofix going GA, AWS Strands Box, an open-source agent sandbox that keeps real credentials out of the agent's environment, and a Microsoft 365 outage through Global Secure Access.
The human closer comes from Paul LaPosta's “Your error budgets don't know AI exists.” AI has split shipping a change from understanding it, and SLOs don't measure comprehension. Your SLO can tell you the service is up. It cannot tell you whether anyone still understands it.
Programming note: Ship It Weekly turns one next month, so expect more conversations over the next couple of months, usually two a week, starting Monday with Rob Koch.
Knowing What Actually Ran
This week's episode kept circling the same question from different directions:
Do you actually know what you're running?
Not what you think you're running. Not what the YAML says. Not what the dashboard says. What actually executed, what state the system is really in, and whether anyone on the team can explain it.
Start with GitHub Actions lockfiles.
For years, the normal way to use a third-party action has been to reference a tag. Readable. Easy to update. Everybody does it.
But a tag is a pointer, and pointers move.
If someone compromises an action's repository and moves the tag, your workflow picks up the new code the next time it runs. Nobody on your team changed anything. Your pull request was approved. Your review was real. And the code that actually ran was not the code anyone reviewed.
That's what lockfiles fix. The workflow YAML keeps the readable tag, and a separate actions.lock file records the exact commit, including transitive dependencies and reusable workflows. Actions runs that commit, not whatever the tag points to today.
It's easy to underrate because it's boring. I think it's one of the more important changes GitHub has made to Actions this year.
But here's the part I wouldn't skip:
A lockfile pins what you reviewed. It doesn't review it for you.
If you lock a compromised version, you've locked a compromised version. Lockfiles move the problem from "something changed underneath me" to "I need to be deliberate about what I accept." That's a better problem to have. It's still a problem.
The GitLab story is the same idea one layer down.
CVE-2026-97229 is a CVSS 10 integer overflow in how GitLab compiles regular expressions in CI/CD configuration. Under certain conditions, a crafted regex could let an unauthenticated attacker run code on the GitLab server.
Think about where that sits.
Your CI platform holds your source code, your pipeline definitions, your runners, your deploy credentials, and usually a pile of variables that are only as protected as the platform itself.
We spend a lot of energy securing what runs inside the pipeline. This is a reminder that the platform parsing the pipeline is part of the attack surface too.
If you self-manage GitLab, upgrade to 19.4.2, 19.3.5, or 19.2.8. GitLab.com is already patched, and Dedicated customers don't need to do anything.
Last week I said developer tooling is production infrastructure. This week reinforced it.
Google's Cloud Storage incident report is the one I keep thinking about.
Two incidents in us-central1, more than eighteen hours of impact across both. The first came from a traffic-sorting optimization in the load-balancing layer that bypassed capacity-aware routing, so writes piled onto a small set of lower-capacity nodes. And Google couldn't simply add emergency capacity, because of regional capacity limits.
Then the second incident: a recurrence caused by an incomplete rollback.
That's the part every on-call engineer should sit with.
We talk about rollback like it's a button.
It's not a button.
A rollback is a claim about state. It says: I put the system back the way it was. That claim is only as good as your understanding of everything the change touched.
If a change spans multiple components, feature flags, or a second feature that shipped alongside it, "rolled back" can quietly mean "rolled back the part I remembered."
So when you write a rollback plan, the question isn't just "how do I revert this?"
It's "how do I prove the revert worked?"
Then there's Linus.
Torvalds pushed an experimental branch of eight page-cache patches built with Claude Code, with roughly a 3x improvement on one cached small-read benchmark on his laptop. Not merged. Experimental.
What I find interesting isn't that Linus used an AI tool. Plenty of very good engineers do.
It's how it was framed. The tests, the review, and a first draft of the cover letter came from the tool, working under his direction. He ran the measurements himself.
He owns it.
At the same time, kernel maintainers are discussing dropping the mandatory Assisted-by commit tag and keeping the disclosure guidance in the cover letter instead. That revised patch hasn't landed.
Disclosure tags are useful. I don't want to dismiss them.
But a tag tells you a tool was involved. It doesn't tell you whether anyone understands the change.
That's the thread Paul LaPosta pulled on in the human closer.
His piece, "Your error budgets don't know AI exists," argues that AI has split shipping a change from understanding it. Understanding used to build up as a side effect of doing the work. Now you can ship working changes without it, so output can grow a lot faster than understanding.
He calls it comprehension debt.
The uncomfortable part is that our usual reliability signals won't catch it. The SLO holds. The rollback is fast. The dashboard says everything worked.
But ask the team why a change failed, and nobody can explain it. They can tell you what changed, when, and who approved it.
Not why.
His test is simple, and I like it a lot: talk to the owning team without the key engineer in the room. Can they explain the change and its risks?
And watch for the warning signs. Merge requests that keep getting reopened. Rollbacks that turn into debates.
That's where all four stories met for me this week.
A lockfile tells you what ran.
A patch tells you the parser is safe, today.
A rollback tells you what you think you undid.
A disclosure tag tells you AI was involved.
None of them tell you whether anyone understands the system.
That part is still our job.
Your SLO can tell you the service is up.
It cannot tell you whether anyone still understands it.
Additional Links
GitHub Actions workflow lockfiles:
https://github.blog/changelog/2026-10-14-github-actions-workflow-lockfiles-in-public-preview/
GitLab patch release 19.4.2 / 19.3.5 / 19.2.8:
https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-4-2-released/
Google Cloud Storage incident report:
https://status.cloud.google.com/incidents/mSFVt6PiP557bjRyYsut
Linus Torvalds and Claude Code (Phoronix):
https://phoronix.com/news/Linus-Torvalds-Claude-Code
Linux drops the Assisted-by requirement (Phoronix):
https://phoronix.com/news/Linux-Dropping-Assisted-By-Req
Your error budgets don't know AI exists (LeadDev):
https://leaddev.com/?p=36182
This week's On Call Brief:
https://www.tellerstech.com/on-call-brief-news/2026-W42/