<![CDATA[Vulnerability Management ]]>https://vulnerability-management.hashnode.devhttps://cdn.hashnode.com/res/hashnode/image/upload/v1593680282896/kNC7E8IR4.pngVulnerability Management https://vulnerability-management.hashnode.devRSS for NodeSun, 20 Sep 2026 06:38:50 GMT60<![CDATA[What is Vulnerability Management, how it works and why is it important? ]]>https://vulnerability-management.hashnode.dev/what-is-vulnerability-management-how-it-works-and-why-is-it-importanthttps://vulnerability-management.hashnode.dev/what-is-vulnerability-management-how-it-works-and-why-is-it-importantSun, 12 Jul 2026 02:06:27 GMTWhat is a vulnerability?

A vulnerability refers to weaknesses or issues present in a system that make a threat more likely to materialize. A threat, in turn, is anything that can cause damage to a system's or organization's data.

Type of Vulnerabilities

Software Vulnerabilities

  • Unintentional weaknesses introduced during the development process.

  • Examples: memory corruption, logical errors.

Misconfigurations

  • Incorrect configuration during installation or maintenance, such as using default credentials, granting excessive privileges, or leaving unnecessary ports open.

  • These are usually accidental or result from failing to follow security best practices.

Design Vulnerabilities

  • These are structural or architectural flaws in a system.

  • Examples include using weak cryptographic algorithms or failing to encrypt data in transit or at rest.

Network Vulnerabilities

  • Network-level vulnerabilities allow attackers to gain access to an internal network.

  • Examples include open ports and weak firewall configurations.

Hardware Vulnerabilities

  • Physical devices such as routers, servers, or USB devices may contain design flaws that cybercriminals can exploit.

Human Vulnerabilities

  • Human error is one of the leading causes of cybersecurity vulnerabilities.

  • Examples include clicking phishing links, using weak or easily guessed passwords, and a lack of security awareness.

What is Vulnerability Management?

Vulnerability management is a continuous, cyclical process that enables organizations to identify, assess, prioritize, and remediate weaknesses and vulnerabilities across their IT infrastructure before attackers can exploit them.

Key Steps

Identification – Use vulnerability scanners, manual assessment techniques, and asset discovery methods to identify and inventory systems, along with any security issues they may have.

Reporting – Report identified security issues to the appropriate stakeholders so they can be reviewed, prioritized, and ultimately resolved.

Remediation – The system owner or responsible technical team addresses the security issues to eliminate the vulnerability. Remediation methods may include applying security patches, reconfiguring systems, or implementing compensating security controls.

Reassessment – Perform follow-up vulnerability scans or manual verification to ensure that identified security issues have been properly remediated and are no longer present.

Key Takeaway: Effectively tracking identified security issues and ensuring that systems and software are updated as quickly as possible—typically after appropriate testing to prevent unintended side effects—significantly reduces the window of opportunity for attackers to exploit known vulnerabilities.

Vulnerability Management Lifecycle

The vulnerability management lifecycle consists of five primary stages:

Step Focus
Discovery Identify and inventory all assets (hardware and software) across the environment.
Assessment Identify vulnerabilities using vulnerability scanners, penetration testing, and threat intelligence (such as OSINT).
Prioritization(Triage) Rank vulnerabilities based on risk by considering both severity and organizational context.
Resolution Remediate, mitigate, or formally accept the identified risk.
Verification Confirm that the vulnerability has been successfully remediated or mitigated, and reassess the affected systems to ensure they remain secure.

Defining the Scope for Discovery

  • Asset Inventory - A comprehensive inventory of all hardware and software assets within the environment.

  • Inventory Creation Methods:

    • Manual: Using spreadsheets or manually surveying networks. Suitable for small organizations but time-consuming and difficult to maintain.

    • Automated: Using asset management platforms, network discovery tools, or deployed agents to continuously discover and inventory assets.

Assessment Methods

  • Vulnerability Scanners

    • Network Scanners – Identify operating systems, software, and versions, then compare them against known vulnerability databases.

    • Web Application Scanners – Detect common web application vulnerabilities such as Cross-Site Scripting (XSS), path traversal, and injection attacks.

    • Static Code Analysis (SAST) – Analyze source code to identify insecure coding patterns, hardcoded secrets, and other security weaknesses before deployment.

    • Configuration Assessment – Detect security misconfigurations in environments such as Active Directory, cloud platforms (AWS, Azure, GCP), and operating systems, often by comparing configurations against CIS Benchmarks and other security standards.

  • Penetration Testing

    • An authorized, simulated cyberattack designed to identify exploitable vulnerabilities.

    • Provides a different perspective than automated vulnerability scanning by validating whether vulnerabilities can actually be exploited.

    • Helps verify the effectiveness of remediation efforts and compensating controls.

    • Requires explicit authorization before testing. In cloud environments, approval from the cloud provider may also be required depending on the scope and testing activities.

Prioritization (Triage)

Don’t Rely Solely on the CVSS Score - it’s important not to rely exclusively on the CVSS score. Organizations should also consider the broader business and operational context to accurately assess risk.

Two Key Considerations

  1. Likelihood of Exploitation

    Factors that increase the probability that a vulnerability will be exploited include:

    • A publicly available proof-of-concept (PoC) or exploit (e.g., Exploit Database or GitHub).

    • The vulnerability is listed in the CISA Known Exploited Vulnerabilities (KEV) Catalog.

    • A high Exploit Prediction Scoring System (EPSS) score, indicating a greater likelihood of exploitation in the wild.

  2. Potential Impact if Exploited

    Evaluate the consequences of successful exploitation, including:

    • Immediate impact (e.g., system compromise or service outage).

    • Delayed or chained impact when combined with other vulnerabilities.

    • Data exposure, service disruption, privilege escalation, or other business-critical consequences.

Vulnerability Classification

