EP100 2022 Accelerate State of DevOps Report and Software Supply Chain Security

Security running.

Hi there. Welcome to the Cloud Security Podcast by Google. Thanks for joining us today. Your hosts here, as ever, are myself, Timothy Peacock, the Senior Product Manager for Threat Detection here at GCP, and Anton Chuvakin, a reformed analyst and senior staff in Google Cloud's Office of the CISO. You can find and subscribe to this podcast wherever you get your podcasts, as well as at our website. cloud.withgoogle.com/cloudsecurity/podcast. If you enjoy our content and want it delivered to you piping hot every Monday afternoon Pacific time, please do hit that subscribe button. You can follow the show and argue with your hosts on Twitter as well, twitter.com/cloudsecpodcast. Anton, we're having an AppSec episode today, aren't we?

You know, you'd think so.

And initially I thought that because this episode involves DevOps and, you know, our report— The DORA report. The DORA report, exactly. I sort of assumed it would be a lot about application But my assumptions were proven partially incorrect.

Listeners, you hear that? Anton's willing to admit he was partially incorrect.

There is that. But it turns out that it's software supply chain security, which in my naivete, I assumed to be part of AppSec.

Well, I think that makes a lot of sense. But I also think it goes beyond AppSec. And perhaps it shouldn't be too surprising we're talking about supply chain security since we had guests from ChainGuard today.

That's exactly right. And I think the supply chain is a fun and scary problem for a lot of people.

And I think I just have this impression that people just aren't Well, you were quite freaked out on the Eric and Aparna episode we did initially about supply chain security. So listeners, if you don't remember that episode, go back to last summer, check out the episode we did with Aparna and Eric about supply chain security, but do that after you listen to today's episode. And with that, let's get into it. Listeners, I'm delighted to introduce today's guests. Today we have 2 special guests joining us. joining us. From within Google, we have Todd Kaliza, a staff user researcher, and from ChainGuard, we have John Speed Myers, a principal security scientist. John Speed, you've got a fascinating background. It's somewhat similar to mine. I think I have not as fascinating, but definitely a weird one for our security industry. So tell us about your background and how you got into this crazy industry we call cloud security.

Yeah, I'm really a public policy researcher by background. Mostly did research at think tanks, research and analysis on military weapons systems. And what I ended up finding is that most military weapons systems are actually computers wrapped in steel. And once I thought about it that way, I got interested in software security. I ended up at a place called In-Q-Tel, something like a venture capital firm for the US intelligence community. It's a weird place. But from there, I learned about a range of startups focused on software supply chain security and came to ChainGuard. And I do research in their R&D team of just a couple of us on software security there.

Have you heard the urban legend about the missile with the memory leak?

I don't know it. Please.

Oh, well, somebody was looking at the control systems code for a missile, discovered a memory leak, and they were told, well, that doesn't matter. The computer explodes before it runs out of memory. Terrifying.

Sounds right. Yeah, sounds about right.

So tell us how you got involved in this year's DORA report and what that's all about.

Oh, I'm sure there was some nepotism involved, but what I really think is that someone at ChainGuard was asked to get involved in the security section of the report, which especially deals with software supply chain security. And so there's a couple of us that do security research on this at ChainGuard. And because I'm the one that's more of a public policy background, do surveys and that sort of stuff, got asked to do it.

So wait a second. So we need to take another step back because ultimately DORA at this point, funny enough, has a— there are a couple of acronyms in our industry that are DORA. And of course, if we are talking about Google's DORA, which is the DevOps Research Report, which now includes security, Any context on this that you want to share? And also, wait, wait, while I'm asking this question, I've seen people kind of obsess about supply chain security. And to me, when I think about AppSec, application security, supply chain is kind of a pillar. If you wake me up at 3 AM and say, Anton, is supply chain security the most important part of AppSec? I probably would not say yes at 3 AM. So help me understand this.

So yeah, to take a step back.

Another step back, right?

Yeah.

So as you said, DORA stands for DevOps Research and Assessment. Like this is a long-running survey, right? And it collects information about developing and delivering software and all of the associated outcomes there. We first asked about some supply chain security practices as part of the report last year and saw kind of an early link there with some performance-based outcomes. And so this year we wanted to do a more rigorous investigation. specifically of supply chain security. Part of the reason that we focused on supply chain security here, as opposed to, as you very rightly point out, this is a much broader area. This is a really good match for the audience who typically responds to the DORA survey, which is largely developers themselves and DevOps practitioners. And so, this is a great vehicle to actually reach that audience. And so, we felt it was one of the most appropriate— blocks to include on the survey outside of kind of the traditional DevOps blocks?

