Episode 877 transcript

FLOSS-877

Jonathan: Hey folks, this week we're talking with Francois Proulx about smoked meat, and poutine, and Bagel, a trio of open source security tools that you don't wanna pass up on. This is Floss Weekly, episode 877, recorded Tuesday, July the 28th: RCE as a Service.

It's time for Floss Weekly. That's the show about free, libre, and open source software. I'm your host, Jonathan Bennett, and today we're revisiting a topic that we've talked about in the past, and in fact, revisiting a guest. We've got Francois Proulx of Boost Security. These guys are experts in supply chain security, and really one of the main things that we're talking about with this is GitHub CI, continuous integration.

And so a lot of projects will have a CI set up to where you run automated tests on your code changes. Where this can get dangerous is if you allow the outside community, so untrusted people, to make pull requests, and then that CI engine runs against those incoming pull requests. And then you have this kind of strange problem, that you're running untrusted code inside your GitHub repository, and surely that doesn't ever go wrong.

Yes, sometimes it goes wrong. We had Francois on the show about two years ago, and we talked about a project then called Poutine, which was a scanner, an automated scanner to take a look at a project's CI runs, and essentially give you an evaluation. Do we think this is safe or not? And in the time since then surely we've fixed this problem and it doesn't exist anymore, right?

Unfortunately I don't think that's the case. I'm gonna go ahead and bring Francois on. He's the guy that has the answers, and we're gonna find out. So welcome, sir, to the show. It is great to have you back.

Francois: Thank you.

Jonathan: Yeah what, w- what, did I get the problem space right? And then what's changed in the last two years?

Francois: Ver- very good introduction. Yeah, I think you got the, the takeaway from the last discussion, and I guess you, you did your own homework on your own projects and could actually see why the tool was created. Why I created it, why it's a, it's an issue that especially maintainers... this audience is both consumers, like users of open source, as well as maintainers.

Jonathan: Yeah, absolutely.

Francois: For the maintainers, I think my message was that they should give the tool a try so that they can protect their own end users, right?

Jonathan: Yeah, and I think we're probably gonna pitch this in the context of GitHub, but this is not just a GitHub issue, is it? There's there's GitLab, there's Codeberg, there's glued together CI scripts that run on infrastructure that's not any of those three things.

And I imagine you could have problems on any of those contexts, couldn't you?

Francois: 100%. So effectively you know- Basically any source control system, be it GitHub, GitLab, or whatever- Yeah ... that can automatically trigger the execution of a CI environment upon the submission of new code changes, just the, you know, triggering on such an event, it they can have the same exact problem.

So really the devil's in the details in terms of the configuration of what is the behavior that happens, like the, effectively the secret, or does the execution of the arbitrary code changes get hacks- access to secrets or not? If it's just arbitrary code execution of the new tests, for instance, or the new code potentially it can be done in a way that's perfectly by design and without clear risk.

Of course, if you were to reuse the same CI environment, like the same machine is is to be reused across different runs, then there can be pollution across those. But assuming it's an ephemeral run runner environment it can be done safely. But then, yeah, like the, the way it gets configured and the various components that get pulled during execution is really what matters.

Jonathan: Yeah. And I think part of the reason why this is such a sticky problem to solve is 'cause on one hand, obviously when you have a pull request from the outside, so like by definition you're talking about untrusted code. It's literally untrusted user-supplied data, and you wanna do a processing run on that.

But- Historically, we've not been concerned about, and I'll just make this very generic, we've not been concerned about malicious code inside of make files, or malicious code inside of build scripts, or malicious code in all these various places, even in C and C++ headers, for that matter.

You can do some interesting things just with preprocessor directives. And that's been a, historically a blind spot because oh, if you're compiling this code on your machine, surely you already trust it. And then you take this and you put it on the cloud, which is, as we all know, just somebody else's computer, and because it's on the cloud, it has to have access to some sort of, to, to some sort of secrets.

It has to have access to your build environment and your accounts in the cloud to one extent or another. And there's multiple ways that this can go wrong, and I've seen firsthand someone will run a build, and part of the build is go grab all of the variables from that you can get ahold of, basically all your environment variables, and then send those off to somebody else's server, and then you lose your secrets, right?

But then there's also even other problems, and I think GitLab had an issue here at one point where because you are... You're in this inside the runner you're validated. You can then potentially go and do things to the project, and so there's that danger as well.

And this is not just theoretical anymore, is it? There's been real attacks pulled off with these sorts of problems.

Francois: Yeah, absolutely. So that, that is exactly how as we publish open source tools, we write articles on the topic, pushing the boundary of the, the research in that area.

And I speak at different conferences and, on podcasts and whatnot. But the, the last series of conference talks that I gave, it really starts with this fact that since we last talked, about two years ago- ... the the threat actors the, the bad guys have also been listening to the podcast or my talks-

or seeing the ar- re-reading the articles and using the same tools that hopefully you guys, the defenders the, the maintainers- ... have been using, but they effectively flipped it or used defensive tools that were designed for defenders as an offensive tool for them to find zero-days effectively.

Because those tools, they can find vulnerabilities in the the attack surface of the, the build pipelines, and then lead to poisoning the the well, poi-poisoning the open source release. And that's what we saw with worms, like in the fall of 2025. I'm sure all of you have heard about the different worms spreading on NPM and PyPI mostly, shyahlood, and there's been a number of iterations of those- Yes ... autonomously propagating malware in, in open source packages. And e-even in the spring of 2026, we saw another wave that was not necessarily using worms, but much more let's say, skilled threat actors that were r- that really understood the benefits that they could get by exploiting effec-effectively large open source projects and have downstream effects in large organizations, right?