Once vulnerabilities have been assessed and prioritized, they are typically categorized into one of the following groups:

  • Remediate Immediately – High-priority vulnerabilities that require prompt action.

  • Acknowledge and Defer – Vulnerabilities that are accepted temporarily and scheduled for future remediation.

  • Requires Further Investigation – Vulnerabilities that need additional analysis before an appropriate course of action can be determined.

Resolution Options

Option Description
Remediate Completely eliminate the vulnerability by applying a security patch, software update, configuration change, or other permanent fix.
Mitigate Reduce the likelihood or impact of exploitation without fully eliminating the vulnerability (e.g., implementing firewall rules, network segmentation, disabling vulnerable services, or applying compensating controls).
Accept Formally acknowledge and accept the risk when remediation or mitigation is not feasible. Risk acceptance should be documented, approved by the appropriate stakeholders, and reviewed periodically, as it is typically intended to be temporary.

Frameworks and Standards for Prioritization

1. CVE (Common Vulnerabilities and Exposures)

A universal identification system for publicly disclosed vulnerabilities. Each vulnerability is assigned a unique identifier in the format CVE-YYYY-NNNNN, allowing vendors, security tools, and organizations to speak the same language. Maintained by the MITRE Corporation (funded by the U.S. government).

  • Operates through CNAs (CVE Numbering Authorities): authorized organizations responsible for assigning CVE IDs. There are currently more than 300 CNAs worldwide, including major vendors, security coordinators, and certified researchers.

  • Use in Prioritization – Enables organizations to look up verified information about a specific vulnerability, determine whether patches are available, and verify whether it is being actively exploited. Without a CVE ID, different tools may report the same vulnerability under different names, leading to confusion and duplicated effort. It is the primary reference for searching public exploit databases and coordinating incident response across security teams.

2. CVSS (Common Vulnerability Scoring System)

A standardized framework for assessing the severity of vulnerabilities using a numerical score ranging from 0.0 (no impact) to 10.0 (critical). It is maintained by FIRST (Forum of Incident Response and Security Teams).

  • Calculates the score using 8 Base Metrics: Attack Vector (where the attack originates), Attack Complexity (difficulty of exploitation), Privileges Required (authentication level), User Interaction (human involvement), Scope (whether the exploit crosses security boundaries), and the impacts on Confidentiality, Integrity, and Availability. It also includes Temporal Metrics (which change over time) and Environmental Metrics (organizational context).

  • Exploitability Metrics

    • Attack Vector (AV): Where the attack originates — Network (remote) / Adjacent (local network) / Local (local access) / Physical (physical access).

    • Attack Complexity (AC): Technical difficulty of exploitation — Low (easy, no special conditions) / High (requires complex conditions or configuration).

    • Privileges Required (PR): Level of authentication required — None (no authentication) / Low (basic user) / High (administrator/root).

    • User Interaction (UI): Whether human interaction is required — None (fully automated) / Required (a user must perform an action).

  • Impact Metrics - Measure the damage caused (CIA Triad + Scope).

    • Scope (S): Does the exploit cross security boundaries? — Unchanged (impact remains within the same component) / Changed (impact extends to other components).

    • Confidentiality (C): Data disclosure — None / Low (limited disclosure) / High (complete disclosure).

    • Integrity (I): Data modification — None / Low (limited modification) / High (complete control).

    • Availability (A): Denial of service impact — None / Low (degraded service) / High (complete system outage).

  • Use in Prioritization – Provides a standardized technical assessment of a vulnerability’s baseline severity. CRITICAL: Do not rely on CVSS alone. It measures theoretical technical severity, not actual risk. A CVSS 9.0 vulnerability on an isolated system may be a lower priority than a CVSS 7.0 vulnerability on a critical public-facing server. Always complement CVSS with organizational context, including asset criticality, real-world exposure, the sensitivity of the data involved, and business impact.

  • Primary Limitation – Measures technical impact but does not account for the likelihood of exploitation or the organization’s specific context.

3. CWE (Common Weakness Enumeration)

A classification system that describes types or classes of vulnerabilities, rather than individual vulnerabilities. It explains the root causes and fundamental nature of security weaknesses. It is maintained by the MITRE Corporation.

  • Organizes weaknesses into a four-level hierarchy:

    • Pillar: Very broad categories (e.g., Access Control).

    • Class: General types of weaknesses (e.g., Improper Authorization).

    • Base: Weaknesses that can be identified in specific code.

    • Variant: Weaknesses specific to a particular platform or programming language.

  • Difference from CVE

    • CVE: A specific vulnerability affecting a particular product and version.

    • CWE: An abstract category describing the underlying weakness that can appear across multiple products.

  • Use in Prioritization – Helps identify systemic patterns of recurring vulnerabilities. If multiple CVEs in your environment map to the same CWE, it indicates a structural issue that requires a fundamental solution beyond applying individual patches. This may involve developer training, reviewing secure development practices, implementing static code analysis, or making architectural changes. CWE is essential for root cause analysis.

4. CPE (Common Platform Enumeration)

A standardized naming scheme used to uniquely identify software and hardware products. It eliminates ambiguity caused by multiple textual representations of the same product (e.g., “Apache Web Server”, “httpd”, or “Apache HTTP Server”). It was created and is maintained by the NIST (National Institute of Standards and Technology).

  • Format Used – A structured URI consisting of 11 components: cpe:2.3:part:vendor:product:version:update:edition:language:sw_edition:target_sw:target_hw:other

    • Example: cpe:2.3:a:apache:http_server:2.4.49:*:*:*:*:*:*:*

  • Use in Prioritization – Enables precise vulnerability searches by product and version in databases such as the National Vulnerability Database (NVD). Automated vulnerability scanners use CPE internally to match detected software with known CVEs. It is fundamental for automation, as it eliminates the need to manually map product names to vulnerabilities. CPE is also essential for asset inventory and Software Bill of Materials (SBOM) management.

  • Primary Limitation – CPE entries are created manually by analysts, which may introduce errors. Newly released software may not yet have an assigned CPE, and some products may have multiple valid CPE representations.

5. CISA KEV (Known Exploited Vulnerabilities Catalog)

