The Software Supply Chain and You: How to Build and Ship More Secure Django Apps w Lisa Tagliaferri

Hi

Speaker 1: everyone, thanks so much for having me today. Today I want to talk about something very exciting, uh software supply chain security. I'm going to be talking about an open source project called Sigstore, which is a developer-first tool that helps to make security a little bit easier for developers. To give you just a little bit of background so you know who I am, as uh I was introduced, I'm Lisa and I've been working at the intersection of community and education and open source for a while. I am currently the head of developer education at Chingar, which is a Software supply chain security startup and we're working to make the uh security more uh default.

Speaker 1: Um And I've been doing a lot of work around building out resources for developers. I also have a few books on Python that are free and open access. Previously I worked in research and higher education and as part of the Digital Humanities Lab at MIT I built quite a few Django apps to support humanities research. And I'm currently also working on the documentation efforts for Sigstore, and that's the project I'm going to be talking about today. So if you find yourself at this uh Your tourist attraction is the gum wall at Pike Place Market in Seattle. You might be chewing gum, you might take your gum out and put it onto the wall, right?

Speaker 1: But maybe you would not take off one of the already chewed gums and put it in your mouth to start chewing on that I think most people would try not to take the risk of getting sick from an unknown bacteria in this chewed gum that they don't they randomly found. They don't know where it came from. They don't know who chewed it before them. However, this is essentially what many developers are doing with software. You're working on a software project, you want to leverage the code that other developers worked on, which is great. Like we want to continue to build upon other people's efforts. But you might not be actually fully investigating all those libraries and all those packages that you've used.

Speaker 1: You might not, maybe you're checking your immediate dependencies, but are you checking the dependencies of those dependencies? Uh say you're a user of software, right, and you're running software in your machine, like are you actually checking to make sure you know the provenance of all that software? This has been a de facto way of kind of working in software and running software for a while, and this is something that I'm also guilty of. But What do we do with this? Like do we actually want to take this software that we don't know where it came from and just start running it in our machine, deploying it, giving it to our users So this is a little diagram of the software supply chain, and vulnerabilities and attacks have been increasing in recent years.

Speaker 1: It's become very important where the the US government uh recently passed a bill in the House that would forbid the Department of Defense from procuring uh software applications that contain a single uh CVE, which is short for common vulnerability or exposure. There's been increased awareness of uh high profile attacks like solar winds code cov log for shell are some of those there's been typosquatting attacks and things like that and attacks and other security issues can can exist all across the software supply chain. So there's the dependencies, there's the code that you're writing, there is the build and deployment and going all the way to the end user. This is a recent report from Sonotype that estimates software supply chain attacks are increasing exponentially year over year.

Speaker 1: And for those of us who are working in the Python space, what's important to keep in mind is that PyPI is growing faster than many other programming language package repositories. So it's very critical for those of us working in this space. And this is also say that the software supply chain is pretty is a pretty recent concept. So what if we take Back the approach to a older, more established industry and think about security in those terms. So say you want to open a new bank account and you get to the bank. What are they going to do to make sure that you are able to open that bank account? They're going to ask you for your ID. The bank is not the the entity that issued you this ID. The ID probably came from your local government

Speaker 1: or a national government, but the bank still accepts this ID. It's because they trust the entity that is giving you that ID. This attests to your identity. There's a root of trust that underlies all of this. Once you open your bank account, uh the bank account number will be part of the database or log or ledger in the older days. And that is what is now tied to your identity. There is this this back-end infrastructure. So there is a way to say that this ID number, the bank account number, and your own who your identity is are all tied together. So when you get new money into your account or you're debiting from your account, you know that it's all coming in and out of the right place.

Speaker 1: Now that you have a bank account, you can get a bank card, you may use a PIN, you might use a signature to issue payment to others. And this signature attests to your identity, and this is all because it's underneath this whole entire root of trust that a few different bodies are all cooperating with. So this is pretty similar to how Sigstore works, which brings identity, your ID, a certificate authority, the governmental body that issued your ID, and a transparency log, which is the bank account database together to enable verification and trust to exist at each step of the software supply chain. So Sigstore has a few different projects underneath it and I'll go through them a little quickly. So there's Cosign which is

Speaker 1: the way that developers can identify themselves and they can sign software and ver and others can verify that those signatures exist Recore is the transparency log, so think about that as the ledger or the database. You could also think about it as like a bulletin board. where people are putting post-its on and other people can inspect those post-its and they'll never they'll never go away. But you'll have to use your own judgment about those, whether those post-its are correct or not Fulcio is the certificate authority and this connects with OpenID Connect tokens, OIDC, so when you authenticate through Google or GitHub or Microsoft, for example. This is like a notary where they are providing you a short-lived key pair that attests that uh all of these things are true at a certain time.

Speaker 1: And then the newest project is GitSign, which allows you to keylessly sign Git commits and you don't need to use GPG keys. So SigStore is working across some parts of the software supply chain to establish this route of trust and make things more transparent so that we could verify claims. and also attest that we are who we say we are. All right, now I'm going to try to do a little demo here, but I'm not sure how this is going to work with those two screens. Let's see. So this um this is a Dango image and the link, and I'll share these slides out on Twitter, but It's basically there's

Speaker 1: Docker file, there's a Docker compose YAML file and the requirements at Txt. I'm going to be using this TTL. sh as an ephemeral Docker registry. And I will copy and paste these. So basically I have I'm already in this directory that has this container in it. I'm building the image and then I'm pushing it, I'm gonna push it to the TTL. sh And the two H tag there is just uh saying is I'll keep it up for two hours.

