The Modern .NET Show

S06E16 - Building Secure Software: Unveiling the Hidden Dependencies 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

S06E16 - Building Secure Software: Unveiling the Hidden Dependencies with Niels Tanis
The .NET Core Podcast

S06E16 - Building Secure Software: Unveiling the Hidden Dependencies 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 Summary

This episode features the return of Niels Tanis, a renowned software security expert who shared valuable insights on building secure software and promoting safe technology usage. Tanis, with a background in .NET development, transitioned to security in 2014 and specializes in pen testing and ethical hacking. He emphasizes the significance of default security measures and the need to make insecure choices difficult during the software development process. Tanis encourages developers to think like attackers to effectively secure systems.

One of the challenges discussed in this episode is the abundance of questionable ideas and architectures shared through blog posts and libraries. These suboptimal approaches can lead to long-term problems, making it crucial for developers to seek guidance and collaborate with experienced professionals. Unfortunately, some developers lack the self-belief to ask for help or admit when they are unsure, hindering their growth and development.

The conversation touched upon the risks associated with outdated dependencies in software projects. Security vulnerabilities and bugs can go unnoticed and unpatched if dependencies are not regularly updated. Furthermore, the speaker highlighted the importance of assuming good intent while using shared packages and libraries, as social engineering and malicious code injection can pose significant risks.

The concept of a software bill of materials (SBoM) was discussed as a crucial component in tracking and documenting all dependencies used in a project. Similar to a manufacturing bill of materials, an SBoM ensures regulatory compliance and aids in identifying potential risks. Provenance, on the other hand, provides information about the build process and tools used, offering insights into the integrity and reliability of a software component.

Several tools and initiatives were mentioned in the podcast to strengthen software security practices. The Guac project by Google focuses on the next step after obtaining SBoM data, enabling actions based on that information. Additionally, Scorecards, an OpenSSF project, provides a way to assess open-source projects for risky practices, while Fennec CLI helps generate security scorecards for .NET projects. The importance of fuzzing, testing components with invalid data to uncover logical bugs and security issues, was also emphasized.

In an era of increasing cyber threats, secure software development practices are paramount. The insights shared by Niels Tanis on “The Modern .NET Show” shed light on the challenges faced by developers and the importance of seeking guidance, collaboration, and continuous learning. By prioritizing secure coding practices, regularly updating dependencies, and leveraging tools such as SBoMs and security scorecards, developers can enhance the resilience and reliability of their software.

Episode Transcription

On Apple Podcasts

Just a quick note for those of you are iOS users (around 40% of the community of listeners):

When iOS 17.4 drops, you'll be able to read transcriptions for the show in Apple Podcasts. Problem is, I have no way to test whether these transcripts are correct or not, and given the technical nature of the show (and my own experience of creating the transcripts for the website) I doubt that they'll be correct.

I'm working with the podcast hosting company that I use for the show to figure out the best way to provide in-app transcripts, but until then I can't guarantee the quality of the Apple provided transcripts.

The best place for a transcription will always be the show's website, and there will be a link to this episode's transcript in the show notes.

And keep in mind that, not to bash OWASP and the top ten at all because I’m a big fan of OWASP, but people always tell me like, "yeah, I’m OWASP compliant," and that’s the biggest BS, to be honest. Because a top ten could not like, it should be an awareness piece and you should work from it. And there are better ways of dealing with that. But I think a security scorecard should never be a goal. It should be a means to reach the goal, to have better understanding, right? And hopefully they can change stuff and be more expressive.

- Niels Tanis

Welcome to The Modern .NET Show! Formerly known as The ..NET Core Podcast, we are the go-to podcast for all .NET developers worldwide and I am your host Jamie “GaProgMan” Taylor.

In this episode, Niels Tanis returned to the show. He was previous on the show back in episode 69 - The Risks of Third Party Code With Niels Tanis - which was released back in February of 2021. I asked Niels to back on the show to talk more about securing the software development supply chain and SBoMs (Software Bills of Materials)

Yeah, that makes sense. It’s funny.

So I think when I started out talking about supply chain, and there were some tools that have been introduced to do SBoM data, and then you also come into an area called provenance, which tells more about the build and about "this build server was used. And I’ve run on GitHub actions, or I run on a GitLab instance, or I have stuff done differently," right? Maybe even the Redhat one: Tekton, that kind of thing. And based on that, I’m producing an SBoM.

And I did a talk and I concluded with that, "it’s like, these are cool tools, you need to look into it." And then somebody at the end asked me the question, "and the what? You have all the data? And then what?" I said, "yeah, that’s solid question because that will be the next step." And it’s funny that you mentioned it as well.

So over the time, I think it was around already when I started out talking. But there’s a project that Google created called Guac.

- Niels Tanis

So let’s sit back, open up a terminal, type in dotnet new podcast and we’ll dive into the core of Modern .NET.

Jamie : So, Niels, welcome back to the show. This is your second time on the show. We’re going to talk about more security stuff. It’s brilliant to have you with us. Thank you very much.

Niels : Yeah, thanks, Jamie, for inviting me again. It’s been a while, but it’s good that we can catch up and talk about some new cool stuff. Yeah, for sure.

Jamie : Oh, absolutely. So for folks listening in, we’re recording this Jan. 16th just ahead of, I think it’s next week after NDC in London. And I know you’re speaking there, but just to give the listeners a bit of insider baseball, we actually reconnected just after MVP summit this last year in, I want to say, May. And sometimes it takes a while to rearrange things.

Niels : Yes. And just to make sure, I’m not speaking at NDC London, I’ve spoken at NDC security last week, unfortunately, NDC London next week, which is the most awesome event held in London for sure. But no, I’ve done a lot of those DNCs. It’s even for me, hard to figure out which one I haven’t done or which I’ve been scheduled to. But yeah, those are the good ones.

But yeah, I think it was April that we run into each other at Microsoft campus right at the summit. It’s good to see and then talk face to face, right after all the stuff that we had over the years before. So, yes, it was good to see you, Jamie. And good to sync up on this as well, saying, "okay, we need to do a new one. We need to talk about some new stuff."

Jamie : Yes, 100%. I must apologize for getting that wrong. I think earlier today when I was doing a little bit of last minute research, I did Google to see if you were giving a talk at NDC and the web page actually exists. If you go to, "NDC London speakers Niels Tanis," you still appear. The header for the page is NDC 2024. So I’m like, you must be speaking there then.

Niels : But you’re not.

Jamie : So thanks. NDC, you messed me about.

Niels : You’ve been social engineered, Jamie, without even noticing it. That’s cool, right?

Jamie : It’s that continuous drive for search engine optimization. That’s what it is.

Niels : I think it is.

Jamie : Cool.

So yeah, like I said at the start, you’ve been on the show before, but that was back in episode 69 to give some kind of frame of reference. I think we’re about double that by now. I’ve kind of stopped with episode numbers. So, I mean, listener, if you want to email me and tell me, I’m wrong and tell me that we’re way further ahead or not as far ahead, then that’s totally fine. Let me know. But yes, 69 episodes. That’s pretty cool.

So I wonder, for the folks who perhaps haven’t heard you on the show before, could you give us a bit of a brief, like an elevator pitch or a speaker bio or something about you?

Niels : About me? Yes, for sure.

