The Modern .NET Show

Episode 69 - The Risks of Third Party Code With Niels Tanis

Sponsors

Support for this episode of The Modern .NET Show comes from the following sponsors. Please take a moment to learn more about their products and services:

Please also see the full sponsor message(s) in the episode transcription for more details of their products and services, and offers exclusive to listeners of The Modern .NET Show.

Thank you to the sponsors for supporting the show.

Embedded Player

Episode 69 - The Risks of Third Party Code With Niels Tanis
The .NET Core Podcast

Episode 69 - The Risks of Third Party Code With Niels Tanis

Supporting The Show

If this episode was interesting or useful to you, please consider supporting the show with one of the above options.

Episode Transcription

This episode of The .NET Core Podcast is brought to you in part by RJJ Software

RJJ Software is dedicated to helping you to realise your company’s digital potential through innovative solutions using the latest technologies.

Utilising the latest in .NET and cloud technologies, we can help you build the solution to your business needs, on time and under budget.

We have world class experience in cross platform development using the latest iterations of the Microsoft technology stack. This includes .NET Core; SQL Server; and Azure. Is Azure not your thing? That’s fine, because we have experience with AWS, GCP, Linode, and Digital Ocean, too.

We know what it means to have to be able to iterate quickly, and how important DevOps practises are when it comes to remaining Agile. As such, we have experts in the major build and release pipelines: from Azure DevOps to AWS, from Netlify to TravisCI, AppVeyor, and everything in between).

So get in touch today at RJJ Software, or check the show notes for a link.


Hello everyone and welcome to THE .NET Core podcast - the only podcast which is devoted to:

and not forgetting The .NET Core community, itself.

I am your host, Jamie “GaProgMan” Taylor, and this is Episode 69: The Risks of Third Party Code with Niels Tanis. In this episode I talked with Niels about exactly what are some of the risks of just nuget add or dotnet add referenceing packages without checking them out first, and what you can do to ensure that the third party code that you include in your applications is exactly what it says it is.

So let’s sit back, open up a terminal, type in dotnet new podcast and let the show begin.

The following is a machine transcription, as such there may be subtle errors. If you would like to help to fix this transcription, please see this GitHub repository

Jamie

So thank you ever so much, Niels for taking some time today, I really appreciate it. We’re all busy people, right? Regardless of so I don’t like to talk about the current situation at the time of recording. But regardless of the current situation, even if it was not the current situation, we’d all be pretty busy anyway. So I really appreciate you taking some time out of your morning to come and talk to me about this very important topic.

Niels

Thanks for inviting me, Jamie. It’s good to be here for sure. Good morning.

Jamie

Excellent. Okay. So I was wondering, for the folks who may be tuning in and not sure about your background and you know, the the the career path that you’ve taken the things that could you perhaps Introduce yourself so that everyone knows a little bit more about Niels as we go in?

Niels
Yeah, it sounds sounds like a good plan to start out first introducing yourself, right. So eah, so Niels Tanis, I work as a security researcher for vertical, which means in my daily job, I’m mostly focused on application security and our static analysis. That’s the service that we offer.

Niels

I’m based, I’m an employee based in the Netherlands and what I’m, like, started out when I like when I started out my career, I first started out developing software. And I’ve written a lot of dotnet, since the early bits, like the one zero bits, and always kept application security on the side track. And after some moves within companies, I moved into the tech space fully. And I was an ethical hacker for a year where I mostly focused on braking systems.

And my goal is just to make sure that developers are aware of the stuff that they’re doing. When they’re writing the software, when they’re doing stuff with external libraries. The thing we’re going to touch today, hopefully, and yeah, make sure that everybody gets their software into better shape. So we we get into a better space overall. Right? I think that’s that’s the goal I have. So yeah, that’s it in a nutshell. And yeah, it’s good. As I said, it’s good to be here. It’s good to talk about stuff. And yeah, talk about application security, for sure.

Jamie

I think I think that’s the most important thing, right? Because I talk about when I’m talking to some folks who are not developers, you know, I say, when it comes to App Security, you can’t build a house without the foundations written, the security has to be the foundations, you think about if you walk into a building, and they have those card readers, right, I’ve seen this, one of the places where I used to work, they have like card readers at the door, and you have to put your card and be authenticated before you can walk in, right.

This place where I used to work had a door and a card reader and the walls around it were plain glass. Okay, so if I if I want to break in, I’m not saying I wanted to break in, if I wanted to break in, you just smashed the glass, right? I don’t need a card to get into the room. And then. And then on top of that, right, the the the ceiling was made of those ceiling tiles, you could just poke to push up and there’s a walk space. So I’m like, there’s no security here. You know.

Niels

That sounds like a bad risk assessment, right? That’s always what needs to happen. Like, what do you want to achieve, by doing it? It looks like something they added later on. That’s how it sounds to me.

And that’s that’s a thing, right? If we talk about security and application security in general, then if you bolt it on later on, then it usually ends up being a problem for your software, you need to think out upfront. And as you said, like structuring of buildings, and the building should not collapse, right? If I restructure my house and I need to change something in a wall that’s also holding off my roof, then I need to have all the regulatiuon in the middle and suddenly having to have some paperwork to prove that I’m getting somebody that knows exactly what he’s doing. You need to do some calculations in order to reduce the risk, right.

And some of the things happen with software. And I think that that’s, that’s something that people need to be aware of like, it starts out with a small thing, small piece of software. And what we usually always like mentioned within customer conversations we have from from the company that I work for is that every company will end up being a software company and it will become their essential parts of running their business. And I always like if I’m talking to like friends who will run a company, he’s like a, he has a webshop and he had some database stuff that he wrote himself and I went through it together with him and I said, Okay, what happens if I’m able to drop all this data that’s inside because there was a SQL injection problem in it. And I just pointed it out to him, I wanted to help him. So like they have got a problem. I said, like, yeah, so that’s a big risk for you if you lose all your data, right?

And I think as long as people are aware of that, and there’s always there’s always a gradation of what you want to achieve, what you’re able to achieve depends on the company that you’re working for, like, what what’s the industry, if it’s a one person shop, it will be different than if it’s a big bank that has like, a lot of developers and maybe even 20 people that run application security, right. But that’s, that’s a different story than the guy that just runs his own online store. Because he’s passionate about selling specific things. He’s like a sneaker, she likes to have nice, like, sneakers to sell. That’s different, right?

So yeah, I think it’s important to be aware of the risks that you’re facing in the context that you’re working with, right? And that you can mature. And it’s always, people always ask me, like, hey, but I need to make sure that I’m fully secure. And that’s also not how it works. You want to reduce the risks, right? You want to make sure that it’s enough to keep the bad guys out. And to keep it operational to keep it workable. Usually, highly secured systems are not the easiest to work with.

And that’s the that’s the flip side of that. So yeah, as you said, it’s it’s important to have some idea of what you want to achieve. If you would put the analogue in of buildings and how they’re built. Even with the space, like within software industry in general, there’s not much legislation happening, right, we do see if a data breach occurs, right. In the UK, some big companies have got like a lot of millions fine to them, because they lost their customer data. That’s the first step right to get people on the same boat. But there’s still a lot to improve. I’m not saying that it’s it’s a bad space right now. But we will get there as long as everybody just takes small steps and do the best they can in their context that that will help out for sure.

