WEBVTT

00:00:00.000 --> 00:00:03.259
This week, Datadog is tracking coordinated
GitHub

00:00:03.259 --> 00:00:06.820
API enumeration using ghost accounts, leaked

00:00:06.820 --> 00:00:10.699
tokens, and normal-looking API traffic, which

00:00:10.699 --> 00:00:13.980
is a reminder that public metadata can still

00:00:13.980 --> 00:00:17.719
become operational intelligence. xAI's Grok
Build

00:00:17.719 --> 00:00:22.000
CLI reportedly transmitted repository data
without

00:00:22.000 --> 00:00:25.940
redaction. So the AI coding tool question is

00:00:25.940 --> 00:00:28.760
not just, does it help me build faster? It

00:00:28.760 --> 00:00:31.899
is, what did it read? And where did that data

00:00:31.899 --> 00:00:35.840
go? AWS Security Hub added Network Scanning and

00:00:35.840 --> 00:00:39.679
exposure impact analysis, which gets cloud
security

00:00:39.679 --> 00:00:43.840
closer to the attacker's view. What is actually

00:00:43.840 --> 00:00:46.740
reachable? And what can that reachable thing

00:00:46.740 --> 00:00:51.159
access next? And Microsoft says AI-powered
vulnerability

00:00:51.159 --> 00:00:54.880
discovery is changing patch management. More

00:00:54.880 --> 00:00:58.219
bugs found faster means more pressure on the

00:00:58.219 --> 00:01:01.679
teams that have to test, deploy, and recover

00:01:01.679 --> 00:01:04.900
from patches. Put those together, and the theme

00:01:04.900 --> 00:01:08.180
this week is exposure. Who can map your systems?

00:01:08.420 --> 00:01:12.219
Who can read your code? Who can reach your
infrastructure?

00:01:12.560 --> 00:01:15.700
And who owns the response when the map gets too

00:01:15.700 --> 00:01:18.579
accurate? I'm Brian Teller from Teller's Tech,

00:01:18.719 --> 00:01:38.420
and this is Ship It Weekly. Welcome back to Ship

00:01:38.420 --> 00:01:41.840
It Weekly, the show about the DevOps, SRE,
cloud,

00:01:42.060 --> 00:01:44.780
platform, and security stories that actually

00:01:44.780 --> 00:01:47.000
matter when you are the person who has to keep

00:01:47.000 --> 00:01:49.840
the thing running at 3am. If you are new here,

00:01:49.959 --> 00:01:52.180
follow or subscribe wherever you are watching

00:01:52.180 --> 00:01:54.859
or listening. And if you want the weekly story

00:01:54.859 --> 00:01:57.939
list and source links, check out OnCallBrief

00:01:57.939 --> 00:02:01.680
.com. For past episodes, full show notes, and

00:02:01.680 --> 00:02:04.519
more from the show, head over to ShipItWeekly

00:02:04.519 --> 00:02:08.580
.fm. This week, we start with GitHub API
enumeration

00:02:08.580 --> 00:02:11.939
because attackers do not always need an exploit

00:02:11.939 --> 00:02:16.120
to build a useful map of your organization. Then

00:02:16.120 --> 00:02:19.919
we get into Grok Build CLI and the data boundary

00:02:19.919 --> 00:02:23.699
around AI coding tools. After that, AWS Security

00:02:23.699 --> 00:02:27.580
Hub Network Scanning and impact analysis. Then

00:02:27.580 --> 00:02:30.780
Microsoft's warning that AI-powered
vulnerability

00:02:30.780 --> 00:02:34.979
discovery may mean more patches, faster
timelines,

00:02:35.340 --> 00:02:38.780
and less room for slow change management. In

00:02:38.780 --> 00:02:41.639
the lightning round, HalluSquatting, Cloudflare

00:02:41.639 --> 00:02:46.379
control plane incidents, node-tar CVEs,
ServiceNow

00:02:46.379 --> 00:02:49.650
authentication risk, quantum procurement
pressure,

00:02:49.909 --> 00:02:53.729
and Lambda Managed Instances for Java cold
starts.

00:02:54.009 --> 00:02:57.889
And we close with something from SRE Weekly
about

00:02:57.889 --> 00:03:01.550
post-incident reviews, authority gaps, and the

00:03:01.550 --> 00:03:04.310
difference between documenting an incident and

00:03:04.310 --> 00:03:07.009
actually learning from it. Let's get into it.