If for a second I assume a more cynical outlook on life, I would think that it includes software supply chain security and not maybe other parts of AppSec, like, I don't know, scanning for static— scanning the source code. It's because it's easier for developers to understand the supply chain, but it's harder for them to understand how the SAST or DAST tools function. Is this too much or not?

No, I would not phrase it that way. We can only ask so many questions on any given survey. And so for us, this was considered to be a very high priority topic. The survey was already very long, and so we already were making a lot of tough decisions about what we should use this vehicle to research and where we might want to find other avenues for that research.

Anton, you should relate to that. We sometimes struggle to not ask too many questions ourselves.

Yeah, there is that. And I think that We've kind of struggled with AppSec in the cloud. The reason I'm dragging us in this direction is because as a former analyst, I like to have a clear picture of a domain. Maybe I wouldn't know all the answers, but I want to have a clear picture. AppSec in the cloud still does not quite form a clear picture in my head. And again, I'm not an AppSec person. I'm more of a SecOps data security. So, it's easy for me to not have a clear picture in an area I don't focus on, but it still bothers me a little bit that people don't have a very crisp framework for thinking about AppSec in the cloud, right?

We should do an episode on that, but we should stay focused on this topic. We tried it twice already.

No, no, no, no, no. We tried it twice.

I think you're right that software supply chain security specifically is, A, one of only a much larger set of categories, AppSec especially, and 2, its boundaries are blurry and contested. And there certainly is no single definition that if you got 100 persons interested in software supply chain security and said, what is it? you're going to get 150 definitions. So it's broad right now, but it's clear that there have been a couple, you know these events probably better than I do, but SolarWinds and Log4j, but there are a number of others too that have—

There's one coming tomorrow. The day we are recording this is of course still the very last day of October, and I hear there is another day coming tomorrow.

Yeah, another OpenSSL vulnerability. And so I think it depends how you frame it, but it's I mean, there's just no way around it. This, this term and this concept has really grown in prominence over the past arguably 2 years.

I think we all agree that this term goes way back in history too. I mean, Untrusting Trust really sort of started it in my mind. So I want to dive into some of the more tactical stuff in the report while we have time today. And so could you lay out for us maybe the difference between SALSA and SSDF and, you know, what's going on with those 2 things?

Yeah, glad to. Well, SALSA, which is an acronym for Supply Chain Levels for Software Artifacts, So you put that together and skip some parts and you get SLSA.

Hmm.

This is a— it really has Google origins as a framework, but now it's actually a working group and specification out of the Open Source Security Foundation. And it's about end-to-end integrity for a software supply chain artifact, for a software artifact. So it's really about preventing tampering. To oversimplify, you could say this is an anti-SolarWinds framework. SSDF, Secure Software Development Framework, it comes out of NIST. National Institute for Standards and Technology. Sorry if I got that a little wrong.

No, that sounds right.

And it is a framework for developing secure software. It's in some ways much broader than Salsa and helps protect against both unintentional and intentional compromise.

Oh, now that's interesting. And listeners, if you want to learn more about Salsa, we did a whole episode talking about it last year with Eric and Aparna, and that was quite a fun episode. So of those 2 frameworks, how's adoption going? How are companies making use of these? What's, what's it all look like?

Yeah, I'll start with that. Todd and I were able to use the DORA survey to actually answer those questions directly, and which is cool because it's surprisingly hard to do that. There's a lot of companies out there, a lot of developers, they're all doing things very differently. Well, this report, it was able to survey over 1,000 developers on exactly the question you asked, and I'll say the I think there's good news mainly for both frameworks in that these practices are associated with SLSA, associated with SSDF. They're not esoteric. They're not uniformly practiced. But on many of the different security controls, you'll find not extremely widespread, but moderate adoption. You know, half, for instance, half of respondents saying that these practices are either established or moderately established. So I think it's actually a pretty good news story overall. It varies across questions.

So one thing I've picked from reading the DORA report is that there seemed to be a correlation between well-put-together development organizations and well-secured software. But one thing I did miss is I wasn't sure, I wasn't really sure whether it's a connection established with like titanium bars welded to it or more like a connection with a string. Like, how correlated, how connected are they?

