CI/CD y seguridad con el agente

Pipeline mejorado

Lint, tests, SAST y cachés optimizados sin romper lo existente

Cobertura y umbrales

Mínimos de cobertura que bloquean el merge si bajan

OWASP básico

Detección de vulnerabilidades automatizada en cada MR

Copilot CLI

ghcs y ghce para CI/CD desde la terminal

---

Conceptos clave

GitLab CI/CD con el agente

El equipo ya tiene CI/CD. El agente lo mejora y extiende sin romper lo que ya funciona.

Cómo instruir al agente para trabajar con el pipeline:

Analiza el fichero .gitlab-ci.yml actual.
No rompas la estructura ni los jobs existentes.

Propón cambios incrementales:
1. Añade un stage 'lint' con ESLint (Angular) y PHP CS Fixer (Laravel)
2. Añade un stage 'test' con Karma+Jasmine y PHPUnit con cobertura
3. Añade un stage 'sast' con PHPStan level 5
4. Optimiza los cachés: node_modules y vendor entre jobs

Para cada cambio:
- Muestra el diff exacto
- Explica qué hace y por qué
- Indica si necesita variables de entorno nuevas en GitLab CI

Ejemplo base — pipeline completo por etapas:

stages:
  - lint
  - test
  - sast
  - build
  - deploy

# ---------- LINT ----------

lint:angular:
  stage: lint
  image: node:20-alpine
  cache:
    key: node-$CI_COMMIT_REF_SLUG
    paths: [node_modules/]
  script:
    - npm ci
    - npx eslint src/ --max-warnings=0
    - npx prettier --check "src/**/*.{ts,html,scss}"

lint:laravel:
  stage: lint
  image: php:8.3-cli
  cache:
    key: composer-$CI_COMMIT_REF_SLUG
    paths: [vendor/]
  script:
    - composer install --no-interaction --prefer-dist
    - vendor/bin/php-cs-fixer fix --dry-run --diff

# ---------- TEST ----------

test:angular:
  stage: test
  image: node:20
  cache:
    key: node-$CI_COMMIT_REF_SLUG
    paths: [node_modules/]
  script:
    - npm ci
    - npx ng test --watch=false --browsers=ChromeHeadless --code-coverage
  coverage: '/Lines\s*:\s*(\d+\.\d+)%/'
  artifacts:
    reports:
      coverage_report:
        coverage_format: cobertura
        path: coverage/cobertura-coverage.xml

test:laravel:
  stage: test
  image: php:8.3
  services:
    - mysql:8.0
  variables:
    DB_CONNECTION: mysql
    DB_HOST: mysql
    DB_DATABASE: test_db
    DB_USERNAME: root
    DB_PASSWORD: ''
  script:
    - composer install --no-interaction
    - php artisan test --coverage --min=80
  coverage: '/^\s*Lines:\s*\d+.\d+\%/'

# ---------- SAST ----------

sast:phpstan:
  stage: sast
  image: php:8.3
  script:
    - composer install --no-interaction
    - vendor/bin/phpstan analyse app/ --level=5 --error-format=gitlab
  artifacts:
    reports:
      codequality: phpstan-report.json
  allow_failure: true

Cobertura y umbrales mínimos

El agente puede calcular y reforzar umbrales de cobertura en el pipeline. Si la cobertura baja del mínimo, el job falla antes del merge.

Laravel — cobertura con umbrales:

test:laravel:
  script:
    - php artisan test --coverage --min=80
  # --min=80 falla si la cobertura cae por debajo del 80%

Cómo usar el agente para mejorar la cobertura:

Analiza el informe de cobertura en coverage/lcov.info.
Identifica los 5 ficheros con menor cobertura que tengan más lógica de negocio.
Para cada uno, genera los tests que cubran los casos no cubiertos.

Diagnosticar pipelines fallidos con el agente

Con el GitLab MCP configurado, el agente puede acceder directamente al log del pipeline fallido:

Analiza el log del último pipeline fallido en el proyecto X.
Identifica la causa raíz del error.
Propón el fix concreto — muestra el diff exacto del cambio necesario.

Sin MCP, se puede pegar el log del error en el chat directamente y el agente lo diagnostica igual de bien.

Casos frecuentes que el agente resuelve bien:

• Comandos fallidos por dependencias no instaladas
• Tests fallidos por variables de entorno que faltan en CI
• Errores de permisos o rutas incorrectas
• Configuraciones de base de datos en los jobs de test

Environments y despliegues automáticos

Con el agente se pueden añadir stages de deploy a entornos con aprobación manual:

deploy:staging:
  stage: deploy
  environment:
    name: staging
    url: https://staging.empresa.com
  script:
    - ssh $DEPLOY_USER@$STAGING_HOST "cd /var/www && git pull && php artisan migrate --force"
  only:
    - dev

