Cuatro funciones de seguridad que todo pipeline de GitHub Actions necesita en 2026

SolarWinds en 2020. Codecov en 2021. event-stream en 2018. Tres ataques a la cadena de suministro que han marcado seis años de pensamiento sobre seguridad de CI/CD, y todos empezaron en el proceso de build. El 26 de marzo de 2026, GitHub publicó una hoja de ruta de seguridad para Actions que apunta justo a esa brecha. Cuatro funciones, con las primeras public previews en tres a seis meses y la GA en seis a nueve.

La mayoría de los equipos con los que trabajamos ponen un firewall en su base de datos de producción, pero dejan su runner de CI abierto de par en par a internet. Esa brecha es exactamente donde operan los atacantes.

El firewall de egress lo cambia todo

Esta es la que más importa. Empiece por aquí.

Hoy, cuando npm install se ejecuta dentro de su pipeline, ese proceso puede alcanzar cualquier servidor del planeta. Un paquete comprometido llama a casa, exfiltra sus secrets de CI a un endpoint externo y usted se entera días después por los logs. Quizás. O no se entera nunca.

GitHub va a añadir un firewall de capa 7 que se ejecuta fuera de la VM del runner. Usted define una whitelist de dominios permitidos (registry.npmjs.org, github.com, su registry privado) y todo lo demás queda bloqueado. Sin resolución DNS, sin conexión TCP, nada.

Esa ubicación es justamente lo importante. Un atacante que consiga root en el runner sigue sin poder saltarse el firewall, porque las reglas corren en una capa a la que nunca llega. Dentro de la VM, root habría zanjado la discusión.

Lo que se puede configurar:

• Dominios y direcciones IP permitidos
• Métodos HTTP permitidos
• Requisitos de TLS (versión mínima, certificate pinning)

Si ya trabaja bien la seguridad del lado del cliente, esta es la mitad que le faltaba. Las cabeceras CSP y los hashes SRI defienden lo que pasa en el navegador. El firewall de egress defiende lo que pasa en el build. Si se salta cualquiera de los dos, el agujero sigue ahí.

Un ataque típico a la cadena de suministro sigue siempre la misma forma. La dependencia comprometida llama a casa, exfiltra tokens o inyecta código malicioso en el bundle de salida. El firewall de egress lo mata a nivel de red. No con logging, no con una alerta. La conexión sencillamente no llega a producirse.

Las VM de los runners tienen actualmente acceso a internet sin restricciones. Es como tener una base de datos sin firewall y confiar en que todo salga bien.

La public preview del firewall de egress llega entre finales de Q4 2026 y principios de Q1 2027, y la GA en algún momento de Q1 o Q2 2027.

Dependency locking mediante SHA

Esta la esperábamos desde hace años. Funciona como go.mod o package-lock.json. Cada action de su YAML recibe un hash SHA en lugar de un tag.

Hoy:

uses: actions/checkout@v4

El tag v4 es solo un puntero. Puede desplazarse a otro commit en cualquier momento. Un force push al tag y su siguiente build descarga código completamente distinto. Sin aviso.

Con locking:

uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11

Cambiar un SHA pasa a requerir una actualización explícita, y un workflow con una referencia sin bloquear ni siquiera arranca, porque la validación ocurre dentro del propio pipeline. Dependabot nunca llegó tan lejos. Puede actualizar las referencias SHA pero no puede obligar a nadie a usarlas. Un desarrollador añade una nueva action con un tag, Dependabot se queda callado, nadie se da cuenta.

Algunos equipos fijan los SHA a mano. Bien. Pero mantenerlo manualmente es trabajo extra y la mayoría de los equipos lo abandona al cabo de un tiempo (¿cuánta gente de su equipo sabe a qué SHA resuelve actions/setup-node@v4?). El soporte nativo de la plataforma lo resuelve igual que package-lock.json resolvió las dependencias de npm.

Public preview en Q3 o Q4 2026, GA entre Q4 2026 y Q1 2027.

Policy controls

Un framework de rulesets centralizado a nivel de organización. Los administradores definen quién puede disparar workflows, qué eventos se permiten, qué actions están aprobadas y qué runner labels son obligatorios. Un único lugar en vez de 40 pull requests en 40 repositorios.

Hoy esto se resuelve con un mosaico de branch protection rules, ficheros CODEOWNERS, required status checks y apaños. El resultado está fragmentado y es doloroso de auditar. Para los sectores regulados (banca, sanidad, sector público), el nuevo framework cubre los requisitos de audit trail de los que hablamos en el contexto de la estrategia de ciberseguridad de Eslovaquia para 2026 a 2030.

Pongamos un banco. Allí los despliegues a producción solo puede dispararlos un miembro del equipo de release-engineering, solo a través de la rama main, solo con un PR aprobado. Con el nuevo framework eso es una sola policy en un solo lugar. La public preview llega junto con el dependency locking en Q3 o Q4 2026.

Telemetría de CI/CD

Actions Data Stream, telemetría casi en tiempo real hacia S3 o Azure Event Hub. GitHub también anticipa una futura visibilidad a nivel de proceso. No solo «el paso X tardó 45 segundos», sino «el paso X lanzó los procesos A, B, C y abrió conexiones de red hacia estas direcciones».

Si un paso que normalmente tarda 30 segundos de repente corre durante 5 minutos, algo cambió. Hacer streaming hacia S3/Azure Event Hub significa que se conecta a su SIEM existente (Splunk, Elastic, Datadog) sin scripts propios. Útil para las auditorías de compliance y la investigación forense tras un incidente. La public preview abarca Q4 2026 y Q1 2027, GA junto con el firewall de egress en Q1 o Q2 2027.

Qué hacer ahora

Fije sus SHA con pinact o pin-github-action, es medio día de trabajo que reduce drásticamente el riesgo de la cadena de suministro. Revise los permisos de los tokens de workflow, porque la mayoría de los workflows no necesitan write sobre contents ni packages, así que cambie el valor por defecto a read. Deshágase de las third-party actions de autores desconocidos con 50 estrellas. Menos dependencias, menor superficie de ataque. Y averigüe cuántos secrets tiene su organización y cuándo se rotaron por última vez.

Dos puntos de partida decentes son la guía de hardening de seguridad de GitHub y el OWASP CI/CD Security Top 10.

La última vez que auditamos el pipeline de un cliente, encontramos 14 dependencias sin SHA pinning. Medio día para arreglarlo. Sin la auditoría seguirían sin saberlo. Si quiere averiguar en qué situación están sus pipelines, póngase en contacto.