Referencia de uso seguro

Busca información sobre los procedimientos recomendados de seguridad al escribir flujos de trabajo y usar las características de seguridad de GitHub Actions.

Escritura de flujos de trabajo

Uso de secretos para la información confidencial

Dado que hay varias maneras de transformar un valor secreto, no se garantiza una redacción automática. Sigue estos procedimientos recomendados para limitar los riesgos asociados a los secretos.

• Principio de privilegio mínimo
  • Cualquier usuario con acceso de escritura al repositorio tiene acceso de lectura a todos los secretos configurados en él. Por lo tanto, debe asegurarse de que las credenciales que se usan en los flujos de trabajo tienen los privilegios mínimos necesarios.
  • Las acciones pueden usar GITHUB_TOKEN accediendo a él desde el contexto github.token. Para más información, consulta Contextos de referencia. Por lo tanto, debe asegurarse de que se conceden los permisos mínimos necesarios a GITHUB_TOKEN. Una buena práctica de seguridad consiste en establecer el permiso predeterminado para que GITHUB_TOKEN tenga acceso de lectura solo para contenido del repositorio. Se pueden incrementar los permisos, según se necesite, para las tareas individuales dentro del archivo de flujo de trabajo. Para más información, consulta Uso de GITHUB_TOKEN para la autenticación en flujos de trabajo.
• Enmascarar datos confidenciales
  • Los datos confidenciales jamás deben almacenarse como texto no cifrado en archivos de flujo de trabajo. Enmascara toda la información confidencial que no sea un secreto de GitHub mediante ::add-mask::VALUE. Esto hace que el valor se trate como un secreto y se redacte de los registros. Para más información sobre el enmascaramiento de datos, consulta Comandos de flujo de trabajo para Acciones de GitHub.
• Eliminación y giro de secretos expuestos
  • Los ejecutores de flujo de trabajo realizan la redacción de secretos. Esto significa que un secreto solo se ocultará si se usó dentro de un trabajo y es accesible para el agente. Si se envía un secreto sin ocultar a un registro de ejecución del flujo de trabajo, debe eliminar el registro y rotar el secreto. Para obtener información sobre cómo eliminar registros, consulta Uso de registros de flujo de trabajo.
• No usar nunca datos estructurados como un secreto
  • Los datos estructurados pueden causar que la redacción de secretos dentro de las bitácoras falle, ya que la redacción depende ampliamente de encontrar una coincidencia exacta para el valor específico del secreto. Por ejemplo, no utilices un blob de JSON, XML, o YAML (o similares) para encapsular el valor de un secreto, ya que esto reduce significativamente la probablidad de que los secretos se redacten adecuadamente. En vez de esto, crea secretos individuales para cada valor sensible.
• Registrar todos los secretos utilizados en los flujos de trabajo
  • Si se usa un secreto para generar otro valor confidencial en un flujo de trabajo, ese valor generado debe registrarse formalmente como secreto, de modo que se redactará si alguna vez aparece en los registros. Por ejemplo, si utilizas una llave privada para generar un JWT firmado para acceder a una API web, asegúrate registrar este JWT como un secreto, de lo contrario, este no se redactará si es que llega a ingresar en la salida de la bitácora.
  • El registrar secretos aplica también a cualquier tipo de transformación/cifrado. Si tu secreto se transforma de alguna manera (como en el cifrado URL o de Base64), asegúrate de registrar el valor nuevo como un secreto también.
• Auditar cómo se manejan los secretos
  • Audita cómo se utilizan los secretos para ayudarte a garantizar que se manejan como lo esperas. Puedes hacer esto si revisas el código fuente del rpositorio que ejecuta el flujo de trabajo y verificas cualquier acción que se utilice en dicho flujo de trabajo. Por ejemplo, verifica que no se estén enviando a hosts no deseados, o que no se estén imprimiendo explícitamente en la salida de una bitácora.
  • Visualiza las bitácoras de ejecución de tu flujo de trabajo después de probar las entradas válidas/no válidas y verifica que los secretos se redacten adecuadamente o que no se muestren. No siempre resulta obvio la forma en que un comando o herramienta que está invocando enviará errores a STDOUT y STDERR, y los secretos podrían acabar posteriormente en los registros de errores. Por consiguiente, es una buena práctica el revisar manualmente las bitácoras de flujo de trabajo después de probar las entradas válidas y no válidas. Para obtener información sobre cómo limpiar los registros de flujo de trabajo que pueden contener datos confidenciales involuntariamente, consulta Uso de registros de flujo de trabajo.
