Continuous Delivery Foundation CDF - Online Meetups, 18 Apr 2023

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Adding Open-Source Security Tooling to your DevOps Pipeline - a CDFOnline Meetup, April 2023

Description

With the recent 'security awakening' new supply chain tooling is available to harden the DevOps Pipeline. Learn from Steve Taylor, CTO of DeployHub and CDF TOC Board Member, what tools go where. He will explore 5 phases of the pipeline where scanning, signing, SBOMs, and cataloging can be added to evolve your DevOps Pipeline into a DevSecOps Pipeline.

A

B

Thank you all for joining the uh either you joined us through the ortelius Meetup group or the CDF online uh Meetup Group. uh Thank you for uh coming on board and uh your interest in continuous delivery and how to secure your your software supply chain. This is becoming more and more of a topic, so it seemed like a a a good and relevant topic for an online Meetup to start really having a discussion about what kind of tools we should be adding into the CD pipeline.

B

I am Tracy. Reagan I have been hosting these meetups now for a few years. uh Thank you to the CD foundation for trusting me to pull these things off. This is being recorded and will be pushed out to um the city, CDF Community, as well as anybody who has joined these meetups uh today. I am happy to introduce Steve Taylor. He is the full disclosure he is our um our deploy.

B

Hub CTO he's also on the board of the technology oversight committee for the CD foundation and has done some work around some open source projects, including ortilius. He is pretty much the senior contributor to that and a project pushed by jfrog called Persia he's also done some work around stream, nine for the open ssf, which has to do with consuming s-bomb data.

B

So he has some experience and background in software security on that Steve I am going to take myself off of the um the video and mute myself and I'm going to hand it over to you.

A

Thank you. So, let's get started here.

A

That's right: there we go so we'll just kind of level set some of the stuff that has been happening in the past uh couple of years.

A

um The amount of attacks that we've been getting uh through the supply chain have been growing tremendously. The hackers have figured out the supply chain is the easy way to get their their malicious code into the process and distributed for them out to the all the end users.

A

So we've had this huge increase of seven times uh higher than we've seen in the past um and as a result, the boards of the companies uh are and like the CEOs, the c-level execs are considering uh cyber security, uh a larger business risk, um so they're putting more focus on security.

A

um Just because you know it can make such a a huge impact when your company is taken out of uh you know, blown out of the water for a week or so when you're trying to recover, even though Disaster Recovery plans are in place um still a huge loss of Revenue on that front, so they're really focusing on that level uh to make sure that cyber security is addressed and then, uh lastly, uh application teams and companies are really wanting to see more visibility into the application. Level uh security.

A

uh There are things where uh you know we have the at the edge. um You know our incoming routers and stuff like that are able to able to handle some like denial of service attacks and things like that. But that's just part of it.

A

um What you really need be able to do is see what's happening at the application Level to see where your vulnerabilities are.

A

So when we think talk about application security, um we need to look at our devops pipeline and our devops pipeline has basically um four to five different areas that you can start addressing. Your security um changes to one is actually at the uh the code and we'll go into each one of these in detail. I'll just give a highlight here, so the first stage is like the coding and the pre-build side.

A

um So that's where the developers are actually doing their work, then you have the build, which is creating your artifacts and making sure that you are doing that level of automation at the build level and then there's a post build piece depending on upon your build tool and your development language that you're using you may need a post build step for application security, and then you have your publish, which is where you actually are.

A

You know pushing out your artifacts to be consumed, some sort of registry or release process at that level, and then finally, we have our audit. um You know when we go through an audit everything how that takes, what we're going to do with the data that we uh We Gather at that level. So we'll look at all these different stages here and we'll dive into our phase, one coding in pre-build.

A

So when we think about uh adding uh security steps to um our coding and our and our pre-build uh when I talk about pre-build, this is like. When you do your git commit. uh You want to make sure that you have a code signing uh enabled so get. You can enable um two things, uh there's a signing piece and then there's a signature piece.

