By Eric Baize, vice president, product & application security at Dell Technologies
Software security bugs are as inevitable as head colds. And while some of them are minor, like a case of the sniffles, others such as vulnerabilities, are akin to infectious diseases as they put customers at risk of exploitation by bad actors. With the normalization of global remote work, exposure is heightened. According to Dell Technologies’ Breakthrough study, 72% of respondents believe that the changing working world has exposed their organization to even greater risk. As a software vendor, it’s your job to protect customers when vulnerabilities arise in your code. But where do you begin?
Step one: Identify vulnerabilities
The first step to squashing a bug is spotting it. Using a secure development lifecycle that highlights continuous security testing will surface vulnerabilities before you ship your software. As you refine your testing process, you might find vulnerabilities during development that would have slipped through the net before. Other sources for vulnerability discovery are external. Independent ethical hackers are eager to report security flaws, but you must make it easy to do so. Support them with clear reporting guidelines and channels, along with a visible disclosure process that clarifies how you’ll work with them. FIRST and ISO29147 provide broadly adopted methods to communicate these guidelines.
You can make even better use of the research community with a more formalized, structured program. One way to do this is to approach ethical hackers or consulting companies privately for penetration testing.
Another is to operate a bug bounty program where the security research community is invited to proactively find vulnerabilities in your products and applications. You can organize a private group of selected researchers or engage in a public program that invites input from the broader community. Companies like Bugcrowd specialize in running these programs for companies.
With so much software today including third-party components, it’s important to watch for vulnerability notifications from upstream software suppliers in your own supply chain. Open-source software can invigorate application development cycles but also needs to be closely monitored and managed.
Your suppliers will sometimes communicate with you right before a vulnerability’s public disclosure. Pay this forward by communicating security vulnerabilities with resellers of your own product.
Step two: Coordinate the remedy
Once you’ve found the vulnerability, you’ll want to prepare a step-by-step remediation plan to drive a remedy before publicly disclosing it. During this stage be sure to follow the coordinated vulnerability disclosure process between you as the software developer and the external parties that found the vulnerability. Use responsible disclosure guidelines such as ISO/IEC 29:147:2018, which provide recommendations on receiving vulnerability reports and disclosing vulnerabilities. The PSIRT Services Framework from the international security forum FIRST is another useful resource.
Step three: Communicate with customers
Having arrived at a disclosure plan, communicate the security vulnerability to customers. Ideally, you’ll have a patch for the vulnerability at this point or at least a workaround in the event of a zero-day flaw that attackers are already exploiting.
Communicating a vulnerability to customers is a sensitive step, as yours won’t be the only one they’re dealing with. Customers are inundated with software patches and often have limited resources to deal with them.
You can guide customers through the process by doing the following:
- Include automated update capabilities in your software. Be sure to give customers an opt-out option, as they might face regulatory or testing constraints before they can apply patches
- Publish detailed security advisories but be careful not to give away too much sensitive information. You must enable customers to fix the bug without empowering attackers to exploit it
- Integrate with customers’ own vulnerability management programs to help communicate information smoothly. This includes assigning a Common Vulnerabilities and Exposures (CVE) to your security vulnerability, which feeds the National Vulnerability Database. This will make it easier for customers to reference.
Ideally, your actions will create a continuum that extends smoothly and quickly from vendor vulnerability response to customer vulnerability management with minimal disruption or confusion. You can even automate some aspects of this by publishing application programming interfaces (APIs) that provide vulnerability information digitally. The OASIS Common Security Advisory Framework is a good starting point for an API. It includes a data structure for structuring this information.
Go end-to-end
Handling one vulnerability well is a good start, but this is a never-ending job. After the disclosure is complete, it’s good practice to run a root cause analysis that can feed back into and enhance your software development process and also search for similar vulnerabilities in other areas of your codebase.
Vulnerability management doesn’t stop when you stop developing a product, either. Each version of your software has a lifecycle that eventually ends when the release is no longer supported by the vendor. Develop a policy for supporting security vulnerabilities in software for a set period after you stop selling it.
This end-to-end vulnerability response process takes planning and continual improvement, but it’s a crucial part of any software developer’s business. It builds customer trust and helps protect them from risk. A smooth, methodical approach to managed vulnerabilities is less error-prone than a haphazard rush to handle unmanaged ones.
This article is the second in a four-part series on secure product development. Be sure to check out the rest of the articles in the series:
Why your coding team needs to use a secure development lifecycle
How to grow a secure software culture from the inside out
How to secure your software supply chain when using open-source technology