• Auditar y rotar los secretos registrados
  • Revisa con frecuencia los secretos que se han registrado para confirmar que aún se requieran. Elimina aquellos que ya no se necesiten.
  • Rotar los secretos periódicamente para reducir el período de tiempo durante el cual un secreto comprometido es válido.
• Tener en cuenta la exigencia de revisiones para acceder a los secretos
  • Puedes utilizar los revisores obligatorios para proteger los secretos del entorno. Una tarea del flujo de trabajo no podrá acceder a los secretos del entorno hasta que el revisor otorgue la aprobación. Para obtener más información sobre cómo almacenar secretos en entornos o requerir revisiones para entornos, consulta Uso de secretos en Acciones de GitHub y Administrar entornos para la implementación.

Buenas pràcticas para mitigar los ataques de inyecciòn de scripts

Enfoques recomendados para mitigar el riesgo de inyección de scripts en los flujos de trabajo:

Usar una acción en vez de un script en línea

El acercamiento recomendado es crear una acción de JavaScript que procese el valor del contexto como un argumento. Este enfoque no es vulnerable a ataques de inyección, ya que el valor del contexto no se utiliza para generar un script de shell, sino que se pasa a la acción como un argumento.

uses: fakeaction/checktitle@v3
with:
  title: ${{ github.event.pull_request.title }}

Utilizar una variable de ambiente intermedia

Para los scripts en línea, el enfoque preferido para manejar entradas no fiables es asignar el valor de la expresión a una variable de entorno intermedia. En el ejemplo siguiente se usa Bash para procesar el valor github.event.pull_request.title como una variable de entorno:

      - name: Check PR title
        env:
          TITLE: ${{ github.event.pull_request.title }}
        run: |
          if [[ "$TITLE" =~ ^octocat ]]; then
          echo "PR title starts with 'octocat'"
          exit 0
          else
          echo "PR title did not start with 'octocat'"
          exit 1
          fi

En este ejemplo, el intento de inyección de script no se realiza correctamente, lo que se refleja en las líneas siguientes del registro:

   env:
     TITLE: a"; ls $GITHUB_WORKSPACE"
PR title did not start with 'octocat'

Con este enfoque, el valor de la expresión ${{ github.event.pull_request.title }} se almacena en memoria y se usa como variable, y no interactúa con el proceso de generación de scripts. Además, considere la posibilidad de usar variables de shell de comillas dobles para evitar la división de palabras, si bien esta es una de las muchas recomendaciones generales para escribir scripts de shell y no es específica de GitHub Actions.

Restringir los permisos para los tokens

Para ayudar a mitigar el riesgo de un token expuesto, considere restringir los permisos asignados. Para más información, consulta Uso de GITHUB_TOKEN para la autenticación en flujos de trabajo.

Mitigación de los riesgos de extracción de código que no es de confianza

De forma similar a los ataques por inyección de scripts, el contenido de solicitudes de cambios que no son de confianza que desencadena automáticamente el procesamiento de acciones también puede suponer un riesgo para la seguridad. Los desencadenadores de flujo de trabajo pull_request_target y workflow_run, cuando se usan con la extracción de una solicitud de cambios que no es de confianza, exponen el repositorio a riesgos de seguridad. Estos flujos de trabajo tienen privilegios, lo que significa que comparten la misma memoria caché de la rama principal con otros desencadenadores de flujo de trabajo con privilegios y pueden tener acceso de escritura al repositorio y acceso a los secretos a los que se hace referencia. Estas vulnerabilidades se pueden aprovechar para tomar el control de un repositorio.

