 I'm here to talk a little bit more about how do we get those kinds of integrations going for not just GitHub, but for your enterprise and for open source software in general. For those of you who aren't familiar with Cloud Events, we'll be talking about that in a moment, but first we're going to talk using some of the terminology from Cloud Events, what is an event? So they define an event to be a notification of something having been observed. So it's not a PR was opened, you know, the PR being opened happens whether or not you listen for the event. But the event is sort of telling you, hey, if you were interested, you could go and listen to this stream of stuff and you could find out all the PRs that are being opened in this repo or something like that. So the great thing about this is that there's a lot of different systems that produce events. The other awesome thing is that everybody has made up their own formats. That's not really awesome because it means if you want to interact with GitHub and you want to interact with GitLab and you want to interact with Bitbucket and you want to understand pull requests, you need to write three copies of the same code. And as much fun it is to write three copies of the same code, I've done it enough. So Cloud Events is a CNCF project to standardize a simple envelope. Kind of think of it like HTTP for events. You know, you walk up to a whole bunch of APIs all over the world. They got different bodies, different payloads, but those headers are common. You got common libraries for like assembling a URL and things like that. And Cloud Events aims to do that and lets you convert things between all the formats that are already out there in the world. It's not going to replace stuff like protocol buffers or JSON or Avro, but you can take a record that was written in Avro and mechanically convert it to JSON and put it on a different type of messaging system, for example, or write it to a log or something like that. And there are a bunch of systems already, I've linked some at the bottom. Some are CNCF projects, some are other projects that produce these kinds of events that you might use to react to security issues. But it's not just about reacting. You can also take advantage of these to be proactive and say, hey, you know, there's a software build. I need to initiate a security scan or, you know, hey, I scanned this two weeks ago, should I re-scan it? You know, I know it was built two weeks ago. I should, you know, re-initiate scans on this thing with a newer set of vulnerabilities. And you can also use this, you saw Falco on the previous page. You can use this to discover, hey, wait, there were unexpected system calls from this container. And I'm not going to run through the demo here, but Falco did a great series of blog posts with eight different systems that you could integrate through cloud events with Falco Sidekick to basically solve the problem. There's a pod running in my cluster. It just started a terminal that's connected to a shell that's connected to an interactive terminal. I would like to delete that pod, you know. So your attacker comes in, pops open a shell and delete pod. Find a different way in, open a shell, delete pod. And so you could actually go and play with this, you know, with kubectl exec or, you know, build yourself a little web shell, run it and watch it get shut down. So these are some examples of actual events. The one on the right is the Falco rule. The one on the left is from CD events about a deployment. You can imagine how both of these are interesting and useful when you're trying to build a picture of your security posture or to react and mitigate things that are happening in your enterprise. I've had to cut down on the content of the payload in both of these cases. They're actually longer than this, but I thought you might want to read them. So this is where I get to my call to action. If you're a vendor who's producing these things, generate cloud events. Tell people what's going on. Document what those cloud events look like so that people can build these. Yes, they're going to be Rube Goldberg machines. But Rube Goldberg machines are how a lot of our lives get done. So don't fear them. Don't go wild, but don't fear them. And if you're an end user, there's a lot of different places where you can do it. You can react immediately. I'm sure a lot of people have seen the Lambda that goes in and fixes IAM if you make an oopsie or something like that. You can store these in BigQuery or Snowflake or something like that and query over them later. Hey, I wanted to know, this incident happened. What else was happening around that time? And you can also keep them as audit records long term in something that's really cheap. And again, if there's a problem, you can pull them out later. And since they're in a standard format, you can stack up a whole bunch of these things and then filter them later. If they were all different formats, you need to know, oh, this one's Avro and this one's Protobuf and this one's JSON. I don't really think you'd enjoy writing that parser later. But if you know you can take them all, stick them all in Avro and record them off into S3 or something like that, then life is pretty good. So little pitch for those of you who haven't seen Cloud Events. It's a short spec. It's like, I don't know, 10 pages, something like that. You can read it real fast. And I don't know who's next.