referencia

Glosario

Toda la sopa de letras en un solo lugar: siglas, identificadores, frameworks y conceptos: qué significa cada uno y cómo se conecta con el resto. Los términos de todos los dominios conviven aquí, con filtro por dominio cuando quieres enfocarte.

frameworks y listasAppSec

OWASP Top 10: La lista de referencia más conocida de riesgos de seguridad en aplicaciones web (A01 control de acceso roto, A02 fallas criptográficas, A03 inyección...), revisada cada pocos años por la comunidad OWASP. Es un mapa educativo de categorías de riesgo, no un checklist de herramientas ni una certificación.
OWASP ASVSestándar de verificación: Application Security Verification Standard: checklist verificable, en tres niveles de rigor, para auditar una aplicación o contratar una auditoría. Donde el Top 10 enseña, el ASVS audita.
NIST SSDF: Framework estadounidense de proceso seguro de desarrollo (prácticas para producir software seguro). Es proceso, no herramienta: cita SAST, SCA y SBOM como partes del ciclo.
OWASP SAMM: Modelo de madurez de seguridad de software: evalúa a la organización en cinco funciones de negocio para decir en qué nivel está y qué priorizar después.

identificadores, bases de datos y puntajesAppSec

CVEcommon vulnerabilities and exposures: El identificador único de UNA vulnerabilidad pública específica, con el formato CVE-AÑO-NÚMERO. Ej.: CVE-2021-44228 es Log4Shell. Es la instancia real, no la clase del problema.
CWEcommon weakness enumeration: El identificador del TIPO de debilidad, la clase del error en el código. CWE-89 es SQL injection, CWE-79 es XSS. La distinción que confunde a todos: CWE es la categoría, CVE es una ocurrencia concreta de ella. Un CVE de SQL injection en tu framework va a referenciar el CWE-89.
CVSScommon vulnerability scoring system: Puntaje de 0 a 10 que mide la severidad técnica de una vulnerabilidad: cómo se explota (red o local, complejidad, privilegio necesario, interacción del usuario) y cuál es el impacto. 9.0+ es crítico, pero el número es teórico: no sabe si estás expuesto.
EPSSexploit prediction scoring system: Probabilidad (0 a 100%) de que un CVE sea explotado de verdad en los próximos 30 días, basada en evidencia. Complementa al CVSS: un 9.8 con EPSS de 0,1% puede ser menos urgente que un 7.5 con EPSS de 60%.
CISA KEVknown exploited vulnerabilities: Catálogo de las vulnerabilidades que están siendo explotadas activamente, ahora, en el mundo real. 'Está en el KEV' = prioridad máxima, independientemente del CVSS.
NVDnational vulnerability database: La base de datos del NIST que enriquece cada CVE con un puntaje CVSS y un CWE asociado. Es de donde beben la mayoría de las herramientas de SCA.
OSV / GitHub Advisoryadvisories: Bases de vulnerabilidades enfocadas en ecosistemas de paquetes (npm, PyPI, Maven...). Más prácticas que el CVE genérico: dicen exactamente qué versión está afectada y cuál la corrige.

pruebas y técnicasAppSec

SAST: Análisis estático: examina el código sin ejecutarlo. Encuentra problemas por análisis de flujo, no por adivinación.→ SAST
DAST: Prueba dinámica: ataca la aplicación en ejecución, desde afuera, en caja negra.→ DAST
IAST: Híbrido: un agente dentro de la aplicación observa la ejecución en tiempo real, combinando el contexto del código (SAST) con la evidencia del ataque (DAST).
RASP: Runtime Application Self-Protection: protección integrada en el runtime de la aplicación que bloquea ataques en ejecución, incluso después del deploy.
SCA: Análisis de composición: inventaría las dependencias de terceros y las cruza con CVEs conocidos.→ SCA
Secrets scanning: Escaneo de credenciales expuestas en código, commits e historial de git.→ Secrets Scanning
Fuzzing: Bombardear la aplicación con entradas aleatorias o mutaciones de entradas válidas, buscando crashes y comportamientos inesperados. El ancestro del DAST moderno.
Pentest: Prueba adversarial manual, con alcance definido e informe: un humano (o equipo) intentando vulnerar la aplicación a propósito.
ASTabstract syntax tree: El árbol de sintaxis que produce el parser: cada construcción del código se vuelve un nodo tipado, y las herramientas analizan el árbol en lugar de texto suelto.→ SAST
Source: El origen de un dato no confiable: input de usuario, query string, header, archivo. Es donde nace el taint.→ SAST
Sink: El destino peligroso donde un dato no confiable se vuelve comando, query o HTML: db.query, eval, innerHTML. Si el taint llega aquí, es una vulnerabilidad.→ SAST
Taint trackinganálisis de contaminación: Seguir la marca de 'dato sucio' desde el source hasta el sink, propagándola por asignaciones y llamadas. Es el corazón del SAST moderno.→ SAST
Sanitizador / barrier: La función que limpia el dato o prueba que es seguro (query parametrizada, escape de HTML). Corta el flujo y el engine deja de alertar en ese camino.→ SAST
Falso positivo / falso negativo: Falso positivo: alerta de una vulnerabilidad que no existe. Falso negativo: vulnerabilidad real que pasó desapercibida. Toda herramienta vive intercambiando uno por el otro.

supply chain y artefactosAppSec

SBOM: La lista de ingredientes del software: dependencias, versiones, licencias y hashes, en un formato estándar.→ SBOM
purlpackage url: Identificador universal de un paquete: pkg:npm/lodash@4.17.15 indica ecosistema, nombre y versión sin ambigüedad. Es la columna vertebral de un SBOM.
CycloneDX / SPDX: Los dos formatos estándar de SBOM. CycloneDX está más orientado a seguridad, SPDX a licencias; en la práctica, ambos listan los mismos componentes.
Hash (SHA-256): Huella digital de un archivo: si cambia un byte, cambia el hash. Prueba que el componente es exactamente lo que dicen que es.
Lockfile: El registro exacto de qué versión de cada dependencia se resolvió (package-lock.json, go.sum...). Sin él, los builds no son reproducibles y el SCA no ve el árbol real.
Dependencia transitiva: Paquete que no elegiste: entró como dependencia de otra dependencia, a veces tres niveles más abajo. Recibe CVEs igual, y es el punto ciego clásico.
Provenanceprocedencia: El registro de cómo y dónde se construyó un artefacto: qué pipeline, qué commit, qué máquina. Permite preguntar '¿este binario realmente vino de nuestro código?'.
SLSA: Supply-chain Levels for Software Artifacts: escala de 1 a 4 para la integridad del build, desde 'tiene documentación' hasta 'build a prueba de manipulación con procedencia verificable'.
Sigstore / Cosign: Firma y verificación de artefactos sin gestionar claves a mano: claves efímeras vinculadas a la identidad del build, con un log público de transparencia.
in-toto: Framework que firma, paso por paso, lo que hizo el pipeline: prueba que el proceso esperado se ejecutó, en el orden esperado, sin un paso cambiado.
SCA vs SBOM: El SCA es el análisis vivo (monitorea CVEs); el SBOM es la foto del momento (el inventario). En la práctica, se alimentan mutuamente: el SCA genera el SBOM y lo monitorea.→ SBOM