Jonathan: That's the, the classic supply chain attack, right? Particularly if you can pull that off without being spotted for a while. So then you can you get your tendrils into one project, and that gives you a l- a, a diving board to then get your tendrils somewhere else.

And the longer someone can go without being spotted, the more of a mess that they can make.

Francois: Yeah. But at the same time even if it's not very long, but everything is automated, they can, achieve the end goal- ... v- so quickly that no one can really stop something like that. Like- Right

at best, it can be detected as it happens or as it has already happened. And if in some case we saw them pivoting multiple levels from the initial access vector, the initial point of entry-

...

Francois: To steal secrets and then pivot down- downwards in the infrastructure, like cloud infrastructures- of large corporations namely.

Jonathan: Yeah, absolutely. And then you, I think sort of tongue in cheek, but it's a point worth following up on. You mentioned the idea that, oh the, the attackers are listening to our podcasts and they're using our defensive tools, and that's the challenge anytime that you build like an auditor or a a red team tool that like, there's not a whole lot of difference between what an auditor does and what an attack tool does.

Is that just the nature of the beast? Is that just the way that it works?

Francois: Yeah, I think there's no... we're not in the 1990s anymore- ... where we try to keep the precious, elite tools behind the curtain, and we only give them to certain trusted people.

The cat's out of the bag. Yeah. The techniques are well-known. And recreating most of those tools is not rocket science. Once you understand what you're looking for, you can probably just use grep, in many cases, it's just configuration mistakes or a couple specific things that you're gonna be looking in this case, in YAML files.

For the most part, those CI/CD configuration will be in YAML files in specifically named folders. And yeah the simplest thing you could be using grep and highlight some things that you would then audit manually. So those tools are just doing that more efficiently, but ultimately that's, as you said it's that, that's what we have to wrangle with.

The technique is known and by b- both defenders a- and attackers.

Jonathan: Yeah, absolutely. We're not in the position where if your CI gets hit, you can just say, "Oh, it must have been a nation state that did it." No, it may have literally been a teenager in a basement. Yeah ... I blame, and again, it's not just a GitHub problem, but GitHub is the, the 800-pound gorilla in the room of of online Git repositories.

And I blame GitHub for this, 'cause I've gone down this track a couple of times. You made me... I don't think that was the first time I'd heard of it, but you definitely made me more aware of this when we talked about it last time. And so I've gone and I've looked at some of the projects I've been involved in, and I've gone down the rabbit hole of do we do this right or not?

And I've read through the GitHub documentation on things like, just for instance, the, the pull request event versus the pull request target event. And I will read through their documentation and come away with one feeling of "Okay, we need to do it this way." And then I go and read somebody else's blog, and they say no, you need to do it this way."

And I still don't know if pull request or pull request target is the safer way to do a CI run. It's... I just, I wish there was a single answer somewhere that I could look to, and it's like, "Don't do this." Okay, I won't do that.

Francois: Yeah. The, the s- the simple answer is pull request target is m- let's say- Is if you're to grab something, pull request target, it's not the only one, right?

But if you're gonna flag that, like that's a clear thing where you need to stop and audit the rest of the code. It doesn't mean it's not is insecure kind of a Boolean flag, right? You m- you can use this in a safe way. It's just that it's a bit of a foot gun.

Like you, you need to really understand how to use it in a safe way because it comes, great power, with great power comes great responsibility. It does grant access to the secrets during the execution of the runner. The big difference between pull request and pull request target, and specifically in the case of GitHub actions, is that one of them will not grant access to secrets, but it will i- it will run the latest version of the pipeline.

So basically, this is in the case where you want your contributors to make- ... changes to the build pipeline- ... and you want them to be tested immediately, right? So that is let's say in the scenario of enterprise or like in a private repo or when you have direct maintainer contribution, this is fine because you want to test like directly the, the latest version of the build pipeline changes.

But pull request target on the other hand, it effectively locks the version of the CI configuration to the one that's already been merged. So that's the biggest difference, is like one is untrusted build configuration, and the other one is trusted build configuration. But the big difference is that one doesn't have access to secret, the other one has ac- access to secret.

If it's a trusted pipeline, it means that as long as there's no vulnerability in that pipeline configuration, everything is okay.

Jonathan: But- But if your repo has a Python script in it that gets evaluated and executed during build time, which is quite common by the way, you have a problem all over again.

Francois: Yeah, exactly. So in, in fact so much so that y- you were asking did the, is GitHub doing enough? And I would say in the past three, like four, basically since March more or less, there's been a big like... They've been, they've started to really move the needle. And that's in response, direct response to all the big things that happened- Yeah

in the spring. So they've made a number of changes that actually in some cases are breaking changes. Like literally they decided to do the very non-Microsoft move of, okay, this is too bad. Too many people don't get it right, so we're gonna completely change the behavior to a more safe by default.

Where you really need to explicitly go ahead and say, "Yeah, I know what I'm doing. Let me do it." As opposed to leaving foot go- foot guns, around. And so th- that, that's a pretty major change. Specifically to pull request target, they made a change that was made fully effective as of two weeks ago or so.

But it still makes it possible to have the same kind of vulnerability as before, it's just that there's one less way that you're gonna do it, like without even knowing, right? ... It's at least a little bit more explicit on your part.

Jonathan: And that's why everybody's CI runs started breaking randomly a couple of weeks ago.

That, that solves one mystery. I, I think something that maybe not everybody realizes I have to remind myself of this every once in a while, is obviously Microsoft owns GitHub. GitHub is the owner or the, the trusted source of NPM. And so like all of this stuff comes back to the same group of people getting black eyes from it.

And so it's not terribly surprising that they are very motivated to try to fix this.

