Análisis de secretos

Las credenciales expuestas en los sistemas de ingeniería proporcionan oportunidades fáciles de aprovechar para los atacantes. Para defenderse de esta amenaza, GitHub Advanced Security para Azure DevOps busca credenciales y otro contenido confidencial en el código fuente. La protección contra inserción también impide que se filtren las credenciales.

El examen de secretos del repositorio busca secretos que ya existan en el código fuente en todo el historial y la protección contra inserción impide que se expongan nuevos secretos en el código fuente.

GitHub Advanced Security para Azure DevOps funciona con Azure Repos. Si quiere usar GitHub Advanced Security con repositorios de GitHub, vea GitHub Advanced Security.

Acerca de las alertas de examen de secretos

Cuando se habilita Advanced Security, examina los repositorios en busca de secretos emitidos por una gran variedad de proveedores de servicios y genera alertas de examen de secretos.

Si para el acceso a un recurso se necesitan credenciales emparejadas, el examen de secretos puede crear una alerta solo cuando se detecten las dos partes del par en el mismo archivo. El emparejamiento garantiza que las fugas más críticas no se oculten detrás de información sobre fugas parciales. La coincidencia de pares también ayuda a reducir los falsos positivos, ya que los dos elementos de un par se deben usar de manera conjunta para acceder al recurso del proveedor.

La pestaña Advanced Security de Repos>Advanced Security en Azure DevOps es el centro para ver las alertas de seguridad. Seleccione la pestaña Secretos para ver las alertas de examen de secretos. Puede filtrar por estado y tipo de secreto. Puede navegar a una alerta para obtener más detalles, incluida la guía de corrección. Después de habilitar Advanced Security, se inicia un análisis del repositorio seleccionado, incluidas todas las confirmaciones históricas. Con el tiempo, a medida que avanza el examen comenzarán a aparecer alertas.

No hay ningún impacto en los resultados si se cambia el nombre de las ramas: pueden pasar hasta 24 horas antes de que se muestre el nuevo nombre.

Para corregir los secretos expuestos, invalide la credencial expuesta y cree una en su lugar. Después, el secreto recién creado se debe almacenar de forma segura para que no se vuelva a insertar directamente en el código. Por ejemplo, el secreto se podría almacenar en Azure Key Vault. La mayoría de los recursos tienen una credencial principal y una secundaria. El método para implementar una credencial principal frente a una secundaria es idéntico, a menos que se indique lo contrario.

Administración de alertas de examen de secretos

Visualizar las alertas para un repositorio

Cualquier usuario con permisos de colaborador en un repositorio puede ver un resumen de todas las alertas de un repositorio en la pestaña Seguridad avanzada de Repositorios. Seleccione la pestaña Secretos para ver las alertas de examen de secretos.

Si Advanced Security se ha habilitado recientemente para el repositorio, es posible que vea una tarjeta que indica que sigue examinando el repositorio.

Una vez que se complete el examen, se muestran los resultados. Se genera una sola alerta para cada credencial única detectada, en todas las ramas y el historial del repositorio. No hay filtros de rama, ya que se acumulan en una alerta.

Los secretos que no son de proveedor se pueden ver seleccionando "Otros" en la lista desplegable de confianza de la pestaña de análisis de secretos.

Detalles de alertas

Al navegar a una alerta, aparece una vista de alerta detallada, se muestran más detalles sobre la búsqueda y se proporcionan instrucciones de corrección específicas para resolver la alerta.

Sección	Explicación
Location	En la sección Ubicaciones se detallan las rutas de acceso en las que el análisis de secretos ha detectado la credencial filtrada. Puede haber varias ubicaciones o varias confirmaciones en el historial que contengan la credencial filtrada. Todas estas ubicaciones y confirmaciones se muestran en Ubicaciones con un vínculo directo al fragmento de código y la confirmación en la que se ha identificado.
Recomendación	La sección de recomendaciones contiene una guía de corrección o un vínculo a una guía de corrección de documentación de terceros para la credencial identificada.
Cerrar alerta	No hay ningún comportamiento de corrección automática para las alertas de examen de secretos. Todas las alertas de examen de secretos se deben evaluar manualmente como corregidas desde la página de detalles de la alerta. Seleccione el botón Cerrar para comprobar que se ha revocado el secreto.
severity	Todas las alertas de examen de secretos se establecen como críticas. Cualquier credencial expuesta es potencialmente una oportunidad para un actor malintencionado.
Búsqueda de detalles	El tipo de credencial y regla que se usa para buscarla se muestran en la barra lateral Buscar detalles de la página de detalles de la alerta.

Con secretos que no son de proveedor, la etiqueta Confianza: otra también aparece mediante el distintivo de gravedad en la vista de detalles de la alerta.

Corrección de alertas de examen de secretos

Cada secreto tiene pasos de corrección únicos para guiarle sobre cómo revocar y regenerar un nuevo secreto en su lugar. Los detalles de la alerta comparten pasos o documentación específicos para cada alerta.

Una alerta de examen de secretos permanece abierta hasta que se cierre. Para comprobar que se ha corregido una alerta de análisis de secretos:

1. Vaya a la alerta que quiera cerrar y selecciónela.
2. Seleccione el menú desplegable Cerrar alerta.
3. Si todavía no está seleccionado, seleccione Corregido.
4. Seleccione Cerrar para enviar la alerta y cerrarla.

Descarte de alertas de examen de secretos