pipeline y prácticasAppSec

CI / CDentrega vs deploy: CI: validar cada cambio automáticamente. CD de entrega: el deploy es un clic. CD de deploy: todo lo que pasa los gates sale a producción solo.→ CI/CD
Stage: Una etapa del pipeline: source, build, test, package, deploy, monitor. Cada stage es un lugar posible para un gate de seguridad.→ CI/CD
Quality gate: La compuerta explícita de un stage: 'falla el build si hay un hallazgo crítico nuevo'. Sin un criterio claro, el gate se vuelve una sugerencia.
Policy as codeOPA / Rego: La política de seguridad escrita como un archivo versionado que el pipeline consulta (denegar imagen con vulnerabilidad crítica, exigir firma). Cambia el criterio = cambia el archivo, con revisión.→ DevSecOps
Pre-commit hook: Verificación local que corre antes de que el commit salga de tu máquina: secrets scanning, linter, SAST rápido. La forma más barata de feedback.→ Shift-left
Shift-left / shift-right: Shift-left: mover la verificación lo más temprano posible en el ciclo. Shift-right: probar y observar también en producción (canary, observabilidad). Los dos conviven.→ Shift-left
DevSecOps: Seguridad como código dentro del CI/CD, con gates automatizados y responsabilidad compartida.→ DevSecOps
Secret manager / vault: Bóveda que guarda credenciales y las inyecta en runtime (Vault, AWS Secrets Manager, Doppler). Saca el secreto del código y permite rotación sin deploy.
Rotación de credenciales: Cambiar la clave comprometida: el paso número uno tras una filtración. Un commit de eliminación no lo resuelve: el historial conserva lo que se commiteó.→ Secrets Scanning
WAFweb application firewall: Filtro en el borde que bloquea patrones de ataque conocidos en HTTP. Complementa al código: no reemplaza corregir la vulnerabilidad, solo compra tiempo.

conceptos fundamentalesAppSec

Vulnerabilidad: La debilidad en el sistema que puede ser explotada: una falla concreta de código, configuración o diseño.
Exploit: La técnica o el artefacto concreto que abusa de una vulnerabilidad. La vulnerabilidad es el agujero; el exploit es el pie que entra en él.
Amenaza vs riesgo: Amenaza es quién o qué puede causar daño (el atacante). Riesgo es probabilidad × impacto en TU contexto. Las herramientas reportan vulnerabilidades; quien decide el riesgo eres tú.
Superficie de ataque: Todo lo que está expuesto a entrada no confiable: endpoints, formularios, dependencias, puertos, pipelines. Una superficie mínima es una estrategia de defensa.
Defensa en profundidad: Capas independientes de protección, bajo la premisa de que cualquiera puede fallar: validación + parametrización + WAF + monitoreo.
Zero-day: Vulnerabilidad explotada antes de que exista una corrección pública. Contra un zero-day, en el momento solo ayudan la defensa en profundidad y la detección.
CNAPP / ASPM: Categorías de mercado que empaquetan SAST + DAST + SCA + infraestructura en una sola plataforma. Útil saber que existen: el concepto detrás es el mismo de los gates de esta KB.

modelado de amenazasAppSec

STRIDE: Mnemónico de seis categorías de amenaza (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege) usado como checklist al recorrer un diagrama de flujo de datos.→ Threat modeling: pensar como el atacante antes de programar
DFDdiagrama de flujo de datos: Dibujo de los actores, procesos, almacenes y flujos de un sistema, con las fronteras de confianza marcadas. Es la entrada del threat modeling: las amenazas aparecen donde un flujo cruza una frontera.→ Threat modeling: pensar como el atacante antes de programar
Frontera de confianzatrust boundary: Línea donde cambia el nivel de confianza de los datos o de quien los envía (internet a VPC, servicio a base de datos, usuario a admin). Todo lo que la cruza debe ser autenticado, autorizado y validado.→ Threat modeling: pensar como el atacante antes de programar

identidad y accesoCloudSec

IAMidentity and access management: El conjunto de políticas, roles y credenciales que dice quién es cada humano, servicio o workload, y qué puede hacer cada uno. En la nube, IAM se convirtió en el nuevo perímetro: el borde de red se volvió poroso, así que la identidad carga la autorización.→ IAM - identidad y acceso
Mínimo privilegioleast privilege: Principio de darle a cada identidad solo los permisos estrictamente necesarios para su función, y nada más. Es lo opuesto a 'usuario admin por defecto': cada rol extra es un camino más que un atacante puede usar después de un compromiso.→ IAM - identidad y acceso
Modelo de responsabilidad compartidashared responsibility model: La división clásica entre lo que garantiza el proveedor de nube (seguridad DE la nube: datacenter, hardware, servicio físico) y lo que es responsabilidad del cliente (seguridad EN la nube: datos, IAM, configuración, red). Confundir los dos extremos es la fuente clásica de filtraciones.
Rotación de secretoscredential rotation: Cambiar periódicamente (o ante la sospecha de una filtración) las claves de API, tokens y contraseñas almacenadas en una bóveda. Sin rotación, un secreto expuesto en un log o en un historial de git vale para siempre; con rotación, vale hasta el próximo cambio.→ Secrets - bóvedas y rotación
Radio de impactoblast radius: El tamaño del daño cuando algo se rompe: una cuenta, una región completa, un tenant. Un buen diseño de nube limita el radio mediante aislamiento (cuentas separadas, VPCs separadas, roles estrechos) para que una falla o un ataque no se convierta en un desastre total.

red y datosCloudSec

Grupo de seguridadsecurity group: Lista de reglas stateful asociada a una instancia o interfaz de red en la nube: quién puede entrar por qué puerto, desde qué origen. Funciona como firewall de host a nivel de nube, y falla por defecto: si olvidas cerrar un puerto, queda abierto a 0.0.0.0/0.→ Network - segmentación y zero-trust
VPCvirtual private cloud: Red privada aislada lógicamente dentro de la nube pública: eliges el rango de IPs, lo divides en subredes públicas y privadas, y controlas el tráfico con route tables y NAT. La VPC es tu datacenter virtual; todo lo que corre dentro conversa como si estuviera en el mismo rack.→ Network - segmentación y zero-trust
Network policy: Reglas de firewall declarativas a nivel de pod (Kubernetes) o de workload (service mesh), que indican qué servicio puede hablar con qué puerto. A diferencia del grupo de seguridad, opera en L7 dentro del clúster, con selectors por label, y es pieza central de la defensa en profundidad para el tráfico east-west.→ Kubernetes - runtime seguro
KMSkey management service: Servicio administrado que crea, almacena y controla el uso de claves criptográficas. La aplicación rara vez toca la clave maestra: le pide al KMS que cifre o descifre, y el proveedor registra cada uso en un log auditable. Sin KMS, la clave termina en disco y se vuelve un objetivo.→ KMS & crypto - claves y envelopes
Envelope encryption: Patrón de dos capas: una clave de datos (DEK) cifra el payload, y una clave del KMS (KEK) cifra la DEK. La aplicación guarda la DEK cifrada junto a los datos, y solo llama al KMS para desenvolver la DEK cuando necesita usarla. Reduce las llamadas al KMS y limita la exposición de la clave maestra.→ KMS & crypto - claves y envelopes