Jamie

Yeah, absolutely. There’s a couple of points that I want to sort of raise there. Because there’s some really interesting points you raised. So I guess one of them is there is no full security, there’s just a little bit. I don’t want to reduce it, but more secure than everyone else. And I’m a metaphor person, right? There’s a there’s another podcast. There’s another podcast I do called tabs and spaces. And I always use examples on that. And the example that I use, when I’m talking about security is imagine you have a like on street parking, right? There’s maybe five cars parked at the side of the street, one car has, it’s locked right there, all the cars are locked. One car has a wheel clamp, and one of those steering wheel locks and a car on the next guy is just a wheel clamp. The next guy has just one of those steering wheel locks. And the other two cars don’t have any other locks other than the standard locks built into the car. If I’m a crook, and I want to steal a car, am I going to waste my time on the incredibly secure cars? Or am I just gonna smash a window of one of the locked cars, Jimmy it and drive off?

You know, that’s that’s the whole point. You have to be as secure as everyone else, but a little bit more. So less attractive, I guess, to the sort of stuff.

Niels

Yeah, it’s similar to burglars with your house, right? Always make sure that your houses is more secure than the one of the neighbours and then you’ve got an issue, right? That’s exactly the same analogy for sure. Yeah.

Jamie

Sure. And you talked about how every company becomes a software company. You want proof of that, go look at Amazon, right? Amazon started out as a retailer, an online retailer for books, you had to call and give your credit card number over the phone. And now they run like 50% of the internet infrastructure or something stupid.

Netflix requires them to run, you know, they have become a software company through selling books. So it doesn’t matter where you start, like you say you are going to be a software company, even if you’re not selling it, you are going to be using it to drive your sales to make your money. So it is important is imperative to get it right. From from the start, I guess?

Niels

For sure for sure. Yes,

Jamie

definitely. Definitely. And I guess from my point of view, some security is better than no security in the same way that some tests are better than no tests. Is that

Niels

Yeah, I think as I said, I think what what usually happens right now would you see if you have a company that has maybe legislations to like adhere to like maybe financially it like financial industry, like banks or something else. You want to make sure that your job posture from security perspective in relation to all the applications you have, will be something that evolves and grows, right, that improves that adapts to, to to the stuff that’s happening. And that will get you into a better shape and then I would agree like yeah, if you’d like to Small steps. And it’s just that start out. Like if you look at coding stuff, dynamic SQL statements like SQL injection, that what’s happening, if you’re like concatenating, just input data that comes from an external source into your SQL statement, then you can do that drop tables, and then get rid of all the data that’s in the database underneath. And if you’ve stopped saying, like, Hey, I just always do parameterised queries, unless there is really a need to do stuff, and then you need to maybe take another approach and make sure that the data is properly vetted. But still, like make sure that you’ve got some good steps and also have some, some basic guidelines where you would like to start, you’re always working. Similarly, if you’re doing like software, I’m pretty confident that if you start out doing a new project, you usually have a scaffolding project, like how it works like this is the I’m going to separate it into these layers. That’s going to be a project that does this, right. And I would say like security just needs to be tied in from the beginning. And hopefully you take on the stuff that you’ve learned in the past and apply it on the new project. Right, that that’s, that’s at least what I’m what I’m doing. And then aside from the fact that I’m lazy, and I don’t want to repeat myself, that that’s a good thing. And then I would say, yes, small steps is definitely better than doing nothing. And make sure that you keep an eye on what’s happening, similar to new stuff that’s like being found, but also the fact that the software that we write nowadays has evolved over time, like when I started out my own development career, I used to say, like I wrote the big monoliths that was installed at the customer, which I literally just gave the installer to go, Okay, this is the thing you need to instal windows to service on your infrastructure. And then you’re good compared to what we’re doing right now, in relation to the AWS example you gave, you just smashed the whole application landscape on AWS, or maybe Azure, or google google clouds, and just software runs. But there’s a lot of moving parts. And also the way that the software will be developed, deployed and tested, has gotten a lot more complex, which also introduces a lot more risks on the supply chain in general. But also, one step off, it would also be like a, you pull in third party libraries, right, and you build on top of something that’s already created. And I think that’s definitely a good thing, because you don’t want to reinvent the wheel. But be aware of that. And there’s no such thing as, as a free puppet. It’s also analogy, you hear a lot, but you pull in a library, you’re going to use it you need to take care of it, you need to keep an eye out stuff that’s being updated. Bubbles, published vulnerabilities, which will happen later on. But what about the simple question? Like, if you look back at the projects that you have may be released with customers are installed? Like, are you able to say which library was used on all those different projects? Right, I think that’s the first step having some visibility of, hey, I’ve used version x of of dapper because I do some data access mapping in that. And right now, it turns out there needs to be an update for that will be good to be aware of exactly like, hey, that’s a system. That’s a system that runs publicly connected to the internet. That’s a high priority. For me, that’s one we need to probably fix more quickly, then the one that’s being run on a back end server and it has to end users. Right, that that’s a different condition on how you need to approach it, I think. But, um, so there was, there was a lot a lot of information. But um, yeah, so I think if you look at continuously growing, the ability of doing the right things in application security, then we should just learn it needs to be integrated, and be aware of the risks that you’re facing. And if we then maybe pivot to the third party libraries, again,

if you would analyse there’s, there are some tools you can run against your, your your code base, there’s also an ability to maybe do on GitHub, even as dependent, but that will do a lot of stuff for you, which I think is a really good thing doesn’t necessarily mean that you’re facing risk, because maybe you’re not using parts of that library that have got back problems, it would always be a good idea to update them as possible. But I think it’s always a good thing to consider, like a essence and necessity. Can I maybe, like don’t need to do it right now. Because it’s that publicly facing system. Or Can it wait till the next cycle because it will only get us out of the moment of having this sprint and we’re releasing a big, big chunk of functionality, which is also important to us, right? And that’s that’s the that’s the that’s the colour and that’s the judgement you need to make as a developer. And there’s a lot and similar with with application security, if you’re lucky to run within an organisation that has got his own application security team that focuses on doing static analysis focuses maybe on forcing teams to do threat modelling that will be of course different than That one person shop that does it all on its own. Right? That that’s that’s the excuse. And you cannot expect a one person shop to do exactly the same as Microsoft who’s got like hundreds of security engineers to solve a problem. And that I think that’s the big key difference between that and same counts. If I maybe want to just like point out to third party libraries, usually they’re being built by people in their spare time, because that’s half solves the problem and they want to share it. But it’s not necessarily it doesn’t necessarily mean that they will be able to invest the same amount of time in maintaining it and fixing problems. Right. And so that that’s the trade off, yes, you will get stuff for free, you need to be aware of the fact that, yeah, stuff gets fixed or updates. And and I think that’s, that’s a key key importance of third party risk and some of the problems basis, and we need to get a better hang off with using the right tools and growing in that space. Right. Sure. I,

