Fase 0 · Arranque

Sesión 1, segunda mitad. Todo el equipo.

Objetivo. Dejar listo el equipo, el repositorio, el Codespace y el primer pipeline en verde. Touchpoint de McGraw: no aplica. Esta fase prepara el terreno para los siete touchpoints.

Contenido de esta página
  1. Antes de empezar
  2. Pasos
    1. 1. Aceptar la tarea de Classroom
    2. 2. Abrir el Codespace
    3. 3. Levantar la app
    4. 4. Recorrer la app 10 minutos
    5. 5. Completar EQUIPO.md
    6. 6. Activar GitHub Pages
    7. 7. Confirmar el pipeline
  3. Predicción con revelación
  4. Checkpoint
  5. Errores comunes
  6. Pistas

Antes de empezar

  • Una cuenta de GitHub por persona. Si es estudiante verificado en GitHub Education, mejor: tendrá más horas de Codespaces y acceso a Copilot para el bonus.
  • El número de equipo y la app que le tocó en el sorteo.
  • El enlace de la tarea de GitHub Classroom de su app. Hay cuatro tareas, una por app; su equipo acepta solo la suya.

Pasos

1. Aceptar la tarea de Classroom

  1. Una sola persona abre el enlace de la tarea de su app, acepta y crea el equipo con el nombre exacto que dio el sorteo, por ejemplo equipo-1.
  2. Las demás personas abren el mismo enlace y se unen a ese equipo. No creen equipos nuevos.
  3. Classroom crea el repositorio sdlc-<app>-<equipo> en la organización del curso, por ejemplo sdlc-vampi-equipo-3. Es público y su equipo tiene permisos de administración: los necesita para Pages y para el ruleset de la fase 3.

2. Abrir el Codespace

En la página del repositorio: Code → Codespaces → Create codespace on main. La primera vez tarda unos minutos: construye el contenedor e instala Semgrep, pytest y requests. El Codespace trae Docker, gh y la extensión de Draw.io.

VS Code avisa cuando la app abre su puerto. Déjelo privado. Un puerto público expondría una app vulnerable a internet con su nombre.

Si el Codespace no abre, use el plan B: presione la tecla . en la página del repositorio para editar en github.dev. Ahí no puede levantar la app, pero todos los workflows corren en Actions.

3. Levantar la app 

bash lab/app.sh levantar   # construye la imagen desde app/ y la levanta
bash lab/app.sh rapido     # usa la imagen oficial del proyecto, si existe
bash lab/app.sh humo       # verifica que responde
bash lab/app.sh logs       # bitácora del contenedor
bash lab/app.sh detener    # la detiene y borra el contenedor
App Puerto Comando recomendado Primer recorrido
Juice Shop 3000 rapido: usa bkimminich/juice-shop:v20.3.0. Construir desde app/ compila el frontend de Angular y en 2 núcleos tarda bastante más Tienda en línea: registro, inicio de sesión, búsqueda, carrito, pedidos, reseñas, perfil
PyGoat 8000 levantar (no hay imagen oficial fijada) Regístrese en /register e inicie sesión en /login/. Es una plataforma de lecciones: concéntrese en usuarios, autenticación, puntajes y administración
VAmPI 5000 levantar No tiene interfaz web: es una API. Explórela con Swagger UI en /ui/. El script llama /createdb al arrancar para crear usuarios y libros de ejemplo
RailsGoat 3000 levantar Portal de empleados: inicio de sesión, pagos, vacaciones, mensajes, beneficios, área de administración

Si el puerto ya está ocupado: APP_PUERTO_HOST=8081 bash lab/app.sh levantar.

4. Recorrer la app 10 minutos

Úsela como una persona normal. Anote en un comentario del issue Fase 0:

  • qué hace la app y quién la usa;
  • qué roles existen (anónimo, cliente, administración);
  • qué datos guarda y cuáles serían graves si se filtraran.

Esas notas son la materia prima del DFD y de los casos de abuso.

5. Completar EQUIPO.md

Una fila por integrante: nombre, usuario de GitHub y el rol de cada sesión. Nadie repite rol. En el equipo de 5, la quinta persona de cada sesión toma Relatoría. Haga commit y push a main.