That's a good question, first off.

Thank you.

It is a statistically significant connection. I want to be clear on that. Like, all of the responses that we're talking about today, we've looked at essentially from a statistical viewpoint and said, these are definitely meaningful connections. In the case of, like, organizational culture and security and the overall benefits that you get out of both of those things, I do suspect there's a little bit of kind of a feedback loop there that they sort of play into one another and feed off of one another. And so, it can be really challenging to tease apart specifically what kind of an impact you're getting from the security automation versus what kind of impact you're getting from a healthy organizational culture or the presence of a CI server or version control or some of these other things that people do. The big thing to take away from, I think, one of the security findings is that we were finding overall, this actually makes for a better developer experience, that developers say they are less burned out, that they are more likely to recommend their team as a good team to work on, which essentially means, or it's some early evidence at least, that you can get these security benefits without having them come at tremendous cost to developers, the productivity of the overall organization, the culture of the team that you work on, and things like that. Does that answer your question?

Well, so there's a couple of interesting pieces in there. One, you talked about statistical significance, and that's great. I don't always see that in this kind of research. And then 2, Could you say that part again about how having these SSDF and SLSA frameworks in place or following those kinds of things help developer happiness and productivity? That's really cool because so often security gets in the way, not helps with the actual thing of development.

But we've seen that in the cloud too. Sorry for interrupting, but we've seen it in the cloud sometimes when we deploy something in the cloud, we do see the double benefits of things being better for business and more secure. So I don't— okay, fine. I stole your thunder.

I'm sorry.

Yeah, go.

No, no, Todd, tell us about the link between the security security stuff and the developer productivity and happiness and saying this is a good team stuff? Because to me, that's really interesting.

For me, the big hypothesis is that automation is helping out here. That essentially, you're taking what can be a lot of fire drills and sort of unplanned work and turning it into hopefully more structured or more planned work. For example, if you're doing vulnerability scanning at CI time, at the very least, your developers now know to expect that. That is when we're going to be seeing reports that, hey, we're depending on dependencies that have some potential vulnerabilities in them. Now, I would argue you can go even a step further, shift that further left, so that if developers can run those scans when they're selecting their dependencies initially, that tends to work out even better for them. But the general idea here is that as you start to automate these tasks, that becomes better for developers because it fits more into their structure. It's less unplanned work overall for them. And thus you're getting some of these benefits of supply chain security without seeing it come at huge costs.

So it's the upside of no surprises.

Yes. Good way to phrase it.

Which obviously helps security and happiness and productivity and a bunch of other things. So that part does make sense. So I want to dive a little bit more in the report. And I think some of the findings, especially making them kind of usable and comprehensible to people who are not developers, because we at this podcast, we sort of face the opposite problem a bit, right? Because most of our audience is security people and cloud people, cloud security people maybe even, but less so developers. So for example, the whole adoption of software supply chain practices, is this kind of a new cool thing? Is it something that everybody must be doing or is it something more aspirational and, you know, come back in 3 years to ask this question kind of thing? So where is the adoption with these practices?

Yeah, I think it's fair to say that a number of these practices are already adopted. What we saw is that, for instance, with things like centralized CI servers, or gosh, even the least adopted of them, which is 2-person review, 2 trusted person review, actually has a number of organizations that still reliably and systematically do this. This is not just a Google practice, for instance. There are many software producers that do these SLSA-related practices in SSDF. But I think it is fair to say that it's highly uneven. The interesting thing about this survey is they actually asked about your software practices on the primary application or service that you work on.

Oh.

So in some ways, what you're seeing here is the rosiest picture because presumably you would invest a lot of time and effort on your primary application. So I think one thing that's under the surface of these findings that of course there are many other There could be, I guess you could call them secondary applications or services you work on, and you probably presumably do less secure versions of whatever you see in the survey. So very likely there is at the top of the iceberg a bunch of well-defended, well-secured applications and services, and then there's the things the survey doesn't cover, which there's probably a lot of room for improvement. But hard to say what's not covered with the survey.

To add on to that, John Speed's absolutely right. We asked the questions around the SALSA framework in terms of how established are these practices at your organization. And so, while we did see a lot of people saying, you know, this is moderately established, this is very established, the numbers got much lower for people who said these things are completely established, which would cover, you know, all of the different applications that you may be aware of. So, I think he's absolutely right that We're talking about kind of the main things that people are working on, and there's been efforts to secure that part of the supply chain. There are going to be other things in your organization that probably don't have those practices in place yet, and this is sort of an acknowledgment of that.