Jamie

I feel like over the past maybe 1015 years, there’s been there’s been this push towards DevOps. And I feel like security needs to be included in there as well. I’ve heard this acronym the past couple years, Dev sec Ops, this idea of you know, including security in that immediate, sort of feedback loop. And I think that that’s really important. I think the couple of things that you’ve mentioned there about which versions of what have I used in which project and where are they? You know, yeah,

Niels

that’s,

Jamie

that’s really quite important. Like, let’s, I’m going to pick a library out of the area, let’s say, because I’m a dotnet. Dev, I’m going to talk about Newton soft JSON. I’m not saying that there’s any security issues with it. But let’s say I’m using version 11. In a project for one customer, and version 12, in a project for a different customer. When version 13 comes out, I may need to go right, what are the differences and what security issues have been solved? I think you’re right there. I think it’s important to have someone on the team, even if it’s if you’re a single person team, who knows which libraries he was done this audit and said, version 12. This was used for this for this version of the application or whatever, version 13 is that and there’s a security fix, right, I’d better create maybe a branch or a spike instal the newest version and see what the differences are. Because it’s not just the case of download the latest version and see what happens. Because you it may break things, it may cause other security instabilities, there needs to be a full investigation, right?

Niels

Yeah, for sure. And that that’s the trade off. And if I if I think there’s a really good tool that people can start out using that allows them to dump dependency graph, including transitive dependencies for a lot of technology stacks. And one of them is also of course, dotnet. And it’s called Cyclone dx. It’s an even a dotnet ci tool that will do that, that will produce a, I think it does JSON XML format, depending on what you want to, like ingest and process. But it has its gives you the fish ability. And if everybody produces that file, and shares that and puts that in with the release, life would be a lot easier. And I know that there’s like, if you’re a big company, you might have got like a repository that our developers are like, forced to use, because of like vetted components being in there. And that’s like the baseline they want to work with, right. But that’s, that’s not going to help out that I want a two person shop that wants to do the same. And then I think those files it’s, it’s, it’s something that’s like related to the supply chain, they call it software bill of materials that allows you to describe the software that you’ve created. And one of the key elements would be like having a dependency graph and having some knowledge of exactly like, hey, version 12 of Newton soft JSON is inside their project that we need to go to 13. And as you said, they need to do the due diligence like that go through and see like, Hey, what’s what’s what’s, what’s the impact? It’s a major version, right? Compared to maybe a minor, if the team if the project makes a properly distinction between it. And then you need to decide what’s the best step to take, like, what are the next steps to take in order to do that update? So yeah, that’s definitely that’s definitely different than if like Newton soft Jason right. That’s always the number one on new gap. I’m not sure if it’s still the case, the last time I looked that was it was like still number one downloads. For you imagine if somebody compromises the package and infects it, right. And that’s like the you it’s third party risks also, but supply chain, right, the package itself, has has its own software development process, title it and we’ve seen in the past also with with NPM. packages, that really low level packages got compromised. And one key example is something that happened to Event Stream, which is a pretty minimal package, but in the MBM space, minimal functionality really small. And somebody was able to compromise it and it’s I think it’s like you’re talking about millions downloads a week. That’s quite an audience to get. And if you like bad intentions, yeah, that’s a lot of compute. You’ve got at your disposal if everybody starts using your library, and you can do maybe do some bad stuff, I think Event Stream was eventually targeting a specific bitcoin wallet to steal the cryptocurrencies out of it right, the keys, it was pretty sophisticated, there wasn’t a well thought, like Target. But keep in mind, like, as you said, like with the burglars, and the cars and ology, again, if there’s money to make, and if it’s an easy one, then it’s just a business model to the crooks, right, they want to get as much as possible within a short time, we know they’re lazy. And if it just means like, I can compromise that package that has a lot of footprint within all of the software that gets used, then, yeah, that’s a, that’s a, I think that’s a big problem. And honestly, looking at nougat, I’m curious, if there is a really good, like, way of seeing that kind of thing happening, right. NPM, in general, has got a really good tooling space of how you can do your audits yourself to see if there’s packages that need your attention. And with nougat and the dotnet ecosystem, it’s, it’s, it’s not there. So once once every year, we publish statistics, and dotnet is one of them. That’s always a bit of the outside, if you look at the amount of public vulnerabilities that are inside, and my boss told her story last week, when he told like a lot, that is even the lowest to that degree, because it’s a pretty clean ecosystem compared to NPM, which already has been built up from a community, right? I think that’s different. If you look at nougat, it’s been built up maybe from top down, and NPM is maybe built from bottom up by community driven stuff. And that’s it, that’s maybe the key difference. It doesn’t mean that there’s not an issue within dotnet, because 80% of the apps that we see, for the first time have a vendor bill component that needs some attention. But yeah, there’s a, there’s a big, there’s a big space. And as long as people are aware of the fact like, Hey, this is a package widely used by a lot of people, a lot of attention, and it’s being run by one or two people. It’s that there’s a skew right. And then if you’re using it, then it will be good to maybe contribute and help out. If there is a problem. I think that’s your some some kind of obligation we have right, in order to make sure that we could always a community and that we write better software that’s more secure, and less risk show.

Jamie

I think there’s a from my point of view, there’s a couple of points there. And I’m not trying to say that one is better than the other, right? Because new get does things that NPM doesn’t an NPM does things that nougat doesn’t rate and both of the benefits and drawbacks. I’m not trying to start any kind of a kind of flame war. I mean, yes, this is the dotnet core podcast. So I’m gonna sides with you get a couple of things like, JavaScript doesn’t have a standard library, whereas dotnet has this huge amount of Standard Code, right? You want some kind of generics into there, you want database access, it’s there. You may want better different database access, but it is there, right? There’s there’s all sorts of code that so let you do all sorts of things. Whereas modern JavaScript requires you to pull in all of these libraries, because the standard library doesn’t exist. Maybe we should have a standard library. I don’t know. Yeah, but then maybe that would make the JavaScript runtime slow, I’m not sure. And then I feel like the projects that I’ve worked on that have been entirely NPM, based through one reason or another, there’s no like version number pinning. Like by default, if you do NPM add, or whatever it is, NPM instal package name, it will pull down the latest version. And if you’re looking at packages, JSON, it’s not pinned to a specific version, it’s this version or higher, or this version, or just like this major version, dot star, any version after this can be installed. Right. And whereas with dotnet, at least the weather I work, I usually go in new get instal or dotnet add package, and then a specific, explicit version number. And I feel like that’s one of the key differences in that I’ve always felt like the, the nougat packages are pinned to that specific version, whereas NPM by default, Now, obviously, there’ll be a there’ll be a switch inside of NPM instal. Or, you know, it’s almost trivial to go Okay, open my package instal JSON and lock it down to this particular version, or is it packages dot lock dot JSON, that can help to, but it’s almost it’s like an afterthought, something you don’t have to do afterwards. And I feel like that’s probably one of the reasons why new get is a little bit. I don’t want to say more secure but a little bit less.

Niels

