Welcome to the Inedo Forums! Check out the Forums Guide for help getting started.
If you are experiencing any issues with the forum software, please visit the Contact Form on our website and let us know!
License blocking vs Vulnerability blocking behaviour
-
I'm trying to get my head around the behaviour of License blocking vs Vulnerability blocking.
The example setup:
A primary feed connected to NuGet.org (eg public/external). A secondary feed (eg private/internal) connected to the primary feed.
NuGet.org --connector-> primary --connector-> secondary, as simple as that.Some license types are blocked by global rules and vulnerability scanning is activated using OSSIndex on the primary feed.
Behaviour:
A package with a blocked license type can't be downloaded (nor promoted), neither from the primary feed nor the secondary. Blocking is applied globally.But a package with a blocked vulnerability is only blocked from download in the primary feed, the vulnerability is not even visible in the secondary feed, and it's possible to download from there (and promote from both feeds).
Since vulnerabilities most probably show up after you already have downloaded and used packages this behaviour forces you to go through every connected feed or feeds where you maybe have promoted a package, and handle them individually. With a lot of feeds that makes it risky and a lot of work.
Is this intended? Wouldn't it be better to have vulnerabilities work globally like license rules?
Or maybe I have missunderstood something...
-
Good question; it sounds like you're creating a Package approval workflow, and are on the right track to thinking about "package governance".
Your observations about licenses and vulnerabilities are correct, and you could simply apply the same vulnerability source to each feed, if you want to use that feature. But i generally suggest putting it in the
approved-packagesfeed (using our workflow above).A couple important things to note.
All packages have a license (even "no license" is a license), and a package with an unacceptable license (i.e. one you explicitly block) is always unacceptable. There are really no exceptions to this (maybe the CEO or legal officer someone could override this rule?), and if someone accidently uses an unacceptable license, it presents an immediate legal risk that you should remediate.
Very few packages have vulnerabilities, and those that do are usually acceptable to use. Most vulnerabilities won't impact your application, and those that do are usually easy to work-around aren't severe enough to warrant action. Severe vulnerabilities (i.e. where remediation is needed, like log4shell) will likely come up once or twice a year for you... if that.
When a severe vulnerability is discovered (i.e. one that you wish to block), tracking across feeds isn't really that big of a problem, compared to discovering which applications consumed that package. What I would recommend is investing in configuring package consumers (see section #2 of the article).
Cheers,
Steve
-
Hi @stevedennis,
Yes, we are aiming to implement a package approval workflow combined with vulnerability scanning.
Our problem is that for security reasons we are not allowed to expose our internal packages for scanning, hence the primary/public/external feed where scanning occurs separated from the connected secondary/private/internal feeds.Apparently I have totally missed the Package Consumers functionality, seems to be just the right thing to help tracking vulnerabilities across multiple feeds and applications.
As I understand it though, to get full coverage the pgscan tool needs to be installed on every build server, and thepgscan publish...command needs to be implemented in every build? That will take som effort to maintain, to be weighed in comparison to chasing vulnerable packages manually. I will bring up the subject with our developers.Thanks for clarifying!
Regards
/Claes
-
Great! Our recommend three-feed workflow (unapproved, approved, internal) is similar, and keeps the third-party packages in the first two feeds. This way, you can scan for vulnerabilities much more easily.
As I understand it though, to get full coverage the pgscan tool needs to be installed on every build server, and the pgscan publish... command needs to be implemented in every build?
This is correct. Dependency resolution is complex and often nondeterministic, so it can only really happen at build-time. Hopefully you can templatize pretty easily :)
Cheers,
Steve