00:03:11.830 --> 00:03:15.139
First up, Datadog Security Research published

00:03:15.139 --> 00:03:18.479
a write-up on coordinated GitHub API enumeration

00:03:18.479 --> 00:03:22.180
and access token abuse. This one matters because

00:03:22.180 --> 00:03:26.120
it is not a flashy exploit story. No zero day,

00:03:26.240 --> 00:03:31.039
no dramatic breach chain, just API traffic.
Datadog

00:03:31.039 --> 00:03:35.259
is tracking campaigns that use GitHub's API to

00:03:35.259 --> 00:03:38.539
enumerate organizations, repositories, users,

00:03:39.000 --> 00:03:43.060
members, followers, public repos, private repo

00:03:43.060 --> 00:03:46.879
paths. and related metadata. Some of that data

00:03:46.879 --> 00:03:49.819
is public by design. That is the uncomfortable

00:03:49.819 --> 00:03:54.199
part. Public repos, org details, user profiles,

00:03:54.780 --> 00:03:58.539
REST endpoints, GraphQL queries, relationships

00:03:58.539 --> 00:04:02.259
between people and projects. Individually, those

00:04:02.259 --> 00:04:06.379
answers may look harmless. At scale, they become

00:04:06.379 --> 00:04:10.180
a map. Who works at the company? What naming

00:04:10.180 --> 00:04:13.669
patterns exist? Which internal project names

00:04:13.669 --> 00:04:17.329
leak into public references? Which private repo

00:04:17.329 --> 00:04:21.550
paths might exist? Which users are worth
targeting?

00:04:21.750 --> 00:04:25.029
Recon is not harmless just because the data is

00:04:25.029 --> 00:04:28.850
public. Datadog also called out ghost accounts.

00:04:29.209 --> 00:04:32.769
Older GitHub accounts created years ago, left

00:04:32.769 --> 00:04:36.529
dormant, and later used for API traffic across

00:04:36.529 --> 00:04:40.399
many organizations. An old account blends better

00:04:40.399 --> 00:04:44.079
than one created yesterday. Then add compromised

00:04:44.079 --> 00:04:48.740
OAuth tokens or personal access tokens, and
enumeration

00:04:48.740 --> 00:04:52.939
can turn into access. Now, the actor may be
probing

00:04:52.939 --> 00:04:56.519
private repo paths, listing repos, checking
commit

00:04:56.519 --> 00:05:00.000
history, or cloning code. The takeaway is
simple.

00:05:00.160 --> 00:05:03.980
Treat GitHub like a production surface, not just

00:05:03.980 --> 00:05:07.209
source control. Watch Token Scopes. OAuth apps,

00:05:07.529 --> 00:05:11.110
old PATs, dormant users, outside collaborators,

00:05:11.610 --> 00:05:15.689
audit logs, GraphQL usage, private repo path

00:05:15.689 --> 00:05:20.550
probes, and sudden bursts of API activity.
GitHub

00:05:20.550 --> 00:05:23.629
holds the instructions for how your company
builds

00:05:23.629 --> 00:05:28.290
and ships software. Attackers know that. Your

00:05:28.290 --> 00:05:36.740
GitHub org is part of your attack surface.
Second

00:05:36.740 --> 00:05:40.720
story. On Call Brief flagged reports that xAI's

00:05:40.720 --> 00:05:45.319
Grok Build CLI transmitted repository data and

00:05:45.319 --> 00:05:49.500
file contents without redaction. The details

00:05:49.500 --> 00:05:52.779
around one tool may change. The bigger lesson

00:05:52.779 --> 00:05:56.560
does not. If an AI coding tool reads your repo,

00:05:56.779 --> 00:06:01.279
that is access. If it reads your dot env file,
Terraform,

00:06:01.500 --> 00:06:04.779
Helm charts, Kubernetes manifests, runbooks,

00:06:05.259 --> 00:06:09.339
incident notes, or internal docs, that is
access.

00:06:09.720 --> 00:06:13.120
And if it sends that context to a cloud service,

00:06:13.360 --> 00:06:17.319
that is data movement. That means security,
legal,

00:06:17.500 --> 00:06:21.060
compliance, and platform teams need to know
about

00:06:21.060 --> 00:06:24.680
it. We spent years building controls around
source

00:06:24.680 --> 00:06:28.480
code, private repos, SSO, branch protections,