An authoritative catalog of vulnerabilities with verified evidence of active exploitation in real-world attacks. It is maintained by CISA (Cybersecurity and Infrastructure Security Agency), a U.S. government agency. The catalog is based on threat intelligence, incident reports, and analysis of malicious campaigns.

  • Establishes mandatory remediation deadlines for U.S. federal agencies, making KEV a compliance requirement for the U.S. public sector.

  • Use in Prioritization – If a vulnerability appears in the CISA KEV Catalog, there is confirmed evidence that it is being actively exploited by real threat actors. These vulnerabilities should be remediated immediately, regardless of their CVSS score, the criticality of the affected system, or the availability of workarounds. Active exploitation means the window of opportunity to prevent compromise is rapidly closing.

Although mandatory only for U.S. federal agencies, private organizations and organizations in other countries should also use the KEV Catalog as an indicator of imminent threat. If attackers are actively exploiting vulnerabilities against government systems, those same vulnerabilities are likely to be targeted in the private sector as well.

6. EPSS (Exploit Prediction Scoring System)

A probabilistic scoring system that uses machine learning to predict the likelihood (0% to 100%) that a vulnerability will be exploited within the next 30 days. It was developed by FIRST (Forum of Incident Response and Security Teams). EPSS analyzes multiple signals, including the availability of public exploit code, mentions on security mailing lists, discussions on social media, activity in code repositories, and historical exploitation trends. The model is continuously trained using historical data.

Unlike CVSS, which is static, EPSS changes daily as the threat landscape evolves. A vulnerability may initially have a low EPSS score but increase significantly once a functional exploit becomes publicly available.

  • Complement to CVSS:

    • CVSS answers: “How severe would the impact be if the vulnerability were exploited?” (Impact)

    • EPSS answers: “How likely is the vulnerability to be exploited in the near future?” (Likelihood)

    • Formula: Actual Risk = Impact (CVSS) × Likelihood (EPSS)

  • Use in Prioritization – Enables risk-based prioritization when remediation resources are limited. A CVSS 9.0 vulnerability with an EPSS of 0.1% may represent a lower immediate risk than a CVSS 7.0 vulnerability with an EPSS of 95%. This approach helps maximize risk reduction by prioritizing vulnerabilities with the highest likelihood of exploitation first.

7. NVD (National Vulnerability Database)

A comprehensive vulnerability database that enriches basic CVE entries with detailed analysis and additional context. It is maintained by the NIST (National Institute of Standards and Technology), a U.S. government agency. The NVD allows users to filter vulnerabilities by specific product (CPE), severity (CVSS), weakness type (CWE), publication date, vendor, or any combination of these criteria.

  • Added Value Compared to CVE.org:

    • Official CVSS scores calculated by NIST analysts.

    • CWE mappings (weakness classification).

    • Affected CPEs (products and versions).

    • Detailed timelines (discovery, publication, and patch release).

    • Specific exploitability configurations.

    • Change history and revision tracking.

  • Use in Prioritization – Serves as the primary source for detailed research on vulnerabilities identified through vulnerability scanners or penetration testing. It provides the official CVSS score, explains the underlying weakness (CWE), identifies the exact affected product versions, lists available patches or workarounds, and describes the attack vector. The NVD API also enables critical automation, such as security dashboards, automated alerts for newly published CVEs affecting products in your asset inventory, and compliance reporting.

Useful Vulnerability Management Tools

The following are examples of tools that can be used to learn and practice vulnerability management. Some are open source, while others offer free or trial versions.

1. Nessus Essentials

Nessus Essentials is a free product from Tenable that allows users to perform vulnerability assessments under a license intended for personal or non-commercial use. It is ideal for short-term assessments, proof-of-concept (PoC) projects, or securing a small home network. It is not intended for enterprise or production environments. With this license, you can scan up to 5 IP addresses and receive detailed information about identified vulnerabilities along with recommendations for remediation.

2. OPENVAS

OPENVAS is an open-source vulnerability scanner developed by Greenbone. It can detect a wide range of security vulnerabilities and supports multiple types of scans, including authenticated and unauthenticated scans, among other assessment methods used for vulnerability detection. One limitation of OpenVAS is that its scanning capacity depends on the appliance model and the available system resources.

3. Nmap

Nmap, short for Network Mapper, is a network discovery and security auditing tool. It can be used to identify devices running on a network, discover open ports and services, and detect potential vulnerabilities. To perform vulnerability detection, Nmap uses the vulners NSE (Nmap Scripting Engine) script. For each detected CPE (Common Platform Enumeration), the script lists known vulnerabilities, provides links to the corresponding vulnerability information, and displays their associated CVSS scores.

Why Is Vulnerability Management Important?

So far this year, 36,141 CVEs have been published, averaging 199 new vulnerabilities per day. In 2025, a total of 48,167 CVEs were published, with an average of 132 per day. According to IBM, the average cost of a data breach has reached $4.4 million worldwide. Some critical vulnerabilities are now exploited within hours of being disclosed, rather than days as was more common in the past. As a result, the window between vulnerability disclosure and patch deployment continues to shrink.

Additional Resources

References

[1] “Tipos de vulnerabilidades en ciberseguridad [2026] Inforges”. INFORGES. Accessed on July 11th, 2026. [Online]. Available: https://inforges.es/blog/tipos-de-vulnerabilidades-en-ciberseguridad/

[2] “Vulnerabilidades de ciberseguridad: prevención y mitigación”. SentinelOne. Accessed on July 11th, 2026. [Online]. Available: https://www.sentinelone.com/es/cybersecurity-101/cybersecurity/cyber-security-vulnerabilities/#-qu-son-las-vulnerabilidades-de-ciberseguridad

[3] “Niveles de gravedad de las incidencias de seguridad | Atlassian”. Atlassian. Accessed on July 11th, 2026. [Online]. Available: https://www.atlassian.com/es/trust/security/security-severity-levels