Francois: Yes. The, directly Microsoft for many of the things, like if you're a Azure cloud user, there's a number of components that are directly used in production in Azure, both from the infrastructure side as well as the end user side of their cloud services, like kind of cloud SDK, Azure SDK, and other things, right?

That you want to interact with their backend that are hosted on GitHub, open source, and that use GitHub actions. Some of those components are deployed on NPM, so they have vested interest in ah, hardening the path to to Azure, right? Because from commercial perspective, ... Microsoft definitely has- Sure

incentive. But it's for the benefit o- of everyone, because a- any, any improvement to this infrastructure is good for open source.

Jonathan: Yeah. Absolutely. All right. So that's sort of the background. And last time we talked about Poutine, but now you've got a new tool, Smoked Meat. I just gotta say, I love the carnivore theme going on here.

I 100% approve of that. But what is Smoked Meat? What does it bring to the game?

Francois: Yeah. Okay. So Poutine was really a scanner. It's meant as a static code analysis scanner. It's meant to basically scan and find all those special YAML files and detect vulnerabilities, like in the misconfiguration in those YAML files.

It's gonna say, "Oh, you have pull request target, and then you have X, Y, Z other conditions, preconditions for it to be considered almost certainly vulnerable, almost certainly exploitable." So there's some, caveats to that, like in practice, but it's a scanner and people would ra- run it.

Since it was published it's now being used by many large organizations many big open source projects. And it's very lightweight, very easy to run at scale. You can scan a large organization with hundreds of repos thousands of pipelines in just a few seconds, and it's gonna spot those.

Then you're responsible for, looking at those results and hopefully fixing the issues,

Jonathan: Yeah. There, there's a- ... and

Francois: on our side ...

Jonathan: it's worth breaking in here and talking about there's a challenge when you run one of these static code analysis tools to then correctly understand the results, make the judgment call of either, "Yes, I think this is a real problem," or, "No, I don't think it is.

I think this is a false, false positive." Or even like, "Yes, this could be a real problem, but we mitigate it in other ways." Yes. And so there's a real judgment call to be made there, and sometimes that's really a hard step to take.

Francois: Yeah. And exactly, that's, I'll get to Smoked Meat, your, to answer your question in a moment.

But a- ab- absolutely as you said, it's it's difficult, and we've been using this tool at scale to scan millions of open source projects. And in the past two years or so, we've made several thousands of coordinated disclosures to many projects like big and small. Like Small, tiny open source projects, as well as things that are maintained by Google, Python Software Foundation Red Hat.

And so indeed, like some of those are pretty trivial, fairly easy to point to the bug and to the solution, the way to re-remediate. But other times it can be very difficult to confirm that it's exploitable- ... and then to find the way to address it. In some cases it's more architectural.

You need to redesign the whole thing because you, you made like wrong assumptions on how to do that securely, and that's much more painful, right?

Jonathan: Absolutely.

Francois: But let me get to the answer to your question about Smoked Meat. So Poutine is a scanner, and Smoked Meat is a red team, like offensive tool.

So the first one is gonna find the vulnerabilities, and in Smoked Meat I use Poutine as a library. So if you remember, Poutine is a Go, is written in Go. It's a common line tool, but here I just use it as a library, as part of a bigger project called Smoked Meat. Which is really, if you want to simplify it for those of you who may have heard about Metasploit.

So Metasploit is an offensive tool, like a red team exploitation tool- Yeah ... where it's gonna scan to find vulnerabilities and then give you automated, like automatic craft payloads to test ex-exploitation and validate that indeed this given vulnerability can be exploited and then you can discover what's behind.

Once you achieve remote code execution, you can, in some cases, like find credentials or discover the environment, do further reconnaissance and pivot. Part of Metasploit, there's this plugin called Meterpreter, which is effectively a small shell execution environment that will run remotely.

Once you achieve the re-remote code execution, effectively you move from your laptop to somewhere further and you rinse and repeat. Like you execute as if you're sitting on that server observe what's around, and then continue. Smoked meat is this, has the same exact concept, but applied to the context of CI/CD.

And the reason why Metasploit would not directly work in the context of CI/CD is because in almost all cases, CI/CD is running ephemeral environments. So the VMs that run your tests, it's typically torn down and completely deleted the minute the tests finish running. Then the next run or maybe parallel run of the test will use new VMs, so it's not like a persistent infrastructure like you would attack a cloud infrastructure typically.

So yeah, so that's the gist of it Smoked Meat uses Poutine as a library. It scans, then it will automatically generate the corresponding payload for the different vulnerabilities and let you basically exploit it, get whatever secrets are running in the CI environment.

And then re- rinse and repeat, discover further what, what's behind. In many cases it's very common, especially for a bit less for open source projects, but in a commercial enterprise environment, you will have a CI environment deploy to a production cluster, right? And then maybe this cluster is connected to something else.

So that's that's really what Smoked Meat is all about.

Jonathan: Yeah. You get a foothold onto maybe somebody's network or somebody's CI runs. Yeah. It's a real problem, and that's how you get into some of those messes with it's how you end up with things like we've been shipping this project or this product, these binaries for the past two years, and oh, they've had a backdoor on them the whole time," right?

It's that it's that sort of supply chain problem that you can run into. Yeah. So super, super important. Does Smoked Meat work a, so if we wanted to use it inside of a Metasploit run, can you do that? Can you build- ... bu- build the stack on top of each other?

Francois: Not really.

It's really, it was designed as a turnkey solution, end-to-end, purely designed with the, the intricacies of CI/CD in mind. All the tricks that basic- It knows exactly what will happen when it lands in a GitHub Actions runner, the environment the tools that are a- accessible there, and the different services a- around it.

And how to get access to the secrets and the different features that are inherent to GitHub Actions. So it's really meant to be used on its own for that specific type of red team engagement. Sure. I've actually created a capture-the-flag environment for people to experiment with that safely- That's great

so that they can practice i- in, in a, an environment that It has a number of challenges. You start basically from a public repo, and once you achieve the first foothold, then you discover private repos, and then eventually you discover a cloud environment, and effectively you can hop through four or f- five or six pivot points a- and get quite deep.

And you in, in the process, you exploit about five vulnerabilities in different CI/CD runners basically where you start from that public perspective initially.

Jonathan: Yeah. That's actually really neat. I appreciate it when people do that with the tools, because it's very nice to be able to learn how to use tools without actually breaking the law.

Francois: Exactly. That's

Jonathan: So that's- ... that's really important.

Francois: Yes. I mean- We don't,

Jonathan: we don't wanna all become Kevin Mitnick, right?

Francois: Yes. Researchers like, like me we all create those kind of environments to practice the proof of concept whe- before we disclose something. We try to reproduce that in a sandbox the separate environment where it tries to reproduce as many of the conditions of the real target.

And, we can use that to take a video demo and say, "Oh look, if someone is- w- was gonna compromise that, that's how it would execute." And we can do that without doing it in the public repo where other people could notice that, "Oh, look at that, someone actually achieved poisoning the thing," and maybe the maintainer is on vacation, and someone else is gonna come back. So we need to do that ethically, and that, that's why this tool is released alongside an environment that people can practice and learn and then test it on their own projects again, maybe in a separate environment that just tries to reproduce the real setup and before they- they maybe apply the patches.

Jonathan: Yeah. It brings to mind a potential problem, and I'm curious if you guys have seen this, 'cause obviously you've been using this tool, and you've used it to help find problems. What do you do if a project is maintained, or unmaintained, but it still has a, a CI vulnerability?

Like, how do you even go about trying to fix that?

Francois: I think it's the case y- that, that's a good point. And I guess you have to see un- unlike a vulnerability in the code itself, right? Where it would be subject of a, a CVE afterwards once it's patched and people know, okay, this, there's been a patch applied to this specific version- of, and so you should update to the latest version, which has addressed it. In this case, it's really an infrastructure. So it's not the code itself- ... where it is the YAML in the GitHub repo, but it is effectively a side door. It's another way to- ... get access to the repo, like as a s- because you achieve remote execu- execution in a privileged environment.

Yeah, to your question if the project is completely unmaintained and the CI/CD is vulnerable I guess hard forking it is is the, what's necessary because otherwise it could be modified and in some cases it can be hard for someone to really determine that it's been compromised if there's no collaboration from the side of the, the maintainer.

The, in terms of forensics, in terms of confirming that it's not been exploited, it can be difficult sometimes.

Jonathan: Yeah. I'm thinking back to, of course, one of the most famous examples of this, this sort of problem. Not exactly CI related, but still close enough to talk about, the, the XZ hack where the, the backdoor was put into the XZ libs, and one of the things that made that more, more complicated is that Lassie Collin, unsung hero, absolutely the good guy in the story, but he was on vacation when all of this broke out, right?

He, it took them several days to track him down and get him to fix things, and that made it all harder to clean up. And I'm just imagining I have seen, I've seen GitHub repositories that are still being used that nobody has touched for months or maybe years, and they're just running on autopilot.

And it's not at all difficult to imagine a scenario where an attacker gets access to one of these through a CI run and pushes out a new version or rewrites a Git tag. Which by the way, if you have the option, you should really be referencing things by Git hashes and not Git tags. That's sort of a different story.

I, it's, boy it's real challenge to try to deal with that. Do you guys have like contacts at GitHub to where you can- Yes ... you can clean something up if there's nobody at the wheel?

Francois: No we do. So as I mentioned, we do coordinated disclosure with many projects.

And we do have privilege like contacts, like we establish relationship with people at GitHub, but not just at GitHub.

And in some cases, there... I've seen examples where the project was so high profile and the maintainer was overwhelmed or- ... for some reason, and the, the ecosystem impact was so broad that, yeah, like GitHub in some cases like put a freeze, like paused any new pushes to the repo.

A- and some cases like reverted, but that's pretty rare. In... I haven't seen many examples of that. Maybe I can think of two or three at most in the past couple of years, where the maintainer was MIA and GitHub had to step in and freeze everything. Otherwise it was cascading.

Like es- Yeah ... especially in the case of the worms, like in the fall, it was so bad, it was propagating so fast that they needed to do something a bit more drastic.

Jonathan: Yeah, that's a big deal for the for the repository host to step in and make changes. That's outside of the normal social contract with how all of these hosting things work.

And so it's gotta you gotta have a, a... It's gotta be a pretty drastic scenario. I think, so talking about XZ, I think that was one of those cases where GitHub hit the button and freeze this and turn it off, and nobody can get to the, the XZ repo anymore until things got fixed. Yeah, I think they did.

Yeah. So we've talked about GitHub quite a bit, but this is not just a GitHub issue. Do you have sort of tales from the trenches from any of the other major hosts or anything outside of that, actually? I would love to- ... I would love to know if this is a proj- or problem that you see in just some maintainer's random glue scripts.

Does it show up there, too?

Francois: A- absolutely. A- again, like it's really a matter if we're talking about... first of all, there's kind of two main threat models that I have to to tell people about. So the first one is the one we just discussed, which is really the public open source project.

