#Hacktoberfest 2023 is coming up and #nugetdefense will be participating. A few bugs need squashed, docs need updated, and tests need added. Feel free to raise an issue for anything you'd want to work and I'll do what I can to assist with learning the codebase. Opportunities for PR to be submitted in #TypeScript #Markdown #csharp #ReactJS

I'm gearing up for an overhaul of the caching system, but anything is up for grabs. Refactoring (for performance or readability) are acceptable.

#NuGetDefense , the #opensource #dotnet #security tool has a new release (3.2.0.0-prerelease2). This is not production ready, but it utilizes the NVD API to generate and update the offline vuln data. Any help testing it would be appreciated.

The current releases should still work for those using the GitHub Security Advisories Database or the OSSIndex remote sources. This push is going to address the deprecation of the NVD JSON feeds.

Hoping to run it through my tests Monday night.

Last night I stumbled across system.threading.ratelimiting a nuget package with basic rate limiting functionality. I'm reworking the API clients in #NuGetDefense and this package allows me to setup explicit policies to take some of the burden off the API's I consume. Basically you can add a handler that returns 429 responses (TooManyRequests) from an http client without actually sending the request.

https://devblogs.microsoft.com/dotnet/announcing-rate-limiting-for-dotnet/

It's a .Net 7 package, but it's built for .Net Standard 2.0 as well.

Well, the National Vulnerability Database is apparently doing away with their legacy feeds, so I'm throwing together a #NVD 2.0 API client for #NuGetDefense that will be published as a #nuget package for #dotnet 6+. This explains the issues I was having getting it to update the NVD feed recently.

Found another bug in #NuGetDefense. Doesn't seem to affect the common use cases so far, but it's problematic for a new CI setup I'm using at work. As much as I Work with Unit Tests, one would think I'd have more tests for my own projects.

I've been thinking about ways to whitelist #nuget packages before allowing them to be installed (explicitly to prevent unauthorized build targets or PowerShell scripts. I'm considering building this sort of protection into #NuGetDefense ( #foss nuget security tool) but I need more insight into how the PowerShell scripts are triggered (ex. Old docs, blog posts, etc). Any insight, ideas, or opinions would be appreciated.

Found article about malicious #nuget packages in the wild. It seems to mainly concern malicious PowerShell init scripts that #visualstudio runs. Although #NuGetDefense has a blocklist for packages, when installed in a project, it checks them after the init script would have already run. I'm going to start running scans prior to letting it restore packages.

https://jfrog.com/blog/attackers-are-starting-to-target-net-developers-with-malicious-code-nuget-packages/

NOTE: I don't know if the #dotnet cli or #jetbrainsrider run those scripts. Hopefully I'll have an update tonight.

Was looking for a way to get a standard folder for some #NuGetDefense features that's cross-platform. Environment.GetFolderPath() is one I wasn't aware of. It provides an enum of special folders such as ApplicationData which maps to the functionally similar directories on Linux and Windows.

https://learn.microsoft.com/en-us/dotnet/api/system.environment.getfolderpath?view=net-8.0

#dotnet #crossplatformdev #linux #csharp

#NuGetDefense v3.0.10 has released! This is a minor bugfix release of the known vulnerability scanner for .Net packages. https://github.com/digitalcoyote/NuGetDefense