Para más información sobre estos desencadenadores, cómo usarlos y los riesgos asociados, consulta Eventos que desencadenan flujos de trabajo y Eventos que desencadenan flujos de trabajo.

Para obtener ejemplos adicionales e instrucciones sobre los riesgos de la extracción de código que no es de confianza, consulta Evitar solicitudes pwn de GitHub Security Lab y la documentación sobre Dangerous-Workflow de OpenSSF Scorecard.

Procedimientos recomendados

• Evita usar el desencadenador de flujo de trabajo pull_request_target si no es necesario. Para la separación de privilegios entre flujos de trabajo, workflow_run es un desencadenador mejor. Usa solo estos desencadenadores de flujo de trabajo cuando el flujo de trabajo necesite realmente el contexto con privilegios.

• Evita usar los desencadenadores de flujo de trabajo pull_request_target y workflow_run con solicitudes de cambios o contenido de código que no sean de confianza. Los flujos de trabajo que usan estos desencadenadores no deben extraer explícitamente código que no es de confianza, incluido desde bifurcaciones de solicitudes de cambios o repositorios que no están bajo tu control. Los flujos de trabajo desencadenados en workflow_run deben tratar con precaución los artefactos cargados desde otros flujos de trabajo.

• CodeQL puede examinar y detectar flujos de trabajo de GitHub Actions potencialmente vulnerables. Puedes establecer la configuración predeterminada para el repositorio y asegurarte de que el análisis de GitHub Actions está habilitado. Para más información, consulta Establecimiento de la configuración predeterminada para el examen del código.

• Los cuadros de mandos de OpenSSF pueden ayudarte a identificar flujos de trabajo potencialmente vulnerables, junto con otros riesgos de seguridad al usar GitHub Actions. Consulta Uso de cuadros de mandos de OpenSSF para proteger las dependencias de flujo de trabajo más adelante en este artículo.

Utilizar acciones de terceros

Los trabajos individuales en un flujo de trabajo pueden interactuar con (y comprometer) otras tareas. Por ejemplo, un job que consulta las variables de ambiente que se utilizan por otro job subsecuente, escribir archivos en un directorio compartido que el job subsecuente procesa, o aún de forma más directa si interactúa con el conector de Docker e inspecciona a otros contenedores en ejecución y ejecuta comandos en ellos.

Esto significa que comprometer una sola acción dentro de un flujo de trabajo puede ser muy significativo, ya que esa acción comprometida tendría acceso a todas las claves secretas configuradas en el repositorio y podría utilizar GITHUB_TOKEN para escribir en él. Por consiguiente, hay un riesgo significativo en suministrar acciones de repositorios de terceros en GitHub. Para obtener información sobre algunos de los pasos que podría realizar un atacante, consulta Referencia de uso seguro.

Puedes ayudar a mitigar este riesgo si sigues estas buenas prácticas:

• Anclaje de acciones a un SHA de confirmación de longitud completa

  Anclar una acción a un SHA de confirmación de longitud completa es actualmente la única forma de utilizar una acción como una versión inmutable. Fijar las acciones a un SHA en particular ayuda a mitigar el riesgo de que un actor malinencionado agregue una puerta trasera al repositorio de la acción, ya que necesitarían generar una colisión de SHA-1 para una carga útil vlálida de un objeto de Git. Al seleccionar un SHA, debe comprobar que se encuentra en el repositorio de la acción y no en una bifurcación de repositorio.

  Para obtener un ejemplo del uso de un SHA de confirmación de longitud completa en un flujo de trabajo, consulta Uso de bloques predefinidos en el flujo de trabajo.

  GitHub ofrece directivas en el nivel del repositorio, organización y empresa para requerir que las acciones se anclen a un SHA de confirmación de longitud completa:

  • Para configurar la directiva en el nivel del repositorio, consulta Administración de la configuración de GitHub Actions para un repositorio.
  • Para configurar la directiva en el nivel de la organización, consulta Deshabilitación o limitación de GitHub Actions para su organización.
  • Para configurar la directiva en el nivel de la empresa, consulta Aplicación de directivas para GitHub Actions en la empresa.