00:06:28.899 --> 00:06:32.560
secret scanning, vendor reviews, access reviews,

00:06:33.040 --> 00:06:36.800
least privilege. Then an AI coding tool shows

00:06:36.800 --> 00:06:40.660
up and says, I can help you build this app.
Cool.

00:06:41.000 --> 00:06:44.279
But what can it read? Where does the data go?

00:06:44.600 --> 00:06:48.139
Is it retained? Is it used for training? Does

00:06:48.139 --> 00:06:51.860
it respect ignored files? Does it read Git
history?

00:06:52.100 --> 00:06:55.420
Does it upload the whole repo or selected
context?

00:06:55.860 --> 00:06:58.920
Can the organization audit usage? Those are not

00:06:58.920 --> 00:07:02.139
boring procurement questions. Those are
production

00:07:02.139 --> 00:07:05.959
security questions. Repos are not just code.

00:07:06.180 --> 00:07:09.819
They contain architecture, service names, build

00:07:09.819 --> 00:07:14.439
pipelines, IAM assumptions, deploy rules,
vulnerability

00:07:14.439 --> 00:07:19.079
hints, and sometimes secrets. The lesson is not

00:07:19.079 --> 00:07:22.500
never use AI coding tools. That ship has sailed.

00:07:22.680 --> 00:07:25.899
The lesson is to stop treating them like
harmless

00:07:25.899 --> 00:07:30.019
editor plugins. They are repo readers. Sometimes

00:07:30.019 --> 00:07:33.750
they are command runners. Sometimes... They are

00:07:33.750 --> 00:07:37.149
package installers. Sometimes they are cloud

00:07:37.149 --> 00:07:40.069
-connected agents sitting next to your source

00:07:40.069 --> 00:07:43.970
code and local environments. So they need
policy,

00:07:44.149 --> 00:07:47.689
review, and boundaries around where they can

00:07:47.689 --> 00:07:51.269
be used. Because it was just on my laptop is

00:07:51.269 --> 00:07:54.449
not a data boundary. Quick break from the news.

00:07:54.649 --> 00:07:58.009
The Ship It Weekly shop is officially open at

00:07:58.009 --> 00:08:01.350
shop.tellerstech.com. I've got a few Ship It

00:08:01.350 --> 00:08:04.009
Weekly t-shirt designs up there now. And I spent

00:08:04.009 --> 00:08:06.829
way too much time sourcing the actual shirts

00:08:06.829 --> 00:08:09.810
because I wanted them to feel like good trade

00:08:09.810 --> 00:08:12.790
show shirts people actually keep. Think of those

00:08:12.790 --> 00:08:15.769
soft Datadog style shirts that you get at
conferences

00:08:15.769 --> 00:08:19.170
and somehow still wear two years later. That

00:08:19.170 --> 00:08:21.470
was the target. I'm wearing one of those now

00:08:21.470 --> 00:08:24.170
so you can get a feel for it on video. If you

00:08:24.170 --> 00:08:26.370
want to support the show and rep the merch a

00:08:26.370 --> 00:08:29.430
little bit, head over to shop.tellerstech.com.

00:08:29.769 --> 00:08:33.070
For the next few weeks, coupon code SHIPTHESTORE

00:08:33.070 --> 00:08:37.210
gets you 20% off your order. That is
SHIPTHESTORE.

00:08:37.350 --> 00:08:41.009
Again, shop.tellerstech.com. All right, back

00:08:41.009 --> 00:08:49.870
to it. Third story. AWS Security Hub added
network

00:08:49.870 --> 00:08:53.669
scanning and impact analysis for exposure
findings.

00:08:54.029 --> 00:08:57.399
The short version. Cloud security is moving from

00:08:57.399 --> 00:09:00.039
this might be exposed based on configuration

00:09:00.039 --> 00:09:04.279
to we checked from the outside, this is actually

00:09:04.279 --> 00:09:07.720
reachable, and here is what that exposure could

00:09:07.720 --> 00:09:11.159
lead to. That is useful. Network scanning probes

00:09:11.159 --> 00:09:14.240
resources from the internet to identify actual

00:09:14.240 --> 00:09:16.799
reachability, not just what the route tables,

00:09:16.899 --> 00:09:20.059
security groups, and diagrams suggest. Actual

00:09:20.059 --> 00:09:24.750
reachability. Public IPs. Virtual machines. Load

00:09:24.750 --> 00:09:28.490
balancers. Reachable ports. Services behind
them.

