Referencia de uso seguro

Procedimientos de seguridad para escribir flujos de trabajo y utilizar las características de GitHub Actions.

En este artículo

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.

Uso de plantillas de flujo de trabajo para code scanning

Code scanning te permite encontrar vulnerabilidades de seguridad antes de que lleguen a producción. GitHub proporciona plantillas de flujo de trabajo para code scanning. Puedes utilizar estos flujos de trabajo sugeridos para construir tus flujos de trabajo del code scanning en vez de comenzar desde cero. El proceso de trabajo de GitHub, el Flujo de trabajo de análisis de CodeQL, está potenciado por CodeQL. También hay disponibles plantillas de flujo de trabajo de terceros.

Para más información, consulta Acerca del examen de código y Establecimiento de la configuración avanzada para el examen del código.

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.

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 y organización para requerir que las acciones se anclen a un SHA de confirmación de longitud completa:

  • 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.

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.

Nota:

La compatibilidad con notificaciones personalizadas para OIDC no está disponible en AWS.

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.

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 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

Los ejecutores hospedados de GitHub toman medidas para ayudar a mitigar los riesgos de seguridad.

Revisión de la cadena de suministro para los corredores hospedados en GitHub

En el caso de ejecutores hospedados en GitHub creados a partir de imágenes que mantiene GitHub, puedes ver una lista de materiales de software (SBOM) para ver qué software se instaló previamente en el ejecutor. Puedes proporcionar a los usuarios la SBOM, que pueden ejecutar con un analizador de vulnerabilidades para validar si hay alguna vulnerabilidad en el producto. Si vas a crear artefactos, puedes incluir esta SBOM en la lista de materiales para obtener una lista completa de todo lo que se ha utlizado en la creación del software.

Las SBOM están disponibles para imágenes de ejecutores de Ubuntu, Windows y macOS que mantiene GitHub. Puedes encontrar la SBOM de la compilación en los recursos de versión en https://github.com/actions/runner-images/releases. Un SBOM con un nombre de archivo en formato sbom.IMAGE-NAME.json.zip se puede encontrar en los archivos adjuntos de cada versión.

En el caso de las imágenes de terceros, como las imágenes de los ejecutores con tecnología de ARM, puede encontrar detalles del software que se incluye en la imagen en el repositorio actions/partner-runner-images.

Denegación del acceso a los hosts

Los ejecutores hospedados de GitHub se aprovisionan con un archivo etc/hosts que bloquea el acceso de red a varios grupos de minería de criptomonedas y sitios malintencionados. Los hosts como MiningMadness.com y cpu-pool.com se vuelven a enrutar a localhost para que no presenten un riesgo de seguridad significativo. Para obtener más información, consulte Ejecutores hospedados en GitHub.

Fortalecimiento para los ejecutores auto-hospedados

Los ejecutores hospedados en GitHub ejecutan código en máquinas virtuales aisladas, limpias y efímeras, lo que significa que no hay forma de poner este entorno en riesgo de forma persistente, o de obtener acceso de otra forma a más información de la que se ha colocado en este entorno durante el proceso de arranque.

Los ejecutores 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.

Como resultado, los ejecutores autohospedados casi nunca se deben usar para repositorios públicos en GitHub, ya que cualquier usuario puede abrir solicitudes de cambios en el repositorio y poner en peligro el entorno. De manera similar, 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 la organización pueden elegir los repositorios que pueden crear ejecutores autohospedados en el nivel de repositorio. .

Para más información, consulta 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é 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.

Nota:

Volver a usar hardware para hospedar ejecutores JIT puede poner en riesgo la exposición de información del entorno. Utiliza la automatización para asegurarte de que el ejecutor JIT use un entorno limpio. Para más información, consulta Referencia de 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. 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.

Captura de pantalla que muestra una búsqueda de "action:org.update_actions_secret" en el registro de auditoría de una organización. Se muestran dos resultados.

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)

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.

El gráfico de dependencias se habilita para los repositorios públicos, y puede elegir habilitarlo también para los privados. Para obtener más información sobre el uso del gráfico de dependencias, consulta Explorar las dependencias de un repositorio.

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:

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.

Nota:

Dependabot solo crea alertas para acciones vulnerables que usan control de versiones semánticos y no crearán alertas para acciones ancladas a valores SHA.

Puedes habilitar Dependabot alerts para tu cuenta personal, para un repositorio, o para una organización. Para obtener más información, consulta Configuración de alertas de Dependabot.

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.

Nota:

  • Dependabot solo admite actualizaciones de GitHub Actions mediante la sintaxis del repositorio GitHub, como actions/checkout@v5 o actions/checkout@<commit>. Dependabot omitirá las acciones o los flujos de trabajo reutilizables a los que se hace referencia localmente (por ejemplo, ./.github/actions/foo.yml).
  • Dependabot actualiza la documentación de la versión de GitHub Actions cuando el comentario está en la misma línea, como actions/checkout@<commit> #<tag or link> o actions/checkout@<tag> #<tag or link>.
  • Si el commit que utilizas no está asociado a ninguna etiqueta, Dependabot actualizará GitHub Actions al commit más reciente (que puede diferir de la versión más reciente).
  • Actualmente no se admiten Docker Hub y direcciones URL del GitHub Packages de Container registry. Por ejemplo, no se admiten referencias a acciones de contenedor de Docker mediante la sintaxis docker://.
  • Dependabot admite repositorios públicos y privados para GitHub Actions. Para obtener las opciones de configuración del registro privado, consulta "git" en Referencia de opciones de Dependabot.

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.

Protección de acciones que ha creado

GitHub permite la colaboración entre personas que publican y mantienen acciones e informantes de vulnerabilidades con el fin de promover la codificación segura. Las asesorías de seguridad del repositorio permiten a los mantenedores de repositorios públicos analizar y corregir de forma privada una vulnerabilidad de seguridad en un proyecto. Después de colaborar en una corrección, los mantenedores de repositorios pueden publicar el aviso de seguridad para revelar públicamente la vulnerabilidad de seguridad a la comunidad del proyecto. Al publicar avisos de seguridad, los mantenedores de repositorios facilitan a su comunidad la actualización de las dependencias de paquetes y la investigación del impacto de las vulnerabilidades de seguridad.

Si es alguien que mantiene una acción que se usa en otros proyectos, puede usar las siguientes características de GitHub para mejorar la seguridad de las acciones que ha publicado.