[4] “¿Qué es la gestión de vulnerabilidades? Mejores prácticas y desafíos”. Leading Cloud Enterprise Security Provider for Zero Trust. Accessed on July 11th, 2026. [Online]. Available: https://www.zscaler.com/es/zpedia/what-is-vulnerability-management#qu-es-el-ciclo-de-vida-de-la-gestin-de-vulnerabilidades

[5] “Gestión de vulnerabilidades: una guía práctica para equipos de TI y proveedores de servicios gestionados (MSP)”. Kaseya. Accessed on July 11th, 2026. [Online]. Available: https://www.kaseya.com/es-la/blog/vulnerability-management/

[6] IBM. “¿Qué es la gestión de vulnerabilidades? | IBM”. IBM. Accessed on July 11th, 2026. [Online]. Available: https://www.ibm.com/es-es/think/topics/vulnerability-management

[7] “¿Qué es la gestión de vulnerabilidades? | Tenable®”. Tenable®. Accessed on July 11th, 2026. [Online]. Available: https://es-la.tenable.com/principles/vulnerability-management-principles

[8] M. Kosinski. “¿Qué es el ciclo de vida de la gestión de vulnerabilidades? | IBM”. IBM. Accessed on July 11th, 2026. [Online]. Available: https://www.ibm.com/mx-es/think/topics/vulnerability-management-lifecycle

[9] “Ciclo de vida de la gestión de vulnerabilidades: una guía sencilla”. SentinelOne. Accessed on July 11th, 2026. [Online]. Available: https://www.sentinelone.com/es/cybersecurity-101/cybersecurity/vulnerability-management-lifecycle/

[10] “What is Vulnerability Management Lifecycle?” Pathlock. Accessed on July 11th, 2026. [Online]. Available: https://pathlock.com/blog/vulnerability-management-lifecycle/

[11] T. Khan y M. Goodwin. “What Is CVE (Common Vulnerabilities and Exposures)? | IBM”. IBM. Accessed on July 11th, 2026. [Online]. Available: https://www.ibm.com/think/topics/cve

[12] A. Gomstyn y A. Jonker. “¿Qué es el sistema de puntuación de vulnerabilidades comunes (CVSS)? | IBM”. IBM. Accessed on July 11th, 2026. [Online]. Available: https://www.ibm.com/mx-es/think/topics/cvss

[13] “What Is a Common Weakness Enumeration (CWE)?” JumpCloud. Accessed on July 11th, 2026. [Online]. Available: https://jumpcloud.com/it-index/what-is-a-common-weakness-enumeration-cwe

[14] “What is Common Platform Enumeration (CPE)? - Hexnode Blogs”. Hexnode Blogs. Accessed on July 11th, 2026. [Online]. Available: https://www.hexnode.com/blogs/explained/what-is-common-platform-enumeration-cpe/

[15] S. Ö. Hacıoğlu. “What Is Known Exploited Vulnerabilities Catalog (KEV)?” Picus Autonomous Exposure Validation Platform. Accessed on July 11th, 2026. [Online]. Available: https://www.picussecurity.com/resource/blog/what-is-kev-known-exploited-vulnerabilities-catalog

[16] “Exploit Prediction Scoring System (EPSS): How It Works and Why It Matters | Splunk”. Splunk. Accessed on July 11th, 2026. [Online]. Available: https://www.splunk.com/en\_us/blog/learn/epss-exploit-prediction-scoring-system.html

[17] “What is the National Vulnerability Database (NVD)? | Fortinet”. Fortinet. Accessed on July 11th, 2026. [Online]. Available: https://www.fortinet.com/resources/cyberglossary/national-vulnerability-database-nvd

[18] “What’s the Average Cost of a Data Breach in 2025? | Huntress”. Huntress. Accessed on July 11th, 2026. [Online]. Available: https://www.huntress.com/blog/average-cost-of-a-data-breach

[19] J. Krell. “Mean Time to Exploit Has Gone Negative. Security Strategy Has to Change.” AI Security Solutions & Offensive Cyber Expertise | Suzu Labs. Accessed on July 11th, 2026. [Online]. Available: https://suzulabs.com/suzu-labs-blog/mean-time-to-exploit-has-gone-negative.-security-strategy-has-to-change

[20] “CVE.ICU - CVE Analysis Dashboard”. CVE.ICU - CVE Analysis Dashboard. Accessed on July 11th, 2026. [Online]. Available: https://cve.icu/years.html

]]><![CDATA[¿Qué es Gestión de Vulnerabilidades, cómo funciona y por qué es importante?]]>https://vulnerability-management.hashnode.dev/qu-es-gesti-n-de-vulnerabilidades-c-mo-funciona-y-por-qu-es-importantehttps://vulnerability-management.hashnode.dev/qu-es-gesti-n-de-vulnerabilidades-c-mo-funciona-y-por-qu-es-importanteSat, 11 Jul 2026 23:41:42 GMT¿Qué es una vulnerabilidad?

Una vulnerabilidad corresponde a debilidades o problemas presentes en un sistema que hacen más probable que se materialice una amenaza. A su vez, una amenaza es algo que puede causar daños a los datos de un sistema u organización.

Tipos de Vulnerabilidades

Vulnerabilidades de Software

  • Debilidades no intencionales introducidas durante el proceso de desarrollo.

  • Ejemplos: corrupción de memoria, errores lógicos.

  • Específicos del lenguaje o independientes del lenguaje.

Errores de Configuración

  • Configuración incorrecta durante la instalación o mantenimiento como por ejemplo credenciales predeterminadas, privilegios excesivos o puertos innecesarios abiertos.

  • Usualmente son accidentales o debidos al incumplimiento de las mejores prácticas de seguridad.

Vulnerabilidades de Diseño

  • Corresponden a fallos estructurales o arquitectónicos.

  • Ejemplos: uso de algoritmos criptográficos débiles o falta de cifrado en tránsito o reposo.

Vulnerabilidades de Red

  • Las vulnerabilidades a nivel de red permiten al atacante acceder a la red interna.

  • Ejemplos: puertos y firewalls débiles.