People can contribute changes using pull requests, right? They will submit new code that is not yet reviewed, and if the CI is going to automatically trigger upon the submission of code changes, then depending on the configuration, we can lead to what we discussed. If the maintainer has been compromised already to some ex- to some way phishing- info stealer malware that ran on their computer, exfiltrated their credentials, or stole them through another, like a p- like basically a first attack- ... maybe a first CI compromise led to getting se- secrets credentials of a maintainer, and then use them to directly attack another project as the maintainer in this case.

Like basically impersonate the maintainer, and that's... We've seen that. Also, the, the worms were really using that in some cases to different techniques to seed, to just bootstrap the the, the malware by phishing info stealer, and a CI compromise.

And then after the, the worm would...

in the, the case of direct automation, it would maybe get as I said, like some credentials of a maintainer, and then discover which projects they can directly attack. So with the second one, which is y- you're basically already the maintainer, , it's kinda hard to to stop that, right?

It's not a vulnerability. It's just like the way that you would modify your own project. And we've seen that across any ecosystem. This is really not specific to any, any given platform. And the same thing, like if you steal like a PyPi publish token or NPM publish token, you're gonna publish directly and skip, s- skip touching the source control environment.

And in fact, that's what most malware author would do because they, they want you to believe that the source code of the open source project is all good, but what's published on PyPi is completely different.

Jonathan: Yeah, definitely a challenge. So what's the, i- d- does d- does Smoked Meat or Poutine, does it give any visibility into that situation?

What, what can we do to even mitigate against th- that, that realm of problem?

Francois: I- if your question is about a maintainer be- being directly- Right ... compromised, like their own credentials. So in, in between the time that we we came out with Poutine and before Smoked Meat, there's a third tool that I haven't mentioned that we released called Bagel.

So all the food theme.

Jonathan: Absolutely.

Francois: And Bagel if you don't, didn't notice, like, all those food items, they're all kinda staple Montreal food because, we're a startup in Montreal, and Poutine is a Quebec-

...

Francois: Food. Smoked Meat, if for those who don't know, who never came to Montreal, Smoked Meat is the way we refer to the, a special type of brisket smoked brisket with a marinade and, you know-

Jonathan: Yeah

Francois: it's just called Montreal style Smoked Meat.

Jonathan: Oh, yeah.

Francois: And Bagel, we have our own Montreal style bagels that is different than the New York style bagel. Got it. The point is that Bagel is all about looking at the posture of your laptop, your e- endpoint, where you write code, and trying to limit the blast radius, limit the impact of a malware running on your laptop-

So that, for instance, take a very simple example. You have your SSH private key in the home folder without a passphrase, right? Malware runs, it's gonna get that, and the passphrase the, the SSH key is usable immediately by the attacker, versus you have a very long, complex passphrase. Even if they get that, they would need to crack the passphrase before they can use the SSH key, right?

So things like that we would if you run Bagel, you're gonna find secrets lying around your laptop, maybe in your bash RC you load as environment variable some, some API keys to automatically push somewhere and, things like that. And then it comes with some kind of remedi- remediation guidance to tell people how to do that in a more s- safe manner.

Because we know that, like- You're gonna click the wrong link, you're gonna download something- ... something will run on your laptop, and then- Yeah. That's true ... if you limit the amount of things that something running at a given moment has access to or there's at least some kind of user interaction, some kind of confirmation.

Personally I'm not here to advocate for, I know that you're a big, like, framework la- laptop user. My colleague actually has that. But on, on a MacBook, I use Touch ID, which the secure enclave fingerprint-backed execution environment to store private keys. So my SSH key, for instance, requires me to put a fingerprint in interaction.

So even if a malware runs, it would, the malware would need to trick me into putting my fingerprint exactly at the moment it wants to sign- ... using my private key. And then that means that the malware could not do that 1,000 times in one second. It would need to have me press 1,000 times with my finger, right?

And the same thing applies to many other types of credential like a passkey, a YubiKey, and whatnot, things like that. They effectively move the sensitive key material off of the normal userland execution environment so that- ... malware running on it will not be able to at least propagate autonomously so quickly.

Jonathan: It-

Francois: So-

Jonathan: It gives you more friction in your workflow, which you sometimes need.

Francois: Exactly.

Jonathan: I've talked about that- At least for

Francois: those-

Jonathan: Yeah, I've talked about that concept of friction when it comes to AI pull requests, but I've never quite thought of it in these terms, but that's really an interesting connection to make.

Francois: Yeah. You want- So in fact, talking about AI and whatnot, ... we didn't do that We had to go

Jonathan: there. We had to go there.

Francois: Okay. Okay, yeah. How many minutes in we didn't use that acronym? But so Bagel is, one thing it is gonna find is if you use Codex Cloud Code, or whatever on your laptop- maybe you don't know, but it saves those conversations in a temporary folder- ... so that you can resume conversations. And very often, without you even knowing, maybe you never copy-pasted some secret, but in the process of Cloud Code reading logs to- Yeah ... for you to troubleshoot something in a production environment, it actually- It caches all kinds of stuff

pulls in the context. Yeah. And those secrets are gonna be in that temp folder, so Bagel is gonna find them right away. There's even a feature to scrub it automatically, like- Oh, nice ... redact with, like a, a fake token.

Jonathan: Yeah I imagine that part of the solution to this also is just to carefully scope your tokens so that, you create- Yeah

a token for one use, and it only works for that, and it does not, it's not the keys to the kingdom for everything you have on GitHub- Yeah ... or every SSH, what have you.

Francois: Yeah, basically, like, if, especially people who maintain open source projects typically everything is public, so read-only access to- things that are already public is not considered a sensitive secret. E- even if, go ahead and steal a token which just has access to a public repo, just read-only, big deal, right? And that's exactly the design consideration that GitHub has when it comes to pull request versus pull request target.