A

So the signing piece is where you actually use a key to sign your commit, and then you can associate your key to your like your GitHub repo or your uh you get lab repo and then it'll give you like this verified tag for your commit. So that's one of the first things that you want to be able to do is generate um your basically your signing key and then make sure that git is configured to go ahead and do all of the signing for every every change that you make.

A

The next part is signatures, signatures, saying signed off by Steve Taylor, for example, and that's just another level to say that I've I've actually done um this is this is what I really wanted to do and I signed off on it?

A

The next part we have is code scanning tools that happen at the the the code and pre-build level. uh The the co-skating tools are going to be. uh You have your SCA code scanning tools, so software composition, analysis, um Vera code, sonar Cube um there. Those are type of of tools, that'll, look at the how your source code is put together and determine, if there's any vulnerabilities uh at that level. uh Next, we have a repository scanning tools, code, ql, trivia, dependabot frogbot.

A

Those are actually looking at your repository looking for Secrets. Looking for how your workflows are structured, um those basic type of uh dependency analysis uh if you're looking at like. If you have a node.js program, it's going to look at your package.json to see if you're on the the latest version of a package uh same thing with um like Ross Ross.

A

Has this cargo uh toml file that you need to look at dependencies for so all the different languages are going to have some sort of files that are at the repository level that are going to be viewed and reviewed by these repository scanner scanning tools.

A

um You know if you want a full list, uh go out to oasp and check out what they have for those tools, also, if you're a GitHub user. If you go to the security tab for a repository, you can turn on and off things like trivia code. Ql depend about those are all configurable right from your repository there. So it's pretty easy to get up and going so. The next phase we're going to go into is our build phase. So this is where we're actually going to gen uh create our our um our artifact.

A

So we're actually going to start. um You know doing compiles packaging uh things at that level. So one of the things that happened at the build phase that we need to address from a security standpoint is, we want to make sure we're we're generating s-bomb.

A

um So some tools to really take a look at especially if you're using uh Docker uh APCO appco, is like a replacement to app get and some of the packaging management tools.

A

um Basically, appco is focused around building from source and getting you a clean artifact that uh at that level, appco can also produce a an s-bomb. So your software build material is generated actually at build Time same thing. With the build X um you when you run build X, you can tell it to generate and ask Mom at the the creation time. Other things we want to do at the build phase is we want to make sure we're signing. We want to assign our artifacts, so Sig store has a tool called code.

A

Cosine, notary 2 has a tool so those things we want to make sure that are being done. So we want to build um as in build our code, generate the s-bomb at build time and then make sure that it's signed now things like build ax and Sig store. These tools will work hand in hand. So the when you do the build X it'll actually generate the s-bomb and the signature. At the same time, other things we want to make sure that we're doing is at the build phase.

A

Is we're not doing this on our own computer by just say like doing a uh npm uh package? For example, uh we want to make sure that it's being done on a hosted, build system, so you have Google cloud build. You have the GitHub. You have git lab uh tecton Jenkins. You want to make sure that it's being done on a a build system and that build system is actually locked down.

A

So there's another phase that you can get into um where you can make sure like with tecton uh titanium, has something called chains, tecton chains that will report everything. That's happened during the workflow or the build process and give you like a log of exactly where things came from. So you know they have a secure build system.

A

Now. What will happen is if we do not, if we're not able to do a an s-bomb at the build phase, we need to add in a secondary uh step into our pipeline, uh and this is where the artifacts are are actually produced at the build build phase, but the build tool wasn't able to produce the the s-bomb natively so because of that, we have to go ahead and do a second step where we actually generate the s-bomb based on the artifact from the previous one.

A

So there's there's tools out there like Encore sift Microsoft has s-bomb tool. The open ssf has spdx. Now these s-bombs are going to come in two formats and they're for the most part, pre-interchangeable, there's Cyclone, DX and spdx.