I always tell, like, when I start out, I talk, "like, it’s always polite to introduce yourself if you start a conversation." Yeah. So I have a background in. Net development, did that from my early days to the early two thousand s with the first bit of. Net, and always did security on the side. Software security 2014 moved fully into the space of security and doing pen testing, ethical hacking, which was fun. Breaking is fun. Building is much harder. That’s my conclusion. And building software is the thing that I focus on right now, and I want everybody to do that in the most safest way and not let technology get into the way of making stuff less secure. I think that’s the take on it right now.

And in my day job, I work for Vercaode. We do static analysis, and that’s mostly programming the heck out of every SDK that’s related to .NET. And I’m also doing a lot of Rust, which I’m probably not allowed to talk about on the podcast, but I might have got some references because that’s a really cool ecosystem. And there are some analogies. Even if you look at the language structures and how C

does it, they all look at each other. And that’s cool, right? Because that improves technology stacks and that improve the way that we can write our software.

But yeah, that’s it in a nutshell. And as you said, I’m doing a lot of public speaking across Europe, even across the globe, which I enjoy a lot, because, as I said, I would love people just to use technology in a safe manner. And I’m also keen on new technology stacks and looking into those, because that should enable people and it should not hold people back. Right. So, yeah, that’s it in a nutshell. That’s who I am. And I think it probably matches up what I said in episode 69, but I need to re-check that one.

Jamie : Yeah, that makes sense.

My point on appsecurity and, "just secure everything by default," is that it should be by default and we should be doing things secure to start with, if that makes sense. Right? Yeah, and I totally get why. If you’re reading a quick start guide on how to use a library, it’s probably not going to give you best practices and security from the ground up because it’s quicker to get started; because they’re writing a "get started" or a "quick start" or whatever.

Problem is of course that we all know that if you’re in an enterprise environment and you do a quick start on anything, that quick start becomes the mvp, right? And then the lack of security from the ground then becomes lack of security throughout the entire app. Right. And the only way to then go back and fix it is to then fundamentally rewrite the entire thing from the start, which is no good.

Niels : Sounds like "unsecure by design." I should brand it that way. Yeah, right. That’s the right take on it.

Honestly, looking at .NET Core, and I’ve been. So when I moved into Veracode, we started out doing .NET Core. Then it was like the first bits of .NET Core were released. And I honestly think that the movement done by Microsoft in having better defaults, having better APIs that are more explanatory in what you’re doing at that point that has definitely improved and especially with the .NET Core family and going up until .NET 8 that we’re at right now. If you do stuff that’s bad, then you will need to call a certain API.

The thing that I always give as an example is like suppressing any certificate errors. Invalidating the API says dangerous, right. And the other thing about what you have seen over the last releases, let’s say, and I can talk about technology already, but for example like BinaryFormatter are being deprecated. That’s the thing that makes me really happy because there’s a lot of problems evolving from that thing. And right now I think .NET 8 would be the framework where it’s fully gone out and you cannot use it anymore. Right. Those are defaults that will help the developer making the right choices and even those getting started templates should be by default the right thing.

And I think last November there even was a security issue found in some Blazor stuff which had to do with a default template and people just filed it and it got fixed and then everybody needs to update their SDK. So it’s thing that they look into and I think that that’s cool. But I totally agree the default should be the right thing to do and it should be less of a burden and it should be really hard to do the wrong thing unless you really have thought about it. And as long as we stick with that, I think then we’re already in a better space for sure.

Jamie : Yeah, definitely. I often tell people, in fact I was telling someone last night that the best way. Please correct me if I’m incorrect with this, but one of the best ways to secure anything is, unfortunately, to think like a criminal. Think like the attacker. That’s why red team exists, right? "How do I secure this from being broken in, then? In order to figure that out, I need to break in," right?

Niels : Yeah, it’s funny. So listening at episode 69, that was exactly the analogy we also had about like having three cars in a row. And the one with the steering lock will probably stolen, will be kept there because the one that next to it has no steering lock will be easy, accessible. Right. So you need to look into risks. And I even gave the example of houses and having your own house being more secure than the ones of your neighbors. That’s the same, right? Because at some point stuff will happen, you need to act on it, and you need to at least make sure that it takes a lot of time and therefore you’re not as attractive anymore, because stuff will be found over time in technology stacks. People thought that certain things were secure. Turns out that they were not so secure at all.

Last week at NDC Security, there is a real nice talk, and I would encourage everybody to look into it if you’re in the .NET space done by Jonathan Birch, who works within Microsoft on software security. And he does a lot of office stuff. And he has a real cool talk on binary formatter and digitalization, but also on mutation stuff that happens, which is like mind blowing if you listen to it. And I think he even has a Defcon black hat version you can find on YouTube right now. But you should wait for the NDC security version because there’s some new bits in it which are quite cool.

But those are things like stuff will be found over time for that reason. And as you said, you want to architect things in the right way and make sure that it’s SOLID and that you’re able to act on it, right. And I think that that’s the key in order to make stuff more secure. This is probably almost feels like a dad that repeats itself to its kid, right? Yeah, it’s like, "not again, dad, you already told this."

Jamie : But I mean, with good reason, right?

In the last couple of months, how do I put it? I’m trying to think of the best way to put it. I’m not trying to throw shade upon the people who are putting out these blog posts and libraries and things, but I’ve seen a lot of blog posts and libraries where I’m reading through it and going, that’s not a great idea. I understand why you’re saying, "hey, you should architect your app or your code base like this," but in six months time, once you’re past the startup phase of your library, or past, "I have created an example, past the hello world version of your app," you’re going to hit trouble because you’ve not set yourself up to fall into the pit of success. Right. You’re not architecting it in a great way.

And I think some of that comes down to perhaps experience and perhaps education. And by that I mean being able to turn to other people around you and go, "hey, is this the right way to do this?" And sometimes it’s a bit about maybe a little bit bravery as well, being able to. Like, if I were working with you, Niels and I wasn’t sure about something, I’d want to turn to you and say, "hey, Niels, is this a secure way to do this?" But I’ve noticed that a lot of people rather let me retract that. I’ve noticed that a subset of developers don’t have that self belief to actually be able to say, "look, I don’t know what this is. I’m going to go ask Neil. So, I’m going to go ask whoever," right?

I’m going to go ask some people, and I feel like maybe that’s where we’re heading, is that we’ve started this cycle again of people like you and me just complaining at people, like you said, like the dad shouting at his teenage son, "no, you can’t do that. And here’s why." And like you said, "you’ve told me that before, Dad." "Yeah, but I’ve told you it before, but you still doing it."

Niels : Yeah, that’s the problem. Right? And you want the best for your kid as you want probably the best for yourself, or like, good intentions. Right? As you said, you’re not doubtful about people not doing the right thing and just also accept the fact that sometimes you’re wrong. I’ve done stuff in the past which I think, like, hey, if I get the question, like, what is the most security thing that you’ve done, which you done in the past, which you’re not proud of, there’s a lot. If you would pick up my code from, let’s say, a decade ago, then I would probably start crying. And that’s exactly the reason, right? Just assume that you at some point, h"ey, I don’t need to know it, all," right? And that’s the thing. And if you have a good team or a good culture within the organization that will enable you to say that I think that’s quite powerful and we need that in order to move forward because, yeah, it’s always like, "hey, I’ve written this software. I totally know what I’m doing, man. I don’t need any security, right?" If I’m allowed to say it, like, cocky approach on this.