postura y detecciónCloudSec

Zero trust: Modelo que parte de la premisa de no confiar en nadie por su posición en la red: cada solicitud se autentica, se autoriza y se registra, incluso si viene de la red interna. Reemplaza el castillo con foso por verificación continua en cada puerta, humana o de servicio.→ Zero-trust - modelo de confianza
CSPMcloud security posture management: Herramienta que escanea la configuración de tu nube contra buenas prácticas y benchmarks (CIS, NIST), señalando buckets S3 públicos, IAM demasiado amplio, puertos expuestos. Hace la pregunta que los humanos olvidan: '¿qué está mal configurado AHORA?'.→ CSPM - postura cloud
CWPPcloud workload protection platform: Protección monitoreada para workloads en ejecución: VMs, contenedores, funciones serverless. Combina visibilidad de lo que corre (procesos, syscalls, red) con prevención (bloquear la ejecución, aislar anomalías). Es el endpoint security reformulado para la realidad efímera de la nube.→ CWPP - protección de workloads
Driftconfiguration drift: Cuando la infraestructura viva se aleja del estado declarado: alguien abrió un puerto en la consola, un bucket quedó público, un rol de IAM se volvió admin. El drift es configuración acumulada fuera del control de versiones, y la mejor cura es IaC con revisión: todo lo que cambia pasa por código.
Hardeningendurecimiento: Reducir la superficie de una workload a lo esencial: deshabilitar servicios no usados, cerrar puertos, quitar paquetes superfluos, aplicar un baseline (CIS). Es el equivalente en la nube de quitar la contraseña por defecto y cerrar las ventanas: aburrido, repetitivo, y la diferencia entre un blanco fácil y uno costoso.
Trazabilidad de auditoríacloudtrail: Registro inmutable de cada llamada de API hecha en la cuenta de la nube: quién llamó a qué, desde dónde, con qué resultado. Es la caja negra de la cuenta: después de una filtración, responde '¿qué hizo el atacante y cuándo?'. Sin trazabilidad no hay investigación ni contención informada.→ Logging & detection - señales y alertas

respuesta a incidentesCloudSec

MTTRmean time to respond: Tiempo promedio entre la confirmación de un incidente y su contención. Es la métrica que muestra si los runbooks y la automatización funcionan de verdad, y la que más baja cuando la respuesta se practica en ejercicios.→ Respuesta a incidentes en la nube
Runbook: Guion paso a paso para un tipo de incidente (clave filtrada, instancia comprometida). Escrito antes de la crisis, probado en game days y, cuando es posible, convertido en automatización.→ Respuesta a incidentes en la nube
Cadena de custodiachain of custody: Registro de quién recolectó, guardó y manipuló cada evidencia digital, y cuándo. Sin ella, la prueba pierde valor para auditorías y para una eventual disputa legal.→ Respuesta a incidentes en la nube

recuperaciónAgentes

Retrievalbúsqueda semántica: Etapa del RAG en la que buscas en tus chunks los pasajes que responden la pregunta del usuario. El retrieval es el cuello de botella real del sistema: un buen LLM con mal retrieval es un LLM que alucina con confianza. Va desde la búsqueda densa por similitud hasta el BM25 clásico, pasando por híbrido y reranking.→ Retrieval
Reranking: Segunda pasada del retrieval: el modelo toma los top-K candidatos que vienen de la búsqueda barata (digamos 50) y los reordena en los K más útiles (top 5 o 10) usando un cross-encoder que vio la query y el chunk juntos. Agrega latencia, pero reduce el ruido: el LLM recibe contexto denso en lugar de una mezcla de bueno y mediocre.→ Retrieval
BM25: Función de ranking clásica de la búsqueda textual: puntúa cada documento con TF-IDF con saturación (los términos importantes pesan más hasta cierto tope) y normaliza por longitud. Es la búsqueda dispersa del retrieval híbrido y captura coincidencias exactas de términos (código de error, nombre de API) donde el embedding solo falla feo.→ Retrieval
Similitud de coseno: Medida de qué tan alineados están dos vectores en el espacio de embeddings: coseno del ángulo entre ellos, independiente de la magnitud. Para embeddings normalizados basta el producto interno y sigue siendo rápido, por eso se volvió la distancia estándar en casi toda base vectorial.→ Embeddings
HNSWhierarchical navigable small world: Estructura de grafo en capas que las bases vectoriales usan para buscar vecinos en alta dimensión. Cada capa es un grafo disperso que salta lejos; las de abajo hacen el ajuste fino. Es la razón por la que pgvector, Pinecone, Weaviate, Qdrant y LanceDB responden en milisegundos con millones de vectores.→ Vector DB
ANNapproximate nearest neighbor: Familia de algoritmos (HNSW, IVF, LSH) que sacrifican exactitud por una velocidad brutal en la búsqueda de vecinos en alta dimensión. ANN no encuentra al vecino perfecto, sino a uno suficientemente bueno, y en retrieval de producción ese trade-off es lo que hace que el sistema quepa en el presupuesto de latencia.→ Vector DB

modelo, agentes y protocolosAgentes