The execution environment will get a secret that has read-only access to, in that case, a public repo. So the attacker gains no no further foothold. It's at the same level as it started initially. But so to your point, yes having different credentials, like a default credential that for instance, that SSH key, you can split your SSH key for pulling and pushing, but signing the commits is a different key material.

You can do a SSH-based Git commit signing. So having two different keys, one that has the friction of the fingerprint authentication, the other one without, and then- ... when you do auditing after, afterward, you, you can confirm, okay, all my Git commits are signed. They're signed with the key that I expected and anything that deviates from that is, to be, Reviewed with suspect

Jonathan: investigated maybe. Yeah. Yeah, that makes a lot of sense. So you opened Pandora's box. You talked about AI first and now I gotta ask about it. And i- in, in just in thinking about the... Of course, the world has changed significantly since we talked two years ago. I'm just kinda curious is there a, is there a strong argument to be made still that Poutine is the way to go to do these scans versus just, "Hey, Claude, take a look at my .github folder in this repo and tell me if there's a problem"?

Francois: No, that's a good question, and in fact- We, when we do this kind of scanning of millions of open source projects, we leverage agentic like agentic approach.

We do a hybrid approach. So basically we use Putine at scale because it's very efficient, very lightweight, no tokens needed. And we've tuned- And you don't pay $1,000

Jonathan: a month for the

Francois: tokens to run it . Yeah, exactly. So we've tuned the rules in both... In, on one side, either it's very narrow but very high signal.

It's like if it's gonna flag that, it's nearly 100% that it's exploitable. We can report it almost without looking. I'm not saying that, but it, it gets to the point where the rule, the deterministic rule from Putine is gonna highlight the, the, the low-hanging fruits. Then the other approach is we use Putine with effectively several preconditions that are not necessarily all proven to be l- lining, like all the ducks, not necessarily all in, in a row.

But then using AI to more creatively combine and say, "Okay, yeah, it has this condition, but not that one. But given that it has this other thing, there might be like a, a less obvious way that static, like a deterministic scanner- ... would have skipped." So a hybrid approach is really what we've been using at scale.

A- and also for those more advanced kind of multi, m- like chained exploit where you have a low risk thing combined with another one. That's the, the, the new thing that is now possible using Claude and others.

Jonathan: Yeah, that makes a lot of sense. It is amazing to me how quickly we have gone from, daniel Stenberg was one of the first guys to really, to blow the whistle on this, because curl is one of the most installed projects anywhere. But people trying to game the trying to game the system and be able to find exploits to make money in, in, the, the various bug bounties, to u- using AI to do that and therefore just creating absolutely garbage reports.

How quickly we've gone from that to AI is now a tool in every security researcher's toolbox, and it's finding real problems every day and helping us fix them. I it seems like I blinked and we went from A to B.

Francois: Yeah. It does require ex- experts in front of the, the keyboard. But that's, there, the...

I agree that there was a period where the experts were like non-believers and in the meantime, you had the non-experts that were just, like creating slop.

And then people s- realized that, okay, if you use that smartly and you don't just trust the output right away, but you use it to augment your scanning, like vulnerability research it's quite amazing, yes.

Jonathan: It, it seems like if you're using the latest models though, they are better about not giving you slop.

Francois: Yes.

No, absolutely.

Jonathan: There's always, just like when a human finds something, there's gonna be a judgment call as to like how serious this is. Is this a real problem or was this part of the design?

Is this an accepted trade-off? There's all of those things that honestly that make our job harder. If you could just, if there was just a magic rule set that, oh, this is a CVE and this isn't we would probably be out of jobs, right? Yeah.

Francois: That being said, if we go back to the question related to did Git- GitHub fix the whole thing they are making...

they published a roadmap with a number of changes to the environment where you can now set policies across your organization or specific repos that will turn off or basically prevent execution of workflows using certain risky features. So now you can effectively decide, like purposely decide that your policy is to effectively remove those footguns or explicitly allow some of them in specific cases that you did do your due diligence.

So there's a lot that GitHub has done in the past two months or so, and there will be more in the next few months for those of you interested.

Jonathan: I, in, in thinking about this more and having listened to your explanation of the two targets in GitHub runs, I don't understand why GitHub does not make a third target that is like a pull request target safe, where you take the safer of both of those two options.

So you pin the .github folder so that you're running your known safe CI, and you also don't share the secrets with the run. This seems like an obvious fix.

Francois: Yeah. No I understand. It's, yeah. At the same time-

Jonathan: That would make life so much easier ... at the same time- We could just go set that for everything and be done with it.

Francois: No, it's true. I think, It all comes down to is the code in the pull request, has it been remo- reviewed? Do you have execution o- of it before it gets reviewed? But every... As soon as it gets merged, it's merged, right? So there, it's trusted. So it's really this this, this line of clicking merge.

But sometimes people review very quickly and merge things that they should not,

Jonathan: Say it's not surely we're all extremely careful, and we read every line of code before things get merged. Surely. Oh, absolutely. All right. I think we've done a good job of covering the problem space and the tools that, that you guys have put together for this.

If you look into your crystal ball and you think about what's coming in the next six months, we'll make it a little easier for you. I was gonna ask for the full year, but we know how much things can change in a year. Just the next six months of sort of this problem space, what what do you see coming?

What are you watching as, as maybe the next trends?

Francois: That's a good question. There, there's a number of things, as I mentioned that, that is happening that makes it harder for threat actors, much less obvious. But it doesn't mean that that we're, it- it's a done deal. Because ultimately CI/CD, I think I sh- personally I think we should all rename CI/CD RCE as a service, because it's really much easier to think of CI/CD as an execution environment running arbitrary code, right?

