> ## Documentation Index
> Fetch the complete documentation index at: https://docs.corgea.app/llms.txt
> Use this file to discover all available pages before exploring further.
# Justificaciones de triaje
> Exigir una razón al cerrar un hallazgo
## 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](/es/permission_groups).
## 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](/es/vulnerabilities)
* 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](/es/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:
```plaintext theme={null}
La consulta de la línea 44 está parametrizada; el valor del usuario se vincula, no se concatena.
Esta entrada es el claim del JWT firmado, validado en el middleware de autenticación antes de llegar a este handler.
Endpoint solo interno detrás de la VPN. Aceptado hasta la actualización a 2.0 del próximo trimestre, a cargo del equipo de plataforma.
Corregido en la PR #1421, que se integró después de este escaneo.
Duplicado del hallazgo 8c31; mismo sink, mismo commit.
```
## Qué se rechaza
Un comentario se devuelve cuando no añade nada a la decisión en sí:
| Patrón | Ejemplos |
| ------------------------------------------------------ | --------------------------------------------------------------------- |
| Repite o etiqueta la decisión | `false positive`, `accept risk`, `won't fix`, `fixed`, `duplicate` |
| Afirma una conclusión sin dar una razón | `not exploitable`, `this is safe`, `not a real issue`, `low priority` |
| Relleno, marcador de posición o texto sin sentido | `n/a`, `test`, `asdf`, `...`, `per policy`, `as discussed` |
| Nombra a quien aprueba o un proceso, pero no una razón | `approved by security`, `reviewed`, `ticket created` |
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](/es/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:
```plaintext theme={null}
@Corgea false positive, the query is parameterized on line 44
@Corgea accept risk until the 2.0 upgrade next quarter, this endpoint is internal-only
```
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](https://www.corgea.app/settings/company/triage-approvals/)). 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/](https://www.corgea.app/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.