Ventana de contextocontext window: Cantidad máxima de tokens que el modelo puede leer de una sola vez: el prompt, todo el historial concatenado y la salida que va a generar. Es la memoria de corto plazo del LLM. Las ventanas enormes parecen resolver el RAG, pero amplifican costo, latencia y el riesgo de que el modelo se pierda en medio del texto, así que un buen contexto es un contexto pequeño y bien elegido.→ LLM - large language model
Alucinaciónhallucination: Cuando el modelo inventa un hecho plausible que no estaba en los datos: nombre de API que no existe, paper inexistente, comando coherente que no hace nada. Es un problema de entrenamiento y de retrieval, no de 'veracidad'. La mitigación es en capas: retrieval con fuentes verificables, prompt que pide citas y un evaluador que caza invenciones automáticamente.→ Agent frameworks
Function callingtool use: Mecanismo por el cual el LLM pide, en vez de solo texto, ejecutar una función con parámetros estructurados: el modelo emite JSON, tu código ejecuta la función y el resultado vuelve a la conversación. Es lo que convierte un modelo puro en un agente capaz de actuar en el mundo, y lo que necesita guardrails para evitar la llamada equivocada con el argumento equivocado.→ Tool calling
Agente: Programa que usa un LLM para decidir qué hacer en cada paso, en vez de seguir un script fijo. Recibe un objetivo, elige herramientas, observa el resultado, decide el siguiente paso y sigue hasta terminar o rendirse. La diferencia con un chatbot es la autonomía: el agente secuencia acciones fuera de un orden predefinido.→ Agent frameworks
Grafo de agente: Descomposición explícita del razonamiento del agente en nodos (planificar, actuar, observar, revisar) y aristas dirigidas, en vez de un único loop que hace todo. Ventaja: cada nodo es auditable y testeable de forma independiente, y cuando el agente se traba sabes en qué nodo. LangGraph y las máquinas de estados en general siguen este modelo.→ Orchestration
MCP servermodel context protocol server: Servidor que implementa el Model Context Protocol, el estándar abierto de Anthropic que estandariza la conversación entre un agente y herramientas externas. El agente lista lo disponible, llama lo que necesita y recibe el resultado, sin integración caso por caso. Un MCP server bien escrito se vuelve reutilizable por Claude, Cursor, Cline y cualquier cliente compatible.→ MCP - model context protocol
Tool vs resource (MCP): En MCP, una tool es una función que el agente invoca con parámetros y de la que recibe un resultado bajo demanda (un POST, un cálculo, un envío). Un resource es un dato con nombre que el agente puede leer cuando quiera (archivo de configuración, schema, log). Separar ambos es importante: el LLM razona mejor cuando las operaciones con efectos secundarios son claramente distintas de las lecturas.→ MCP - model context protocol
DeepAgents: Biblioteca de agentes en grafo de LangChain que combina una planning tool, una filesystem tool y subagentes para resolver tareas demasiado largas para un loop único. Es una referencia práctica de agente que no se traba en la tercera tool call y el lugar donde aprendes a calibrar la autonomía antes de soltar un agente real en producción.→ Agent frameworks

evaluación y seguridadAgentes

SWE-bench: Benchmark que mide si un agente logra resolver issues reales de GitHub en código real de proyectos open source: multiarchivo, con tests, sin instrucciones de cómo hacerlo. Es el estándar actual para distinguir al agente que impresiona en una demo del que realmente cierra tickets, y donde deepagents y similares publican sus números de evolución.→ Benchmarks - referencia pública
JudgeLLM-as-judge: Usar un LLM fuerte (en general clase GPT-4 o Claude Opus) para puntuar la salida de otro modelo según una rúbrica. Resuelve la escala, porque un humano no lee 5.000 salidas por PR. Trae sesgos propios: sesgo de posición (prefiere al primer candidato), de verbosidad (prefiere al más largo) y autopromoción (cree que su propio modelo es mejor). Calibrar contra un evaluador humano es obligatorio antes de confiar en el judge.→ LLM as judge - rúbrica automatizada
Rúbrica: Lista explícita de criterios y pesos que el juez usa para puntuar una salida: 'cita la fuente en la primera frase, máximo 2 líneas, sin adjetivos, devuelve JSON'. Sin una rúbrica escrita, el LLM-as-judge diverge entre ejecuciones y entre modelos, y no puedes mejorar prompt, modelo y dataset de forma reproducible. Con la rúbrica fijada se vuelve una regla de medir; sin ella, una opinión.→ LLM as judge - rúbrica automatizada
Baseline: Modelo o configuración de referencia (fija) que corre sobre todo el dataset antes de cualquier cambio, para medir el delta de tu modificación. En evals de LLM, 'mejor' sin baseline es una apuesta: ¿la versión anterior ya era buena, o solo lo parecía en la demo? Un baseline fijado por versión es lo que convierte el eval en ciencia, y lo que separa 'pasó la prueba' de 'pasó la prueba, y aquí está la evidencia'.→ Regression evals - suite fija en el PR
Prompt injection: Ataque en el que contenido hostil (en una página indexada, en un correo resumido, en un documento que abre el agente) intenta reemplazar las instrucciones del sistema. El atacante sabe que el LLM mezcla texto confiable con texto encontrado y planta un 'ignora las instrucciones anteriores y ejecuta X'. Es el vector número 1 en agentes en producción hoy; no es un bug del LLM, es cómo los agentes leen texto por diseño.→ Guardrails - filtros de entrada y salida
PIIpersonally identifiable information: Dato personal que identifica a alguien: nombre y documento de identidad, correo, teléfono, dirección, IP. Cuando el usuario pega un documento con PII en el chat, o el RAG indexa un CRM con 5.000 clientes, el agente se convierte en una fuga por diseño. Los guardrails aquí son detección en la entrada, redacción antes de enviar al LLM y retención corta, porque enmascarar después de recibir la respuesta ya es demasiado tarde.→ Guardrails - filtros de entrada y salida

defensa de bordeSecOps

WAFweb application firewall: Filtro de tráfico HTTP en la capa 7 que decide, por solicitud, si continúa, se desafía, se limita o se bloquea. Reduce la superficie expuesta y permite el parche virtual; no sustituye la corrección en la aplicación.→ WAF - observación, shadow y enforcement
Modelo positivoallowlist: Definir qué es válido para un endpoint (métodos, rutas, formatos, tamaños) y bloquear el resto. Más preciso que las firmas, pero exige conocer la aplicación.→ WAF - observación, shadow y enforcement
Shadow mode: Fase en que una regla corre en paralelo, sin actuar, y la decisión simulada se compara con la realidad para medir el falso positivo antes del enforcement.→ WAF - observación, shadow y enforcement
Parche virtualvirtual patching: Regla de WAF que bloquea la explotación de una vulnerabilidad conocida mientras la corrección real aún no llega a la aplicación. Gana tiempo, no elimina la falla.→ WAF - observación, shadow y enforcement
Rate limiting: Límite de solicitudes por entidad y ventana de tiempo. La elección de la clave (IP, cuenta, token, ASN) pesa tanto como el valor del límite.→ Rate limiting adaptativo
Challengedesafío: Verificación que intenta probar que el cliente es un navegador real, sin pedirle nada al usuario en la mayoría de los casos. Es el escalón previo al bloqueo.→ Bot management
Fail-open / fail-closed: Lo que hace el sistema cuando falla un control de seguridad: fail-open deja pasar (disponible, desprotegido), fail-closed bloquea (seguro, no disponible). La elección debe ser consciente, por endpoint.→ Defensa en capas: diseño de sistemas de borde

detección y métricasSecOps

