Seguridad como Código: DevSecOps Spec-Driven sobre GitHub para Banca

El día que la charla se volvió real

El 18 de mayo de 2026 di una charla técnica de una hora en Techno Week 8.0, hospedada por el Banco de Costa Rica. La audiencia: desarrolladores y tomadores de decisión TI del sector financiero costarricense. El tema: cómo convertir la seguridad en código verificable, versionado y automatizado usando GitHub Actions y la OpenAPI Specification.

Este post es la charla extendida. Mi objetivo no es repetir las slides — es darte todo lo necesario para que implementes este enfoque en tu propia organización. Comandos, configuraciones, archivos completos, decisiones de diseño, y las preguntas difíciles que me hicieron (con sus respuestas).

Si solo querés ver cómo fue el evento detrás de cámaras, saltá al final del post. Si querés implementar esto en tu equipo, seguí leyendo en orden.

El problema: por qué este post existe

En abril de 2022, Costa Rica vivió uno de los ataques cibernéticos más serios de su historia. El grupo Conti atacó múltiples instituciones públicas con ransomware. El país declaró estado de emergencia nacional. Durante semanas, servicios críticos quedaron paralizados.

Ese fue el punto de inflexión. La ciberseguridad pasó de ser "algo de TI" a ser una prioridad de Estado.

A partir de ahí, todo cambió:

• Julio 2024: CONASSIF aprobó el Acuerdo 5-24, que obliga a todo el sistema financiero a tener gobierno de TI, SGSI formal, gestión de incidentes y resiliencia operativa.
• Febrero 2026: La Asamblea Legislativa aprobó en primer debate una ley que cambia las reglas del juego: si un banco sufre un breach y no puede demostrar que cumplía con los estándares de SUGEF, el banco es responsable ante el cliente afectado. No el hacker. El banco.

Y mientras tanto, las APIs se volvieron el vector de ataque número uno del sector financiero. Las cifras son brutales:

• 84% de las empresas tuvieron al menos un incidente de seguridad en APIs el año pasado ¹
• Solo el 13% logra prevenir más del 50% de los ataques
• $9.36 millones es el costo promedio de un breach en banca en EE.UU.
• 5.8 millones de registros fueron expuestos por 700Credit por una vulnerabilidad de API en 2025

Las APIs son donde se mueve el dinero. SINPE, transferencias, consultas de saldo, integraciones con partners — todo pasa por APIs. Si protegés las APIs, protegés el banco.

Pero acá está el problema: la seguridad tradicional no escala. Los code reviews manuales son inconsistentes. Los pen tests anuales encuentran problemas que ya están en producción. Los checklists de Excel se desactualizan en semanas.

La solución que propongo en esta charla es radical en su simpleza: convertir la seguridad en código.