less prone to these kinds of issues. Right? Because the default gives you a better path to walk. I think that’s that’s the key thing. As I said, If If you look at NPM, and the audit capabilities that are inside, that’s something that we miss out on nougat. But right now there are some designs still open. And there is stuff being worked on right now by by Microsoft Teams on getting similar functionalities of being able to edit like, audits your nougat, graph and audit the packages that you have inside your, your project and see if there’s any updates needed. It has been a project that started I think, even a couple years ago. And the last thing I saw on the issue when I checked it last week, to prepare for this, I thought, okay, they said, they’re pretty close on wrapping it up. So it might be part of dotnet five, who knows. But it won’t be good. And that means that it has that filterable like CVE numbers, type of information inside. And it allows everybody just to take the dotnet c li, and to audit their their dependency graph and to see like, Hey, there is a vulnerable component inside your graph, make sure you take the next steps or allocate work that needs to be done in the future in the near future. Right. So that I think that’s a good thing. But as you said, like if a system is more fine grained, and if there’s more packages needed, and there’s no base class functionality available. And that’s, that’s that’s one of the risks. And if you then one, one example I also gave if you look at vias code, which is based on top based on top of electron. And if you didn’t look at the NPM graph, and the dependency graph, including and transitive, once you get, if you’re using electron, it’s scary to see the degroff in your system. And then you see the amount of people that touch those packages, which are like the maintainers, I think it was like 130 packages and a couple of 100 maintainers. But that doesn’t mean that that that’s all the contributors that are helping out developing it, right. So there’s a lot of people all, like, don’t get me wrong, probably good intentions. But there needs to be one inside that chain that can literally just like, screw it up for everybody. Right. And that that’s, that’s not a risk that I wanted, like maybe point out like everybody needs to be aware of, but it’s definitely a problem within that whole type of system. And if it works like that. And, and because of apps do consist of a big portion of those libraries, right? That also makes results in your your app, like possibly being vulnerable. So I think that that’s the key thing. And I would have been amazed at that there’s a really like, you can see the graph and VS code runs on an electron, right. And even VS code itself, has got his own extension based system. There were some stuff happening with the Python extension. So don’t get me wrong, I love VS code, I use it all the time. Because it’s like my one, like the first thing I will go to if I need to run some software and the fact that you can just grab an extension. And if I need to do some PL SQL things to investigate, then I could just grab the extension and it will just work for me. But there is a downside to that like having such a vibrant ecosystem. It also becomes a target for for people. And there’s like a, there’s something to gain there. And they will focus on that. So a lot of moving parts. And I think Yeah, being more fine grained, NPM definitely has got like a problem, because you need to pull in a lot in order to start out right, compared to starting out with the new dotnet core project, which of course is more because it’s more curated by the Microsoft Teams itself. Right? That makes sense. And it’s being built off from that way. And that helps out. For sure. Yeah. Yeah, excellent.

Jamie

Yeah. We’ve we’ve talked a few times. I mean, you’ve you’ve brought it up yourself about doing audits, and dependency graphs, and you talked about the cyclone dx earlier on. Yeah. But let’s say, let’s say I’m a one person team. Or maybe I’m part of a huge, it doesn’t really matter how many people are on the team. And I’m building some software in whatever language, whatever frame we’re sitting here thinking, what if what is what is the security of this thing? How is it best to start with a security audit or a dependency graph? And then work from there? Or is there like, I know, I’ll go tell the boss, we need to do some testing. And I’m gonna get a security expert to come and do it all. For me. What’s the from your point of view? Now, obviously, I know that there’s a potentially a vested interest for you to say, hey, you should talk to veracode. But whatever it is, like, for me, that was the starting point, like we said earlier on some security is better than no security. How do I go from I don’t know whether I have some security? Do I have some security?

Niels

I think the biggest like a proper the key approach to take would first be to assess, assess some of the risks that you’re facing, and maybe look into doing some threat modelling and if you search for threat modelling, in general, you’ll probably get a lot of information like pointed to you need to do this and that but why not just like create a component from a diagram of your app. Have all its architectural components in Besides seeing data flowing, that comes externally, that maybe goes through some back end system, that kind of thing, and maybe assess the risk down to that kind of thing, and then point out like, Hey, what are the big biggest risks that I’m facing? If this is a publicly connected system? Okay, first up, hey, there’s a web front end that will get all the traffic. So that will be the first one to jump into. So that will be the first thing that just to have some guests some sense of, like, what are the risks that I’m facing. Secondly, then investigate the technology stack that you’re using. Make sure that you’re doing best practices from that perspective, if there are some analyzer tools available. If you’re doing dotnet code, as there’s a really rich set of Roslyn analyzers, that can do a lot of you, for you right already out of the box, maybe you’re fortunate enough to have some commercial product available that does static analysis, right, but data flows tight it and maybe also do those dependency checks, right. and work your way down from that. Similar to, and yeah, and then allow it to grow. Secondly, if you look at the developer space, in general, if there is a bigger team of developers insight, maybe some learning and some education, of knowing, like, hey, these are the type of abilities you will create if you’re maybe parsing an XML document. And if you have the DTD resolving, enabled, for example, which Luckily, with dotnet, there’s a good default, right, that helps us. So if you need to do something bad between calls, then that’s an explicit API call. And, but then people need to be aware of like, these are the consequences. Because if we can do external dtds, with XML, I can maybe even get data out of the system or maybe execute stuff that I’m not like allowed to do. And that that’s the next step. Right. So to get more awareness between the teams that are developing and and and allow it to grow from from that perspective. Similar with bigger organisations, usually the application should go to people seem like the amount of people that do it is usually really a small team. And what we do ourselves within our product security, right, because we run software, we we run AWS, we run, we write software, ourselves. And two of my colleagues within the team are mostly focused on product security. But our development teams are a lot bigger things like 100 plus people. So you want them to have the resources available to do the best job that they can. We work with a concept called security champs that allows them to like people who are more savvy, more security aware that probably enjoy it, and they can help our team members on doing the right thing, right, that’s usually the link in between the application security because it’s really hard to scale, that kind of practice within the organisation. And But getting back to developing software, I think it would be good to have some baseline yourself. Like if you do software development, similar types of apps within the organisation that all rely on similar back end systems that need those kinds of libraries, then why not have a baseline architecture that allows the security people to more easily see what’s happening. And it also allows them to say like, Hey, if you’re going for this architecture, you’re going to develop it like this, then don’t bother the security team, because we’re good with this, right? It will, it will give you a lot of freedom. I’m a big fan of getting out of the way of developers and also give them the information that they need in order to not like programme that findability. But also give them the freedom just to write the software, and the best way they can because most of them are usually better than I. So just just allow that right. And I think that that’s also one of the key things to be aware of, if you’re fortunate enough to have those kinds of resources available between between the organisation that you’re working in, right, or the people that you’re working with. Yeah, so I think that’s always a good thing. I always get the question about, okay, if I write this app, like, what do I need to do to do a good job? Right? And, yeah, as I said, so awareness between development developers themselves knowing that, okay, if you’re doing this type of coding practice, that’s a bad practice, having maybe your baseline and as I said, like, I think it all starts with some kind of risk assessments to know exactly like, what are the thing that you’re facing? Is that app that’s used internally by five people? Or is that app that will have a key in our business, and we’ll be publicly facing, and we’ll get a lot of requests every hour in order to persist data, right? That’s that i think that’s that’s the key difference between what to choose from, but as long as you take small steps and improve, that’s, that’s the key.

