3 ms·

Would you go into some specifics to guide my web searching?

smackeyacky 3y ago
https://learn.microsoft.com/en-us/nuget/concepts/security-best-practices https://learn.microsoft.com/en-us/nuget/concepts/security-be... However, I've seen some definitely dodgy packages in NuGet. Since "bulk insert" isn't (wasn't?) widely supported in EntityFramework packages, there were some extremely dodgy copies of commercial bulk insert frameworks being made available, along which who knows what else. I find npm/node.js the scariest package manager combo though. Including something simple that then drags in 20 or 30 other packages is inexplicable.
- nerpderp82 3y ago
  That is a good list, many of these can also be applied to Rust because it has many of the same affordances in its build and supply chain ecosystem. I thought maybe there was module level capabilities in .net, I don't follow it at all but would be willing to take a look. I feel gross even using pip in python, because the thing you use as the noun in `pip install <noun>` isn't the same as the package you are importing. Name attacks in Python are trivial to exploit. JS is even crazier, your gonna get a disease! There is no safe JS.
  - smackeyacky 3y ago
    .NET does have signing capabilities for assemblies...but you have to trust who signed it. In theory that's a bit of extra protection, but in practice how do you know who signed it was trustworthy in the first place. I like .NET but I often feel it's safer than node.js by accident, because the range of packages you need to get something running is much smaller because the date/time classes are sane and things like networking and security are built in rather than imported. But there is no getting around the fact that you're still vulnerable to all the same supply chain attacks as Javascript.
    - neonsunset 3y ago
      What helps is companies would sometimes disallow access to external feeds like nuget.org and instead host internal feed with pre-approved packages and their versions. Luckily, the standard library is so extensive you rarely find yourself reaching for an external package for a piece of basic functionality, and companies often are extremely averse to taking on third-party dependencies to a point of unreasonable (you have to go through sec dept even for otherwise popular and actively maintained packages which really doesn't help as it leads to NIH proliferation, doing more damage than good). It is probably less prevalent in small size businesses however which has its advantages - the productivity loss and maintenance effort is highly likely outweighs whatever security benefits the above approach may bring, if any (good OSS package is usually more secure and does a better job than a particular team often unequipped with sufficient skills).

https://learn.microsoft.com/en-us/nuget/concepts/security-best-practices https://learn.microsoft.com/en-us/nuget/concepts/security-be... However, I've seen some definitely dodgy packages in NuGet. Since "bulk insert" isn't (wasn't?) widely supported in EntityFramework packages, there were some extremely dodgy copies of commercial bulk insert frameworks being made available, along which who knows what else. I find npm/node.js the scariest package manager combo though. Including something simple that then drags in 20 or 30 other packages is inexplicable.

nerpderp82 3y ago
That is a good list, many of these can also be applied to Rust because it has many of the same affordances in its build and supply chain ecosystem. I thought maybe there was module level capabilities in .net, I don't follow it at all but would be willing to take a look. I feel gross even using pip in python, because the thing you use as the noun in `pip install <noun>` isn't the same as the package you are importing. Name attacks in Python are trivial to exploit. JS is even crazier, your gonna get a disease! There is no safe JS.
- smackeyacky 3y ago
  .NET does have signing capabilities for assemblies...but you have to trust who signed it. In theory that's a bit of extra protection, but in practice how do you know who signed it was trustworthy in the first place. I like .NET but I often feel it's safer than node.js by accident, because the range of packages you need to get something running is much smaller because the date/time classes are sane and things like networking and security are built in rather than imported. But there is no getting around the fact that you're still vulnerable to all the same supply chain attacks as Javascript.
  - neonsunset 3y ago
    What helps is companies would sometimes disallow access to external feeds like nuget.org and instead host internal feed with pre-approved packages and their versions. Luckily, the standard library is so extensive you rarely find yourself reaching for an external package for a piece of basic functionality, and companies often are extremely averse to taking on third-party dependencies to a point of unreasonable (you have to go through sec dept even for otherwise popular and actively maintained packages which really doesn't help as it leads to NIH proliferation, doing more damage than good). It is probably less prevalent in small size businesses however which has its advantages - the productivity loss and maintenance effort is highly likely outweighs whatever security benefits the above approach may bring, if any (good OSS package is usually more secure and does a better job than a particular team often unequipped with sufficient skills).