 be here. Thank you for having us. We have prepared a great workflow presentation for you all today, but first off, just to kind of start on who we are, as Megan said, I'm Thomas. I'm a partner solutions architect at Sneak and then co-percenting with me today. I have Tom Gibson and Ryan Patterson. I'll let them kind of quickly introduce themselves before we start. So hi everyone. My name is Tom Gibson. As Megan and Thomas have said at the stage, I'm a senior staff engineer at CloudSmith. I've been with the company around about two years or so and I work to sort of lead the engineering teams within CloudSmith. I do some of the webinar type stuff we're on today and work to further the engineering roadmap. So nice to be here. Really excited to get going. I'm Ryan Patterson, a senior solutions engineer at CircleCI. I've been with the company about a year and a half. My role just means I get to help teams adopt CI and CDBest practices and allow for rocket ship emoji growth. I love the rocket ship emoji. Thank you, Ryan. Thank you Tom, for being here and co-percenting this with us. For the audience, we've prepared an awesome presentation that shows how we can together help construct a secure software supply chain. But before we jump into the meat of this presentation, the demo, just a little bit about who these three companies are that are coming together. So from the sneak side, we've been around since about 2015, gone through five rounds of funding. We're used to buy over 2.2 million developers worldwide. And our mission is to put into those developers' hands the tools that they need to take security of their applications into their own hands and help turn security into a team exercise that everybody owns. So from the sneak side, we'll be talking about security. And then Cloud Smith. Awesome. Thanks, Tomas. So Cloud Smith founded 2017 in Belfast in Northern Ireland. So you'll have to excuse my accent. So we operate to essentially enable our customers to do continuous packaging. And you'll hear us talk a little bit about this further on in the webinar. But we offer a package delivery network in order to help speed up package downloads, uploads, all that kind of stuff. But our primary mission is ultimately to help people secure their supply chains. We offer universal repositories. So they cover virtually all of the formats that people use today across all of the biggest organizations. You can see some of those on the bottom slide, such as MyOB, Font Awesome, Shopify, a bunch of others as well. It's a 24-7 product. It's SaaS based. It's entirely cloud native. So I'll hand over now to Ryan to talk a little bit about Circle. Thanks, Tom. So at Circle CI, we help high performing teams, all types of industry, different points in their trajectories. And we bring some of these points up really just, we've hundreds of customers, thousands of customers that run millions of builds per day. We've seen it all highly flexible in terms of what things people can do on the platform. So developers come onto Circle CI really to just reduce workflow duration, increase deployment frequency, and reduce mean time to recovery. And put that a, it's a more simple way, deploy more code, get feedback faster, and troubleshoot more quickly. We'll get on to the presentation. Yeah. Thank you, Ryan and Tom. So before we jump into the demonstration, just a real quick overview of what we're going to be showing you today, we're going to cover all these points we've mentioned in the introduction. Continuous everything, right? So this includes integration and delivery, security as well as packaging. We're going to wrap this all into a demo and kind of show you what it all looks like in action. So before we jump into the good stuff, just to walk you over what it is we're going to be showing you without stealing too much thunder from the demonstration. So you've probably, if you've heard about Shifting Left, it's this concept of introducing security testing earlier into the development workflow. So if we think of the lifecycle of an application, it's about testing the application as it gets written. And then also testing it after code is checked into the source control system to ensure that no new vulnerabilities can be introduced. But there's a couple of extra steps that need to happen for an application to go from code and concept to production. And so that's where CircleCI comes in, where a build is triggered to package and get our application deploy ready. So Ryan, can you walk us a little bit about what we're going to be seeing today from a CircleCI perspective? Absolutely. And again, without giving too much away, CircleCI, I guess it's pretty evident, is in the business of continuous integration and delivery. It's right in the name. We can think of that really as just a change validation for developers who are committing code. And good CI enables the business to be more nimble and to meet customer needs faster. What we'll be seeing in the demo today is just how CircleCI is used to coordinate the work that needs to be done as a change passes from early stages when it's triggered to the point where it's ready to get into the hands of customers. And then I'm going to pass it off to Tom to talk a bit more about the Cloudsmit and Continuous Packaging piece. So thanks, Ryan. So yeah, today we're going to be talking a little bit further about Continuous Packaging. We see, in essence, the glue between continuous integration, continuous security, and continuous delivery. So we're going to talk a little bit about repository structure best practices and how you can help mitigate against dependency confusion attacks and focus a little bit on distribution to your teams, services, and customers as well. Beautiful. Thank you all. So again, not to steal too much thunder from the demonstration, but we're going to be showing you how all this fits coherently to ensure that the applications that are being deployed into a production environment, whether it's a containerized application, a serverless function, or an application running on an application server in a VM, we hope to demonstrate some of these security best practices and how you can build workflows where validation happens naturally as part of the workflow. So with that, it is time to tempt the demo gods and let's show all this in action. So starting off with the application, we're going to be demonstrating the application with the coolest name ever that Tom shared with us. This is, we're calling it the Waffle application, more specifically the sturdy waffle. And this is a Python application that, you know, we're going to be running through CircleCI to build. And in that CircleCI workflow, we're going to see how that application, as Ryan mentioned, how that application is taken from concept into a packageable artifact. And this is constructed using a CircleCI config.yaml file. So, Randy, you want to kind of walk over real quick what this config file does and how it translates into instructions for CircleCI? Absolutely. Yeah, so everything we're going to see, again, another sneak peek later in the UI is set up here in source control. It's a config file under the .CircleCI directory that we're looking at. It has the instructions and logic for what to validate or needs to trigger. It's all set up here. So each time CircleCI kicks off work and follows the instructions there. The mandatory piece is you see a job stanza here. And there's also an orb stanza that was above. Orbs will get into. But again, just a little hint, they're great for extensibility and best practices. And then a workflow stanza at the bottom. So we'll dig into what those really are, but those are the main pieces of the config file. And we'll see how it all mirrors into the UI. Yeah, and that's a perfect transition over to the CircleCI UI, where we have our pipelines. So, Ryan, can you just walk us over what it is that we're seeing here? Absolutely. So we are in the CircleCI UI, the all pipelines page. And a pipeline is the full set of workflows and the parameters run when work is triggered into CircleCI. So you can just think of it as that full config file that we just saw with all of the surrounding context. Just on that, actually, sort of can ask a question actually on that. Just what are the best ways and what are the ways in which pipelines can be triggered then? Yeah, excellent question. The pipelines are triggered on any action like a new commit, a tag, a PR through the API. And there's also a button in the UI to be able to trigger those. In a sneak peek, you can also look for additional native triggers that are coming up in the coming quarters as well. Awesome. And then, Tom, do you want to jump into that workflow? Perfect, way ahead of me. And then, so under a pipeline, a workflow is just the orchestration of jobs, which jobs are running and in which order. And the jobs are set of commands, specified environment. What we're seeing these here is they're each their own independent ephemeral environments spun up on demand to the specs in the config file and then torn down after. They each have their own set level of vertical scale. So CPU and RAMs to match what's needed for that job specifically. The environments can be Docker, Linux, Mac, Windows or a custom hosted runner. Also, Brian, you mentioned something interesting, a custom hosted runner. Can you tell us a little bit about what that is? What is a custom hosted runner? Who would need that? Yeah. Yeah, so it's a go binary you can install. If you want to, we have cloud resources that are available, absolutely scalable for you. But there are a couple, I think reasons that people might also raise their hand to use a self hosted runner. One would be exotic compute requirements. I love saying exotic like I'm describing a jungle cat. Our execution environments cover the vast majority of use cases, but there's something really specific you need to run on. It's perfect for that. And then sometimes security protocols. So if you can only access production environments from behind a firewall, for instance, or if you have some other protocols, you can use those for specific jobs that are part of the core workflow. Awesome. And so we're seeing here, this is a workflow and then each of these are the jobs within that workflow defined by the by the config file. Yes. Yeah. Yes, exactly. And we can jump in perfect ahead of me yet again. And so we're seeing a failed job here. Of course, we want everything to be green, but in reality, you know, that's what we're here to talk about is how to fix things outside of the happy path. And then a job is really just a set of commands in an execution environment that you specify. So you can absolutely want to set your environment, run the exact steps needed to validate what you want inside of that environment. And if you want to do adult bash using CLIs, you can 100% do that and you're off the races. One other note before I pass it off to Tom, though. So there's another piece that we're also here to talk about. In reality, most people don't want to write everything out in bash in each config. Really want to utilize the best practices and simplify the processes. So orbs are CircleCI's tooling to help establish processes. Configuration is code and you can think of them as CircleCI's package manager. We have certified partner orbs with great teams like Sneak and Cloudsmith. And with these orbs, you can not worry about reinventing the wheel. The best practices are built in helps you simplify your configuration. So just think many lines of code combing through docs to figure out what to write simplified into a single or a few lines of code and plug and play commands, full jobs maintained by CircleCI or the partners and you know they're up to date and version. Perfect segue to actually hand this off and talk about some orbs and ways to use them. Yeah, thank you, Ryan. So just what we're seeing here then going back to the CircleCI YAML file, we kind of give a sneak preview of that. But here are the two orbs that are in use as part of our workflow right now. And these orbs are used in the jobs that we ran, which each of these lines represent. And what we're seeing here, the failing job is actually an invocation of the Sneak orb, where as part of the CI pipeline, where in this particular case, testing to see if there are any vulnerabilities in the open source components utilized by the sturdy waffle application. So Sneak, the whole idea here is just an extension of that shifting left. Yes, we want to put security into developer's hands, but it's still important to integrate security testing because developers are human or new vulnerabilities might be disclosed for an open source component that a developer was using. And when it runs through the CI pipeline, what we're doing here is just testing, making sure that we're preventing issues from entering our production environment. Question on my end, do all the types of security tests have to run at the same time? So, Ryan, that's a good question because Sneak supports testing the open source, we can test the built container image, we can test the proprietary code that's part of the application and the infrastructure as code. Short answer, no, we do not need to run all the tests at the same time. Case in point, right here, we're only testing if our open source dependencies have vulnerabilities before we build our application. So that's a great question. So in this case, let me zoom in a little bit for the viewers and the audience. The orb that invoked the Sneak CLI, in this case, failed the job because we have an issue in one of our eight dependencies. There's one issue in the JINJA package that is used by our application where version 2.11.2 is introducing a regular expression denial of service vulnerability that can be fixed by upgrading to JINJA 2.11.3. So when we set up this orb, we can actually see a reflection of the vulnerability within the Sneak user interface. So when you import the GitHub repository, where this application is currently hosted in the Sneak, it constructs a representation of, oh, here's our requirements.txt file. And if we go into the Sneak user interface, we can see that exact same vulnerability that was identified in the CircleCI workflow. And from here, as a developer, we can choose how we want to take action. Do I want to manually upgrade this to JINJA 2.11.3? Do I want to ignore this vulnerability? Or do I want to have Sneak help fix this for me by creating a pull request? In this case, because we have a broken pipeline, and we want to make sure that we can resume our builds and get our application pushed as fast as possible, we're going to have Sneak open a pull request on our behalf, which is going to bump up that version of JINJA from 2.11.2 to 2.11.3. Question for me actually was for doing that, Thomas. Can we configure? Is there a way to configure the tolerances of the Sneak orb itself so that you can open the range and say, well, I want to allow some things through or I want to reject? Can we get controls on that? Absolutely. So within the configuration of the Sneak orb in the CircleCI YAML, you can definitely pass in what we call the severity threshold, where you can choose what the level of acceptable risk is that you want to allow introducing into your code base. So in this case, this is a medium severity vulnerability. So it is totally possible to add into the CircleCI or instructions. Like, yeah, only fail my build if there are any high severity issues or higher. So in this case, though, we have it failing on all severities, which is why this medium severity issue failed our build. But now we've merged this fix into the repository and which will be received by CircleCI and then Tom will kick off another build by pushing another tag. And what we should see is that the Sneak orb will now allow the pass to allow the task to pass. So while that workflow runs though, because it does take a little bit of time to retest, it's a good chance to verify, to talk about what it is that CloudSmith is doing here to ensure that both the artifacts we're using in our build, but also the artifacts we're publishing come from a known trusted good source. So while that runs, Tom, you want to take us through a little bit about what CloudSmith is doing here in this pipeline? Yeah, yeah, absolutely. Thanks so much, Tomas. So you can see on the run within CircleCI we're in the process of building a Debian package based upon of that Python application. And the process then will be to push that up to CloudSmith. So thumbs up, it looks like it's doing the right thing. It's nice to see within a demo. Always a good thing to do. But I would like to talk a little bit just about repository layout then within CloudSmith and I guess best practices perhaps and ideas for how you can best structure your assets and strategies and techniques that you can use in order to strengthen your supply chain. So Tomas, would you mind showing the repo list again? So first off the list, you see the app repository. So the app repository in this case is where we perform continuous packaging. We're constantly producing new versions of this application and pushing this up to CloudSmith. What happens when it goes into that is open. We can trigger off other workflows, perhaps using webhooks. We can perform actions based upon that. We can enrich the information within that as well. A couple of other repositories worth mentioning at this point. We have first off the different environment repositories. And so we're going to talk here a little bit about a staging repository and a production repository as well. Tom, quick question. What kind of stuff can you store in a repo? Do they have to be all the same format? No, that's a great question. We like to try and leave that up to our users, ultimately their best place to make those decisions. So we currently support around about 25 formats, give or take a margin off the top of my head. It's changing rapidly, but it's ultimately about empowering our users to have the flexibility and freedom to structure the repositories in the ways in which they fit and make sense to them and their deployment. So one of the best practices that we advocate in this case is to use, keep your assets organized by environment. So in this case, for example, we've got a staging repository and a production repository, both of which reflect your different environments in a traditional setting. This allows you to kind of think of things and approaches to promote things across a pipeline. So within a staging repository, for example, we can put assets in there. We can perform tests against there. So we could call it to sneak, for example, if we pushed a Docker image up, we could call it to sneak and perform a vulnerability scan. We could perform end-to-end testing, perhaps some smoke testing, API testing, whichever really makes sense for the application. And then sort of once everything has been signed off, once we're thumbs up, it's all looking good, we can then promote those assets into the release's repository. And that whole process is in essence what we like to call continuous packaging. There is an element of this then that sort of talks about, well, applications are built, right? They have dependencies. So I'll talk a little bit about that now in the dependencies repository. So Tomas, if you mind bringing that up for me. And thanks very much. We'll talk a little bit about what's going on here. First off, you might ask, well, why would you keep your dependencies in CloudSmith? Ultimately boils down to trust and visibility. Having a single 10-foot view of what's going into your software, it helps inform you of your bill of materials, software bill of materials. Manufacturing has had this nailed for years. If I pick up my iPhone, right, not to discredit other phones exist, they're all very good. This particular phone, we have a screen, we have a chassis, we have a main board. I personally don't know the components that go into this, but you can be rest assured that the manufacturer does. So they have a list of all of the components. They know that the main board may be sourced from Foxconn, the display may be sourced from Samsung or LG. And that information is retained by the manufacturer. They're fully aware of everything that's going to go into that product. And so software should be no different. We've gotten to a stage now where tools such as CloudSmith and others are getting to a point where they're really helping facilitate that visibility of what's going into a product. And ultimately, it's about assertion that we are fully aware of where our stuff is coming from, where dependencies are coming from, and validating that it is what it says it is. And we do that through the use of upstream proxying and signing keys attributed to the repositories as well. So you can prioritize upstreams. Ultimately, you fetch a package. If it exists in the local repository, it's served out first. Otherwise, it can fall through to upstreams and be served. And there is a priority to those. So you're able to fetch from the local and then upstream number one, and then upstream number two, and so on. Tom, interesting that you mentioned upstreaming. Is that related to this very hot topic that we constantly hear about called dependency confusion? Is that related? Yes, yes. So, Bingo, bang on. Let's take a hypothetical situation. So we have Bob at Hooli, right, bearing no resemblance to any fictional companies that you may have heard about. But Bob has been in the company for a long time, three, four, five years. He didn't get a promotion for the third year, but he's getting quite jaded about this very disgruntled. Bob leaves the company. But with that walks out a lot of the knowledge of the internal systems of Hooli. So Bob is fully aware that they have a Python stack, that they have packages internally called Hooli middleware and Hooli comms, et cetera. And so ultimately, Bob could be in a position where either he wants to inflict harm upon the company or he could sell this information to someone who wishes to act upon it. And so the process is quite simple. You can create a package named exactly the same as an internal package, upload this to a public upstream, such as PyPy, and all of a sudden, Hooli CI at some stage could potentially pull that into the environment. And so through use of services such as CloudSmith that enable you to have that layer in between, we can actively help prevent that. We can ensure that when requests are made for that particular asset that they're serving out the asset that has been uploaded directly with CloudSmith rather than any external untrusted sources. Awesome. Thank you, Tom. So if we flip back to CircleCI, we should have given it enough time to complete our workflow. We can see that the test that previously failed succeeded this time. And because that test succeeded, it proceeded with the rest of the workflow. We now have built and published our Debian package into CloudSmith. So what comes next? But how would we then take this? You mentioned staging to release repository. What would be the next part in our workflow, Tom? So the next stage, right? At this point, we will have uploaded an image. We've created a package. We verified it with Sneak. We've uploaded it to CloudSmith and we created a Docker image from everything at that point. So now everything lives in our staging repository and we're looking to kind of okay things before it gets promoted into a production. So you may need to hit refresh on the UI. There's a second step has appeared above and true demo fashion, these things, you know, they line up. But so we've utilized CircleCI to do an approval step in this position, which is a great feature and allows us to be able to give a manual intervention step prior to doing something that could be potentially risky. So in this case, we're talking about putting in something that's just been created, something that's just been built into a production environment. It's obviously something that we want to, we don't take lightly. So with that, the next step is to essentially approve that, if you want to want to do that. And this is, you know, there are multiple ways in which you can do this, right? Common ways we've seen in the past is perhaps to call out to Slack or some other kind of system using some of the CircleCI orbs in order to do so. And they help facilitate and make this process seamless. But with the approval, we're at the promotion stage of this application. And from here on out, we're able to take that asset and put it into our production environment. So at that stage, we've verified it's all good. Everything's looking great. How do you get yourself out of that repository, right? Well, to get things out, our best practice is in general to use entitlement tokens. So you can use sort of, you can have users, you can have public repositories. But for private repositories, our best practice would be for entitlement tokens. Basic question coming in hot, Tom. What does an entitlement token do? Is it like a password or set of credentials? Yeah, in a nutshell, but there's a lot more to it than that. Good catch. It allows you ultimately to control your stuff and who has access to it and where it can go. You can get reports on it. So you can get reports on the number of downloads, perhaps the amount of bandwidth that's been confused. So if you happen to be selling software, for example, you can get visibility of someone's abusing a token or someone's went rogue, and perhaps this token is being misused and out in the wild somewhere. But you can also apply constraints to it via filters. So I could, for example, as part of my deployment, give container D within Kubernetes permission to pull an image to do an instant to bring up a pod. Or perhaps I could give Terraform exclusive access to the repository just to retrieve Terraform modules. So the choice is ultimately yours with them. We try to empower users like the whole way through the stack. But certainly when it comes to the deployment piece, these things are quite powerful. They're the recommended approaches. They're a read-only way to get your stuff out of the repository, and they can be filtered and constrained throughout. We obviously like all of this stuff, right? We recommend this stuff is cycled. So, you know, where possible, where makes sense. Refresh these tokens. They could be done through the UI, the CLI, API or CircleCI, you know, either way. This gets my gears turning, right? Going to go slightly off-script here. But this approval process is really interesting because we built our application. It got pushed into our staging repository. And then you have this approval to promote it and declare this artifact production ready, effectively. But you could apply the same logic to security testing as well as other activities. This concept of acceptable risk, Brian, to your question earlier about setting different severity levels for the Sneak Orb. If you don't necessarily want the Sneak Orb to halt your pipeline in the case of vulnerabilities, you can still use these types of manual approvals to say, ah, well, it did find some low severity issues, but that's okay. We're going to still let this artifact be promoted. And this allows you to set up different tolerances for deploying an application, maybe to an internal staging environment that's not customer-facing and is not exposed to the internet, and set up more strict rules toward a production environment that is exposed to the internet that is customer-facing, where those risks are much more important to address. So really cool mechanic here that we've displayed with this approval, because it could have been used to let the pipeline continue, even though the Sneak job failed. What you could even do on top of that is set up the approval to only work if someone is tied to a certain security group in GitHub. So if you want to allow someone to press the button, but maybe not just in turn to come in and hit the approval, because if you want someone to go look at it, you can just gate it there too. So that's a really cool thinking. Yeah, absolutely. So to kind of recap, there's a lot of things that we didn't show, but for the audience, what we wanted to demonstrate is the workflow lives on CircleCI. In CircleCI, you have these orbs that allow you to extend the tasks that are running as part of your workflow. In this case, for this demonstration, we showed two orbs. First, the orb for Sneak that allows you to test the open source, the code. We could have scanned the container, we didn't show that today. We could scan the infrastructure as code. All of this can be done with the Sneak orb. But then we also showed the CloudSmith orb. And some of the invisible functionality that wasn't shown with CloudSmith is what Tom mentioned, knowing that the application's dependencies are coming from a known trusted good source. But then also using the orb to control that promotion of an artifact from staging to production ready is a way to ensure that whatever you're deploying in production, you really know where all those bits of your supply chain. Tom, I loved your iPhone analogy, like showing that you know where the chassis came from, where the main board came from, where the screen came from, have that kind of provenance. That's very, very powerful and necessary to ensure that the software you're running isn't going to compromise you. Nobody wants to be the next case study on a data breach, leaking customer data or anything. So thank you all for helping put this demonstration together. I hope my recap captured most of what we showed. Ryan, Tom, is there anything you'd add? I don't think so. I think we've covered a good bit of ground here today. You know, like you say, having provenance of what's happening across a build and deploy pipeline is crucial. That is, we're all on this webinar today because that's something we firmly believe as individuals and the companies in which we represent. The provenance, it starts in one two, right? We think of the mentality of Chef Left, like you say, you know, the earlier that you catch a vulnerability or an issue, the impact weakens, right? You know, if we're able to identify something that's happening all the way over here, it's no big deal. We go, okay, let's bump it, let's fix it, let's move on. If something happens the whole way to the right of that platform, deployment, where it's out in the wild, the customers are using it, it's like you say, you can end up a case study, right? You can end up where this deployment has hit hundreds of thousands, maybe more users, right? It's on systems all over and at that point, the impact in order to try and control and mitigate that becomes significantly more challenging. So these are strategies, right? These are a bunch of strategies presented by us today, but they're most certainly not everything that we should be doing. Ultimately, it's about kind of provoking discussion and trying to shift the mentality. You know, we're already there, right, in the sense that most of our audience members will most certainly be doing continuous integration to some degree. They'll almost certainly be doing continuous security to some degree and continuous delivery. This is about kind of meshing all that together and going, let's think about this holistically as a pipeline and what steps we can do to mitigate this from ever happening again. Absolutely. Thank you for that. I would try to chime in, but that was so elegantly put by both of you also. That was perfect. Awesome. So real, that was what we had for the demonstration, you know, that appreciate the back and forth, the engaging conversation, you know, the questions that were asked, I feel like added value to what we were displaying. So before we, you know, to kind of recap what we showed, right, we showed how you can configure CircleCI, that config, that config YAML file, if you look at the GitHub repository, I look up sturdy waffle, it's a very hard to forget name. But that GitHub repository has the CircleCI YAML that we used for today's demonstration of workflow if you need some inspiration. But we saw how you can orchestrate this entire workflow, including integration, security, packaging and delivery entirely from a YAML file. You can use orbs to add functionality from tools such as Sneak and CloudSmith into the CircleCI workflow without having to write everything from scratch. So definitely check out those two orbs. From the Sneak side, you saw how the Sneak orb, you can use it to fix security issues. In this case, we demonstrated an issue in an open source component, but the Sneak orb goes beyond that if you'd like to also scan your containers for vulnerabilities or if you have Terraform, CloudFormation or Kubernetes YAML files, you want to scan for configuration issues, you can do all that with the Sneak orb. And then we showed how you can use CloudSmith to construct that trusted golden repository and to control how artifacts are promoted and declared production ready as part of these workflows. So thank you, Ryan. Thank you, Tom, for helping put together this demonstration. It's been so much fun to put this together with you. I guess we can, before going into the Q&A, just leave our audience with some calls to action. All these offerings, try them. Try them for yourself. Log in to CircleCI, build your delivery pipelines and play with how you can run your tests and integrate your unit functional integration tests like practice your CI. Check out CloudSmith. Build that secure cloud native repository and integrate it into the CircleCI pipeline using both the CloudSmith orb as well as the capabilities that it provides. And of course, also check out the Sneak orb. There's a free account that you can sign up for. It gives you a free scan allowance. You can replay this entire demonstration that we did today with your own applications. For the slides, we have included some additional resources here for the audience. So if you'd like to read a little bit more about what it is that we do, please check out these resources. But with that, I think we're ready to move into any questions that our audience might have from our interactive demonstration. So I'm wondering, have we gotten any? And as a reminder to attendees, you can drop those questions directly into the Q&A section in your Zoom. We must have blown everybody's minds and just in a perfect manner. Yeah, I'm not seeing any questions. Hopefully just got one. What's the difference between CloudSmith and GitHub? Yeah, GitHub. I guess I'm probably best place to take that one. That's a great question. Thanks very much for that. So I guess the primary difference is when it comes to security supply chain type stuff, it's the amount of exposure and the amount of control that you get in order to put mitigating factors in that. So let's take a look even at the examples that we've seen in today's webinar where we're talking about upstream sources and prioritization of those sources. With CloudSmith, you have absolute full control of that. You can create as many of these things as you like. Our repositories are polyglot. In other words, we support more than one format in a single repository, and that enables us to have our customers use our service like we've demonstrated today in a kind of environment by environment basis. And so the usefulness of that is you can have particular permissions for a staging repository completely separate from a production repository. The world's your oyster with it, right? It's ultimately about empowering control of the users of CloudSmith. So the people that are actually going to be uploading packages, the people that are going to be performing operations with those packages, and then once it gets to the south side and it comes to delivery where those things go. So we provide very, very granular controls in order to allow you to access your packages. As we touched on at the end of the webinar presentation, you can create entitlement tokens on a repository by repository basis, and they're very, very powerful. We have customers that use us, some customers, for example, will use us exclusively for internal development purposes, and many others will use us for distribution. Take Font Awesome, for example, who use us exclusively for distribution of their glyphsets. They're massive. They might have used that they come across is obscene. And one of the big challenges that they have is identifying who are the bad actors that are taking the data out of their service, because many times, particularly for distribution pieces, there is the fear that a license key can be repurposed, perhaps shared amongst users, that kind of thing. We give Font Awesome and customers who use the service the full visibility and provenance of what's happening with their software so that they can make the decisions of, okay, well, it's pretty clear that there's something funny going on here. This has been accessed from 100 unique locations. It's been accessed from a thousand different IP addresses, and so it's about empowering users with that element of control. Ultimately, that's the gist of it. But in essence, keeping everything in the same place, giving you the part to control your supply chain through the use of upstreams, through the use of signatures, signing, all that good stuff. That's an in essence set. There's significantly more, but I don't want to talk too much and consume the entire rest of the webinar. By all means, if there's nothing we're talking about here that doesn't resonate or you need more information, please reach out even to me directly if you'd rather not speak to support. Our details are on the slide deck anyway. Okay, so what if we... I think we just got another question from Wolfsman. So how do developers and security folks work together when it comes to alerting there is a vulnerability found in the software, keeping in view the shift left paradigm? So great question. And so this can... New vulnerabilities are disclosed every day. And so just because a pipeline passed today, taking in context, the demo we just showed, our pipeline may have passed right now, but if an hour from now, a vulnerability against that package was disclosed, next time that pipeline executes, we'll be right back to where we were. So how does this turn into action towards the developer? Well, one thing that... And I'll quickly hop back into the circle CI UI for this bit. But one thing that we do to try to make this in a developer workflow is we actually show, and this is the test that passed. So that's not a good one to show. But when it fails, we do demonstrate the fix, how this component was introduced. So right in the CI pipeline, a developer could get alerted because circle CI has webhooks that can report information back to GitHub as pull request checks or as commit checks. So through the form of those checks, a developer can be alerted, yo, something broke in your pipeline. And in the pipeline execution logs, they can then see, ah, and here's what actually cost it. That's one way. Another way is as we saw in the demonstration, it is possible for a sneak to automate the process of opening a pull request that can fix the vulnerability. So it would show right here, this is where we used to have the vulnerability, not anymore. But if we go back to that previous snapshot where we did have the vulnerability, what we saw today in the demonstration was how we opened a pull request. So a security person with access to sneak could potentially open this PR. And since it creates a separate branch, it won't just commit it straight to the master branch. When it creates a separate branch, all a developer has to do is check out that branch and, you know, test it, make sure all the tests work correctly. So in this case, we're helping it become a team exercise. So either the developer finds out because a pipeline failed, or a security person takes a proactive action and opens a pull request on behalf of the developer. So the developer can start verifying that the issues have a fix. Those are two potential ways that it can happen. Now, of course, there's other ways to do it, right? A security person could use the JIRA integration to create a JIRA ticket on behalf of the, you know, for the developer to fix this, or they could just use the alerting functionality within Sneak where if there is a new vulnerability disclosed, it will show you in the UI, hey, there's new vulnerabilities for your projects. So there's a plethora of options for, you know, encouraging that team exercise. Go back here. That was a great question. Any others? We probably have time for one more. While we wait for that last question, you know, Tom, Ryan, it's been an absolute pleasure putting this demonstration together with you. Thanks for, you know, joining forces with us to, you know, to spread the love and share the message for how developers can speed up their delivery cycles while keeping their applications secure. I appreciate it. And getting waffles. It's been a pleasure. Yeah. For those who want to know the true story of that, it was an auto-generated docker image, right? The docker container that started up, and we looked at it and thought, wow, that looks great. Why isn't there a company that exists with this name? So, yeah. One last question from our same newsman. Thank you for the engagement. So how do you see the future of developer security? You know, the future is one where developers are empowered to own more parts of the stack. You know, before there used to be this really clear line of responsibility where developers would write code and pick their open source, and they would then deploy their application into a golden image provided by their operations or IT department. But now with the rise of the cloud, with the rise of containerization, with the propagation of open source, particularly for serverless functions, developers now have more responsibility over the stack. You know, the choice of base image is developer declaring that in their docker file. The infrastructure that's on the cloud is a developer declaring that in Terraform manifest or CloudFormation manifest or Kubernetes YAML files. So before where there used to be this very divided line of what developers did and didn't do, now that infrastructure is becoming part of the application. So the future of developer security is one where developers can confidently use all these new exciting and empowering technologies confidently and securely, where they have the tools needed to manage security themselves. With guardrails set up by their other stakeholders, the security team, their operations team. And, you know, what Tom demonstrated today with CloudSmith is definitely part of that as well, where developer knows where the artifacts they're using are coming from, where, you know, all their artifacts are being promoted and declared production ready. So hopefully that helps. Thank you, Tomas. And big thank you to Tomas again, Ryan and Tom for their time today. And thank you to everyone who joined us for today's webinar. As a reminder, this recording will be on the Linux Foundation YouTube page later today. And we hope to see you at future webinars. Have a wonderful day, everybody. Thank you all. Thanks, everyone.