We use cookies to deliver you the best experience on our website. By continuing to use our website, you consent to our cookie usage and revised Privacy Statement.

Filter By:



Recent Podcasts

Back to Insights

Shostack: Learning From npm's Rough Few Months

August 14, 2017 | AppDev Frameworks
By Adam Shostack, IANS Faculty

The node package manager (npm) is having a bad few months. Let’s look at what we can do, what other package managers should do and what we can learn at a policy level, particularly in the U.S. framing of “critical infrastructure.”

People in security who remain focused on the IT side of the house, rather than the development side, may not be familiar with npm. As its website says, "npm is the package manager for JavaScript and the world’s largest software registry. Discover packages of reusable code — and assemble them in powerful new ways." Odds are excellent that one or more of your websites rely on npm.

But back to npm’s bad few months. In June, security researcher ChALkeR explained how he "obtained direct publish access to 14% of npm packages (including popular ones). The estimated number of packages potentially reachable through dependency chains is 54%." Then, there was a typo-squatting attack that went undetected for two weeks. And just a few days ago, Ivan Akulov reported on malicious packages in npm.

Establishing Controls

So, does your organization have good controls across the applications in your portfolio and their dependencies? To borrow from the NIST CSF, you need identification, protection and detection (you probably also need response and recovery). This isn't about just npm; it's also about the Linux distro your web servers run on, your back end Ruby/Python/Java code and so on, because odds are excellent there's yet another package manager for each:

  • Identification (inventory): Anyone who's serving web pages of any complexity is using an awful lot of packaged code. Do you have a central inventory of that code, which you can use to check to see if you're using any of those typo-squatted packages? I choose my words carefully there: a “central inventory," not "central inventories." This is one of the advantages of the emerging “orchestration” market. Being able to interrogate inventory managers across an organization and at various levels of the stack may mean that you have a virtual central inventory that you can treat as one thing, while using the inventories that operational teams use.

  • Identification (threat intelligence): Did your threat intelligence feed tell you about any of this? Hahaha, no, really – did it? If not, did you expect it to? Should it?

  • Protection: Do you have tools to help you proactively find problems? From outdated versions to code analysis tools, you again need to walk up and down the stack. For example, Guy Podjarny is building tools to track known issues, and there are a few early static analysis tools.

  • Detection: What tools do you have that you think should have revealed issues like this? Did they work?

Threat Modeling

Next, if you develop or maintain a package manager, you need to threat model. Look at attacks where code gets into your package system, generalize them and think about variants that apply to you. Look at the attacks on search, which is how the typo-squatting attacks work. Look at “A Study of Security Vulnerabilities on Docker Hub” and while you're at it, look at other threats to your system. Then, publish your threat model, so that people can assess how well you've done and help you improve. If you use a package manager, look for its threat model.

Defining ‘Critical Infrastructure’

Lastly, there's a policy question: Is npm critical infrastructure? As I mentioned above, the U.S. uses the term “critical infrastructure” to refer to 19 or 20 sectors of the economy (power, food, chemicals, etc.) that are subject to increased scrutiny and regulation. Being subject to that scrutiny costs money, even if you're doing everything listed in the standard, because someone has to send reports to the regulator. But odds are you're not doing all the things, because each standard is slightly different.

Being regulated as critical infrastructure is expensive. I don't want to focus on the politics of it, but read through former Homeland Security Secretary Jeh Johnson's words about the concerns states expressed when rebuffing DHS help in the elections.

Regardless, is npm critical infrastructure? What happens when it's a part of the supply chain of recognized critical infrastructure? (I think that the model of there being distinct critical infrastructure may be optimistic, but that's a separate topic.)

To sum up, you should look at your controls for identification, protection and detection around your package management. If you make a package manager, you should be threat modeling the heck out of it. And lastly, if you have a public policy arm, you should engage with it about what being “critical infrastructure” would mean to you, in development, operations and security.



Adam Shostack is an entrepreneur, technologist, author and game designer. He is a member of the BlackHat Review Board, helped found the CVE, and is the author of "Threat Modeling: Designing for Security," and co-author of "The New School of Information Security."

Related Research

2/15/2018 | Ask-an-Expert
Best Practices in Container Security

8/4/2017 | Ask-an-Expert
Match Your Open Source Tools to Your AppSec Workflow

7/27/2017 | Ask-an-Expert
Standardize Docker Security