A (11:06)

I'm Ben Yellen, co host of the Caveat podcast. Each Thursday we sit down and talk about the biggest legal and policy development affecting technology that are shaping our world, whether it be sitting down with experts or government officials, or breaking down the latest political developments. We talk about the stories that will have tangible impacts on businesses and people around the world. If you are looking to stay informed on what is happening and how it could impact you, make sure to listen to the Caveat podcast.

B (11:43)

Compliance regulations, third party risk and customer security demands are all growing and changing fast. Is your manual GRC program actually slowing you down? If you're thinking there has to be something more efficient than spreadsheets, screenshots and all those manual processes, you're right. GRC can be so much easier and it can strengthen your security posture while actually driving revenue for your business. You know, one of the things I really like about Vanta is how it takes the heavy lifting out of your GRC program. Their trust management platform automates those key compliance, internal and third party risk, and even customer trust so you're not buried under spreadsheets and endless manual tasks. Vanta really streamlines the way you gather and manage information across your entire business. And this isn't just theoretical. A recent IDC analysis found that compliance teams using Vanta are 129% more productive. That's a pretty impressive number. So what does it mean for you? It means you get back more time and energy to focus on what actually matters, like strengthening your security posture and scaling your business. Vanta GRC Just imagine how much easier trust can be. Visit vanta.com cyber to sign up today for a free demo. That's V A N T a dot com CYBER Randall Deggs is head of Developer and security relations at snyk. I recently caught up with him to learn how under qualified or outsourced coding support could open doors for nation state threats.

A (13:38)

Any company that has actual paying customers, security ends up becoming a concern either early or a little bit later. And definitely when you're talking about big companies, security is a really big deal. You know, I don't have to tell your audience how important it is that if you have a product, you're not leaking people's sensitive payment information or personal address or you know, any sort of identification stuff. So there's always a concern around like data being leaked or problems being caused. And fundamentally all of those problems lead back to code. If the applications that your company is deploying, like your website, maybe it's like a user portal or a payments portal, healthcare portal, whatever the heck it is that you're building, if the code that powers those systems has vulnerabilities in it, that means attackers can take advantage of those vulnerabilities. That's really the bottom line.

B (14:32)

And is it the Reality that quite often the security side of things comes after the initial round of coding, that in some ways it gets maybe bolted.

A (14:45)

On a million percent. Yes. So my background is I've been a developer for about 25 years. Even in my role leading the developer and security relations team here at Snyk, I mean, I still spend at least 20% of my time on software engineering related tasks. And so I feel like I'm kind of a perfect example of like your average developer, let's say. And one of the things any developer will tell you is that security is always an afterthought. If they tell you that it's not an afterthought, they're straight up lying to you. And, and the reason why is really simple. So if you put yourself in the shoes of an engineer who's working on a product at a company, your KPIs have nothing to do with security. I mean, really, they don't like, what you are judged against as an engineer isn't how many security vulnerabilities are in your code or anything like that you are judged against. Did you get this bug fixed? Did you get this feature launched on time? Those are the main things that engineers care about. And so speed and developer experience is the priority. Everything else is an afterthought, including security.

B (15:50)

And so what happens in most situations, then do the initial round of coders hand something off to someone else? Maybe someone outside of the organization?

A (16:02)

I mean, you're asking a very good question. So it looks a little bit differently at different companies. So at really big companies, what ends up happening is after developers write their code and get their feature done, a security team within the company will scan the code, find security issues, and then reach out to various engineering teams to see if they can go in and fix it. So it's a collaborative process. If you're lucky, you'll have some developers internally at your company who are more security minded, maybe people who are even really passionate about the topic, which is rare, but definitely happens. And in those cases, security teams will often try to leverage those people to kind of be like a security champion or an advocate for the rest of the engineers that they work with. I'm not sure if you've heard of the phrase security champions programs, but the concept of a security champions program is really widespread at organizations. And so that's like a very common thing. As a security person, you try to find the developers who are the most security focused and then try to amplify their work across the organization.

B (17:07)

Now you make the case that there are particular perils that can come into play if you're relying on this type of security management here? What are some of the things, things that people need to be concerned about?

