GitHub API Enumeration, Grok Build CLI Data Exposure, AWS Security Hub Network Scanning, AI-Powered Patch Pressure, and Why Visibility Is Not Ownership

Transcript

This week, Datadog is tracking coordinated GitHub

API enumeration using ghost accounts, leaked

tokens, and normal-looking API traffic, which

is a reminder that public metadata can still

become operational intelligence. xAI's Grok Build

CLI reportedly transmitted repository data without

redaction. So the AI coding tool question is

not just, does it help me build faster? It

is, what did it read? And where did that data

go? AWS Security Hub added Network Scanning and

exposure impact analysis, which gets cloud security

closer to the attacker's view. What is actually

reachable? And what can that reachable thing

access next? And Microsoft says AI-powered vulnerability

discovery is changing patch management. More

bugs found faster means more pressure on the

teams that have to test, deploy, and recover

from patches. Put those together, and the theme

this week is exposure. Who can map your systems?

Who can read your code? Who can reach your infrastructure?

And who owns the response when the map gets too

accurate? I'm Brian Teller from Teller's Tech,

and this is Ship It Weekly. Welcome back to Ship

It Weekly, the show about the DevOps, SRE, cloud,

platform, and security stories that actually

matter when you are the person who has to keep

the thing running at 3am. If you are new here,

follow or subscribe wherever you are watching

or listening. And if you want the weekly story

list and source links, check out OnCallBrief

.com. For past episodes, full show notes, and

more from the show, head over to ShipItWeekly

.fm. This week, we start with GitHub API enumeration

because attackers do not always need an exploit

to build a useful map of your organization. Then

we get into Grok Build CLI and the data boundary

around AI coding tools. After that, AWS Security

Hub Network Scanning and impact analysis. Then

Microsoft's warning that AI-powered vulnerability

discovery may mean more patches, faster timelines,

and less room for slow change management. In

the lightning round, HalluSquatting, Cloudflare

control plane incidents, node-tar CVEs, ServiceNow

authentication risk, quantum procurement pressure,

and Lambda Managed Instances for Java cold starts.

And we close with something from SRE Weekly about

post-incident reviews, authority gaps, and the

difference between documenting an incident and

actually learning from it. Let's get into it.

First up, Datadog Security Research published

a write-up on coordinated GitHub API enumeration

and access token abuse. This one matters because

it is not a flashy exploit story. No zero day,

no dramatic breach chain, just API traffic. Datadog

is tracking campaigns that use GitHub's API to

enumerate organizations, repositories, users,

members, followers, public repos, private repo

paths. and related metadata. Some of that data

is public by design. That is the uncomfortable

part. Public repos, org details, user profiles,

REST endpoints, GraphQL queries, relationships

between people and projects. Individually, those

answers may look harmless. At scale, they become

a map. Who works at the company? What naming

patterns exist? Which internal project names

leak into public references? Which private repo

paths might exist? Which users are worth targeting?

Recon is not harmless just because the data is

public. Datadog also called out ghost accounts.

Older GitHub accounts created years ago, left

dormant, and later used for API traffic across

many organizations. An old account blends better

than one created yesterday. Then add compromised

OAuth tokens or personal access tokens, and enumeration

can turn into access. Now, the actor may be probing

private repo paths, listing repos, checking commit

history, or cloning code. The takeaway is simple.

Treat GitHub like a production surface, not just

source control. Watch Token Scopes. OAuth apps,

old PATs, dormant users, outside collaborators,

audit logs, GraphQL usage, private repo path

probes, and sudden bursts of API activity. GitHub

holds the instructions for how your company builds

and ships software. Attackers know that. Your

GitHub org is part of your attack surface. Second

story. On Call Brief flagged reports that xAI's

Grok Build CLI transmitted repository data and

file contents without redaction. The details

around one tool may change. The bigger lesson

does not. If an AI coding tool reads your repo,

that is access. If it reads your dot env file, Terraform,

Helm charts, Kubernetes manifests, runbooks,

incident notes, or internal docs, that is access.

And if it sends that context to a cloud service,

that is data movement. That means security, legal,

compliance, and platform teams need to know about

it. We spent years building controls around source

code, private repos, SSO, branch protections,

secret scanning, vendor reviews, access reviews,

least privilege. Then an AI coding tool shows

up and says, I can help you build this app. Cool.

But what can it read? Where does the data go?

Is it retained? Is it used for training? Does

it respect ignored files? Does it read Git history?

Does it upload the whole repo or selected context?

Can the organization audit usage? Those are not

boring procurement questions. Those are production

security questions. Repos are not just code.