A

Those are two different um I want to say they kind of are competing uh formats uh of your s-bomb, but basically in the software build material. It's going to list all of your dependencies that your artifact is dependent upon. Now, one of the things I haven't seen yet uh in these s-bomb tools is actually reporting the source code that was used at build time.

A

What ends up happening is it'll report upon uh package dependencies so dependencies that you have from a package to package level, but right now they haven't been generating at the very first level saying you know, I just built this artifact, here's a list of all the source code, all the hashes for every single piece of source code that went in to create this artifact. So it's one of those um they haven't quite got there. Yet the s-bomb formats supported, but the tools just haven't been rolled out.

A

Yet to do that and the reason why that's important is when you look at your vulnerabilities, you want to make sure that you may have a vulnerability in in this one file in your code base and that's where the vulnerability exists and we want to be able to track back to the actual commit that could have introduced. That vulnerability.

A

uh For example, like maybe there's a regular expression uh that is, enables a denial service attack uh type of thing, and you want to be able to get back to that exact source code and that commit where that was introduced. So the s-bombs are evolving um at this level. We are when we're talking post, build uh we're mainly going to get a package. The package type of s-bomb created.

A

On our next phase, uh we're actually going to do our publishing, um so we've created our artifact, um whether it's a Docker image, a jar file, War file- uh you know, we've done our we're going to do our our release now, so we're going to release our artifact out to um a location that it can be consumed.

A

So the when we do a publish, if we're talking Docker images, um we're going to push those out to oci Registries, so like artifact, hob, Docker, Hub Quay are just a few of the oci Registries that are out there. You may also have internal uh oci registries. You know all the cloud vendors have them so Google as there's the GCR um uh Azure has one you know. Basically, AWS has their their registry, so it doesn't really matter where it's going to end up.

A

But what we want to make sure of is that when it gets there, we want to go ahead and scan again, um anything that was published out to the uh the Registries and the reason why we do this. um This secondary scan is in case. The build pipeline is not doing the vulnerability rescan at the build or at the post, build step. So we want to make sure that we um we do that scan at that level, and also one of the things I've seen is different tools will find different vulnerabilities at different times.

A

So some of the scanning tools will work really well and we'll find um a vulnerability like at build time um like the code. Ql and trivia will find things at build time or post build time, but after it gets out to Docker Hub. uh The vulnerability may show up um two days uh later, that we have no new vulnerability that we're not catching at the build time. So it's these things that we have to constantly keep running and keeping track of and keeping an eye on um throughout the process.

A

Because one of the things with um securing your your pipeline and your your supply chain is, you have to constantly do it. You just can't. Do it once and say: okay I've done it I've done my security scan at the the code level we're all good, um but because these things, because we have vulnerabilities popping up every day, we need to be constantly looking over our code base and our artifacts that we've created now. One of the things that will will happen is the cve side, the vulnerability side.

A

They will get published to different repositories at different times depending upon the language. So um we have things like nist, miter openssf has the osv dev, which is kind of like a aggregation, um cve details, GitHub advisories, so all these different locations we have to go and check to see if a new vulnerability uh has been found, and that's one of the things that we want to keep an eye on is um is making sure that our our that we're checking or cross-referencing those databases on a daily basis.

A

So, finally, we get to our our pipeline audit, and one of the things that we want to do at this level is to actually audit what we did from our developer check-in all the way out through all the different stages. So when we did our our code check-in, uh then we did our build. Then we did our post build. Then we did our publish and we did our release. We want to make sure we're auditing. All of that, and one of the things in the supply chain process is we want to.

A

We want to audit the supply chain itself to see if there's anywhere that things could have been introduced when we went from our build phase to our publish, were there any new dependencies that were introduced, that we weren't expecting so did somebody hack the the supply chain itself? This is where the audit process comes into play and there's the Jenkins Auto Trail techton chains are just a couple examples of auditing the pipeline itself.