It’s me. And I’m not wrong. I’m a developer. I’ve been a principal developer for like a decade, man. How are you even considering doubting my abilities? And I always keep my mind open, said, "okay, but what if I’m wrong, right? Or what if I miss out on something?" And I think that should be the approach 100%.

Jamie : There’s something you said there that really tracks with. I think it was two years ago I was listening to. So I listen to a lot of podcasts outside of everything else I do. And one of the ones I listen to is a show called Clear+Vivid. It’s got nothing to do with software development, but it is related to what you just said there.

And if you’ll indulge me, Niels and the listeners, I’ll tell you a little bit about this show, which is hosted by Alan Alda, who is an actor who’s in his 90s. And he was interviewing, I can’t remember who it was. I’ll get the link for the show notes. But he was interviewing someone, and at the end of every single episode, he asks, "six quick questions that are designed to elicit very quick answers." One of the questions he’s asked across all twelve seasons of the podcast, it’s not been going for twelve years, but for twelve seasons, right? Twelve seasons of the podcast. Every single episode has this question in it. And that is, "how do you tell people that they’ve got their facts wrong?" And what’s related is that the guest for this particular episode, I wish I could remember the person’s name, but he said, "with great humility, because I might be the one that’s wrong."

Niels : That’s good.

Jamie : Yeah, right. And I think that’s super important for every walk of life. I think that person that was being interviewed was a writer. But I might be wrong. But just sort of approaching something and saying, "actually, do I know everything in this situation?" I think is a very important and salient point for everyone to think about, and not just with development, just with literally everything. Right. There’s something that Brene Brown says in one of her books, and that is just to assume that everyone’s doing their best. If you pair those two up, when you go into a situation instead of getting angry and shouting and being, "this is bad, the code is wrong and you are wrong and everything’s wrong!" Just like sitting the and going, well, maybe they did it this way because either they just don’t know or maybe there was a huge amount of internal pressure to actually ship the software. Right. Who knows?

Niels : That’s good. That’s really good. Thanks for sharing that one for sure.

Jamie : Thanks.

But yeah, if we’re able to pair that idea up with secure by default, then we don’t ever have to get upset, do we? Right, because, all right, you might end up with a supply chain thing, which we’ll talk about in a minute, but by default the code is then more secure than anyone else’s? More secure than the bad code? I don’t know.

Niels : Yeah, I think it’s a good starting point. The baseline will be more solid than starting out with that thing that’s broken by default for sure. Yeah.

Jamie : Cool. Okay.

So I guess just to give a teaser for our previous discussion then, and I wonder if they’ve changed. Last time we talked, we talked about the risks of taking a dependency into your project. Right. Which we’ll talk about a little bit more in a minute because we’re going to talk about supply chain security. But I wonder whether anything’s changed since last time. Could you give a really quick brief, two sentence, five sentence, 60-second overview of maybe the top three security risks, I guess, of just pulling in a NuGet package or whatever to your project, like I dotnet new and then I go NuGet install X. Well, maybe not "X" because people are going to think I’m talking about Twitter, but package Alpha or whatever. Right?

What are the top three things that I really should be worried about?

Niels : That’s a real good one.

I think we collect some statistics ourselves and this is the only plug that I’m going to do about Veracode and I’m not going to mention it anymore. But we will have the state of software security published each year, which exactly tells the trends about what’s happening and what we have seen. And in the version we did on open source a while ago, I think it’s like one ish plus years. We saw that if a dependency gets added, so people add that package to your NuGet, like from NuGet to your source locally and you start developing it. We have seen that almost 80% of people never touch that package anymore and never update it, which is quite worrisome because we need to update and bugs are found and security problems are found and there is a need for updating things. Right? That’s the thing. So I think that’s the biggest problem.

The other thing that was published recently as well, and I’m going to take a sidestep and move a bit to the Java ecosystem because two years ago we had log4j happening, which is like a big known security problem that everybody was facing because logging was done literally everywhere. And technically it was based on the fact that, "hey, there’s some untrusted data ending into the logger that will then allow you to do external calls or do some code execution." That’s what it, in a nutshell is. Turns out that right now, last December we did a check after two years and said, have we learned that there’s still 3% that’s vulnerable and there is almost 4% who have updated only that version because of the problems. But after that there were a lot more CVE, so a lot of more known security issues published for that matter. And even one third of all what we’ve seen are running an outdated version, end of life. And that gives me the shivers because they are not even like in any way close to the latest version. And all the patches edit.

That’s the thing. And yes, there’s context in how libraries are used and it might not be a risk. That’s a risk assessment, right. And even if a business doesn’t decide to update it because of several reasons, then that’s a business decision, right. They’re willing to take the risk. That’s different. But I think that’s still in key, a big issue. If you look at NuGet in general, it’s always good to keep a sane picture of what you’re expecting from a library. And I know that I talked about this in the last time, like episode 69, about looking into intentions of library, "like what do you plan to use it for? What do I expect from it?" You want to know more about security and we’re going to touch that in a bit more like looking into NuGet packages from an abstract view and having the ability to judge if it’s the right thing to do or not. Because a package that’s widely used and has high statistics in download doesn’t necessarily mean it’s good, right?

Yes. You should always assume good intent and people have shared it with communities. Yes, and for sure. And if it’s run by one person, then there’s always that XKCD drawing about the modern digital infrastructure. It’s like a pile of blocks, and then underneath there’s a single block. I always use it in each of my talks, saying like, "hey, this block has been something that was thanklessly maintained since 2003 by some random person in Nebraska," which illustrates like, "hey, we put a lot of trust in those things, on building on top of it. And by pulling in a package, you pull in your supply chain of that package as well. So how is it built?" If it’s widely used, then people with bad intentions might think, "hey, I should grab hold of it or I should participate." And there have been stories where social engineering helped out people getting code into something which is not supposed to be there, right? That’s the thing.

So I think in general that’s the biggest thing. And always be aware that a package never comes on its own. There’s always the whole list of transitive ones included with that. And I think that’s the key thing. Even with, I think since .NET, I’m not sure when it was introduced, but with .NET 8, the CLI will do a check for vulnerabilities in all the packages, even if you do a dotnet restore.

So that’s cool. So if you grab a package like a project from GitHub, it will check it on the fly for you. That’s cool. But it won’t include the transitive ones by default. And people like the CLI tool. Yes, I’m happy, and everybody should use it for sure. And even if you do other stuff with our tooling or with, let’s say, the stuff that’s on GitHub, totally go for it, because it helps. But keep aware that, be aware that a package never comes on its own. There’s always a whole tree of stuff you will pull into it as well. And every package will have influence on the outcome of your app and what’s inside. And I think that’s the thing I would like people to take away from the security aspects of pulling in third party liabilities.

Do you have a WPF application and want to take it to macOS or Linux? Avalonia XPF, a binary-compatible cross-platform fork of WPF, enables WPF apps to run on new platforms with minimal effort and maximum compatibility.

With a few tweaks to your project file, your WPF app and all its dependencies are ready for testing on new platforms.