Credential stuffing: Ataque que prueba en masa pares usuario/contraseña filtrados de otros servicios. Firma: muchos fallos de inicio de sesión distribuidos en muchas IPs, con pocos intentos por cuenta.→ Ataques L7: qué buscar
Z-score: Distancia de un valor a la media, medida en desviaciones estándar. En detección, valores muy por encima del historial reciente de la misma clave sugieren una anomalía.→ Ingeniería de detección
EWMAmedia móvil exponencial: Media que da más peso a los datos recientes. Se usa como baseline adaptativo: acompaña el cambio del tráfico normal sin quedar atada al pasado.→ Ingeniería de detección
Cardinalidad: Cantidad de valores distintos de un campo (IPs, user agents). La alta cardinalidad encarece las agregaciones y tumba los sistemas de métricas; agregue por el nivel más grueso que todavía separe el ataque de lo normal.→ Escala: telemetría, cardinalidad y costo
MTTTmean time to triage: Tiempo medio entre la alerta y su clasificación como real o falsa.→ SLOs de SOC y tuning continuo
MTTCmean time to contain: Tiempo medio entre la confirmación de un ataque y su contención.→ SLOs de SOC y tuning continuo
Precisión y recall: Precisión: de las alertas emitidas, cuántas eran ataques reales. Recall: de los ataques existentes, cuántos se detectaron. Subir uno tiende a bajar el otro.→ SLOs de SOC y tuning continuo

infraestructura y política como códigoIngeniería

IaCinfraestructura como código: Describir la infraestructura en archivos versionados (Terraform, Ansible). Aporta revisión, historial y pruebas a la configuración, pero replica errores a escala si no se escanea.→ Infraestructura segura como código
Drift: Divergencia entre el estado real de la infraestructura y el descrito en el código, normalmente por un cambio manual. Detectarlo mantiene el código como fuente de verdad.→ Infraestructura segura como código
RegoOPA: Lenguaje declarativo de Open Policy Agent para escribir políticas que se evalúan sobre una entrada (un plan de Terraform, un manifiesto de Kubernetes, una solicitud de API).→ Policy as code
OIDC en el pipeline: El pipeline demuestra su identidad al proveedor de nube con un token de corta duración y recibe credenciales temporales, eliminando las claves estáticas guardadas como secretos.→ Hardening de CI/CD
SLSA: Framework de niveles de garantía para la cadena de build: quién construyó el artefacto, a partir de qué fuente y en qué entorno, con procedencia verificable.→ Hardening de CI/CD

escala y confiabilidadIngeniería

Lag: Distancia entre el final del log y la posición del consumidor. Es la señal más directa de que la detección va atrasada.→ Observabilidad de la propia plataforma de seguridad
Idempotencia: Propiedad de una operación que, al repetirse, produce el mismo resultado que una sola ejecución. Base para tolerar entregas duplicadas sin actuar dos veces.→ Confiabilidad a escala: idempotencia, reintentos y backpressure
DLQdead letter queue: Cola para los eventos que no pudieron procesarse tras los reintentos. Evita bloquear el flujo y conserva el evento para su análisis.→ Confiabilidad a escala: idempotencia, reintentos y backpressure
Backpressure: Mecanismo por el cual un consumidor lento hace que el productor desacelere (o que el exceso se descarte de forma deliberada), en lugar de que la memoria crezca sin límite.→ Confiabilidad a escala: idempotencia, reintentos y backpressure
SOAR: Orquestación, automatización y respuesta de seguridad: ejecutar pasos de respuesta de forma automática, descritos en playbooks, con frenos como la aprobación humana y la auditoría.→ Automatización de seguridad y playbooks como código

acceso e identidadOWASP Top 10

IDORreferencia directa insegura a objetos · BOLA: La solicitud nombra un objeto (un id) y el servidor lo devuelve sin comprobar que quien llama puede verlo. Es la forma más común de control de acceso roto y, en las APIs, se llama broken object level authorization.→ A01 Broken Access Control
Denegar por defecto: El acceso está prohibido a menos que una regla lo permita explícitamente, de modo que una ruta olvidada falla cerrada en lugar de abierta.→ A01 Broken Access Control
Credential stuffing: Reutilizar pares de correo y contraseña filtrados en otras brechas contra tu login. Funciona porque la gente reutiliza contraseñas, así que la defensa es throttling, verificación de contraseñas filtradas y un segundo factor.→ A07 Authentication Failures
Session fixation: Un atacante coloca un id de sesión conocido en el navegador de la víctima; si la app conserva ese id después del login, el atacante comparte la sesión. Regenera el id al iniciar sesión.→ A07 Authentication Failures
PasskeyWebAuthn: Un inicio de sesión resistente al phishing basado en un par de claves guardado en el dispositivo del usuario; el sitio solo conserva la clave pública, así que no hay contraseña que robar ni reutilizar.→ A07 Authentication Failures

datos y entradaOWASP Top 10

SQL injectionSQLi: La entrada concatenada en una cadena SQL se interpreta como parte de la consulta. Las consultas parametrizadas envían los valores por separado y eliminan el problema.→ A05 Injection
XSScross-site scripting: Inyección en una página web: la entrada no confiable se renderiza como HTML o script en el navegador de otro usuario. Haz escape en la salida según el contexto y agrega una Content-Security-Policy.→ A05 Injection
Prepared statementconsulta parametrizada: Una consulta cuya estructura se fija antes de suministrar cualquier valor, de modo que la base de datos no puede confundir datos con instrucciones.→ A05 Injection
Argon2id: Una función de hash de contraseñas de uso intensivo de memoria con salt integrado. La lentitud es el objetivo: hace que cada intento sea costoso para el atacante.→ A04 Cryptographic Failures
CSPRNGgenerador de números aleatorios criptográficamente seguro: La fuente de bytes impredecibles del sistema operativo (secrets en Python, crypto.randomBytes en Node, crypto/rand en Go). Úsala para tokens y claves, nunca Math.random.→ A04 Cryptographic Failures
Cifrado autenticadoAEAD: Cifrado que además detecta la manipulación (AES-GCM, ChaCha20-Poly1305). El cifrado por sí solo no impide que un atacante modifique el texto cifrado.→ A04 Cryptographic Failures

diseño y cadena de suministroOWASP Top 10

Modelo de amenazas: Una respuesta estructurada a cuatro preguntas: qué estamos construyendo, qué puede salir mal, qué haremos al respecto y si hicimos un buen trabajo.→ A06 Insecure Design
Caso de abuso: Una historia de usuario escrita desde el lado del atacante. Cada una produce un requisito y una prueba.→ A06 Insecure Design
SBOMlista de materiales de software: Un inventario legible por máquina de los componentes de un build. Responde "¿estamos afectados?" en minutos cuando se anuncia una nueva vulnerabilidad.→ A03 Software Supply Chain Failures
Dependency confusion: Engañar a un build para que descargue un paquete público con el mismo nombre que uno interno. Usa nombres con alcance y un registry privado que tenga prioridad.→ A03 Software Supply Chain Failures
Subresource IntegritySRI: Un hash en una etiqueta script o link que hace que el navegador rechace el archivo si no coincide, de modo que una CDN comprometida no pueda alterar tu página.→ A08 Software or Data Integrity Failures
Deserialización insegura: Reconstruir objetos a partir de bytes no confiables con un formato que puede instanciar tipos arbitrarios (serialización de Java, pickle). Los bytes pueden provocar la ejecución de código.→ A08 Software or Data Integrity Failures