Para descartar alertas en Advanced Security, necesita los permisos adecuados. De manera predeterminada, solo los administradores de proyectos pueden descartar alertas de seguridad avanzada. Para más información sobre los permisos de Advanced Security, vea Administración de permisos de Advanced Security.

Para descartar una alerta:

1. Vaya a la alerta que quiere cerrar y selecciónela.
2. Seleccione el menú desplegable Cerrar alerta.
3. Si aún no está seleccionado, seleccione Riesgo aceptado o Falso positivo como motivo del cierre.
4. Agregue un comentario opcional en el cuadro de texto Comentario.
5. Seleccione Cerrar para enviar y cerrar la alerta.
6. El estado de la alerta cambia de Abierto a Cerrado y muestra el motivo del cierre.

Cualquier alerta que se haya descartado anteriormente se puede volver a abrir de forma manual.

Asegurar los secretos en riesgo

Cuando un secreto se haya confirmado en un repositorio, está en riesgo. Microsoft recomienda las siguientes acciones para los secretos en peligro:

• Para un token de acceso personal de Azure DevOps en peligro, elimínelo, cree otros y actualice los servicios que usan el token anterior.
• Para todos los demás secretos, compruebe primero que el secreto confirmado en Azure Repos es válido. Si es así, cree un secreto, actualice los servicios que usan el secreto anterior y, después, elimine el secreto anterior.
• Identifique las acciones realizadas por el token en peligro en los recursos de la empresa.

Al actualizar un secreto, asegúrese de almacenar el nuevo secreto de forma segura y de que siempre se accede a él y nunca se almacena como texto no cifrado. Una posibilidad puede ser desde Azure Key Vault u otras soluciones de administración de secretos.

Protección contra inserción de secretos

La protección contra inserción comprueba si en las inserciones entrantes hay secretos de alta confianza y evita que se realicen. Un mensaje de error muestra todos los secretos identificados para que los quite, o bien continúe con su inserción si es necesario.

Acerca de las alertas de protección de inserción

Las alertas de protección contra inserción son alertas de usuario notificadas por la protección contra inserción. El examen de secretos como protección contra inserción examina actualmente los repositorios en busca de secretos emitidos por algunos proveedores de servicios.

Si para el acceso a un recurso se necesitan credenciales emparejadas, el examen de secretos puede crear una alerta solo cuando se detecten las dos partes del par en el mismo archivo. El emparejamiento garantiza que las fugas más críticas no se oculten detrás de información sobre fugas parciales. La coincidencia de pares ayuda a reducir los falsos positivos, ya que ambos elementos de un par deben usarse juntos para acceder al recurso del proveedor.

Es posible que la protección contra inserción no bloquee versiones anteriores de ciertos tokens, ya que estos tokens pueden generar un número mayor de falsos positivos que su versión más reciente. Es posible que la protección contra inserción tampoco bloquee los tokens heredados. En el caso de tokens como claves de Azure Storage, Advanced Security solo admite tokens creados recientemente, no los que coincidan con los patrones heredados.

Protección contra inserción desde la línea de comandos

La protección contra inserción se integra de forma nativa en Git de Azure DevOps. Si las confirmaciones contienen un secreto identificado, verá un error que indica que la inserción se ha rechazado.

Protección contra inserción desde la interfaz web

La protección contra inserción también funciona desde la interfaz web. Si se identifica un secreto en una confirmación, verá el siguiente bloque de error que le impide insertar los cambios:

Qué hacer si se bloquea la inserción

La protección contra inserción bloquea los secretos que se encuentran en archivos de texto sin formato que normalmente son (aunque no exclusivamente) archivos de texto, como el código fuente o los archivos de configuración JSON. Estos secretos se almacenan en texto no cifrado. Si un actor malintencionado obtiene acceso a los archivos y se publican en un repositorio público, cualquiera puede usar los secretos.

Se recomienda quitar el secreto del archivo marcado y, después, quitarlo del historial de confirmaciones. Si el secreto marcado es de marcador de posición o de ejemplo, se recomienda actualizar el secreto falso para anteponer la cadena Placeholder por delante.

Si el secreto se ha agregado en la confirmación inmediatamente anterior, rectifíquela y cree otra confirmación:

1. Quita el secreto del código.
2. Confirme los cambios mediante git commit --amend
3. Vuelva a insertar los cambio.

Si el secreto se ha agregado en un punto posterior del historial, edite las confirmaciones mediante una base interactiva:

1. Use git log para determinar qué confirmación ha confirmado primero el secreto.
2. Realice un fusión mediante cambio de base interactiva: git rebase -i [commit ID before credential introduction]~1
3. Identifica la confirmación para editar cambiando pick a edit en la primera línea del texto que aparece en el editor.
4. Quita el secreto del código.
5. Confirma el cambio con git commit --amend.
6. Para finalizar la nueva base, ejecute git rebase --continue.

Inserción de un secreto bloqueado

No se recomienda omitir secretos marcados porque al hacerlo puede poner en riesgo la seguridad de la empresa. Si confirma que un secreto identificado no es un falso positivo, debe quitarlo de todo el historial de ramas antes de intentar volver a insertar los cambios.

Si cree que un secreto bloqueado es un falso positivo o que se puede insertar de forma segura, puede omitir la protección contra inserción. Incluya la cadena skip-secret-scanning:true en el mensaje de confirmación. Incluso si omite la protección contra inserción, se genera una alerta de análisis de secretos en la experiencia de usuario de la alerta una vez que se ha insertado el secreto.