Niels Tanis
Sr. Principal Security Researcher at Veracode | Microsoft MVP | International Speaker
Amersfoort, The Netherlands
Actions
Niels Tanis has got a background in .NET development, pentesting and security consultancy. He is Microsoft MVP and has been involved in breaking, defending and building secure applications. He joined Veracode in 2015 and right now he works as a security researcher on a variant of languages and technologies related to Veracode’s Binary Static Analysis service. He is married, father of two and lives in a small village just outside Amersfoort, The Netherlands.
Awards
Area of Expertise
Topics
Reviewing NuGet Packages security easily using OpenSSF Scorecard
Several studies shown that round 80% of our applications consist of other people's code because why would you re-create something that's already made by someone else? But with using a NuGet Package that is developed by others, we also put a lot of trust in it, which might result in bigger security problems later. Of course, it's always a good idea to get updates of libraries in case of a bug fix related to a functional and/or security issue found. But will that be enough? What about packages that have malicious code inside? Even related to your own supply-chain security, any problem in the package its supply-chain implicitly means your supply-chain is compromised as well!
Would it not be nice if there is a better way to review NuGet packages for security? An easier way to perform an assessment based on certain aspects of the package that will tell you more about the package its software security. With the introduction of Scorecard project the Open Source Security Foundation (OpenSSF) exactly tries to achieve that. You could consider a Scorecard being the equivalent of a nutrition labels put on food you buy in a supermarket. It will allow you to see what's inside and determine if you want to eat it or not.
In this session we start out with different area's covered by of OpenSSF Scorecard, like how well it's maintained, does the build have dangerous workflows, and does the project use other security tools to check for problems? We're also going to identify additional area's for NuGet packages in which we could add additional information related to reproducibility, insights on what .NET APIs are used, and security review of the codebase. All combined will give us the ability to assess a NuGet package its security posture more easily and improve our own application security.
Using WebAssembly to run, extend, and secure your .NET application
WebAssembly (WASM) has come a long way since its first release in 2017. As a technology stack running inside the web browser, it even allows products like Adobe Photoshop to run in that context, and with Blazor WebAssembly .NET runs inside of the browser as well. Now, WASM is expanding beyond the browser to run in a server-based context. With the introduction of WebAssembly System Interface (WASI), the technology leverages a standardised API that allows it to run on any system that supports it, for example to support cloud-based workloads.
Had WASM and WASI been around in 2009, Docker would not have existed according to one of its founders, Solomon Hykes. WASM has a strong security posture given how it works with linear memory space and how it supports a sandboxed-based environment called “nano-process”, which uses a capabilities-based security model. Users can even take .NET and, with the help of WASI, run it on a Trusted Execution Environment (TEE) to add an additional layer of security.
In this session we'll start out with going through some of the basic security features of WASM and then move to running and extending an .NET application it with WASM module written in Rust. After that we'll focus on the security features and run .NET on a TEE and use the sandbox and the capabilities based security model to limit what it's allowed to do.
Securing your .NET application software supply-chain, the practical approach!
With our complete software development process becoming more complex we also got a lot more security problems to deal with. What starts with code and ends with releasing/deploying software is also being referred at as the software-supply chain. The software supply-chain consists of a lot of moving parts. Each of them facing their own security risks starting from access to source code, compromised third-party libraries and tools, or even hacked build servers. For example with SolarWinds the compromised build server added malicious functionality to the end product used by their customers. And the supply-chain of the 3CX voice-over-IP software was even compromised via a piece of software installed on one of it's developers machine.
In this session we'll get hands-on with securing a .NET application it's supply chain and look how we can limit the security risks in all the different area's. We're going to look into reproducible builds, signing artifacts, creating (and validating) provenance and software bill of materials (SBOM) with guidance of Google SLSA and the Secure Supply Chain Consumption Framework (S2C2F).
Sandboxing .NET assemblies for fun, profit and of course security!
In our current way of developing .NET applications we rely a lot on third-party libraries developed by others. This of course has a lot of benefits from productivity perspective because there is no need to write needed functionality from scratch.
But by using in a third-party library you also pull in it's issues and possibly security problems that are found over time. What does the library do? And what type of other libraries and/or functionality does it rely on? What do the projects/people behind it do for security?
If we develop a .NET application using external libraries can we improve our security posture? Other new technologies like WebAssembly introduced a concept of nano-process, which allows the developer to limit the capabilities available for an external module by creating a restricted sandbox for it. Could we maybe do the same in .NET? In the old days we could use AppDomains and Code-Access Security (CAS) to achieve that, but with the introduction .NET Core there only is a single AppDomain and CAS has been deprecated.
Luckily with .NET Core we did get more internals exposed on AssemblyLoadContext and in this session we're going to create a sandbox using that. A restricted sandbox that limits the functionality available that will improve the security posture of our application!
Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.
Jump to top