Programa de 6 semanas para equipos técnicos
Un día de formación se olvida. Seis semanas de trabajo dejan el repositorio cambiado y con números.
Primero mido dónde está el equipo. Luego doy el workshop de desarrollo seguro, reviso con vosotros pull requests reales y en la semana 6 vuelvo a medir. Os quedáis con los controles puestos en vuestro repositorio, la evidencia para el auditor y un antes y un después con vuestros propios números.
Para equipos que mantienen aplicaciones web o APIs en producción. El workshop es presencial en vuestra empresa (de 5 a 8 horas según el equipo) y el resto lo hacemos en remoto. En español o en inglés.
Bonificable a través de FUNDAE.
El problema que ya tenéis
El equipo sale del curso con ganas y a las tres semanas el código es el de siempre
Si la formación es un solo día, lo aprendido tiene que competir con el sprint, las entregas y las incidencias. El control de acceso roto, la inyección o los secretos en el historial de git se quedan donde están por mucho que el equipo los entendiera un martes. Se van cuando alguien los busca en el código, los arregla y deja un test para que no vuelvan.
Y a quien os pide formación le suelen pedir que la demuestre. Si vendéis a bancos, tratáis pagos, tenéis ISO 27001 o pasáis una auditoría SOC 2, la formación de desarrolladores tiene que estar documentada, con fecha, contenido y asistentes. Con una lista de asistencia a veces no llega.
El programa cubre las dos cosas. Mido cómo estáis hoy, paso del workshop a vuestro repositorio revisando cambios reales y acabo volviendo a medir, para que quien decide vea qué se movió y qué no.
Resultado del programa
Qué tendréis al terminar la semana 6
Todo esto se lo podéis enseñar a quien tenga que aprobarlo. Ninguna parte depende de que yo prometa un porcentaje.
- 01
Un punto de partida medido
Indicadores que elegimos juntos sobre vuestro código y vuestro pipeline, medidos antes de dar una sola hora de formación.
Evidencia: ficha de diagnóstico con los valores de la semana 0. - 02
Controles puestos en vuestro repositorio
En el último bloque del workshop dejo las configuraciones y la checklist de pull request en una rama vuestra, y el equipo las revisa y las fusiona.
Evidencia: una rama con los cambios, en vuestro repositorio y con vuestros permisos. - 03
Dirección con decisiones en la mano, sin presentación de por medio
Entre tres y cinco páginas con lo que salió en el diagnóstico, lo que se trabajó y cinco acciones priorizadas, cada una con un responsable propuesto.
Evidencia: informe a dirección entregado en la semana 2. Ojo, no es una auditoría. - 04
Revisión de pull requests reales
Dos o tres cambios vuestros revisados por escrito con las mismas pautas del workshop, para que el equipo vea cómo se aplican sobre su código y no sobre el de unas prácticas.
Evidencia: comentarios por escrito sobre vuestros propios pull requests. - 05
Un antes y un después con vuestros números
Los mismos indicadores de la semana 0, medidos otra vez en la semana 6, con lo que se movió, lo que no y qué creo yo que ha pasado.
Evidencia: comparativa de la semana 0 contra la semana 6.
Cómo se desarrolla
Seis semanas, cinco fases
Cada fase tiene un responsable (el equipo o yo) y un entregable. El programa incluye el workshop de desarrollo seguro completo, y su temario está en su propia ficha.
Diagnóstico y medición inicial
El equipo contesta una encuesta de 10 minutos sobre su stack, sus prácticas y sus dudas. Yo miro una muestra de código y de pipeline que me dejéis ver y acordamos entre 4 y 6 indicadores. Con todo eso adapto los laboratorios a vuestro stack.
Entregable: Ficha de diagnóstico con la medición inicial.Workshop presencial (5 a 8 horas según el equipo)
Doy el workshop completo en vuestras instalaciones. El último bloque lo hacemos sobre vuestro repositorio y ahí dejo en una rama vuestra las configuraciones y la checklist de pull request. El equipo decide qué fusiona.
Entregable: Rama con configuraciones y checklist; certificados individuales.Evidencia e informe a dirección
Preparo el paquete de evidencia con la asistencia firmada el día del workshop. Con lo que salió en el diagnóstico y en el bloque sobre vuestro código escribo el informe para dirección, os lo presento y lo comentamos.
Entregable: Paquete de evidencia e informe de 3 a 5 páginas con 5 acciones priorizadas.Canal de dudas y revisión de pull requests
Abrimos un canal en vuestro Slack o Teams. Respondo en dos días laborables y se cierra al final de la semana 5. El equipo me manda dos o tres pull requests que quiera revisar con las pautas del workshop y yo los comento por escrito.
Entregable: Comentarios escritos sobre 2 o 3 pull requests.Revisión remota y segunda medición
Noventa minutos con el equipo para ver qué se ha aplicado, qué no y por qué, y ajustar las configuraciones si hace falta. Antes de la sesión repetimos la medición con los mismos indicadores de la semana 0.
Entregable: Comparativa entre la semana 0 y la semana 6.
La semana 1 es el workshop completo, con su temario y sus prácticas: Desarrollo seguro
Medir en lugar de prometer
Los indicadores se eligen con vosotros y se miden dos veces
No te voy a prometer que vuestro código tendrá un porcentaje menos de vulnerabilidades. Depende de lo que apliquéis y cualquier cifra que os diera me la estaría inventando. Lo que hago es medir lo mismo antes y después, con vuestros datos, y contaros lo que se movió. Estos son los candidatos y elegimos entre cuatro y seis.
Hallazgos de SAST por pull request
Cuántos hallazgos nuevos entran en cada cambio, medidos sobre una ventana de pull requests anterior y otra posterior.
Pull requests revisados con la checklist de autorización
Qué proporción de los cambios que tocan endpoints pasa por la checklist del programa.
Secretos detectados en el repositorio y en su historial
Cuántos encuentra un escáner de secretos y cuántos se han rotado y retirado en la semana 6.
Dependencias con vulnerabilidad conocida y tiempo de corrección
Cuántas tiene el repositorio y cuánto tarda el equipo en actualizar las críticas.
Pipelines con lockfile y acciones fijadas por SHA
Qué proporción de los pipelines instala desde el lockfile y referencia las acciones por commit completo.
Confianza del equipo, por encuesta
Las mismas preguntas en la semana 0 y en la 6 sobre si saben revisar autorización, entradas y dependencias. Es una percepción y lo cuento como tal.
Curso o programa
| Si necesitáis | Workshop | Programa |
|---|---|---|
| Que el equipo aprenda a explotar y arreglar los fallos más repetidos. | Con el curso vale. Un día, seis laboratorios y el bloque sobre vuestro código. | Incluye el curso entero. |
| Saber si algo ha cambiado semanas después. | No mide nada. Os lleváis plantillas y la medición la hacéis vosotros. | Medición en la semana 0 y en la 6, con los mismos indicadores. |
| Que dirección vea qué hacer y en qué orden. | No lleva informe. Los hallazgos se quedan en el equipo. | Informe de 3 a 5 páginas con cinco acciones priorizadas. |
| Que el equipo aplique lo del workshop a su código, con alguien que lo revise. | Cada uno trabaja en su portátil durante el último bloque. | Canal de dudas y revisión escrita de 2 o 3 pull requests vuestros. |
Lo que se queda en la empresa
Entregables del programa
Todo es vuestro desde la semana en que se entrega. El material de laboratorio tiene licencia de uso interno durante 12 meses.
- Ficha de diagnósticoLo que contesta el equipo en la encuesta, lo que veo en la muestra de código y los indicadores de la medición inicial.
- Configuraciones y checklist de PR en una rama vuestraChecklist de autorización por endpoint y gates de CI adaptados a vuestro pipeline. Es una plantilla técnica y vuestro equipo la revisa antes de fusionar.
- Paquete de evidencia de cumplimientoAsistencia firmada, certificado individual con fecha, horas y contenidos, temario mapeado a las normas que os apliquen y una carta de una página para el auditor.
- Informe a direcciónDe 3 a 5 páginas, con cinco acciones priorizadas y responsable propuesto para cada una.
- Revisión escrita de 2 o 3 pull requestsComentarios sobre cambios reales vuestros, en vuestra plataforma o sobre fragmentos, lo que prefiráis.
- Comparativa de la mediciónSemana 0 y semana 6 con los mismos indicadores, y lo que yo vigilaría en los meses siguientes.
- Repositorio de laboratorios con solucionesByteBazaar, los enunciados y las soluciones. Con licencia de uso interno durante 12 meses, para repetirlos con quien se incorpore.
Incluido en el programa
Cuatro cosas que os lleváis además del trabajo de las seis semanas
Son las mismas que vienen con el curso. En el programa van metidas en las fases en lugar de ir sueltas.
- +1
Paquete de evidencia de cumplimiento
Asistencia firmada, certificado individual con fecha, horas y contenidos, temario mapeado a las normas que os apliquen y una carta de una página para el auditor.
- +2
Encuesta previa al equipo
Diez minutos por persona en la semana 0 para adaptar los laboratorios a vuestro stack. Si no llega a tiempo, sigo con el temario estándar.
- +3
Configuraciones en una rama de vuestro repositorio
Gates de CI y checklist de pull request, que dejo en el último bloque del workshop. Es una plantilla técnica que revisa y fusiona vuestro equipo.
- +4
Repositorio de laboratorios con soluciones
Las prácticas del día para repetirlas con quien entre al equipo. Con licencia de uso interno durante 12 meses.
Cumplimiento
Qué evidencia deja el programa y para qué sirve
El programa deja la formación documentada. No certifica que cumplís ninguna norma, eso lo valora vuestro auditor, y este registro es una de las piezas que puede usar.
| Norma | Qué pide | Qué os dejo como evidencia |
|---|---|---|
| PCI DSS 4.0 · 6.2.2 | Formación al menos cada 12 meses para el personal que desarrolla software a medida, en diseño seguro, codificación segura y herramientas de testing, documentada. | Temario mapeado a los puntos del requisito, asistencia firmada y certificado individual con fecha. |
| ISO/IEC 27001:2022 · A.6.3 | Concienciación, educación y formación en seguridad adecuadas a la función de cada persona. | Registro por persona y por rol con contenidos y fecha. |
| ISO/IEC 27001:2022 · A.8.25 y A.8.28 | Ciclo de desarrollo seguro y codificación segura, que incluye formar a quien programa. | Temario mapeado y la checklist de pull request y los gates de CI que quedan en vuestra rama. |
| SOC 2 · CC1.4 y CC2.2 | Programa de formación documentado, con registros de finalización por empleado y profundidad según el rol. | Lista con nombre, fecha, contenido y rol, más el informe a dirección. |
| DORA · artículo 13(6) | Programas de formación en resiliencia operativa digital para el personal de entidades financieras, proporcionales a su función. | Registro de asistencia y temario, para quien está dentro del ámbito de DORA. |
A quién va dirigido
Para un equipo que quiere acabar con el repositorio cambiado y con números
Encaja especialmente con
- Equipos que mantienen aplicaciones web o APIs en producción.
- Tech leads y responsables de ingeniería a quienes les piden demostrar que el equipo está formado en desarrollo seguro.
- Empresas con PCI DSS, ISO 27001, SOC 2 o DORA en el horizonte, que necesitan documentar la formación de quien programa.
- Equipos que prefieren una comparativa de antes y después a una promesa.
No es la formación adecuada si
- Buscáis una charla de inspiración para todo un departamento.
- Tenéis que formar a doscientas personas. Para eso sale más barata una plataforma de formación.
- Esperáis una auditoría o un pentest. Aquí el equipo busca en su propio código y no hay informe de hallazgos técnicos.
- Os basta con una jornada. Entonces, el curso solo.
Quién lo imparte
Seguridad y desarrollo contados por alguien que ha trabajado en los dos lados
Soy Daniel Alfocea y llevo veinte años en desarrollo y seguridad. En Banco Santander fui Principal Engineer del departamento de IA cuando se puso en marcha el área. En BBVA fui Tech Lead de ciberseguridad. En 42Crunch, en Reino Unido, fui responsable de uno de sus productos de seguridad de APIs.
He presentado investigación en RSA Conference y en OWASP AppSec EU, y he sido ponente habitual de RootedCON. El Instituto Nacional de Ciberseguridad (INCIBE) me ha llamado varias veces como juez de sus concursos. Fundé Navaja Negra y el capítulo de OWASP Madrid. Soy autor de herramientas de seguridad muy usadas, como GoLismero, Plecost y Dockerscan, y de LAPIS, una investigación publicada en arXiv sobre cómo describirle una API a un modelo con menos tokens. Con Alfonso Muñoz escribí MCP Seguro. Guía práctica para desarrolladores, arquitectos software y tech leads.
La aplicación de los laboratorios es mía y es pública. Las seis semanas las llevo yo de principio a fin, de la medición inicial a la revisión final.
Si algo no funciona
Lo que arreglo yo sin cobraros un euro
Configuraciones que no funcionan
Si las configuraciones que dejo en vuestro repositorio no funcionan en vuestro pipeline, las arreglo en una sesión remota sin coste y repetimos la revisión de la semana 6.
Equipo atascado a los 30 días
Si a los 30 días de la revisión final el equipo se ha atascado aplicando algo del programa, os dedico una hora en remoto, gratis.
Esto no es una auditoría y no os prometo menos vulnerabilidades ni un porcentaje de mejora. Lo que os dejo es el antes y el después, medidos con vuestros números.
Formato
Una propuesta cerrada, después de hablar con vosotros
El precio depende de la duración y del tamaño del equipo, y lo cerramos tras una llamada porque también cuentan el tamaño del código que haya que revisar y cuántos indicadores acordemos. Incluye el workshop completo, el paquete de evidencia, el informe a dirección, el canal de dudas, la revisión de pull requests, la revisión final y la segunda medición.
- Participantes del mismo equipo o de áreas que trabajan juntas.
- Workshop presencial en vuestra empresa y el resto en remoto. En español o en inglés.
- Sala, pantalla, wifi y portátiles a cargo de la empresa, con Docker instalado y acceso al repositorio de cada participante.
- Acceso a una muestra de código y de pipeline para el diagnóstico, en vuestra plataforma y con vuestros permisos.
- Desplazamiento fuera de Madrid acordado antes de cerrar la fecha.
Antes de pedir la llamada