This interview is part of the Simplyblock's Cloud Commute Podcast, available on Youtube, Spotify, iTunes/Apple Podcasts, Pandora, Samsung Podcasts, and our show site.
In this installment of podcast, we're joined by Brian Vermeer (Twitter/X , Personal Blog) from Synk, a cybersecurity company providing tooling to detect common code issues and vulnerabilities throughout your development and deployment pipeline, talks about the necessity of multi checks, the commonly found threads, and how important it is to rebuild images for every deployment, even if the code hasn’t changed.
Chris Engelbert: Welcome back everyone. Welcome back to the next episode of simplyblock's Cloud Commute podcast. Today I have yet another amazing guest with me, Brian from Snyk.
Brian Vermeer: That's always the question, right? How do you pronounce that name? Is it Snek, Snik, Synk? It's not Synk. It's actually it's Snyk. Some people say Snyk, but I don't like that. And the founder wants that it's Snyk. And it's actually an abbreviation.
Chris Engelbert: All right, well, we'll get into that in a second.
Brian Vermeer: So now you know, I mean.
Chris Engelbert: Yeah, we'll get back to that in a second. All right. So you're working for Snyk. But maybe we can talk a little bit about you first, like who you are, where you come from. I mean, we know each other for a couple of years, but...
Brian Vermeer: That's always hard to talk about yourself, right? I'm Brian Vermeer. I live in the Netherlands, just an hour and a half south of Amsterdam. I work for Snyk as a developer advocate. I've been a long term Java developer, mostly back end developer for all sorts of jobs within the Netherlands. Java champion, very active in the community, specifically the Dutch community. So the Netherlands Java user group and adjacent Java user groups do some stuff in the virtual Java user group that we just relaunched. That I've tried to be active and I'm just a happy programmer.
Chris Engelbert: You're just a happy programmer. Does that even exist?
Brian Vermeer: Apparently, I am the living example.
Chris Engelbert: All right, fair enough. So let's get back to Snyk and the cool abbreviation. What is Snyk? What does it mean? What do you guys do?
Brian Vermeer: Well, what we do, first of all, we create security tooling for developers. So our mission is to make security an integrated thing within your development lifecycle. Like in most companies, it's an afterthought. Like one security team trying to do a lot of things and we have something in the pipeline and that's horrible because I don't want to deal with that. If all tests are green, it's fine. But what if we perceive it in such a way as, "Hey, catch it early from your local machine." Just like you do with unit tests. Maybe that's already a hard job creating unit tests, but hey, let's say we're all good at that. Why not perceive it in that way? If we can catch things early, we probably do not have to do a lot of rework if something comes up. So that's why we create tooling for all stages of your software development lifecycle. And what I said, Snyk is an abbreviation. So now you know.
Chris Engelbert: So what does it mean? Or do you forget?
Brian Vermeer: So Now You Know.
Chris Engelbert: Oh!
Brian Vermeer: Literally. So now you know.
Chris Engelbert: Oh, that took a second.
Brian Vermeer: Yep. That takes a while for some people. Now, the thought behind that is we started as a software composite analysis tool and people just bring in libraries. They have no clue what they're bringing in and what kind of implications come with that. So we can do tests on that. We can report of that. We can make reports of that. And you can make the decisions. So now at least you know what you're getting into.
Chris Engelbert: Right. And I think with implications and stuff, you mean transitive dependencies. Yeah. Stuff like that.
Brian Vermeer: Yeah.
Chris Engelbert: Yeah. And I guess that just got worse with Docker and images and all that kind of stuff.
Brian Vermeer: I won't say it gets worse. I think we shifted the problem. I mean, we used to do this on bare metal machines as well that these machines also had an operating system. Right. So I'm not saying it's getting worse, but developers get into more responsibility because let's say we're doing DevOps, whatever that may mean. I mean, ask 10 DevOps engineers. That's nowadays a job. What DevOps is, you probably get a lot of questions about tooling and that, but apparently what we did is tearing down the wall between old fashioned developer creation and getting things to production. So the ops folks, so we're now responsible as a team to do all of that. And now your container or your environment, your cluster, your code is all together in your Git repository. So it's all code now. And the team creating it is responsible for it. So yes, it shifted the problem from being in separate teams now to all in one team that we need to create and maintain stuff. So I don't, I don't think we're getting into worse problems. I think we're, we're shifting the problems and it's getting easier to get into problems. That's, that's what I, yeah.
Chris Engelbert: Yeah. Okay. We're, we're broadened the scope of where you could potentially run into issues. So, so the way it works is that Snyk, I need to remember to say Snyk and not Synk because now it makes sense.
Brian Vermeer: I'm okay with however you call it. As long as you don't say sync, I'm fine. That's, then you're actually messing up letters.
Chris Engelbert: Yeah, sync, sync is different. It's, it's not, it's not awkward and it's not Worcester. Anyway. So, so that means the, the tooling is actually looking into, I think the dependencies, built environment, whatever ends up in your Docker container or your container image. Let's say that way, nobody's using Docker anymore. And all those other things. So basically everything along the pipeline or the built pipeline, right?
Brian Vermeer: Yeah. You can say that actually we start at the custom code that you're actually writing. So we're doing static analysis on that as well. Might combine that with stuff that we know from your, let's say all your dependencies that come in your dependencies, transitive dependencies, like, "hey, you bring in a spring boot starter that has a ton of implications on how many libraries come in." Are these affected? Yes or no, et cetera, et cetera. That we go one layer deeper or around that, say your, your container images and let's say it's Docker because it's still the most commonly used, but whatever, like any image is built on a base image and probably you streamlined some binaries in there. So what's there, that's another shell around the whole application. And then you get into, in the end, for instance, your configuration for your infrastructure is go to the bullet. That can go wrong by not having a security context or like some policies that are not bad or something like that. Some pods that you gave more privileges than you should have because, Hey, it works on my machine, right? Let's ship it. These kinds of things. So on all these four fronts, we try to provide pooling and test capabilities in such a way that you can choose how you want to utilize these test capabilities, either in a CI pipeline or our local machine or in between or part of your build, whatever fits your needs. And instead of, Hey, this needs to be part of your build pipeline, because that's how the tool works. And I was a developer myself for back end for backend jobs a long time. And I was the person that was like, if we need to satisfy that tool, I will find a way around it.
Chris Engelbert: Yeah, I hear you.
Brian Vermeer: Which defeats the purpose because, because at that point you're only like checking boxes. So I think if these tools fit your way of working and implement your way of working, then you actually have an enabler instead of a wall that you bump into every time.
Chris Engelbert: Yeah. That makes a lot of sense. So that means when you, say you start at a code level, I think simple, like the still most common thing, like SQL injection issues, all that kind of stuff, that is probably handled as well, right?
Brian Vermeer: Yeah. SQL injections, path of virtual injections, cross-site scripting, all these kinds of things will get notified and we will, if possible, we will give you remediation advice on that. And then we go levels deeper. So it's actually like, you can almost say it's like four different types of scanner that you can use in whatever way you want. Some people are like, no, I'm just only using the dependency analysis stuff. That's also fine. Like it's just four different capabilities for basically four levels in your, in your application, because it's no longer just your binary that you put in. It's more than that, as we just discussed.
Chris Engelbert: So, when we look at like the recent and not so recent past, I mean, we're both coming from the Java world. You said you're also, you were a Java programmer for a long time. I am. I think the, I mean, the Java world isn't necessarily known for like the massive CVEs. except Log4Shell.
Brian Vermeer: Yeah, that was a big,
Chris Engelbert: Right? Yeah.
Brian Vermeer: The thing, I think, is in the Java world, it's either not so big or very big. There's no in between, or at least it doesn't get the amount of attention, but yeah, Log4Shell was a big one because first of all, props to the folks that maintain that, because I think there were only three active maintainers at that point when the thing came out and it's a small library that is used and consumed by a lot of bigger frameworks. So everybody was looking at you doing a bad job. It was just three guys that voluntarily maintained it.
Chris Engelbert: So for the people that do not know what Log4Shell was. So Log4J is one of the most common logging frameworks in Java. And there was a way to inject remote code and execute it with basically whatever permission your process had. And as you said, a lot of people love to run their containers with root privileges. So there is your problem right there. But yeah, so Log4Shell was, I think, at least from what I can remember, probably like the biggest CVE in the Java world, ever since I joined.
Brian Vermeer: Maybe that one, but we had in 2017, we had the Apache struts, one that blew, blew, blew away, blew away our friendly neighborhood Equifax. But yeah.
Chris Engelbert: I'm not talking about struts because that was like so long deprecated by that point of time. It was, it was, it was ... They deserved it. No, but seriously, yeah. True, true. The struts one was also pretty big, but since we are just recording it, this on April 3rd, there was just like a very, very interesting thing that was like two days ago, three days ago, like April 1st. I think it was actually April 1st, because I initially thought it's an April's Fool joke, but it was unfortunately not.
Brian Vermeer: I think it was the last day of March though. So it was not.
Chris Engelbert: Maybe I just saw it like April 1st. To be honest, initially I thought, okay, that's a really bad April's Fool. So what we're talking about is the XZ issue. Maybe you want to say a few words about that or what?
Brian Vermeer: Well, let's keep it simple. The XZ issue is basically an issue in one of the tools that come with some Linux distributions. And long story short, I'm not sure if they already created exploits on that. I didn't, I didn't actually try it because we've got folks that are doing the research. But apparently there, because of that tool, you could do nasty stuff such as arbitrary code executions or, or things with going into secure connections. At least it comes with your operating system. So that means if you have a Docker image or whatever image and you're based on a certain well-known Linux distribution, you might be infected, regardless of whatever your application does. And it's a big one. If you want to go deeper, there are tons of blogs of people that can explain to you what the actual problem was. But I think for the general developers, like, don't shut your eyes and like, it's not on my machine. It might be in your container because you're using an outdated, now outdated image.
Chris Engelbert: I think there's two things. First of all, I think it was found before it actually made it into any distribution, which is good. So if you're, if you're not using any of the like self-built distributions, you're probably good. But what I found more interesting about it, that this backdoor was introduced from a person that was working on the tool for quite a while, like over a year or so, basically getting the trust of the actual maintainers and just sneaking stuff in eventually. And that is... That is why I think tools like Snyk or let's, let's be blunt, some of the competitors are so important, right? Because it's, it's really hard to just follow all of the new CVEs and sometimes they're not blowing up this big. So you probably don't even hear about them, but for that reason, it's really important to have those tools.
Brian Vermeer: I totally agree. I mean, as a development team, it is a side effect for you, like you're building stuff and you don't focus on checking manually, whatever is coming in and if it's vulnerable or not, but you should be aware of these kinds of things. And so if they come in, you can make appropriate choices. I'm not saying you have to fix it. That's up to you, like, and your threat level and whatever is going on in your company, but you need to be able to make these decisions based on accurate knowledge and have the appropriate knowledge that you can actually make such a decision. And yeah, you don't want to manually hunt these things down. You want to be actively pinged when something happens to your application that might have implications for it, for your security risk.
Chris Engelbert: Right. And from your own feeling, like, in the past, we mostly deployed like on-prem installations or in like private clouds, but with the shift to public cloud, do we increase the risk factor? Do we increase the attack surface?
Brian Vermeer: Yes. I think the short story, the short thing is, yes, there are more things that we have under our control as a development team. We do not always have the necessary specialties within the team. So we're doing the best we can, but that means we've got multiple attack phases. Like your connection with your application is one thing, but this one is if I can get into your container for some reason, I can use this, even though at some, some things in containers or some things in operating systems might not be directly usable, but part of a chain that causes a problem. So I can get in in one, like if there's one hole, I could get in and use certain objects or certain binaries in my chain of attacks and make it a domino effect, basically. So you're, you're giving people more and more ammunition. So, and as we automate certain things, we do not always have the necessary knowledge about certain things that might become bigger and bigger. Plus the fast pace we're currently moving. Like, like tell me like 10 years ago, how were you deploying?
Chris Engelbert: I don't know. I don't remember. I don't remember yesterday.
Brian Vermeer: Yeah. But I mean, probably not three times a day, like 10 years ago, we're probably deploying once a month, you have time to test or something like that. So it's a combination of doing all within one team, which yes, we should do, but also the fast pace that we need to release nowadays is something like, okay, we're just doing it. The whole continuous development and continuous deployment is part of this. If you're actually doing that, of course.
Chris Engelbert: Yeah, that's, that's true. I think it would have been like about every two weeks or so. But yeah, you normally had like one week development, one week bug fixing and testing, and then you deployed it. Now it's like, you do something, you think it's ready, it runs through the pipeline. And in the best case, it gets deployed immediately. And if something breaks, you gonna fix it. Or are you in the worst case, you roll back if it's really bad.
Brian Vermeer: But on the other end, say you're an application developer, and you need to do that stuff in a container. And do you ship it? Are you touching your container if you or rebuild your container if your application didn't change?
Chris Engelbert: Yes.
Brian Vermeer: Probably, probably, probably a lot of folks won't, because hey, did some, some things didn't change, but it can be that the image your base your stuff upon or your base image or however you may manage that can be company wide, or you just will something out of Docker hub or whatever. That's another layer that might have changed and might have been fixed or might have been vulnerabilities found in it. So it's not anymore like, 'hey, I didn't touch that application. So I don't have to rebuild.' Yes, you should because other layers in that whole application changed.
Chris Engelbert: Right, right. And I think you brought up an important other factor. It might be that meanwhile, like, during the last we were in between the last deployment, and now a CVE has been found or something else, right? So you want to make sure you're going to test it again. And then you have other programming languages, I'm not naming things here. But you might get a different version of the dependency, which is slightly newer. You're doing a new install, right? And, and all of that are there's so many different things, applications, these days, even micro services are so complex, because they normally need like, so many different dependencies. And it is hard to keep an eye on that. And that kind of brings me to the next question, like, how does snake play into something like SBOM or the software bill of materials?
Brian Vermeer: Getting into the hype train of SBOMs. Now, it's not, it's not just the hype train. I mean, it's a serious thing. For folks that don't know, you can compare the SBOM as your ingredients nutrition list for whatever you try to consume to stuff in your face. Basically, what's in there, you have no clue, the nutrition facts on the package should say what's in it, right? So that's how you should perceive an SBOM. If you create an artifact, then you should create a suitable SBOM with it that basically says, 'okay, I'm using these dependencies and these transitive dependencies, and maybe even these Docker containers or whatever, I'm using these things to create my artifact.' And a consumer of that artifact is then able to search around that like say a CVE comes up, a new Log4Shell comes up, let's make it big. Am I infected? That's the first question, a consumer or somebody that uses your artifact says. And with an SBOM, you have a standardized, well, there are three standards, but nevertheless, like multiple standard, but there's a standardized way of having that and make it at least machine searchable to see if you are vulnerable or not. So how do we play into that? Yes, you can use our sneak tooling to create SBOMs for your applications or for your containers, that's possible. We have the capabilities to read SBOMs in to see if these SBOMs contain packages or artifacts or stuff that have known vulnerabilities. So you can again, take the appropriate measures. I think it's, yes, SBOM is great from the consumer side. So it's very clear what that stuff that I got from the internet or got from a supplier, because we're talking about supply chain all the time, from a supplier within stuff that I build upon or that I'm using that I can see if it contains problems or it contains potential problems when something new comes up. And yes, we have capabilities of creating these SBOMs and scanning these SBOMs.
Chris Engelbert: All right. We're basically out of time. But there's one more question I still want to ask. And how do you or where do you personally see the biggest trend could be related to Snyk to security in general?
Brian Vermeer: The biggest trend is the hype of AI nowadays. And that is definitely a thing. What people think is that AI is a suitable replacement for a security engineer. Yeah, I exaggerate now, but that's not because we have demos where we let a code assistant tool, a well known code assistant tool, spit out vulnerable code, for instance. So I think the trend is two things, the whole supply chain, software supply chain, whatever you get into, you should look at one thing. But the other tool is that if people are using AI, don't trust it blindly. And I think it's that's for everything for both stuff in your supply chain, as in generated code by a code assistant. You should know what you're doing. Like it's a great tool. But don't trust it blindly, because it can also hallucinate and bring in stuff that you didn't expect if you are not aware of what you're doing.
Chris Engelbert: So yeah. I think that is a perfect closing. It can hallucinate things.
Brian Vermeer: Oh, definitely, definitely. It's a lot of fun to play with it. It's also a great tool. But you should know it doesn't first of all, it doesn't replace developers that think. Like thinking is still something an AI doesn't do.
Chris Engelbert: All right. Thank you very much. Time is over. 20 minutes is always super, super short, but it's supposed to be that way. So Brian, thank you very much for being here. I hope that was not only interesting to me. I actually learned quite a few new things about Snyk because I haven't looked into it for a couple of years now. So yeah, thank you very much. And for the audience, I hope you're listening next week. New guest, new show episode, and we're going to see you again.
Opmerkingen