Vulnerabilidades de Hardware

  • Dispositivos físicos como por ejemplo routers, servidores o dispositivos USB, que pueden tener vulnerabilidades en su diseño que los ciberdelincuentes aprovechan.

Vulnerabilidades Humanas

  • Corresponde a la mayor causa de vulnerabilidades de ciberseguridad.

  • Abrir enlaces de phishing, usar contraseñas fáciles de adivinar o falta de concientización son algunas de estas.

¿Qué es Gestión de Vulnerabilidades?

Gestión de vulnerabilidades corresponde a un proceso continuo y cíclico que permite a las organizaciones identificar, evaluar, priorizar y remediar debilidades y vulnerabilidades en la infraestructura de TI antes de que los atacantes puedan explotarlas.

Pasos Esenciales

Identificación – Hacer uso de escáneres de vulnerabilidades, técnicas manuales y métodos de descubrimiento de equipos para identificar y registrar los sistemas, junto con cualquier problema de seguridad que presenten.

Informes – Informar sobre estos problemas a las partes interesadas para que puedan abordarse y, finalmente, resolverse.

Corrección – El propietario del sistema o el responsable técnico corrigen los problemas de seguridad para que la vulnerabilidad deje de existir. Se pueden utilizar diferentes métodos para corregir las vulnerabilidades, como parches de seguridad, reconfiguraciones o controles de mitigación.

Reevaluación – Escanear o verificar manualmente para asegurar que los problemas de seguridad se hayan corregido correctamente.

Punto clave: Poder controlar los problemas de seguridad encontrados y asegurarse de que los productos se actualicen lo antes posible (normalmente después de las pruebas, para garantizar que no haya efectos no deseados derivados de la actualización) significa que los hackers tienen menos tiempo para intentar explotar las vulnerabilidades.

Ciclo de Vida de la Gestión de Vulnerabilidades

El ciclo de vida de gestión de vulnerabilidades consta de 5 pasos principales:

Paso Enfoque
Descubrimiento (Discovery) Identificar todos los activos (hardware + software) en el entorno.
Evaluación (Assessment) Detectar vulnerabilidades usando escáneres, pentesting, threat intelligence (como por ejemplo OSINT).
Priorización (Prioritization/Triage) Clasificar por riesgo usando gravedad + contexto organizacional.
Resolución (Resolution) Remediar, mitigar o aceptar el riesgo.
Verificación (Verification) Confirmar que la vulnerabilidad fue eliminada/mitigada; reevalorar.

Definición del Alcance para el Descubrimiento

  • Inventario de Activos (Asset Inventory) - Es una lista completa de activos de hardware + software.

  • Métodos de Creación:

    • Manual: Hoja de cálculo, recorriendo redes (orgs pequeñas, consume tiempo).

    • Automatizado: Herramientas de gestión de activos, escaneo de red, agentes desplegados.

Métodos de Evaluación

  • Escáneres de Vulnerabilidades

    • Escáneres de Red (Network Scanners) – Identifican sistemas operativos, software y sus versiones, y posteriormente los comparan con bases de datos de vulnerabilidades conocidas.

    • Escáneres de Aplicaciones Web (Web Application Scanners) – Detectan vulnerabilidades comunes en aplicaciones web, como Cross-Site Scripting (XSS), Path Traversal y ataques de inyección (por ejemplo, SQL Injection).

    • Análisis Estático de Código (SAST - Static Application Security Testing) – Analiza el código fuente para identificar patrones de programación inseguros, credenciales o secretos embebidos (hardcoded secrets) y otras debilidades de seguridad antes del despliegue.

    • Evaluación de Configuración (Configuration Assessment) – Detecta configuraciones inseguras en entornos como Active Directory, plataformas en la nube (AWS, Azure y GCP) y sistemas operativos, comparando la configuración con estándares de seguridad como los CIS Benchmarks y otras buenas prácticas.

  • Pruebas de Penetración (Penetration Testing)

    • Consisten en un ciberataque simulado y autorizado diseñado para identificar vulnerabilidades que pueden ser explotadas por un atacante.

    • Proporcionan una perspectiva diferente a la de los escáneres automatizados, ya que validan si una vulnerabilidad puede explotarse en un entorno real.

    • Permiten verificar la efectividad de las acciones de remediación y de los controles compensatorios implementados.

    • Requieren autorización explícita antes de su ejecución. En entornos de nube, dependiendo del alcance y del tipo de pruebas, también puede ser necesario obtener la aprobación del proveedor del servicio en la nube.

Priorización (Prioritization/Triage)

No basarse solo en el score CVSS — es importante incluir el contexto organizacional.

Dos Consideraciones Clave

  1. Probabilidad de Explotación - Los factores que aumentan la probabilidad de que una vulnerabilidad sea explotada incluyen:

    • La existencia de un proof of concept (PoC) o un exploit disponible públicamente (por ejemplo, en Exploit Database o GitHub).

    • Que la vulnerabilidad se encuentre en el catálogo CISA Known Exploited Vulnerabilities (KEV).

    • Puntaje alto en el Exploit Prediction Scoring System (EPSS), lo que indica una mayor probabilidad de que la vulnerabilidad sea explotada en entornos reales.

  2. Impacto Potencial si es Explotada - Se deben evaluar las consecuencias de una explotación exitosa, incluyendo:

    • Impacto inmediato, como el compromiso de un sistema o la interrupción de un servicio.

    • Impacto diferido o encadenado, cuando la vulnerabilidad puede combinarse con otras para aumentar su impacto.

    • Exposición de datos, interrupción del servicio, escalamiento de privilegios u otras consecuencias críticas para el negocio

Categorización de Vulnerabilidades

Una vez que las vulnerabilidades han sido evaluadas y priorizadas, normalmente se clasifican en una de las siguientes categorías:

  • Corregir Inmediatamente – Vulnerabilidades de alta prioridad que requieren una acción inmediata.

  • Reconocer pero diferir – Vulnerabilidades cuyo riesgo se acepta de forma temporal y cuya remediación se programa para una fecha posterior.

  • Requiere Investigación Adicional – Vulnerabilidades que necesitan un análisis más profundo antes de determinar el curso de acción más adecuado.