And if you start to think about that- ... a- and design your environments like, But for the next six months yeah I don't know. I think the, the threat actors seem to the bad guys that have been very active in the past couple of months, they seem to have been a bit more quiet.

I think they're feeling the heat. But if we remember what happened in the fall of 2025, I hope it's gonna be quieter.

Jonathan: Yeah.

Francois: But I don't know. Supply chain security as a whole there's so many angles. The build pipeline was a we- weak, weaker spot, I would say. Very easy attack surface to, to profile from the outside with Poutine or other tools.

And the other angle, the maintainer side phishing, we're never gonna fix that limiting blast radius is something we can at least do. The, the, the package ecosystem like NPM and PyPi and others they've been doing quite a bit of work in that respect as well.

So I,

Jonathan: I will-

Francois: I, I don't know ...

Jonathan: I will throw in there that the idea of a, a malicious maintainer or a compromised maintainer, there, there are some tools out there that you can use. So we've got one repository that's set up to where I c- I don't think I can do a f- I'm the owner of it, and I don't think I can do a force push to it.

And particularly if I do a pull request- ... I cannot approve and push my own pull request. There has to be a second set of eyes that go in there and gives it a review before it'll go in. So there are- Yes ... there are some tools that, I don't know that either of those are a magic bullet, but there's gonna be w- ways to at least to some extent mitigate that.

And I think, if people are working with important code bases, that's definitely something they should take some time and investigate and see if they can get set up. If it's practical. Not every project has two dedicated maintainers, and I g- I get that.

Francois: Absolutely.

Jonathan: So

Francois: that's

Jonathan: that's a real challenge.

Yep. E- as you look at at some of the attacks that have happened, do you get the idea that some of them are, like, big nation state actors, or do we think most of them are just essentially cyber criminals looking for a cash-in?

Francois: There has been very few... when it comes to attribution, that's always you don't want to just, wave your attribution without a- as access to as many of forensics evidence.

But yeah, I would say probably 98% of the cases that I've seen, it's clearly just people just having fun,

...

Francois: Or with a intent of gaining some kind of, you know, like- A lot of them- ... money out of that ... a

Jonathan: lot of them come down to stealing Bitcoin wallets, don't they?

Francois: Yeah, absolutely.

In many cases, if you're... And that's, that, that would go a bit closer to some nation state, which I will not name, but those interested in this topic, they know that there is one nation state threat actor that is very fond of crypto. And-

Jonathan: the one that comes to my mind is not in the South and it's not in the West.

Francois: Yes, it is. There's some compass if you were in a different... yes. And they, basically any open source project that is near, near or directly in the path of anything related to crypto infrastructure- Oh, yeah ... be it cryptocurrency wallet or some kind of backend- Oh, yeah ... it's dangerous.

So- I

Jonathan: mean, those guys just have a- ... you

Francois: might be a collateral victim ...

Jonathan: giant target painted on them. Yeah. There, there is... it is impossible for those guys to be too paranoid. Yeah.

Francois: Yeah, absolutely. So basically, if you're gonna be using pretty much anything that some cryptocurrency infrastructure happens to use also you might unfortunately be a collateral victim of that, and it's kinda hard to know, right?

If you go back to spring of 2025, C- Coinbase- ... was the actual intended victim for the TG Actions CI/CD compromise. So if you remember- ... there was TG Actions change files was a small GitHub Action component that many people were using.

But the final victim was Coinbase.

And yeah. But in that case, it was not, likely not a nation state threat actor, but still someone that was after

Jonathan: cryptocurrency. Yeah. Yeah. That makes sense. So we talked a lot about the open source stuff. Tell us briefly about Boost Security. What do you guys do?

Francois: Yeah. So we have a, ob- obviously like a commercial offering and we have the research angle that I've been talking about the different projects.

So we have a application security posture management product that is in some cases like using the open source projects that we put out there and, put a layer that's more like for enterprise grade kind of policy and scaling of of all that. And yeah, w- we have an, a whole new set of offering that's a bit closer to when I mentioned Bagel, where it's gonna be looking for the laptop of a developer for enterprise users like they...

We have a product specifically for that and it's quite on the mind of many security-minded people in, in, in medium and large organizations now- Absolutely ... because the laptop of developers has been effectively ignored in many cases, like by traditional EDR and things like that.

And so that, that's a big angle that we're looking to address now.

Jonathan: One of the reasons is because as a developer, it is such a pain to run almost any of the existing antivirus products. Like almost all of them are just terrible and will get in your day and ruin your... Get in your way and ruin your day.

So most of us developers, me for one we're tech s- we're in this dangerous place where it's like, "Oh, we're tech savvy enough to keep ourselves out of trouble. I would... I know what I'm doing. I would never get my laptop compromised." Also followed with, the big company's antivirus project or, endpoint security pro- I know too much about it.

I would never run that on my computer. And like- Yeah ... I get it because I'm right there too, but at the same time, that's a terrible and dangerous place to sit.

Francois: Yeah, so I c- I can tease that we're gonna be coming out with something in the near future that people may... People interested in that area, they may want to look look at what w- we'll be announcing in the next couple of weeks.

Jonathan: Yeah. I would, man, I would love for, I would love for there to be a really good endpoint security solution that was not insulting to run on my own machines. Maybe that's you guys. I would lo- I would love for that to be you guys. That would be so much fun. Parts of that open source? All of it open source?

Francois: Part of it- Parts of it ... is definitely open source. The rest we'll see when the announcement, Sure ... comes, but Sure. Yeah,

