ATALAIAUn equipo de una persona no puede hacerlo todo, así que la pregunta útil es qué hacer primero y cómo saber si funciona. Este plan asume un ingeniero de seguridad, unas pocas decenas de repositorios, un sistema de CI y al menos una cuenta cloud. Recorre la línea más o menos en el orden en que el código viaja por ella.
Cada bloque dura dos semanas. La regla de cada bloque es la misma: terminar con un control que se ejecute en todas partes, aunque sea básico, antes que un control perfecto en un único repositorio piloto.
Semanas 1-2: inventariar la línea
No puedes proteger lo que no has listado. Construye un inventario sencillo de repositorios, responsables, lenguajes, pipelines, destinos de deploy y quién tiene derechos de admin. Vale una hoja de cálculo. Casi todo se puede sacar de la API del control de versiones.
# list repositories with their default branch and archive status
gh repo list your-org --limit 500 \
--json name,defaultBranchRef,isArchived,visibility \
--jq '.[] | [.name, .defaultBranchRef.name, .isArchived, .visibility] | @tsv'Marca cada repositorio con un equipo responsable. Los repositorios sin responsable son el primer hallazgo del programa.
Semanas 3-6: estaciones de build y release
Dos bloques en la parte de la línea donde se escribe y se empaqueta el código.
- Protección de ramas y revisión. Exige pull requests y al menos una revisión en las ramas por defecto. Activa el secret scanning y la push protection donde tu plataforma lo permita.
- Secretos en CI. Añade Gitleaks como job no bloqueante en todas partes y hazlo bloqueante cuando el backlog esté limpio.
- Dependencias. Genera un SBOM con Syft y analízalo con Grype o Trivy. Empieza solo informando, para que los equipos vean la forma del problema antes de que falle nada.
- Higiene del pipeline. Fija las actions de terceros a SHAs de commit y pon los permisos por defecto del token de workflow en solo lectura. Ejecuta actionlint y zizmor para cazar los errores obvios.
# a minimal shared job, called from each repository
name: security-baseline
on: [pull_request]
permissions:
contents: read
jobs:
secrets:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@<pinned-sha>
with:
fetch-depth: 0
- run: gitleaks git --redact --exit-code 1 .Semanas 7-10: estaciones de run y diseño
Pasa a los dos extremos de la línea que un ingeniero en solitario suele saltarse.
- Ejecuta. Confirma que los logs de producción de autenticación, acciones de administración y el plano de control cloud acaban en un sitio donde se pueda buscar y se conservan el tiempo suficiente para investigar. Anota a quién se avisa ante un posible incidente.
- Diseño. Elige los dos o tres servicios que manejan dinero, credenciales o datos personales y haz una sesión corta de STRIDE con cada equipo. Una hora por servicio basta para sacar una lista de riesgos y responsables.
- Accesos. Revisa quién tiene admin en el control de código, el CI y la nube. Quita lo que no haga falta y documenta el resto.
Semanas 11-13: el programa alrededor
El último bloque convierte la actividad en un programa en el que la gente puede confiar.
- Rota de triageLos hallazgos llegan a una sola cola, con una persona designada cada semana y reglas de severidad por escrito.
- Objetivos de correcciónAcuerda con la dirección de ingeniería en cuánto tiempo debe corregirse cada severidad y cómo es una excepción.
- ChampionsUn ingeniero interesado por equipo que recibe avisos tempranos de los cambios y una línea directa con seguridad.
- Hoja de rutaUn plan de una página para los dos trimestres siguientes, basado en lo que mostraron las primeras 10 semanas.
Qué medir
Los recuentos de hallazgos por sí solos son ruido: suben al añadir un scanner y bajan al apagar uno. Mide un conjunto pequeño de cosas que puedas definir con precisión y que se muevan cuando el programa mejora.
| Mide | Definición | Por qué importa |
|---|---|---|
| Cobertura de controles | Porcentaje de repositorios activos con protección de ramas, escaneo de secretos y escaneo de dependencias habilitados a la vez | Te dice si la línea base está de verdad en todas partes |
| Tiempo de triage | Mediana de tiempo desde que se registra un hallazgo hasta que una persona lo acepta, rechaza o asigna | Muestra si la cola está viva o es un cementerio |
| Tiempo de corrección | Mediana de tiempo desde el triage hasta el cierre, por severidad | El número que le importa a dirección, y el que refleja la capacidad de ingeniería |
| Recurrencia | Porcentaje de hallazgos cerrados cuya regla vuelve a saltar en el mismo repositorio en menos de 90 días | Distingue las correcciones reales de las supresiones y los parches puntuales |
Informa de estas medidas cada mes en una página, como tendencias, junto con una nota breve sobre lo que ha cambiado. Si necesitas una quinta medida, que sea el número de servicios con un threat model vigente.
Qué hacer el lunes
- Exporta la lista de repositorios y añade una columna de responsable.
- Elige un control de las semanas 3-6 y despliégalo en modo solo informe en todos los repositorios esta semana.
- Reserva tres sesiones de diseño de una hora para los servicios que más importan.
- Escribe las cuatro definiciones de medidas de arriba en el wiki de tu equipo, para que el primer informe use las mismas palabras que el último.
Dónde encaja en la línea
En la torre (en desarrollo):