 All right, I'll go ahead and get started today. Good evening, and welcome to this discussion on continuous security, injecting your pipelines with critical protection for your applications. I'm Kamala Desika, your moderator, and I focus on product marketing for Cloud Platform and the ISV ecosystem at Pivotal, which means I get to work with some really great partners that help us broaden the value of the platform offering that we have. Now, platforms like Cloud Foundry just fundamentally change and speed up development. And we've heard a lot about this today from users all day long. So as the platform evolves to support high velocity and continuous application delivery, it's becoming very clear that the traditional bolt-on security type of siloed security specialists just won't cut it, right? So we have to rethink the software supply chain completely and think about security at every step of the pipeline. We have a panel of experts here today, each of whom represents very different aspects of security. What we're gonna try to do here is get their take on how the Cloud Foundry ecosystem is working to rethink security. So please join me in welcoming our panelists. I'll start in the middle, because he's probably not expecting it and I like to pick on people. So let's start with you, Josh. Hi, I'm Josh Kirk. Would I look after DevOps security in the UK and North Europe for cyber rock? Little bit closer? Little bit closer? Oh, there we are. Hi, Josh Kirk. Would I look after DevOps security in the UK and North Europe for cyber rock? Hi, Simon Maple. Thanks everyone for coming. I'm one of the developer advocates in SNCC, which is a tool that helps developers adopt all the wonderful best practices of security. Hi, I'm James Wicket. I work over at Signal Sciences. I guess we'll talk more about what we do later, but I work over there as a developer evangelist type role. Perfect. So let's start with our first question again with Josh because he started us out. All right. I'm lucky today. Perfect for you today. Secrets management is one of those security topics that's traditionally been an afterthought in enterprises. The passwords are set up manually. They're shared with everybody through non-secure methods, like emailed or not rotated. Tell us why proper secrets management is so important in CICD pipelines and also maybe throw in some examples of where not having them has been an issue. Okay. So with my security hat on Uber, 2016, 2014, great examples of really strong secrets management for everybody else. But essentially it's something you need to deal with across the board. It's a challenge that's been around for more than the last 10 years. And there's been a secrets management problem since before we've been saying DevOps. And essentially not doing it is a form of negligence. If you start hard coding credentials in apps, you just end up with technical debt from day one that will be there until you decommission the application. If you fix it from the beginning, it's simple and it's done. It's kind of quite a simple one, actually. Please don't hard code credentials. Have you ever done a search on GitHub for password removed or something like that? My favorite is AWS secret access key. Would firmly recommend it. You've got about half a million results. They're not all keys, but I can guarantee you in the last 24 hours they'll be at least 10 live ones. And if you think of the guys doing that, they're not technically complex enough that this is an IAM role. That's going to be a root account credential. They've probably joined the cryptocurrency revolution the hard way, which means that they're mining a cryptocurrency now, they're not getting paid for it, and stock prices definitely aren't going up. Tesla 2018, good examples. And it's real easy for developers to somehow check in. I've done it, right? You check in commits that have your access key or something in it that you don't want exposed. And so this is where like putting tooling in place is really helpful for this, right? You can monitor like this kind of, these kind of commits and kind of stop them before they get into your version control or in the history. Cause that's another thing I often see is like, I removed it, okay, but it's, yeah, but that's the point of version control, right? It has a history of all this stuff, so. That's it. And there's some brilliant tools out there that cost nothing. Personal favorite is Truffle Hog. Just as a way of scanning your repository, looking for high-end tree strings. He's a Truffle Hog. Truffle Hog. Okay. Big fan of Truffles. Git Rob is one. Is that Git Rob? Git Rob's another brilliant one? Yeah, there's Git Secrets and... It's almost like this is a long problem. Git Hound is another one, yeah. Everyone should probably be dealing with. And if you don't, you end up in really, really interesting situations. I mean, if you ask 14-year-old me when I set up my first WordPress and I pop my database creds in to the old WP.config, that was fine then, but it just isn't fine now. You wouldn't do it, so please. Don't? Yeah, yeah. Well, and this is one of those things that people ask me when they're doing CICD pipelines or whatever, it's like, well, this is a super easy thing that you can do. This takes no compute resources. It takes just a couple hours of someone's time at that at most to set this sort of thing up with filtering for what you need and then you're set for your entire team. So it's a really easy thing. And from day one, it doesn't really cost much. I mean, we give away our products open source. Everybody else in our segment does. There's no need to pay for it from the beginning and only when it becomes something that you probably don't wanna be running yourself. Does it need budgets? Yeah. But that happens with most things. I mean, all around the vendor boots up there, most people have a model that's when it's a problem, pay for it, run it free when you don't need it. Well, the other thing is, of course, I think people are using bots now to kind of search these, get repositories and everything. So when your opponent is completely automated and you're not, that's a problem, right? You can scale up by hiring a ton more staff. But I thought we kind of learned about that. Pretty sure that's the whole point of being here. Like we're trying not to throw engineers at problems and instead make them better through automation and other reasonable ideas. But it's absolutely right. I mean, look, the modern 14 year old is definitely about automation when it comes to ruining your website or business. They don't wanna spend a long time doing it. And the methodologies they're exposed to are the same enablement materials that your own engineers are reading. They're gonna automate it, right? An AWS free tier account gives you enough compute resource to go to town on GitHub, any public repository. Showdown's glorious for picking things out. Weight Watchers, big fan of Weight Watchers myself. They themselves had open Kubernetes, just chilling. No authentication on it with AWS secret keys sitting in Kubernetes secrets, no authentication to stop people from getting it. And that was found by security researchers using Showdown. It's not hard. It's not difficult. Any idiot, myself included, could find your credentials if you hard code them and I'll careless with them. So, put the time there. Particularly into your applications. Now, a similar note, Sneak, this is for Simon. Sneak, yeah. Sneak, Sneak, or multiple ways to say this. Snike. Snike, also, yeah. It lets you flag. I'm gonna say it. It's got mileage. Yeah. It lets you flag open source security and license risks, right? That's the product space. Now, the most famous example of this is, of course, the Apache Struts, or I should say infamous, right? Is the Apache Struts virus and what happened? Now, the first public exploit of that happened literally a day after it was reported. So, there's really not a whole lot of time despite the patch being available, right? Now, how can enterprises today get in front of something like that? Yeah, so, this was earlier this year. For those who hasn't heard of Equifax these days. Not a single hand. I got a year of free credit protection from that, thank you. Really? Yeah. It's a good deal. Yeah, I mean, Equifax aren't the only one, of course. British Airways was a classic example, just the other day. I got a year of free credit protection from that. Yeah, I got offered it. My boss actually said to me, Simon, have you booked any flights recently with British Airways? I said, yeah, I booked one just the other day. And he said, oh, you should probably change your credit card. I said, actually, Guy, I used your credit card, so you should probably change yours. And he said, that's a true story here to change his credit card. But yeah, I mean, you know, these attacks, we can't, it's not like they're not gonna happen in future. They will happen, it's a case of when, and it's a case of who. So, what protection do we have against these kind of attacks? Well, these attacks are typically happening from known vulnerabilities. They're vulnerabilities that are not being found out from scratch by every single really smart hacker kind of sitting in a back room with loads of monitors. These are known vulnerabilities and very, very easy to exploit. So, you know, if there's a CVE, the chances are if you just type that CVE in, into Google, and type exploit in, you'll find a hack on GitHub or somewhere like that, and then you just run that hack. And very often, particularly with the Apache struts, Spring Break is another good example, whereby there are a couple of interesting vulnerabilities, whereby so long as you're running a specific version of that package, you need to do little else, in terms of structure of your application, to actually be vulnerable to that. So, the vulnerabilities are really easy to hack. You talked about showdown and ways in which people can find out, you know, what you're running, what you're using. It's incredibly easy for people to find you. So, you know, if we draw a parallel with maybe, my honeymoon, I went to Kruger Park, where there's Lions and Impalas and everything else around, do you need to be the fastest Impala to keep away from a lion? No, you need to make sure you're not the slowest. And, you know, that's all you need to do. If you put minimal effort in and, you know, you're not so, so vulnerable that someone can without, you know, too much effort hack you, that's all you need to do. You need to be able to outlast a hacker's, you know, time-attention span. And once you've done that, they'll move on to someone else. You just need to, you know, stop being the obvious target. So, how can we do this with a day of notice? Well, you're not gonna have a human looking around at every single application, package that you're using, every single dependency. Who knows how many dependencies they even have in their application? One person, direct and indirect? Indirect, yes. Indirect as well. You must use a tool for that, right? You're not gonna go around counting every single one. So, the- It's one and two and one, so- Right, absolutely. So, Java or Node? Java, okay, Spring, I presume. Right. So, you know, when you have this, you know, amazing number of packages and indirect packages, you need the kind of tooling that will allow you to say, these are the packages you're using, these are the vulnerabilities that you have. And when new vulnerabilities come out for a tool to say, by the way, you are now vulnerable, here is the suggested fix, and we can automate this for you. That's the kind of thing you need. Now, in the Struts case, and in the Equifax case, I think it was a couple of days. Okay, it was a couple of days for the first hack, but we need to understand there's a difference between a hack and a breach, okay? A hack is just someone breaking a perimeter. A breach is someone taking sensitive information. And there was at least a month, two months, I think, I can't remember the actual dates, but a really good time between the first hack and the breach. It isn't the case of when an attacker calms in, they just go, smash, I'm gonna download your database and I'm gone. Those times are shortening as well. Yeah. We do research from every year, and four years ago, it was nearly a year, and now it's down to about 90 days. So, you know, there's definitely a relevance of automating this. Oh, yeah. And I think for a lot of companies, even if they noticed, even if they were made aware, at the time of the public disclosure, sometimes their CICD pipelines aren't short enough for them to even, you know, put the change in public and in production before that happens. To kind of further your metaphor, right? It's like Equifax did know that the Impala was getting eaten for like two months, right? It's not just, you know, outrunning. It's like they just had no clue that they were getting eaten. I mean, this is a dangerous audience to ask the question, but how long roughly does a deploy take you? We were gonna say it's in the minutes territory, or is that policy that holds you up? You know, change control, anything like this? You're talking about whole CD, total cycle time, total cycle time. Get commit to running production. Yeah, exactly. Is it something you do hourly, daily, weekly? I think part of the issue is also discoverability, right? Discoverability of like, where's the patch? What do I do? What comes next? Like, is that something that we can make easier now for developers and actually applying the patch, Simon? Well, I mean, so for example, the company I'm representing here, SNCC, we automate a huge amount of, not just the discoverability of the patch, but also the possibility of the patch to be able to be able to be able to be able to be able to do the same amount of not just the discoverability, but we are very opinionated in the way which we suggest the fix that you should apply should be done. And then we'll actually go ahead and push pull requests so that you as a developer, you know, don't just aren't just told about what the potential fix is, but we'll actually go ahead and update your palm or your package, Jason, with the necessary update or a patch that we would handcraft, that would alleviate you of that vulnerability. So I think tools are extremely helpful. But they are definitely not, and this is from a tooling vendor, they are not. You can't buy a tool and say, I'm DevSecOps compliant. There are many things which you need to change within your organization, from the culture of the team, from making sure security is in your processes and through your processes from start to finish, and so that the security team is actually part of your overall working focus group, your feature teams. Tooling, of course, is there to actually help you achieve that in your processes in a timely fashion, but it's certainly not the be-all and end-all. Now that actually, that reminds me of a fun piece that I read written by James where he said that securities shift left should really be shift right. Well, it's an and, and, yeah. And, and shift right. Now it's a little unexpected given what the industry mantra is right now. So, can you explain what you meant by that and how does that actually lead to continuous security? I need to explain, yeah. You know, it's funny, just like an hour and a half ago, like I was getting trolled on Twitter for this exact same thing, you know? It's lovely, right? They copy like the company Twitter handle in there as well, so it's really great. I appreciate that. So if you're going to troll me, please make sure my boss gets to see that. Julie, now did you learn that? Yeah, thank you. Please, please do that. What's, one of the problems, okay, let's ask a question here. How many people know if you're under attack right now? How many people would know, you know, feel confident that you would know if you're under attack right now or not under attack? Right? That's a question that really kept us up at night, especially when we started Signal Sciences. So we, you know, we are kind of on the, on the production side, the operation side of the continuous delivery pipeline when customers are actually using it. And, you know, we're looking at application security vulnerabilities like cross-site scripting, SQL injection, all the oldies that we've had, you know, since like, you know, 15 years ago. And how to actually monitor and defend against those. And then we're also looking at other things like bot mitigation or feature abuse and misuse or any types of, any types of, any logic in your application that you want to instrument the flow of and monitor, you know, we can be able to do that. And then we also correlate things from all sorts of lists, you know, like bad actor lists or weird anomalous behavior, error codes or anything like that. And then we contextualize the whole thing. And then we let you know, like, is the impala getting eaten or is it not, right? And like, that's kind of our answer there. So what do I mean by the idea of shift right? I think that to a point, we sort of have brought this DevSecOps belief that we want to do all the shifting left. And I totally think like shifting left is a good approach. And whenever we think of putting tooling in the pipeline, putting tooling, like we just talked about like to get secret stuff or SNCC or other types of things that like, you know, do like a software build materials. I think all that stuff is really, really great. You totally need all the shift left early in your pipeline testing stuff. But often we do that to the detriment of actually putting in any like good instrumentation. So if you think back to, and I have a corollary here that I think is really important for us. When DevOps started in 2009, Patrick DeBlas like, hey, like it's agile, but for operations, right? And kind of marry that thing. I think Patrick was totally right on with that and Andrew Schaefer and some other folks whenever that was coming out. And when we were in those like early days over the conversations, right? It was like doing better testing, infrastructure as code. There was also a big hinging point on monitoring and actually doing instrumentation where it matters like putting the operational data back to the developers and developers are gonna support this thing. Well, you know, developers also care about security. Often they're maligned by security and said that they don't care, that there's like stupid developers or whatever. And I think security people that do that are very wrong and wrong headed in their approach with that. But I believe that we have to look at this in a way where we're adding instrumentation that provides feedback to the developers just like operations did when they kind of underwent the DevOps transformation. Security's doing that under DevSecOps. Sorry, that was really long, but I think it has to be contextualized in that view. Right, perfect. I think that's really helpful for us to understand, I think somehow we think that everything should move to the front of the line. It's only important to think about, what's that? No, I'm gonna say this is really interesting. When we talk, the words we're using is like moving things or shifting things. It's really not, it's about just making sure you have focuses in other areas as well. So it's like when we talk about shifting left, when we talk about, and the same words we use with performance as well sometimes, shifting performance left. And I think we just need to shift performance. It's like shift security everywhere, right? It's about having- We need to expand our focus basically rather than this. Like, oh, we're gonna improve development. We'll train every developer to be secure and then we'll replace our security teams with security engineers in there. What we actually need to do is sort of pay the same amount of attention across the whole thing. Train our security folk to be engineers. Train our risk people to understand what the hell's going on. Grow everything rather than just focusing on one part. Yeah, well, and I think you're corollary there to performance. I think performance and security are very similar in their space and how you do problem solving here. And you can rewind to like 2007 or six or whatever when velocity conference started out. It was like the weirdest conference idea that O'Reilly ever put together at the time. It was like, we're gonna take some front end developers and we're gonna take some back end operations folks and we're gonna jam them into a conference because we want less than two second page load times, right? And like, and so from that, like you had tooling that, you know, that like people started doing like Weislo and all that sort of stuff on the front end. You had infrastructures code and fig management and all that stuff. And that was really a birthplace of DevOps. Like one of the main places where like DevOps really grew out of, but it was taking these two separate people that in most organizations don't talk to each other and are separated by many layers and many silos and kind of jam them together in a conference. So I don't think that it was, you know, happenstance that it all kind of happened together. And I think security kind of needs some of that same approach, right? Like it's got to fit both of those sides. Yeah. That's exactly what we're doing, right? Yeah, that's what we're doing. Yeah, jam security right into the... Because at its course about having the data at the right data at the right time and whether that's pulling security left so that the developers understand which vulnerabilities are going in at the time that they're actually putting it in or whether that's in production whereby you actually understand what's happening at the time and what signs are there that a hack might be happening and things like that. It's about getting those data points at the right time and feeding it to the people who need it so that it's easier to fix. Telemetry for everybody. What I find really funny with a lot of this discussion is that everyone since they're talking about improving news observability and I hate the word. Yeah. Of course, we call monitoring. Let's call it monitoring. Yeah, there you go. It's been there for a long time, it works. And then they start building out all these processes around it and then they start talking to the traditional security people who sit at the back of a basement or somewhere far away from the developers like the diagrams in 10 Deploys a Day 10 years ago where there's this line between Dev and Ops and they don't realize that there's a sock. An entire team of reactive engineers focused on looking for events that warrant attention and resolving them and because there's this dotted line that blocks security from Dev Ops they're missing out on this giant team of people that can do their jobs. Well, sorry, do the boring bits of their jobs for them. The things that you don't want to do. The things that aren't building a new product that aren't making things move faster. And they just neglect it because they don't want to interact with security folk. Yeah. Not unlike the testers of seven or eight years ago and it's like many people brought their QA teams in and when we were working on a Dev Ops project at a large enterprise, we just sat down with the testing team and was like, okay, let's go over like test automation stuff and like in it just like night and day like the way that the team functioned and how the performance worked and it kind of brought them into the whole development cycle as part of the team instead of kind of the separate, oh, that's the QA group that we send stuff over to. It seems like we covered a lot of ground here. Yeah, yeah, sorry. We talked about some of the soft spots that people would be able to exploit and just, it's not like they're super sophisticated hackers are not super sophisticated. They just look for vulnerabilities or things that we might have forgotten to do. Now, what are the steps that enterprises can take to first of all, find these kinds of soft spots, right? Where problems in applications that are already out there and also secondly, what about the newer applications, right? Like what does that ideal pipeline look like to you? And that's really for all of you in your various fields. All right, yeah, okay, so I have a presentation that I've given recently and I can send the link to you as well but it kind of goes through the whole CICD pipeline and breaks down each stage of the pipeline with some ideas of security tools that you can use. And every stage is different depending on your language and how you're architected and how you're producing this out but I'd be happy to share that as a useful thing. And I took some of that and I distilled it into a course for LinkedIn Learning that's gonna be hitting, if you have a LinkedIn Learning subscription you can check that out and that comes out within the next couple of weeks, so. Yeah, perfect. I think the first thing, before we even think about tools is from a company point of view. Everyone talks about, and it's a phrase, I've already said DevSecOps but it's another phrase, I'm not massively keen on digital transformation. If anyone wants to leave the room when I say that, you're welcome to. Digital transformation, effectively, yeah, just trying to push jobs through CICD, quicker, being able to release faster. But yeah, the problem with that is things like performance, things like security. They get left behind because they're traditionally not designed to fit in those kind of short time-lapse release cycles. And I think the first thing to do is to make sure that the team is actually structured in a way that when you get tools and change processes, the right people are talking to each other, having security people from the very first design meeting, talking to developers, talking with the architect about the differences that you need to think about when you're thinking about a serverless architecture versus a monolith architecture or a microservices architecture, those kind of things. First of all, I think that's massively the biggest thing. I think it was Martin Fowler when he was talking about people adopting microservices. Unless you have a team whereby you have lots of many teams each representing a kind of single service, unless you have that, you won't actually design and create a microservices architecture. If you have one massive team, all you're actually gonna do is have what you think are modular microservices but you're actually just creating a monolith with the light boundaries. If you really want to structure your application, structure your environment to deal with security, you need to change the way you work, change the organization. So that's the first thing I would say. So I'll weigh in on a different one because I completely agree with both these points. But a lot of them- This is a panel, you shouldn't agree. Come on, let's disagree. Drop the mic on us. I don't wanna pay for it. It's a really good mic. So I think a lot of those tackle the moving forwards side of things. And security isn't something that you draw a line in the sand and say, right, from this point on everything's secure because that's how you get hacked. I think actually sitting down and trying to break down the walls organizationally first and saying, what sucks? Ask the question of a open room full of people inside your organization. Tell them that no one will get fired, bring in some pizza and beer and say, right, everyone in here will know something bad. Let's write a list of these. Let's find the low hanging fruit. Let's collect them all together and fix them. And often, you know, your developer will pick out something like, my app doesn't log well enough. There'll be a guy who knows how to fix that in the heartbeat. Improve that, you gain visibility, you get back to this, but you have to start with the old stuff first because otherwise you get lost in this but everything new we're doing is secure which is a really good way of not fixing anything. I haven't heard of Docker, have you? You know, one thing I'd recommend for folks, if you're doing like, you know, agile or weekly or sprinting, you know, for development cycles which a lot of people are, you kind of read security stuff and they're like, oh, threat model and it's like this big gigantic process and you know, and they only, you know, security really wants to do like once a year, if that, right, but there's a new one called Mozilla rapid risk assessments and I'd recommend checking it out. It's built to do 30 minute tabletop exercises that you do once, one time per sprint and then over time you build out like a holistic threat model together but like that's a great thing because it's basically that idea of like, okay, what do we think's wrong with this thing? What are the pieces we're changing in the application? Okay, what does that mean for authentication and other pieces that are critical? Okay, thanks, good meeting. See you all in two weeks, right? And that's, it's a good process and we've been seeing some companies that are kind of leading edge security do that kind of stuff. And to maybe give some more practical advice into CI CD pipeline, I think, you know, looking from the moment a developer starts writing code, I think there are actions and security activities that you don't need to be a security expert to do but will harden your environment. And I can talk from the vulnerability side, from the open source vulnerability side and we'll use PCF as an example as well. From the minute a developer writes code, okay, they're gonna be writing code, there's potential for them actually writing their own vulnerability, writing their own vulnerable code. So there are tools available that can actually scan your source code, have some static analysis of your source code. You're also gonna be pulling in vulnerable libraries. There are tools, Nick is an example of one of them that can check the vulnerable libraries that you are using against its vulnerable library database and it can tell you which vulnerable libraries you are using, which are the remediation steps. So if you have vulnerabilities in your direct or transitive dependencies, you can get remediation steps as to this is the direct dependency you need to be using to get the transitive dependencies without vulnerabilities. And then that can end up as an automated pull request which can make that change for you. Then when you go into CI CD, your CI environment, your Jenkins build, that can also run a full test to check your vulnerabilities and fail the build if you are using vulnerable code, you are pulling in vulnerable code. When a developer sends a pull request, we, for example, at SNCC, we automatically test every single pull request on a webhook so that any chance, any delta of code changes that a developer will put into that pull request will be tested and you can set it up to a fail and merge if new vulnerabilities are being added. And then pushing into production, if a new vulnerability occurs, what happens? Well, one of the things we do is we automatically create a pull request against your repository with the fix. So you don't need to be a really in-depth, detailed security expert to do this. You just need to be aware of the problems and aware of the solutions and you then go in and try and enact those solutions. So there's some practical advice in the CI CD pipeline for the few guys that love this. There's a point too where we kind of bring security into the full, that Paul Trzowski in his last session was like, we got to drag security into this because sometimes that's one of the problems. And I was thinking recently, I was talking it up at a security kind of insider security thing and I was like, yeah, Linting and they were like, Linting never heard of it, no idea, right? You're like, okay, well, you can actually do some like easy quick security checks doing some Linting, right? And so we kind of talked through that process but exposing them to kind of what hooks and things are in place in the pipeline because security people are smart people. You just got to help bring them along for the process otherwise we'll kind of continue the silos. So we're getting towards one of my favorite points on this which is enabling services. You mentioned it on Twitter, creepy, I've been reading this Twitter, I get bored. There's paved roads from Netflix. The idea being that if your security team are doing it well, they'll start offering services. We'll deal with your logs, we'll deal with your WAF, we'll deal with managing the packages you're using. So these aren't problems for you. And when you start doing this right, you get to this magical guide rails, not gates. Or my personal favorite, the carrot shape stick. The idea being that you can do it any way you want but if you don't do it our way, it's not gonna work. And that's when you really start improving the security whilst making it a process they barely notice and just walking along the road. Yeah, I had a friend of mine who came up to me and he said, hey, he's worked at a big enterprise. They're just now getting the DevOps in the cloud so you know, whatever. But a lot of folks can be in that space and he said, okay, what should I do? I'm security guide, director of security. And I said, yeah, you need to never say no. Like you need to figure out a way to always say yes to these people because they're ready to route around you and just do whatever they want. There is nothing more creative than a dev told no. Yeah, and yeah, and I think building this paved road that they do in Netflix is like make it so it's easy and free to get security. And really, that's really security's only option because we don't have enough people in the industry to fill the vacant seats now, much less if we tried to staff up more. So like their only way is to automate themselves through this process, so. I think we're a little bit over time. Do we have a few minutes to do questions or should we just, all right. One burning question. Do we have one question for the panel? Otherwise. Half a question. Is it really sneak? It's a, it's sneak. Okay, all right. Kind of in between the two. I will never get that right. That is not something I would have thought of at all. All right, going ones, going twice. All right, so I want to thank our panel today. Thank you, and of course you audience today for your time. It's been a pretty good discussion. I think it's a lot of progress that the ecosystem has made, I guess, overall for the platform and I think using and extending some of the capabilities of Cloud Foundry so that customers can essentially implement those, think of security, not just, hey, I bought myself a platform or I bought myself a couple of tools. You really think about the picture as a whole. All right, that brings us to the end of this session. Thanks, everybody.