Start your app transformation journey with a 30-day free trial.

Head over to http://avaloniaui.net/themoderndotnetshow to get started today.

Jamie : Right. That all makes sense. Right. If I’m building a house, I take a dependency on the ground in which I build the house, right? And I’m taking a dependency on the pipes which provide the infrastructure: the water, the gas, electricity or whatever, and it takes away the sewage in that from my house. And so I need to be aware of those. And then I don’t know what it’s like in other countries with this, but like in the UK, if there’s like one water system or whatever that runs through the entirety of the UK, and if there’s ever a problem, the, it’s down to the local companies or the local councils or whatever, to go around to people’s houses and say, "right, we need to check your water pipes or whatever." And so you, as a person who lives in the house, not the person who built the house, took the dependency upon the people who keep an eye on the pipes to inform you that there is a problem. Right?

Niels : Yeah, for sure.

Jamie : We don’t have that in software, right. We just have the. "I am renting the house and therefore the pipes are my responsibility."

Niels : Yeah. Or, "I have no clue what type of pipes are even used that are like behind the plaster wall because they’re tucked away."

Like I refurbished my house as well over the last couple of years. And all the stuff that I’ve done with electricity and with tubing, which we’re allowed to do ourselves in the Netherlands, which is a whole different discussion, but it will put it behind the wall. I know exactly where stuff is found, but let’s say I sell my house and somebody walks in, that’s exactly the same situation. How do you ever guarantee that it’s all done properly? What type of materials are used? Maybe it’s a known fabric that turned out to be bad after x amount of years, which will turn in a risk.

So we have a lot of natural gas pipes over here in the Netherlands that will use our heating systems. And there was an accident where certain pipes were used, and it was also in my village that they replaced because they broke off. And of course you can imagine what happened if natural gas flows and into your basement, for example, and something else happens afterwards. But that’s the thing, right? And luckily they did exactly what you just mentioned in the UK, they caught up with it and they made agreements with every house that was known to be faulty, to be replaced, and they just did it. Right. And they connected my house, the old house I was owning exactly for that reason, with the new type of tubes, which were better.

So, yeah, that’s the whole thing and that’s the whole story. And it’s the same with, there’s no such thing as a free puppy, right? That’s always the analogy that everybody uses. Like, you can get stuff or an animal, but you need to take care of it, right? It needs to stay healthy, it needs to be fed. And for packages, kind of nurturing counts for the same reason. You cannot pull it in, and as I mentioned with the statistics of our report say like, hey, I’m not going to touch it anymore. That’s not how it works. They need to continuously look into stuff and hopefully have a good sense of what’s inside and what’s been put where in order to act on it as well. Right.

That’s step one. Maybe if you don’t talk about supply chain then the whole bill of materials type of thing, that’s the thing that comes more prevalent. And even European Union I’m sure like if the UK does any of it in general, but the US, they all have defined certain standards that they expect from commercial software. And I’m not like all the details, I don’t know all the details by heart. But it’s a good start at least to have a baseline for that industry because compared to building houses and other stuff, we need to catch up for sure because software is becoming more critical in business processes in the stuff that we do nowadays.

You cannot imagine if we don’t have got all the compute at our disposal in all the different things that we’re doing on a daily basis. Having your phone, doing all the stuff for you, having your intelligent stuff in your house, which even I as a security person, I have some stuff running and I will scrutinize it before I start using it; because it’s fun as well to understand how things work. But yeah, we do so much more with software and that’s a concern. It’s for sure. We need to have proper assessments done in order to make sure to have understanding what’s inside.

And getting back to the NuGet question, because that’s how we started out: I think that’s the key. Right. Be aware of what’s inside and pull it in and what comes with it. Have a good sense of what’s inside. I think that’s the step one. And then be able to act on if stuff is published, if you do a new build or a new release, and if then you do the net Cli vulnerable stuff and you see that there’s things inside. There’s even a real. There’s a site, I think it’s. I forgot his name, its name. But there’s a public registry even that has NuGet vulnerabilities being published that have no fix yet or you can look into it. We’re going to touch it if we’re going to talk about scorecards because it uses it as well. But it will produce a list of known vulnerabilities for a package. Right.

So the information is there and you need to do something smart with it, I guess. Right.

Jamie : Totally.

And I think putting in a software bill of materials, it feels like it’s a super simple thing to do. I’ve done it for a few projects that I’ve been working on. And it is just literally, if you have an automated build pipeline, you can make whatever build pipeline you use, let’s say GitHub actions for argument’s sake, you just drag in an action to perform on your build and it produces either an XML, or an HTML, or a PDF, or whatever of everything that you are relying upon. And that is like it takes what, 10 minutes if that. And the bang, you’ve got something, you can email that off to someone, or you can have that stored somewhere or like the majority of people I’ve spoken to don’t do anything with.

But the most interesting thing to me about that is that I was talking to a developer only a few weeks back, and I was saying, "maybe you should have an SBoM." And he went, "what’s one of those?" And I was like, "a software bill of materials." I sent him a link and he was like, "this makes perfect sense." He said, "my wife," he said,"works in manufacturing, like physical manufacturing, and they have to have a manufacturing bill of materials in the exact same way so that then they can pass regulatory compliances to say, yeah, we’ve built this widget with these particular materials in this particular way so that they could be certified to actually sell it to the public or sell it to businesses or sell it to whomever." Right?

Niels : Yeah, that makes sense. It’s funny.

So I think when I started out talking about supply chain, and there were some tools that have been introduced to do SBoM data, and then you also come into an area called provenance, which tells more about the build and about "this build server was used. And I’ve run on GitHub actions, or I run on a GitLab instance, or I have stuff done differently," right? Maybe even the Redhat one: Tekton, that kind of thing. And based on that, I’m producing an SBoM.

And I did a talk and I concluded with that, "it’s like, these are cool tools, you need to look into it." And then somebody at the end asked me the question, "and the what? You have all the data? And then what?" I said, "yeah, that’s solid question because that will be the next step.https://cyclonedx.org/ And it’s funny that you mentioned it as well.

So over the time, I think it was around already when I started out talking. But there’s a project that Google created called Guac

So they have their supply chain project called Salsa, which is of course somebody loves mexican food, and then they have Guac that comes with that. But that’s a graphic database - graph database, not graphic, but graph database - that allows you to ingest bill of material data, like in total at a station. So that are like provenance, but also SBom data that’s created by CycloneDX, which is a nice project that you can just use to produce that bill of materials for the full dependency graph. And then you can run queries on it.

And the cool thing is that I think they just did a rewrite just last couple of months ago. And right now, if you have all your SBoM data of the whole application landscape that you were responsible for inside a database, you can ask like, "okay, I’m interested in knowing which application runs on this version of this package," or "I’m interested in at that point in time we were running on a GitLab runner or GitHub runner," for example, "that had some vulnerabilities in it, which might resulted in a compromise." You can ask real specific questions about a certain moment in time. And I think that’s the powerful thing of having that bill of materials explaining what’s inside and how it was built. If you even have providence, that’s the next step.

