Continuous Security

It’s been almost a year since npm acquired ^Lift Security and even less since the official formation of the internal npm Security Team. In addition to working on securing the Registry and its users, I’ve been setting aside time to think through how we look at security at npm. I wanted share some of my ideas with our community so that you can see what’s going on and benefit from them too.

I’ll start by describing what I call ‘Continuous Security’:

Imagine you’re standing at the bottom of an escalator that’s moving downwards. Your goal is to reach the top. You might think, ‘easy, I’ll just sprint my way to the top! Run as fast as possible and I’ll get there and the problem is solved’.

It’s not that easy though. As you start your climb, you realize that you haven’t really trained for this and you’re slower than expected. The people travelling down towards you become obstacles to be evaded. Through all this, you have to maintain your upward momentum or you’ll end up back where you started.

Now, it might sound a little cliche, but that’s how I view security. Security is something you have to continually train for—a constant cycle of risk discovery, prioritization, and skill-building to close the gap to get results.

Continuous security is all about becoming more efficient at this entire lifecycle and reducing the time to risk discovery and the overall cost of mitigation.

Risk Discovery

The first step to improving your security situation is to find something that needs improvement. These tend to be risks to the business and look different depending on your focus area. For legal that might be license compliance; for a development team it’s likely to be a security impacting bug in a production service.

When you first start out, your abilities to discover risk are going to be pretty poor, but that’s ok. I like to apply this discovery process at the natural gates of the development lifecycle. Major ones include: When the feature is designed, when code is first written, when someone makes a pull request, pushes code to staging, and pushes it to production. The tooling and techniques you use in each of these will vary greatly by the needs of the business and change as your security program matures. There will continually be arguments about what is considered a risk and how they should be prioritized. This is part of the process of refining your risk discovery skills and tools.

Policy and standards

There is rarely any change without pressure, and because we don’t always have an active incident to force improvement, that pressure sometimes has to come from within. Motivating your team through policies and standards can be the ideal way to influence improvement. Everyone at your org will have their own perspective, so developing a strong set of policies and standards that you measure yourself against will go a long way. Writing and adopting these standards should be collaborative, both with your security team and the organization as a whole.

These policies help you determine what is a risk and how you prioritize it as an organization. At npm we have a standard rating scale (P0 = drop everything and fix critical, to P3 = fix within 180 days) that security assigns to risk. This tells engineering how long each risk should take to mitigate and helps them prioritize their work accordingly.

Mitigation and improvement

This is where the technical practitioner will have the most fun—fixing lapses in security is usually satisfying work. The important part is to use each incident as an opportunity to scale your efforts in risk identification.

For development teams, that means pushing more automation in your CI/CD pipeline to arm developers with the ability to find security issues earlier in the development process. I like to call this the CI/CD/CS pipeline: continuous integration, delivery, and security. However, automation is far from perfect, and the best way to improve decision making is to provide a human with the right amount of information in the right context whenever a decision needs to be made.

An important thing to remember is that your solution does not have to be perfect. There are many situations in security where ‘better’ is good enough to mitigate risk to an acceptable level. In the end, what you need to have is a constant feedback loop of risk discovery and mitigation using technology and processes to manage and improve.

Continuously improving Continuous Security

Setting goals and expectations is a part of Continuous Security, but you should keep in mind that ‘security’ is not a set destination. The word ‘security’ lies to us by suggesting that it’s possible to ‘secure’ something, when in truth the mitigation of all risk is an impossibility.

Instead, always try to maintain your upward momentum. Measuring all successes and failures honestly allows you to be effective at all times, whether in the middle of a security issue or a period of relative calm. A continuous, proactive approach to security is the only way to effectively ensure the safety of the 11 million developers who depend on npm’s Registry and products.