Recently, we sat down with Adam Baldwin, VP of Security at npm, to discuss his approach to security and what he’s learned as far as security goes throughout his career. We wanted to share the insights that came out of our conversation.
Tell me a little bit about yourself and your time at npm
I’m the VP of Security at npm. I came aboard npm as part of an acquisition in early 2018 from a pentesting company (called ^Lift Security) that I ran. I stepped into the VP of Security role to help npm scale and uplevel our security.
I have a history with npm however, so it was only fitting that I ended up there. I started the node security project, and my first open source contribution was to the npm registry 7-8 years ago as a security fix for the registry.
What’s your history with security? How did you get started?
I was a curious mind in a small town. I started experimenting with hacking when I was 15 years old, exploring efforts like guessing passwords. Then I found a mentor who taught me programming and reverse engineering. That really kicked off my career and journey into security.
My first jobs were in places that got me into network administration, security, and more. I worked with ISPs, so attackers were continuously attempting to compromise us, and we had to learn to defend ourselves.
From there, I followed my interest in offensive security and started my own pentesting company. I’ve spent a lot of time in offensive security, and now that I’m on the other side, I can say that the defensive side is way harder. Offense has no real restrictions, while defense does (budget, people, legacy code, etc.). Defense becomes a continuous effort to keep up.
Security is a broad topic with a lot of different approaches and beliefs. What is your philosophy on it?
I base my approach on the fact that we can’t ever be perfect as far as security goes. Security is not a solvable problem. When you approach it from that perspective, you realise you can’t just have one product or solution — you need a multi-layered approach to handle security at different points and different levels.
As far as security goes in any company, you have to be okay with just doing better. It’s about continuous improvement rather than achieving any semblance of perfection. Even if it were possible to hit a level of point-in-time perfection, attackers or your environment would evolve, and moments later, you’re no longer perfect. So it’s really about figuring out how to keep moving forward, every day.
Now as far as what this means in practice: for application security teams and developers, or whenever you roll out new systems, make the right thing easy and make the easy thing secure. Whatever the “right thing” is for a developer in your organization to do, make it frictionless and make it the secure option. If you can build a system where engineers can do a secure thing easily, then they’ll do it. That’s the best way to build security into your development culture.
How have you approached security at npm?
My approach at npm has come from a fairly unique place. I transitioned from an offensive services company to a defensive, product company. There’s a transition that happens there that’s not always smooth. However, I am able to bring a great bit of value to the team: I know the bad things I would do to npm from my offensive background, so it helps me identify and prioritize the different security risks we have. I have the perspective needed to know which sorts of risks are the most dangerous or need the quickest attention, based on which ones I know I could exploit.
A lot of the work we do is not publicly seen, but one of the top visible things we’ve brought out is npm-audit — which makes npm more secure and extends it into the ecosystem. It helps people recognize and realize that they have a set of vulnerabilities. That’s the start. From there, they can focus on patching and remediating them.
We do a lot internally to constantly uplevel our security. We’re doing a lot of research at scale in order to make npm-install a safe operation. We also build internal systems to identify malware, suspect packages, and more.
As you’ve grown, how have you evolved and scaled security at npm? What steps have you taken?
We have a security team of five, which is very small compared to the ecosystem, but not unusual for the industry.
When I started at npm, the first thing I focused on was understanding what we had. The early questions were focused on understanding the state of things internally, such as clarifying what the inventory looks like. If you don’t know what you have, you can’t secure it. For the build tools for example, internal teams might say one thing, but what does AWS say? Are they in alignment? Are people going outside of the build tools to do things?
Really what it comes down to is making attackers do enough work to make enough noise. If you make their attacks not worth the effort or noisy enough that you can detect them easily, you’re in a great position.
To scale, we automate as much as we can from a discovery and understanding perspective. That’s the starting point. However, no matter how much we automate, we’re always playing catch-up. That’s not unique to npm — defense is always playing catch-up to offense. It’s a driver for us to always keep improving. We’re constantly learning about the latest attacks, paying attention to other ecosystems, learning from others, and keeping an eye on the news and seeing if it applies to us.
Fortunately for us, we have a huge, fantastic community, and that community is very quick to report anything they find, so we get a lot of alerts and reports. This helps us stay on top of any urgent and immediate issues.
We do a fair amount of experimenting as well. As part of the security insights API, for example, we built detonation environments to blow up something and see what it does in a safe space. This way we’ve been able to learn some surprising things about how our applications react in unusual situations.
Bringing in tooling and automation has been a focus for us as well. You can’t scale with just humans. We get 7,700 publishes a day to the ecosystem. We can’t manually audit that, and even if we could, people would miss something eventually, because we’re only human, after all. Complimenting humans with automation can go a long way towards scaling what you’re capable of, security-wise.
What does your ideal state of security look like and what are the challenges you see blocking it today?
Because security is not solvable, it’s always in flux. That means an ideal state is not really achievable. That doesn’t mean you give up, of course! You need to implement tooling to surface suspicious activities and events for any app or area that matters to you. Implementing a multi-layered approach to security is the best thing to do. The layers may differ for different industries and companies, but one example may be static analysis on everything that surfaces all dangerous stuff up, running monitoring and protection in real time, keeping a bug bounty to have people look at and test all of it, and getting the feedback to fix what matters most.
Really what it comes down to is making attackers do enough work to make enough noise. If you make their attacks not worth the effort or noisy enough that you can detect them easily, you’re in a great position.
Think about having to write the incident blog post — the first line of which is always some variation of “we care deeply about security.” There’s always a word missing there: “now.”
As far as the main challenges I see, adoption and adherence to security policies will always be up there. Known attacks like password spraying still work even with 2FA, because not everyone will use it. For user hygiene, it’s about awareness and not having enough of that out there. The challenge is in getting people to act. Some people don’t know to pay attention to security, while others just put it off.
A lot of the other limitations around security is hands-on-keyboard items — getting the time and resources to build and implement the tooling you need to protect yourself. Some of these insights will come as more things are developed and rolled out, while some of it is just about allocating the budget and time to either build or buy tools that will monitor, protect, and alert you.
What excites you about the future of security?
I’m really interested in what we can do with the larger and larger datasets we’re getting access to. There are lots of opportunities to collect more signals and apply models and machine learning to them. For example, we could create a model that gathers and processes all the security signals that an organization gives off, and leverage that for insights.
Raising up security signals and collecting them (from a bug bounty or some sort of tooling), is a huge and interesting area. Right now, for bug bounties, you don’t know what the researchers covered or didn’t touch. They’re a valuable security contribution, but we don’t capture enough.
The only way to achieve any of these developments is through automation. It can’t be done with people alone. Two people doing security reviews and assessments are going to find different things. People have bad days and miss stuff too. You have to pair humans with automation to start to level things up.
Do you have any advice for companies or people beginning their own security journey?
It comes down to “crawl-walk-run.” If you’re starting out with a limited staff or security knowledge, there’s still a lot you can do to improve your security. Asset management is the heart of it — making sure that you know what you have. From there, start doing the healthy things and follow best practices. Keep all of your software and dependencies up-to-date, do regular backups, implement strong password management, etc. — the basics.
We talk about fancy machine learning and aspirational items like that, but it’s often the simple things that compromise us — phishing emails, credential stuffing, social engineering, etc. That’s how people get breached way more often. So the best way to uplevel your security is to focus on those items. Once you have those in a good place, layer on the next level of security practices — logging, application protection, alerting, etc.
If you can’t prevent attacks, then at least ensure that you’re able to detect and recover from them. If a system is compromised, what happens? Sit down with your engineers and play out scenarios. What if this server is compromised? Would we know, how could we detect it, and what would we do? Think about having to write the incident blog post — the first line of which is always some variation of “we care deeply about security.” There’s always a word missing there: “now.” They care about security now. As the security owner, it’s your job to make that line not a lie. What could you do today that would make you feel comfortable saying that line if you get breached? Security is not 100%, or fully solvable, so you may have to write that line and blog post at some point no matter what you do. So do whatever you need to do to make it not a lie.
Some other quick hits that I’ve learned:
- Don’t over-collect data. If you don’t need it, throw it away. If you don’t have it, attackers can’t steal it.
- Checklists are key. We all make mistakes and it helps to have a guide post to ensure that you’re not forgetting anything obvious.
—-
Thanks so much to Adam for his time. If you’d like to read more interviews with people in the industry, check out our conversation with Dan Robinson and Jerry van Leeuwen on prioritizing security at Heap.