And you can take well informed decisions by having that. So if people are struggling with CycloneDX or with other attestations, like in toto, from the provenance that they’ve built on, on Tekton or Tekton chains, then look into that Guac project, because that might be the answer of being able to search throughout stuff like, "hey, I’ve used this library before, a month or so ago on this project, which should be updated, right? I should maybe put out an email or a message to that customer or to that project team that’s responsible," saying like, "hey, we’re getting this, we need to fix this." Right? That’s the thing that takes the power of an SBoM and uses it in the right way for the same reason. Like, "hey, you used leaded pipes in your house. That’s not a good idea." Right? And which ones are there? Like in. Then you want to act on it.

Jamie : Yeah, totally. And like you said, unless you know that you have leaded pipes in your house, you don’t know that you need to act on it.

Niels : Exactly.

Jamie : And yeah, having the data, like you said, is the first step. And then extrapolating on that. I like this idea of being able to - because I looked it up a little bit whilst you were talking there -of being able to query that data. I’ve collected that data. "How vulnerable am I? Or am I vulnerable? Or what’s the problem here?" I think that the .NET 8 CLi is taking the right steps, but I don’t feel like it should be… my problem here is I’m going to be quite controversial. I don’t think it should be Microsoft’s job to make sure that my code is using the latest versions of my dependencies. Right? It should be my job to do that.

Niels : It’s cool that it’s a tool that everybody has at this disposal, right? That’s the thing I like about the fact that it’s a CLI and everybody who installs the SDK has it available that makes it accessible. That’s step one. Right? But I agree, you should be aware of it yourself for sure. For that reason.

And if I may catch on a bit on the NuGet thing again and move back into that space, looking into the fact that, "hey, I said if you grab a package from NuGet, then it would be nice if you’re able to look into how good it does security things in general." And wouldn’t it be nice to have a way of looking into packages from the outside saying like, "hey, is this a thing that I want to use or not?" Right? And I literally use this phrase in episode 60 as well, "like some kind of nutrition label for software and for NuGet packages." And last week I talked about the project that I’m working on right now, which is related on doing that for the NuGet ecosystem. And OpenSSF is the Open Software Security Foundation. Part of the Linux foundation has got a project called Scorecards. And Scorecards allow you to look into how good open source projects deal with security things. And if you go on their website, it’s securityscorecards.dev, it says, quickly assesses open source projects for risky practices and it will have a set of automated checks that it will run for you.

And in this case it’s heavily focused on stuff that’s residing in GitHub. So you can take the tool and install it on your machine and run it on, let’s say Newtonsoft.Json, right, which is still a widely used JSON library within the NuGet ecosystem. And it will get a score from 0 to 10. And of course 0 is bad, 10 is good. And if you go down you will see a whole set of risks. If you go on the website, you will see a whole set of risks that it will check for, the checks, how it’s called, and every check will have a risk level which will have a weight and its score will then be separately calculated. So hey, "do we have a security policy in place? Does this project have any branch protection done on the project itself?" Right. Could you just easily overwrite a public branch, which is a risk, dangerous workflows, like does it maybe have some patterns inside of it, but it takes external input and maybe execute something in the workflow context which allows people to hack the actions and maybe do stuff with the build output of it, right? So there’s a lot of good practices, but then at the end it will have a score and the that score will also vary from 0 to 10. And it almost feels like my middle school thing. If I had a 5, then it was not good enough, and a 6.something would be more than half. So that’s good enough, right? But that will give you a better judgment.

In the same way that if you grab a thing of food out of the supermarket over here in the Netherlands, it will have a nutrition label on it, and that nutrition label will explain to you like, "hey, if you take 100 grams of this product, then these are the elements that are inside it, right? And it will contain four cubes of sugar, let’s say 20 grams of sugar, which is not a good thing if you want to keep track of your weight." Or let’s say if you look at candy and there’s a lot of sugar in it, which is always the case, right. You should eat less of it, that would help, right? But it will allow you to take well informed decisions. And I think that’s the thing that we need. And luckily with scorecards that is a good thing.

And Google has a project called deps.dev. I’m going to drop another link, but deps.dev is a website that collects a lot of those things as well from different ecosystems, including scorecards. And it will also correlate it back to the NuGet ecosystem. And now it gets cool.

And Scorecard also is allowing you to say, "hey, I want to have the scorecard that comes with the NuGet package that’s known as Newtonsoft.Json." You can do that based on the CLI, and it will then run locally. And of course the data needs to query GitHub. And if you have the tool locally, it will need a token to access GitHub and to get all the stuff from the repo if it’s based on GitHub. And then it will do the calculations and it will give you the outcome of it.

Funny fact is that deps.dev will do it for a lot of products already, and the data is just there and they have a pretty strong API where you can just grab the information from, which is a nice JSON document, which just contains the nutrition label of a piece of software which also changes over time. That’s good, right? There are a couple of checks that they do which might have got a different view on it or projects will improve hopefully. That’s hopefully the outcome of it as well because can imagine that you want to do the best thing as well. Always keep good intentions. But I think this is definitely a good thing. To have the ability to look from the outside to a NuGet package and say, "hey, they do some really bad stuff on when they build their things. I’m not sure if this is a risk I’m willing to take or do we want to rely on this or do we need to take additional countermeasures ourselves?" Right. It gives you the information and I think that’s cool.

Jamie : Yeah, I’ve just been playing around with deps.dev whilst you were talking about it and threw one of my open source packages at it just to see the information it gives and it’s pretty good. The open source package I chose was a bad one because it only depends on .NET, so its dependencies are clear.

Niels : Yeah, but the other thing it also shows and Tanis is not a metric: let’s say contributors, code reviews. And code reviews might be a bit of an abstract thing you can look at, but contributors, the amount of people from different organizations that touch this package, which is a good thing, you can say, "hey, I don’t want it to rely on that single person," as the example I gave about the cartoon earlier, that’s a different thing. "But I also don’t want 1,100 people touching your code of that package. Because although I trust people in the same way as you’re doing, there always needs to be a single person that does a bad thing." Right? And that’s the flip side. But those metrics will all be show and I think you can take better decisions and I think that’s the key as well.

Jamie : Yeah, I just really quickly took a look at Newtonsoft.Json as you’d mentioned it earlier on, and it has a score of 3/10 at the moment on Jan 16th, 1155 UK time.

Niels : Yeah, and I talked about this one last week as well and it has 3.2/3.0 and it fluctuates because they still do stuff on the codebase as well, and it’s a moving target. Nut it will give you a sense, right, of the things.

And keep in mind that, not to bash OWASP and the top ten at all because I’m a big fan of OWASP, but people always tell me like, "yeah, I’m OWASP compliant," and that’s the biggest BS, to be honest. Because a top ten could not like, it should be an awareness piece and you should work from it. And there are better ways of dealing with that. But I think a security scorecard should never be a goal. It should be a means to reach the goal, to have better understanding, right? And hopefully they can change stuff and be more expressive.

So what I’ve done, so looking into that data and working with it when I was creating the things, and I also run a tool which is Fennec, and I think we might have touched it the last episode as well when I used it for dumping APIs that are used inside a library, which to a degree is a thing that I think we should still do. Because what would a library that does a document generation, why does it need to have heavy crypto involved? Like crypto liabilities, right? Why is that there? Why? For what reason? That should maybe be a judgment call for you to take.