They contain architecture, service names, build

pipelines, IAM assumptions, deploy rules, vulnerability

hints, and sometimes secrets. The lesson is not

never use AI coding tools. That ship has sailed.

The lesson is to stop treating them like harmless

editor plugins. They are repo readers. Sometimes

they are command runners. Sometimes... They are

package installers. Sometimes they are cloud

-connected agents sitting next to your source

code and local environments. So they need policy,

review, and boundaries around where they can

be used. Because it was just on my laptop is

not a data boundary. Quick break from the news.

The Ship It Weekly shop is officially open at

shop.tellerstech.com. I've got a few Ship It

Weekly t-shirt designs up there now. And I spent

way too much time sourcing the actual shirts

because I wanted them to feel like good trade

show shirts people actually keep. Think of those

soft Datadog style shirts that you get at conferences

and somehow still wear two years later. That

was the target. I'm wearing one of those now

so you can get a feel for it on video. If you

want to support the show and rep the merch a

little bit, head over to shop.tellerstech.com.

For the next few weeks, coupon code SHIPTHESTORE

gets you 20% off your order. That is SHIPTHESTORE.

Again, shop.tellerstech.com. All right, back

to it. Third story. AWS Security Hub added network

scanning and impact analysis for exposure findings.

The short version. Cloud security is moving from

this might be exposed based on configuration

to we checked from the outside, this is actually

reachable, and here is what that exposure could

lead to. That is useful. Network scanning probes

resources from the internet to identify actual

reachability, not just what the route tables,

security groups, and diagrams suggest. Actual

reachability. Public IPs. Virtual machines. Load

balancers. Reachable ports. Services behind them.

That matters because cloud reality drifts. A

public IP gets attached during troubleshooting.

A port gets opened and forgotten. A test load

balancer lives forever. A Kubernetes service

becomes public because someone copied a helm

value from dev. Config analysis is helpful, but

active scanning gets closer to the attacker's

view. Can I reach it? What port is open? What

service is there? What evidence proves it? Then,

impact analysis adds the blast radius side. AWS

says Security Hub can map downstream resources

that could be compromised beyond the initial

exposed resource. That matters because exposure

alone is not the whole story. An exposed test

box with no useful permissions is one kind of

risk. An exposed instance with a role that can

read production secrets, write to S3, or reach

a database is a very different risk. So do not

only prioritize by severity label. Prioritize

by reachability and blast radius. Public and

reachable matters. Public and reachable with

dangerous IAM matters more. And when something

is exposed, do not stop at closing the port.

Ask who owns it, how long it was exposed, what

it could access, what logs prove activity, and

what prevents it from coming back. The tool finding

the exposure is only step one. Someone still

has to own the cleanup. Fourth story. Microsoft

published a post about evolving Windows vulnerability

management. for AI-powered discovery. And even

if you are not managing Windows endpoints, the

larger trend matters. AI is not just helping

people write code faster. It is helping defenders

find bugs faster. It is helping researchers analyze

code faster. And eventually, attackers get better

at this too. Microsoft talked about using an

agentic scanning harness called MDASH. to analyze

Windows at scale with multiple models, validation,

human review, and then high confidence findings

going to engineers. The operator takeaway is

that faster discovery means more update pressure.

A lot of companies still treat patching like

a monthly chore. Patch Tuesday happens. Vulnerability

teams triage. Endpoint teams test. App owners

delay. Exceptions pile up. Someone asks if it

can wait until the next window. That rhythm already

struggles. AI-accelerated discovery makes the

tempo worse. More findings. Faster analysis.

Shorter response windows. More pressure to know

what is actually affected. This does not mean

patch everything instantly and hope. Patching

is still production change. Patches break things.

Agents break things. Middleware breaks things.

Security fixes can have side effects, but patching

needs to look more like a real operational system.

Known inventory, staged rollout, rollback, ownership,

emergency paths, and coverage reporting, not

spreadsheet theater. If your patch process depends

on 10 people manually asking app owners how they

feel, AI is going to make that pain worse. Security

updates are becoming production operations, so

they need production-grade process around them.

Quick lightning round. First, HalluSquatting.

AI coding agents can hallucinate package or repo

names, and attackers can squat those names ahead

of time. If the agent tries to install the fake

dependency, it can pull malicious code. Do not

let agents install packages just because the

name sounds plausible. Second, Cloudflare had

dashboard and API incidents. The edge may keep

serving traffic, but if the dashboard or API

is down, incident response can still be impaired.

Data plane and control plane are different things.

Both matter. Third, node-tar had a cluster of

denial of service issues. Archive parsing sits

