|
|
|
|
|
|
by xemdetia
2658 days ago
|
|
|
I'm trying to understand your point. I agree with the basic premise that most pieces of code that end up not getting exposed are not sensitive, but building guardrails to ensure people who aren't security minded ask the right questions and get closer to 'default correct' ends up being a requirement in major banks/government organizations. The number of times someone has done something completely silly like include API keys in a public package or Git repo is reason enough to care. Being beholden on an external system being secure and up to standard ruins pretty much every category of a risk analysis, especially when you end up with gold like this article or the PHP PEAR hack. Then there is always that part of the organization that isn't judicious about keeping packages up to date, and these kinds of package exposures expose their negligence. Then there is the other piece of my systems being dependent on your systems in a sometimes inappropriate matter if precautions aren't taken. 'Oh I just added this dependency' is a quick way to an outage if rules aren't set. |
|
|
Agreed, but that is not a publication problem. That is a separation of concerns violation which indicates a host of other problems from the lack of code review to incomplete security testing to various ad hoc or integrity violations.
External systems have no bearing on the validity and completeness of your organizations internal security controls. It doesn't matter how incomplete, insecure, or unqualified NPM is to serve a given set of code. The problem isn't NPM or the publication to NPM. The problem is the contents that comprise the publication in question. A good security audit would ask why any certain content is available for publication in violation of internal policy regardless of what that content is.
For example if you accidentally publish to NPM code containing a bunch of user PII the problem is why PII was resident in the code in the first prior to publication. The fact that such PII is exposed is now a different second problem demanding a different resolution. You could make the argument that halting and regulating all publications would solve that problem. That is incorrect, because the PII is still exposed within your organization outside of a controlled environment and can still be leaked to the public by various other means.
> Then there is always that part of the organization that isn't judicious about keeping packages up to date, and these kinds of package exposures expose their negligence.
That is dependency management whether or not you own the packages in question. Dependencies need to be appropriately managed for a variety of security reasons. Exposing poor dependency management advertises a vulnerability, but the vulnerability is there anyways and a dedicated malicious attacker will exploit it the same either way.
---
The bottom line is that hiding your security problems by "not publishing" is not a valid security control. That is the dreaded security by obfuscation and it works both ways. By hiding the vulnerability you also hide the exploitation from visibility.