_{[1] Fuente: State of API Security Report 2024, Salt Security. Disponible en https://content.salt.security/state-api-report.html}

La tesis: Security as Code

La idea central es esta:

Si la seguridad está escrita como código, vive en el mismo repositorio que tu aplicación. Se versiona. Se revisa en Pull Requests. Se ejecuta automáticamente. Y genera evidencia auditable.

Para que esto funcione necesitás una sola fuente de verdad que describa qué hace tu API, qué datos maneja, y cómo se debe proteger. Esa fuente es la OpenAPI Specification.

¿Qué es OpenAPI?

Pensá en la OpenAPI spec como el plano arquitectónico de tu API. Así como un arquitecto dibuja cada puerta, ventana y pared antes de construir la casa, la spec describe cada endpoint, qué acepta, qué retorna, y cómo se autentica.

Y al igual que los inspectores municipales usan el plano para verificar que la construcción cumple el código, las herramientas de seguridad usan la spec para verificar que tu API cumple las reglas.

Pero la diferencia clave es esta: el plano arquitectónico es estático. La OpenAPI spec genera pruebas, validaciones y documentación automáticamente.

Una nota histórica: Swagger vs OpenAPI

Mucha gente todavía dice "archivo Swagger". Es entendible — el estándar nació en 2011 con ese nombre. En 2015 fue donado a la Linux Foundation y renombrado a OpenAPI Specification. Hoy:

• OpenAPI = el estándar (la especificación)
• Swagger = las herramientas (Swagger UI, Swagger Editor, Swagger Codegen)

Es como decir "HTML es el estándar, Chrome es el navegador". El archivo correcto se llama openapi.yaml, no swagger.yaml. Pero ambos términos siguen vivos en conversación.

Ejemplo mínimo de una OpenAPI spec

openapi: "3.1.0"
info:
  title: SecureBank API
  description: API bancaria para transferencias
  version: "1.0.0"

servers:
  - url: https://api.banco.co.cr/v1
    description: Producción

paths:
  /accounts/{id}/balance:
    get:
      summary: Consultar saldo
      security:
        - BearerAuth: []
      parameters:
        - name: id
          in: path
          required: true
          schema:
            type: string
            format: uuid
      responses:
        "200":
          description: Saldo consultado exitosamente
          content:
            application/json:
              schema:
                $ref: "#/components/schemas/Balance"
        "401":
          description: No autenticado

components:
  securitySchemes:
    BearerAuth:
      type: http
      scheme: bearer
      bearerFormat: JWT
  schemas:
    Balance:
      type: object
      properties:
        available:
          type: number
          format: double
        currency:
          type: string
          enum: [CRC, USD]

Este archivo describe una API con un endpoint que requiere JWT y retorna un saldo. Pero no es solo documentación. Es un contrato ejecutable.

La arquitectura del pipeline: 7 etapas que cubren el OWASP API Top 10

El pipeline que mostré en la charla tiene 7 etapas. Cada una usa la OpenAPI spec como insumo. Las primeras 6 son open source. La séptima (CodeQL) requiere GitHub Advanced Security.

Etapa 1: Spec Lint con Spectral

Qué hace: Lee tu openapi.yaml y lo valida contra un conjunto de reglas. Si algo no cumple, falla.

Analogía: Es el corrector ortográfico de tu API. Así como Word subraya errores en rojo, Spectral subraya problemas de seguridad en tu spec.

Configuración:

# .spectral/.spectral-banking.yaml
extends: ["spectral:oas"]

rules:
  operation-security-defined:
    description: "Cada endpoint debe tener security definido"
    severity: error
    given: "$.paths[*][get,post,put,delete,patch]"
    then:
      field: "security"
      function: truthy

  no-http-servers:
    description: "Solo HTTPS está permitido en servidores"
    severity: error
    given: "$.servers[*].url"
    then:
      function: pattern
      functionOptions:
        match: "^https://"

  financial-amount-limits:
    description: "Montos deben tener máximo definido"
    severity: warn
    given: "$.components.schemas..properties.amount"
    then:
      field: "maximum"
      function: truthy

Por qué importa: Si un endpoint no tiene security definido en la spec, es un candidato a tener autenticación rota. Spectral lo detecta antes de que se escriba una sola línea de código.

Etapa 2: SAST con Semgrep

Qué hace: Lee tu código fuente buscando patrones de código peligrosos. No ejecuta nada — solo analiza.

Analogía: Es un detective que lee tu código buscando patrones sospechosos. SQL injection concatenado, secretos hardcodeados, uso inseguro de JWT, eval(), funciones criptográficas débiles.

Configuración en el pipeline:

- name: Run Semgrep
  uses: returntocorp/semgrep-action@v1
  with:
    config: >-
      p/owasp-top-ten
      p/nodejs
      p/jwt
      p/security-audit

Diferencia con SonarQube: SonarQube es excelente para calidad de código y deuda técnica. Semgrep está enfocado en seguridad. Son complementarios. Si ya tenés SonarQube, mantenelo — Semgrep agrega la capa de detección de patrones de seguridad específicos.

Etapa 3: Secret Detection con Gitleaks

Qué hace: Escanea todo el repositorio buscando secretos hardcodeados (API keys, passwords, tokens).

Configuración:

- name: Run Gitleaks
  uses: gitleaks/gitleaks-action@v2
  env:
    GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Importante: Gitleaks complementa (no reemplaza) Push Protection de GitHub Advanced Security. Push Protection bloquea antes del push. Gitleaks detecta después y escanea el historial completo. Los dos juntos dan defensa en profundidad.

Etapa 4: Dependency Check con npm audit

Qué hace: Escanea las dependencias buscando vulnerabilidades conocidas (CVEs).

Para Node.js:

- name: Audit dependencies
  run: npm audit --audit-level=high

Para otros lenguajes:

Lenguaje	Herramienta
Node.js	npm audit
.NET / C#	dotnet list package --vulnerable --include-transitive
Java	mvn dependency-check:check
Python	pip-audit
Go	govulncheck ./...
Ruby	bundle audit

Alternativa multi-lenguaje: OWASP Dependency-Check funciona con todos los ecosistemas y genera reportes unificados.

Etapa 5: DAST con OWASP ZAP

Qué hace: Levanta tu API en un container, le pasa la OpenAPI spec, y la ataca. Prueba inyección SQL, XSS, autenticación rota, BOLA — todo el OWASP API Top 10.

Analogía: Si Spectral revisa el plano de la casa, ZAP intenta entrar a la casa. SAST vs DAST: uno lee el código, el otro ataca la aplicación corriendo.

Configuración:

- name: ZAP API Scan
  uses: zaproxy/action-api-scan@v0.9.0
  with:
    target: "http://localhost:3000/api/v1"
    format: openapi
    docker_name: "ghcr.io/zaproxy/zaproxy:stable"

Modos de escaneo:

Modo	Duración	Profundidad	Uso
Baseline	~2 min	Superficial	CI rápido, cada PR
API Scan	~5 min	Media (spec-driven)	El que usamos
Full Scan	~30+ min	Profunda	Semanal o pre-release

Sobre falsos positivos: ZAP genera falsos positivos, especialmente con CORS y cache headers. La estrategia es: empezar solo con severidad High y Critical, manejar excepciones en un archivo rules.tsv versionado, y nunca ignorar nada silenciosamente. Cada falso positivo se documenta con justificación.

Etapa 6: Compliance Report Automatizado

Qué hace: Genera un reporte de compliance en Markdown que se postea automáticamente como comentario en el Pull Request.

compliance-report:
  needs: [spec-lint, sast, secrets, deps, dast]
  if: always() && github.event_name == 'pull_request'
  runs-on: ubuntu-latest
  steps:
    - name: Generate compliance report
      run: |
        echo "## 🛡️ DevSecOps Compliance Report" > report.md
        echo "" >> report.md
        echo "| Check | Status | Tool |" >> report.md
        echo "|-------|--------|------|" >> report.md
        echo "| Spec Lint | ${{ needs.spec-lint.result }} | Spectral |" >> report.md
        echo "| SAST | ${{ needs.sast.result }} | Semgrep |" >> report.md
        echo "| Secrets | ${{ needs.secrets.result }} | Gitleaks |" >> report.md
        echo "| Dependencies | ${{ needs.deps.result }} | npm audit |" >> report.md
        echo "| DAST | ${{ needs.dast.result }} | OWASP ZAP |" >> report.md
    
    - name: Post comment to PR
      uses: marocchino/sticky-pull-request-comment@v2
      with:
        path: report.md

Por qué sticky-pull-request-comment: Actualiza el mismo comentario en lugar de crear uno nuevo en cada corrida. El PR queda con un solo reporte siempre actualizado, no con 20 comentarios duplicados.

Etapa 7: CodeQL (GitHub Advanced Security)

Qué hace: Análisis semántico profundo. A diferencia de Semgrep que busca patrones, CodeQL entiende el flujo de datos: rastrea cómo un input del usuario viaja por el código hasta llegar a una query SQL o una respuesta HTTP.

# .github/workflows/codeql.yml
name: CodeQL Analysis
on:
  pull_request:
    branches: [main]
  schedule:
    - cron: '0 6 * * 1'  # Semanal, lunes 6am UTC

jobs:
  analyze:
    runs-on: ubuntu-latest
    permissions:
      security-events: write
    steps:
      - uses: actions/checkout@v4
      - uses: github/codeql-action/init@v3
        with:
          languages: javascript-typescript
          queries: security-and-quality
      - uses: github/codeql-action/autobuild@v3
      - uses: github/codeql-action/analyze@v3

CodeQL soporta: JavaScript/TypeScript, Python, Java/Kotlin, C#, C/C++, Go, Ruby, Swift. No soporta: PHP, Scala, Rust.

Costo: Repos públicos = gratis. Repos privados = GitHub Code Security a $30/committer/mes.

El problema del endpoint drift

Hay un escenario que el pipeline spec-driven no cubre directamente: ¿qué pasa si un developer agrega un endpoint en el código pero no lo documenta en la spec?

Spectral solo analiza lo que está en la spec. ZAP solo ataca lo que la spec describe. Si el endpoint no está en la spec, queda fuera del radar.

La solución: validación bidireccional con un script de drift detection.

detect-drift.js

Este script compara las rutas registradas en Express contra los paths de la OpenAPI spec. Si encuentra rutas en el código que no están en la spec, falla.

#!/usr/bin/env node

const fs = require("fs");
const yaml = require("js-yaml");
const app = require("../src/app");

function getExpressRoutes(app) {
  const routes = [];
  function extractFromStack(stack, basePath = "") {
    if (!stack) return;
    stack.forEach((layer) => {
      if (layer.route) {
        const methods = Object.keys(layer.route.methods);
        methods.forEach((method) => {
          routes.push({
            method: method.toUpperCase(),
            path: normalizePath(basePath + layer.route.path),
          });
        });
      } else if (layer.name === "router" && layer.handle?.stack) {
        const prefix = layer.regexp ? extractPrefix(layer.regexp) : "";
        extractFromStack(layer.handle.stack, basePath + prefix);
      }
    });
  }
  extractFromStack(app._router?.stack || []);
  return routes;
}

function normalizePath(path) {
  return path
    .replace(/:(\w+)/g, "{$1}")
    .replace(/\/+/g, "/")
    .replace(/\/$/, "");
}

function detectDrift(expressRoutes, specPaths) {
  const ignoredPatterns = ["/health", "/favicon.ico"];
  const specSet = new Set(specPaths.map((p) => `${p.method}:${p.path}`));
  return expressRoutes.filter((route) => {
    if (ignoredPatterns.some((p) => route.path === p)) return false;
    if (!route.path || route.path === "/") return false;
    return !specSet.has(`${route.method}:${route.path}`);
  });
}

// Main execution...
const drift = detectDrift(expressRoutes, specPaths);
if (drift.length === 0) {
  console.log("✅ No endpoint drift detected!");
  process.exit(0);
} else {
  console.log(`❌ ENDPOINT DRIFT DETECTED: ${drift.length} undocumented route(s)`);
  drift.forEach((route) => {
    console.log(`   ⚠️  ${route.method} ${route.path}`);
    console.log(`      → Exists in code but NOT in openapi.yaml`);
  });
  process.exit(1);
}

Integración en el pipeline

drift-check:
  name: "🔍 Drift — Spec vs Code"
  runs-on: ubuntu-latest
  steps:
    - uses: actions/checkout@v4
    - uses: actions/setup-node@v4
      with:
        node-version: "20"
        cache: "npm"
    - run: npm ci
    - run: node scripts/detect-drift.js

El resultado: entre Spectral (spec → código) y drift detection (código → spec), ningún endpoint puede existir sin contrato de seguridad. Es validación bidireccional.

Estandarización: cómo aplicar esto a 50 repositorios

Una pregunta común en la charla: "¿Cómo escalamos esto a toda la organización sin configurar el pipeline 50 veces?"

La respuesta: Reusable Workflows.

Workflow central (en el repo de la organización)

# org/.github/.github/workflows/devsecops.yml
name: Reusable DevSecOps Pipeline
on:
  workflow_call:
    inputs:
      spec-file:
        type: string
        default: "openapi.yaml"
      security-tier:
        type: string
        default: "standard"  # basic | standard | strict

jobs:
  spec-lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: stoplightio/spectral-action@latest
        with:
          file_glob: ${{ inputs.spec-file }}
  
  # Resto de los jobs según el tier...

Invocación desde cualquier repo

# Cualquier repo del banco: .github/workflows/security.yml
name: Security
on: [pull_request]
jobs:
  security:
    uses: org/.github/.github/workflows/devsecops.yml@main
    with:
      spec-file: openapi.yaml
      security-tier: strict
    secrets: inherit

Beneficio: Si actualizás el workflow central, todos los repos reciben la actualización automáticamente en la próxima corrida. No hay que tocar cada repo individualmente.

Organization Rulesets

Complementario a los Reusable Workflows, GitHub permite forzar checks a nivel de organización:

1. Settings de la organización → Rulesets
2. Crear regla: "Require status checks to pass before merging"
3. Especificar: security/spec-lint, security/sast, security/dast
4. Aplicar a: todos los repos con la propiedad tier: critical

Ahora ningún PR se puede mergear sin pasar el pipeline. No hay forma de saltársela.

Las preguntas difíciles (y sus respuestas)

Durante la sección de Q&A me hicieron varias preguntas que vale la pena documentar. Acá van con respuestas más extensas que las que pude dar en el momento.

"¿Esto no hace más lento el desarrollo?"

El pipeline tarda ~5 minutos. Un code review humano tarda entre 30 minutos y varias horas. La pregunta real no es "¿esto es lento?" sino "¿qué tan lento es encontrar una vulnerabilidad en producción?"

Un breach cuesta meses de investigación, parches de emergencia, notificaciones a SUGEF, y daño reputacional. 5 minutos por PR es trivial comparado con eso.

Y los developers no lo odian — lo que odian es esperar días por un code review que les dice "arreglá esta vulnerabilidad" cuando ya se olvidaron del contexto. El pipeline da feedback en minutos, no en días.

"¿Cuánto cuesta implementar esto?"

Repos públicos: cero. Todo es open source y GitHub Actions es gratis con minutos ilimitados.

Repos privados: el pipeline base no requiere licencias adicionales. Corre con el plan Free de GitHub que incluye 2,000 minutos/mes de Actions — suficiente para ~400 corridas del pipeline.

Si querés agregar CodeQL y Secret Scanning con Push Protection, GitHub Advanced Security desde abril 2025 se vende en dos productos:

• Secret Protection: $19/committer/mes
• Code Security: $30/committer/mes

Pero podés empezar sin GHAS. El pipeline base ya cubre 8 de las 10 vulnerabilidades del OWASP API Top 10.

"Esto reemplaza SonarQube?"

No. Son complementarios.

SonarQube es excelente para calidad de código, deuda técnica y métricas centralizadas. Este pipeline se enfoca en seguridad continua y spec-driven validation.

Ejemplo concreto:

• SonarQube te dice: "esta función tiene complejidad ciclomática de 25, debería refactorizarse"
• Semgrep te dice: "esta función está concatenando SQL con input del usuario — inyección SQL crítica"
• CodeQL te dice: "este input viaja por 5 funciones hasta llegar a una query SQL sin sanitizar"

Los tres aportan valor diferente. Los tres se quedan.

"¿Qué pasa con las APIs legacy que no tienen OpenAPI spec?"

Tres opciones:

1. Generarla desde el código con herramientas como swagger-jsdoc (Node), SpringDoc (Java), o anotaciones nativas en FastAPI (Python). Toma horas, no semanas.

2. Reverse engineering del tráfico con herramientas como Akto o API gateways modernos que analizan el tráfico HTTP y generan la spec.

3. Escribirla manualmente para APIs críticas o pequeñas.

La realidad: si una API no tiene spec, probablemente tampoco tiene tests automatizados ni validación de inputs. El problema no es la falta de spec — es la falta de disciplina de ingeniería. La spec es el primer paso para poner orden.

"ZAP genera muchos falsos positivos. ¿Cómo evitamos que el equipo ignore las alertas?"

Estrategia en cuatro pasos:

1. Empezar solo con severidad High y Critical. Los Medium y Low se analizan después.
2. Versionar el archivo rules.tsv donde se documentan las excepciones con justificación.
3. Proceso de revisión: un falso positivo lo aprueba otro developer o el security champion. Nada se ignora silenciosamente.
4. Mejora continua: cada falso positivo documentado reduce el ruido en futuras corridas.

Sí, va a haber falsos positivos. Pero prefiero 10 falsos positivos que descarto en 5 minutos a 1 verdadero positivo que se me escapa y llega a producción.

"¿El pipeline reemplaza un pen test manual?"

No. Son complementarios.

El pipeline cubre lo continuo y lo automatizable: cada PR, todos los días. El pen test manual cubre lo profundo y lo creativo: una vez al año, con pensamiento humano.

PCI-DSS lo dice explícitamente: el pipeline cubre los requisitos 6 (desarrollo seguro) y 11.3 (escaneos continuos), pero el requisito 11.4 (pen testing anual) sigue siendo obligatorio.

Analogía: el pipeline son las alarmas, cámaras y guardias del banco. El pen test manual es contratar un ladrón profesional una vez al año para que intente entrar y te diga cómo lo haría. Los dos son necesarios.

"¿Por qué APIs y no frontend o infraestructura?"

Porque las APIs son la superficie de ataque #1 del sector financiero. Las APIs son las que mueven dinero. Y a diferencia de frontends o infraestructura, las APIs tienen un estándar maduro (OpenAPI) que permite validación automatizada spec-driven.

Esto no significa que el frontend o la infraestructura no importan — importan. Pero si tenés que priorizar dónde poner seguridad automatizada primero, ponela en las APIs. Ahí está el dinero y ahí están los ataques.

La frase con la que cerré la charla

Pasé 60 minutos hablando de pipelines, herramientas y configuraciones. Pero al final, el mensaje es uno solo:

La seguridad no es un gate. Es un guardrail.

Un gate frena. Un guardrail guía.

No queremos developers frustrados peleando contra el equipo de seguridad. Queremos developers que escriban código seguro porque la plataforma se los hace fácil.

Y cuando SUGEF pregunte "¿cómo garantizan que sus APIs son seguras?", la respuesta no es un PDF de 300 páginas con políticas. La respuesta es un repositorio de GitHub donde cada Pull Request tiene su reporte de seguridad, cada deploy tiene su trazabilidad, y cada commit tiene su evidencia auditable.

Tu repositorio es la evidencia. Tu pipeline es el control. Tu spec es el contrato.

Recursos para implementar esto en tu equipo

Repositorio de ejemplo

El repositorio completo con todos los workflows, scripts y la API de demostración está disponible en mi GitHub: github.com/victorar42/techno-week

Incluye:

• API de ejemplo en Node.js/Express con endpoints bancarios
• OpenAPI 3.1 spec completa con security schemes
• 3 workflows de GitHub Actions (pipeline principal, CodeQL, reusable)
• Reglas custom de Spectral para banca
• Script de drift detection
• Guía de implementación paso a paso

Documentación oficial recomendada

• OpenAPI 3.1: spec.openapis.org/oas/v3.1.0
• OWASP API Top 10: owasp.org/API-Security
• GitHub Actions: docs.github.com/actions
• GitHub Advanced Security: docs.github.com/code-security
• Spectral: stoplight.io/open-source/spectral
• OWASP ZAP: zaproxy.org/docs
• Semgrep: semgrep.dev/docs

Regulación local

• Acuerdo CONASSIF 5-24: Buscar en el sitio de SUGEF
• Estrategia Nacional de Ciberseguridad 2023-2027: MICITT
• Ley de ciberseguridad bancaria (febrero 2026): Artículo de ECIJA

Detrás de cámaras: cómo fue dar la charla

Llegué al venue una hora y media antes. No por nervios — por estrategia. Quería tener tiempo de respirar, repasar conceptos que no quería que quedaran en el aire, y familiarizarme con el espacio.

Lo que no esperaba era el nivel de producción profesional del evento.

El maquillaje. Sí, te maquillan antes de subir al escenario. La razón es práctica: las luces de escenario son intensas y las cámaras capturan cada brillo, cada gota de sudor. El maquillaje neutraliza la luz y hace que te veas natural en pantalla.

El micrófono. Lavalier inalámbrico, conectado a un transmisor en el cinturón. Probaron el audio dos veces antes de subir. La diferencia entre un micrófono profesional y uno improvisado es brutal — la voz se escucha clara hasta el fondo del salón.

Las cámaras. Múltiples cámaras grabando desde diferentes ángulos. Un camarógrafo principal capturando todo el escenario, otros enfocados en mí y en las slides. Todo coordinado por un director de producción en una mesa de mezclas.

El equipo detrás. No es solo subir y hablar. Detrás del escenario hay un equipo completo: técnicos de sonido, operadores de cámara, director de producción, asistentes que cuidan que cada speaker llegue a tiempo, equipo de stage management que cuenta los minutos.

El clicker. Pequeño, ligero, con dos botones (siguiente y anterior). Por instrucción del evento no podía tener laptop en el escenario — solo el clicker. Esto cambió completamente mi estrategia: en lugar de demo en vivo, tuve que convertir todo en narración con screenshots de alta calidad.

Lo que aprendí:

1. Llegá temprano. Una hora y media no es exagerado. Es el tiempo necesario para que tu cerebro se calme, para hablar con el equipo de producción, y para repasar puntos críticos.

2. El equipo de producción es tu aliado. Conversá con ellos. Preguntales cómo prefieren que te muevas, dónde apuntar la mirada, qué señales te van a dar.

3. No improvisás en eventos así. Todo está cronometrado. Sabés exactamente cuándo entrás, cuándo salís, cuándo arranca el Q&A. La improvisación es para conversaciones de café, no para charlas con producción profesional.

4. La adrenalina es real. Pero también pasa. Después de los primeros 2 minutos, el cuerpo se calma y entrás en flow. Lo importante es no resistir la adrenalina inicial — usarla.

5. El público bancario es exigente pero respetuoso. No esperaba el nivel de preguntas técnicas que recibí. Pero también noté algo: cuando demostrás que dominás el tema, la audiencia te respeta y se compromete con tu charla.

Lo que sigue

Esta charla fue el principio de una conversación, no el final. Mi objetivo es seguir documentando lo que aprendo sobre DevSecOps en el sector financiero costarricense. En los próximos posts vas a encontrar:

• Entrevistas con CTOs, arquitectos y product managers sobre el estado de la tecnología en Latinoamérica
• Guías técnicas paso a paso para implementar componentes del pipeline
• Reflexiones sobre la intersección entre regulación bancaria, seguridad técnica y experiencia de developer

Si tenés preguntas, si querés implementar esto en tu organización, o si simplemente querés conversar sobre DevSecOps en banca, escribime. Esta es la dirección: josuevjar@gmail.com

Gracias a Banco de Costa Rica por la invitación a Techno Week 8.0. Gracias al equipo de producción por hacer que la experiencia fuera tan profesional. Y gracias a vos por leer hasta acá.

ardops.dev — Costa Rica.