Speaker 1: And then I will push it And what I'm going to do is I'm going to assign this software artifact. So a software artifact we could think of it as a container container, but it could also be like a binary, it could even be a readme. md file in your GitHub repo or something like that. But basically cosign will assign those, any of those software artifacts. And right now the way to keylessly sign is with this cosine experimental flag, but soon that is going to change. And what we want to do now is to keylessly sign the certificate. Cosign also enables you to use keys, but

Speaker 1: If you don't need to use keys, why bother? And then you log into Sigstore with the OIDC Connect. And you say, yes, I want you to sign it And then it will push the signature to recore, which is the transparency log. Okay, and then the next thing we want to do is to verify that claim. So say Say we're two different people, and we want to see that this uh container was indeed signed, and we could do that again with cosine. And it's the cosine experimental true flag again and cosine verify and we're passing in that

Speaker 1: that container image again. There we go. So what we get back I can make this bigger. What we get back is that The cosine claims are validated. The existence of the claims in the transparency log was verified. And we get a you know, a little bit of a messy JSON file because I didn't make it look pretty. But we also see that there's a an entry that was created at the recore transparency log. This is the entry number. So we could verify that those claims are true. So if you're a software developer and you want to share with other people that like indeed my Django container was signed, then you could share with people though that transparency log or they could look up that container with cosign.

Speaker 1: So that's all great, right? But this doesn't automate anything like that was kind of a manual process. So the good news is that we can in fact do this much more in a much more automated way. And we can do that with GitHub Actions. I'm going to go through this a little quickly because I already have this set up , but I will show you where I am. So I have this repo Oh gosh. So I have this Hello Django image repo and what I want to do is to add my GitHub Actions. Which will look like this.

Speaker 1: And in fact, maybe I will show you the test image. Okay, so this is um We have the same image that we had before, and then we want to add these GitHub actions into here And basically what we're doing is the important parts of this are the ID token and writing, which ties back to the full CEO certificate authority. So this is what is connecting the OIDC to the automated process here. The next thing we're going to do is install Cosine as part of our action

Speaker 1: and we could pin that release to a specific version of Cosine. And finally, what is going to happen is we're going to push this image up to the GitHub repository and build the image and check that it's signed. And so when you go through this process, and I'll give you all the resources you need, and this is my delete a store pull request, but If you go through and check about the signing the container image, you'll get all of this information back that the the tr there was an entry that was posted in the transparency log because this is a public repo that is going to be using the public instance of Recore if you are working in a

Speaker 1: place where you're not you don't want everything to be public, you could also set up your own instance of recore and have that all like all internally if you want instead. So this is the step through of doing this, and I will share with you all the slides. So if you want to go through yourself. And then yeah, so you can confirm keyless signing, and moreover, you could go through this cosign verify again. And here it is my username.

Speaker 1: So here again we see that it was definitely signed. Um we have the fulcillo roots. We could actually make it bigger better looking with that JCUB over here. So it's a little easier to read the JSON. But here it's very clear that we have the log index here, we have the log ID , we have the URL, and all the data here. And this recore is all like uh all based on Merkle trees if you wanna read more about it. And the other thing that we could do is we could use um recourse CLI to verify this too. So we would uh paste in our log index and we could verify it this way as well.

Speaker 1: Oops So we get um we get the data right from recore in this case. So So if you're familiar, PyPI has recently been asking for more security measures in place. So Python I think is really leading the way in making sure that dependencies and libraries are built more securely. This is the Pi PI dashboard as of today for the multi-factor authentication process that they're doing where they're

Speaker 1: A lot of projects are opting in to two-factor on their own. Critical projects are are really opting in and they're moving really quickly. So it's really great news. The other really great news is that Pi PI is working to add more security features all around, not just the multi-factor, but they are also including Artifact signing through Sigstore. And if you would like to learn more about this, I recommend this talk and I have it in the notes of the slide deck, Securing the Open Source Software Supply Chain by Dustin Ingram, which was in a PyCon. In Salt Lake City earlier this year. If you would like to learn more about Sigstore, I co-created this course with the Linux Foundation. It's free to take through

Speaker 1: edX and it goes through all of the things I talked about much more depth than you could play with the tools. And it's free to take on edX if you want the certificate. There's a Linux Foundation fee associated with it And finally, I just want to say that it's up to all of us to make sure that open source software is secure and it's important for making sure that the community is taken care of to start to think about bringing security into the development process and not tagging it in at the end. Thank you.

Speaker 2: Thank you very much, Lisa. If we have any questions, raise your hands. We'll pull the mic out.

Speaker 3: Hi. Um how's the adoption so far? Like would you know do you know like the adoption, like is are a lot of developers Like using it right now?

Speaker 1: Yeah. So six store um some we have a number of indicators, right? So some of the things that we've been tracking have been uh like the stars of repositories. So like Cosine um has t uh 2,600 um stars right now. There's a lot of people who are using it in in different programming language ecosystems. I think it could be more widely adopted and as I mentioned like Pi PI is one of the leaders in the adoption space, but there's a lot of work in the Java community community as well and there is going to be a SigcirCon that's co-located with KubeCon next week at um yeah in Detroit on Tuesday

Speaker 2: Any more questions? Oh, okay, you

Speaker 3: Um is this specifically signing containers or does it sign anything else?

Speaker 1: Yeah, it could sign um any software artifact. It is definitely I think the people who developed it were thinking about container workloads specifically, but I think uh we We allow like signing of binaries and signing of like README files, text files. You could sign basically anything and you could put it into the record transparency log. It's it's a matter of like what how it is that you're packaging your software and how it is that people are consuming your software and I would think about how you would how you would sign it in a way that's meaningful for your for whoever's interacting with it Yeah.

Speaker 2: All right. Any more questions? If not, then thank you very much, Lisa. Small token of appreciation from the organizing committee. One welcome uh uh thank Lyself for a talk.