Documentación

Hallazgos y su ciclo de vida

Cómo Seguridad mantiene una única lista de hallazgos, cuándo se abren y cierran, si se corrigen en el código o donde se despliegan, y cómo funcionan las excepciones.

Seguridad → Hallazgos es la única lista de todo lo que detectó Seguridad, sin importar quién lo encontró. Cada origen escribe en el mismo almacén, y el mismo problema reportado por dos orígenes es un solo hallazgo.

Hallazgos, ocurrencias y orígenes

  • Un hallazgo es un problema específico en un repositorio: un paquete vulnerable, una credencial filtrada o un patrón de código vulnerable.
  • Sus ocurrencias indican dónde se encuentra: una ruta de manifiesto y dependencias, un archivo y línea, o el commit y ruta donde aparece un secreto. Dos versiones instaladas del mismo paquete son dos ocurrencias.
  • Sus orígenes indican quién lo vio, cuándo y con qué nivel de detalle: OSV-Scanner, GitHub Dependabot, escaneo de código de GitHub, escaneo de secretos de GitHub, escaneo de secretos de Coroid, reglas de código de Coroid, tu propio comando de escaneo, Coroid Revisión y la auditoría de seguridad.

La lista se agrupa por proyecto. Puedes filtrarla por proyecto, tipo, gravedad, estado, origen, divulgación y evidencia. Un hallazgo de dependencias se agrupa por paquete, junto con la actualización que lo corrige cuando existe.

Gravedad y fechas límite

Cada hallazgo tiene una fecha límite después de abrirse:

GravedadLímite para resolver
Crítico2 días
Alto7 días
Medio30 días
Bajo90 días

El Resumen cuenta los hallazgos que ya superaron su plazo y los que vencen en los próximos tres días.

Estados

EstadoSignificado
AbiertoPresente en la rama predeterminada.
Corregido en el códigoTodas las ocurrencias en la rama predeterminada han desaparecido, según un escaneo completo.
Rotación confirmadaUna credencial filtrada cuya rotación o revocación fue confirmada. Ver Secretos filtrados.
Ya no aplicaTodos los avisos relacionados con el hallazgo fueron retirados. Esto no significa que esté "corregido".
En un pull requestSolo se ve en un pull request. Pertenece a ese pull request, y el siguiente escaneo de la rama predeterminada lo detectará si el cambio se fusiona.

Sin resultados verdes silenciosos

Una ocurrencia solo deja de existir cuando un escaneo completo del encabezado actual lo indica. Un escaneo parcial, fallido, sin permisos o de un commit al que la rama ya pasó no cambia nada. La cobertura muestra cada caso:

  • Parcial: algunos archivos no pudieron leerse por completo; se nombran en la cobertura.
  • Obsoleto: el inventario no corresponde al encabezado actual de la rama predeterminada o tiene más de un día de antigüedad.
  • Desconocido desde…: un origen perdió sus permisos o no pudo leerse. Los hallazgos que solo él reportó muestran "estado desconocido desde" ese momento.
  • Retraso en la alimentación de avisos: ningún proyecto muestra cobertura limpia mientras dure este estado.

Los resultados se aplican en el orden en que Coroid observó los encabezados de las ramas, no por la fecha del commit. Si alguien hace un force-push de una rama a un commit anterior, el escaneo de ese commit será el resultado más reciente, y un resultado tardío de un encabezado que la rama ya dejó de usar no cambiará nada.

Corregido en el código y corregido donde se ejecuta

Fusionar una corrección no significa que esta se esté ejecutando. Seguridad registra ambos casos por separado:

  • Corregido en el código: la rama predeterminada ya no presenta el problema.
  • Por entorno: para cada entorno que indique qué ejecuta, Coroid escanea exactamente esa revisión. El hallazgo se considera corregido allí solo cuando el escaneo es completo y no lo detecta. Una reversión o rollback que vuelva a causar el problema reabrirá el hallazgo para ese entorno.

Los Entornos de un hallazgo muestran, para cada entorno, "En ejecución en producción", "Solo en el código" o "Despliegue desconocido". Despliegue desconocido significa que Coroid no ha observado una revisión para el entorno o aún no ha realizado un escaneo completo de este. Un proyecto sin seguimiento de despliegues indica: "Solo postura del repositorio: no se sigue ninguna revisión de despliegue." Para seguir los despliegues, ver Eventos de despliegue.

Resumen → El recuento de progreso de correcciones indica qué elementos siguen en ejecución en producción, qué ya se ha corregido en el código pero aún no se ha desplegado, qué aún no puede determinarse, las solicitudes de extracción de correcciones pendientes de revisión y el tiempo medio desde la detección hasta la fusión de la corrección y su despliegue.

Excepciones

Una excepción oculta un hallazgo de la lista abierta sin eliminarlo. Los propietarios y administradores pueden agregar una a un hallazgo:

TipoNecesidades
Aceptar riesgoUn motivo, la mayor severidad que se acepta y una fecha de caducidad futura.
No es un problema (falso positivo)Un motivo y la mayor severidad que se acepta. La fecha de caducidad es opcional.

El hallazgo reaparecerá cuando expire la excepción, cuando alguien la revoque o cuando la severidad del hallazgo supere lo que permite la excepción. Un aumento de severidad anula la excepción de forma permanente. Las observaciones que ocultó la excepción se conservan; además, se le asigna un nombre. Cada excepción queda registrada en el registro de auditoría de la organización.

Una credencial filtrada es diferente: solo se cierra cuando alguien certifica que se ha rotado o revocado. Consulte Secretos filtrados.

Acciones sobre un hallazgo

Desde un hallazgo, los propietarios y administradores pueden:

  • Corregir: abrir el trabajo de corrección correspondiente. Para un hallazgo de dependencia pública, una solicitud de extracción de corrección o una tarea de mitigación cuando no exista una versión corregida; para un hallazgo de código, una tarea de corrección; para un secreto filtrado, la lista de verificación de rotación. Consulte Solicitudes de extracción de correcciones.
  • Aceptar riesgo o marcarlo como No es un problema.
  • Seguir su tarea de corrección abierta y pull request.

Retención

Los hallazgos, sus ocurrencias y sus pruebas se conservan mientras el repositorio esté conectado. Cuando un repositorio se desconecta, se eliminan después de 30 días y se restauran si se reconecta dentro de ese plazo. Los datos de asesoramiento compartidos no son de su propiedad y se conservan. Las entradas de auditoría relativas a excepciones, certificaciones y divulgaciones siguen la política de retención del registro de auditoría.