A recent npm survey revealed that 77 percent of developers were concerned about the quality and security of the open source libraries they use, while 52 percent said the tools currently available were inadequate. Given the trust issues in open source and the ongoing discovery of website and application vulnerabilities, security should be top of mind for developers at the start of every project—but also on an ongoing basis. I call this practice of constant re-assessment “continuous security.” Here’s how I like to describe it:
Imagine you are standing at the bottom of an escalator that’s moving downward. 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 traveling down toward 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 cliché, 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 life cycle 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 a legal team, that might be license compliance; for a development team, it’s likely to be a security bug in a production service.
When you start out, your abilities to discover risk are going to be pretty poor, but that’s okay. I like to apply this discovery process at the natural gates of the development life cycle. Major ones include: when the feature is designed, when code is first written and 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 stages will vary greatly by the needs of the business and change as your security program matures. There will be arguments continually about what is considered a risk and how it 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 in your organization will have their own perspective, so developing a strong set of policies and standards to 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 that security assigns to risk (P0 = drop everything and fix critical, to P3 = fix within 180 days). This tells engineering how long each risk should take to mitigate, helping 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 to be able 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 developers and code.
