WEBVTT 1 00:00:00.000 --> 00:00:01.860 Michael Novinson: Hello, this is Michael Novinson with 2 00:00:01.860 --> 00:00:05.430 Information Security Media Group. I'm joined today by Sam 3 00:00:05.430 --> 00:00:08.940 King. She is the CEO at Veracode. Good morning, Sam, how 4 00:00:08.940 --> 00:00:09.270 are you? 5 00:00:09.870 --> 00:00:11.730 Sam King: Doing good. How are you doing, Michael? 6 00:00:12.270 --> 00:00:13.860 Michael Novinson: I'm doing really well, thanks so much for 7 00:00:13.860 --> 00:00:14.610 taking the time. 8 00:00:15.420 --> 00:00:16.170 Sam King: No problem. 9 00:00:16.660 --> 00:00:19.480 Michael Novinson: Wanted to dive in here. Just last month, you, 10 00:00:19.480 --> 00:00:22.660 at Veracode, had announced a container security offering. And 11 00:00:22.660 --> 00:00:25.390 I wanted to give a little bit more color around why you 12 00:00:25.390 --> 00:00:28.510 decided to invest into container security, first off, and then 13 00:00:28.510 --> 00:00:30.760 secondly, what do you feel differentiates your approach to 14 00:00:30.760 --> 00:00:33.280 container security from some of the other players in the market? 15 00:00:33.900 --> 00:00:38.580 Sam King: Yeah. So the reason that we did this is that we are 16 00:00:38.580 --> 00:00:42.960 looking at the ways in which our customers are developing and 17 00:00:42.960 --> 00:00:48.810 deploying software and with the massive move to cloud-native and 18 00:00:49.830 --> 00:00:52.590 new application development, starting with cloud-native 19 00:00:52.590 --> 00:00:56.550 principles in mind, and a lot of migration going on of monolithic 20 00:00:56.550 --> 00:01:00.060 applications into microservices, etc. that are ultimately being 21 00:01:00.060 --> 00:01:03.090 transformed to run in cloud-native architectures, 22 00:01:03.150 --> 00:01:07.500 there's increasing use of containers. And it is an area 23 00:01:07.500 --> 00:01:11.070 that we wanted to extend our security solutions to. And the 24 00:01:11.100 --> 00:01:16.350 approach that we have taken is we ultimately are all about 25 00:01:16.350 --> 00:01:19.350 building a bridge between the security team and the 26 00:01:19.350 --> 00:01:23.160 development team. So we think that both those constituencies 27 00:01:23.160 --> 00:01:26.250 matter tremendously if we're going to get software security 28 00:01:26.250 --> 00:01:29.430 done the right way in the future. So what we have come out 29 00:01:29.430 --> 00:01:32.850 with is a capability that is extremely easy for developers to 30 00:01:32.850 --> 00:01:36.360 use, you can use it to a command line interface, and it gives you 31 00:01:36.360 --> 00:01:39.840 very quick results where you can get intelligence on what you've 32 00:01:39.840 --> 00:01:41.520 got in your container, what might be some of the 33 00:01:41.520 --> 00:01:45.000 vulnerabilities that are present in there. But then also provide 34 00:01:45.000 --> 00:01:48.540 it in such a way that the security team can, overtime, get 35 00:01:48.540 --> 00:01:51.570 information around what kind of software has been developed, and 36 00:01:51.600 --> 00:01:54.420 what kind of policies are being practiced in the organization. 37 00:01:54.000 --> 00:01:57.900 Michael Novinson: So you moved into the container security 38 00:01:57.900 --> 00:02:00.570 space from your heritage and application security. And I was 39 00:02:00.570 --> 00:02:03.180 wondering what do you feel the benefits are from that versus - 40 00:02:03.180 --> 00:02:05.220 we've seen, obviously, a number of standalone container security 41 00:02:05.220 --> 00:02:08.370 startups as well as cloud security companies, CSPM, SIEM, 42 00:02:08.970 --> 00:02:11.280 CASB companies move into container security. What's the 43 00:02:11.280 --> 00:02:14.040 benefit about moving into container security from the 44 00:02:14.040 --> 00:02:15.960 application space versus the cloud space? 45 00:02:16.350 --> 00:02:20.340 Sam King: Yeah, great question. Because with things like 46 00:02:20.340 --> 00:02:24.660 container security and so forth, you see a little bit of 47 00:02:24.690 --> 00:02:27.870 migration into those areas from people that do software 48 00:02:27.870 --> 00:02:30.540 security, as well as people that do infrastructure security, 49 00:02:30.540 --> 00:02:34.680 right? So for us, everything is about securing software. So we 50 00:02:34.710 --> 00:02:38.400 approach all problems software-out, right? So we're 51 00:02:38.400 --> 00:02:41.220 not saying, "Hey, here's a set of infrastructure-level 52 00:02:41.250 --> 00:02:43.260 vulnerabilities that we're providing to you. And here's a 53 00:02:43.260 --> 00:02:45.540 little something that we can tell you about containers or 54 00:02:45.540 --> 00:02:48.810 your infrastructure as code," etc. right? We're approaching 55 00:02:48.840 --> 00:02:51.990 everything from the standpoint of what makes up the software, 56 00:02:52.080 --> 00:02:54.960 what's in that container, how much of that is your code, how 57 00:02:54.960 --> 00:02:56.550 much of that is open-source code, what are the 58 00:02:56.550 --> 00:02:58.710 vulnerabilities that are present in it, what are the known 59 00:02:58.710 --> 00:03:01.830 vulnerabilities, how do you go fix those vulnerabilities. So 60 00:03:01.830 --> 00:03:05.340 for us, everything is driven from software-out because 61 00:03:05.370 --> 00:03:08.640 ultimately, it's about making what is in the container secure. 62 00:03:08.790 --> 00:03:11.340 Whereas, I think a number of other providers that have come 63 00:03:11.340 --> 00:03:15.000 at this from whatever their core was outside of software 64 00:03:15.000 --> 00:03:18.870 security, or potentially looking at it more outside-in, looking 65 00:03:18.870 --> 00:03:20.910 at maybe how the container is running in the runtime 66 00:03:20.910 --> 00:03:24.150 environment, and so forth. Whereas we are focused more on 67 00:03:24.300 --> 00:03:27.090 what does the container contain. And what are the vulnerabilities 68 00:03:27.090 --> 00:03:30.060 you are inheriting and therefore running in your production 69 00:03:30.060 --> 00:03:31.500 environment as a result of that. 70 00:03:33.070 --> 00:03:35.380 Michael Novinson: Interesting. Want to get a sense from the 71 00:03:35.380 --> 00:03:38.050 standpoint of existing customers who've been using you for 72 00:03:38.050 --> 00:03:41.770 application security today. What are the primary benefits of them 73 00:03:42.220 --> 00:03:45.910 buying into your container security offering, an extender 74 00:03:46.480 --> 00:03:47.650 capability with Veracode? 75 00:03:47.000 --> 00:03:51.770 Sam King: Yeah, I mean, listen, one benefit, which is more a 76 00:03:51.770 --> 00:03:55.880 business benefit really than a technology benefit, is now more 77 00:03:55.880 --> 00:04:00.050 than ever before, I hear a strong desire for simplifying 78 00:04:00.080 --> 00:04:03.140 your cybersecurity program as a whole. And part of that 79 00:04:03.140 --> 00:04:07.010 simplification comes from consolidating with a certain 80 00:04:07.010 --> 00:04:10.220 number of key vendors because one of the things that I'm sure 81 00:04:10.340 --> 00:04:13.850 you observed, Michael, is that the cybersecurity industry is 82 00:04:13.880 --> 00:04:17.510 very fragmented. It's very noisy, right? But there's the 83 00:04:17.510 --> 00:04:21.380 next gen of the next gen of the next gen and enterprises, 84 00:04:21.410 --> 00:04:24.290 sometimes they're using over hundred security vendors to 85 00:04:24.290 --> 00:04:27.680 solve this problem. And so increasingly, I'm hearing 86 00:04:27.710 --> 00:04:33.140 enterprises say, "This is madness. We need to standardize 87 00:04:33.140 --> 00:04:36.380 around a set of key strategic partners that are going to solve 88 00:04:36.380 --> 00:04:40.100 our problems in cybersecurity for, let's say, software or 89 00:04:40.100 --> 00:04:43.490 endpoint or infrastructure or what have you." So in this case, 90 00:04:43.490 --> 00:04:46.700 one of the value propositions that we're offering is customers 91 00:04:46.850 --> 00:04:50.210 that have been utilizing us for testing their software 92 00:04:50.210 --> 00:04:53.120 applications, whether it was software applications they built 93 00:04:53.120 --> 00:04:56.180 or open-source code or what have you, can now also extend to 94 00:04:56.180 --> 00:04:59.600 users, a known party or trusted party to also do container 95 00:04:59.600 --> 00:05:00.200 security. 96 00:05:01.970 --> 00:05:03.620 Michael Novinson: I see, why don't you discuss this well. 97 00:05:03.620 --> 00:05:07.370 Back in August, you'd announced extended integrations around SCA 98 00:05:07.370 --> 00:05:11.840 (software composition analysis), as well as the API for SBOM. I 99 00:05:11.840 --> 00:05:15.200 was wondering why, first off, why were those areas of focus 100 00:05:15.200 --> 00:05:16.730 from an integration standpoint for you? 101 00:05:17.440 --> 00:05:23.770 Sam King: Yeah. So a term that is almost inescapable now, when 102 00:05:23.770 --> 00:05:26.620 you're talking about software security is software supply 103 00:05:26.620 --> 00:05:30.160 chain security, right? That topic has come to the forefront, 104 00:05:30.370 --> 00:05:34.870 especially this year in 2022, more so than at any other period 105 00:05:34.870 --> 00:05:37.180 of time prior to that. Now, that's not because 106 00:05:37.510 --> 00:05:40.360 vulnerabilities in the software supply chain didn't exist prior 107 00:05:40.360 --> 00:05:44.440 to 2022. They did. It's just that they got mainstage and a 108 00:05:44.440 --> 00:05:48.100 lot of attention with some of the events that we saw happen 109 00:05:48.130 --> 00:05:51.130 this year, right. So software supply chain security is a 110 00:05:51.370 --> 00:05:55.210 really high-priority item for the customers that we're working 111 00:05:55.210 --> 00:05:58.750 with. And it's for good reason. Because when they look at what 112 00:05:58.750 --> 00:06:01.270 makes up their software infrastructure, the software 113 00:06:01.270 --> 00:06:04.630 that they're relying on as an organization, a good portion of 114 00:06:04.630 --> 00:06:07.240 it is software that they didn't build, it's either open-source 115 00:06:07.240 --> 00:06:09.520 code, or it's commercial, third-party code that they're 116 00:06:09.550 --> 00:06:12.670 reusing. So the extended software supply chain becomes 117 00:06:12.670 --> 00:06:16.000 increasingly important to what is their posture around software 118 00:06:16.000 --> 00:06:19.960 security. So for us, taking something like SCA (software 119 00:06:19.960 --> 00:06:23.110 composition analysis), and being able to offer that at the 120 00:06:23.140 --> 00:06:26.350 earliest stages of the software development lifecycle where 121 00:06:26.440 --> 00:06:30.010 developer is making a decision around what they're going to 122 00:06:30.010 --> 00:06:34.090 include in their code is really powerful, because we are 123 00:06:34.120 --> 00:06:39.610 shifting software supply chain security solutions left as well, 124 00:06:39.640 --> 00:06:44.860 right? So that was the reason why we really worked hard to 125 00:06:44.860 --> 00:06:48.340 talk about, and think about, how should you take SCA and 126 00:06:48.340 --> 00:06:50.470 integrate it into the earliest stages of the software 127 00:06:50.470 --> 00:06:56.050 development lifecycle, and then our move to provide SBOM through 128 00:06:56.080 --> 00:06:59.800 APIs and just the functionality around a software bill of 129 00:06:59.800 --> 00:07:03.940 materials is to help organizations satisfy some of 130 00:07:03.940 --> 00:07:07.720 the requirements that have been put out in the executive order. 131 00:07:08.470 --> 00:07:13.720 That was issued last year, as well as, just giving 132 00:07:13.750 --> 00:07:16.750 organizations a way to demonstrate that they know what 133 00:07:16.750 --> 00:07:19.120 makes up their software infrastructure, and in doing so, 134 00:07:19.120 --> 00:07:22.930 be able to demonstrate that they're using the secure 135 00:07:22.930 --> 00:07:25.720 versions of various libraries and things like that. So we're 136 00:07:25.720 --> 00:07:30.640 really trying to further the solutions that people are 137 00:07:30.640 --> 00:07:33.400 bringing to bear on the software supply chain topic. 138 00:07:34.780 --> 00:07:36.615 Michael Novinson: As you mentioned, it has been a major 139 00:07:36.665 --> 00:07:39.890 topic of conversation this year, in particular, also last year on 140 00:07:39.940 --> 00:07:43.065 software supply chain. What do you feel is different about your 141 00:07:43.115 --> 00:07:46.092 approach, particularly to the SBOM issue, in wake of the EO? 142 00:07:46.141 --> 00:07:49.019 What do you feel is different about how you're approaching 143 00:07:49.069 --> 00:07:51.550 next month versus what else you see in the market. 144 00:07:51.000 --> 00:07:53.963 Sam King: Michael, for us, it's a similar answer to what I 145 00:07:54.024 --> 00:07:57.975 shared earlier around container security. For us, it's all about 146 00:07:58.037 --> 00:08:01.803 software-out, right? So we are looking at the code at its DNA 147 00:08:01.865 --> 00:08:05.507 level, if you will. We do, you know, binary analysis, which 148 00:08:05.569 --> 00:08:08.717 allows us to look at dependencies and so forth. And 149 00:08:08.779 --> 00:08:12.792 so what we are trying to provide is deep insight into what is the 150 00:08:12.853 --> 00:08:16.681 code that you have, and not just the code that you've written, 151 00:08:16.743 --> 00:08:20.262 but the code that you are ultimately dependent on because 152 00:08:20.323 --> 00:08:23.780 of various dependencies, transitive dependencies, and so 153 00:08:23.842 --> 00:08:27.670 forth, and illuminate what those vulnerabilities might be as a 154 00:08:27.731 --> 00:08:31.559 result of all of this code that is getting pulled in sometimes 155 00:08:31.621 --> 00:08:35.572 without you even realizing. And then the other thing that we are 156 00:08:35.633 --> 00:08:39.461 doing, because we study the code at a very deep level is we're 157 00:08:39.523 --> 00:08:43.350 also giving you a sense for - are you actually using this code 158 00:08:43.412 --> 00:08:46.807 path where there is this vulnerability present, because 159 00:08:46.869 --> 00:08:50.758 one of the problems that exists in security in general, is that 160 00:08:50.820 --> 00:08:54.771 we inundate users with lots and lots of data, right? But someone 161 00:08:54.833 --> 00:08:58.660 has to do something with that data. It's not about finding all 162 00:08:58.722 --> 00:09:02.735 these vulnerabilities but fixing those vulnerabilities. So making 163 00:09:02.797 --> 00:09:06.624 the data that we're providing actionable has always been a big 164 00:09:06.686 --> 00:09:10.575 part of our thinking around how we report out this information. 165 00:09:10.637 --> 00:09:14.526 So we have functionality in SCA around vulnerable methods where 166 00:09:14.588 --> 00:09:18.292 we are giving you a sense for the known vulnerabilities that 167 00:09:18.354 --> 00:09:21.934 are present in the open-source code you're using, but also 168 00:09:21.996 --> 00:09:25.577 whether your code is actually exercising that code path or 169 00:09:25.638 --> 00:09:29.589 not, because if it isn't, maybe you can defer the remediation of 170 00:09:29.651 --> 00:09:32.985 that later. If it's a high severity vulnerability, you 171 00:09:33.046 --> 00:09:36.874 still want to go fix it, but it allows you to prioritize where 172 00:09:36.936 --> 00:09:38.850 you bring your attention first. 173 00:09:40.410 --> 00:09:42.581 Michael Novinson: Before existing customers who've been 174 00:09:42.639 --> 00:09:46.336 using you, I mean, what's been their biggest challenges as many 175 00:09:46.395 --> 00:09:49.740 start to think or focus more on the software supply chain 176 00:09:49.799 --> 00:09:53.378 security issues last year? What have been some of the biggest 177 00:09:53.437 --> 00:09:57.017 obstacles or hurdles they've had to overcome? 178 00:09:57.000 --> 00:09:59.593 Sam King: I think it starts - it's weird, first of all, 179 00:09:57.075 --> 00:09:57.780 start to get 180 00:09:59.651 --> 00:10:03.224 finding manageable ways to wrap your arms around this problem, 181 00:10:03.282 --> 00:10:06.509 right? Because the software supply chain has a long tail 182 00:10:06.567 --> 00:10:10.198 associated with it, right? It's a large issue, it's an extended 183 00:10:10.256 --> 00:10:13.887 issue. So I think we work with our customers to help them break 184 00:10:13.944 --> 00:10:17.057 the problem down into its constituent parts, right? So 185 00:10:17.114 --> 00:10:20.630 you've got a lot of software infrastructure that you rely on, 186 00:10:20.688 --> 00:10:24.319 let's split that up into - you got your own code. So here's how 187 00:10:24.377 --> 00:10:27.835 we can work with your developers to educate them on security 188 00:10:27.892 --> 00:10:31.351 principles, integrate security testing into the SDLC, in the 189 00:10:31.408 --> 00:10:34.982 IDE, in the pipeline, etc., then you have all this third-party 190 00:10:35.039 --> 00:10:38.440 software, okay, what kind of third-party software, you have 191 00:10:38.497 --> 00:10:42.071 open source, there are solutions that you can bring to bear on 192 00:10:42.128 --> 00:10:45.298 that, there's commercial third-party code. So what kind 193 00:10:45.356 --> 00:10:48.987 of agreements do you have with your vendor community around the 194 00:10:49.045 --> 00:10:52.503 security of the software that they're supplying to you, your 195 00:10:52.561 --> 00:10:56.249 third-party contractors. So the first step is to help them break 196 00:10:56.307 --> 00:10:59.362 this down into constituent parts. So you can start to 197 00:10:59.419 --> 00:11:02.877 tackle the problem because if you just think of the software 198 00:11:02.935 --> 00:11:05.529 supply chain issue in its entirety, it can be 199 00:11:05.586 --> 00:11:08.814 overwhelming. So that's really the first challenge we're 200 00:11:08.872 --> 00:11:10.140 helping them overcome. 201 00:11:11.800 --> 00:11:13.300 Michael Novinson: Interesting. Let's shift gears here a little 202 00:11:13.300 --> 00:11:16.270 bit. Wanted to talk to you about the market landscape. Notably in 203 00:11:16.270 --> 00:11:19.930 the application security world, we saw Synopsys acquire WhiteHat 204 00:11:19.930 --> 00:11:22.060 earlier this year, and I wanted to get a sense of what the 205 00:11:22.060 --> 00:11:24.760 impact has been when you're in competitive bid situations 206 00:11:24.760 --> 00:11:27.370 during RFPs of those two organizations coming together. 207 00:11:27.000 --> 00:11:30.043 Sam King: Yeah, so I think we view dynamic analysis as a key 208 00:11:30.104 --> 00:11:33.696 part of any software security program, which is why we have 209 00:11:33.757 --> 00:11:37.044 had a dynamic analysis capability for quite some time, 210 00:11:37.105 --> 00:11:40.575 and have invested quite a bit behind our dynamic analysis 211 00:11:40.636 --> 00:11:44.167 capability in recent years, as well. And most importantly, 212 00:11:44.228 --> 00:11:47.637 bring that to market in an integrated fashion, right? So 213 00:11:47.698 --> 00:11:51.411 there's a single platform where you can do static, you can do 214 00:11:51.472 --> 00:11:54.881 dynamic, you can get those results in a similar look and 215 00:11:54.942 --> 00:11:58.777 feel. So at the end of the day, you're just getting information 216 00:11:58.838 --> 00:12:02.247 on the security vulnerabilities in your application from 217 00:12:02.308 --> 00:12:05.961 multiple engines. But those engines are really less relevant 218 00:12:06.022 --> 00:12:09.675 than the complete picture that both doing static and dynamic 219 00:12:09.735 --> 00:12:13.449 and SCA etc. provide for you. So I can see why Synopsys would 220 00:12:13.510 --> 00:12:17.041 have made that move to further extend into this particular 221 00:12:17.102 --> 00:12:20.998 area. You know, what I observed was, I think they also liked the 222 00:12:21.059 --> 00:12:24.711 fact that WhiteHat does what they do as a service. And so it 223 00:12:24.772 --> 00:12:28.242 was giving them a little bit more capability around SaaS, 224 00:12:28.303 --> 00:12:31.712 which is something that they have transitioned to versus 225 00:12:31.773 --> 00:12:35.547 something that they started out as. I think in our case, we've 226 00:12:35.608 --> 00:12:39.139 been a SaaS vendor, a cloud vendor since day one. And so I 227 00:12:39.200 --> 00:12:42.792 could see why it was not just about dynamic, it was also to 228 00:12:42.853 --> 00:12:45.957 try to get some SaaS capabilities. The question, of 229 00:12:46.018 --> 00:12:49.549 course, is always how well do you integrate it so that you 230 00:12:49.610 --> 00:12:52.350 provide a unified view to your customer base? 231 00:12:53.830 --> 00:12:56.140 Michael Novinson: Has it been different in terms of going to 232 00:12:56.140 --> 00:12:59.800 market in the months since this acquisition closed? Or has it 233 00:12:59.800 --> 00:13:03.310 looked different in terms of when you're pursuing competitive 234 00:13:03.640 --> 00:13:06.580 customers, new customers? Or is that the landscape has not 235 00:13:06.580 --> 00:13:09.130 really changed too much in that contract, even with the two 236 00:13:09.130 --> 00:13:09.850 coming together? 237 00:13:10.120 --> 00:13:13.570 Sam King: No. I mean, we have competed with WhiteHat 238 00:13:13.570 --> 00:13:17.620 effectively. We've competed with Synopsys effectively. So it's 239 00:13:17.650 --> 00:13:20.260 really just now we're competing with them as one entity, but it 240 00:13:20.260 --> 00:13:22.810 hasn't changed that much. Because the use cases for the 241 00:13:22.810 --> 00:13:24.550 customers are still the same. 242 00:13:26.520 --> 00:13:29.280 Michael Novinson: I see. I wanted to ask as well, in terms 243 00:13:29.280 --> 00:13:31.830 of the startup world, we've seen Snyk announced multiple rounds 244 00:13:31.830 --> 00:13:35.460 of layoffs in recent months. Wanted to get a sense from you - 245 00:13:35.460 --> 00:13:38.430 a two-parter. First, have you seen any changes in terms of the 246 00:13:38.460 --> 00:13:40.890 customer buying patterns or behaviors with the macro 247 00:13:40.890 --> 00:13:44.700 economic slowdown? And then secondly, have you done or 248 00:13:44.700 --> 00:13:46.980 considered any workforce reductions of your own? 249 00:13:47.410 --> 00:13:50.320 Sam King: Yeah, so great questions, Michael, because the 250 00:13:50.320 --> 00:13:54.760 macro environment is a topic that's top of mind for everybody 251 00:13:54.760 --> 00:13:58.210 right now. It's kind of - you can't not think about it, right? 252 00:13:58.960 --> 00:14:04.570 And for good reasons. So here's how I have observed the 253 00:14:05.770 --> 00:14:09.310 internalization of the macro environment inside the companies 254 00:14:09.310 --> 00:14:14.800 that we've worked with. The sense of urgency and the 255 00:14:14.800 --> 00:14:20.800 priority around software security continues to be really 256 00:14:20.800 --> 00:14:24.070 high. And if anything, is higher this year than it was last year. 257 00:14:24.250 --> 00:14:29.920 Maybe in preparation for some of the SEC requirements that are 258 00:14:29.920 --> 00:14:32.560 likely going to come out in April of next year, that are 259 00:14:32.560 --> 00:14:35.380 going to strengthen the disclosure requirements for 260 00:14:35.380 --> 00:14:39.220 public companies, talking about what policies and procedures 261 00:14:39.220 --> 00:14:41.200 they have, what management expertise they have around 262 00:14:41.200 --> 00:14:43.120 cybersecurity, what board expertise they have around 263 00:14:43.120 --> 00:14:47.440 cybersecurity, etc. So, as far as the topic of security and the 264 00:14:47.440 --> 00:14:50.380 topic of software security is concerned, the level of urgency 265 00:14:50.380 --> 00:14:53.680 and this need to act and go, do something and try to solve this 266 00:14:53.680 --> 00:14:57.010 problem for real is as high as it has ever been and if 267 00:14:57.010 --> 00:15:01.540 anything, increasing. At the same time, businesses also have 268 00:15:01.540 --> 00:15:04.630 to cater to the economic environment in which they are 269 00:15:04.630 --> 00:15:10.810 operating. So what I do see is a more stringent buying process, I 270 00:15:10.810 --> 00:15:15.820 see more connection between the procurement team and the 271 00:15:15.820 --> 00:15:19.150 business buyers to make sure that they are doing the right 272 00:15:19.150 --> 00:15:22.600 job of vetting the vendors, I see a greater orientation toward 273 00:15:22.600 --> 00:15:25.600 vendor consolidation, because perhaps with that simplicity, 274 00:15:25.690 --> 00:15:30.460 they can reduce some of the effort on their site to manage 275 00:15:30.460 --> 00:15:32.650 multiple vendors, and so therefore, do more with a 276 00:15:32.650 --> 00:15:35.410 smaller number of key partners. So that is one of the changes 277 00:15:35.410 --> 00:15:40.720 that I'm definitely observing. And in some organizations, the 278 00:15:40.750 --> 00:15:46.720 approval chains for getting especially large orders approved 279 00:15:47.230 --> 00:15:49.690 might be a little bit more scrutinized than it was before. 280 00:15:49.690 --> 00:15:52.480 So those are the changes that I'm seeing around the buying 281 00:15:52.480 --> 00:15:56.500 behavior. As far as the need is concerned, the need has never 282 00:15:56.500 --> 00:15:57.100 been greater. 283 00:15:59.250 --> 00:16:00.570 Michael Novinson: In terms of the buying behavior then what's 284 00:16:00.570 --> 00:16:04.470 been the tangible impact? Has it been primarily longer sales 285 00:16:04.470 --> 00:16:06.900 cycles, has it been that some deals just don't get across the 286 00:16:06.900 --> 00:16:09.150 finish line, because of the additional scrutiny? What does 287 00:16:09.150 --> 00:16:09.840 it actually mean? 288 00:16:10.110 --> 00:16:12.090 Sam King: I think, for us, it means that you have to get more 289 00:16:12.090 --> 00:16:16.020 people involved earlier in the sales cycle. Right? So now we 290 00:16:16.050 --> 00:16:20.010 typically try to make sure that we've got security, and we've 291 00:16:20.010 --> 00:16:23.250 got development at the table from day one, talking about what 292 00:16:23.250 --> 00:16:25.590 the needs are of each of the constituencies. So we can, 293 00:16:25.620 --> 00:16:28.410 through the buying process, help them get aligned so that when we 294 00:16:28.410 --> 00:16:31.110 roll out our solution, it has a higher likelihood of being 295 00:16:31.110 --> 00:16:33.960 successful. Increasingly, though, I think we're also 296 00:16:33.960 --> 00:16:38.580 saying, "Okay, what has shifted in the procurement environment 297 00:16:38.580 --> 00:16:41.430 inside your organization? How do we need to be catering to that? 298 00:16:41.430 --> 00:16:43.980 What do we need to be aware of?" So I think it's just a greater 299 00:16:43.980 --> 00:16:47.340 recognition of that. And in some cases, you just have to be 300 00:16:47.340 --> 00:16:50.940 prepared for - there's going to be a little bit more scrutiny in 301 00:16:50.940 --> 00:16:52.500 terms of where their budget is going. 302 00:16:52.000 --> 00:16:54.540 Michael Novinson: Interesting. From a personnel standpoint, I 303 00:16:54.599 --> 00:16:57.967 know Snyk had disclosed those two rounds of layoffs since 304 00:16:58.026 --> 00:17:01.630 June. Do you have to do any workforce reductions at Veracode? 305 00:17:01.000 --> 00:17:04.061 Sam King: So, in our case, you know, we have always been on a 306 00:17:04.121 --> 00:17:07.842 path of profitable growth. So when you look at our competitive 307 00:17:07.902 --> 00:17:11.564 landscape, I think there were several companies that were all 308 00:17:11.624 --> 00:17:15.406 around growth at all costs. And that pendulum has swung back in 309 00:17:15.466 --> 00:17:18.887 the market as a whole, that pendulum has definitely swung 310 00:17:18.947 --> 00:17:22.128 back in the direction of profitability. And companies 311 00:17:22.188 --> 00:17:25.070 that weren't previously profitable are having to 312 00:17:25.130 --> 00:17:28.131 exercise that muscle and figure out how to move to 313 00:17:28.191 --> 00:17:32.033 profitability, we have been on a path to profitability. For many 314 00:17:32.093 --> 00:17:35.694 years, we've exceeded the rule of 40. So this was a playbook 315 00:17:35.754 --> 00:17:39.356 that we were running the last few years, versus just now. So 316 00:17:39.416 --> 00:17:42.837 in that sense, it's not a new muscle that we're having to 317 00:17:42.897 --> 00:17:46.439 exercise. We are being more judicious around the use of our 318 00:17:46.499 --> 00:17:50.160 dollars for sure. So, you know, we have calibrated around the 319 00:17:50.220 --> 00:17:53.822 budget that we had set when we came into our fiscal year, we 320 00:17:53.882 --> 00:17:57.543 have calibrated around that a little bit, around do we really 321 00:17:57.603 --> 00:18:01.025 need to make all of these investments right now? Or do we 322 00:18:01.085 --> 00:18:04.806 want to watch what happens macro economically? So, we're being 323 00:18:04.866 --> 00:18:07.988 more thoughtful and more judicious in the use of our 324 00:18:08.048 --> 00:18:12.310 dollars. Year over year, we'll still be investing more in the business. 325 00:18:12.000 --> 00:18:15.660 Michael Novinson: I see. Let me ask you here. Finally, I'm going 326 00:18:15.660 --> 00:18:18.990 to ask you to gaze into the crystal ball here and give our 327 00:18:18.990 --> 00:18:21.300 viewers a sense of what they should be expecting from 328 00:18:21.300 --> 00:18:25.170 Veracode in 2023. What do you anticipate being the main areas 329 00:18:25.170 --> 00:18:27.360 of focus, the main areas of investment for you in the year 330 00:18:27.360 --> 00:18:27.750 ahead? 331 00:18:28.140 --> 00:18:30.510 Sam King: Yeah, great question. And something that I get super 332 00:18:30.510 --> 00:18:34.260 excited to talk about. So the thesis that we have is around 333 00:18:34.500 --> 00:18:37.710 bringing security and development teams together, and 334 00:18:37.710 --> 00:18:41.040 actually increasingly more than just security and development 335 00:18:41.040 --> 00:18:43.290 teams together, getting your board involved in this 336 00:18:43.290 --> 00:18:45.570 conversation, getting your executive team involved in this 337 00:18:45.570 --> 00:18:47.580 conversation, getting your procurement team, if you're 338 00:18:47.580 --> 00:18:49.800 talking about the software supply chain involved in this 339 00:18:49.800 --> 00:18:54.660 conversation. So we view our role as building bridges between 340 00:18:54.660 --> 00:18:57.810 these key constituencies that have to play a really important 341 00:18:57.810 --> 00:19:01.200 part to make sure that software is built securely, and that 342 00:19:01.200 --> 00:19:05.010 software stays secure. So with that lens in mind, we always 343 00:19:05.010 --> 00:19:07.830 think about what can we be doing more for each of these 344 00:19:07.830 --> 00:19:11.490 constituencies. For developers, we will continue to emphasize 345 00:19:11.520 --> 00:19:14.400 automation and orchestration and the integration into the 346 00:19:14.400 --> 00:19:18.000 software development lifecycle, tighter ways to integrate. We 347 00:19:18.000 --> 00:19:22.080 are very excited to be coming out with intelligent remediation 348 00:19:22.260 --> 00:19:26.550 where Michael, to date, we have scanned 97 trillion lines of 349 00:19:26.550 --> 00:19:29.850 code. And we have helped customers fix something like 79 350 00:19:29.850 --> 00:19:33.450 million security flaws. So we have a massive data set from 351 00:19:33.450 --> 00:19:37.170 which we can derive a lot of knowledge on what do code fixes 352 00:19:37.170 --> 00:19:40.200 look like. So we've been training our machine learning 353 00:19:40.200 --> 00:19:43.680 algorithms against that and are going to be doing intelligent 354 00:19:43.680 --> 00:19:47.460 remediation. So we will help to automate not just the finding of 355 00:19:47.460 --> 00:19:49.530 the security vulnerabilities, but hopefully fixing the 356 00:19:49.530 --> 00:19:52.320 security vulnerabilities too, so that we can make development 357 00:19:52.320 --> 00:19:55.350 teams more productive, right. So that's a capability for 358 00:19:55.350 --> 00:19:57.630 developers along with tight integrations that I'm super 359 00:19:57.630 --> 00:20:03.000 excited about. In terms of the security teams, we will continue 360 00:20:03.000 --> 00:20:05.490 to build on our SBOM functionality, we will continue 361 00:20:05.490 --> 00:20:08.730 to build on a flexible policy engine so that your governance 362 00:20:08.730 --> 00:20:12.660 needs can be met in a better and better way. Super excited to be 363 00:20:12.660 --> 00:20:17.430 launching real-time peer benchmarking. So we have all 364 00:20:17.430 --> 00:20:21.180 this data at our disposal, customers can go in and they can 365 00:20:21.180 --> 00:20:24.750 get a sense at any given point in time of - how does their 366 00:20:24.750 --> 00:20:27.840 software security compare to peers in their industry or the 367 00:20:27.840 --> 00:20:32.340 industry as a whole? That's really powerful data to bring 368 00:20:32.340 --> 00:20:34.890 into the kinds of conversations that are going to be 369 00:20:34.890 --> 00:20:38.550 increasingly occurring inside boardrooms and executive tables, 370 00:20:38.550 --> 00:20:42.390 right? So equipping the security team with that visibility, not 371 00:20:42.390 --> 00:20:44.940 just of your program, but how does it benchmark against 372 00:20:44.940 --> 00:20:48.360 everyone else, and then continuing to do more around 373 00:20:49.410 --> 00:20:52.020 supporting security for cloud-native application 374 00:20:52.020 --> 00:20:55.590 development, as more and more people move to the cloud. You 375 00:20:55.620 --> 00:20:58.290 saw us launch container security, we're looking to do 376 00:20:58.290 --> 00:21:00.360 more around infrastructure-as-code scanning, 377 00:21:00.360 --> 00:21:05.040 continue to build on our API scanning solution. So those are 378 00:21:05.040 --> 00:21:07.920 some of the themes and some of the areas that we're pursuing. 379 00:21:09.450 --> 00:21:10.860 Michael Novinson: Definitely a lot of interesting stuff to 380 00:21:10.860 --> 00:21:12.960 watch. Sam, thank you so much for the time. 381 00:21:13.950 --> 00:21:14.970 Sam King: Thank you for having me. 382 00:21:15.690 --> 00:21:17.250 Michael Novinson: Of course. We've been speaking with Sam 383 00:21:17.250 --> 00:21:20.370 King. She is the CEO of Veracode. For Information 384 00:21:20.370 --> 00:21:23.580 Security Media Group, this is Michael Novinson. Have a nice 385 00:21:23.580 --> 00:21:23.850 day.