But I decided like, "hey, I’m going to promote it to become a CLI," and I call it the fennec CLI. And I have taken the deps.dev APIs. And right now the tool that I’m close on releasing allows you to go into a solution file or a project file within a .NET project, and you can say, fennec CLIgive me the scorecards of all of this,fennec CLI and it will produce the files for you and it will put them in a specific location, like a desired location where you want those files to be. And that will be the first step in order for you to grab that data and have it available for the same way that we produced the SBoMs earlier. Right.

You have the data you can work your way through and then I think, https://mijailovic.net/2023/07/23/sharpfuzz-anniversaryokay, if you see this, what will be good additions on the scorecard, aside from the fact that there are certain checks which are not really made for the net ecosystem." So there might be improvements done on scorecard in general as a project to have better coverage for NuGet and .NET in general.

But what are the things that we can improve on? One thing is there is a bit of fuzzing also done in OpenSSF, but those are fuzzing libraries that have no relation to .NET. And people always questions like, "why should you have managed libraries being fuzzed,?" Right? So fuzzing for the people who are not aware of it is just throwing an amount of unvalidated, like invalid data to your component or to your application and see how it behaves. And in [the] security world, it’s normally used to do a lot of C/C++ mingling in order to find those buffer overflows that will result in code execution. Right? If to throw in a couple of more things, but for managed code it should be less of a risk. But there are still logical paths that you might be interested in.

So there’s a project called sharpfuzz that has been created five years ago by a person, I’m not sure where he or she is located, but it’s pretty cool. It uses a library, but it will do a coverage based testing on .NET components and there’s a sweet spot.

So you can take a library and put it on a bench on, an app that will give it the right context, and then you can have some of its inputs being squeezed by some of the better fuzzing frameworks like AFL or libfuzzer. And then found some cool stuff and find some real cool stuff, or at least improve the things.

And there’s a blog post done by the creator of sharpfuzz last summer where they look into what has been found, and some of them are logical bugs that are resulting in a library not behaving in the right way. But a couple of stuff was found in .NET in general, in ASP .NET Core I believe as well, which had to do with security issues, right? So that’s cool. So we can improve a way that we look into it.

But fuzzing in general is hard and it’s the same with static analysis. That’s one other thing that they do with scorecards as well. They look into if you use, I think it’s CodeQL and SonarCube, not very good yet, but they will look into those static analysis bits. And I think like yeah, looking at a component, I have strong opinions about how you should look at it from static analysis perspective. "I can see that you use md5 inside a component. That’s a bad thing." But I would be really interested in seeing it used in the right context. By looking into how data behaves and data flows are connecting, you use a library or a framework and it will facilitate a lot more.

You cannot just throw that library or that framework against a static analyzer or a fuzzer and have reasonable results out of it. You need to have more context. And that’s still a bit of disconnect where I see room for improvements, which I’ve been working on as well. Like, "hey, how could we define it?" And there are some good projects as well, also within the Rust ecosystem, but they do some good things, right? And we as NET community should look into those projects and say like, "hey, can we do the same?"

So that’s the thing I find really interesting that I would love to see as an extension for that nutrition label for NuGet. And on top of that, I think we also mentioned it the last episode. It has to do with reproducibility of builds. And I think we can talk about this as well. Like how can you have the guarantee that the library that you’re using has used the same source code to be built out of, right. There’s a link to probably which commit was used in the package. I believe you can tuck it in as well. But then there’s no guarantee.

Even if you do a small console app on your machine, if you then rename that folder, you put a tool behind it and then you just do the same .NET CLI call of dontet new again with the same name, and you build those two folders, those control apps will be different from binary perspective, bitwise; there will be a difference in it looking into the IL, they will be the same. Right.

So the other thing I was looking into for my Fennec Cli is doing IL comparison for that reason and being able to do a reproducible build by saying, "hey, this is Newtonsoft.Json I grabbed from GitHub, and this is the branch, this is the version that I’m on. And I would love to compare this one to the published version of 13.0.3 or four." I’m not sure which one it’s at right now. And then it should show you what the differences are. If there are any difference. Maybe it’s not notable or maybe it’s like some small bits and pieces. But that gives you the guarantee, right, that this is the source that’s inside and there’s no malicious things done during build, right.

Because we have seen that as well with SolarWind still remains the biggest example of their product being compromised at build stages, right? It’s hard. They even had a package that was signed. That’s the example I always throw in. So for the outside world, it would just look as their legit package that was released, their software was released in the right way, but inside there was stuff that was not supposed to be there, and that’s a big of a problem.

So hopefully we can also have some good practices done for scorecards or even additional information available that will allow you to see that and say like, "hey, we checked the reproducibility of this package on this version and it’s a good mark, right?" I think that’s the thing that I would love to go to, having an additional data source that everybody could just query say like, "hey, this project, yes, reproducibility can be signed off. We have the guarantee that this is the same." So that’s the thing that I would love to see added to that.

And the other thing when I was looking to improvements would be collectively reviewing security of MuGet packages. So I’m a security reviewer and I do this on a daily basis and it would be nice if you’re able to say, "hey, are these packages all reviewed?" And now I’m going to mention Rust and Cargo again because Cargo has a project called Vet and they do exactly that. The have people from I think Mozilla, Cloudflare and some others Fastly and they do collective reviews of packages and they will share that data with all that want to have it; which I would trust a package more if it’s being reviewed by two people that have really looked into it and there’s still a certain trust in it. Right, I get that. But that’s better, right? It’s almost an analog to what you just mentioned about Microsoft should not be worried about my versions. Right. I should be doing it myself. And I think this is the same. If you have an additional source of information saying like, "hey, this package looks good, or this package, they do some flaky things over here, we should look into it more detailed." Right? That’s the power of community and we should leverage it in order to secure the components that we all rely on. I think that’s almost like, sounds like a utopia, but I would love us to head there. Right. That’s cool.

And I think the scorecard project could definitely be the starting point of all of this. As you noticed, I’ve got loads of ideas, but there’s always less time on your hands. I think that’s the biggest call. And I love my work, don’t get me wrong, but I also have a family and kids that might want to see me now and then. That’s the thing. But there’s so much momentum we can grab and that’s definitely a better spot to be in compared to when we talked about it before. Right?

Jamie : Yeah. All of the points you’ve raised are fantastic, but you’ve raised a few thoughts in my head along the lines of, obviously this all gives you the information so that you can turn to the decision maker and say, "look, this is the problem, these are the possible solutions. I can estimate how long it will take to get around that," rather than going, "boss, we’ve got a problem." Right. Like when the log4jissue happened, it felt like the way it was initially reported was, "boss, we’ve got a problem." Not, "it will take us 2 hours, 3 hours to upgrade and rerun our tests and publish a release." It was, "the sky is falling!"

And I feel like there’s possibly three different states in software development. There is, "everything’s going really well," "we don’t know what’s happening," and "the sky is falling!" And I feel like there should be a continuum between those three. It shouldn’t just be three particular states. Because then, in my opinion, you would then end up with fewer big enterprises complaining to the open source developers, "you need to fix my stuff immediately!" Whereas actually it’s not the open source developer who needs to fix it. The fix is already there and has been there for several years. You’ve just not given your developers chance to actually put it in place.