| Nombre | Usuario de GitHub | Sesión 2 (fases 1 y 2) | Sesión 3 (fase 3) | Sesión 4 (fase 4) | Sesión 5 (fase 5) |
|:---|:---|:---|:---|:---|:---|
| María Fernández | mfernandez | Arquitectura | AppSec | DevSecOps | Equipo rojo |

6. Activar GitHub Pages

Settings → Pages → Build and deployment → Source: GitHub Actions. No elija «Deploy from a branch». Luego vaya a Actions → Checkpoints → Run workflow para publicar el primer reporte. Su página queda en https://ic8071-sdlc-2026s2.github.io/<repositorio>/ y el tablero de la clase lee de ahí el archivo estado.json.

7. Confirmar el pipeline

En Actions, el workflow «Fase 0 · CI» construye la imagen de la app, la levanta en el runner y hace una prueba de humo. Debe terminar en verde. La primera corrida es la más lenta porque llena la caché de Docker.

Predicción con revelación

Antes de cada herramienta, el equipo escribe qué espera que pase y después compara. En la fase 0 la predicción es del laboratorio completo:

  1. Después del recorrido, cada persona escribe en el issue Fase 0 las tres debilidades que cree que tiene la app y qué técnica cree que las va a encontrar (ARA, SAST, SCA, secretos, DAST o pruebas).
  2. No discutan todavía. Guarden el comentario.
  3. En la fase 5, la sección 3 de la presentación compara esa predicción con lo que realmente encontró cada técnica.

El comentario queda con fecha y hora: esa es la evidencia de que la predicción fue antes.

Checkpoint

Identificador Condición Cómo se cumple
f0.equipo EQUIPO.md lista al menos 4 integrantes con usuario de GitHub El verificador lee la tabla de EQUIPO.md. La columna «Usuario de GitHub» debe tener el usuario tal cual, con o sin @, sin enlaces ni espacios. Las filas que dicen usuario no cuentan
f0.ci «Fase 0 · CI» terminó en verde en la rama principal Al menos una corrida exitosa de fase0-ci.yml en main
f0.pages GitHub Pages está activado El repositorio tiene Pages activado. Use la fuente «GitHub Actions» para que el reporte se publique

Cuando las tres condiciones se cumplen, el workflow cierra el issue Fase 0 y abre Fase 1. Si no pasa nada, espere a que termine «Checkpoints» o córralo a mano desde Actions.

Errores comunes

  • Crear un equipo nuevo en Classroom en vez de unirse. Classroom crea un repositorio por equipo; un equipo duplicado deja a una persona sola en otro repositorio. Avise al profesor para que lo corrija.
  • Escribir el usuario como enlace ([mfernandez](https://github.com/mfernandez)) o con el nombre completo. El verificador espera solo el usuario.
  • Elegir «Deploy from a branch» en Pages. f0.pages pasa, pero el reporte no se publica y el tablero muestra al equipo «sin Pages».
  • Construir Juice Shop desde app/ en el Codespace. Funciona, pero tarda. Use rapido en el Codespace; el runner de Actions sí construye desde app/.
  • Dejar el Codespace encendido. Consume horas de su cuota. Se detiene solo después de 30 minutos sin uso; deténgalo usted al terminar.

Pistas

Pista 1 · El issue «Fase 0» no aparece

El issue lo abre el workflow «Checkpoints» la primera vez que corre. Vaya a Actions → Checkpoints → Run workflow. Si el workflow falla, abra la corrida y lea el paso «Evaluar checkpoints».

Pista 2 · «Fase 0 · CI» falla

Abra la corrida y busque el primer paso en rojo. Si falla «Levantar la app y esperar a que responda», lea la bitácora del último paso: casi siempre la app tardó más que APP_ESPERA_SEGUNDOS o se detuvo al arrancar. Vuelva a correr el workflow: la segunda vez usa la caché.

Pista 3 · Todo está hecho pero el tablero no muestra al equipo

Revise tres cosas: que Pages use la fuente «GitHub Actions», que el job «publicar» de «Checkpoints» haya terminado en verde y que https://ic8071-sdlc-2026s2.github.io/<repositorio>/estado.json abra en el navegador. Si abre, el tablero lo leerá en la siguiente actualización, cada 60 segundos.

Siguiente: Fase 1 · Casos de abuso y requerimientos.

Volver arriba

IC-8071 Seguridad del Software · Instituto Tecnológico de Costa Rica · Laboratorio SDLC Seguro