A

So just kind of review when we go through and do our publishing one of the things when we publish is, we want to pull together all the information that we have, so we want to make it basically a giant cross-reference of the data that we've gathered from the developer check-in all the way out to the release.

A

So some of the things that we want to try to pull out of each step in our pipeline is the the s-bomb, and then we want to take the s-bomb in cross reference that with the cve and then we want to make sure that when we do a release, we have that release being audited and any cves attached to that addressed, and then we want to keep track of what's happening at the the changes. You know what changes were actually done for from the developer, all the way out now.

A

One of the things we need to do is when we look at this from a microservices point of view, is we have all these repositories scattered about? So a typical microservice application?

A

Is these days is around 200 microservices, so we have um basically 200 workflows or Supply chains that we need to Monitor and then aggregate that information up into our logical application. View and then we want to be able to look at it from the The Logical application and see where things are are falling over. Where which parts of our code base are are could have vulnerabilities that could be attacked.

A

And then we need to make sure we address those if we focus things on just at the low level we'll be able to track it, but it's much harder to figure out what's running where what's running and which microservice version is running in development versus one which version of the same services in QA and production. So we have to look at this from the high level perspective of pulling together and aggregating all the data up to a logical application viewpoint.

A

So that's where um the open source project that I work with ortilius it'll hook in and grab for each one of those microservices the data that we want and do that aggregation up to uh the app logical application view. Now that gives us uh information that we can really utilize.

A

We can, you know, be able to say for this application that's running in production. uh This is all the actual data that we need to look at. So these are the new cves that popped up, that we have to address within the last couple hours and then we can then go through and say: oh microservers, a is the one that's giving us problem. Let's go focus on that all the the other 199 are good for today.

A

So what this allows us to do is really give us uh that Federated Insight across all of our applications and all the Clusters.

A

um As part of that you can, you know, answer questions like where's log4j running you know: do we have which services are are using these vulnerabilities um and being able to really pinpoint- and you know in a few keystrokes um what is going on where and what needs to be addressed at that level. This this really helps developers manage drift, uh see what's happening between the different environments, and you know address things uh quicker.

A

It's a it's amazing on how much time you can spend just chasing cves and fixes, uh even though the fix may be just as simple as bumping to the uh you know, this version to the latest, one uh knowing which ones have to be you know addressed and when uh really cuts down the amount of time on the development side, uh and then also it gives you the the point of view of you know: microservice a was the one that had the vulnerability.

A

We just fixed that now we should just be able to test the the test microservice a instead of having to retest all 200 uh services so uh drastically cutting down on our our time to uh production at that level, foreign.

A

We want to be able to look at uh the whole supply chain, uh aggregate that together.

A

um This is where we'll be able to bring in um you know the detect on chains, uh the Jenkins audit Trail, and give you that visibility of what's Happening uh in your application, Level uh security.

A

So all of this will happen on an automated uh level. So the way we introduce artillius into the pipeline is at the build stage and then at the published stage or the release stage, it could go either place. But basically, when you, uh when you generate your ass bomb, we have a process, basically ortalia CLI, that allow us to capture that that s-bomb Associated to the git commit of the source code and then be able to track that as it moves through that version of the of your microservice or your artifact moves through the pipeline.

A

So when it gets deployed and released out to production, that's where we make a second call out to artillius to say: I just deployed this service. This version out to this this cluster, for example, and now I, know what's running where the S associated s-bomb with it all the supply chain. Information is aggregated to um that version of that service and then aggregate it up to the logical application view.

A

So what we're doing is we're gathering together all the moving pieces and persisting them, making a version of them to make sure that when we need to to track something down, we have the information right at our fingertips.

A

So now that we have our data, let's do something with it. So one of the things that we're going to be able to do is uh with artillius is centralize all of your devops and all your security and and software composition into one place. Give you that uh view of what your open source footprint looks like across the organization.

A

