npmjs.com

npm Security Policy

Outlined in this document are the practices and policies that npm applies to help ensure that we release stable/secure software, and react appropriately to security threats when they arise.

Table of Contents

  1. Reporting Security Problems to npm
  2. Security Point of Contact
  3. Onboarding Developers
  4. Separation of Duties and Authorization
  5. Critical Updates And Security Notices
  6. Responding to Security Threats
  7. Vulnerability Scanning
  8. Password Policies
  9. Application Design Best Practices
  10. Development Process
  11. AntiVirus Software

Reporting Security Problems to npm

If you need to report a security vulnerability. Please contact us or email security@npmjs.com.

We review all security reports within one business day. Note that the npm staff is generally offline for most US holidays, but please do not delay your report! Our off-hours support staff can fix many issues, and will alert our security point of contact if needed.

Security Point of Contact

npm's CTO Laurie Voss is the current point of contact for all security related issues.

Any emails sent to security@npmjs.com will be escalated to the security point of contact, who will delegate incident response activities as appropriate.

Onboarding Developers

All new technical hires are introduced to our security policy as part of the onboarding process.

Separation of Duties and Authorization

Critical Updates And Security Notices

We learn about critical software updates and security threats from a variety of sources:

Ubuntu Automatic Security Updates

Along with keeping an eye out for critical security updates, automatic security updates are enabled on all of our production servers allowing patches to be applied immediately without human intervention.

https://help.ubuntu.com/community/AutomaticSecurityUpdates

Responding to Security Threats and Critical Updates

When a security threat is identified, we have the following process in place:

  1. We have the slack channel security-all, which is used to prioritize and coordinate responses to security threats.
  2. Our Security Point of Contact oversees this discussion: managing the triage, responding to emails, and updating npm's status page.
  3. Based on the triage, work is allocated to developers to address the threat:

Vulnerability Scanning

Along with reacting to security notifications as they happen, we proactively pen-test and audit software.

Third-Party Audits

We perform regular penetration testing and code audits with the security firm Lift Security.

While working on features at npm, all engineers coordinate security audits with the Security Point of Contact.

Documents from this process are available, and can be provided to customers when requested.

Automated Scanning

The cloud hosting platforms that we use provide options for automated vulnerability scanning.

Password Policies

Don't Use Passwords

We should opt for alternative authentication methods when possible:

SSH Keys

SSH keys should be rolled out selectively, providing developers access to only the severs that they require access to.

Application Design Best Practices

In the next section of the document, we discuss the design methodologies that we use to build stable and secure software.

Logging Practices

Logs are important for both debugging applications and detecting security breaches in our software -- ask CJ for a speech about logging.

What We Log

Log format

All applications should contain logging for date, time, operation, and a unique request identifier.

We use common-log-string internally to standardize this:

Backing Up Logs

At least 90 days of logs should be kept for each service. On high traffic hosts this may require backing-up logs in cloud storage on a regular basis.

Reviewing Logs

On the servers that we manage for other companies, we should audit logs on a regular basis.

TODO: We plan to build automated anomaly detection systems in place for our logs see internal issue #381.

Secrets in Logs

Logs should not contain any sensitive user information, e.g., passwords.

The module hide-secrets is used to help with this.

Limiting Access to Operating System Files

Micro-services should only have access to databases and files that they need access to.

With our docker-based infrastructure (npm On-Site) this is achieved by having containers only mount folders on the root host that they require access to.

In our production environment, this is achieved by partitioning services across multiple hosts.

Security Groups

Security-groups, or Zones in the case of SoftLayer, are used to limit the network connectivity between hosts.

When deploying a service, ask: "what other services does this actually need to connect to?"

Storage of Data

Any sensitive user information should be encrypted at rest. Using encrypted EBS drives, or an equivalent, is a great way to achieve this.

Inter-Service Communication

Communication between services on the same host can be performed via HTTP.

All inter-service communication between two hosts is performed using TLS.

Development Process

npm has a well-defined, security-focused, development process:

Code Reviews

No code goes into production unless it is reviewed by at least one other developer.

The onus is on the reviewer to ask hard questions: "what are the ramifications of opening up port-X?", "why is this connection being made over HTTP instead of HTTPS?"

Deploying Updates

Unit Testing

We love testing at npm:

Design Cycle

The design process, and management techniques vary from team to team at npm. Across the board, however, we strive to have continuous deployments. Releasing many small features as they become production ready.

Security is taken into account during all phases of the software development life-cycle: unit tests think about potential threats; when testing on staging, we attempt to test potential exploits, etc.

AntiVirus Software

On our managed Ubuntu hosts, we run the ClamAV AntiVirus software.

When A Virus Is Identified

The infected server should be retired, and a new server should be provisioned from scratch.

Changes

This is a living document and may be updated from time to time. Please refer to the git history for this document to view the changes.

License

This document may be reused under a Creative Commons Attribution-ShareAlike License.

Last modified February 02, 2016           Found a typo? Send a pull request!

npm Services

Getting Started

How npm works

Private Modules

Troubleshooting

Using npm

CLI Commands

Configuring npm

npm policy documents

View All On One Page