Opciones de Resolución

Opción Descripción
Remediar (Remediate) Eliminar completamente la vulnerabilidad mediante la aplicación de un parche de seguridad, una actualización de software, un cambio de configuración u otra solución permanente.
Mitigar (Mitigate) Reducir la probabilidad o el impacto de la explotación sin eliminar por completo la vulnerabilidad (por ejemplo, implementando reglas de firewall, segmentación de red, deshabilitando servicios vulnerables o aplicando controles compensatorios).
Aceptar (Accept) Reconocer y aceptar formalmente el riesgo cuando la remediación o la mitigación no sean viables. La aceptación del riesgo debe documentarse, ser aprobada por las partes interesadas correspondientes y revisarse periódicamente, ya que normalmente se considera una medida temporal.

Frameworks y Estándares Para Priorización

1. CVE (Common Vulnerabilities and Exposures)

Sistema de identificación único y universal para vulnerabilidades conocidas públicamente. Cada vulnerabilidad recibe un ID único en formato CVE-YYYY-NNNNN que permite que vendedores, herramientas y organizaciones hablen el mismo idioma. Mantenido por MITRE Corporation (financiado por gobierno EE.UU.).

  • Opera mediante CNAs (CVE Numbering Authorities): organizaciones autorizadas para asignar IDs. Actualmente existen más de 300 CNAs distribuidos globalmente, incluyendo vendors principales, coordinadores de seguridad e investigadores certificados.

  • Uso en priorización - Permite buscar información verificable sobre una vulnerabilidad específica, consultar si hay parches disponibles y verificar si está siendo explotada activamente. Sin CVE ID, diferentes herramientas reportan la misma vulnerabilidad con nombres distintos, causando confusión y duplicación de esfuerzos. Es la clave para buscar en bases de datos de exploits públicos y coordinar respuesta entre equipos.

2. CVSS (Common Vulnerability Scoring System)

Es un framework estandarizado para evaluar severidad de vulnerabilidades mediante puntuación numérica de 0.0 (sin impacto) a 10.0 (crítico). Mantenido por FIRST (Forum of Incident Response and Security Teams).

  • Calcula el score usando 8 métricas base: Attack Vector (desde dónde), Attack Complexity (dificultad), Privileges Required (autenticación), User Interaction (intervención humana), Scope (cruza límites), Confidentiality/Integrity/Availability impact. También incluye métricas Temporales (cambian con el tiempo) y de Entorno (contexto organizacional).

  • Métricas de Explotabilidad

    • Attack Vector (AV): Desde dónde se ataca - Network (remoto)/Adjacent (red local)/Local (acceso local)/Physical (acceso físico).

    • Attack Complexity (AC): Dificultad técnica - Low (fácil, sin condiciones especiales)/High (requiere configuración compleja).

    • Privileges Required (PR): Autenticación necesaria - None (sin auth)/Low (usuario básico)/High (admin/root).

    • User Interaction (UI): Intervención humana requerida - None (totalmente automatizado)/Required (usuario debe hacer algo).

  • Métricas de Impacto - Miden el daño causado (CIA Triad + Scope)

    • Scope (S): ¿El exploit cruza límites de seguridad? - Unchanged (impacto dentro del mismo componente)/Changed (impacto cruza a otros componentes).

    • Confidentiality (C): Exposición de datos - None/Low (acceso limitado)/High (acceso completo).

    • Integrity (I): Modificación de datos - None/Low (modificación limitada)/High (control completo).

    • Availability (A): Denegación de servicio - None/Low (degradación)/High (sistema completamente caído).

  • Uso en priorización - Proporciona evaluación técnica estandarizada de severidad base. CRÍTICO: NO usar solo CVSS. Mide severidad técnica teórica, NO riesgo real. CVSS 9.0 en sistema aislado puede ser menos prioritario que CVSS 7.0 en servidor público crítico. Siempre complementar con contexto organizacional: criticidad del activo, exposición real, datos manejados, impacto al negocio.

  • Limitación principal - Mide impacto técnico, ignora probabilidad de explotación y el contexto organizacional.

3. CWE (Common Weakness Enumeration)

Sistema de clasificación que describe TIPOS o CLASES de vulnerabilidades, no vulnerabilidades individuales. Explica causas raíz y naturaleza fundamental de debilidades de seguridad. Es mantenido por MITRE Corporation.

  • Organiza debilidades en jerarquía de 4 niveles:

    • Pillar: Categorías muy amplias (ej: Access Control).

    • Class: Tipos generales (ej: Improper Authorization).

    • Base: Identificables en código específico.

    • Variant: Específicos a plataforma/lenguaje.

  • Diferencia con CVE

    • CVE: Instancia específica de vulnerabilidad en producto/versión particular.

    • CWE: Categoría abstracta del problema subyacente que puede manifestarse en múltiples productos.

  • Uso en priorización - Identifica patrones sistémicos de vulnerabilidades recurrentes. Si múltiples CVEs en tu entorno mapean al mismo CWE, indica problema estructural que requiere solución fundamental más allá del parcheo individual: capacitación de developers, revisión de prácticas de desarrollo, implementación de análisis estático, o cambios arquitectónicos. Esencial para análisis de causa raíz.

4. CPE (Common Platform Enumeration)

