← Volver al portal de guías
1. DevSecOps: el shift-left de seguridad
DevSecOps integra seguridad como responsabilidad compartida en cada etapa: dev, build, test, deploy, run. La idea contraria al modelo viejo, donde InfoSec auditaba al final y bloqueaba el release.
1️⃣ Plan
- Threat modeling
- Security stories
- Definir ASVS level
2️⃣ Code
- IDE plugins (Snyk, Semgrep)
- Pre-commit hooks
- Secrets blocking
3️⃣ Build (CI)
- SAST
- SCA
- Secrets scan
- Container scan
4️⃣ Test
- DAST en staging
- API security
- Auth tests
5️⃣ Deploy
- IaC scan
- Pre-prod gates
- Sign images
6️⃣ Run
- WAF / RASP
- SIEM, IDS
- Bug bounty
📌 Pirámide de costo: arreglar una vulnerabilidad en code = $1; en QA = $10; en prod sin incidente = $100; en prod después de un breach = $1.000-100.000+ (regulación, daño reputacional, multas GDPR/LGPD).
2. OWASP Top 10 (2021)
Los 10 riesgos más críticos en aplicaciones web. Imprescindibles de cubrir en cualquier suite de seguridad.
| # |
Riesgo |
Descripción |
Cómo probarlo |
| A01 |
Broken Access Control |
Usuarios pueden acceder a recursos que no les corresponden (IDOR, vertical/horizontal privilege escalation) |
Tests funcionales con usuarios de distintos roles + IDs ajenos. Burp Suite + extension AuthMatrix. |
| A02 |
Cryptographic Failures |
Datos sensibles sin cifrar, TLS débil, hashes inseguros (MD5, SHA1), claves hardcoded |
SAST detecta crypto débil. testssl.sh para TLS. Lint para secrets. |
| A03 |
Injection |
SQL, NoSQL, OS, LDAP injection — input sin sanitizar llega a un intérprete |
SAST (semgrep, sonarqube) + DAST (ZAP). Tests con payloads OWASP. |
| A04 |
Insecure Design |
Fallas de diseño que el código correcto no puede arreglar |
Threat modeling antes de codear. Reviews de arquitectura. |
| A05 |
Security Misconfiguration |
Credenciales por defecto, headers de seguridad ausentes, debug=true en prod |
DAST + scanners de configuración (Gixy para Nginx, kube-bench para K8s) |
| A06 |
Vulnerable & Outdated Components |
Librerías con CVEs conocidos (log4shell, struts2) |
SCA: Trivy, Snyk, Dependabot, OWASP Dependency-Check |
| A07 |
Identification & Authentication Failures |
Auth débil: passwords por defecto, sin MFA, session tokens predecibles |
Tests de fuerza bruta (ratelimit), tests de session fixation, ASVS V2/V3 |
| A08 |
Software & Data Integrity Failures |
Updates sin firma, deserialización insegura, supply chain |
SBOM (CycloneDX/SPDX), Sigstore para firma, SCA |
| A09 |
Security Logging & Monitoring Failures |
No se loguean eventos críticos, ataques pasan desapercibidos |
Threat modeling de eventos a loguear. SIEM con detection rules. |
| A10 |
Server-Side Request Forgery (SSRF) |
Servidor hace requests a URLs controladas por atacante (acceso a metadata cloud, internas) |
DAST con payloads SSRF + tests específicos. Cuidado con IMDS de AWS. |
3. OWASP ASVS — niveles 1, 2, 3
El Application Security Verification Standard (ASVS 4.0.3) es la referencia más completa para verificación de seguridad. Define 14 capítulos con > 280 controles, agrupados en 3 niveles:
| Nivel |
Para qué tipo de aplicación |
Cobertura |
Esfuerzo típico |
| L1 — Opportunistic |
Aplicaciones con baja criticidad, riesgo bajo de ataque dirigido |
~70 controles automatizables |
Mostly automatizable en pipeline |
| L2 — Standard |
La mayoría de aplicaciones con datos de usuarios o de negocio |
~180 controles |
Automation + manual verification |
| L3 — Advanced |
Aplicaciones críticas: financieras, salud, militar, infraestructura |
> 280 controles |
Manual extensivo + pentest formal |
📌 Recomendación práctica: declarar formalmente el nivel ASVS objetivo en la fase de plan. Casi todo proyecto B2C/B2B serio debería apuntar a L2. Mantener un checklist del nivel elegido como evidencia de compliance.
3.1 Capítulos ASVS (resumen)
- V1 Architecture — diseño y modelado
- V2 Authentication — passwords, MFA, sesiones
- V3 Session Management — tokens, cookies, expiración
- V4 Access Control — autorización RBAC/ABAC
- V5 Validation, Sanitization & Encoding — input/output
- V6 Stored Cryptography — hashing, encryption at rest
- V7 Error Handling & Logging — qué loguear, qué no
- V8 Data Protection — privacy, retention, GDPR/LGPD
- V9 Communication — TLS, HSTS, certificados
- V10 Malicious Code — supply chain, deserialization
- V11 Business Logic — race conditions, abuse prevention
- V12 Files & Resources — uploads, downloads, paths
- V13 API & Web Services — REST, GraphQL, SOAP
- V14 Configuration — secrets, secure defaults
4. SAST — Análisis estático de código
Analiza el código fuente sin ejecutarlo. Detecta patrones inseguros, mal uso de APIs criptográficas, taint flow desde input no confiable a sinks peligrosos.
| Herramienta |
Tipo |
Fortalezas |
Notas |
| Semgrep | OSS / SaaS | Reglas custom muy fáciles, rápido, multi-lenguaje | Muy recomendado para shift-left |
| SonarQube / SonarCloud | OSS / SaaS | Analiza también calidad y bugs, no solo seguridad | Standard en muchas empresas |
| Snyk Code | SaaS | Buena UX, integración GitHub, regla AI-driven | Comercial |
| Bandit (Python) | OSS | Específico Python, rápido | Lenguaje específico |
| CodeQL (GitHub) | OSS / SaaS | Queries muy potentes (semantic analysis) | Curva de aprendizaje, gratis en repos públicos |
| Checkmarx, Veracode | SaaS enterprise | Compliance reports, soporte enterprise | Caros, lentos |
# Semgrep — ejemplo de regla custom para detectar uso de pickle inseguro en Python
rules:
- id: insecure-pickle-load
pattern: pickle.load(...)
message: "pickle.load es vulnerable a code execution. Usar json o un parser seguro."
severity: ERROR
languages: [python]
metadata:
cwe: CWE-502
owasp: A08:2021 — Software and Data Integrity Failures
5. DAST — Análisis dinámico
Prueba la aplicación corriendo, simulando ataques desde fuera. Detecta vulnerabilidades en runtime — XSS, SQLi, SSRF, path traversal, misconfig de headers.
| Herramienta |
Tipo |
Uso recomendado |
| OWASP ZAP | OSS | Automatable en CI (baseline / full scan), bueno para apps web tradicionales |
| Burp Suite Pro | Comercial | Standard en pentesting manual, mejor en aplicaciones complejas |
| Nuclei | OSS | Fast template-based, miles de checks de la comunidad |
| Nikto | OSS | Web server scanner clásico, complementario |
| sqlmap | OSS | Específico para SQLi, muy potente |
# DAST básico con OWASP ZAP en GitHub Actions
- name: ZAP Baseline Scan
uses: zaproxy/action-baseline@v0.12.0
with:
target: 'https://staging.example.com'
rules_file_name: '.zap/rules.tsv'
cmd_options: '-a' # active scan (más profundo, más ruidoso)
fail_action: true # falla el job si encuentra HIGH
6. SCA — Software Composition Analysis
Detecta vulnerabilidades en dependencias de terceros. Crítico — el 80% del código de una app moderna es de terceros.
| Herramienta | Tipo | Fortalezas |
|---|
| Trivy | OSS (Aqua) | Multi-uso: dependencias, contenedores, IaC. Muy rápido. |
| Snyk | SaaS / OSS | Excelente DB de vulnerabilidades, fixes automatizables |
| GitHub Dependabot | SaaS (gratis) | Built-in en GitHub, PRs automáticos |
| OWASP Dependency-Check | OSS | Standard veterano, muchas integraciones |
| Grype | OSS (Anchore) | Específico para imágenes y dirs, rápido |
| Renovate | OSS | Bot de updates más potente que Dependabot, configurable |
6.1 SBOM — Software Bill of Materials
Un SBOM es la lista exhaustiva de todos los componentes (libs, runtime, OS packages) de tu aplicación. Es obligatorio en muchos sectores (finanza, gobierno, salud) y exigido por la Executive Order 14028 (US, 2021) para software vendido al gobierno.
- Formatos estándar: CycloneDX (OWASP) y SPDX (Linux Foundation).
- Generación:
syft, cyclonedx-cli, builders nativos de Maven/npm/etc.
- Distribución: adjuntar al release como artefacto firmado.
7. Secrets scanning
Una API key en git es game over: queda en la historia para siempre, y los bots de GitHub la encuentran en minutos.
| Herramienta | Cuándo |
|---|
| Gitleaks | Pre-commit hook + CI scan completo |
| TruffleHog | Detección con verificación (intenta autenticarse para validar el secreto) |
| GitHub Secret Scanning | Built-in, free en repos públicos, alerta a partners cuando un token se filtra |
| detect-secrets (Yelp) | Baseline file → detecta secretos NUEVOS |
🚨 Si filtraste un secreto, NO basta con borrarlo del código. Sigue en la historia git. Hay que: (1) rotar el secreto en el sistema fuente, (2) opcionalmente reescribir la historia con git-filter-repo o BFG (operación destructiva), (3) confirmar con el equipo de seguridad. Asumir compromiso.
8. Container & IaC scanning
8.1 Container scanning
| Herramienta | Detecta |
|---|
| Trivy | CVEs en OS packages + libs + misconfig + secrets en imagen |
| Grype | CVEs en imágenes y filesystems |
| Docker Scout | Built-in en Docker Desktop / Hub |
| Snyk Container | Comercial, fix automation |
✅ Hardening básico: base images mínimas (distroless, alpine), USER no-root, healthchecks, multi-stage builds, no instalar herramientas de debug en imagen final.
8.2 IaC scanning (Terraform, Kubernetes, CloudFormation)
| Herramienta | Stack |
|---|
| Checkov (Bridgecrew) | Multi: Terraform, K8s, CloudFormation, Helm, ARM |
| tfsec / Trivy Config | Específico Terraform |
| kube-bench | CIS Benchmark de Kubernetes |
| kubesec | Manifests Kubernetes |
| cfn-lint, cfn-nag | CloudFormation |
9. Threat modeling con STRIDE
STRIDE (Microsoft) es el modelo más usado para identificar amenazas durante el diseño:
| Letra | Amenaza | Propiedad violada | Mitigación típica |
|---|
| S | Spoofing | Authentication | MFA, certificados, OAuth |
| T | Tampering | Integrity | Hashing, firmas, integrity checks |
| R | Repudiation | Non-repudiation | Audit logs firmados, timestamping |
| I | Information Disclosure | Confidentiality | Encryption, access control, PII anonymization |
| D | Denial of Service | Availability | Rate limiting, autoscaling, DDoS protection |
| E | Elevation of Privilege | Authorization | Principle of least privilege, RBAC, sandboxing |
9.1 Plantilla de threat modeling
# Threat Model — <feature>
## Diagrama de flujo de datos
- Actores: Usuario, Servicio Auth, API, DB, S3
- Trust boundaries: Internet ↔ DMZ ↔ App tier ↔ Data tier
## Amenazas identificadas (STRIDE)
| ID | Categoría | Activo | Amenaza | Likelihood | Impact | Mitigación |
|----|-----------|--------|---------|------------|--------|------------|
| T1 | S | Login API | Credential stuffing | High | Critical | Rate limit + MFA |
| T2 | T | API tokens | Modificación en tránsito | Medium | High | TLS 1.3 + JWT signed |
| T3 | I | DB | SQL injection | Medium | Critical | Prepared statements + WAF |
| T4 | D | Public API | Volumetric DDoS | Low | High | CloudFlare / AWS Shield |
| T5 | E | Admin endpoint | Bypass de auth via IDOR | Medium | Critical | RBAC + tests |
## Controles compensatorios
- WAF en frontend (rules OWASP CRS)
- Logging estructurado de eventos de seguridad
- Pentest semestral
## Tests derivados (a agregar al test plan)
- TC-SEC-001: rate limiting en /login (20 req/min)
- TC-SEC-002: MFA obligatorio para roles admin
- TC-SEC-003: SQL injection probes en /search
10. Pentesting y red teaming
| Tipo |
Objetivo |
Cuándo |
| Black-box pentest |
Atacante externo sin conocimiento del sistema |
Pre-release, anual mínimo |
| Grey-box pentest |
Atacante con credenciales de usuario normal |
Test típico para apps SaaS |
| White-box pentest |
Tester con acceso a código y arquitectura |
Auditoría profunda, sistemas críticos |
| Red teaming |
Ejercicio adversarial completo (incluye phishing, físico) |
Empresas grandes, SOC maduros |
| Bug bounty |
Programa público (HackerOne, Bugcrowd) o privado |
Producción estable + presupuesto recurrent |
📌 Cadencia recomendada: SAST/DAST/SCA en cada PR (automático), pentest manual semestral o ante cambios mayores, bug bounty continuo si hay budget.
11. Pipeline DevSecOps end-to-end
# .github/workflows/devsecops.yml — pipeline integral
name: DevSecOps Pipeline
on: [push, pull_request]
jobs:
secrets:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with: { fetch-depth: 0 }
- name: Gitleaks
uses: gitleaks/gitleaks-action@v2
sast:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Semgrep SAST
uses: returntocorp/semgrep-action@v1
with:
config: "p/owasp-top-ten p/cwe-top-25 p/security-audit"
sca:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Trivy filesystem scan
uses: aquasecurity/trivy-action@master
with:
scan-type: 'fs'
severity: 'CRITICAL,HIGH'
exit-code: '1'
iac:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Checkov IaC
uses: bridgecrewio/checkov-action@master
with:
quiet: true
framework: terraform,kubernetes,helm
container:
runs-on: ubuntu-latest
needs: [sast, sca]
steps:
- uses: actions/checkout@v4
- name: Build image
run: docker build -t app:${{ github.sha }} .
- name: Trivy container scan
uses: aquasecurity/trivy-action@master
with:
image-ref: 'app:${{ github.sha }}'
severity: 'CRITICAL,HIGH'
exit-code: '1'
- name: Generate SBOM
run: syft app:${{ github.sha }} -o cyclonedx-json > sbom.json
- name: Sign image (cosign)
run: cosign sign --yes app:${{ github.sha }}
dast:
runs-on: ubuntu-latest
if: github.ref == 'refs/heads/main'
needs: container
steps:
- name: Deploy to staging
run: ./deploy-staging.sh
- name: ZAP Baseline Scan
uses: zaproxy/action-baseline@v0.12.0
with:
target: 'https://staging.example.com'
fail_action: true
12. Métricas e indicadores
| Métrica | Definición | Target |
|---|
| MTTR vulnerabilidades CRITICAL | Tiempo medio para parchear | < 7 días |
| MTTR vulnerabilidades HIGH | Tiempo medio para parchear | < 30 días |
| Defect escape rate (security) | Vulns encontradas en prod / total | < 5% |
| SAST coverage | % de repos con SAST en CI | 100% |
| Dependencies up-to-date | % de deps en versión > n-2 | ≥ 90% |
| Secrets detected/sprint | Tendencia (debe ↓ con tiempo) | 0 en main |
| % de PRs con threat model actualizado | Para features con cambios de superficie | ≥ 80% |
| ASVS coverage | % de controles del nivel verificados | ≥ 95% L2 |
13. Anti-patterns
- "Pentest anual basta". Sin SAST/DAST/SCA continuo, el delta entre pentests acumula deuda.
- Romper el build con MEDIUM/LOW desde el día 1. El equipo desactivará el check. Empezar solo con CRITICAL/HIGH y bajar el umbral con el tiempo.
- Reportar 1000 vulnerabilidades sin priorizar. Sin contextualizar (exploitability + reach), el equipo no sabe por dónde empezar y pierde confianza en la herramienta.
- Ejecutar DAST contra producción. Tests activos pueden corromper datos. Staging idéntico a prod.
- "Es solo un MVP, después aseguramos". Las decisiones de arquitectura inseguras se quedan. Threat modeling desde el día 1.
- No tener inventario de assets. No podés proteger lo que no conocés. SBOM + asset register actualizado.
- Ignorar dependencias transitivas. El 70% de vulns vienen de deps de deps. SCA con análisis transitivo.
- Confiar solo en escaneo automatizado. Las fallas de lógica de negocio (race conditions, IDOR no triviales) requieren testing manual.
- Pull request "Update dependency X" sin testing. Updates pueden romper. Suite de tests verde antes de mergear.
- No tener plan de respuesta a incidentes. El día que pasa algo, el caos se cobra solo.
📚 Referencias
- OWASP Top 10 (2021) —
owasp.org/Top10
- OWASP ASVS 4.0.3 —
owasp.org/www-project-application-security-verification-standard
- OWASP Cheat Sheet Series —
cheatsheetseries.owasp.org
- NIST SP 800-218 — Secure Software Development Framework (SSDF)
- NIST Cybersecurity Framework 2.0 (2024)
- ISO/IEC 27001:2022 — Information Security Management Systems
- ISO/IEC 27034 — Application Security
- CIS Controls v8
- CWE/SANS Top 25 Most Dangerous Software Weaknesses
- Microsoft Threat Modeling — STRIDE
- EU NIS2 Directive (2024) — para infraestructura crítica
QA Shift-Left Methodology — Framework operativo integrado por E-Gregorio
Guía DevSecOps — referencia a estándares públicos: OWASP Top 10 (2021), OWASP ASVS 4.0.3, ISO/IEC 27001:2022 y NIST CSF 2.0