Jonathan: absolutely. I will make sure and watch out for that. That sounds that sounds really cool. Sounds interesting. I unfortunately, a lot of us, we get in situ- ourselves in situations where it's like because of whatever we're working on, we're required to have something running, and it's like, "Okay, fine.

I guess I'll go install Malwarebytes. That's the one that I hate the least," or, something like that, and maybe not necessarily the right answer. Just because I hate it the least doesn't mean it's the best answer.

Francois: Yeah the, the issue is that almost all of those EDRs or mal- antivirus, they were not designed to work on a developer laptop- where you write new code, and you compile it, and you run it five seconds after you, you wrote it. You modify a Python script, you execute. What's the difference between the one you just wrote five seconds ago and a malware that you downloaded where you Wget some Python script and then you execute it?

Unless it's really need threading the needle, or you downloaded that from a third-party source, and then even then it... That happens all the time. That's what we do to build different things, right? It's really more about the behavior of, it's not normal for your SSH private key to be loaded in the memory of something that, it... There's a number of behavioral things that you can look at to, to at least either a- alert or block, right?

Jonathan: Yeah, very interesting. Definitely looking forward to that. Is there anything that we didn't touch on that, that we should have?

Francois: No I think that's pretty much that.

Obviously, like Smoked Meat is a tool that's not for everyone. It's something that is more int- interesting for pen testers- It- ... red team operators and whatnot. But,

Jonathan: I'm sure somewhere in the source code and/or on the website, there's a notice, "Do not run this. Do not break the law-" Yes

with this tool. Do not run this on live code anywhere."

Francois: For sure. But as a learning tool, like for even for people who think, "I'm no- never gonna be running that tool," we have a YouTube short YouTube video, three minutes- ... that people can see how it works and the type of damage that can be done if ex- exploitation of a CI/CD environment is to occur.

And it can be used as just a, a, a learning moment for, for people to tell others that they should maybe be running poutine and look at auditing their CI environments.

Jonathan: Yeah, absolutely. We do have a bit of a live audience today, and they've been going back and forth with the food puns, and Mashed Potato says, "It's not for vegetarians."

I have to point out, it's the bagel. If you really- Yeah ... if you really want the vegan option, you've got the bagel.

Francois: Technically poutine is not vegan, but it's vegetarian at least. There you

Jonathan: go. I don't know. It sounds pretty good to me to put the smoked brisket on top of the fries and the gravy.

That sounds really good. Just have it all together. All right. Thank you. Thank you so much for being here. I've gotta ask you a couple of questions before I let you go, and we asked them last time. I don't expect the answers to change, but we still, we gotta get them in. What, Francois, what is your personal favorite text editor and scripting language?

Francois: Ah do people write code anymore, it's just like prompt code.

Jonathan: I know. I know. Oh somebody one of these days is gonna tell me that "Oh yeah Claude Code is my preferred text editor." Yeah. I'm gonna have to resist the urge to strangle them through the screen.

Francois: I was almost gonna say if you are to profile the number of times that I...

The answer is VI. For me it's a VI guy,

i've never installed Emacs on my box. But I do use Z- Zed as like instead of Visual Studio Code sometimes- Okay ... like for a lightweight more visual- ... like a Z- E-D. But yeah, VI guy.

Jonathan: Yeah. And then you were gonna make the point I think that if you measured it by lines of code you write that something like Claude- Yeah

might end up being the winner.

Francois: Yeah, probably. Pr- well, Codex, but yeah.

Jonathan: Okay. Yeah. That's... I would... To, to, to each their own, right? All of those, all of the different models have- Yeah ... their different wrinkles, and I think they're well-suited for different tasks, and we all get used to

Francois: one.

Especially for security tasks. I've had some... Yeah. Like the, Cla- Cla... I love Cla- Claude Code, but like for security professionals, it, it's- there's been some some some drama in the past two months or so.

Jonathan: Sure.

Francois: So we

Jonathan: can see that. Although they do now have a some form you go fill out.

One of my, one of my other maintainers did this, where it's like, "I promise I am a maintainer of this project. I promise I will use this responsibly. Please let me hack with it." And they will look at it and go, "Okay, fine," and give you m- more access. I don't know. There's... I'm sure there's still some guardrails, right?

But they will give you a little bit more access. I- in my experience,

Francois: that's not enough. I'm part of those, those those programs- Okay ... and even then the, the guardrails are a bit annoying for professionals, like security professionals.

Jonathan: Sure.

Francois: But-

Jonathan: Ha- have you found have you found that running models locally lets you get around some of that?

Is there a a case to be made for doing security research with local models- I- ... for that reason?

Francois: I think so, but it's quite expensive. And quite... I think if to run any model that, that is even close to the, the frontier models, it's impractical for- Yeah. But I did, yeah, I did mess with some smaller models.

They can be useful for a very specific a- scenarios, yes.

Jonathan: Yeah. Yeah. Interesting. Very cool. Francois, thank you so much for being here. It's been an excellent conversation. The, the hour plus just absolutely flew by, and really had a lot of fun with it. Thank you, sir, for being here.

Francois: Thank you.

Jonathan: Yeah, I appreciate it. All right. That is Francois Proulx talking about Boost Security and their open source projects, Poutine, Bagel, and Smoked Meat. We've got a whole meal, Canada style, and that's a lot of fun. We do have some great shows coming up. Next week we're having Jonathan Polance of Ferris Systems, and then I know we've got quite a few that we have emailed and working on scheduling.

But we do have some slots open, so if you have a project or you know of one that needs to be on the show, you can shoot us an email, floss@hackaday.com, and we can get them scheduled up. We appreciate everybody that's here. Thank you for watching and listening, whether you get us live or on the download, and we will see you next week on Floss Weekly.