Seguridad → Configuración contiene el Valor predeterminado de la organización y cada proyecto sigue esa configuración. Cada proyecto adopta el valor predeterminado hasta que alguien establece una configuración propia; Usar el valor predeterminado lo restaura. Los propietarios y administradores modifican la configuración; los miembros la ven en modo solo lectura.
Observar y aplicar
Cada protección tiene dos estados independientes:
- Observar: detectar, registrar y mostrar. Los hallazgos aparecen en Seguridad, y
Coroid Securityla comprobación en las solicitudes de incorporación de cambios los reporta sin causar fallos. - Aplicar: hacer que una comprobación falle. Un cambio que genere un hallazgo de la severidad establecida o superior hará que la comprobación falle, y las tareas de Coroid no abrirán una solicitud de incorporación de cambios más allá de ese punto.
La aplicación ofrece tres opciones por ámbito:
| Opción | Significado |
|---|---|
| Heredar (el valor predeterminado) | Aplicar una vez que la protección haya superado el criterio de disponibilidad de la plataforma. |
| Aplicar | Lo mismo, seleccionado explícitamente para este ámbito. |
| Solo observar | Nunca hacer que una comprobación falle, independientemente de lo que haga la plataforma. |
Todas las protecciones comienzan en modo observar. Coroid activa la aplicación por protección únicamente después de que esta haya superado su criterio de disponibilidad: para las dependencias, las pruebas de cobertura y un período de observación sin bloqueos incorrectos; para las reglas de secretos y código, la calibración descrita a continuación y el mismo período de observación. Hasta entonces, una protección configurada como Heredar o Aplicar opera en modo observar, y la configuración así lo indica. Una vez superado el criterio, todos los elementos con valor Heredar pasan a aplicar; quienes eligieron Solo observar continúan en modo observar.
Aplicar no equivale a "GitHub impide la fusión". GitHub bloquea una fusión
solo cuando el repositorio requiere la Coroid Security comprobación. Ver
Permisos de GitHub y la comprobación de Seguridad de Coroid.
Reglas calibradas
Las protecciones contra secretos filtrados y el análisis de código solo se aplican con versiones del detector que hayan superado la calibración: precisión y cobertura medidas sobre un conjunto etiquetado de código real y secretos sintéticos, tasa de bloqueos incorrectos determinada al reproducir cambios fusionados reales, cada error reportado se registra como caso que debe seguir aprobándose, y 14 días de observación sin bloqueos incorrectos.
Una nueva versión del detector nunca asume la aplicación por sí sola. La última versión aprobada sigue aplicando la protección mientras la nueva opera en modo observar junto a ella, y solo toma el control cuando su propia calibración sea exitosa. Si ninguna versión aprobada puede ejecutarse, una protección en modo aplicar informará que no está disponible y la comprobación fallará, en lugar de pasar sin verificación.
La configuración
| Protección | Conmutador | Ajustar |
|---|---|---|
| Dependencias vulnerables | Observar | Aplicación; "Aplicar a partir de" (valor predeterminado: alto) |
| Corregir dependencias vulnerables | Activado o desactivado | "Abrir trabajo de corrección a partir de" (valor predeterminado: alto); límite de pull request por proyecto para abrir correcciones (predeterminado: 5, máximo 50); presupuesto de horas del agente, según el valor predeterminado de la organización |
| Secretos filtrados | Observar | Aplicación. Solo en el valor predeterminado de la organización: bloquear nuevos secretos y el cambio más grande analizado |
| Análisis de código | Observar | Aplicación; su propio comando de análisis; la lista de reglas |
| Revisión de Seguridad en solicitudes de incorporación de cambios | Observar | Aplicación; "Aplicar a partir de" (valor predeterminado: alto) |
| Alertas de seguridad de GitHub | Observar | Ninguno |
| Auditoría de Seguridad | Activado o desactivado | Frecuencia: diaria, semanal (predeterminada) o mensual |
Algunas protecciones dependen de otros elementos:
- Revisión de Seguridad en solicitudes de incorporación de cambios necesita que Coroid tenga activada la Revisión en el proyecto en Control de Calidad. Si Coroid tiene desactivada la Revisión, la fila lo indicará y la protección no tendrá efecto.
- Corregir dependencias vulnerables en el valor predeterminado de la organización también activa o desactiva el mandato integrado de correcciones de Seguridad. Ver Corregir solicitudes de incorporación de cambios.
- Auditoría de Seguridad sigue su plan a menos que lo modifique: activada en planes de pago, desactivada en la versión Gratuita. Ver Auditoría de Seguridad.
Seguridad actúa según lo indicado por Control de Calidad.
Las protecciones de Seguridad no dependen de los controles del Control de Calidad. Al desactivar la función anti-slop en el Control de Calidad, se deshabilitan sus reglas de calidad y no las reglas de código de Seguridad. En las solicitudes de extracción, Coroid Security publica su propia comprobación, independientemente de si el proyecto tiene o no un gráfico de Entrega publicado.
La configuración del Escáner proviene de Coroid
Los Escáneres se ejecutan con la configuración Coroid generada a partir de estos parámetros y de las excepciones aceptadas en Seguridad, nunca a partir de archivos incluidos en el cambio en pruebas. Un cambio que agregue o modifique la configuración del escáner (osv-scanner.toml,
.gitleaks.toml, .gitleaksignore, .github/secret_scanning.yml,
.secrets.baseline y similares) se verifica bajo la configuración del commit base y obtiene un security.policy-changed hallazgo. Un archivo del repositorio puede proponer una excepción; esta solo se aplica una vez que un propietario o administrador la acepte en Seguridad. La misma regla se aplica a las tareas de corrección propias de Coroid: un agente no puede hacer que su propia comprobación sea aprobada modificando lo que está excluido.
La Configuración viaja junto con la organización
La security configuración forma parte del paquete de configuraciones de la organización, junto con las demás políticas de calidad, al igual que el último modelo de amenazas de cada proyecto. Las excepciones, hallazgos y evidencias son resultados, no configuraciones, y no viajan. Consulte Portabilidad de la configuración.