Niels : No, exactly. I think with the whole log4j, it was literally at some point, I think during that timeline it was even running on places where people were not expecting it to be running. I think even there were cars known to have a version that was in it. Right. Which I think like, "okay, this just gives you the shivers." But yeah, exactly.

And given the ability to catch up with technical depth and fixing the things, it’s much more powerful if you can go back and say, "hey, I know this is the problem, I know it’s being run in this app. So even if you have good build materials or some good administration on where stuff is running, and it will probably take us x amount of time per thing to fix it and then we’re good. Or we can wait for this one on the next cycle when we’re going to release because the risk is limited and this machine will be behind some other thing that it cannot reach out. So it will be useless if people get to that, right? Aside from maybe data storm and that kind of thing." But you can deliberately make better decisions and prioritize, I think that’s the thing. Instead of like, "hey, we have an issue." "What is it running?" "I have no clue."

That will be my worst writing nightmare for.

Jamie : I think, I don’t think you said this directly, but you’ve raised the point that’s made me sort of pause and think like I’m going to pick Newtonsoft.Json just because it’s a large, well known .NET package, right?

If you’re using a static analysis tool or some kind of standard dependency system, it may flag up, "version 13." I’ll say version 13, we picked on that one earlier on. "Version 13 has this issue. However, like you said, you need to see it in context, right? It has this issue with this API that you are never calling, right?" So in the current way that the code is written, that shouldn’t be a problem, right? Because if you’re not calling that API, maybe that’s not a problem, right? And the, if you take that one step further and think about how we now have ahead of time compilation ,and tree shaking, and things like that. Yes, version 13 of Newtonsoft may have this issue. It doesn’t. I’m just making it up listener. But if version 13 has this issue with an API you’re never calling and you do tree shaking, it will never be there in the compiled binary. So that’s why I think you’re right.

You need to see these issues in context, because without the context you don’t know what’s going on with it, right? You don’t know whether it’s a valuable actual metric to worry about. You don’t get this report that says, "all of your dependencies are insecure and then you say the sky is falling and tell all your developers you’ve got 3 minutes to fix it all." And then they say, "well actually boss, none of those things are relevant because we’re not doing those things," right.

Niels : There’s a real cool project that also was created because of this. So if you look at like for the people listening, if a security problem gets published and they also talk about a CVE, which will be like a unique identifier that everybody in the industry could tie stuff to and say like, "hey, cve 2024," and then a number will be tied to one that’s found like in this year.

But even with .NET in general, we have .NET and since .NET Core we can literally run everywhere, right? And for example, we might have got a package that will be vulnerable to something if it only runs on Windows and not if it runs on Linux. And for that matter that CVE might not be applicable. And the cool thing is that there is a project called OpenVas which exactly tries to capture that, and that will take security people that can publish OPenVas data to everybody who wants to see it - I believe that’s the concept. And I need to work more in this because I find it really intriguing. But then you can exactly say, "okay, but if you run on Windows this is not an issue," and then you don’t need to update. Or if you run on Linux it’s not an issue because it’s only applicable on Windows and that gives the right information to the right people and it will make it less of a pain. Instead of people screaming, you need to fix it right now because, yeah. And you need to stop everything that you’re doing, and you might have been in the middle of a refactoring of a whole bunch of other things that are more important to the business. Right. And I think that should be there. So that’s cool.

OpenVas, if people are interested in knowing more about, like," hey, I’ve got this security problem and I want to have better control over it," then OpenVas should be the right answer to look into additional information to have.

Jamie : Nice, because that’s it, right? Knowledge is power. So we need to know these things because otherwise we’ve gone all the way [and] we circle back around to, "yeah, I have the sSBoM. Now what?" Right. And feed it into all of these apps and produce a report. Right. Because then you can then make that decision. That’s where that comes from. Right. You need the information before you can make the decision. And you can’t make the decision until… you don’t know whether you need to make the decision until you have the information. Right.

Niels : Yeah, exactly.

Jamie : Cool.

Yeah. Okay, so we’ve talked about NuGet, we’ve talked about running our apps essentially on different operating systems, and I realize we’re running low on time, but what about Webassembly? Because Webassembly is this new thing and everyone’s got, "wow, push everything to the web in this contained sandbox, this runtime that can’t reach outside of the browser, because then everything’s secure and it’s running natively." And I’m like, "you want me to run native code that I can’t debug, that I can’t read inside the browser? The one place where everyone lives, where all of my cookies live, where all of my JWTs live, where all of my cache lives, all of that stuff."

Niels : Yeah.

So I’ve been talking about Webassembly as well. And I totally love the way that’s being built up and how it works as a stack based virtual machine, and it’s just an instruction set that runs inside the browser. And as you said, it will have the goal of running a native inside your browser.

There’s a way that it works: a module will have a contiguous chunk of memory it can only work inside of. That’s cool. And there is a thing called control flow integrity enforced, which means that even if people are able to mingle with certain modules, then control flow integrity will contain a map of possible things that will happen next, and it will stop executing, which is like a mitigation layer for bad stuff happening. And Webassembly has been, from [a] language security perspective, as good as there’s a real cool project called RLBox which is used by Firefox inside the browser. And what they have done is they have taken some of their C plugins that they use for font rendering and media rendering, and then people who have known from the early days when we have browsers, then all the security problems mostly were with plugins that render media or fonts that were being rendered and then resulted into buffer overflows because some really smart person has used a fuzzer to figure it all out. Those things are being converted into Webassembly or compiled into Webassembly. So they take a SQL base and they use a tool called Emscripten. And for the .NET folks, that’s exactly how we run Blazer inside the Webassembly. It’s all based on Emscripten. It will then be compiled into Webassembly modules that can be executed.

But the nice thing is that you can get all those security things I just mentioned, like memory can only be used by the module itself, its own memory. It cannot access any other module’s memory unless there is some involvement done. And the control flow integrity, those are really good security measures. The compiled their C to Webassembly so the plugins are safe from those security problems I just mentioned. And then they take that Webassembly and compile it back into C because they want to have a good code base that will still be only C/C++ and not any Webassembly or like modules because that’s maybe harder to maintain. But they use the language security features of Webassembly as a strong perimeter to run those plugins in safer manner. And everybody who’s running Firefox nowadays relies on that piece of thing. And that proves that Webassembly as a technology is good.

The things that I also talk about is taking Webassembly outside of the browser and having it on a runtime on your system, because that will be the next thing that they’ve introduced. And for cloud native workflows, it makes sense because a Webassembly module can almost be seen as a docker container, but much smaller. And even with Project Hyperlite that Microsoft talked about at Build [2023] - you can look up the video where Mark Russinovich shows Hyperlite, which is a hypervisor that runs Webassembly modules on cloud compute, but it’s secure. It will leverage Webassembly security features. And they even put a hypervisor underneath that, that will even make it more secure. And then you get up with the whole confidential computing story that Mark Russinovich has been talking about over the last year, and that gets really cool. And I think Webassembly is one of the building blocks for that thing.

Still, having a Webassembly module on your system on a runtime, it will be as secure as the runtime is implemented. And the Bytecode Alliance, that’s a big collaborative group between Microsoft, and Mozilla, and Fastly, and Cloudflare, a lot of big companies are in it. They work on a runtime called Wasmtime, which is highly scrutinized for security reasons. They have a real good security process. There are some good talks on where the security person explains what they do for security. That includes fuzzing, that includes good testing, that includes a lot of good things. Threat modelling, it’s all there. And that makes it nice.