A (17:20)

I mean, it. It's everything from really obvious mistakes that can be very costly to really sophisticated mistakes that can be really costly. And I think the part that most people don't realize is that all vulnerabilities fundamentally come down to a coding issue. You know, like it means that something wasn't properly sanitized or something wasn't done correctly on the back end somewhere. And because of that there's this potential exploit that can take place. I know we're talking about nation states and actors and the difference between private attackers or people who are doing it for fun or monetary gain and nation states. The main difference is resourcing. Nation states have an incredible amount of resourcing. They actually hire programmers on a 9 to 5 schedule to go look up popular vulnerabilities and test them out on lots of different company websites and platforms and things like that to see what types of things they can abuse at scale. And so when you're talking about nation states, you basically just think whatever types of vulnerabilities are out there, nation states have the resourcing to abuse them. And so that's kind of the scary part and the part that I think people sometimes don't really understand is just how much resourcing they allocate and dedicate to this type of thing.

B (18:41)

Well then how does an organization go about balancing the practical realities of this? I mean, you still have to ship software, but you want it to be as secure as possible. How do you meet in the middle there?

A (18:55)

So I'm going to answer your question, but I'm going to kind of just give you a little bit of what I think is happening for the most part right now. So how do you balance this? Well, first of all, generative AI in the last three plus years, however long it's been, has really enabled developers to speed up their programming. Even if your company doesn't allow the usage of AI tools, a lot of developers are going around IT backs, security backs to use these things anyway. So you have a shadow IT situation. But the reality is generative AI is making life for developers a lot better right now in the sense that instead of spending a full day trying to debug an issue, they can go have a conversation with their favorite AI tool and figure out the problem. Maybe they're even more on the bleeding edge and they're using things like cursor or Windsurf or CLAUDE code or whatever the latest AI coding tool is to write a lot of the code for them. But fundamentally, the security problem still needs to be addressed. If you're in the minority, like, if you're very conscious about your security footprint and you're trying to do a good job of deploying secure software, what almost anyone will tell you is that the important part is making sure you're not introducing new vulnerabilities into your application. That when your developers are writing code, whether it's them writing code directly, like by literally typing on the keyboard, or whether it's one of their AI tools generating code on their behalf, in either scenario, you need to make sure that the code that's being generated is secure by default. And so how do you do that? Well, there's a lot of tools out there. I mean, I work at snyk. This is pretty much what we're known for. Our tool basically is a developer tool. It analyzes your code as you're writing it in real time and helps find and fix the vulnerabilities that you are generating. And so using some sort of security tool to iterate on this code in real time is basically like the best thing you can do. Now, there's also a secondary concern, which is, well, what about security issues that are already in a code base or that are already in a project? How do you go about resolving these things that might have been there for a long period of time? And the answer there, I mean, I don't think there's a foolproof answer right now, to be honest with you, but the main answer today is prioritization. So there's lots of tools, Snyk provides tools, but there's tons of other companies that do as well, where they will analyze your code base, analyze your runtime environment and tell you this particular vulnerability. Or these five vulnerabilities are the most critical for you to fix, because we know they can be abused. Right now they're user facing, they are highly exploitable. Right. And so we have the technology today to understand a lot of these things better. Maybe if your code base has 10,000 vulnerabilities, only 75 of them are actually important to fix. And so understanding that is important. In the future, I feel pretty confident we're going to have autonomous tools that can go in there, look through your security backlog, and just get the entire thing done in a day. But I don't think as an industry, we're quite there yet.

B (21:58)

Well, you mentioned AI being used to help speed up the coding process. Are there applications where folks can use those same AI tools to try to hunt down some of these security gaps?

A (22:11)

Totally. I mean, I do that all the time. As a matter of fact, I would say there's a couple different patterns you can approach this with. So let's say you're a developer. You're using like Cursor to help you write code, you know, quickly. At a very basic level, if you don't have a lot of security understanding, what you can do is after you generate some code, you can go in and type a message to Cursor and say, hey, can you check my code for security issues and fix them?

B (22:38)

Right.

A (22:39)