00:09:28.730 --> 00:09:32.269
That matters because cloud reality drifts. A

00:09:32.269 --> 00:09:35.169
public IP gets attached during troubleshooting.

00:09:35.330 --> 00:09:38.990
A port gets opened and forgotten. A test load

00:09:38.990 --> 00:09:42.149
balancer lives forever. A Kubernetes service

00:09:42.149 --> 00:09:44.950
becomes public because someone copied a helm

00:09:44.950 --> 00:09:49.289
value from dev. Config analysis is helpful, but

00:09:49.289 --> 00:09:52.690
active scanning gets closer to the attacker's

00:09:52.690 --> 00:09:56.659
view. Can I reach it? What port is open? What

00:09:56.659 --> 00:10:00.120
service is there? What evidence proves it? Then,

00:10:00.179 --> 00:10:04.440
impact analysis adds the blast radius side. AWS

00:10:04.440 --> 00:10:07.740
says Security Hub can map downstream resources

00:10:07.740 --> 00:10:11.320
that could be compromised beyond the initial

00:10:11.320 --> 00:10:14.240
exposed resource. That matters because exposure

00:10:14.240 --> 00:10:18.220
alone is not the whole story. An exposed test

00:10:18.220 --> 00:10:22.299
box with no useful permissions is one kind of

00:10:22.299 --> 00:10:25.659
risk. An exposed instance with a role that can

00:10:25.659 --> 00:10:29.259
read production secrets, write to S3, or reach

00:10:29.259 --> 00:10:32.960
a database is a very different risk. So do not

00:10:32.960 --> 00:10:36.940
only prioritize by severity label. Prioritize

00:10:36.940 --> 00:10:40.519
by reachability and blast radius. Public and

00:10:40.519 --> 00:10:43.740
reachable matters. Public and reachable with

00:10:43.740 --> 00:10:47.379
dangerous IAM matters more. And when something

00:10:47.379 --> 00:10:50.879
is exposed, do not stop at closing the port.

00:10:51.470 --> 00:10:55.309
Ask who owns it, how long it was exposed, what

00:10:55.309 --> 00:10:58.929
it could access, what logs prove activity, and

00:10:58.929 --> 00:11:02.490
what prevents it from coming back. The tool
finding

00:11:02.490 --> 00:11:06.350
the exposure is only step one. Someone still

00:11:06.350 --> 00:11:14.850
has to own the cleanup. Fourth story. Microsoft

00:11:14.850 --> 00:11:18.269
published a post about evolving Windows
vulnerability

00:11:18.269 --> 00:11:22.279
management. for AI-powered discovery. And even

00:11:22.279 --> 00:11:25.100
if you are not managing Windows endpoints, the

00:11:25.100 --> 00:11:29.059
larger trend matters. AI is not just helping

00:11:29.059 --> 00:11:32.139
people write code faster. It is helping
defenders

00:11:32.139 --> 00:11:36.279
find bugs faster. It is helping researchers
analyze

00:11:36.279 --> 00:11:39.919
code faster. And eventually, attackers get
better

00:11:39.919 --> 00:11:43.740
at this too. Microsoft talked about using an

00:11:43.740 --> 00:11:48.100
agentic scanning harness called MDASH. to
analyze

00:11:48.100 --> 00:11:51.659
Windows at scale with multiple models,
validation,

00:11:52.159 --> 00:11:55.100
human review, and then high confidence findings

00:11:55.100 --> 00:11:58.879
going to engineers. The operator takeaway is

00:11:58.879 --> 00:12:02.080
that faster discovery means more update
pressure.

00:12:02.419 --> 00:12:05.320
A lot of companies still treat patching like

00:12:05.320 --> 00:12:08.460
a monthly chore. Patch Tuesday happens. Vulnerability

00:12:08.460 --> 00:12:11.879
teams triage. Endpoint teams test. App owners

00:12:11.879 --> 00:12:15.730
delay. Exceptions pile up. Someone asks if it

00:12:15.730 --> 00:12:18.769
can wait until the next window. That rhythm
already

00:12:18.769 --> 00:12:22.529
struggles. AI-accelerated discovery makes the

00:12:22.529 --> 00:12:26.070
tempo worse. More findings. Faster analysis.

00:12:26.710 --> 00:12:29.850
Shorter response windows. More pressure to know

00:12:29.850 --> 00:12:33.210
what is actually affected. This does not mean