Are you a lead developer? Would you like to bring mobile development in-house? ARE YOU A DEV provides you and your team with everything needed to prototype, code and support a mobile product in-house.

Deliver your first mobile app and upskill your in-house team within 3 months.

The ARE YOU A DEV program includes 3 hours of bespoke video content tailored to your project, over 18 hours of mobile product video material, weekly live video Q&A and email support with SLA response times for those annoying bugs.

Visit areyouadev.com to schedule a 1 to 1 demo of our business team programme.


Jamie

Sure, it feels very much like a case of yesterday, I do this much data, this much information about keeping my application secure. And tomorrow, maybe next week, maybe hopefully in about a month, but after a certain amount of time. I know a little bit more, and I can sort of backport that to my practice and make my applications and the applications of the people ran me more secure by recommending, hey, maybe you shouldn’t do it this way. Maybe you shouldn’t do it that way. Oh, I saw that there was this security vulnerability reported and things like that. I think maybe that’s a good thing to say that’s a good place to start, right? Start with small steps and build up, right. Yeah.

Niels

And also learn, right? If you know exactly like I at this point, somebody tells me today like aliens, if you’re doing this, without that that’s a big issue, then flip the switch yourself, go go back to the previous things you’ve developed, and and see like, hey, I’ve done exactly the same thing there. Right. And maybe we need to take care of it also, as I said, because you’re like, hopefully, repeating the stuff that you’ve used before, right? Because that, that made you successful that helped you out achieving the goals, but also to that flip back, and also make sure that the team members know like, Hey, this is a big problem. maybe do some fun challenges around and some some educational systems, we’ve got one ourselves, there’s a lot of others that you have got, like Capture the Flag things that will also make it enjoyable for people to see what type of things happen. But it will then like hook them, right? It’s okay. I won’t make that mistake again. And don’t get me wrong. Even when I’m writing software, there’s always something like that somebody’s like, hey, well, this is this is not a good idea Niels because what you’ve just done will result in this. And this just happens, right? That that’s just how it works. But as long as you’re aware of it, that’s step one, and then improve on that. I think that’s that’s, that’s really important. Sure. Okay.

Jamie

So let’s say I’ve done my security audit, I’ve got my baseline application that I’m using somewhere else, maybe I’m using a company wide template, and it’s been approved by the security team. I’ve built my app, I’ve done my security audit, I’ve shipped it, project has ended, do have a need to come back to it and go, I wonder how that’s running? Or should I just go in until I tell us a reported problem? Because this is where like it could run into into cost for, let’s say, let’s say I’m working a short project for a client, right? I’m working as part of a team and we’re building some software. And at the end of three months, six months, I’ve handed it over, and projects done. Right? Do I Do I have to come back to that and say, Oh, this has just been flagged with this library. They let’s say I’m doing something with RGB, right, I’m working in the RGB space, some library that I’ve leveraged has some security issue. It’s been fixed six months ago, I wrote an application with the old version of it. Right. And I gave that to the customer that I now know, that’s running in production somewhere on the web. Right? I’ve personally read this is my personal opinion, not the opinion of anyone else, okay. Sure has been on the show. I’m not an employee of anyone related to dotnet. My personal opinion would be I would need to reach out to that, that customer that client and say, Hey, here’s the detail. So you can look it up if you if you want to yourself, but I happen to know there’s a security vulnerability in the application. Here’s the information. So if you want to go to someone else to fix it, that’s fine. But since I have knowledge of the system, I can fix it for you. But it might cost you a little bit of money. Right? That that’s where it gets a bit hairy, right? I’m saying to them, there’s a problem with your system. Pay me and I’ll fix it.

Niels

Yeah, and the other hand, hopefully, you’ve got a good relationship that, like you’ve done the best you could at the time when you were writing the software, right? And as long as that kind of trust, then I would definitely encourage everybody to do exactly the same. And How hard would it be just to drop that message saying, Okay, this is inside, I noticed an issue. And feel free to reach out to me if you need any help, right? That that’s the that’s the key thing to do. For sure.

Jamie

Sure. But then I guess you can only do that so long as you have those security audits and dependency graphs. And I guess someone in the organisation needs to be on some kind of mailing list to get information from the authors of those packages. Right, and all the dependencies. So let’s say, let’s say you are building something with again, I’m not trying to pick on NPM. But let’s say you’re building something with NPM, you’re using, I don’t know, some platform system, let’s say Angular, right? I’m not saying Angular has any security vulnerabilities, because I don’t know I’ve never done an audit, right. But Angular will likely have a massive security dependency, like a massive dependency graph. Sorry, right. And somewhere down the line, it’s probably using left pad or Event Stream or my NPM package or is using something somewhere that’s going to get attacked. Now, I would assume, again, I’m not trying to pick on Angular, but I would assume that since Google is the main architect of that it is open source, but since Google’s the main architect, they get a handle the security. But let’s say something gets through it. I need to know as a developer who’s using that technology, that at some point, there was a security vulnerability and they need to fix it. So I got to be on a mailing list right? Or do I just I just keep hitting blogs and just go Angular news where it was was

Niels

was that a hard problem to solve, right? If you would have kept track of let’s say, the dependency graph I just talked about, then there will be the first step, if you’ve got some sense of like what’s inside the project at that point in time. That also can be a deliverable to the customer, right? saying, Okay, this is a, it almost is like a, it’s like a nutrition schedule on a box of food, right? Like this is inside, look at this. And this may contain gluten. So if people are like allergic to gluten, they should not eat it. So this might contain this library or this, this will use this library internally. So be aware of that. Right? That that’s, that’s, that’s a, that’s a really, that’s, that’s our problem, for sure. And I think it’s not easily solvable. That’s my conclusion, we should do the best we can. And maybe it’s similar with if you would point down to software bill of materials in general. And both Microsoft and Google have pointed out like, Hey, we need to do a better job as an industry in order to produce that. And, and I can already tell you like doing that dependency graph is definitely not enough. Because how can you give your customers guaranteed that the source that was in that source repo was eventually also the code that build that package? They got deployed? The steps that are done in between? How can you guarantee that that what happens that that would that exactly happened? And what happened? like is this you probably tested that you do some code analysis. But is it that source that isn’t that good tack that was being put into the package, right, and then you get to the space, also technical problems, like reproducible builds, being able to take source code yourself, and build it, that that those are hard problems that we need to solve? And I think what the dotnet core space, and the reproducibility is definitely, but it depends on your compiler, like what you have installed, but packages have you included, and then they will give you the guarantee that if the sequence, if it’s all the same, then the sequence will be the same, and it will have the same output. That’s the first step. But I believe what I think Mark russinovich mentioned that in his RSA talk on supply chains, that’s definitely one to watch. If you want to have a nice story about that. He told like, yeah, I think windows, they they got like two components that are being able, like they’re able to build reproducibly. But I’m thinking even within Linux, there are kernel modules that are not like they’re not able to build them exactly the same as they were like used right now. And that’s a problem. Because how can we then know for sure that the code that’s inside that package, or in that module, or in that library that’s using that system hasn’t been altered in a way that it has got some some problems? Right. That’s, that’s the, that’s a definitely a real big problem space that we’re not going to solve. But hopefully, if we’re able to focus on on software bill of materials and focus on supply chains, and recognising the fact that if you pull in that library, that becomes inherently a risk to your own application, because you’re also pulling the supply chain behind that library. And if it gets compromised, then your application is compromised. But that doesn’t still solve the problem. But like, as a contractor delivering software to a customer. And then so like, it turns off, right, and then we need to do some, some, some, some hands off, including that information. I think that’s the best you can do right now.