So from that perspective, it’s totally different of running Webassembly inside your browser, right, which will still have the limitations of same origin. And if you want to reach out to other things, you still need to do the same as if you would with any, let’s say, single page app that runs on Javascript inside your browser. But as I said, from language security perspective and how it internally works, there’s a lot of goodness in it and cloud native and all the stuff. I can definitely see Webassembly becoming even bigger over the next decade or so. We’re going to see a lot of it. So that’s my take on it in general.

Jamie : As I say, I realize we’re really low on time at the moment, but what are some of the things that we need to be concerned about? Like say I’m building some .NET app and the marketing team have said, "we should build it with Webassembly and running on Hyperlite because the marketing team have decided that we can win loads of work if we say it’s Hyperlite, and we put the badge on the website, and we can win this work,"" what do I need to worry about? If it’s constrained within a smaller environment and we can’t reach out of our memory constraints and things like that, then there are no security issues?

Niels : It’s just a matter of time. Jamie, that’s the dead answer almost; like you’re going to bump your head at some point in the future.

If you have the bigger players again. And that maybe it works the opposite way even with Fastly is doing a lot as well on that space. They’re a big contributor on the Bytecode Alliance because Webassembly allows them to run compute on the edge, close to the data, and they’re all about distributing data across the Internet. Right. Same for Cloudflare. So that totally makes sense. So I would put a lot of trust in them taking the right decisions in a bigger story.

Will it be completely unhackable? Probably not. I think the funniest thing I saw with Webassembly two years ago when I was doing some security conferences is like most of the research did, focus on the runtimes failing and finding bugs in that, which is good because that will [heighten] the bar in that area and will make it secure for sure. But any big things happening? As far as I see right now, there is a thing called component model, which should help us out [with] composing apps that are Webassembly modules. But the we end up in layer seven space where people need to develop things.

And when we started out this conversation, we already talked about secure defaults. Right. And it still ends up for the person that writes software in such a way that we should give guidance. But as I said, Webassembly itself should be Secure. Will it be free [of issues]? No, not. But we should make sure that we do the right thing and with all the information we have right now. I think that’s my take on it.

Jamie : Right? Yeah. Okay. So if we own a mansion and it is surrounded by a fence, and the fence is 400ft high, and the gates have all these super duper amazing sensors on them, we still want to lock the door when we leave the mansion before we get to the gate. Right. Because what if someone manages to vault over the wall? Like, if it’s a 400ft wall, I just need a 401ft tall ladder, right? Yeah. And I can still get in.

Niels : This is something nice. You talked about this example, and I don’t want to plug Netflix, but there is a documentary on CyberBunker, and people should watch that because at the end, and I’m not going to give a spoiler, but there’s exactly similar stories. Like, it has to do with doing bad stuff inside a cyberbunker that was used for hosting dark web stuff. And at the end, they need to get into the bunker and everybody should watch it. It’s such a nice story. I watched it. I think it’s like an hour long. It was published in December, and it’s about the cyberbunker on Netflix. Everybody should watch it. It’s a nice documentary. And at the end there is a real good example of exactly just the thing you mentioned. Funny thing, right?

Jamie : Interesting.

But yeah, taking that, metaphorizing it and applying it to our code. We still want to build secure code by default, even though the constraints that we’re working in make it secure. We still want to have that secure… we still want to lock the door. Right. Because that’s a security best practice. We still want to put the steering wheel lock on our car because it’s a security best practice. Even though we may not "need" to do it, it still is a good practice to do. I like that.

Okay, cool. So I guess just before we sign off then, other interesting things that you’ve seen in the Webassembly area coming down the pipe, because I know that people will be interested in checking out Hyperlite. And if you haven’t seen it, folks, there will be a link in the show notes to the talk given by Mark Russinovich at MS Build [2023].

But from my perspective, Webassembly delivers on that one promise we’ve had from all of the framework vendors of run it everywhere. Right. We’re finally getting there.

Niels : Yes, I guess so. I think we finally get there in a good way. It’s driven from a way that it’s also top down, which I think will give it a higher success factor than compared to a technology stack that’s already there.

And I believe that is the thing. If people want to see more cool stuff on Webassembly and have more general concepts, ideas about how it internally works, and some of the security things, as I just mentioned, people should look into a conference called WasmCon, which was held last year in September in Seattle, and it’s on YouTube, and you find some really good. There’s also the developer of Hyperlite explaining the need for Hyperlite and what’s inside. And there’s another one, I think his name is Brian, who is doing the security for wasmtime and exactly explaining, "these are the things that make it secure," in order to gain trust on why I think the right ones run everywhere might be succeeding and heading into the right direction.

Jamie : Right. Okay, cool.

That’s interesting stuff. It really is, because I can envision a period of time, and I suppose I’m looking across my desktop at my Nintendo Switch, and I just had this thought of like, I will at some point in the future, perhaps be able to build something, write something in one language, and run it where it shouldn’t be able to run, like on a video games console. It changes everything. Nice. Okay, cool. Yeah. All right.

So what about getting in touch with you then, if folks are listening along. Are you on Twitter/X? I know you are. I’m just giving you a chance to tell everyone.

Niels : It has been a pretty stale since last November, or maybe even longer. So Mastodon is a thing. You can drop me a message on Mastodon, and go to fennec.dev. You will find my website and all my other contact details. If people want to reach out to me, I think that’s the best way right now.

And there’s also fennec.dev will have the tools that I mentioned. fennec.dev will now point you to the GitHub repo where the original version is. And as soon as I’m publishing stuff, there will be more there and I hope to write up some blog posts, which is like, "new year; you have gotten new ideas and you want to make sure that you succeed." So, yeah, people should keep an eye out on my blog, hopefully, and I can tell them more about the tooling that I mentioned during this talk.

Jamie : Nice. Okay, well, I’ve been collecting links whilst we’ve been chatting anyway, but I’ll put the links to everything that we talked about in the show notes.

But, yeah, I just want to say, Niels, thank you again for being on the show. Security is one of those things that I feel like I’m doing things vaguely well, and then I learn a little bit more about how the industry works, and I’m like, "okay, I’m not doing anything even remotely well, but at least I’m doing it a little bit better than most people."

Niels : And that’s the first step. Right. And that makes sure everybody improves on that.

Jamie : Sure. Excellent. Well, like I said, Niels, thank you very much for being on the show. And let’s look forward to maybe your third appearance when you’ve got more security things to scare us with. Right.

Niels : I’m confident. Yeah, I would love to come back in the future sometimes. And thanks for having me, Jamie, and see you around.

Jamie : Definitely. Yeah, definitely. All right, cool. See you later.

Wrapping Up

Thank you for listening to this episode of The Modern .NET Show with me, Jamie Taylor. I’d like to thank this episode’s guest, Niels Tanis, for graciously sharing his time, expertise, and knowledge.

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 the podcast's website, 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/review for ways to do that - reach out via our contact page, or join out discord server at dotnetcore.show/discord - all of which are linked in the show notes.

But above all, I hope you have a fantastic rest of your day, and I hope that I’ll see you again, next time for more .NET 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