That's kind of like level one of this scheme. The problem with that, of course, is large language models aren't fully accurate. And so if you tell them to just find and fix security issues, a couple things might happen. Like, first of all, they may not find security issues that are there. So that's one problem. Secondly, they might hallucinate issues and think there's something there when there really isn't and do a lot of code breakage and things. And then finally, they might find a valid issue, but they might fail to fix it because of a number of problems, whether it's hallucination or accuracy or whatever. And so they're not super reliable as security partners. That's where external tooling typically comes into play. So, like at Snyk, the way that this works is you would hook Snyk into your Cursor environment, for example. And by the way, for those of you listening, you can sign up for a free sneak account. It doesn't cost you anything. You can use it in all the things we're about to describe at no cost. You just create a free account. Basically, the way it would work there is you plug sneak into Cursor and it will come with a set of rules. And these rules tell the Cursor AI engine that every time code is being developed and outputted, all that code is going to be scanned with Snykit. And then Snyk is going to provide the AI engine that Cursor is using with all of the intelligence and heuristics that it needs to actually go in and make an accurate fix. And then once that's done, Snyk will rescan the code to make sure the issue was actually fixed and not hallucinated. So that is kind of like the current state of the art in bleeding edge security for these applications, no?

B (24:12)

That's interesting. What are your recommendations for folks who are just getting started down this path, what's the best way to begin?

A (24:22)

So I would say a couple things. So first of all, if you're listening to the show and you're a developer, one thing I would kind of challenge you to is to change your mindset about security. You know, a lot of developers kind of use security as like someone else's problem. And I would actually challenge you to think of security as a code quality issue. You know, like, developers love talking about code quality. You know, like, we love figuring out the best style for our code, the best architecture patterns, the best tools to use, all these different things. And I think security is just one part of overall code quality. You know, if you're building a product and architecting it well, but you're not shipping secure software, I would say that the overall quality of your code is low. And so first of all, on the developer mindset side, understanding that security is a core part of engineering work is really important. And then secondarily, in terms of what you should be doing, I would just recommend that every developer have a Go to Security tool. Like, for example, for me, when I'm writing code, when I'm writing Python code, I always use the black formatter, which is free and open source, to format my code and maintain consistent styles. Similarly, I use tools like GitHub Actions to Run all of my tests and I try to maintain a high level of test coverage in that same regard. Every developer should have a security tool. So whenever they're writing code or reviewing code, the security tool is pointing out vulnerabilities. And with the technology we have nowadays, ideally it's just autonomously fixing them as well. And so security should be a tool that every developer has in their toolkit. That's just a standard part of their workflow. And I can tell you this, if you do that, you're going to be ahead of 99% of your peers and you will be shipping far more reliable quality software than your peers.

B (26:03)

In a lot of cases, that's Randall Deggs from Sneak. And finally, in the Netherlands, a lingering cyber attack has left dozens of speed cameras in a prolonged nap, much to the delight of lead footed motorists. The Public Prosecution Service's central processing office admits it knows exactly which cameras are snoozing, but won't say where because, well, they're not that generous. The July 17 breach, courtesy of Citrix vulnerabilities, didn't break the cameras directly. It just left the service unavailable to switch them back on. Officials insist a phased relaunch is necessary since their systems are tangled up with police, courts and other agencies. Email was restored on August 7, though large files remain in limbo until then. Dutch drivers might consider this their brief, unofficial autobahn moment. And that's the Cyber Wire. For links to all of today's stories, check out our daily briefing@thecyberwire.com we'd love to hear from you. We are conducting our annual audience survey to learn more about our listeners. We're collecting your insights through the end of this month. There's a link in the show Notes. Please take a moment and check it out. Be sure to check out this weekend's Research Saturday and my conversation with Bob Ruddis, VP of Data Science from Gray Noise. The research we're discussing is titled Early Warning Signals When Attacker Behavior Precedes New Vulnerabilities. That's Research Saturday. Check it out. N2K's senior producer is Alice Carruth. Our Cyberwire producer is Liz Stokes. We're mixed by Trey Hestker with original music by Elliot Peltzman. Our executive producer is Jennifer Ibin. Peter Kilpe is our publisher and I'm Dave Bittner. Thanks for listening. We'll see you back here next week.