Jamie

You mentioned there about reproducible builds, right? I’m gonna get a little bit of buzzword bingo, right? Let’s say you’re building a microservices system that uses Docker for its runtime, right? You’ve got some series of Docker images, right? And they’re all based on like, let’s say my Docker image for my dotnet core portion is based on Microsoft dotnet core, which is based on Debian stretch, which is based on Alpine, which is based on, which is based on which is based on the sea graph for your runtime as well, not just for your code, right? No, it’s

Niels

even bigger than that. Yes.

Jamie

Yeah. Right. So then, then you go, okay, Docker run, and it goes, Okay, let me give me a sec, I got to pull the latest version of the Docker image, which was updated 30 seconds ago, between now and when you last run it, or you you It runs on your machine, and you’ve got the a version of the Docker base image. And then 25 minutes goes by you push it up for a CI build. And, and a change has been made to that Docker build image, which means it needs to pull that image in, and then everything breaks or something, some new vulnerabilities found, right, that makes it that must be an even harder target to hit. Because it’s not just the software that you’ve written, and not just the libraries around it, but the platform is running on is constantly changing. Right? Or has the ability to constantly change? Yeah,

Niels

yeah. I think there’s a there’s a bit of a flip you can make in this situation also. If you just assume that you like doing that late approach, often darker layers that will be pulled in That implicitly also means that your security needs to be layered, right. So if you have a Docker image that will do some processing for you that generates PDFs, that’s one of the examples I’ve used in my third party risk talks. And one of the problems that that our library was introducing. And that was mostly based on the way that it was used is that it was able to do web requests from that PDF library to get an image into a PDF, which is like, a trivial thing to do, and everybody does it. And that’s just how it works. But that’s, that’s a problem. If we look at it from security side, it’s something they call server site request forgeries, which allows the, if I can like get put in data, then I can get that Docker image to do a web request on my behalf, and maybe get metadata out of the system of the cloud when the web is running on or maybe do calls to other back end systems that I’m not allowed to reach out. But because I’m in that Docker image, that part of that’s part of that cluster, that I’m able to access it right. I think from that perspective, we talk about layers, and you need to lock down like, why would a Docker image if you don’t want to have those images loaded externally? Like why wouldn’t talk to the image you need to have like in internet access, or English and being able to do that, the question is, it will lock it down, right. And if you look at the library, like the library exposes the functionality, maybe you want to limit that. And maybe you want to cut out some of the things and I created a concept within dotnet core that allows you to do a load context. So which is a piece that will load all dependencies, at some point, if you if you start out an app, then there’s an assembly load context, that will take care of assembly resolving, and it will get all the libraries that you need. And it’s closely tied to what we used to known as something called an app domain. And what app domains we could do some isolation, right in the beginning of the dotnet, there was something called code access security that allows you to do fine grained access to a component. And that’s a really strong core like concept, but it was too complex to use, and it wasn’t used a lot. And ASP net has got something called medium trust, you might have been aware of it like if you lock it down, you cannot access them for any files. And in the shared hosting environment, it makes sense to lock down temporary files, because otherwise I can use that to read files from other apps, right? You’re not allowed to do that anymore. Um, but with that load context, what I’m doing is I’m stripping out types, and I’m just taking out the ability of a library to use HTTP client. That’s exactly what I’ve done in my demos on this. And I think that’s quite powerful. And what I’m seeing right now, even with

dotnet, five would blazer there. They’re doing stack stripping euro to reduce sizes, right, because if you do a five mega byte download of a dotnet app within the browser, in order to run it on top of webassembly, that’s, of course, a big burden. And it’s, of course, only done once, but the first initial load will take long, and that’s not what they want, right. So they will do some tree shaking, and they will cut out types. And I think that concept is also really usable to patch libraries and use libraries as as but then say, like, hey, you’re not allowed to do HTTP client, because I don’t want you to do that. And even if a developer uses that library, and says, like, hey, putting in a URL where he’s not aware of it, because it’s just like a data element that he takes from the end user, and just puts it into that PDF component, then it will still be like a lockdown because the library doesn’t allow that. And I think that’s, that’s a powerful concept and looking at other technologies, like web assembly. And I don’t know, if you’re aware of a concept called Waze, which is like a shared interface that they’re creating right now. Because webassembly can run literally everywhere. They will have a similar type of access control on the Waze layer on on that API layer that allows you to say, like, hey, this component cannot use this part of that base framework. And I think that’s a really powerful concept. And, unfortunately, with dotnet, and codecs, and security didn’t work out. But maybe there are ways for us to do it. And as I said, like with my demos, I’m just stripping out types, that will be the first step and you will have a load context that will be responsible for PDF generation. And you can still use it from your own app as if it was functionality that was close to your own DLL that you’re using. But it definitely has some some minimizations on what it’s able to do. And that’s a layered approach, right? I’m not saying that it’s, everybody should use that. No, but it’s the layered approach similar to getting back to that that Docker image or that Kubernetes cluster that runs on those images. And we will always have a layered defence, hopefully. And if one layer fails, hopefully it’s not a problem. If the second layer fails, then if the code is written in the right way, then it might still be safe, right? And hopefully, then all the alarm bells go off within the production system, and people can act on them, right. And then you get back to it like, hey, if I’m doing that, then I’m mature and I’m dealing with the problem in the right way. And you can definitely reduce risk. If you’re doing that. I think so that’s the opposite side. Just assume that you’re like on a thing that might be compromised and work your way down from that. Sure.

Jamie

Okay. My goodness, is this a lot? It’s not, it’s not a quick put a bandaid over it and everything will be fine. Right. there’s a there’s a lot of stuff involved, which is why I guess the security professionals are so sought after, right? And why, what and I guess it’s also why security is traditionally don’t last because it’s like, we don’t want to have to deal with all of those headaches. We don’t have to deal with the platform changing and the library changing. We’ll just wait till last minute doing that. Right. That must must be why it was traditionally done that way.

Niels

