Dos mecanismos protegen directamente el código: Análisis de código aplica reglas predefinidas en cada cambio y en la rama predeterminada, y Revisión de seguridad en solicitudes de extracción verifica los problemas de seguridad que detecta Coroid Review antes de que puedan hacer fallar un pull request.
Análisis de código
Las reglas de Coroid
El equipo de Seguridad gestiona estas reglas. Formaron parte de las medidas contra código inseguro en Control de Calidad y ahora se encuentran aquí, por lo que cada una tiene su ubicación específica:
| Regla | Busca |
|---|---|
security.hardcoded-secret | Credenciales escritas en el código. Consulta Secrets filtrados. |
security.tls-disabled | Desactivación de la verificación del certificado TLS. |
security.auth-removed | Eliminación o comentario de mecanismos de autenticación o autorización, decoradores o middleware. |
security.cors-wildcard-credentials | Permiso para cualquier origen junto con credenciales. |
security.sql-concat | Consultas SQL generadas a partir de cadenas interpoladas y pasadas a funciones de consulta. |
security.eval | Código ejecutado a partir de entradas: eval, new Function, sin sanitizar dangerouslySetInnerHTML. |
security.remote-script-exec | Scripts descargados y ejecutados directamente en un shell o intérprete. |
security.policy-changed | Cambios en la configuración del analizador. Consulta Protecciones y aplicación de normas. |
deps.nonexistent | Dependencias nuevas que no existen en su registro. |
deps.known-malicious | Dependencias nuevas con advertencia de paquete malicioso. |
deps.suspicious-new | Dependencias nuevas publicadas hace menos de 30 días, con muy pocas descargas, cuyo nombre difiere en una o dos letras de un paquete popular, o con cambio reciente de mantenedor. |
deps.install-script | Dependencias npm nuevas que ejecutan un script al instalarse. |
Las reglas de higiene de dependencias, versiones no fijas y desfases entre manifiestos y archivos de bloqueo permanecen en Control de Calidad como medidas contra código inseguro. Consulta Contra código inseguro.
Las reglas se aplican en los cambios, en el mismo análisis que la comprobación contra código inseguro de Control de Calidad, y en la rama predeterminada en cada envío y una vez al día, independientemente de si la opción contra código inseguro está activada. El equipo de Seguridad, no la configuración contra código inseguro, decide la acción de cada regla. En Seguridad → Configuración → Análisis de código se listan todas ellas. Hasta que el análisis de código empiece a aplicar las reglas, cada una mantendrá la acción que tenía en Control de Calidad; por ejemplo, una regla configurada para bloquear seguirá haciéndolo.
Tu propio comando de análisis
Si tu proyecto ya cuenta con un analizador de seguridad, introduce su comando en
Tu propio comando de análisis en la sección de Análisis de código. Se ejecuta como comprobación del proyecto
security_scan en cada cambio. Déjalo vacío para desactivarlo.
Los resultados de herramientas externas como SonarQube, Snyk o Semgrep también pueden llegar a Coroid como evidencia de revisión. Consulta Proveedores de evidencia de revisión.
Revisión de seguridad en solicitudes de extracción
Coroid Review revisa las solicitudes de extracción en Control de Calidad. Cuando detecta un problema de seguridad, no lo incluye en la revisión como texto descriptivo. Lo reporta como una afirmación estructurada: tipo de vulnerabilidad, archivo y líneas afectadas, y gravedad. El equipo de Seguridad registra cada afirmación como Aún no confirmado.
La comprobación independiente
Para afirmaciones críticas y de alta gravedad, Coroid realiza una comprobación independiente: un modelo separado y acotado que analiza el archivo mencionado en la afirmación, en el commit principal de pull request, y debe derivar el problema por sí mismo. Si lo consigue, la afirmación se convierte en un hallazgo estático validado. Si el código que determina el problema está en otro archivo, la comprobación no puede confirmarlo y la afirmación permanece sin confirmar.
Esta comprobación consume los créditos de tu organización como cualquier otra tarea de modelo, dentro de los límites establecidos para pull request. Cuando se agoten los créditos o horas, no se ejecutará y la revisión indicará: "No se pudo verificar un posible problema de seguridad: se han agotado los créditos o horas de la organización."
Qué hace que la revisión falle
| Observar | Aplicar | |
|---|---|---|
| Una afirmación confirmada de gravedad igual o superior al umbral (alta por defecto) | Neutro, "Hallazgo confirmado" | La comprobación de Coroid Review falla, "Hallazgo confirmado" |
| Una afirmación que no está confirmada | Nunca falla | Nunca falla |
Una afirmación crítica o de alta gravedad, confirmada y con la opción de aplicación activada, hace fallar a Coroid Review incluso cuando la revisión está configurada como consultiva en Control de Calidad. Esta es la única excepción a que las revisiones consultivas nunca fallen. Una revisión que solicita cambios solo debido a afirmaciones de seguridad no confirmadas se considera consultiva.
La revisión de seguridad requiere que Coroid Review esté activado para el proyecto. Si Coroid Review está desactivado, así se indicará en la fila correspondiente en Seguridad → Configuración.
Qué llega a GitHub
Antes de que cualquier texto de revisión, comentario o comprobación llegue a GitHub, pasa por la puerta de publicación. En un repositorio público, o en uno cuya visibilidad Coroid no pueda confirmar, cualquier problema de seguridad que no sea público se sustituirá por el mensaje «Coroid detectó un posible problema de seguridad; los detalles están en Coroid», junto con un enlace. Ver Divulgación.