lirantal
commented
3 years ago Hi @ewanharris Great to see the awareness for open source security, thanks for opening an issue to discuss this.
Given the nature of the issue being the client that install the packages, anything we do on lockfile-lint will actually be after-the-fact and wouldn't realistically prevent an individual from the vulnerability. Meaning that, even if there's a rule that says a specific package scope is restricted to a host, when the users run an npm install, the npm logic will actually try to hit upstream registry, regardless of the lockfile or any lockfile-lint rules. That's the situation as I understand it.
Is your feature request related to a problem? Please describe.
I was reading this article that discusses a supply chain attack by searching for internal packages within an organisation that don't exist in public npm and using them as a potential attack vector.
I wondered whether this is something lockfile-lint could provide a solution to (although perfectly understandable if it's out of scope), by allowing folks to tie packages or scopes to a specific host.
Describe the solution you'd like
I think this would work similar to the other validators, it would take some form of configuration that allows people to tie a package name or scope to a certain host. Although this would probably be less than ideal to expose as CLI options
I took a look into what it would take to expose just the scope configuration and came up with this , I think it wouldn't be too much effort to extend it to package names also if you're interested :)