uh If we, if we have microservices involved, how is each microservice put together and how is that microservers relating to other microservices and to the application View, and then we can look at the impact you know. Like I said we have a package vulnerability, um we can look at it from the microserver side or the you know, going from I know that this service um has a vulnerability. What are all the lot, what are all the application teams using it?

A

So, if I fix this vulnerability, who do I have to tell to go fix and retest uh their their logical application or from the other side? um How does the the security footprint look like from this application? Are we are? Do we get the greens, you know the thumbs up.

A

Everything is coming up green or do we have vulnerabilities that we need to address and what is the the level of risk that we that we're exposed to um then also we can, you know, track at the The Logical application view um what's happening in development versus production and all those stages in between um is Qi does QA have house QA, looking or uat, um because of that we can version that logical application view across the different stages of the pipeline and give you that that print that look in between what's running in production, what's in QA and see if things are getting fixed and how things are moving across the pipeline.

A

And finally, when we talk about microservices, um you know, like I, said typical microservice applications getting around 200 100 to 200 microservices. How does that uh affect all the Clusters that we have running? What we're seeing is you know production.

A

Is that one single big cluster these days, um but it's many clusters spread out across different regions of the world uh that we need to keep track of what's running in each cluster compared to uh you know like a a blue green deployment, or uh you know a a tiered deployment where we're going to go hit. Maybe uh the states at three o'clock in the morning I see how things happen and then we're gonna run out roll it out to the UK uh the next day.

A

Type of thing so we'll be able to track what's happening in each level uh across that and give you that that uh view of how your securities uh and supply chain looks at that point,.

A

So here's just an example of one of the uh uh and a microservice environment uh and looking at a version of a component is what we call them so basically an artifact that we've created all of the dependencies that are in it from the s-bomb level and then the corresponding uh vulnerabilities. So it makes it an easy dashboard to take a look at where you stand. uh Vulnerability, wise.

A

And then again you know who's using log4j. uh Basically, it's a search box. You say I want to find out who's using uh this package and we're able to give you the component, that's consuming it and then the application that's being affected by it. So that gives you that that quick, Deep dive uh to answer that question who's using what.

A

So we have uh some exciting uh new architectural changes coming through for artillius. uh One of the things that we're actually going to be doing is uh utilizing a blockchain, so The xrpl Ledger uh to track historically um the immutable data uh that we're Gathering.

A

So all the package dependencies the application dependencies, uh the cves, the s-bombs, all that information is going to be pushed through uh on a Rango database that we're going to use for caching we're going to persist that information in the blockchain, uh the basically The blockchain Ledger, and then also we're going to persist the data over in nft storage. The reason why we're doing this is the amount of data that gets generated from your your supply chain process is huge. We were talking to one of the the lead project managers over at Encore.

A

They were just keeping track of the um the verified, Docker images on Docker Hub and they ran their s-bomb tool against those images for two weeks and they ended up getting three gig worth of of s-bomb data. So we're going to be using this process to normalize data and do some efficient storage and be able to make it easy for folks to be able to find things and keep track of what's Happening, where in an immutable fashion,.

A

So if we look at uh the um the open source side of uh the security landscape um again, this is just the open source side. There's many other. um You know regular vendors out there, but if we're looking at the the code and uh pre-build, uh there are open source tools from verico. It's on our Cube, the repository scanning, um the code ql truvy uh depend about those are already part of just need to turn them on in GitHub the build side.

A

uh When you go ahead and do the artifact generation uh APCO in build X now both of these, especially in the APCO side, you need to do a little work because it actually changes up how you do your packaging, so that is going to be actually a a change in your package manager to utilize that uh build X will work with a a basic Docker file, but there are some extra bells and whistle. If you go ahead and change up the the way you um do, your Docker images, you do build them.

A

You can get some more benefits from both those tools: the hosted build systems. Obviously all the cloud providers GitHub gitlab techton. Some of them are going to have like tecton. It's gonna have tecton chains. That's going to give you the ability to to audit the the supply chain process.