in package managers, build systems, CI jobs,

artifact handling, upload pipelines, and scanners.

If you accept archives from untrusted sources,

tar parsing bugs matter. Fourth, ServiceNow had

a requires authentication equals false issue.

One unauthenticated REST endpoint in a platform

that holds tickets. assets, workflows, and incident

context can become an enterprise data exposure

problem fast. Fifth, France is pushing quantum

risk into procurement language. That is how post

-quantum migration becomes real. Procurement,

compliance, vendor questionnaires, and data retention

expectation. And last, AWS wrote about Lambda

-managed instances for Java cold starts. Serverless

keeps getting features that look more like managed

capacity under the hood. That is not bad, but

the abstraction is not magic. Cold starts, warm

capacity, runtime behavior, and cost still matter.

The human closer this week comes from SRE Weekly.

Issue 525 had a few pieces around post-incident

reviews, human-in-the-loop authority gaps,

and whether teams confuse collecting artifacts

with actually learning. That fits this episode,

because this whole week is about maps and exposure.

Datadog is talking about attackers mapping GitHub

organizations. Grok Build raises the question

of what AI coding tools read. Security Hub is

mapping what is reachable from the internet.

Microsoft is talking about AI finding vulnerabilities

faster. Maps are useful, but maps do not fix

anything by themselves. An exposure finding does

not close the port. An API log does not revoke

the token. A patch bulletin does not patch the

fleet. A postmortem timeline does not create

learning. A human approval step does not guarantee

judgment if the human has no context. That last

one matters. Human in the loop sounds safe. But

if the human is pulled in at the worst moment

with the least context under the most pressure,

the approval step can become theater. Same with

post-incident reviews. A meeting is not learning.

A timeline is not learning. A document in the

wiki is not learning those things can help but

the learning happens when the system changes

when ownership becomes clear when the runbook

improves when alert noise goes down when the

risky default gets removed when the next operator

is less dependent on luck so the question is

not just did we review the incident the question

is what changed because of it visibility is not

ownership. A map is not a fix. That's it for

this week of Ship It Weekly. We covered GitHub

API enumeration, Grok Build CLI, and AI coding

tool data boundaries, AWS Security Hub network

scanning, and impact analysis. Microsoft's AI

-powered vulnerability discovery and patch cadence,

plus HalluSquatting, Cloudflare incidents,

node-tar CVEs, ServiceNow authentication risk,

Quantum Procurement Pressure, and Lambda Managed

Instances. If this episode was useful, follow

or subscribe wherever you are watching or listening.

If you know someone dealing with GitHub org security,

AI coding tools, cloud exposure, or patch pressure,

send them this one. Also, the Ship It Weekly shop

is open at shop.tellerstech.com. Use coupon

code SHIPTHESTORE for 20% off your order for

the next few weeks. Again, SHIPTHESTORE at

shop.tellerstech.com. You can find the weekly brief

at OnCallBrief.com and the full show notes,

links, and past episodes at ShipItWeekly.fm.

I'm Brian Teller from Teller's Tech. Thanks for

listening. And remember, visibility is not ownership.

A map... is not a fix.

GitHub API Enumeration, Grok Build CLI Data Exposure, AWS Security Hub Network Scanning, AI-Powered Patch Pressure, and Why Visibility Is Not Ownership

Watch this episode here

Chapters

Transcript

Catch This Episode

Show Notes

More from Ship It Weekly

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

CISA’s GitHub Leak, AI Root Cause Analysis, Copilot Agents, Claude Code in CI/CD, and Kubernetes Seccomp Risk

Cursor Deletes PocketOS Prod DB, .de DNSSEC Outage, Bluesky Postmortem, Argo CD, and Copy Fail

Ship It Conversations: Gareth Kersey on IaCConf 2026, AI, and Corey Quinn’s Terraform Keynote

Get the next episode in your inbox

GitHub API Enumeration, Grok Build CLI Data Exposure, AWS Security Hub Network Scanning, AI-Powered Patch Pressure, and Why Visibility Is Not Ownership

Chapters

Transcript

Catch This Episode

Show Notes

Related On Call Brief

More from Ship It Weekly

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

CISA’s GitHub Leak, AI Root Cause Analysis, Copilot Agents, Claude Code in CI/CD, and Kubernetes Seccomp Risk

Cursor Deletes PocketOS Prod DB, .de DNSSEC Outage, Bluesky Postmortem, Argo CD, and Copy Fail

Ship It Conversations: Gareth Kersey on IaCConf 2026, AI, and Corey Quinn’s Terraform Keynote

Get the next episode in your inbox