1 
2Una vulnerabilidad encontrada mientras se escribe codigo le cuesta a un desarrollador minutos en corregirla. La misma vulnerabilidad detectada en produccion cuesta un sprint. Y si un atacante la encuentra primero, cuesta millones. Este es el argumento central de la **shift-left security**  -  mover los controles de seguridad lo mas temprano posible en el ciclo de vida del desarrollo.
3 
4DevSecOps toma esta idea y la convierte en una practica: la seguridad no es una fase separada al final, sino un proceso continuo integrado en cada etapa del desarrollo, desde la primera linea de codigo hasta el despliegue en produccion.
5 
6## El coste de la seguridad tardia
7 
8El informe Cost of a Data Breach de IBM ha demostrado consistentemente que el coste de corregir problemas de seguridad crece exponencialmente cuanto mas tarde se detectan:
9 
10| Etapa | Coste de correccion | Tiempo de correccion |
11|-------|---------------------|----------------------|
12| **IDE / Desarrollo local** | Minutos | Segundos a minutos |
13| **Code review / PR** | Horas | Minutos a horas |
14| **Pipeline CI/CD** | Dias | Horas a dias |
15| **Staging / QA** | Semanas | Dias |
16| **Produccion** | Meses | Semanas a meses |
17| **Post-breach** | Millones ($) | Meses a anos |
18 
19La conclusion es clara: cada etapa en la que adelantas la seguridad ahorra un orden de magnitud en coste y tiempo.
20 
21## La pipeline DevSecOps
22 
23Una pipeline DevSecOps madura integra controles de seguridad en cada etapa:
24 
25```mermaid
26graph LR
27    IDE[IDE / Editor] --> PC[Pre-commit Hooks]
28    PC --> PR[Pull Request]
29    PR --> CI[CI Pipeline]
30    CI --> Build[Build / Package]
31    Build --> Deploy[Deploy]
32    Deploy --> Runtime[Runtime / Production]
33 
34    IDE -.- S1[SAST\nSecret Detection\nLinting]
35    PC -.- S2[Secrets Scan\nFormat Check]
36    PR -.- S3[Code Review\nDependency Audit]
37    CI -.- S4[SAST\nSCA\nContainer Scan\nSBOM]
38    Build -.- S5[Image Signing\nArtifact Verification]
39    Deploy -.- S6[Policy Enforcement\nAdmission Control]
40    Runtime -.- S7[DAST\nWAF\nMonitoring]
41```
42 
43Desglosemos cada etapa con herramientas y configuraciones concretas.
44 
45## Etapa 1: seguridad en el IDE
46 
47El ciclo de feedback mas rapido. Detecta vulnerabilidades antes incluso de guardar el archivo.
48 
49### Herramientas recomendadas
50 
51- **Semgrep**: analisis estatico ligero con reglas de la comunidad para vulnerabilidades OWASP
52- **Snyk IDE Extension**: escaneo en tiempo real de vulnerabilidades en dependencias
53- **GitLens + GitLeaks**: detecta secrets en tu editor
54- **ESLint Security Plugins**: `eslint-plugin-security` para Node.js, `eslint-plugin-no-unsanitized` para DOM XSS
55 
56### Ejemplo: configuracion ESLint para seguridad
57 
58```json
59{
60  "extends": ["eslint:recommended"],
61  "plugins": ["security", "no-unsanitized"],
62  "rules": {
63    "security/detect-object-injection": "warn",
64    "security/detect-non-literal-regexp": "warn",
65    "security/detect-unsafe-regex": "error",
66    "security/detect-buffer-noassert": "error",
67    "security/detect-eval-with-expression": "error",
68    "security/detect-no-csrf-before-method-override": "error",
69    "security/detect-possible-timing-attacks": "warn",
70    "no-unsanitized/method": "error",
71    "no-unsanitized/property": "error"
72  }
73}
74```
75 
76## Etapa 2: Pre-commit Hooks
77 
78La segunda linea de defensa. Se ejecutan automaticamente antes de cada commit, bloqueando codigo peligroso para que no entre en el repositorio.
79 
80### Gitleaks: intercepta secrets antes de que lleguen a Git
81 
82El error de seguridad mas comun en los codebases es hacer commit de secrets  -  claves API, contrasenas de bases de datos, tokens. Una vez que un secret llega al historial de git, es extremadamente dificil eliminarlo por completo (incluso con force pushes, los forks y caches pueden retenerlo).
83 
84```yaml
85# .pre-commit-config.yaml
86repos:
87  - repo: https://github.com/gitleaks/gitleaks
88    rev: v8.21.0
89    hooks:
90      - id: gitleaks
91 
92  - repo: https://github.com/semgrep/semgrep
93    rev: v1.90.0
94    hooks:
95      - id: semgrep
96        args: ['--config', 'auto']
97```
98 
99Instala y activa:
100 
101```bash
102pip install pre-commit
103pre-commit install
104```
105 
106Ahora cada `git commit` escanea automaticamente en busca de secrets filtrados y vulnerabilidades comunes. Si se encuentra algo, el commit se bloquea.
107 
108### Reglas personalizadas de Gitleaks
109 
110Puedes agregar patrones personalizados para los secrets de tu organizacion:
111 
112```toml
113# .gitleaks.toml
114title = "Custom Gitleaks Config"
115 
116[[rules]]
117id = "internal-api-key"
118description = "Internal API key detected"
119regex = '''INTERNAL_KEY_[A-Za-z0-9]{32}'''
120tags = ["key", "internal"]
121```
122 
123## Etapa 3: seguridad de la pipeline CI/CD
124 
125Aqui es donde ocurre el trabajo pesado. Tu pipeline CI deberia ejecutar multiples escaneos de seguridad en cada pull request.
126 
127### SAST (Static Application Security Testing)
128 
129Las herramientas SAST analizan el codigo fuente sin ejecutarlo, buscando patrones que indican vulnerabilidades.
130 
131```yaml
132# .github/workflows/security.yml
133name: Security Scan
134on:
135  pull_request:
136    branches: [main]
137 
138jobs:
139  sast:
140    name: Static Analysis
141    runs-on: ubuntu-latest
142    steps:
143      - uses: actions/checkout@v4
144 
145      - name: Run Semgrep
146        uses: semgrep/semgrep-action@v1
147        with:
148          config: >-
149            p/owasp-top-ten
150            p/typescript
151            p/nodejs
152            p/react
153          generateSarif: true
154 
155      - name: Upload SARIF
156        uses: github/codeql-action/upload-sarif@v3
157        with:
158          sarif_file: semgrep.sarif
159```
160 
161El ruleset `p/owasp-top-ten` de Semgrep detecta las vulnerabilidades mas comunes: SQL injection, XSS, SSRF, path traversal, deserializacion insegura y mas.
162 
163### SCA (Software Composition Analysis)
164 
165El SCA escanea tus dependencias en busca de vulnerabilidades conocidas. Esto es fundamental  -  mas del 80 % del codigo de las aplicaciones modernas proviene de dependencias open-source.
166 
167```yaml
168  dependency-scan:
169    name: Dependency Audit
170    runs-on: ubuntu-latest
171    steps:
172      - uses: actions/checkout@v4
173 
174      - name: Run Snyk
175        uses: snyk/actions/node@master
176        env:
177          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
178        with:
179          args: --severity-threshold=high
180 
181      - name: npm audit
182        run: npm audit --audit-level=high
183```
184 
185### Seguridad de contenedores con Trivy
186 
187Si construyes imagenes Docker, escanearlas en busca de vulnerabilidades es esencial. **Trivy** es el scanner de contenedores open-source mas popular.
188 
189```yaml
190  container-scan:
191    name: Container Security
192    runs-on: ubuntu-latest
193    steps:
194      - uses: actions/checkout@v4
195 
196      - name: Build image
197        run: docker build -t my-app:${{ github.sha }} .
198 
199      - name: Run Trivy
200        uses: aquasecurity/trivy-action@master
201        with:
202          image-ref: my-app:${{ github.sha }}
203          format: 'sarif'
204          output: 'trivy-results.sarif'
205          severity: 'CRITICAL,HIGH'
206          exit-code: '1'
207 
208      - name: Upload Trivy SARIF
209        uses: github/codeql-action/upload-sarif@v3
210        with:
211          sarif_file: trivy-results.sarif
212```
213 
214### Generacion de SBOM
215 
216Una **Software Bill of Materials (SBOM)** es un inventario completo de cada componente de tu aplicacion. Es cada vez mas requerida por los marcos de cumplimiento y las regulaciones gubernamentales (la Orden Ejecutiva de EE.UU. sobre Ciberseguridad exige SBOM para el software federal).
217 
218```yaml
219  sbom:
220    name: Generate SBOM
221    runs-on: ubuntu-latest
222    steps:
223      - uses: actions/checkout@v4
224 
225      - name: Generate SBOM with Syft
226        uses: anchore/sbom-action@v0
227        with:
228          format: spdx-json
229          output-file: sbom.spdx.json
230 
231      - name: Upload SBOM
232        uses: actions/upload-artifact@v4
233        with:
234          name: sbom
235          path: sbom.spdx.json
236```
237 
238## Etapa 4: imagenes Docker seguras
239 
240Una imagen Docker de produccion deberia seguir el principio de minimo privilegio. Asi es como luce un Dockerfile reforzado:
241 
242```dockerfile
243# Build stage
244FROM node:22-alpine AS builder
245WORKDIR /app
246COPY package.json package-lock.json ./
247RUN npm ci
248COPY . .
249RUN npm run build
250 
251# Production stage
252FROM node:22-alpine AS runner
253WORKDIR /app
254 
255# Install dumb-init before dropping root
256RUN apk add --no-cache dumb-init
257 
258# Don't run as root
259RUN addgroup -S app && adduser -S app -G app
260 
261# Copy only what's needed
262COPY --from=builder --chown=app:app /app/dist ./dist
263COPY --from=builder --chown=app:app /app/node_modules ./node_modules
264COPY --from=builder --chown=app:app /app/package.json ./
265 
266# Drop to non-root user
267USER app
268ENTRYPOINT ["dumb-init", "--"]
269 
270# Health check
271HEALTHCHECK --interval=30s --timeout=3s --retries=3 \
272  CMD wget -qO- http://localhost:3000/health || exit 1
273 
274EXPOSE 3000
275CMD ["node", "dist/server.js"]
276```
277 
278Practicas clave:
279 
2801. **Usa builds multi-stage**: el stage builder tiene las dependencias de desarrollo; el stage runner solo tiene el codigo de produccion
2812. **No ejecutes como root**: crea un usuario no-root y cambia a el
2823. **Usa imagenes Alpine**: superficie de ataque reducida (menos paquetes instalados por defecto)
2834. **Fija las versiones de las imagenes**: `node:22-alpine` en lugar de `node:latest` para evitar ataques a la supply chain
2845. **Usa `npm ci`**: instalaciones deterministas desde el lock file, no `npm install`
285 
286## Etapa 5: gestion de secrets
287 
288Los secrets hard-coded son la causa numero uno de las brechas en los incidentes provocados por desarrolladores.
289 
290### Que NO hacer
291 
292```typescript
293// NEVER do this
294const API_KEY = "sk-1234567890abcdef";
295const DB_PASSWORD = "supersecret123";
296 
297const client = new Client({
298  connectionString: `postgres://admin:${DB_PASSWORD}@db.example.com/prod`
299});
300```
301 
302### Que hacer en su lugar
303 
304```typescript
305// Use environment variables
306const client = new Client({
307  connectionString: process.env.DATABASE_URL
308});
309 
310// Or use a secret manager
311import { SecretManagerServiceClient } from '@google-cloud/secret-manager';
312 
313const client = new SecretManagerServiceClient();
314const [version] = await client.accessSecretVersion({
315  name: 'projects/my-project/secrets/db-password/versions/latest',
316});
317const dbPassword = version.payload?.data?.toString();
318```
319 
320### Jerarquia de la gestion de secrets
321 
322```mermaid
323graph TD
324    A[Secret Manager\nAWS Secrets Manager\nGCP Secret Manager\nHashiCorp Vault] --> B[Best: Rotated, audited, centralized]
325    C[Environment Variables\nInjected at deploy time] --> D[Good: Not in code, but static]
326    E[.env files\nWith .gitignore] --> F[Acceptable: Local development only]
327    G[Hard-coded in source] --> H[NEVER: Instant breach risk]
328 
329    style A fill:#d4edda
330    style C fill:#fff3cd
331    style E fill:#ffeeba
332    style G fill:#f8d7da
333```
334 
335## El OWASP Top 10: referencia rapida
336 
337Todo desarrollador deberia conocer el OWASP Top 10. Version resumida:
338 
339| # | Vulnerabilidad | Que es | Prevencion |
340|---|----------------|--------|------------|
341| 1 | **Broken Access Control** | Usuarios accediendo a recursos no autorizados | Denegar por defecto, validar en el servidor |
342| 2 | **Cryptographic Failures** | Cifrado debil, datos en texto plano | Usar algoritmos robustos (AES-256, bcrypt), TLS en todas partes |
343| 3 | **Injection** | SQL, NoSQL, OS command injection | Consultas parametrizadas, validacion de entradas |
344| 4 | **Insecure Design** | Arquitectura con fallos | Threat modeling, secure design patterns |
345| 5 | **Security Misconfiguration** | Credenciales por defecto, buckets cloud abiertos | Valores por defecto reforzados, auditorias automatizadas de configuracion |
346| 6 | **Vulnerable Components** | CVE conocidas en dependencias | Escaneo SCA, actualizaciones regulares |
347| 7 | **Auth Failures** | Contrasenas debiles, sesiones comprometidas | MFA, rate limiting, gestion segura de sesiones |
348| 8 | **Data Integrity Failures** | Actualizaciones no firmadas, CI/CD no confiable | Code signing, SBOM, integridad de la pipeline |
349| 9 | **Logging Failures** | Sin pista de auditoria | Logging estructurado, alertas sobre anomalias |
350| 10 | **SSRF** | Server-side request forgery | Allowlist de URLs salientes, validacion de entradas |
351 
352## Workflow completo de seguridad con GitHub Actions
353 
354Un workflow completo y listo para produccion que combina todo lo anterior:
355 
356```yaml
357# .github/workflows/security.yml
358name: Security Pipeline
359on:
360  pull_request:
361    branches: [main]
362  push:
363    branches: [main]
364 
365permissions:
366  contents: read
367  security-events: write
368 
369jobs:
370  secrets-scan:
371    name: Secret Detection
372    runs-on: ubuntu-latest
373    steps:
374      - uses: actions/checkout@v4
375        with:
376          fetch-depth: 0
377      - uses: gitleaks/gitleaks-action@v2
378        env:
379          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
380 
381  sast:
382    name: Static Analysis (SAST)
383    runs-on: ubuntu-latest
384    steps:
385      - uses: actions/checkout@v4
386      - uses: semgrep/semgrep-action@v1
387        with:
388          config: p/owasp-top-ten p/typescript p/nodejs
389 
390  dependency-audit:
391    name: Dependency Scan (SCA)
392    runs-on: ubuntu-latest
393    steps:
394      - uses: actions/checkout@v4
395      - uses: actions/setup-node@v4
396        with:
397          node-version: 22
398      - run: npm ci
399      - run: npm audit --audit-level=high
400      - uses: snyk/actions/node@master
401        env:
402          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
403        with:
404          args: --severity-threshold=high
405        continue-on-error: true
406 
407  container-scan:
408    name: Container Scan
409    runs-on: ubuntu-latest
410    needs: [sast, dependency-audit]
411    steps:
412      - uses: actions/checkout@v4
413      - run: docker build -t app:${{ github.sha }} .
414      - uses: aquasecurity/trivy-action@master
415        with:
416          image-ref: app:${{ github.sha }}
417          severity: CRITICAL,HIGH
418          exit-code: '1'
419 
420  sbom:
421    name: SBOM Generation
422    runs-on: ubuntu-latest
423    needs: [container-scan]
424    steps:
425      - uses: actions/checkout@v4
426      - uses: anchore/sbom-action@v0
427        with:
428          format: spdx-json
429          output-file: sbom.spdx.json
430```
431 
432```mermaid
433graph TD
434    PR[Pull Request] --> S1[Secret Detection]
435    PR --> S2[SAST - Semgrep]
436    PR --> S3[SCA - Snyk + npm audit]
437    S2 --> S4[Container Scan - Trivy]
438    S3 --> S4
439    S4 --> S5[SBOM Generation]
440    S5 --> Deploy[Deploy]
441 
442    S1 -.- F1[Block if secrets found]
443    S2 -.- F2[Block on critical vulns]
444    S3 -.- F3[Block on high severity]
445    S4 -.- F4[Block on critical CVEs]
446```
447 
448## Metricas a seguir
449 
450Como saber si tu programa DevSecOps esta funcionando? Monitorea estas metricas:
451 
452- **Mean time to remediate (MTTR)**: la rapidez con la que corriges vulnerabilidades tras la deteccion
453- **Vulnerability escape rate**: porcentaje de vulnerabilidades que llegan a produccion
454- **False positive rate**: demasiados falsos positivos llevan a fatiga de alertas y advertencias ignoradas
455- **Dependency freshness**: edad promedio de tus dependencias (mas antiguas = mas probabilidad de CVE conocidas)
456- **SBOM coverage**: porcentaje de proyectos con SBOM actualizadas
457 
458## Para empezar: una hoja de ruta practica
459 
460No intentes implementar todo de una vez. Un enfoque gradual funciona mejor:
461 
462```mermaid
463flowchart TD
464    A[Week 1-2: Foundations] --> B[Week 3-4: CI/CD Integration]
465    B --> C[Month 2: Container Security]
466    C --> D[Month 3+: Advanced]
467 
468    A --> A1[Add Gitleaks pre-commit hooks]
469    A --> A2[Enable npm audit in CI]
470    A --> A3[Add .gitignore for .env files]
471 
472    B --> B1[Add Semgrep to GitHub Actions]
473    B --> B2[Add Snyk dependency scanning]
474    B --> B3[Set up SARIF upload to GitHub]
475 
476    C --> C1[Add Trivy container scanning]
477    C --> C2[Harden Dockerfiles]
478    C --> C3[Generate SBOMs]
479 
480    D --> D1[Secret manager integration]
481    D --> D2[Runtime protection - DAST]
482    D --> D3[Policy as code - OPA]
483```
484 
485## Conclusion
486 
487DevSecOps no consiste en agregar mas herramientas a tu pipeline  -  se trata de hacer que la seguridad sea una parte natural de como construyes software. El objetivo no es bloquear cada PR con advertencias de seguridad, sino dar a los desarrolladores feedback rapido para que puedan corregir los problemas mientras el codigo aun esta fresco en su mente.
488 
489Empieza con lo basico: pre-commit hooks para secrets, dependency scanning en la CI y container scanning para imagenes Docker. Luego itera segun las necesidades de tu equipo.
490 
491La seguridad no es una funcionalidad que se entrega una sola vez. Es una practica que se integra en cada commit.
492 
493> **Checklist inicial DevSecOps:**
494>
495> - [x] Pre-commit hooks Gitleaks instalados
496> - [x] Archivos .env y secrets en el .gitignore
497> - [x] Semgrep SAST en la pipeline CI
498> - [x] Snyk o npm audit para dependency scanning
499> - [x] Trivy para el escaneo de imagenes de contenedores
500> - [x] Usuario no-root en los Dockerfiles
501> - [x] Secrets en variables de entorno o secret manager
502> - [x] Generacion de SBOM en cada release
503> - [x] Conocimiento del OWASP Top 10 en todo el equipo
504