Es un esquema de nomenclatura estandarizado para identificar productos de software y hardware de forma única. Elimina ambigüedad en nombres de productos que pueden tener múltiples representaciones textuales ("Apache Web Server" vs "httpd" vs "Apache HTTP Server"). Creado y mantenido por el NIST (National Institute of Standards and Technology).

  • Formato que utilizan - URI estructurado con 11 componentes: cpe:2.3:part:vendor:product:version:update:edition:language:sw_edition:target_sw:target_hw:other

    • Ejemplo: cpe:2.3:a:apache:http_server:2.4.49:*:*:*:*:*:*:*

  • Uso en priorización - Permite búsquedas precisas de vulnerabilidades por producto/versión en bases de datos como NVD. Escáneres automatizados usan CPE internamente para matchear software detectado con CVEs conocidos. Fundamental para automatización: sin CPE, sería necesario mapeo manual entre nombres y vulnerabilidades. Esencial para inventario de activos y Software Bill of Materials (SBOM).

  • Limitación principal - CPEs creados manualmente por analistas (pueden tener errores). Software muy nuevo puede no tener CPE asignado. Algunos productos tienen múltiples representaciones CPE válidas.

5. CISA KEV (Known Exploited Vulnerabilities Catalog)

Catálogo autoritativo de vulnerabilidades con evidencia confiable y verificada de explotación ACTIVA en ataques reales. Creado por CISA (Cybersecurity and Infrastructure Security Agency - gobierno EE.UU.). Se basa en inteligencia de amenazas, reportes de incidentes y análisis de campañas maliciosas.

  • Establece fechas límite OBLIGATORIAS de remediación para agencias federales estadounidenses. Por lo cual, KEV se convierte en un requisito de compliance para sector público de Estados Unidos.

  • Uso en priorización - Si una vulnerabilidad aparece en KEV, existe evidencia confirmada de explotación activa por actores maliciosos reales. Remediar inmediatamente independientemente del score CVSS, criticidad del sistema o disponibilidad de workarounds. La explotación activa significa que la ventana para prevenir compromiso se cierra rápidamente.

Aunque es obligatorio solo para agencias federales de Estados Unidos, organizaciones privadas y de otros países deben usarlo como indicador de amenaza inminente. Si atacantes explotan contra el gobierno, en algún momento se podrán mover hacia el sector privado.

6. EPSS (Exploit Prediction Scoring System)

Sistema de scoring probabilístico basado en machine learning que predice la PROBABILIDAD (0% a 100%) de que una vulnerabilidad sea explotada en los próximos 30 días. Creado por el FIRST (Forum of Incident Response and Security Teams). Analiza múltiples señales como la disponibilidad de código de exploit público, menciones en listas de correo de seguridad, discusiones en redes sociales, actividad en repositorios de código, tendencias históricas de explotación. Modelo entrenado continuamente con datos históricos.

A diferencia de CVSS (estático), EPSS cambia diariamente según evoluciona el panorama de amenazas. Una vulnerabilidad puede tener EPSS bajo inicialmente pero subir si se publica exploit funcional.

  • Complemnento del CVSS:

    • CVSS responde: "¿Qué tan malo sería si fuera explotado?" (Impacto)

    • EPSS responde: "¿Qué tan probable es que sea explotado pronto?" (Probabilidad)

    • Fórmula: Riesgo Real = Impacto (CVSS) × Probabilidad (EPSS)

  • Uso en priorización - Permite priorización basada en riesgo real cuando recursos son limitados. CVSS 9.0 + EPSS 0.1% = menos riesgo inmediato que CVSS 7.0 + EPSS 95%. Maximiza reducción de riesgo por unidad de esfuerzo atacando primero alta probabilidad de explotación.

7. NVD (National Vulnerability Database)

Base de datos comprensiva que enriquece entradas CVE básicas con análisis detallado y contexto adicional. Mantenido por el NIST (National Institute of Standards and Technology - gobierno EE.UU.). Permite filtrar por: producto específico (CPE), rango de severidad (CVSS), tipo de debilidad (CWE), fecha de publicación, vendor, o combinaciones múltiples.

  • Valor agregado sobre CVE.org:

    • Scores CVSS oficiales calculados por analistas NIST

    • Mapeos a CWE (tipo de debilidad)

    • CPEs afectados (productos/versiones)

    • Timelines detalladas (descubrimiento-publicación-patch)

    • Configuraciones específicas de explotabilidad

    • Historial de cambios

  • Uso en priorización - Fuente centralizada para investigación detallada de vulnerabilidades identificadas (vía escáneres o pentesting). Consultar score CVSS oficial, entender tipo de debilidad (CWE), verificar versiones afectadas exactas, encontrar parches/workarounds, comprender vector de ataque. API permite automatización crítica: dashboards, alertas automáticas para nuevos CVEs en productos de tu inventario, reportes de compliance.

Herramientas Útiles en Gestión de vulnerabilidades

Ejemplos de herramientas que se pueden utilizar para aprender sobre gestión de vulnerabilidades, algunas son open-source y otras tiene versiones gratuitas de prueba.

1. Nessus Essentials

Nessus Essentials es un producto gratuito de Tenable que permite realizar una evaluación de vulnerabilidades a través de una licencia de 30 días, diseñada específicamente para uso personal o no comercial. Es ideal para evaluaciones a corto plazo, pruebas de concepto (PoC) o para proteger una red doméstica pequeña. No está diseñado para entornos empresariales o de producción. Con esta licencia, se pueden escanear hasta 5 direcciones IP y obtener información detallada sobre vulnerabilidades y recomendaciones para su corrección.

2. OPENVAS

OPENVAS es un escáner de vulnerabilidades creado por Greenbone. Este escáner puede detectar varidad de vulnerabilidades. Permite realizar varios tipos de escaneos como por ejemplo autenticados y no auntenticados, entre otros tipos de pruebas que sirven para la detección de vulnerabilidades. Una limitación de OPENVAS SCAN es que su capacidad de escaneo depende del modelo del appliance y de sus recursos.

3. Nmap

Nmap es la abreviatura de "Network Mapper". Permite encontrar qué dispositivos se están ejecutando en su red local, detectar vulnerabilidades y descubrir puertos y servicios abiertos. Para poder detectar vulnerabilidades se debe hacer uso del script llamado vulners, para cada CPE disponible, el script imprime las vulnerabilidades conocidas (con enlaces a la información correspondiente) y sus puntuaciones CVSS.

¿Por qué es Importante la Gestión de Vulnerabilidades?

