Our AI strategy for preemptive security
The vulnerability management lifecycle is a continuous, six-step process that organizations use to discover assets, assess them for security flaws, prioritize what to fix first, remediate or mitigate, and verify the result before starting again. The point of running it as a cycle rather than a project is that the environment changes faster than any single assessment: new assets appear, new vulnerabilities are published daily, and a system that was clean last quarter may not be clean today.
The six steps on this page are discover, prioritize assets, assess, report, remediate, and verify. Some frameworks compress the same work into five stages and others expand it to seven; the labels vary more than the substance does.
Effective vulnerability management in the modern threat landscape is cyclical. Faced with a dynamic and expanding attack surface, new vulnerabilities constantly emerge in the complex interplay between people and technology. It’s not enough to just find vulnerabilities at a point in time, fix them, and then consider vulnerability management “done.” This article overviews the vulnerability management lifecycle and describes its importance for strengthening your company’s security posture.
A vulnerability is a flaw in a computer system that weakens its security and can be exploited by a malicious actor for nefarious purposes. A crucial part of this definition is that vulnerabilities don’t just come from weaknesses in the design or implementation of software or hardware; how a system is operated or managed can also result in vulnerabilities.
IT security vulnerabilities have been around since well before the invention of modern personal computers. In 1965, William D. Mathews from MIT found a vulnerability in an operating system running on an IBM mainframe computer. This vulnerability revealed the contents of the operating system’s password file to any user when multiple versions of the system’s text editor were opened simultaneously.
During the 1990s, as personal computing became mainstream, and businesses started using a wider variety of software applications, more security vulnerabilities emerged. Various vendors released the earliest vulnerability scanners to help security professionals identify vulnerabilities. However, the problem was that each vendor used its own database of vulnerabilities, which created headaches for security professionals trying to verify scan results and cross-reference different databases.
In 1999, the idea came to fruition that a list of Common Vulnerabilities and Exposures (CVE) would be much more useful and remove confusion by negating any need for cross-referencing across databases. The first-ever CVE list contained 321 publicly known vulnerabilities the most recent count stands at 196,196.
Aside from known CVE vulnerabilities for which patches and fixes exist, there is also the constantly lurking threat of zero-day vulnerabilities. These are vulnerabilities for which no patch or other mitigation is yet available.
The non-profit organization Open Worldwide Application Security Project (OWASP) has spent decades working to improve the security of software. The OWASP Top 10 provides development teams with a list of top web security vulnerabilities based on data from the security community. Below we’ve listed the current OWASP Top 10:
The diagram below shows the six steps in the vulnerability management lifecycle: discover, prioritize assets, assess, report, remediate, and verify.
The point of the vulnerability management lifecycle is to put in place a systematic approach that enables organizations to discover vulnerabilities in their IT environment, understand their risks, and remediate them.
The importance of a cyclical and continuous approach to the vulnerability management lifecycle is reflected in the 7th Critical Security Control devised by the Center for Internet Security. According to the advice, organizations should, “develop a plan to continuously assess and track vulnerabilities on all enterprise assets within the enterprise’s infrastructure, in order to remediate, and minimize, the window of opportunity for attackers.” A solid basis for this plan comes from the vulnerability management lifecycle.
The first stage in the vulnerability management lifecycle is an effort to discover and create an inventory of all the different assets that should be scanned for vulnerabilities (e.g. software, web apps, operating systems, devices). Comprehensive discovery is critical in avoiding situations where you have vulnerabilities in systems or apps that aren’t properly tracked.
Bugcrowd’s external attack surface management platform provides automated asset and vulnerability discovery, with integrated penetration testing that surfaces the more complex vulnerabilities typical scans miss. It also produces the context you need to spot new risks and shrink the attack surface over time.
Not every asset carries the same weight, so the first job here is to rank systems by asset criticality: how central the system is to normal operations, how much it would cost if it went down, and how sensitive the data it holds is. Typical characteristics of high-priority assets are those that are central to normal business operations, that lack fault tolerance, or that store sensitive data.
The point here is that since vulnerability management programs are often constrained by limitations in personnel or other resources, it’s prudent to focus on hunting down vulnerabilities in high-priority assets first. When neglected and left vulnerable, organizations face significantly higher risks from potential compromises of high-impact systems. Lower priority assets don’t get ignored in vulnerability assessments, but they do take a back seat.
The assessment stage is where you run traditional vulnerability scans, ideally using as much automation as possible. You should aim for both breadth and depth here. Breadth comes from deploying dedicated tools that scan web apps, cloud infrastructure, and all other assets in your inventory for code vulnerabilities, misconfigurations, etc. You can achieve depth by adding penetration testing to the mix, in which expert security testers probe for vulnerabilities that are difficult to detect with scanning tools.
After enumerating vulnerabilities, it’s important to combine this information with your prioritized list of assets and other contextual information. This contextual information includes a risk rating for the vulnerability and the exposure level of the impacted asset(s). All of this information sets the groundwork for accurate and informative reporting on vulnerabilities and how to prioritize them for remediation.
Compile what the previous steps produced and put it in front of the people who act on it. The mistake here is writing one report for everybody.
Executives and technology decision-makers need trend and exposure, not findings: is the backlog growing or shrinking, how long does a critical issue stay open, and which business systems carry the most risk right now. Security and engineering teams need the opposite, a specific finding with an affected asset, a severity rating, a recommended fix and an owner.
This is also the step auditors ask about. A program that discovers, fixes and verifies well but reports informally will still struggle to evidence itself against SOC 2, ISO 27001 or PCI DSS, because none of the work is written down in a reviewable form.
The remediation phase includes any action to fix a vulnerability, whether that means applying a security patch, updating hardware, or changing system configurations. Sometimes, direct remediation is not immediately possible, so the best course of action will be to mitigate the risk of a vulnerability being exploited until a fix is practical, for example, by isolating a vulnerable system from the rest of the network. The severity of a vulnerability and the criticality of the underlying system will help to prioritize remediation.
The verification phase completes the vulnerability management lifecycle by double-checking that any attempts to remove or mitigate vulnerabilities have been successful.
Verification overlaps with the discover and assess phases of the next cycle, which is what continuous monitoring means in practice: assets are re-checked on an ongoing schedule rather than at the next scheduled audit, so a fix that silently regressed shows up as a finding instead of staying closed on paper. Alternatively, follow-up audits involving separate re-scans or penetration tests can help to verify if remediation actions were successful.
The six-step model is not proprietary. It is a readable version of guidance that already exists in the major frameworks, and if you need to justify a program internally, it helps to point at the source.
NIST SP 800-40 Rev. 4 covers enterprise patch management planning and preventive maintenance, which is the work that sits behind the remediate step. NIST SP 800-53 includes vulnerability monitoring and scanning as a named control, which covers assess and verify. CIS Critical Security Control 7 requires continuous vulnerability management across all enterprise assets, which is the cyclical property the whole model rests on, and is quoted earlier on this page.
If your organization reports against SOC 2, ISO 27001, or PCI DSS, all three expect evidence that vulnerabilities are identified, ranked and resolved on a defined schedule. The reporting step is where most programs fall short at audit time, not because the work was not done but because it was not recorded in a form anyone can review later.
Many teams describe the vulnerability management lifecycle in five steps. Here’s the plain-language version:
How this maps to the 6-step model on this page
Bugcrowd helps teams run vulnerability management as a repeatable program, particularly when you need more than point-in-time scanning.
Running vulnerability management as a lifecycle rather than a periodic exercise is what keeps it honest. Results and reports from each cycle of vulnerability management should inform the next cycle, for example, by highlighting key performance indicators where your business isn’t hitting its objectives.
Additionally, verifying that vulnerabilities were successfully mitigated helps to reduce the attack surface of systems. With fewer weaknesses to exploit, your company’s security posture strengthens. And, the next cycle of vulnerability management (hopefully) comes with fewer vulnerabilities to discover and remediate.
While vulnerability management does help to reduce your attack surface, a dedicated approach to attack surface management encompasses visibility into all external assets and the discovery of all potential entry points across infrastructure, devices, apps, and data. Attack surface management also accounts for the interconnectedness of different systems and components for more granular risk management.
Informer’s external attack surface management platform provides automated asset and vulnerability discovery, with integrated penetration testing able to unearth more complex vulnerabilities that typical scans may not find. You also get actionable security insights for uncovering new risks and helping to shrink your attack surface.
Organizations can identify vulnerabilities through various methods, including:
Vulnerabilities are assessed and prioritized based on factors such as their severity, potential impact on the organization, exploitability, and the value of the affected assets.
Common methods include using vulnerability scoring systems, such as the Common Vulnerability Scoring System (CVSS), and considering additional contextual factors specific to the organization’s environment.
Organizations can ensure the effectiveness of vulnerability management by: