{"id":3533,"date":"2026-08-31T10:17:37","date_gmt":"2026-08-31T14:17:37","guid":{"rendered":"https:\/\/orendasecurity.com\/?p=3533"},"modified":"2026-08-31T10:18:56","modified_gmt":"2026-08-31T14:18:56","slug":"despues-informe-pentesting","status":"publish","type":"post","link":"https:\/\/orendasecurity.com\/es\/blog\/despues-informe-pentesting\/","title":{"rendered":"Despu\u00e9s del informe de pentesting: la gu\u00eda pr\u00e1ctica para el triaje, la remediaci\u00f3n y el retest"},"content":{"rendered":"

Resumen:<\/strong> Menos de la mitad de todos los hallazgos de un pentest llegan a corregirse, y hasta los m\u00e1s cr\u00edticos permanecen abiertos m\u00e1s de un mes despu\u00e9s de vencido su SLA. El informe nunca fue el entregable que importaba. Lo que se hace con \u00e9l, eso es lo que importa. Este es un marco pr\u00e1ctico para clasificar hallazgos, priorizar correcciones y cerrar el ciclo con un retest real, no solo otro escaneo anual.<\/p>\n

La mayor\u00eda de las organizaciones trata un informe de pentesting como la l\u00ednea de meta. El PDF llega, se abren algunos tickets, y la atenci\u00f3n vuelve a la hoja de ruta, hasta que el siguiente test anual revela la mitad de los mismos hallazgos bajo un nuevo CVE.<\/p>\n

Los datos lo confirman. Solo el 48 % de las vulnerabilidades identificadas se llega a remediar, e incluso los hallazgos m\u00e1s severos alcanzan apenas un 69 % de tasa de correcci\u00f3n, dejando alrededor de un tercio del riesgo de mayor nivel sin resolver, con un tiempo mediano de resoluci\u00f3n de 37 d\u00edas frente a un SLA t\u00edpico de dos semanas. La brecha es m\u00e1s amplia en los hallazgos de IA\/LLM: aparecen a una tasa m\u00e1s de 2,5 veces superior a la de otros hallazgos, pero solo se corrigen el 38 % de las veces, la tasa m\u00e1s baja de cualquier tipo de activo.<\/p>\n

Nada de esto es un problema de testing. Es un problema de remediaci\u00f3n, y es solucionable con un proceso estructurado aplicado despu\u00e9s de cada compromiso.<\/p>\n

Por qu\u00e9 se estancan los hallazgos<\/h2>\n

Antes de corregir el proceso, ayuda identificar d\u00f3nde se rompe realmente. En la pr\u00e1ctica, rara vez es un solo fallo dram\u00e1tico. Es un pu\u00f1ado de peque\u00f1as brechas que se acumulan:<\/p>\n

La deduplicaci\u00f3n nunca ocurre<\/h3>\n

Un test de aplicaci\u00f3n web y un test de API revelan la misma falla de autorizaci\u00f3n subyacente desde dos \u00e1ngulos distintos. Sin cruce de referencias, aparece como dos tickets, se corrige parcialmente una vez, y reaparece en el siguiente test.<\/p>\n

La propiedad es ambigua<\/h3>\n

Un hallazgo en una biblioteca de terceros queda entre el equipo de ingenier\u00eda que la incorpor\u00f3 y el equipo de seguridad que lo se\u00f1al\u00f3. Ninguno de los dos se hace cargo de la correcci\u00f3n, as\u00ed que ninguno lo prioriza.<\/p>\n

La severidad se aplana<\/h3>\n

Una puntuaci\u00f3n CVSS por s\u00ed sola no le dice a un l\u00edder de ingenier\u00eda si un hallazgo es realmente alcanzable en producci\u00f3n, o te\u00f3rico. Todo lo que supera \u00abMedio\u00bb termina en la misma cola indiferenciada.<\/p>\n

No hay un ciclo de retest<\/h3>\n

El hallazgo se marca como \u00abresuelto\u00bb a partir de un cambio de c\u00f3digo, no de una prueba de verificaci\u00f3n. Se despliega, y la correcci\u00f3n se revierte silenciosamente seis meses despu\u00e9s.<\/p>\n

Cada uno de estos es un problema de proceso, no t\u00e9cnico, lo que significa que cada uno se puede resolver sin nuevas herramientas.<\/p>\n

Un marco de triaje que realmente prioriza<\/h2>\n

Reemplace la \u00abseveridad\u00bb como \u00fanica variable de clasificaci\u00f3n por un enfoque de tres partes aplicado a cada hallazgo:<\/p>\n

    \n
  1. Explotabilidad.<\/strong> \u00bfEs alcanzable por un atacante no autenticado, o requiere un punto de apoyo interno ya comprometido? Los hallazgos que su equipo de pentesting pudo efectivamente encadenar para lograr mayor acceso durante el compromiso deber\u00edan saltar la cola. Esa es una se\u00f1al que ninguna puntuaci\u00f3n CVSS captura por completo.<\/li>\n
  2. Impacto en el negocio.<\/strong> \u00bfDelante de qu\u00e9 se encuentra este hallazgo? Un control de acceso roto en un endpoint de facturaci\u00f3n de clientes no representa el mismo riesgo que la misma falla en una herramienta de administraci\u00f3n interna usada por tres personas. Relacione los hallazgos con los datos o el sistema que exponen, no solo con su descripci\u00f3n t\u00e9cnica.<\/li>\n
  3. Costo de correcci\u00f3n.<\/strong> Algunos hallazgos de alta severidad son un cambio de configuraci\u00f3n de una sola l\u00ednea. Algunos hallazgos de severidad media requieren una reestructuraci\u00f3n arquitect\u00f3nica. Secuenciar primero las correcciones r\u00e1pidas de alto impacto genera impulso y cierra la exposici\u00f3n real m\u00e1s r\u00e1pido que trabajar estrictamente por una lista de severidad.<\/li>\n<\/ol>\n

    Punt\u00fae cada hallazgo en estas tres dimensiones y obtendr\u00e1 un orden de priorizaci\u00f3n que refleja la reducci\u00f3n de riesgo real por unidad de esfuerzo de ingenier\u00eda, no solo una lista ordenada seg\u00fan la opini\u00f3n de un esc\u00e1ner automatizado.<\/p>\n

    Cerrar el ciclo: construir un h\u00e1bito de retest, no solo un evento anual<\/h2>\n

    Una correcci\u00f3n que no ha sido retesteada es una hip\u00f3tesis, no una resoluci\u00f3n. Las organizaciones que cierran la brecha de remediaci\u00f3n tratan el retest como una parte permanente del compromiso, no como una decisi\u00f3n de compra separada tomada meses despu\u00e9s:<\/p>\n