• Auditar el código fuente de la acción

  Asegúrate de que la acción está manejando los secretos y el contenido de tu repositorio como se espera. Por ejemplo, verifica que los secretos no se envíen a hosts no deseados, o que no se registren inadvertidamente.

• Ancla las acciones a una etiqueta solo si confías en el creador

  Aunque fijar el SHA de una confirmación es la opción más segura, especificar una etiqueta es más conveniente y se utiliza ampliamente. Si te gustaría especificar una etiqueta, entonces asegúrate de que confías en los creadores de la acción. La insignia de ‘Creador verificado’ en GitHub Marketplace es una señal útil, ya que indica que la acción fue redactada por un equipo cuya identidad ha sido verificada por GitHub. Nota que este acercamiento sí tiene riesgos aún si confías en el autor, ya que una etiqueta se puede mover o borrar en caso de que un actor malicioso consiga acceso al repositorio que almacena la acción.

Reutilizar los flujos de trabajo de terceros

El mismo principio que se describió anteriormente para utilizar acciones de terceros también aplica para los flujos de trabajo de terceros. Puedes ayudar a mitigar los riesgos asociados con la reutilización de flujos de trabajo si sigues las mismas buenas prácticas que se describen anteriormente. Para más información, consulta Reutilización de flujos de trabajo.

Características de seguridad de GitHub

GitHub proporciona muchas características para que el código sea más seguro. Puede usar las características integradas de GitHub para comprender las acciones que dependen de los flujos de trabajo, asegurarse de que se le notifican vulnerabilidades en las acciones que consume o automatizar el proceso de mantener actualizadas las acciones de los flujos de trabajo. Si publica y mantiene acciones, puede usar GitHub para comunicarse con la comunidad sobre vulnerabilidades y cómo corregirlas. Para obtener más información sobre las características de seguridad que ofrece GitHub, consulta Características de seguridad de GitHub.

Uso de CODEOWNERS para supervisar los cambios

Puede usar la característica CODEOWNERS para controlar cómo se realizan los cambios en los archivos de flujo de trabajo. Por ejemplo, si todos tus archivos de flujo de trabajo se almacenan en .github/workflows, puedes agregar este directorio a la lista de propietarios de código para que cualquier cambio propuesto a estos archivos requiera primero de una aprobación de un revisor designado.

Para más información, consulta Acerca de los propietarios de código.

Administrar los permisos para la configuración de GitHub Actions en su organización

Puedes aplicar el principio de privilegio mínimo en el pipeline de CI/CD de tu organización con GitHub Actions administrando roles personalizados en la organización. Un rol de organización personalizado es una manera de conceder a una persona o equipo de la organización la capacidad de controlar determinados subconjuntos de configuraciones sin conceder control administrativo total de la organización y sus repositorios.

Para GitHub Actions, puede habilitar cualquiera de los permisos siguientes para usuarios o equipos de su organización.

• Administrar directivas de acciones de la organización: acceso para administrar toda la configuración en la página de configuración "Acciones generales", excepto para la configuración de ejecutores autohospedados.
• Administrar ejecutores de la organización y grupos de ejecutores: acceso para crear y administrar ejecutores hospedados en GitHub, ejecutores autohospedados y grupos de ejecutores, y controlar dónde se pueden crear ejecutores autohospedados.
• Administrar secretos de acciones de la organización: acceso para crear y administrar secretos de la organización de Acciones.
• Administrar variables de acciones de la organización: acceso para crear y administrar variables de la organización de Acciones.

Para más información, consulta Permisos de roles de organización personalizados.

Utilizar OpenID connect para acceder a los recursos en la nube

Si tus flujos de trabajo de GitHub Actions necesitan acceder a los recursos de un proveedor de servicios en la red que sea compatible con OpenID Connect (OIDC), puedes configurarlos para que se autentiquen directamente con dicho proveedor. Esto te permitirá dejar de almacenar estas credenciales como secretos de duración larga y te proporcionará otros beneficios de seguridad. Para más información, consulta OpenID Connect.