En lo que va del presente año, se han publicado 36,141 CVEs, lo cual corresponde a un promedio de 199 por día. En el 2025 se publicaron 48.167 CVEs, con un promedio de 132 por día. Según los datos de IBM, el costo promedio de una brecha de seguridad ha alcanzado los $4,4 millones a nivel mundial. Algunas vulnerabilidades críticas son explotadas en cuestión de horas, no días como solía ser anteriormente. El tiempo entre el descubrimiento y el patch es cada vez más corto.

Recursos Adicionales

Referencias

[1] “Tipos de vulnerabilidades en ciberseguridad [2026] Inforges”. INFORGES. Accedido el 11 de julio de 2026. [En línea]. Disponible: https://inforges.es/blog/tipos-de-vulnerabilidades-en-ciberseguridad/

[2] “Vulnerabilidades de ciberseguridad: prevención y mitigación”. SentinelOne. Accedido el 11 de julio de 2026. [En línea]. Disponible: https://www.sentinelone.com/es/cybersecurity-101/cybersecurity/cyber-security-vulnerabilities/#-qu-son-las-vulnerabilidades-de-ciberseguridad

[3] “Niveles de gravedad de las incidencias de seguridad | Atlassian”. Atlassian. Accedido el 11 de julio de 2026. [En línea]. Disponible: https://www.atlassian.com/es/trust/security/security-severity-levels

[4] “¿Qué es la gestión de vulnerabilidades? Mejores prácticas y desafíos”. Leading Cloud Enterprise Security Provider for Zero Trust. Accedido el 11 de julio de 2026. [En línea]. Disponible: https://www.zscaler.com/es/zpedia/what-is-vulnerability-management#qu-es-el-ciclo-de-vida-de-la-gestin-de-vulnerabilidades

[5] “Gestión de vulnerabilidades: una guía práctica para equipos de TI y proveedores de servicios gestionados (MSP)”. Kaseya. Accedido el 11 de julio de 2026. [En línea]. Disponible: https://www.kaseya.com/es-la/blog/vulnerability-management/

[6] IBM. “¿Qué es la gestión de vulnerabilidades? | IBM”. IBM. Accedido el 11 de julio de 2026. [En línea]. Disponible: https://www.ibm.com/es-es/think/topics/vulnerability-management

[7] “¿Qué es la gestión de vulnerabilidades? | Tenable®”. Tenable®. Accedido el 11 de julio de 2026. [En línea]. Disponible: https://es-la.tenable.com/principles/vulnerability-management-principles

[8] M. Kosinski. “¿Qué es el ciclo de vida de la gestión de vulnerabilidades? | IBM”. IBM. Accedido el 11 de julio de 2026. [En línea]. Disponible: https://www.ibm.com/mx-es/think/topics/vulnerability-management-lifecycle

[9] “Ciclo de vida de la gestión de vulnerabilidades: una guía sencilla”. SentinelOne. Accedido el 11 de julio de 2026. [En línea]. Disponible: https://www.sentinelone.com/es/cybersecurity-101/cybersecurity/vulnerability-management-lifecycle/

[10] “What is Vulnerability Management Lifecycle?” Pathlock. Accedido el 11 de julio de 2026. [En línea]. Disponible: https://pathlock.com/blog/vulnerability-management-lifecycle/

[11] T. Khan y M. Goodwin. “What Is CVE (Common Vulnerabilities and Exposures)? | IBM”. IBM. Accedido el 11 de julio de 2026. [En línea]. Disponible: https://www.ibm.com/think/topics/cve

[12] A. Gomstyn y A. Jonker. “¿Qué es el sistema de puntuación de vulnerabilidades comunes (CVSS)? | IBM”. IBM. Accedido el 11 de julio de 2026. [En línea]. Disponible: https://www.ibm.com/mx-es/think/topics/cvss

[13] “What Is a Common Weakness Enumeration (CWE)?” JumpCloud. Accedido el 11 de julio de 2026. [En línea]. Disponible: https://jumpcloud.com/it-index/what-is-a-common-weakness-enumeration-cwe

[14] “What is Common Platform Enumeration (CPE)? - Hexnode Blogs”. Hexnode Blogs. Accedido el 11 de julio de 2026. [En línea]. Disponible: https://www.hexnode.com/blogs/explained/what-is-common-platform-enumeration-cpe/

[15] S. Ö. Hacıoğlu. “What Is Known Exploited Vulnerabilities Catalog (KEV)?” Picus Autonomous Exposure Validation Platform. Accedido el 11 de julio de 2026. [En línea]. Disponible: https://www.picussecurity.com/resource/blog/what-is-kev-known-exploited-vulnerabilities-catalog

[16] “Exploit Prediction Scoring System (EPSS): How It Works and Why It Matters | Splunk”. Splunk. Accedido el 11 de julio de 2026. [En línea]. Disponible: https://www.splunk.com/en\_us/blog/learn/epss-exploit-prediction-scoring-system.html

[17] “What is the National Vulnerability Database (NVD)? | Fortinet”. Fortinet. Accedido el 11 de julio de 2026. [En línea]. Disponible: https://www.fortinet.com/resources/cyberglossary/national-vulnerability-database-nvd

[18] “What’s the Average Cost of a Data Breach in 2025? | Huntress”. Huntress. Accedido el 11 de julio de 2026. [En línea]. Disponible: https://www.huntress.com/blog/average-cost-of-a-data-breach

[19] J. Krell. “Mean Time to Exploit Has Gone Negative. Security Strategy Has to Change.” AI Security Solutions & Offensive Cyber Expertise | Suzu Labs. Accedido el 11 de julio de 2026. [En línea]. Disponible: https://suzulabs.com/suzu-labs-blog/mean-time-to-exploit-has-gone-negative.-security-strategy-has-to-change

[20] “CVE.ICU - CVE Analysis Dashboard”. CVE.ICU - CVE Analysis Dashboard. Accedido el 11 de julio de 2026. [En línea]. Disponible: https://cve.icu/years.html

]]>