operación y falloOWASP Top 10

Fail closedfail secure: Cuando una verificación de seguridad no puede decidir (timeout, error), la respuesta es denegar. Lo contrario, fallar abierto, convierte cada caída en un bypass del control de acceso.→ A10 Mishandling of Exceptional Conditions
Log injection: La entrada del usuario que contiene saltos de línea o caracteres de control falsifica entradas de log. Codifica la entrada o usa logging estructurado (JSON).→ A09 Security Logging and Alerting Failures
Correlation idrequest id: Un id único asociado a una solicitud y a cada línea de log que genera, que se muestra al usuario en los mensajes de error para que soporte encuentre los detalles sin filtrarlos.→ A09 Security Logging and Alerting Failures
Mala configuración de seguridad: Software correcto ejecutándose con configuraciones inseguras: debug activado, credenciales por defecto, almacenamiento público, CORS permisivo, headers ausentes.→ A02 Security Misconfiguration
CORSintercambio de recursos entre orígenes: Un mecanismo del navegador que permite a un servidor indicar qué otros orígenes pueden leer sus respuestas. Un origen comodín combinado con credenciales es una mala configuración.→ A02 Security Misconfiguration

capas y términosVibecoding

Vibe coding: Un estilo de programación en el que describes lo que quieres y diriges ejecutando el resultado, sin leer cada línea. El término se popularizó a principios de 2025 y hoy suele nombrar la programación asistida por IA en general.→ El espectro del vibecoding
Modelo: La red neuronal que predice el siguiente paso. Produce texto, incluidas solicitudes para llamar herramientas. No es la herramienta en la que escribes.→ Modelo, harness y provider
Harnessagent harness · scaffold: El programa que rodea al modelo: arma el prompt, expone herramientas, aplica permisos y ejecuta el loop. Claude Code, OpenCode, oh-my-pi y Codex CLI son harnesses.→ Modelo, harness y provider
Provider: Dónde se ejecuta un modelo y cómo llegas a él: la API del proveedor, una nube, un enrutador como OpenRouter o tu propia máquina.→ Modelo, harness y provider
Modelo open-weight: Un modelo cuyos pesos entrenados se publican, de modo que puedes ejecutarlo por tu cuenta. No siempre es lo mismo que open source: revisa la licencia.→ Elegir un modelo: de frontera, barato y abierto

herramientasVibecoding

OMPoh-my-pi: Un agent de código open source para terminal que comenzó como un fork del minimalista Pi agent y añadió ediciones estructuradas, operaciones de language server y debugger, acceso al navegador, plugins y subagents.→ Agents de código comparados
OMOOh My OpenAgent · oh-my-opencode: Un plugin de OpenCode que añade un equipo de agents especializados y un modo multiagente autónomo. Extiende un harness; no es uno.→ Agents de código comparados
herdr: Un multiplexor de terminal para agents de código con IA. Mantiene varios agents en paneles de terminal reales, muestra su estado y persiste tras las desconexiones. Organiza los agents en lugar de reemplazarlos.→ Orquestación y agents en paralelo
Git worktree: Un directorio de trabajo adicional, con su propia rama, para el mismo repositorio. Da a cada agent un lugar aislado donde trabajar.→ Orquestación y agents en paralelo

trabajar bien y con seguridadVibecoding

AGENTS.md: Un archivo en la raíz del repositorio con instrucciones para agents de código (comandos, convenciones, límites). Una convención común entre herramientas; Claude Code lee CLAUDE.md.→ Context engineering para agents de código
MCPModel Context Protocol: Un protocolo abierto para conectar agents con herramientas y fuentes de datos mediante servidores. Cada servidor que conectas amplía lo que el agent puede hacer y, por lo tanto, también amplía la superficie de ataque.→ Context engineering para agents de código
Plan mode: Un modo de solo lectura en el que el agent explora y propone un plan para su aprobación antes de editar nada.→ Context engineering para agents de código
Prompt injection: Instrucciones ocultas en contenido que el agent lee (un README, una página web, el resultado de una herramienta) y que el modelo puede seguir como si las hubieras escrito tú.→ Proteger al propio agent
Slopsquatting: Registrar un paquete con un nombre que una IA inventó, de modo que un agent o desarrollador que lo instale sin verificar reciba malware.→ Proteger al propio agent
Loop de verificación: Las comprobaciones que todo cambio debe pasar antes de ser considerado confiable: pruebas que deciden, un diff que tú lees, gates de CI y revisión independiente.→ El loop de verificación

entregaDevOps

CIintegración continua: Integrar cambios pequeños en una rama compartida con frecuencia, con cada cambio compilado y probado automáticamente, para que los problemas de integración aparezcan en minutos.→ El ciclo de vida de la entrega
CDentrega continua · despliegue continuo: La entrega continua mantiene cada cambio listo para desplegarse en cualquier momento; el despliegue continuo va más allá y libera automáticamente a producción cada cambio que pasa las pruebas.→ El ciclo de vida de la entrega
Artefacto: La salida versionada e inmutable de un build (una imagen de contenedor, un paquete). El mismo artefacto se promueve por todos los entornos.→ Pipelines de CI que siguen siendo rápidos
Trunk-based development: Trabajar en ramas de corta vida que se integran con frecuencia en la rama principal, ocultando el trabajo sin terminar detrás de feature flags.→ Flujos de Git y code review
CODEOWNERS: Un archivo del repositorio que asigna rutas a las personas o equipos que deben revisar los cambios allí.→ Flujos de Git y code review

releaseDevOps

Canary release: Enviar una pequeña parte del tráfico a una nueva versión, observar sus métricas y luego ampliarla. Limita el daño de un mal release.→ Estrategias de release y rollback
Blue/green deployment: Dos entornos completos: el tráfico pasa del antiguo al nuevo de una sola vez, y el rollback consiste en volver a cambiarlo.→ Estrategias de release y rollback
Feature flag: Un interruptor en la configuración que activa o desactiva una funcionalidad sin un nuevo deploy. Separa desplegar el código de liberarlo.→ Estrategias de release y rollback

plataformaDevOps