deploy:production:
  stage: deploy
  environment:
    name: production
    url: https://empresa.com
  when: manual # Requiere aprobación manual en GitLab
  script:
    - ssh $DEPLOY_USER@$PROD_HOST "cd /var/www && git pull && php artisan migrate --force"
  only:
    - main

Detección de vulnerabilidades en el pipeline

SAST básico automatizado en cada MR. El agente revisa el diff buscando patrones de vulnerabilidad. No sustituye una auditoría, pero bloquea los errores más comunes antes del merge.

OWASP Top 10 básico — qué buscar:

Vulnerabilidad	Señales en código	Fix
Inyección SQL	DB::statement("... $variable")	Bindings: ->where('id', $id)
XSS	{!! $variable !!} sin sanitizar	{{ $variable }} o DOMPurify
Exposición de datos	JSON con password/token en respuesta	makeHidden(['password'])
Auth rota	Endpoints sin auth middleware	Añadir middleware o Policy
Config insegura	APP_DEBUG=true en producción	Verificar .env por entorno

El Reviewer puede integrar el checklist en su informe:

---
name: Reviewer
---
# instrucciones existentes...

## Checklist de seguridad (en cada review)
- [ ] No hay queries SQL sin prepared statements o bindings
- [ ] Los inputs están validados (Form Requests en Laravel)
- [ ] No se exponen datos sensibles en respuestas API
- [ ] Todos los endpoints protegidos tienen middleware de auth
- [ ] No hay credenciales hardcodeadas en el código

Añadir revisión de seguridad al pipeline:

sast:semgrep:
  stage: sast
  image: returntocorp/semgrep
  script:
    - semgrep --config=p/owasp-top-ten --error .
  allow_failure: true
  artifacts:
    reports:
      sast: semgrep-report.json

Notificaciones de pipeline al equipo

El agente puede añadir notificaciones de resultado al pipeline. Con el GitLab MCP y/o webhooks:

notify:on-failure:
  stage: .post
  script:
    - curl -X POST $SLACK_WEBHOOK
        -d "{\"text\": \"Pipeline fallido en $CI_PROJECT_NAME - $CI_PIPELINE_URL\"}"
  when: on_failure
  only:
    - main
    - dev

Copilot CLI para trabajar con el pipeline desde la terminal

Cuando estás depurando un pipeline y necesitas construir o entender comandos de shell, gh copilot es más rápido que abrir el chat.

Instalación (ver bloque de Fundamentos si no está instalado):

gh extension install github/gh-copilot
eval "$(gh copilot alias -- bash)"  # activa los alias ghcs y ghce

Casos de uso frecuentes en CI/CD:

# No recuerdas cómo pasar variables de entorno a Docker en el pipeline
ghcs "run docker container passing env vars from file .env without exposing them"

# Entender un comando de deploy heredado en el .gitlab-ci.yml
ghce "rsync -avz --delete --exclude='.git' --exclude='storage/logs' src/ deploy@host:/var/www/"

# Construir el comando correcto para limpiar artefactos viejos
ghcs "delete gitlab artifacts older than 30 days using gitlab api and curl"

# Depurar un error de permisos en el job de CI
ghce "chmod -R 775 storage bootstrap/cache && chown -R www-data:www-data ."

Flujo real de diagnóstico desde terminal:

# 1. Ver el log del pipeline fallido (con GitLab CLI)
gh api /projects/:id/pipelines/:pipeline_id/jobs | jq '.[] | select(.status=="failed") | .id'

# 2. Entender el comando que falló
ghce "el comando que aparece en el log"

# 3. Construir el fix correcto
ghcs "descripción de lo que necesita hacer el comando fixed"

Cuándo usar CLI vs chat de VS Code:

Situación	Herramienta
Depurando en la terminal, en el servidor, con SSH	gh copilot
Revisando el .gitlab-ci.yml y quieres editar el fichero	Chat de VS Code / Agent
Script complejo con lógica + ficheros del repo	Chat de VS Code / Agent
Comando rápido de shell, git o docker que no recuerdas	gh copilot suggest

---

Tarea individual (entre sesiones)

Tiempo: 45–60 min · Entregable: pipeline mejorado en rama + CI pasando + Reviewer con OWASP

1. Aplicar las mejoras del pipeline en una rama del proyecto real: lint + test con cobertura + cachés

2. Añadir el stage sast:phpstan con level 5 y el stage sast:semgrep con p/owasp-top-ten

3. Hacer push de la rama y verificar que el CI completo pasa (lint, test, sast)

4. Actualizar el agente Reviewer con el checklist de seguridad OWASP — ejecutarlo sobre el código actual

5. Crear .github/prompts/analizar-pipeline.prompt.md que abra el agente con el .gitlab-ci.yml como contexto

6. Instalar y probar gh copilot en la terminal: usar ghcs para construir al menos 2 comandos reales de tu flujo de CI/CD

7. Anotar el tiempo de ejecución del pipeline antes y después de las mejoras — dato para la sesión de métricas