Usar Dependabot version updates para mantener actualizadas las acciones

Puede usar Dependabot para asegurarte de que las referencias a las acciones y los flujos de trabajo reutilizables usados en el repositorio se mantienen actualizados. Las acciones a menudo se actualizan con correcciones de errores y con nuevas características para que los procesos automatizados sean más confiables, rápidos y seguros. Dependabot acaba con la necesidad de mantener las dependencias, ya que lo hace automáticamente. Para más información, consulta Mantener tus acciones actualizadas con el Dependabot y Sobre las actualizaciones de seguridad de Dependabot.

Habilitación para que los flujos de trabajo accedan a los repositorios internos y privados

Si haces que un repositorio privado sea accesible a los flujos de trabajo de GitHub Actions de otros repositorios, los colaboradores externos de otros repositorios pueden acceder a él indirectamente a pesar de que no tengan acceso directo a estos repositorios. Los colaboradores externos pueden ver registros de las ejecuciones de flujo de trabajo cuando se utilizan acciones o flujos de trabajo del repositorio privado. Para obtener más información, consulta Compartir acciones y flujos de trabajo con tu empresa.

Para permitir que los ejecutores descarguen estas acciones, GitHub pasa un token de instalación con ámbito al ejecutor. Este token tiene acceso de lectura al repositorio y expira automáticamente después de una hora.

Impedir la creación o aprobación de solicitudes de incorporación de cambios por parte de GitHub Actions

Puedes elegir permitir o impedir que los flujos de trabajo GitHub Actions creen o aprueben solicitudes de incorporación de cambios. Permitir que los flujos de trabajo, o cualquier otra automatización, creen o aprueben solicitudes de cambios podría ser un riesgo de seguridad si la solicitud de cambios se combina sin la supervisión adecuada.

Para obtener más información sobre cómo configurar esta opción, consulta Aplicación de directivas para GitHub Actions en la empresa, Inhabilitación o limitación de GitHub Actions para tu organización y Administración de la configuración de GitHub Actions para un repositorio.

Uso de code scanning para proteger los flujos de trabajo

Code scanning puede detectar automáticamente y sugerir mejoras para patrones vulnerables comunes utilizados en flujos de trabajo GitHub Actions. Para obtener más información sobre cómo activar code scanning, consulta Establecimiento de la configuración predeterminada para el examen del código.