IaCinfraestructura como código: Describir la infraestructura en archivos versionados que se revisan y se aplican con herramientas, de modo que los entornos sean reproducibles.→ Infraestructura como código
Drift: Una diferencia entre la infraestructura real y lo que dice el código, normalmente por un cambio manual.→ Infraestructura como código
Imagen de contenedor: Una pila de capas de solo lectura más metadatos desde la cual arrancan los contenedores. Se identifica por un digest y se etiqueta con un nombre mutable.→ Contenedores e imágenes
Pod: En Kubernetes, uno o más contenedores que corren juntos y comparten una identidad de red. La unidad desplegable más pequeña, y desechable.→ Fundamentos de Kubernetes
Probereadiness · liveness: Una verificación de salud que ejecuta el clúster: la readiness decide si un pod recibe tráfico, la liveness decide si debe reiniciarse.→ Fundamentos de Kubernetes

operaciones y confiabilidadDevOps

SLIindicador de nivel de servicio: Una medición de la calidad del servicio tal como la perciben los usuarios, como la fracción de solicitudes que tienen éxito con rapidez.→ Confiabilidad: SLOs, error budgets e incidentes
SLOobjetivo de nivel de servicio: La meta de un SLI en una ventana de tiempo. Define qué tan confiable es suficientemente confiable.→ Confiabilidad: SLOs, error budgets e incidentes
Error budget: La falta de confiabilidad permitida: 100% menos el SLO. Mientras queda, puedes asumir riesgos; cuando se agota, el trabajo de confiabilidad va primero.→ Confiabilidad: SLOs, error budgets e incidentes
Golden signals: Latencia, tráfico, errores y saturación: cuatro mediciones que describen la salud de casi cualquier servicio.→ Observabilidad: métricas, logs y traces
Cardinalidad: El número de combinaciones distintas de labels en una métrica. Los labels sin límite (ids de usuario) pueden saturar un sistema de métricas.→ Observabilidad: métricas, logs y traces
Postmortemrevisión sin culpables: Una revisión escrita de un incidente que pregunta cómo lo permitió el sistema, no quién se equivocó, y termina con acciones que tienen responsable.→ Confiabilidad: SLOs, error budgets e incidentes

proceso y rolesRespuesta a incidentes

Comandante del incidenteIC: La persona que es responsable de la respuesta y toma las decisiones, mientras otros hacen el trabajo técnico. Mantener estos roles separados evita que el líder desaparezca en los detalles técnicos.→ El ciclo de vida de la respuesta a incidentes
Severidadnivel SEV: Una escala acordada de qué tan grave es un incidente, definida de antemano para que nadie discuta sobre ello durante el evento. Determina a quién se avisa y con qué rapidez.→ El ciclo de vida de la respuesta a incidentes
Ejercicio de mesa (tabletop): Un ensayo basado en la discusión de un escenario de incidente. Prueba el plan, los contactos y las decisiones sin tocar producción.→ El ciclo de vida de la respuesta a incidentes
Contención: Limitar la propagación y el daño de un incidente: aislar un host, revocar credenciales, bloquear un destino. La contención de corto plazo gana tiempo; la de largo plazo prepara una recuperación limpia.→ Triaje, acotamiento del alcance y contención
Triaje: La primera evaluación de una alerta: si es real, hasta dónde llegó y qué tan urgente es.→ Triaje, acotamiento del alcance y contención

detección e inteligenciaRespuesta a incidentes

Threat hunting: Una búsqueda proactiva en la telemetría de actividad de atacantes que las detecciones automáticas no vieron, guiada por una hipótesis comprobable.→ Threat hunting
IOCindicador de compromiso: Un observable que sugiere compromiso, como el hash de un archivo, un dominio o una dirección. Es rápido de usar y rápido de caducar, porque los atacantes los cambian con facilidad.→ Inteligencia de amenazas
TTPtácticas, técnicas y procedimientos: Cómo opera un adversario. Al atacante le resulta mucho más difícil cambiar su comportamiento que un indicador, por lo que es una base más duradera para la detección.→ Inteligencia de amenazas
MITRE ATT&CK: Una base de conocimiento pública de tácticas y técnicas de adversarios observadas en intrusiones reales, usada para describir comportamiento y medir la cobertura de detección.→ Inteligencia de amenazas
Pirámide del Dolor (Pyramid of Pain): Un modelo que clasifica los indicadores según cuánto daña al atacante que se los bloquee, de triviales (valores hash) a dolorosos (tácticas y técnicas).→ Inteligencia de amenazas
Sigma: Un formato neutral respecto a proveedores para reglas de detección, que puede convertirse al lenguaje de consulta de muchos productos SIEM.→ Análisis de logs y construcción de una línea de tiempo
Pivoteo (pivoting): Tomar un hecho conocido (una dirección, una cuenta, un hash) y buscar todo lo demás que lo comparte, para ampliar o reducir el alcance.→ Análisis de logs y construcción de una línea de tiempo

forense y malwareRespuesta a incidentes

Cadena de custodia: Un registro escrito de quién tuvo en su poder una evidencia, cuándo y qué se hizo con ella. Respalda la credibilidad de la evidencia en una disputa.→ Fundamentos de forense digital
Orden de volatilidad: El principio de recolectar primero la evidencia más frágil: la memoria, luego procesos y conexiones, luego archivos temporales, luego disco y logs.→ Fundamentos de forense digital
Bloqueador de escritura (write blocker): Un dispositivo o software que permite leer un disco sin permitir ningún cambio en él, de modo que la evidencia quede intacta.→ Fundamentos de forense digital
YARA: Un lenguaje para describir los patrones que identifican una familia de archivos, usado para encontrar muestras y variantes de malware.→ Fundamentos de análisis de malware
Sandbox: Un entorno aislado donde un archivo sospechoso puede ejecutarse bajo monitoreo para observar su comportamiento de forma segura.→ Fundamentos de análisis de malware
Doble extorsión (double extortion): Una táctica de ransomware que cifra los sistemas y además roba datos, amenazando con publicarlos, de modo que restaurar desde un respaldo no termina la presión.→ Playbook de respuesta a ransomware

compromisos de pruebaSeguridad ofensiva

Reglas de compromisoRoE: El documento acordado que convierte el permiso en límites prácticos: alcance, ventana de tiempo, acciones prohibidas, tasa de solicitudes, contactos de emergencia y cómo se reportan los hallazgos.→ Autorización, alcance y ética
Alcance: La lista de sistemas, cuentas y actividades que pueden probarse, y de los explícitamente excluidos. Todo lo que queda fuera no está autorizado.→ Autorización, alcance y ética
Divulgación coordinadadivulgación responsable: Reportar una vulnerabilidad de forma privada a su responsable y darle un plazo razonable para corregirla antes de publicar cualquier detalle.→ Autorización, alcance y ética
Prueba de penetraciónpentest: Un intento, con tiempo limitado, de explotar debilidades dentro de un alcance acordado, para mostrar lo que un atacante realmente podría hacer.→ Metodología de pruebas de penetración
Black, gray y white box: Cuánto sabe el evaluador de antemano: nada, algo (como cuentas y documentación) o todo, incluido el código fuente.→ Metodología de pruebas de penetración
PTESPenetration Testing Execution Standard: Una descripción de las fases de una prueba de penetración, desde el pre-compromiso hasta el informe.→ Metodología de pruebas de penetración