00:12:33.210 --> 00:12:36.250
patch everything instantly and hope. Patching

00:12:36.250 --> 00:12:39.669
is still production change. Patches break
things.

00:12:40.110 --> 00:12:43.649
Agents break things. Middleware breaks things.

00:12:44.169 --> 00:12:47.789
Security fixes can have side effects, but
patching

00:12:47.789 --> 00:12:50.970
needs to look more like a real operational
system.

00:12:51.509 --> 00:12:56.870
Known inventory, staged rollout, rollback,
ownership,

00:12:57.169 --> 00:13:01.570
emergency paths, and coverage reporting, not

00:13:01.570 --> 00:13:04.710
spreadsheet theater. If your patch process
depends

00:13:04.710 --> 00:13:08.570
on 10 people manually asking app owners how they

00:13:08.570 --> 00:13:12.870
feel, AI is going to make that pain worse.
Security

00:13:12.870 --> 00:13:16.669
updates are becoming production operations, so

00:13:16.669 --> 00:13:19.330
they need production-grade process around them.

00:13:26.429 --> 00:13:29.909
Quick lightning round. First, HalluSquatting.

00:13:29.950 --> 00:13:33.570
AI coding agents can hallucinate package or repo

00:13:33.570 --> 00:13:37.070
names, and attackers can squat those names ahead

00:13:37.070 --> 00:13:40.289
of time. If the agent tries to install the fake

00:13:40.289 --> 00:13:43.970
dependency, it can pull malicious code. Do not

00:13:43.970 --> 00:13:47.090
let agents install packages just because the

00:13:47.090 --> 00:13:50.529
name sounds plausible. Second, Cloudflare had

00:13:50.529 --> 00:13:54.429
dashboard and API incidents. The edge may keep

00:13:54.429 --> 00:13:57.409
serving traffic, but if the dashboard or API

00:13:57.409 --> 00:14:01.269
is down, incident response can still be
impaired.

00:14:01.929 --> 00:14:05.470
Data plane and control plane are different
things.

00:14:05.690 --> 00:14:10.120
Both matter. Third, node-tar had a cluster of

00:14:10.120 --> 00:14:13.720
denial of service issues. Archive parsing sits

00:14:13.720 --> 00:14:17.159
in package managers, build systems, CI jobs,

00:14:17.620 --> 00:14:21.019
artifact handling, upload pipelines, and
scanners.

00:14:21.279 --> 00:14:24.679
If you accept archives from untrusted sources,

00:14:25.299 --> 00:14:29.259
tar parsing bugs matter. Fourth, ServiceNow had

00:14:29.259 --> 00:14:32.279
a requires authentication equals false issue.

00:14:32.379 --> 00:14:35.700
One unauthenticated REST endpoint in a platform

00:14:35.700 --> 00:14:40.080
that holds tickets. assets, workflows, and
incident

00:14:40.080 --> 00:14:43.480
context can become an enterprise data exposure

00:14:43.480 --> 00:14:46.879
problem fast. Fifth, France is pushing quantum

00:14:46.879 --> 00:14:50.639
risk into procurement language. That is how post

00:14:50.639 --> 00:14:54.100
-quantum migration becomes real. Procurement,

00:14:54.120 --> 00:14:57.799
compliance, vendor questionnaires, and data
retention

00:14:57.799 --> 00:15:02.340
expectation. And last, AWS wrote about Lambda

00:15:02.340 --> 00:15:06.860
-managed instances for Java cold starts.
Serverless

00:15:06.860 --> 00:15:10.100
keeps getting features that look more like
managed

00:15:10.100 --> 00:15:13.879
capacity under the hood. That is not bad, but

00:15:13.879 --> 00:15:17.679
the abstraction is not magic. Cold starts, warm

00:15:17.679 --> 00:15:22.080
capacity, runtime behavior, and cost still
matter.

00:15:30.720 --> 00:15:34.620
The human closer this week comes from SRE
Weekly.

00:15:35.049 --> 00:15:38.889
Issue 525 had a few pieces around post-incident

00:15:38.889 --> 00:15:41.269
reviews, human-in-the-loop authority gaps,

00:15:41.570 --> 00:15:44.309
and whether teams confuse collecting artifacts

00:15:44.309 --> 00:15:48.409
with actually learning. That fits this episode,

00:15:48.610 --> 00:15:52.210
because this whole week is about maps and
exposure.

