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.