Yeah, it’s unfortunate, because if you that would correlate that back to the money, it costs to fix it afterwards, or to do it right straight from the flex straight out starting out doing the right thing. That’s that’s that’s, of course, also like, a key difference than doing it at the end. And then having an absolute application security guy kicking the tires, and say like, This is bad. And also the relationship between the development teams and security team won’t, like won’t help out, let’s put it like that, right? Oh, there’s there, they’ve got those guys that will hold us back on not putting to production. And I think like, as I said before, I’m a strong believer, like, facilitate, make sure that developers can take the right decisions from the start. And they just go on production when needed. And everything is a blessed like, and they might not even notice that there is an application security process that runs underneath it all. And that will have those basic risks covered in the right way. Right.

Jamie

So one of the things that, that we’ve talked about, there’s a whole bunch of stuff that we’ve talked about, hopefully, we haven’t scared anyone out of the business, or just saying some things that you need to know about, because that’s the way that I like this show to be is like, Hey, here’s this thing you’ve you’ve likely never really thought about. So it gives you something to go away and Google or Bing or search or whatever, and go talk to someone about it and learn a little bit more. And I happen to know that some software houses have almost like a, an internal server, like a private feed of publicly available packages, right? Let’s go with nougat. Right? I know of at least one company, one software house that has a private server on prem or whatever. That only their their employees and build servers can access. So the when they build the software, does the new get restore or whatever. But it only pulls this specific vetted audited packages, rather than pulling them from the public source, because like we said earlier on, what if 12.1 and 12.2? What if some security issue is present in 12.2, but you’re using 12.1, you do dotnet date, or whatever it is, then restore is going to pull 12.2 unless you pin it specifically to 12 point 12.1. So is that a practice that you would recommend? Is that something that folks should maybe start with rather than going oh, my goodness, the sky is falling? I don’t know how to deal with this is way too many security issues. The platform’s changing the libraries changing, my code is changing. Maybe start with one thing like perhaps a private version of a public repo for your common libraries? Or is it more a case of don’t worry about that? That’s the least of your problems? Because here’s the biggest problem

Niels

depends on the context and depends a bit on on the risks. But I think in general, I would say it’s definitely good to consider doing some curation in that area and say, like, Hey, this is the baseline of packages, we’ve got our own own build system. I even got questions like, Hey, would you maybe forked the repo that built that’s been used to build a package and do it yourself? If it’s a high profile app that contains a lot of risks for your organisation, then it might make sense to have that strong, like curated builds of that component, and make sure that you know exactly what’s inside. On the other end, minor updates? I would say just go with the flow, because it should not like hold you back in in development. And then that depends, but yeah, I think if you start out looking at like, maybe pinning to a version saying like, hey, this, this is a version you should use, as you already pointed out, it doesn’t necessarily mean that the whole dependency graph would be exactly the same, right? That it’s a trade off. I don’t think there’s a there’s a good answer to that. That totally depends on the organisation, but if there’s a baseline you want to work with, and it makes sense to have a base liability centre that everybody uses, right? Because that’s easy to curate. And there’s no need to go over saying like, Hey, we know exactly everybody’s on his own distribution. We know that because that’s, that’s something that we maintain With our own own repo internally, and that makes it easier, right? For sure.

Jamie

Sure. Okay. So let’s say I have a small library, I’ve already looked it up on the in the source code, I’ve gotten to GitHub get lab, wherever it’s hosted. It’s maybe four files. And it’s C sharp, I know that there is a built pipeline, I can see the build pipeline, maybe there’s a GitHub action, and it produces a DLL, which is, or a new get package, which is pushed up to nougat. So I know that I can see, when each build is pushed up, I can see the hash values that calls the build to happen. Is it worth me pulling the source code and doing it like a line by line security audit of, Oh, I get what they’re doing? Maybe they should change this? Or is it a case of just pull the DLL get the or rather pull the nougat package, make sure that it is that exact version that came from the build that happened in GitHub actions, or the CI CD pipeline? What’s, what’s the process for actually, in your opinion, for actually auditing is small, I’m not talking like a like a Newton, soft JSON, or any of the packages that make up the dotnet core runtime, and I’m talking like, something that does a single action, right, we can talk about the same thing for NPM, I guess, like left pad, right, that has no dependencies. But it does one very specific thing, how do I go about auditing that and do I pull the built version two, I pulled the source code and just sort of pull request all of the changes in merge all the changes in what what’s what’s the process for a small, small package.

Niels

If it’s such a minimal package, then you could, you could choose to pull in those files and just have a part of your own product. And then you of course, need to maintain it yourself. But as you said, if it’s really simple and a small package, then I would still stick with getting the package from the source where it originates from, and maybe have some sense of what’s inside, look what’s inside to a certain degree. And even if it’s a bigger project or something else. So I wrote a small tool myself that allows you to do an assembly dump of a dotnet assembly, and it will point you out to all API calls that are done inside that library. And there’s some like alphabetical ordering in so it’s a flat file. And if you do have a version x over library, and if you do it from version y, which is the next version of library, you could easily compare and see like, hey, what type of API calls are there done inside this library is something I should worry about if it’s all in the system space. And if it’s just some basic stuff, then don’t even bother looking into it in more detail, just accept the fact that it’s there. If it’s using API calls that do have concerns tied to it, which might be far manipulation, or if it has a binary format inside of it, then I would definitely scratch behind the ears and say, like, Hey, this is a package that needs more attention. And I would still maybe pull it from its original source, right, just to have it more excited to have it there. And it also depends a bit on the risk profile I talked about before, and how beta component is because I totally see that it’s not like you cannot ask a developer to do a full fledged review of something. But I think it would be good to have some basic sounds. And if there is a way of dumping that which I’ve done it, it’s a tool called Sonic, which I created, which is on nougat you can get, it really does that straightforward dump. And it allows you to compare it and and that will just give somebody the at least the urgency to look into something. And if there’s a version, and if at some degree, it gets in another library, which makes no sense in the context, then alarm bells should run off, right, so that they did you do like a more high overview of the library. And I don’t think it doesn’t necessarily mean it needs to be something you’d build yourself. And I think it just rely on the package manager to deliver the right stuff to you, but still have some sense of what’s inside. And also, as a developer, I think the least you need to do is if you pull in a library, you need to have you’re pulling a library to achieve something you need to have some good sense of what’s inside and how it’s used, right and use it in the best way possible not to introduce any any risks. If there are any, maybe there’s an API call you should not do. And if I then put the parallel back to dotnet. That’s the big thing I like about dotnet core and ASP. NET Core, the defaults are really strong. Meaning that the it’s you can do that stuff. But you will choose to do so. And in to do it explicitly, which also makes it really easier for static analysis vendors like us to identify problems, but it will, it will force developers to to walk the right lane by default. Right. And I think that’s that’s a really good thing.

Jamie

