‍

In this episode of Mitiga Mic, Field CISO Brian Contos talks with Idan Cohen, Senior Cloud Security Analyst at Mitiga, about the growing risks in SaaS and cloud workflows. The discussion covers supply chain compromises, the security challenges of CI/CD pipelines, and how attackers take advantage of automation and misconfigurations. Idan shares practical steps for detection, response, and strengthening defenses against modern threats to the cloud.

Every other week, Mitiga Mic delves into the human side of cybersecurity in today's cloud-centric landscape. Join our host Brian Contos as he engages in insightful conversations with CISOs, analysts, researchers, founders, engineers, and other thought leaders, uncovering their unique stories and perspectives on navigating the evolving threat landscape.

‍

Want more expert insights?

‍

Subscribe to Mitiga on YouTube to explore past episodes and stay ahead of what’s next in cloud and SaaS security with Mitiga Mic.

‍

‍

Transcript

‍

Brian Contos: Idan, welcome to Mitiga Mic.

Idan Cohen: Thank you, Brian. Very excited to be here.

Brian Contos: So, who the heck are you and what do you do?

Idan Cohen: I am Idan Cohen. I'm in Tel Aviv, Israel. I'm a senior cloud security analyst on the investigation team. We provide incident response, threat hunts, and also MCDR services here at Mitiga. I focus mostly on performing threat detections and assisting with security research to identify new vectors and attack paths of adversaries, implementing them into our CDR platform, and sometimes assisting in response efforts.

Brian Contos: You can just say you do all the cool stuff. I think that kind of sums it up—you get to research the cool stuff and respond to the scary stuff. Awesome. Well, thanks for being part of Mitiga Mic. I really want to dive into some research you’ve done recently around GitHub Actions. Maybe you could frame for our viewers what exactly happened.

Idan Cohen: Let’s take it back to March 14, 2025. There was a post on one of the social platforms where someone linked a StepSecurity research about a compromise they had investigated. They identified a repository that is very widely used, common across many organizations, called changed-files under the TJ Action. It had about 20,000 different organizations dependent on it.

They discovered a threat actor was able to inject malicious commands into it—specifically, a script that allowed a full memory dump within the GitHub Actions workflow. So, everyone dependent on it executed the workflow with the malicious commit, allowing memory dumps. This exposed many secrets ranging from access keys to credentials used by companies that did not want them leaked publicly.

The repository was public, but it was also used by internal and private repositories. Later, a post by Adnan Khan suggested that this compromise may have initially started with a different repository. But the one we’re discussing today is a critical supply chain attack.

Brian Contos: Yeah, it got a lot of press. Most people watching this are probably familiar with GitHub. For those who aren’t, it’s basically a mainstay on the development side. GitHub Actions and related tools are all about workflow automation. So how did this workflow automation component actually become the target?

Idan Cohen: It does sound unusual at first. But when you look into GitHub Actions and workflows, you quickly see the potential impact. Compared to compromising an EC2 instance or a workstation, compromising a workflow has much wider impact across an organization.

GitHub Actions run automatically in response to events like PRs, commits, or issue commands. Attackers can abuse these triggers to inject malicious inputs, especially when workflows aren’t properly validated or scoped. That’s why threat actors are focusing on this vector.

Brian Contos: So, it’s like people being a bit cavalier, setting things up quickly without a security mindset—similar to web application attacks or SQL injection where parameter checking is ignored. That makes sense. So, what actual vulnerabilities were exploited here?

Idan Cohen: One CVE was recorded to track this event, but this wasn’t really a code exploit. It was workflow misconfiguration. The workflow accepted untrusted inputs from forks or public PRs without proper checks.

Anyone can submit code into a public repository to help the open-source community. That’s great for development, but in this case, threat actors committed malicious scripts. These repositories weren’t pinning commits to hashes. Instead, they were applied with IDs, so attackers could compromise every version of the workflow automation. That made the entire repository compromised.

Brian Contos: I’m wondering if the attacker was just trying to build their résumé. [Laughter] Who knows? Well, let’s switch gears. From a defender’s perspective, what are some best practices organizations should take to secure their CI/CD pipelines on GitHub?

Idan Cohen: First, use pull request targets carefully. Validate everything. Scoping permissions is always important. Avoid executing code from forks directly.

More broadly, reusable workflows with proper controls will standardize secure execution. Use scanning tools—GitHub has some, and third parties as well—to check workflows for misconfigurations.

Also, isolate jobs. Avoid reusing artifacts or environment data between trusted and untrusted jobs. These steps strengthen CI/CD pipeline security.

Brian Contos: Let me ask about non-human identities—bots or automated accounts. Any tips for detecting anomalous activity across GitHub?

Idan Cohen: First, make sure you have proper logs. Audit logs alone aren’t enough—sometimes they don’t even include IP addresses. Build logs and workflow logs are critical. With them, you can implement behavioral monitoring to detect anomalies.

Rate limiting is also effective. Flag accounts making abnormal API calls or workflow interactions. And always review audit logs for patterns and access anomalies, especially once IP addresses are included. Combine that with reputation checks from threat intel feeds, and you’ll catch a lot.

Brian Contos: Yeah, IP reputation checks are basic but powerful. Seems like a no-brainer.

Idan Cohen: Exactly. It’s the minimal step every organization should take.

Brian Contos: Let’s broaden out to SaaS platforms in general. How can engineers enhance detection and mitigation to prevent breaches?

Idan Cohen: First, integrate with detection and response systems: SIM, XDR, CDR. Collect and centralize all logs. Threat actors are increasingly targeting SaaS products, like Slack and Zendesk.

Leverage logs for analysis. Use secret scanning tools and rotate secrets regularly. Consider honeypot workflows to detect probing.

Of course, Mitiga’s CDR provides detection coverage for SaaS and cloud products, and we’re always expanding. Finally, periodic security reviews of workflows, permissions, and integrations are essential.

Brian Contos: That’s fantastic advice. And you’re right about secrets—they’re not just usernames and passwords. They can be tokens, database information, and so much more. Once an attacker gets a foothold, they can spread across platforms and partners.

Idan Cohen: Exactly. Movement becomes easy once secrets are exposed, and attackers can leverage them for wide-scale attacks.

Brian Contos: Well said. Idan, where can viewers get more information on this research?

Idan Cohen: You can find the full write-up and technical breakdown on our website at mitiga.io. It’s also on my LinkedIn, on Mitiga’s LinkedIn, and on Ariel’s—my colleague from the security research team who worked on this with me. We’ve included detection examples anyone can apply with simple code.

Brian Contos: That’s awesome. You heard it here. Check out mitiga.io. Thank you, Idan, for being part of Mitiga Mic.

Idan Cohen: Thank you, Brian, for having me. Appreciate it.

‍