A

uh Github actions I, haven't seen anything yet on that front um and I believe Google Cloud build is starting to introduce some more and more like supply chain, uh immutable supply chain auditing around that the signing side and attribution Providence um the signing side of six store, which is cosine notary, twos coming out. uh There's other tools out there like I uh to do I to dodos is another part of uh attribution and Providence.

A

um So there's those are some of the tools you want to look at from uh the signing and attribution Side, Package verification, uh the Persia project, uh which is a build consensus process. So you actually build the open source projects on four different five different nodes and compare that they all came up with the the same result.

A

Making sure that you didn't have a supply chain hack, then post build we're going to have um the s-bomb generation tools that are going to look at the artifacts, so sift spdx, Microsoft's s-bomb, there's a couple other tools out there, depending upon your language, that your your coding in we'll have the different posts, build s-bomb tools, and then we, when we publish, we want to make sure that we're publishing over to a registry that's being scanned as well.

A

So like Docker Hub has their scanning artifact hob for your home charts Quaid does scanning Maven Central the mpm world, Pi Pi. All those Registries have some sort of scanning uh happening at the publish level to see where you stand for the CVS and finally, the evidence catalog that pulls all of this information together uh is where artillius lies.

A

So if you're interested in artillius, uh please uh join us we're part of the uh the CD Foundation, uh you can go to artillius.io or you can go to thecd.foundation uh and you can find us there. um Like I said we have some exciting work going on.

A

We have a new project that we're just starting up around The blockchain Ledger, uh the ipfs and the nft storage, um and we're also pulling in uh additional oci Registries as part of the data storage that we're going to be utilizing uh as as a side, uh project or side option to the nft storage.

A

um So we are looking for more contributors to dive in um we. If you go out to the CD Foundation, they have a calendar and you'll be able to find the artillius meetings out there. There's the general meeting we just had one this morning, and then we have an architecture and Outreach meeting that will be happening next week.

A

So, like I said, come out and join us. uh If you have any questions, let's go ahead and open it up. um I believe there's the Q a that we have enabled for this webinar.

A

um So if you have any questions, drop them on the Q a um or like I said, if you go out to the Discord channel here, you can go ahead and reach us on our Discord and ask questions out there as well.

B

And yeah everybody is uh unmuted, so you can just ask a question or put it in the Q. A I do have one question um when, when the open ssf is also or the Google salsa project in the phases, does it just primarily deal with the build phase.

A

uh That is the main area that salsa is trying to address so there's if, depending on which version of the salsa that you look at there's one.

A

That I think has like eight different areas that you can attack or or are part of the attack, plane and I, believe they simplified it down the four or five uh in the new version of salsa um and what that is highlighting is um places that you can introduce um malicious code into uh as part of the build process so like, for example, if I do a git, if I do a get clone and I check out the code and then I do my build in between that those two steps, if my supply chain is, if, if my workflow is not secure, I can introduce a vulnerability in there.

A

So I could actually do a uh like a curl command and go fetch some malicious code and put it into the build directory. So there's processes and things that they do at that level to ensure that there's nothing being introduced uh into the salsa framework there. But.

B

It's the sauce is just a recommended framework. It doesn't really specify the tools or how to get it done. Is that correct, correct.

A

It just says this is: we know this is how you can hack it and here's some recommendations on how we're trying to fix it.

B

So the projects like Persia doing the package verification um helps get you to those salsa levels, because you are addressing those gaps. Correct.

A

Okay, so like one of the things so in the Persia project, where it's a build consensus, Network, um if you have five five build nodes, they all check out the same code and then one of the nodes is compromise. Where you go ahead and introduce um some malicious code, what will end up happening is that one node out of the five will come up with a different result and because it it comes up with a different result than the other four that result from that build node uh is basically thrown away.

B

A

