---
title: "François Proulx -- Actionable Software Supply Chain Security"
url: https://appsecpodcast.com/francois-proulx-actionable-software-supply-chain-security/
date: 2023-06-22
duration_seconds: 2524
season: 10
episode: 13
guests: ["François Proulx"]
topics: ["Threat Modeling", "Software Supply Chain", "DevSecOps and CI/CD"]
audio: https://www.buzzsprout.com/1730684/episodes/13075949-francois-proulx-actionable-software-supply-chain-security.mp3
video: https://www.youtube.com/watch?v=JedvVLXhVVk
transcript: true
---

# François Proulx -- Actionable Software Supply Chain Security

*June 22, 2023 · 42 min · Season 10, episode 13*

with [François Proulx](https://appsecpodcast.com/guests/francois-proulx/)

on [Threat Modeling](https://appsecpodcast.com/topics/threat-modeling/), [Software Supply Chain](https://appsecpodcast.com/topics/supply-chain/), [DevSecOps and CI/CD](https://appsecpodcast.com/topics/devsecops/)

[Audio](https://www.buzzsprout.com/1730684/episodes/13075949-francois-proulx-actionable-software-supply-chain-security.mp3) · [Video](https://www.youtube.com/watch?v=JedvVLXhVVk)

## Show notes

Software supply chain -- how deep does the problem go? François is here to help us realize how deep the rabbit hole of the supply chain is and enlighten us with strategies to get out of the hole. François is a senior product security engineer for Boost Security, where he leads the supply chain research team. With over 10 years of experience in building AppSec programs for large corporations such as Intel and small startups, he's been in the heat of the action as the DevSecOps movement took shape. François is one of the founders of NorthSec and was a challenge designer for the NorthSec CTF.

The Application Security Podcast is brought to you by [Security Journey](https://www.securityjourney.com/).

About Security Journey  
François is a senior product security engineer for Boost Security, where he leads the supply chain research team.  
→ [Learn more about Security Journey](https://www.securityjourney.com/)

Connect with François Proulx:  
→ [François Proulx on LinkedIn](https://www.linkedin.com/in/francoisp/)  
→ [deps.dev](https://deps.dev)

Mentioned in this episode:  
→ [deps.dev](https://deps.dev)  
→ [Sigstore](https://www.sigstore.dev/)  
→ [OpenSSF Scorecard](https://securityscorecards.dev/)  
→ [SLSA](https://slsa.dev)  
→ [Attack Trees (Schneier)](https://www.schneier.com/academic/archives/1999/12/attack_trees.html)  
→ [Let's Encrypt](https://letsencrypt.org/)  
→ [OpenSSF](https://openssf.org/)  
→ [Terraform](https://developer.hashicorp.com/terraform)  
→ [OpenID Connect](https://openid.net/developers/how-connect-works/)  
→ [Brook S.E. Schoenfield](https://twitter.com/BrkSchoenfield)  
→ [Jonathan Marcil](https://twitter.com/jonathanmarcil)

Chapters:  
00:00 Meet François Proulx: Actionable Software Supply Chain Security  
02:18 I do, definitely. Okay. I was going to trademark it, but  
12:20 I think about the complexity of the modern software supply chain  
18:57 Okay. So, what are some of the lessons  
25:36 Continuing on the ATT&CK tree perspective, I'm going to kind of  
27:51 Okay. Thanks. Yeah, that was helpful to kind of, as I'm  
33:20 Could we or should we create the same thing for the  
39:46 François, we're coming to the end of our conversation, and I

## Transcript

*6,312 words · assemblyai*

**0:00 Chris Romeo:** François is a senior product security engineer for Boost Security, where he leads the supply chain research team. With over 10 years of experience in building AppSec programs for large corporations such as Intel and small startups, he's been in the heat of the action as the DevSecOps movement took shape. François is one of the founders of NorthSec and was a challenge designer for the NorthSec CTF. François joins us to talk about supply chain attacks, some of the new things that are happening. We get into Salsa, we talk about attack trees and some work he did looking at source code control systems with attack trees, and really just provide you some actionable results and things you can take away about how to properly secure your software supply chain. We hope you enjoy this conversation with François Proulx.

**0:54** None of the top 50 university programs teach secure coding in their curriculum. At Security Journey, we help enterprises reduce vulnerabilities through application security education for developers and everyone in the SDLC. With over 400 up-to-date lessons created by industry-leading security experts and a programmatic approach that creates security champions, our program has increased AppSec knowledge as much as 85%. Visit securityjourney.com to try our training today.

**1:20 Chris Romeo:** Hey folks, welcome to another episode of the Application Security Podcast. This is Chris Romeo, CEO of Kerr Ventures, and also AppSec aficionado. Giving myself a new tagline here.

**1:50 François Proulx:** We're trying it out.

**1:50 Chris Romeo:** I'll see if it works. I don't know if I really love it yet, but I'm going with it just because I made it up on the fly. Joined by my good friend Robert. Hey, Robert, how are you?

**1:59 François Proulx:** Hey, Chris, doing well.

**2:00 Chris Romeo:** Yeah, Robert Hurlbut.

**2:01 François Proulx:** I am a principal application security architect at Acquia, also focused on threat modeling, and always good to be here to talk again about application security.

**2:12 Chris Romeo:** Now, do you consider yourself, Robert, an AppSec aficionado?

**2:16 François Proulx:** I do.

**2:17 Chris Romeo:** I do, definitely. Okay. I was going to trademark it, but I guess I really don't need to now because apparently other people think this too. So, I'm super excited today to have François Proulx, who's going to be answering some questions and helping us to understand software supply chain and the different attacks that come into it. And so, this is based on a talk that he's done at a number of conferences already. Broken Links: Behind the Scenes of Supply Chain Breaches. And so, you can actually Google that and find it. I watched a version of it from BSides NYC just earlier today in preparing for the interview. But François, we'd like to just dive right into the deep end of AppSec, and we want to know your origin story. How'd you get into AppSec? Sure.

**3:05 François Proulx:** Glad to be here with you guys.

**3:07 Chris Romeo:** Yeah.

**3:07 François Proulx:** So, all right. So, I guess, Things get, start to get interesting when I was about 5 years old. So, you know, I had, like many kids back in the '80s, I had one of those Radio Shack computers, which had the BASIC programming language built in. And like many kids, you know, at the time, we were all retyping games that we would kind of find in books and magazines and whatnot. There was also like a pretty cool feature, which I remember in those Radio Shack computers, there was a a basic statement called motor on, motor off, which was originally intended to trigger the cassette tape, but it was really like a way to trigger any kind of electronic, like kind of a, you know, on and off thing. So, we would plug like at a relay and build all sorts of Lego contraptions and trigger motors that would plug into even VCRs to create a multimedia experience with that. So, that's kind of how it started. And then later in middle school, I was spending most, you know, all my free time at lunchtime in the computer lab with other kids that did that when they were young like me. And one of those kids is Jonathan Marcil, which many of you know. And, you know, it was the time of dial-up internet with Netscape 0.9 and Mosaic and things like that. And, you know, I didn't have internet at home, so I would save as web pages onto floppy disks, bring them back home to teach myself HTML and later JavaScript by reverse engineering the web pages. So with Jonathan back then, we were kind of tinkering with writing our own text-based adventure games in BASIC. And, you know, also kind of get a glimpse at social engineering with him. He was He's about 2 years older than me, so he would kind of teach me some tricks that he had already. And later, a couple of years later, I got my first summer job as a technician, computer technician for a local school district, which was pretty awesome as a first summer job, you know, building PCs, passing Ethernet cables in the wall and installing Windows NT 4 or, even 3.51 servers. So actually pretty cool first summer job, well paid. But, you know, soon enough I got my first lesson because one of the things I did the year before that was use those social engineering skills combined with programming to create a fake Windows OS login screen and trick the teacher into giving his admin password. I don't even remember what we ended up using the admin password for, honestly. But, you know, we were in those, you know, phone phreaking, reading zines type of scene back then. So, I guess someone snitched me because my boss at the school district heard about this thing that happened with weird OS login screen and thought that out of all the kids in the school, I might know something about that. And, you know, in the end, I got the lesson by not getting renewed the next summer. Because I confessed what I did, and he told my dad at the time that I needed to decide if I wanted to be on the dark side or the good side going forward. So, that's how it started. And, you know, after engineering school, did a bunch of CTFs to practice and put to good use those security skills, and later founded NorthSec here, a security conference and CTF in Montreal. I was participating in different CTFs like DEF CON qualifications and whatnot, but really my first job, like real job out of university was as an iPhone developer because I was even tinkering with the jailbreak OS before it was the official like way to develop on iPhone. So I knew how to develop iPhone applications before it became official. So I kind of had a head start in the game. But always all those know-how of SQL injection, XSS, and whatnot. I was the one around every dev team kind of telling the developers to be careful about that. I was kind of always the annoying guy on the team back then. There's no GitHub, so no pull request, but we're still doing some kind of code review. But Anyway, so like, a couple of years later, I got my first full-time security job in a startup. I was kind of, you know, literally kind of building an application security program from zero, just as like my first full-time security job, like in a startup of about 30 or so employees. 6 months later, we were acquired by Intel. So pretty fast turnaround of like building that AppSec program And then joining Intel and then worked with Brooke Schoenfeld, which I think you guys know. So he was kind of my, you know, mentor at Intel. Worked pretty closely with him as a product security champion. And then at some point they closed the office. I did a couple of years in the blockchain stuff, which don't really love, but found my home at Boost Security now where I am senior product security engineer, so helping both on the security research side as well as helping define what the product and service that we're building now. It's really kind of an AppSec orchestration platform that kind of aggregates results from all sorts of scanners and orchestrates what happens with those findings, kind of automatically to triage and, you know, And all that.

**9:06 Chris Romeo:** Very cool. I always love it when someone's story goes back to early childhood and then maps forward. I love to hear those stories because it's so cool to see the connections and the intersections. And, you know, growing up with Jonathan Marcel and then Brooke, who is Brooke Schoenfeld, who is one of my favorite people on earth, and somebody who I certainly cherish the time that I get to spend with him, which is not very much, but to be mentored by him is like, You know, to me, he's one of the giants in the industry, even though he's going to be so mad when he hears that, hears me describe him as that, but he is.

**9:43 François Proulx:** He taught me threat modeling, so that's been a great mentor. Excellent. Yeah, agreed, agree about Brooke and hearing the stories of Jonathan as well. That's fantastic. So, François, you know, as we dive into the topic today, Could you briefly explain this idea or this concept of supply chain attack for our listeners who may not be familiar? Sure. So, you know, I think, I mean, all your listeners are very much into application security, which is sort of a, I would say, narrow-focused aspect of what supply chain, if you kind of step back a little bit and just not focus on, like, looking at the source code, finding SQL injections, and all sorts of OWASP top 10 vulnerabilities by scanning the code and whatnot. If you kind of step back a little bit and look at it, not just from the perspective, okay, there's a piece of code, it's going to be running in production, I want to prevent vulnerabilities from being exploited, but actually, if you're like, okay, well, this place where the source code is actually stored, it is something that you want to care about in terms of security. It's just like, you know, Information Security 101, like data security. It's not just the application, but hey, the source code, if it gets compromised, if it gets modified by someone unauthorized, either, you know, some outsider or insider, so like malicious insider type of threat. So that's, you know, the supply chain is like when you start to step step out of it and not just look at application security, but really the developers that are touching that code and where does that code go? And like, it goes into the build system, and that build system, can it be compromised and then actually affect the downstream code, like what runs in production? So, there are many, many areas where the supply chain comes in, like through the ways of your dependencies you pull in, like Typically, nowadays, you're going to have Maven dependencies, npm, PyPI, and whatnot, kind of pull all those things from open-source packages. So, again, you kind of— when you go down the rabbit hole of, okay, I looked at my supply chain, but then I step back and look at the supply chain of my own dependencies, it gets quite complex. So, that's The big picture.

**12:19 Chris Romeo:** So, when I think about the complexity of the modern software supply chain, it amazes me every time an application runs. It actually does something. It's like, there are so many transitive dependencies that just buffet out across so many different projects and things that are coming together. And then, boom, it all comes together, and it starts, and it just works. And I'm like, It's just amazing to me that that much complexity can all come together and still work. So, from the CI/CD pipeline perspective, we know, you know, we did an episode last year with Daniel, and I can't remember the other gentleman's name, who created the OWASP Top 10 list for CI/CD. So, certainly, this area has gotten a lot more attention recently. From your perspective, like, why are CI/CD pipelines the prime target? Why are they getting so much attention these days?

**13:20 François Proulx:** I think in recent years, I mean, you know, it's in the news, it's in the ether, you know, people talk about it much more. I think, you know, it comes back to the talk I did, which is, you know, behind the scenes of supply chain breaches. I started the talk by saying that, You know, it's what people talk about these days. It's a hot topic in the news with SolarWinds. Like, you know, many people heard the term supply chain in the context of software engineering related to SolarWinds, which we can get into a bit more. But I think, you know, it's really been the kind of secret sauce of many nation-state actors for much, much longer, so like decades, because, you know, supply chain tricks, it's been the de facto thing of spies kind of, you know, infiltrating organizations and replacing bits, you know, like changing the package, the content of the package on its way to the destination. Just apply that to your open source dependency, you know, you can look at that. So looking at The CI environment, it's really where it's supposed to come all together. You're supposed to have the legitimate source code that you built, and then you pull all sorts of dependencies. So, this environment where it gets compiled or packaged and hopefully signed so that later downstream, you can assert that it really came from your trustworthy CI environment, that's kind of a high-security piece of the supply chain, if you don't have any signature, well, then you cannot even trust that. But I think, yeah, it's just like something that came in the news, like in the spotlight with those high-profile breaches, but it's been the tricks of, you know, nation states. I think it's really because we're getting better at AppSec overall, like, you know, thanks to OWASP and other initiatives and your podcast, People start to know the basics of good security hygiene. And now we're just moving on to the other weakest links, you know, like you might have a perfect zero vulnerability codebase, but then you have a vulnerable pipeline with GitHub Action that can compromise by accepting, you know, open source contributions, God knows what, you know. So, you mentioned SolarWinds breach, and I know you mentioned that in your talk as well. Could you give us a brief overview of what happened in that particular case? And I think there's some new stuff that's come out recently. Maybe talk about that as well? Sure. Actually, there was an article published by Wired at the beginning of May, so you may wanna look it up. It's called The Untold Story of the Boldest Supply Chain Hack Ever. It's a pretty cool title. So it goes a little bit further than what had been disclosed before. And really, SolarWinds is an American company that's building a software called Orion, amongst other things, that is actually pretty popular amongst U.S. government departments, including U.S. Department of Defense, pretty high-security environments where this network monitoring and management tool is used.

**16:51 Chris Romeo:** Yeah.

**16:53 François Proulx:** And one way that nation-state actors found to infiltrate those high-security networks was actually through this supplier, this company building the software. And they, in this case, did not modify the source code directly. They somehow found a vulnerability into, or found a way to get into the CI environment. and modify, add a DLL, if I remember, it's in the article, that would modify at runtime in the build environment, which I think if it was TeamCity, it's like JetBrains, I think, CI environment. So it would kind of modify the source code that would get built. So if you looked at the file system, you would not necessarily see the malicious code. Yeah. Source code, it would get compiled, and then downstream users of SolarWinds would get a tainted copy. So someone doing forensics, which was done by Mandiant at the time, and Microsoft did the forensics. The article actually goes into disclosing, which was not known before, that even the Justice Department was actually probably one of the first targets, and they omitted to tell it to the FBI. And the FBI later and the NSA learned about the fact that the Justice Department was the first target about 9 months or so before it got into DOD systems. So that was kind of the entry point into the US, and they kind of tested, perfected their method. And The article kind of tells the story of those FBI agents that were really mad to hear on a phone call that the Justice Department withheld a security incident that happened that was exactly the one that they found out leaked further.

**18:56 Chris Romeo:** Okay. So, what are some of the lessons? that we should learn from this? Like, are there, are there things that companies should be doing differently as a result, especially with the new information that's come out from SolarWinds? Like, I didn't, I didn't actually know that. I, I glanced at that article. I didn't read it in depth enough. I should have read it closer, but I didn't realize the DLL connection. Like, that's brilliant to modify a DLL that you could— even if you scanned the text fields of all of the things on that hard drive, You wouldn't have seen any— it wasn't a script or something that I could find an artifact that was doing some action. It's buried in the DLL, which nobody's going to forensically find, at least on a quick pass of looking at it. So, are there any other lessons learned that you would say we could apply to modern companies?

**19:50** Yeah.

**19:52 François Proulx:** I mean, I think the holy grail of supply chain best practices nowadays is through the the SALSA initiative, the S-L-S-A, which stands for, you know, those acronyms, sometimes they have fun with it. I think it's Supply Chain Levels for Software Artifacts, a bit of a mouthful, but that's really where I guess someone who is interested in hardening their supply chain throughout and understanding the threat model of what you should pay attention to at the different stages, like the The source where your source is stored, source code, like source control management, like say GitHub, your CI environment, which, you know, could be GitHub Actions, CircleCI, or other kind of Jenkins server that you may be running yourself. And then where you store the artifacts, maybe your Docker registry, or you publish npm packages, and then later you consume it in a, I guess, Kubernetes cluster nowadays, or Or whatever. So the Salsa framework kind of shows all the ins and outs, like all the input outputs where you should kind of pay attention. And we wrote a series of articles and created attack trees that go in a lot of depth into the different sections of Salsa. And I think, yeah, so this article is published. It's kind of the prelude to the conference talks where we have a focus on sort of the lessons learned of real-world attacks. So I kind of walk through in the conference talk by each part of the Salsa model and giving a real example of an attack that was in the news in recent years. and learning from those mistakes. So you mentioned attack trees. Could you take us through that, especially against SCMs, the effort and then also the results? Sure. So I think, yeah, SCM is— I made a pretty exhaustive attack tree. That one was really focused on GitHub, but it the same research could be applied to other SCMs. In fact, it is open source. We used an attack tree tool called Decidius.

**22:22 Chris Romeo:** Okay.

**22:23 François Proulx:** Which is a pretty cool little tool that I kind of like because it uses sort of a markdown format, like just text-based format, and it creates the graph viz, like all the nodes balance automatically. It's just very efficient to write attack trees. So, yeah, I think, let's say, I would say when it comes to source code, where you want to start is with branch protection. So, if the source code repo where you store your most critical source code is not even using branch protection, that's really where you want to start, because that's the cornerstone of ensuring that the default branch, like main branch, master branch, that is used to build the source code that goes into production has been reviewed. So this enforces that there's been peer review and potentially, like, static code analysis that is performed before it gets merged. So that's really the cornerstone of anything in supply chain is branch protection. After that, there's all sorts of tricks and, like, weaknesses in the configuration of GitHub, which is highly complex, has all sorts of knobs everywhere that you can on and off. Like, one of the, I would say, it's a little less well-known thing. There's a thing called tag protection even. So, we know sometimes you might, like, merge to main, and then later you say, okay, I'm gonna trust, like, version 1.2.3 with semantic version. So you apply a tag, right? So, but even if you have branch protection, but you don't have tag protection, by default, anyone with write access to the repo can write a tag and potentially even overwrite an existing tag. So if in your CI, you're like, oh, I'm going to pull the latest 1.2.3, it could be overwritten. The commit where that, this tag points to could be changed. So that's, you know, something you might want to look at, like tag protection. And in fact, one thing I disclosed recently, there was a responsible disclosure that we did as part of research last— this spring on the Terraform modules, where Terraform, if you notice, the infrastructure as code system, they have the concept of modules, and those modules are tagged. So when they're in the registry, really all it means is that it has a Git tag in GitHub. And if someone can modify that tag, it actually modifies the module. And I was able to demonstrate that there were thousands of modules that were vulnerable to Pwn requests. So it's like in GitHub Action, you're going to have kind of vulnerabilities that you can, through open source, let's say, You have a public repo fork, and you can submit open-source contributions. With that vulnerable GitHub Action, you can effectively override that tag and compromise the Terraform module, for instance.

**25:35 Chris Romeo:** So continuing on the ATT&CK tree perspective, I'm going to kind of shift in a little bit of a different direction for a minute, just because you mentioned Brooke and being your threat modeling So, ATT&CK trees versus threat models. What are the compare and contrast for me? Because I'm somebody, I've not yet used ATT&CK trees very much. I've looked at them a few times and they look like they'd be very powerful, but I haven't yet grasped how to bring them together. So, compare and contrast those 2 things for me. Are they the same or are they different?

**26:14 François Proulx:** No, I think it's complementary. I think that one, someone with like that has a mature AppSec program should not use only one or the other. It's like really they complement each other. It actually is just from a different perspective, a different angle, and it kind of maybe helps you get into a little bit more of a structured, very systematic approach of red versus blue, kind of like, here's an attack, here's the defense. Yeah, in threat modeling, you would also have that perspective, but I think the ATT&CK tree is really a visual way. Maybe it's a bit more lightweight instead of maybe a threat model that goes into more verbose, maybe like a longer document. Yeah, you might have, you know, your DFDs and diagram and kind of look at it from different perspective. But just the attack tree is just a way to visualize just the sequence of one attack versus another defense. Okay. And then, yeah, but even if there is this defense, there is this other subattack. And so it's really more the going down the chain of potential weaknesses that One small weakness is the crack that leads to the other one and down the path to the ultimate goal of, you know, getting what you want, the crown jewel at the end. So, I just see that as complementary to any other threat modeling activity.

**27:50 Chris Romeo:** Okay. Thanks. Yeah, that was helpful to kind of, as I'm trying to move in the direction of attack trees, that's very helpful to get. I'm trying to get different people's perspectives and share those perspectives with the rest of the world. So, Salsa. I wanna boil this thing down because I guess one of the challenges I've had in trying to grasp Salsa, I guess today everything's about me trying to grasp things, is like, as a developer, let me give you a scenario. I'm a developer in a small startup, part of a 5-person engineering team, What do I use SALSA for? Is SALSA even for me? Does it provide any benefit to me, or is this something that only works for enterprises? Or, like, how does it change my life as a developer in a small startup?

**28:38 François Proulx:** I mean, in theory, SALSA, what it stands for is software level— supply chain levels for a software artifact. So, the idea of the word level in it is really kind of a maturity model, like, where you have different stages of maturity. So, if you stick to that for a moment, yeah, it's quite more like enterprise-grade, like something really mature, like complex setup because when you get to level 4, it requires to get everything perfect. And it's, I think to my knowledge, even those who wrote the model, they even, they have, they struggle to get to SASE level 4. In their own— in fact, it's originally pioneered by Google. So they kind of brought that to the Open Source Security Foundation, and they themselves internally at Google. I mean, I have friends at Google who came to my talk and said, hey, thank you for this talk, because internally, we have some teams that would get some ideas from your talk. So, I think, yeah, to get to that level of maturity, it's tough, but there are low-hanging fruits at level 1. Again, like this kind of branch protections, really just to enforce that there is code review. If there's no code review or no enforcement of it, then you don't know what you're running in production. And then, you know, kind of the software bill of material, SBOM. So if you don't know what you're intaking and what other dependencies you have in your package, especially those transitive dependencies, you know, downstream, the dependency of the other dependency and down the rabbit hole, you don't know what you're running in production. So at the very least, have all those tools, which are, many are open source, easy to run, even for small startups, to have that inventory and some basic assurance of what you have. And then if something goes wrong, at the very least, you can kind of come back to a Git commit that you're pretty sure is that one that originated the thing. And maybe you can kind of look at what went wrong, because then you can look at your CI environment in even like basic ways and just like access control, you know, very basic information security principle, like least privilege and things like that. Should everyone on the team have access to modify the configuration of CI environment? Probably not. And just reduce the number of people who have high-power access. Say, you know, take GitHub, for instance. There is the concept of a member of an organization and organization owner. How many organization owners should you have? Probably more than one, because that guy is on vacation, you don't want to be stuck. But you probably don't want to have tens, you know, dozens of organization owners because this is a high-power credential, which can basically modify anything, including disable branch protection. So yeah, I think it's just your normal information security hygiene, just common-sense things at level 1. And then later, where it gets more complex, is to really Make it tamper-proof, like tamper-evident, where you add the cryptographic signature at every step of the way. And then when you consume the artifact in production, you're sure of where it originated. And if something goes wrong, the forensics is easier.

**32:19 Chris Romeo:** You just made me think of something else when you said cryptographic. So, let me bounce this idea off you. I have this idea for what I think needs to happen. to solve a piece of the software supply chain problem. But I don't know if I'm just grasping at straws. I'm trying to find the right English idiom to describe. I don't know if this is a good idea or not, or if this would work, but let me give you this idea. So I look at Let's Encrypt and I look at what Let's Encrypt has done for the world of web server certificates. Nobody— everybody has certificates now. Like, you see no sites using HTTP anymore. And I attribute a lot of that to the fact that Let's Encrypt made it simple. They made it available. They made it free for everybody so that we don't even really worry about that problem anymore. Like, of all the things, like you said, we've made some progress in AppSec. Like, this is— there's an example of progress.

**33:18 François Proulx:** Yeah.

**33:19 Chris Romeo:** Could we or should we create the same thing for the software supply chain? Why is there not a Let's Encrypt version for packages where it makes signature and provenance and all of those things for supply chain packages just as easy as it is for my web app certificates that I use today? Like, is that even a reasonable idea?

**33:46** Yeah.

**33:47 François Proulx:** And I think that's exactly what Uh, they, uh, the people behind Cosign, uh, if you're familiar with the Sigstore project, which is sort of a sister project to Salsa and OpenSSL and all those things, um, one key thing that they brought— key, just to use the word key here in the context of cryptography— uh, um, is, uh, the concept of keyless, uh, signature. So, uh, in most modern build environments like GitHub Action, CircleCI, or other Travis, whatnot. I would say in the past 18 months or so, so fairly recently, most of those added the concept of OpenID Connect. They use, you know, OpenID Connect, which was used like in more like authentication scenarios, but built into the CI environment so that when the job, the CI, build runs, it has its own authentication. So, it has like an ephemeral token to prove that it is the virtual machine that ran the build steps and can cryptographically prove that it is coming from a virtual machine that is in Microsoft Azure environment through this OpenID Connect token. which is sort of provided that, like, from the sky, as in the case of GitHub Action, as the GitHub_TOKEN environment variable or secret. Other environments have something similar. And the beauty of that is that once the virtual machine or the build environment can prove an identity, ephemeral identity, and then later you can say, hey, you know, at 3:00 AM, on a Sunday, there was a virtual machine in Azure which builds something, and then you can use it with CoSign, for instance, to actually sign. So it's like the keyless signature. So it's very similar to what she said, like for Let's Encrypt, it's like you don't need to manage private keys because, you know, private keys are dangerous. Like, you don't want them on your laptop. But the same thing here, you don't want to just have like a private key that you sort of grab from somewhere. Like, they should have a KMS where they keep the private key outside of the boundary of your build environment, and you just obtain a token which is already signed, and then CodeSign has a way to use it to sign the actual artifact using that ephemeral token. So, I think that is the answer to the equivalent of Let's Encrypt for build systems. And there are things like, very similar to, again, like Let's Encrypt, like certificate transparency logs. Exactly the same kind of technology is applied with other projects where you can optionally push a transparency log where the hash of some artifact being built in a certain environment can be provably, like, put in the public. Like, you can turn to those transparency log systems and confirm that there really was a hash which was added to that Merkle tree at 3:00 AM on a Sunday. And it's not just your, like, here's a hash, like, okay, yeah, where is that from? You know? So, a lot of great strategies. Are there some other things that you could recommend for developers and organizations that they could adopt to prevent supply chain attacks? There are so many things. Like, when you start to go down that rabbit hole, you know, it keeps me up at night. But I think, you know, when you start by understanding your dependency tree, I mean, first, like one simple thing that I would hope that most of your listeners are already doing, if they're not, stop the podcast and go do that, is dependency, like package manager lock files. So like, you know, you may have like package.json at the root of your project, you define your dependencies, but if you don't have a lock file, like, you may be defining, okay, OpenSSL version 2.3.3, but that is just like a label. It's just like a semantic version. You need to have a cryptographic hash to ensure that it's really the version of OpenSSL that you expect to be downloading from the CDN, from you know, npm, and not just, like, you know, at any moment, something, someone can override, like, override the version that is stored in npm. You should be able to assert that it's the hash you expect. So, that's, you know, using the lock file. And that comes back to what I mentioned before with the Terraform modules. One key thing that Terraform does with providers, if people are familiar with Terraform and providers, it has a lock file, but not for modules. And that's the key takeaway of this research is that you don't have the same level of protection to guarantee that the module you're running in Terraform is the one you really expect. So there are some, let's say, open issues in GitHub in Terraform that's been open for a number of years. to convince HashiCorp to add the same level of protection as is provided for providers to modules. Very cool.

**39:46 Chris Romeo:** Well, François, we're coming to the end of our conversation, and I want to give you the opportunity to share a key takeaway, a call to action. You know, is there something that you want our listeners to do as a result of our conversation? or a last thought you want to leave them with, let them have it.

**40:05 François Proulx:** Yeah, there are all sorts of great initiatives. If you just look for OpenSSF, it's a great place to start. Look at pretty much any project they're working on, such as the Scorecard project, for instance. It's a way to get just a security posture of your repo. If it's a public repo, you can literally Click, and maybe they've already actually ran, so, the security posture on your repo. You can look at deps.dev, D-E-P-S dot D-E-V. It's a Google-managed service. They actually scan, you know, open-source repos and run the scorecard on those open-source projects and keep the security posture archived there. So, if you kind of, you know, you're like, ah, I'm about to add this dependency. Some developer on the team is, say, how about we add this little JavaScript thing? You can look at dev.dev, look at their reputation. Is it something that was created, like, you know, 2 weeks ago, or it's, like, 5 years old with hundreds of contributors? It's still maintained, you know, they have branch protection, all those good things. And it's just a very quick sniff test for adding a new dependency, for instance.

**41:22 Chris Romeo:** Very good. Well, Francois, thank you for sharing this knowledge with us. And I know I learned a couple of new things and a few things I need to go dig into deeper, like attack trees. And I want to look at your example with the SCMs in more depth. And you helped us to understand Salsa better. That's one I'd been struggling with and gave me some pointers for my Let's Encrypt for third party or for software packages. So I got a lot of homework coming out of this. That's not supposed to happen. I'm supposed to be the one that's giving out the homework. But you gave me a lot of things to think about. So, thanks for sharing with us, and we look forward to a future conversation with you about something related to AppSec.

**42:01 François Proulx:** Thank you.

---

Source: https://appsecpodcast.com/francois-proulx-actionable-software-supply-chain-security/