Uso de tarjetas de puntuación OpenSSF para proteger las dependencias de los flujos de trabajo

          Los [cuadros de mandos](https://github.com/ossf/scorecard) son una herramienta de seguridad automatizada que marca las prácticas de riesgo en la cadena de suministro. Puede usar la [acción de cuadros de mandos](https://github.com/marketplace/actions/ossf-scorecard-action) y la [plantilla de flujo de trabajo](https://github.com/actions/starter-workflows) para seguir las prácticas de seguridad recomendadas. Una vez configurada, la acción de puntuación se ejecutará automáticamente al realizar cambios en el repositorio y alertará a los desarrolladores sobre prácticas de riesgo en la cadena de suministro utilizando la experiencia integrada de code scanning. El proyecto Scorecards ejecuta varias comprobaciones, incluyendo las de ataques de inyección de scripts, permisos de tokens y acciones fijadas.

Protección de ejecutores hospedados de GitHub

Fortalecimiento para los ejecutores auto-hospedados

Autohospedados para GitHub no tienen garantías sobre ejecutar en máquinas virtuales limpias y efímeras, y pueden ponerse en riesgo de forma persistente mediante código no fiable en un flujo de trabajo.

Ten cuidado al utilizar ejecutores autohospedados en repositorios privados o internos, ya que cualquier usuario que pueda bifurcar el repositorio y abrir una solicitud de incorporación de cambios (por lo general, aquellos con acceso de lectura al repositorio) pueden poner en riesgo el entorno del ejecutor autohospedado, incluida la obtención de acceso a los secretos y a GITHUB_TOKEN que, en función de su configuración, puede conceder acceso de lectura al repositorio. Aunque los flujos de trabajo pueden controlar el acceso a los secretos de ambiente utilizando ambientes y revisiones requeridas, estos flujos de trabajo no se encuentran en un ambiente aislado y aún son susceptibles a los mismos riesgos cuando se ejecutan en un ejecutor auto-hospedado.

Los propietarios de empresa y de organización pueden elegir los repositorios que pueden crear ejecutores autohospedados en el nivel de repositorio. Los usuarios con el permiso "Administrar ejecutores de la organización y grupos de ejecutores" solo pueden elegir qué repositorios pueden crear ejecutores autohospedados de nivel de repositorio para repositorios de su organización.

Para obtener más información sobre los roles de organización personalizados, consulta Permisos de roles de organización personalizados.

Para más información, consulta Aplicación de directivas para GitHub Actions en la empresa y Deshabilitación o limitación de GitHub Actions para su organización.

Cuando se define un ejecutor autohospedado en el nivel de organización o de empresa, GitHub puede programar flujos de trabajo de varios repositorios en el mismo ejecutor. Como consecuencia, si se pone en riesgo la seguridad de estos ambientes, se puede ocasionar un impacto amplio. Para ayudar a reducir el alcance de esta vulneración, puedes crear límites si organizas tus ejecutores auto-hospedados en grupos separados. Puedes restringir qué flujos de trabajo, organizaciones y repositorios pueden acceder a los grupos de ejecutores. Para más información, consulta Administración del acceso a los ejecutores autohospedados mediante grupos.

También deberás considerar el ambiente de las máquinas del ejecutor auto-hospedado:

• ¿Qué información sensible se encuentra en la máquina configurada como ejecutor auto-hospedado? Por ejemplo, llaves SSH privadas, tokens de acceso a la API, entre otros.
• ¿La máquina tiene acceso a la red para servicios sensibles? Por ejemplo, Azure o servicios de metadatos de AWS. La cantidad de información sensible en este ambiente debe ser mínima, y siempre debes estar consciente de que cualquier usuario capaz de invocar flujos de trabajo tendrá acceso a este ambiente.

Algunos clientes podrían intentar mitigar estos riesgos parcialmente implementando sistemas que destruyan automáticamente al ejecutor propio después de cada ejecución de una tarea. Sin embargo, este acercamiento podría no ser tan efectivo como se pretende, ya que no hay forma de garantizar que un ejecutor auto-hospedado ejecute solamente un job. Algunos trabajos utilizarán secretos como los argumentos de la línea de comandos, los cuales puede ver otro trabajo que se esté ejecutando en el mismo ejecutor, como ps x -w. Esto puede causar fugas de secretos.

Uso de ejecutores Just-In-Time

Para mejorar la seguridad del registro del ejecutor, puedes usar la API REST para crear ejecutores efímeros Just-In-Time (JIT). Estos ejecutores autohospedados realizan como máximo un trabajo antes de quitarse automáticamente del repositorio, la organización o la empresa. Para más información sobre cómo configurar los ejecutores JIT, consulta Puntos de conexión de API de REST para ejecutores autohospedados.

Cuando tengas el archivo de configuración de la respuesta de la API REST, puedes pasarlo al ejecutor en el inicio.

./run.sh --jitconfig ${encoded_jit_config}

Planear tu estrategia de administración para los ejecutores auto-hospedados

Un ejecutor auto-hospedado puede agregarse a varios niveles en tu jerarquía de GitHub: el nivel de empresa, organización o repositorio. Esta colocación determina quién podrá administrar el ejecutor:

          **Administración centralizada**:

• Si planeas que un equipo centralizado sea el propietario de los ejecutores auto-hospedados, entonces la recomendación es agregar tus ejecutores en el nivel de empresa u organización mutua más alto. Esto otorga a tu equipo una ubicación única para ver y administrar tus ejecutores.

• Si solo tienes una organización sencilla, entonces el agregar tus ejecutores a nivel organizacional es efectivamente el mismo acercamiento, pero puede que encuentres dificultades si agregas otra organización en el futuro.

          **Administración descentralizada**:
  

• Si cada equipo administrará sus propios ejecutores auto-hospedados, entonces se recomienda agregarlos en el nivel más alto de propiedad del equipo. Por ejemplo, si cada equipo es dueño de su propia organización, entonces sería más sencillo si los corredores se agregan a nivel organizativo también.

• También podrías agregar ejecutores a nivel de repositorio, pero esto agregará una sobrecarga de administración y también incrementará la cantidad de ejecutores que necesitas, ya que no puedes compartir ejecutores entre repositorios.

Autenticarte a tu proveedor en la nube

Si estás utilizando las GitHub Actions para desplegar a un proveedor en la nube o si intentas utilizar HashiCorp Vault para la administración de secretos, entonces se recomienda que consideres utilizar OpenID Connect para crear tokens de acceso con un buen alcance y de vida corta para tus ejecuciones de flujo de trabajo. Para más información, consulta OpenID Connect.

Auditar eventos de GitHub Actions

Puedes usar el registro de seguridad para supervisar la actividad de tu cuenta de usuario y el registro de auditoría para supervisar la actividad en tu organización o empresa. El registro de seguridad y auditoría registra el tipo de acción, cuándo se ejecutó, y qué cuenta personal llevó a cabo la acción.

Por ejemplo, puedes usar el registro de auditoría para realizar un seguimiento del evento org.update_actions_secret, que realiza un seguimiento de los cambios en los secretos de la organización.

Para obtener la lista completa de eventos que puedes encontrar en el registro de auditoría de cada tipo de cuenta, consulta los artículos siguientes:

• Eventos de registro de seguridad

•           [AUTOTITLE](/organizations/keeping-your-organization-secure/managing-security-settings-for-your-organization/audit-log-events-for-your-organization)
  

• Eventos de registro de auditoría de la empresa

Descripción de las dependencias de los flujos de trabajo

Puede usar el gráfico de dependencias para explorar las acciones que usan los flujos de trabajo del repositorio. El gráfico de dependencias es un resumen del manifiesto y de los archivos de lock almacenados en un repositorio. También reconoce archivos en ./github/workflows/ como manifiestos, lo que significa que las acciones o flujos de trabajo a los que se hace referencia mediante la sintaxis jobs[*].steps[*].uses o jobs.<job_id>.uses se analizarán como dependencias.

El gráfico de dependencias muestra la siguiente información sobre las acciones usadas en los flujos de trabajo:

• Cuenta u organización que posee la acción.
• Archivo de flujo de trabajo que hace referencia a la acción.
• La versión o SHA a la que está anclada la acción.

En el gráfico de dependencias, éstas se ordenan automáticamente por gravedad de la vulnerabilidad. Si alguna de las acciones que usa tiene avisos de seguridad, se mostrarán en la parte superior de la lista. Puede ir al aviso desde el gráfico de dependencias e instrucciones de acceso para resolver la vulnerabilidad.

Los propietarios de empresas pueden configurar el gráfico de dependencias y Dependabot alerts para una empresa. Para más información, consulta Habilitación del gráfico de dependencias para la empresa.

Tener en cuenta las vulnerabilidades de seguridad en las acciones que se usan

Para las acciones disponibles en el Marketplace, GitHub revisa los avisos de seguridad relacionados y, a continuación, agrega esos avisos a GitHub Advisory Database. Puede buscar en la base de datos las acciones que use para buscar información sobre las vulnerabilidades existentes e instrucciones sobre cómo corregirlas. Para simplificar la búsqueda, use el filtro GitHub Actions en GitHub Advisory Database.

Puede configurar los repositorios para:

• Recibir alertas cuando las acciones usadas en los flujos de trabajo reciben un informe de vulnerabilidades. Para obtener más información, consulta Supervisión de las acciones en los flujos de trabajo.
• Se advierte sobre los avisos existentes al agregar o actualizar una acción en un flujo de trabajo. Para obtener más información, consulta Acciones de filtrado de vulnerabilidades en flujos de trabajo nuevos o actualizados.

Supervisión de las acciones en los flujos de trabajo

Puede usar Dependabot para supervisar las acciones de los flujos de trabajo y habilitar Dependabot alerts para notificarle cuándo una acción que usa tiene una vulnerabilidad notificada. Dependabot realiza un examen de la rama predeterminada de los repositorios donde está habilitado para detectar dependencias no seguras. Dependabot genera Dependabot alerts cuando se agrega una nueva advertencia a GitHub Advisory Database o cuando se actualiza una acción que se usa.

Un propietario de la empresa debe configurar primero Dependabot para tu empresa antes de poder administrar Dependabot alerts para el repositorio. Para más información, consulta Habilitación de Dependabot para la empresa.

Puede ver todos los elementos abiertos y cerrados Dependabot alerts y correspondientes Dependabot security updates en la pestaña Dependabot de su repositorio. Para obtener más información, consulta Visualización y actualización de alertas de Dependabot.

Acciones de detección de vulnerabilidades en flujos de trabajo nuevos o actualizados

Al abrir solicitudes de incorporación de cambios para actualizar los flujos de trabajo, se recomienda usar la revisión de dependencias para comprender el impacto en la seguridad de los cambios realizados en las acciones que use. La revisión de dependencias te permite entender los cambios a las dependencias y el impacto de seguridad de estos cambios en cada solicitud de cambios. Proporciona una visualización fácil de entender para los cambios de dependencia con un diferencial importante en la pestaña "Archivos cambiados" de una solicitud de incorporación de cambios. La revisión de dependencias te informa sobre:

• Qué dependencias se agregaron, eliminaron o actualizaron junto con las fechas de lanzamiento
• Cuántos proyectos utilizan estos componentes
• Datos de las vulnerabilidades para estas dependencias

Si alguno de los cambios realizados en los flujos de trabajo está marcado como vulnerable, puede evitar agregarlos al proyecto o actualizarlos a una versión segura.

Para más información sobre la revisión de dependencias, consulta Acerca de la revisión de dependencias.

La "Acción de revisión de dependencias" hace referencia a la acción específica que puede informar sobre las diferencias en una solicitud de cambios dentro del contexto de GitHub Actions. Vea dependency-review-action. Puedes usar Acción de revisión de dependencias en el repositorio para aplicar revisiones de dependencias en las solicitudes de incorporación de cambios. La acción analiza las versiones vulnerables de las dependencias introducidas por los cambios de versión del paquete en las solicitudes de incorporación de cambios y le advierte sobre las vulnerabilidades de seguridad asociadas. Esto proporciona una mejor visibilidad de los cambios en una solicitud de incorporación de cambios y ayuda a evitar que se agreguen vulnerabilidades al repositorio. Para obtener más información, consulta Acerca de la revisión de dependencias.

Mantener las acciones en los flujos de trabajo seguras y actualizadas

Puede usar Dependabot para asegurarte de que las referencias a las acciones y los flujos de trabajo reutilizables usados en el repositorio se mantienen actualizados. Las acciones a menudo se actualizan con correcciones de errores y con nuevas características para que los procesos automatizados sean más confiables, rápidos y seguros. Dependabot acaba con la necesidad de mantener las dependencias, ya que lo hace automáticamente. Para más información, consulta Mantener tus acciones actualizadas con el Dependabot y Sobre las actualizaciones de seguridad de Dependabot.

Las siguientes características pueden actualizar automáticamente las acciones de los flujos de trabajo.

•           Las **Dependabot version updates** abren las solicitudes de incorporación de cambios para actualizar las acciones a la versión más reciente cuando se publica una nueva versión.
  

• Dependabot security updates abra solicitudes de incorporación de cambios para actualizar acciones con vulnerabilidades notificadas a la versión mínima revisada.

Para obtener información sobre la configuración de Dependabot version updates, consulta Configuración de las actualizaciones de versiones de Dependabot.

Para obtener más información sobre cómo configurar Dependabot security updates, consulta Configuración de actualizaciones de seguridad de Dependabot.