And the same thing happens like with the the the signing, uh those those aspects of it. So when you build your code and you you sign it um and then you do your release, uh you know somebody downloads that release and they go to verify the signature in the signatures, not matching up. That's where you know that that release has been compromised.

A

So that's another. One of the the steps in the to fix salsa is to do um signing as well. I.

B

See well, thank you. uh So much Steve. You gave us a huge amount of information. There there's a lot to do in terms of building up that that devops process to add security, uh but it's well worth it and with the tools I think you've given us, all of which are open source. You can do it at kind of a low cost, but there is a lot of human. The cost of the humans, to put it together, can be uh challenging.

B

There is a project at the CD foundation called CD events that is sort of changing the way we put together our pipelines, allowing them to be more event-based so that you don't have to have all of these pipeline workflows to edit to change to make for every single one, and that may be another thing that folks should think about is moving to an event-based process.

B

I believe that Jenkins is looking at Jenkins and Spinnaker have looked at adding events so that some of the interoperability issues that we've had in the past won't bite us in the future. As we start adding these security tools.

A

Yeah, it's it's amazing. When you look at the amount of work like I said, if you have a microservices project that has 200 repositories um and you want to go turn on dependabot for uh 200 repositories, it's more than a five minute uh effort.

B

A

Know and and turning on just the pen about to make sure you're on the latest release of everything um is, you know really basic I mean it's it's a simple: it's a big win for a simple amount of effort, but when you look at 200 repositories, um it grows your your amount of work grows exponentially and then then the next part is when you actually go find that you have a dependency that needs to be updated. Now you have 200 pull requests, you have to go approve, you know.

A

How do you automate that process and then, once you approve the pull request, how do you get tested all you know.

B

In a microservices environment in particular, that's where you're really it's really starting to explode the complexity um and being able to pull together. The information becomes more and more important.

A

Yeah, when I, when we've been working with artillius and implementing, um you know, supply chain security, um and we only have a about a dozen microservices. That.

A

That process um is, is easy to to implement um and we're able to keep track of it, and we put some automation around it, but you know the the complexity.

A

um Our new version of artillius is going to have about 30 different microservices, um so it's growing uh quickly and keeping track of all those different um areas you have to invest in is quite complicated, because what I'm seeing is in order to secure your supply chain. It's there's about 15 to 20 different um I, won't say necessary tools, but checks you have to do. You have to make sure you have GitHub git commit signing, and then you have to have your signature and then you have to have your um you you're, dependent by trivia.

A

You know, so the list is about 15 different things. You have to do for every single repo to make sure you're you're getting a secure supply chain. So it's it's one of those. uh Take a little bit at a time is what we found just do one one thing at a time and and figure out that process and then keep adding to it, and that's where, like CD events will come into play, which will be nice is I need to add in um another scanning tool.

A

I just go and update it in one place and now the whole event process rolls it out. For me.

B

Right, instead of updating every single pipeline, every single workflow file, yeah.

A

B

Okay, so next uh next month we do have cdcon. Cdcon is in Vancouver May, um 8th and 9th, followed by open ssf days, which is on the 10th, and it was all happening at the same time as open source Summit, which I believe is the 8th through the 11th. So if you're there come find us we'll be hanging out at the CDF Booth ortillas will have a room, um I, don't remember the time and date, but artillius will have a room for a summit. I believe it's on the 8th at noon.

B

So look for that in the schedule and in announcements coming from us see, the events will also have a summit and that will be on the schedule. So if that's something of interest to you, I would uh highly recommend if you're there go to the CD events, project Summit I said like an hour and a half where you can talk about what events will do and how uh how far along the events framework is to getting a version one getting it implemented. So we hope to see you all next month.

B

There will not be a online Meetup next month, because CDF is half their CD. Con is happening so we'll see you all again in June and thank you so much for being here and Steve. Thank you for that excellent review of security tools. Thank.

A

B

A

B