And so, Todd, are we going to look at how that improves in next year's report?

Potentially. I don't really have a plan there quite yet.

One thing that struck me as another lesson, possibly from the report, that sort of connected with DevOps and SRE kind of practices, the whole blameless culture, which we— what's the polite term? Just don't have in security. I'm not going to make any pithy jokes or curse words or anything. We just don't do blameless all that well. Well, we here at Google do, but generally, the security industry does not do blameless well. So, what are the secrets we can learn from DevOps blameless culture to use it for security supply chain and possibly elsewhere in security?

Oh gosh.

Easy one, right? That's an easy one.

The sad truth is that where exactly this blameless culture comes from, these— this generative culture is also the term of art you've seen— isn't covered by the survey. What is the magical ingredients that you can use? It's actually very good about is delineating what are the elements of it. And I think there's a set of— it's almost mental attitudes. It's certainly not technical controls that you can adopt. How to get those is a little different, but it's things like having cooperative attitudes. It's feeling a collective sense of responsibility for security problems or any other problems that you find and not thinking that because your role is narrow in some way, that that is certainly not your responsibility to deal with. So this set of practices, which you can read about, generative culture, I think is what you want to adopt. Ideally, but where exactly it comes from, I'm sorry, that's a secret mystery that I'm also trying to unravel.

I mean, that sort of psychological safety to have those open conversations, that's hard to develop. But we did talk about psychological safety and belonging in what came out last week with Share the Mic in Cyber. And I think often on the podcast, I joke that CISOs don't need another piece of technology, they need a family therapist. So speaking of families, although a different kind of family, one of the pieces of advice I got early in my career at Google was, as a PM at Google, your goal is to build your mafia of allies in different parts of the org. What advice would you have for a CISO when it comes to making a mafia out of the DevOps world?

Yeah, I think there's a couple of things you can do. This is more aimed at developers and what CISOs do, but I think in general, there is a tremendous fear of the compliance style of governance that comes out of CISO offices. One way to get around that, I think, because it's not viewed as compliance, is having a CI system that consistently and reliably and hopefully quickly and without glitches runs the security checks. Because the CI system isn't seen, I think, in the same boring way as filling out a security checklist or—

Oh yeah.

Contacting the security team to have some onerous security review. It's like, well, this is just my normal standard operating procedure. I simply have to get all the green checks to pass and then I get a merge. And this actually shows up in the finding. If you can have CI implemented, it actually is this important foundation that makes it much more likely all the other software supply chain security-related controls are implemented. So I would say that's kind of the surprising thing. A really good CI with all that automation that Todd talked about That can be a CISO's best friend.

Now that's really interesting because that's actually a piece of technology that solves the problem, not some new piece of psychology for people. That's great.

It's not the, in some ways, the cool sexy technology. It's something that's simple, but it turns out to change the psychology. I think it feels different.

Yeah, I think there is psychology at play here because it's already part of the developer's workflow, essentially. It's not this extra checklist or extra touchpoint that you need to go through to kind of get sign-off for whatever it is that you're working on.

That is fascinating. And it's always like, it's interesting how— sorry, I'm going to go pontificate for 30 seconds because sometimes we do want a technical solution to a societal problem. And that's the right call because ultimately phishing to me better be solved technically, not by education. So phishing, they say, oh yeah, phishing is about the user. Well, actually no, phishing is about building an unphishable auth. And so in that sense, we've solved a broader problem by technical means and that's the right call. But sometimes we have a cultural problem and we can't solve it by technical means. So this seemed to be in the solvable by technical means bucket, which is good.

Absolutely.

There's probably an evolution of things into solvable by technical means. I mean, until we had FIDO and WebAuthn, we really didn't have unphishable auth. We had harder-to-phish auth.

That's fair. Yeah.

So let's go to some other maybe more fuzzy matter. And this is kind of a— I was reading the DORA report, and somebody somewhere said it would prevent vulnerabilities. And of course, my security mind initially went into the, you know, rage. Because it's pretty clear to me that you can't prevent all vulnerabilities. And whoever is trying to prevent all vulnerabilities is gonna fail, and it's gonna be a lot of embarrassment and fun. I mean, that type of stuff. But it does seem to be that some of the practices do reduce the chance of a severe vuln quite a bit. And there's very measurable and very real dynamic at work that makes vulnerabilities, especially bad ones, less likely. So how should security and developers and DevOps work together to maybe not keep vulnerabilities out, but reduce them dramatically?

