Mark private Nuget/Npm Packages as Vulnerable?

tayl7973_1825

Is it possible to mark private Nuget/Npm packages as vulnerable through ProGet?
I see I can mark the packages as deprecated and leave a note but I was wondering is it possible go further and actually more it as vulnerable along with the severity and have that showing up in dotnet restore -vulnerable commands along with npm -audit commands.

The use case being if we have some logically issue that is causing the package to be vulnerable we would like to be able to mark it as such and have that be able to be communicated to our users. The deprecation feature accomplishes some of that but we also have custom reporting on our side where we would like to be able to identify the severity of vulnerability through out our repos.

stevedennis

Hi @tayl7973_1825 ,

This is not possible nor is it a workflow we'd recommend to support. Vulnerabilities have a very specific meaning / use case -- third-party discoveries in open-source packages that may impact your code (but probably won't) -- and it's not a good idea to "abuse" them for other purposes.

Deprecated is one solution, but a better would be to use SCA and monitor how that package is being used, so you can understand impact on library consumers:
https://docs.inedo.com/docs/proget/sca/builds

Thanks,
Steve

tayl7973_1825

This post is deleted!

tayl7973_1825

@stevedennis Thank you for the quick reply.

Yeah the use case mainly comes from some of our other security tools identifying code patterns that represent security issues. In this case sonar cloud see's one of our custom libraries has logic that is not secure. We wouldn't particularly need it for open source libraries.

SCA would work for seeing the breakout like you said but it would require us marking the package vulnerable in some outside source and mapping it back to perform the analysis.

Would you still not see the potential value in marking private packages as vulnerable or is that just not possible given the way nuget is setup?

I can imagine the dotnet restore -vulnerable not working if it can only be tied to some registry of vulnerabilities that can't be changed.

stevedennis

Hi @tayl7973_1825 ,

Thanks for clarifying it. Based on that, I would say that "Vulnerabilities" are most definitely the wrong tool for the job. You can certainly "hammer in a screw" but there's a better way to do it - and we don't make "screw hammers" at Inedo

We're working on best practices / guidance on how to build security policies around these topics, but I'll try to give some tips now.

What you're describing isn't a vulnerability per se, but a SAST Issue: a potential weakness in code detected by a static analysis security tool. Most of these are false positives and present no real security risks, but some are.

If you discover a SAST Issue in one of your libraries, then you should use the following process:

Evaluate if it's a false positive or not
Unpublish the library internally if there's a security risk
Enumerate the consumers (i.e. applications in flight or deployed to production)
Evaluate the security risk (low, high), based on the consumers/usage
Notify the application teams to upgrade the library as appropriate

Note how this process is fundamentally different than OSS packages / vulnerability workflows:

you can unpublish/block packages from your repository
you know which applications are consuming your packages
you know which teams maintain which applications
you can work with those teams to assess the risks

Bottom line: if a package causes a real security risk, then unpublish it and fix the consuming applications as appropriate. Otherwise, don't.

There's really no middle ground or room in this process for "Vulnerabilities" - and trying to curate an internal "vulnerability database" is just going to make things less secure in your organization.

That's a theme in our upcoming content, but the general idea is when you treat all issues/vulnerabilities as security risks, then it's impossible to focus on the ones that are actual risks -- and it's as meaningless as saying "everything is a top priority".

Thanks,
Steve

tayl7973_1825

@stevedennis Thanks, Steve. I hear where you are coming from.

I suppose what we’re really looking for is something that eases the communication and tracking of security issues (whether low or high severity) across our teams. Right now, based on your suggestion, it sounds like the workflow would require us to manually identify which applications depend on a vulnerable library, notify each owning team, hope it fits within their priorities, and then track remediation through individual tickets.

Ideally, we were hoping our package management system — since it already governs distribution and security controls — could act as that “one stop shop” to track and visualize which applications still rely on a vulnerable version along side it's assigned severity rating. That kind of visibility would make coordination much more efficient in my opinion.

It sounds like that’s not something ProGet currently supports directly, but I appreciate the clarification if I'm wrong there as we are currently looking for something that would help that form of tracking.

And I'd like to once again thank you for all your responses today and if I don't hear from you again. I hope you have a great weekend.

stevedennis

Hi @tayl7973_1825 ,

Thanks for the feedback; this is all a relatively new space, so we're in the process of building best practices / advice as well as tools to help teams solve these problems.

Right now, based on your suggestion, it sounds like the workflow would require us to manually identify which applications depend on a vulnerable library, notify each owning team

You are correct - the SCA Builds & Projects functionality is designed to "provide that link" between specific package versions and specific builds of applications. The builds are a moving target, as they may or may not be active/deployed.

The "Project" in ProGet is not intended to the "source of truth" about the project itself, but be sort of sync'd with the truth (e.g. like an Application in BuildMaster). That's why there's a "stages timeline" for builds in PRoGet.

hope it fits within their priorities, and then track remediation through individual tickets.

Our advice here is to think of it more like, "advise them of the identified security risk and unavailability of the impacted library they are using". Ultimately it should be up to the team (their product owner) to evaluate the risk you identified and mitigate it. For example, TeamLunchDecider1000 can probably live with a security risk, but let the team decide.

Once you've removed the library from ProGet, they can't use it anymore and it's "no longer your problem" to worry about or track through tickets.

Ideally, we were hoping our package management system — since it already governs distribution and security controls — could act as that “one stop shop” to track and visualize which applications still rely on a vulnerable version along side it's assigned severity rating.

ProGet already provides visibility into consumers through SCA, and you can already see how OSS Vulnerabilities impact builds.

HOWEVER, our core advice here is to not try to establish your own in-house "vulnerability database" for in-house libraries your organization. Even large orgs (2000+ developers) won't do that.

Instead, it's a simple binary decision: PULL or KEEP the library. If you PULL, then notify consumers it's unavailable going forward and let them decide how to mitigate.

That approach is superior to OSS Vulnerability workflows, but it's obviously not possible for OSS library authors to do.

Cheers,
Steve