Okay. I mean, that makes sense, right? You, you have to know what’s running inside of your application. I think that’s one of the key takeaways that I’ve taken away from from this chapter. thing is that I need to know what is running before I can worry about. Is this code secure? I need to know what the code is. Yeah, not necessarily line by line, but maybe a high level overview of like you said that dependency graph, right. I need to know what my software relies on. So that I know where to look for potential security vulnerabilities, right? Yep. Okay, excellent. Yeah. Because I do remember working on some projects, where they’re just like, Don’t worry, just pull this new get package in or just pull this NPM package. And I’m like, Well, what to do to manage it, get the look what I did, right? This one developer said to be wheels, I was stuck with this problem. And I did a Google four NPM package to do this. And I just literally NPM installed the first one that I found, and it solved my problem. And I’m like, Yeah, but what does it actually do? Well, I don’t know solves the problem.

Niels

Type the type of squatting in named packages, right? Look up, look up my talk. I’ve got some examples about that, like how easy it is to pull something in and it solves your problem, but you pull in a lot more, you need to be aware of for sure.

Jamie

Absolutely, absolutely. So then just sort of on our way to sort of wrapping up. And let’s say I’m completely new to this whole thing, where I don’t know about security audits, I don’t know about any of the stuff that we’ve talked about, I don’t know about, like our own sort of private NPM repos, or new Git repos, or whatever. If you were to take someone under your wing, like an apprentice and say, these five things, go learn these five things, I’ll go check out these five resources. And that will get you started what what would be the best place to start this journey of learning about making my applications more secure, from a sort of pulling in third party code point of view?

Niels

I think it I think it’s hard to tie to libraries in general. But then I still would say, the education part I pointed out before, having some awareness of some basic security issues and how that relates to the way that you run your software. I think that’s the key thing, that that’s the awareness step on, he has the information, he needs to do his job at that point, right, and also has a way to improve his skills or her skills in order to not introduce any of those problems. I think I think that that’s the key thing. And I think I’m heavily believer of having some sense of what you pull in and why you’re using it for right, I think that’s the biggest unseen problem. Like if you’re not like, if you started developing, and there’s a basic tutorial, if you look on docs, microsoft.com, you can start developing literally everything right? Make sure you’ve got some sense of like, Hey, what’s happening? And why am I doing this? Or I need to do this image manipulation, and I need to pull in that library. Okay, so what do I get with that? Like, how does that then reflect my software, and I will definitely, if there’s, if somebody starts out developing, as I said, about the risk analysis type of thing, like making sure that you can draw a diagram of your app, and identify some of the data flows, identify the components that are needed to order to store its data in a crisis to disk queue, it’s part of our internal infrastructure. That is a, there’s some configuration management happening, it maybe needs to get some secrets, because it’s a Docker container that will have environment variables, which of course, is a bad thing. But you need to maybe use a Key Vault in order to build those best practices, and point them out to do the right job starting out from that point, and work your way through that, right and all, and still encourage everybody to use technology and use new technology. I’m a big fan of new technology, I think it should not hold people back on creating cool stuff. But always flip the switch now and to make sure that you know, you’re aware of, Hey, this is cool stuff. But what are the implications? It’s similar with the example of webassembly I gave like people are a bit scared like, Hey, webassembly in such a browser and running the kind of things and as I said, like, the thoughts and the designs that are done behind it with the standards that’s also done by people at Mozilla. I think it’s really, it’s really cool to see, okay, they’ve thought about this, right. And there are people in the industry that worked with dotnet. Also before that, move to webassembly. And then have some sense of like, these are good standards, this is a good model to work with. And there’s always a trade off between writing functional software and creating secure systems, right, because the most secure system would be one, you turn off, you dig a hole, and then you put the system in, and then it’s fully secured, because nothing will happen. Unless there is water coming underneath. Right? That’s, that’s a different story. So be aware of the context of the app that you’re writing, and work your way out of that. And just, as I said, enjoy technology and build cool software. I think that’s the key thing I would like to to take away to people who start out,

Jamie

okay. I mean, that will make sense, right? You’ve got to get to have an awareness of what the problems are and, and not be afraid to try something new. No, but it’s It all comes back to education, right? You’re one of the things when I was at university, I did Computer Science at university. And the thing that they said to me was, we aren’t going to teach you everything you need to know. There isn’t meant to be that we’re not going to teach you what you need to know, you’re not going to learn it all from us. We need to set you up for lifelong learning. And a lot of people get into this business and like, I can be a programmer or a developer or a coder or whatever name you want, make loads of money on them never have to learn a thing again, and I’m like you again into the wrong business. Exactly. If I have to learn anything ever again, you’re in the wrong business? For sure, because it’s like my friend James jokes. Hey, we’ve been talking now for 30 seconds. That means that 4000 new JavaScript libraries have been created. And it never stops, right?

Jamie

Because you’re right. We’re constantly moving forward, which is both a blessing and a curse, we get the new, shiny, new amazingness. But also, you need to take a moment to maybe think about learn, study, and then reflect on what you’ve learned, which is important. Right? Excellent. For sure. For sure as so what about what about keeping up with you then if people want to learn about maybe the next time you’re giving a talk or any interesting blog posts or video, I don’t know whether you’re a badass writer or a video creator. But if you are doing these things, how do we find out about it.

Niels

So I do have a blog, which can be found at blog dot Finnick dot Dev. And it also has a list of speaking engagements that I’ve done, including videos and, and code snippets. I think that’s that’s a good. That’s a good starting point, when talk about third party risk, if people want to see more about the assembler load context, that’s what I’m pointing out there. And my GitHub repo has got every source example that I’ve used in the past. So that will be a good start. And keep an eye out on my blog. I started that out beginning of this year, with the intention of writing a lot, but you know how it goes. And maybe this isn’t a good trigger for me to be more actively on that because I’ve got some, I’ve got some things, some stuff ready that I need to share about software supply chains, about the rozlyn. A code generator, source generators, which are pretty powerful also to do some security stuff with so go go see my blog and my twitter and start from that I would say,

Jamie

excellent. Okay. Well, I mean, that’s, that’s essentially all the questions that I have. We did veer off topic, a little bit of inside baseball talk, I do send around a document with here are some of the things I’d like to touch on. And we veered off course, like like we normally do. And hopefully I didn’t catch on too far off guard. No, that’s completely fine. That’s fine. No worries. Excellent. Yeah, thank you ever so much, Niels for taking the time to chat with me today. I really appreciate I genuinely really appreciate anyone who comes on the show. But this is incredibly exciting, too, because I’m always about tweaking my code to make it a little bit more secured. There were a few things we talked about that I’m going to go do this afternoon, and figure out how to implement into my normal daily practice. So cool. Thank you ever so much for that.

Niels

You’re welcome, Jamie. It was my pleasure to join you in this conversation. Cool. Thanks.

The above is a machine transcription, as such there may be subtle errors. If you would like to help to fix this transcription, please see this GitHub repository

Wrapping Up

That was my interview with Niels Tanis and the security risks of including third party code in your applications. Be sure to check out the show notes for a bunch of links to some of the stuff that we covered, and full transcription of the interview. The show notes, as always, can be found at dotnetcore.show, and there will be a link directly to them in your podcatcher.

And don’t forget to spread the word, leave a rating or review on your podcatcher of choice - head over to dotnetcore.show/subscribe for ways to do that - and to come back next time for more .NET Core goodness.

I will see you again real soon. See you later folks.

Follow the show

You can find the show on any of these places