00:15:52.809 --> 00:15:56.409
Datadog is talking about attackers mapping
GitHub

00:15:56.409 --> 00:15:59.590
organizations. Grok Build raises the question

00:15:59.590 --> 00:16:04.100
of what AI coding tools read. Security Hub is

00:16:04.100 --> 00:16:06.759
mapping what is reachable from the internet.

00:16:06.940 --> 00:16:10.440
Microsoft is talking about AI finding
vulnerabilities

00:16:10.440 --> 00:16:15.259
faster. Maps are useful, but maps do not fix

00:16:15.259 --> 00:16:19.080
anything by themselves. An exposure finding does

00:16:19.080 --> 00:16:23.399
not close the port. An API log does not revoke

00:16:23.399 --> 00:16:27.240
the token. A patch bulletin does not patch the

00:16:27.240 --> 00:16:31.080
fleet. A postmortem timeline does not create

00:16:31.080 --> 00:16:34.750
learning. A human approval step does not
guarantee

00:16:34.750 --> 00:16:38.509
judgment if the human has no context. That last

00:16:38.509 --> 00:16:42.590
one matters. Human in the loop sounds safe. But

00:16:42.590 --> 00:16:45.350
if the human is pulled in at the worst moment

00:16:45.350 --> 00:16:48.870
with the least context under the most pressure,

00:16:48.990 --> 00:16:52.889
the approval step can become theater. Same with

00:16:52.889 --> 00:16:56.669
post-incident reviews. A meeting is not
learning.

00:16:56.850 --> 00:17:00.730
A timeline is not learning. A document in the

00:17:00.730 --> 00:17:04.660
wiki is not learning those things can help but

00:17:04.660 --> 00:17:07.279
the learning happens when the system changes

00:17:07.279 --> 00:17:11.200
when ownership becomes clear when the runbook

00:17:11.200 --> 00:17:15.500
improves when alert noise goes down when the

00:17:15.500 --> 00:17:19.500
risky default gets removed when the next
operator

00:17:19.500 --> 00:17:22.900
is less dependent on luck so the question is

00:17:22.900 --> 00:17:26.900
not just did we review the incident the question

00:17:26.900 --> 00:17:31.779
is what changed because of it visibility is not

00:17:31.779 --> 00:17:37.220
ownership. A map is not a fix. That's it for

00:17:37.220 --> 00:17:40.359
this week of Ship It Weekly. We covered GitHub

00:17:40.359 --> 00:17:44.920
API enumeration, Grok Build CLI, and AI coding

00:17:44.920 --> 00:17:48.339
tool data boundaries, AWS Security Hub network

00:17:48.339 --> 00:17:52.779
scanning, and impact analysis. Microsoft's AI

00:17:52.779 --> 00:17:56.339
-powered vulnerability discovery and patch
cadence,

00:17:56.579 --> 00:17:59.819
plus HalluSquatting, Cloudflare incidents,

00:18:00.440 --> 00:18:04.200
node-tar CVEs, ServiceNow authentication risk,

00:18:04.559 --> 00:18:08.519
Quantum Procurement Pressure, and Lambda Managed

00:18:08.519 --> 00:18:11.559
Instances. If this episode was useful, follow

00:18:11.559 --> 00:18:14.240
or subscribe wherever you are watching or
listening.

00:18:14.500 --> 00:18:17.380
If you know someone dealing with GitHub org
security,

00:18:17.839 --> 00:18:21.960
AI coding tools, cloud exposure, or patch
pressure,

00:18:22.339 --> 00:18:26.000
send them this one. Also, the Ship It Weekly
shop

00:18:26.000 --> 00:18:30.839
is open at shop.tellerstech.com. Use coupon

00:18:30.839 --> 00:18:35.299
code SHIPTHESTORE for 20% off your order for

00:18:35.299 --> 00:18:38.960
the next few weeks. Again, SHIPTHESTORE at

00:18:38.960 --> 00:18:43.220
shop.tellerstech.com. You can find the weekly brief

00:18:43.220 --> 00:18:46.359
at OnCallBrief.com and the full show notes,

00:18:46.519 --> 00:18:50.720
links, and past episodes at ShipItWeekly.fm.

00:18:50.799 --> 00:18:53.539
I'm Brian Teller from Teller's Tech. Thanks for

00:18:53.539 --> 00:18:57.640
listening. And remember, visibility is not
ownership.

00:18:57.839 --> 00:19:00.210
A map... is not a fix.