técnicasSeguridad ofensiva

Superficie de ataque: Todo lo que un atacante puede alcanzar e intentar: activos expuestos a internet, servicios, interfaces y las personas que los usan.→ Reconocimiento y superficie de ataque
Recon pasivo y activo: El pasivo reúne información sin tocar el objetivo; el activo lo sondea directamente y debe respetar el alcance y los límites de tasa.→ Reconocimiento y superficie de ataque
Subdomain takeover: Un registro DNS que apunta a un recurso de nube o SaaS que ya no existe y que otra persona puede reclamar para servir contenido desde tu dominio.→ Reconocimiento y superficie de ataque
BOLAbroken object level authorization: Una API acepta el id de un objeto y lo devuelve sin verificar si quien llama puede acceder a él. Es la forma de IDOR en las APIs.→ Pruebas de seguridad de web y API
Mass assignment: Una API vincula campos enviados por el cliente a un objeto, permitiendo que quien llama defina campos (como un rol) que no debería controlar.→ Pruebas de seguridad de web y API
Ruta de ataque: Una cadena de permisos, credenciales y relaciones de confianza que lleva de un punto de apoyo a algo valioso. Los defensores mapean y cortan estas rutas.→ Rutas de ataque y escalada de privilegios
Escalada de privilegios: Obtener más derechos de los concedidos inicialmente, mediante una falla, una configuración incorrecta o una credencial robada.→ Rutas de ataque y escalada de privilegios

ejercicios e informesSeguridad ofensiva

Red team: Una simulación basada en objetivos, por lo general encubierta, de un adversario realista, que pone a prueba las personas, los procesos y la tecnología de la organización.→ Red team, purple team y emulación de adversario
Purple team: Un ejercicio colaborativo en el que atacantes y defensores trabajan juntos abiertamente, verificando la detección técnica por técnica y corrigiendo las brechas de inmediato.→ Red team, purple team y emulación de adversario
Emulación de adversario: Reproducir el comportamiento documentado de un actor de amenaza específico para probar si las defensas lo detectarían.→ Red team, purple team y emulación de adversario
DMARC: Una política de autenticación de correo que indica a los receptores qué hacer con los mensajes que fallan las verificaciones SPF o DKIM de tu dominio y adónde enviar los informes.→ Ingeniería social y defensa contra phishing
CVSSCommon Vulnerability Scoring System: Un estándar para puntuar la severidad técnica de una vulnerabilidad. Hay que ajustarlo a tu contexto antes de usarlo para fijar la prioridad.→ Reportar hallazgos y conducir la remediación
Reteste: Verificar que una corrección realmente cierra un hallazgo, y no solo la solicitud exacta que se reportó.→ Reportar hallazgos y conducir la remediación

riesgoGRC y liderazgo

Apetito de riesgo: Cuánto riesgo está dispuesta a aceptar la organización en la búsqueda de sus objetivos. Define qué riesgos necesitan tratamiento y cuáles pueden aceptarse.→ Gestión de riesgos de seguridad
Riesgo inherente y residual: El riesgo inherente es el nivel antes de los controles; el riesgo residual es el que queda después. Reportar ambos muestra lo que los controles realmente logran.→ Gestión de riesgos de seguridad
Registro de riesgos: El registro de trabajo de los riesgos identificados: responsable, calificación, controles, tratamiento, acciones y fecha de revisión.→ Gestión de riesgos de seguridad
Tratamiento del riesgo: Las cuatro respuestas a un riesgo: reducirlo con controles, aceptarlo de forma consciente, transferirlo (seguro, contrato) o evitarlo dejando de realizar la actividad.→ Gestión de riesgos de seguridad
Riesgo de concentración: Dependencia excesiva de un proveedor, prestador o tecnología, de modo que su falla se convierte en la tuya.→ Riesgo de terceros y de la cadena de suministro
Clasificación de proveedores por niveles (vendor tiering): Agrupar a los proveedores por criticidad para que la profundidad de la revisión y del monitoreo corresponda al impacto de su falla.→ Riesgo de terceros y de la cadena de suministro

marcos y cumplimientoGRC y liderazgo

ISMSsistema de gestión de seguridad de la información: El conjunto de políticas, procesos y controles que una organización usa para gestionar la seguridad de la información, según exige la ISO 27001.→ Marcos y estándares de seguridad
NIST CSF: Un marco voluntario que organiza un programa de seguridad en funciones: Govern, Identify, Protect, Detect, Respond y Recover.→ Marcos y estándares de seguridad
CIS Controls: Una lista priorizada de salvaguardas prácticas agrupadas en niveles de implementación, útil para decidir por dónde empezar.→ Marcos y estándares de seguridad
SOC 2: Un informe de un auditor sobre los controles de un proveedor de servicios en materia de seguridad y criterios relacionados, solicitado con frecuencia por los clientes.→ Marcos y estándares de seguridad
Control: Una salvaguarda que reduce la probabilidad o el impacto de un riesgo; para ser auditable debe tener responsable, frecuencia y evidencia.→ Cumplimiento en la práctica: controles, evidencias y auditorías
Evidencia: Prueba de que un control operó durante un período, como una exportación de configuración, un log, un ticket o un registro de aprobación.→ Cumplimiento en la práctica: controles, evidencias y auditorías

arquitectura y liderazgoGRC y liderazgo

Zero trust: Un enfoque que no otorga confianza por la ubicación en la red: cada solicitud se autentica y autoriza usando identidad, dispositivo y contexto.→ Principios de arquitectura de seguridad
ADRregistro de decisión de arquitectura: Un documento breve que registra una decisión significativa, su contexto, alternativas y consecuencias.→ Principios de arquitectura de seguridad
KRIindicador clave de riesgo: Una medida que advierte que el riesgo está aumentando, como un backlog creciente de hallazgos críticos o de sistemas sin soporte.→ Métricas de seguridad e informes para la dirección
Joyas de la corona (crown jewels): Los activos cuya pérdida o compromiso dañaría más a la organización. La estrategia comienza por identificarlos y protegerlos.→ Estrategia, hoja de ruta y presupuesto de seguridad
Reporte sin culpa (blameless reporting): Una cultura en la que se apoya a quienes reportan errores o incidentes rápidamente, porque los reportes tempranos limitan el daño.→ Comunicación de crisis y cultura de seguridad
Security champion: Una persona de un equipo de ingeniería o de negocio que actúa como punto de contacto local para la seguridad y la incorpora al trabajo diario.→ Comunicación de crisis y cultura de seguridad