Podcast Detail

SANS Stormcast Wednesday, May 20th, 2026: Assume Supply Chain Compromise; GitHub Action Compromise;

If you are not able to play the podcast using the player below: Use this direct link to the audio file: https://traffic.libsyn.com/securitypodcast/9938.mp3

Podcast Logo
Assume Supply Chain Compromise; GitHub Action Compromise;
00:00

My Next Class

Click HERE to learn more about classes Johannes is teaching for SANS

Podcast Transcript

 Hello and welcome to the Wednesday, May 20th, 2026
 edition of the SANS Internet Storm Center's Stormcast. My
 name is Johannes Ullrich, recording today from
 Jacksonville, Florida. And this episode is brought to you
 by the SANS.edu Bachelor's Degree Program in Applied
 Cybersecurity. Today's podcast, if everything goes to
 plan, and it's not that I'm starting to write down
 everything, but I'm hoping to do something a little bit more
 focused because there are a couple real important things
 that I want to talk about. And well, with that, maybe spend a
 little bit less time on it, but we'll see how it goes. So
 really, what it's all about is Ken Hartman put together a
 real good summary of what recently happened with the
 TeamPCP and all of these supply chain campaigns. I
 mentioned some in podcasts over the last couple of weeks.
 For example, Checkmarx getting compromised a couple
 of times. And with that, also some of their products. I
 think this sort of has reached a new quality, and Ken also
 points that out, is with the TanStack compromise. Now,
 TanStack actually had SLSA Level 3 verified components.
 So what this means is the software they produced was not
 only digitally signed, but also the systems being used to
 compile and basically run the build process were verified
 and were audited. So that's what SLSA Level 3 means. And
 well, it's sort of one of these software supply chain
 verification procedures. It used to be that you could say,
 hey, you know, if software is really verified to that level,
 well, you should probably trust it. But I think, and
 that's sort of really where my soapbox today a little bit
 starts is, you must assume compromise. We're living sort
 of with that on the network security level for quite a
 while, that we try to encrypt all of our data, even on
 internal networks, because we assume compromise that has
 been sort of introduced years ago. But I think developers,
 and when it comes to software components, we also at this
 point must assume a compromise, just because of
 the sheer number of credentials having been leaked
 with campaigns like the TeamPCP campaign recently. And
 this wasn't just the only real campaign like this. We had a
 number of different campaigns like this, that stole
 credentials, stole GitHub access for a large number of
 open source projects. And even, you know, with that,
 some more closed projects like Checkmarx and such, basically
 proprietary software is affected by this as well. This
 is no longer just an open source problem. It's, I think,
 also important to understand here, when it comes to, well,
 with that, what are you going to do about it? And I think
 one thing that's really, really important here is sort
 of that enterprise-wide credential management or
 secret management. It's not easy. Like, you know, a lot of
 these things, we're talking about things like inventory
 and such, they sound easy, but they're definitely not easy.
 I'm not understating this here, but it is something you
 definitely have to focus on. How are you managing your
 credentials? How are you able to quickly rotate them as
 needed? And also, well, how are you protecting them as
 they're being used as part of your own supply chain and
 build processes? Definitely something where you have to
 look for solutions here. And that's, I think, sort of what
 I'm getting out of these recent supply chain issues.
 Number one, assume compromise. Number two, protect your
 credentials, protect your secrets. In particular, if
 they're being used as some kind of CICD pipeline, because
 I think that's where, based on what we've seen currently,
 they're probably the most vulnerable. And just sticking
 with this here for one more topic, and that's compromised
 GitHub actions. So the latest example here is, as pointed
 out by Step Security, the issues helper action. And
 that's a very popular action. And what the attacker here did
 also is that they relabeled all the tags. So all the
 different tags for prior versions are now pointing to
 compromised versions of this GitHub action that, well, no
 surprise, exfiltrate secrets again. So be aware. And yep,
 like locking it in on a particular tag is not going to
 help you here. Talking more about credential theft,
 Microsoft has a good blog post about some recent more
 advanced targeted attacks that they have seen. And they all
 start out with the attacker abusing the self-service
 password reset feature in Azure. And if you have to
 factor authentication enabled, they'll be sending you some
 social engineering in order to get the victim to approve the
 change of passwords. So definitely user education may
 be an option here, but also some auditing of password
 reset requests may help a little bit here. And yes, then
 the goal of course is to gain access to the victim's cloud
 infrastructure and exfiltrate data. Well, that's it for
 today. So thanks for listening. Thanks for liking.
 Thanks for subscribing and special thanks for anybody
 leaving good comments in particular sort of on your
 favorite podcast platform. And remember this podcast should
 be available via sort of the standard podcast outlets, but
 also on YouTube. If you enjoy a little bit more video
 version and also like on systems like Alexa, it should
 be available. Thanks and talk to you again tomorrow. Bye.
 Bye.