Skip to main content

​
Descripción general

Cerrar un hallazgo es un registro de auditoría permanente. Un comentario como “falso positivo” o “riesgo aceptado” solo repite la decisión que ya quedó registrada en el estado, así que quien lea el hallazgo meses después —un compañero de equipo, una nueva persona responsable o alguien que audita— no aprende nada de él. Corgea revisa el comentario que escribes al cambiar el estado de un hallazgo y vuelve a pedirlo cuando no explica la decisión. El listón es bajo: basta con una frase concreta que alguien pueda comprobar.
El requisito de justificación afecta al comentario de un cambio de estado. No cambia quién puede cambiar un estado, que sigue estando controlado por el permiso change_issue_status. Consulta Grupos de permisos.

​
Dónde se aplica

La revisión se ejecuta en todos los lugares donde se registra un cambio de estado:
  • El modal Change Decision de la página de detalles del hallazgo
  • El panel de detalles del Workbench de vulnerabilidades
  • La barra de acciones de triaje masivo, incluidos los hallazgos de SAST, SCA e IaC
  • Los descartes solicitados desde una pull request mediante el Corgea Agent
Reabrir un hallazgo está exento. Reabrir no descarta nada, así que no tiene requisito de justificación.

​
Qué hace buena a una justificación

Una justificación se acepta cuando menciona al menos algo concreto que alguien pueda verificar. Basta con cualquiera de estos puntos:
  • El control que hace seguro el código: validación de entrada, escapado de salida, una consulta parametrizada, una comprobación de autorización o una garantía del framework
  • Por qué la entrada es de confianza o la ruta es inalcanzable en este despliegue
  • Un control compensatorio o una razón de negocio para asumir el riesgo, idealmente con responsable, plazo o alcance
  • Dónde se aplicó la corrección, o a qué hallazgo duplica este: un commit, una pull request, un ticket o un ID de hallazgo
  • Qué interpretó mal el escáner en el código
Ejemplos que se aceptan:

​
Qué se rechaza

Un comentario se devuelve cuando no añade nada a la decisión en sí: Cuando se rechaza un comentario, Corgea explica qué falta y conserva lo que escribiste para que puedas completarlo. El estado no cambia hasta que se acepta el comentario.
La misma frase seguida de una razón real sí vale. “Falso positivo: la plantilla escapa el valor antes de renderizarlo” se acepta; “falso positivo” por sí solo, no.

​
Por qué Corgea nunca rechaza

La revisión comprueba si se da una razón, no lo bien redactada que está.
Una justificación nunca se rechaza por su longitud, ortografía, gramática, tono informal ni por el idioma en que está escrita. Las justificaciones escritas en cualquier idioma se revisan en igualdad de condiciones. Corgea tampoco juzga si tu razonamiento es técnicamente correcto —ese criterio sigue siendo de tu equipo— y acepta el comentario cuando tiene dudas.
Si la revisión no está disponible, el comentario se acepta y el cambio de estado se aplica. El triaje nunca se bloquea porque la revisión esté caída.

​
Cerrar un hallazgo desde una pull request

El Corgea Agent escribe el mismo registro de auditoría cuando actúa sobre un comentario de una pull request, así que pide la misma razón. Un comentario que pide descartar un hallazgo sin decir por qué —@Corgea false positive, accept risk, not an issue, wontfix— recibe una respuesta pidiendo la razón en lugar de un cambio de estado. Incluye la razón en el comentario y el agente la registra:
Una razón que ya diste antes en el mismo hilo cuenta. Esto se aplica a los descartes —falso positivo y riesgo aceptado— porque cierran un hallazgo real. Marcar un hallazgo como corregido o duplicado desde una pull request no cambia.

​
Exigir una segunda revisión

Una justificación explica una decisión, pero por sí sola nadie la comprueba. Los administradores de la empresa también pueden exigir que una segunda persona apruebe un descarte antes de que surta efecto. Actívalo en Settings → Company → Triage approvals (abrir). La página tiene dos interruptores independientes, ambos desactivados por defecto:
  • False positive: descartar un hallazgo como falso positivo queda pendiente de aprobación.
  • Accepted risk: suprimir un hallazgo como riesgo aceptado queda pendiente de aprobación, con o sin fecha de expiración.
Con una decisión activada, tomarla desde la página de detalles del hallazgo, el panel del workbench o la barra de triaje masivo crea una solicitud en lugar de cambiar el estado. El hallazgo mantiene el estado que tiene y aparece como Pending approval hasta que alguien la revisa. Tu justificación viaja con la solicitud: es lo que lee quien revisa.

​
Revisar solicitudes

La revisión se hace desde la cola de aprobaciones en /approvals/, con las pestañas Pending, Approved, Rejected y Withdrawn. Puedes filtrar por decisión, proyecto y solicitante, acotar a Everyone, Waiting on me o Mine, y buscar por CWE, CVE, ruta, proyecto, justificación, nota de revisión y solicitante. Los filtros van en la cadena de consulta, así que una vista filtrada se puede compartir como enlace. Quien revisa debe ser una persona distinta de quien solicita, de la misma empresa, con permiso para aprobar solicitudes de triaje y para cambiar todos los tipos de hallazgo incluidos en la solicitud. Aprobar o rechazar admite una nota opcional, y quien solicita puede retirar sus propias solicitudes.
Quienes pueden aprobar solicitudes están exentos de su propio control: poner su decisión en la cola solo les pediría aprobarse a sí mismos, así que se aplica de inmediato. Los administradores de la empresa ven todas las solicitudes de la cola; el resto solo ve las que ha enviado.
Cada paso —la solicitud, la aprobación o el rechazo, cualquier nota de revisión y una retirada— queda registrado en el historial del hallazgo.