I like the way you framed that, first off, because, yeah, any system that involves humans in it, there's always room for error. We need to anticipate that. And again, coming back to the idea of automating as much as we can, that can help to reduce some of the human error here. For me, I do view dependencies as one of the key things to focus on in terms of keeping vulnerabilities out of your software, because if you're building on libraries that have vulnerabilities, then you are inheriting those vulnerabilities along with all of the other beneficial things of the library. You're also getting that risky component of it. And so we talked earlier about the importance of CI overall in these systems, and that is a great time to run those vulnerability scanners to ensure that your dependencies don't have any known vulnerabilities in them as your software's kind of moving through that pipeline. Then you can go a step further and tools like npm audit or go vuln check, which is a new preview tool that the Go team has put out, allow developers to run these scans locally. This is not part of the DORA report, but my own research involves talking to developers and the things that they do to try to make their code more secure. And they talk about the benefit of running these scans locally as twofold. One is that, you know, upfront now, hey, I just started to build this thing or just started to incorporate this third-party library and I know before I put any effort into building on top of that, whether this is a secure foundation for me, whether this is something that's even going to pass company policies if I was to try to put it into our codebase. The other aspect there, and this is heavily dependent on context, CI systems can sometimes take a long time to run. With Go, we often hear about minutes, tens of minutes, but other languages, it's not uncommon to have a CI run that's incorporating your full test suite that can take hours to run. If your queue for CI gets full, now you've got developers that have maybe a multi-hour wait before they're even able to get feedback, particularly around, you know, what they just did to hopefully resolve a vulnerable dependency. And so, if they've got a multiple-hour feedback loop to even understand, hey, if upgrading this dependency to the latest version fixes the problem that we found from the vulnerability scanner, versus the ability to do that locally and just get that feedback in a matter of seconds or minutes, as opposed to hours. So, 2 big advantages to being able to run that locally. But besides dependency scanning, security and DevOps, I think, can also work together to kind of secure the source code and build infrastructure as well. And that's where the Salsa framework really starts to, I think, support kind of a plan of action here. So, for example, you can start just by scripting out what it is that your build does, even if you're maybe still making production builds on a developer's workstation. Once it's scripted, it's really easy now to move that over to a hosted build solution in the future. Once it's there, you can start putting more scanners or linters or, you know, code health scanners essentially on top of that. You can start using cryptographic signatures to verify the artifacts coming out of that have not been tampered with versus what you see in production. Basically layering the security, kind of building, you know, one level on top of another level on top of another. It makes it possible to adopt these things one stage at a time and improve your organization's security posture as you're doing that.

So that's a really great answer about the preventive side. What about the detective reactive side? So once we've got a vulnerability, how does security and DevOps work together to respond quickly?

Yeah, I think there's starting to be a stock answer to this response, which me by setting it up suggests that there are some complications, but software bill of materials, really just a recipe list, a set of dependencies all the way down, preferably. Has become this idea that it's come of age in some ways. Everybody's talking about it, but it's because it's sensible. When you have a software application or a service, you should know everything that's in there, ideally at least. It just turns out, and even enthusiasts for SBOMs will concede this, that's why there's so much hustle and bustle and activity. It's actually very hard to figure out how to store and parse and make usable all this SBOM data. So in many ways, the SBOM set of activities has really shifted from generation over the past year or 2 to analysis and querying. And it's the Wild West right now. Everyone's figuring out how to do this and have it be easy and usable. And I don't have answers because I'm not sure really anyone does yet.

That does make sense. And I think that there's— it's not like there's magic. There's some magic, but there's not like easy magic. You wave a wand and you're done. So that to me is there. So, let me ask you a strange question that will possibly demoralize you a little bit. Sometimes compliance and audit comes into the picture, and people show up with little clipboards and with little blunt pencils, and they try to reduce your 2022 modern security practices to, like, big, fat crayon checkboxes on a compliance board.

So—

Yeah.

This helps somehow, right? All this modern application supply chain stuff does help with this as well somehow, right? I hope.

I think it does. At the end of the day, I do feel like this is largely about trust. And to your point of you've got auditors maybe looking at the system or the systems that an organization has, how much do you trust that they're actually seeing all of the systems, right? There are very likely things that do not go through the standard CI approach, even though everyone's supposed to. There are always these little one-offs, and that's going to be a vector for risk going forward. I don't know how you prove to someone that all of your software is built using the exact same pipelines necessarily, because there's that unknown, unknown problem there where the auditor doesn't necessarily know what to look for. Quite frankly, most of the engineers in the organization may not know what to look for because it could just be one person stood up this one server for this random task, and it's been running ever since for 10 years, and the institutional knowledge about it is now gone. This is outside of my area of expertise. I want to be really clear, but it just seems like it's fundamentally a trust problem there. And so it's really good to bring as much as you can into that sort of well-lit path of this goes through secure source control to CI to our CD servers, and we know this is being monitored properly. It's a hard answer because you don't know what's not going through those systems.

I think there's starting to be an economy even of these organizations. It's just starting now where saying, well, how do I do third-party assessments, for instance, for SALSA? And it's very early. But I think the general outlines are clear that you can in fact boil SALSA down to something that goes on a piece of paper. It's hard. There will be disagreement from different parties about how exactly to do it. But I think it can be done, at least with people with some requisite knowledge. And that will be what you see over the next few years, SALSA, SSDF, and others, when organizations want to attest or have a third party attest that they follow these But it's going to be a messy process.

I'm very upset about the idea of boiling salsa. The Californian in me is just not having any of that. So, we're at the point now, on that horrible note, where we have to ask our traditional closing questions. And so, aside from the DORA report, do you have recommended reading? And 2, do you have a recommended tip to help people improve their DevOps security partnerships?

I might recommend salsa.dev since we've been talking about it. It's just, it's salsa.dev. It's the website where you'll find all the Salsa-related activities, and you can join the open source community associated with OpenSSL. Worth checking out. And I had to recommend something to make both the DevOps and dev team happy together. I think one, there's a common mental framework you see of scan everything, fix it, And I think that's good. There's another way of start clean, start minimal, and avoid the vulnerabilities by using known good components. I would suggest realizing that those are 2 different approaches, and the second at least has conceptual merit but is different.

For recommended reading, I don't think I have anything better than salsa.dev either. In terms of, I guess, the takeaways here, one big one for me is kind of the impact that unplanned work can have on the developer experience, that this is generally a frustrating thing for developers. I think there was some early data from elsewhere in the DORA report kind of talking about how this links to burnout. There's a negative correlation there, or sorry, it leads to burnout. It's a bad thing.

It's a correlation that's negative if you want to avoid burnout.

Correct.

Thank you.

So, anything that you can do in the security space that reduces unplanned work, and one thing that has come up are these basically vulnerability reports, that when developers get this, their first instinct is usually to just upgrade the vulnerable dependency itself and hope that that resolves it and that all their tests pass after that. And if that works out as expected, they are done. It's kind of back to regular, your regular scheduled programming at that point. If that does not work out, all of a sudden we are in the territory of, okay, now we need to investigate this deeply. We may need to delay a release. We may need to pull engineers from other things off to deal with this. And so trying to basically help developers in that first case kind of get through it quickly and understand when they need to focus more on that second case, I think, is an open area for research. I don't have a great solution as to exactly what that looks like. One of the things I think we're kind of exploring right now is the possibility of doing some of the— basically trying the update and running tests for you if you already have those written, and thus being able to kind of give you a preview of, hey, if you do this, here's what you can expect. But for the, uh, the more in-depth investigation path of that decision tree, that can still be a lot of unplanned work.

I got it. Those are very interesting answers. Todd, John Speed, thank you both so much for joining us today. Listeners, I hope you found this as interesting as we did. We were looking forward to this, and in my opinion, this conversation did not disappoint.

Thank you for having us.

Thank you so much. This was really fun.

And now we are at time. Thank you very much for listening and of course for subscribing. You can find this podcast at Google Podcasts, Apple Podcasts, Spotify, or wherever else you get your podcasts. Also, you can find us at our website, cloud.withgoogle.com/cloudsecurity/podcast. Please subscribe so that you don't miss episodes. You can follow us on Twitter, twitter.com/cloudsecpodcast. Your hosts are also on Twitter @anton_chuvakin and @_timpego. Tweet at us, email us, argue with us, and if you like or hate what you hear, We can invite you to the next episode. See you on the next Cloud Security Podcast episode.

Security.