Este glosario explica los t\u00e9rminos t\u00e9cnicos clave en lenguaje sencillo, adaptado para auditores, responsables de cumplimiento y gestores de riesgos. Para cada t\u00e9rmino, explicamos qu\u00e9 es<\/strong>, por qu\u00e9 les importa a los auditores<\/strong> y qu\u00e9 evidencias buscar<\/strong>.<\/p>\n Qu\u00e9 es:<\/strong> Un sistema automatizado que construye, prueba e implementa software cada vez que los desarrolladores realizan cambios. Piense en \u00e9l como una l\u00ednea de montaje digital para el software: el c\u00f3digo entra por un extremo y el software probado y empaquetado sale por el otro.<\/p>\n Por qu\u00e9 les importa a los auditores:<\/strong> Los pipelines CI\/CD son la capa de aplicaci\u00f3n de controles<\/em> para la entrega de software. Si los controles de seguridad no est\u00e1n integrados en este pipeline, es probable que no se apliquen en absoluto. Bajo DORA y NIS2, los sistemas CI\/CD se consideran sistemas TIC regulados.<\/p>\n Evidencias a buscar:<\/strong> Registros de ejecuci\u00f3n del pipeline con marcas de tiempo, registros de finalizaci\u00f3n obligatoria de etapas, flujos de trabajo de aprobaci\u00f3n antes de la implementaci\u00f3n en producci\u00f3n.<\/p>\n Qu\u00e9 es:<\/strong> Una secuencia de pasos automatizados (construcci\u00f3n, prueba, an\u00e1lisis, implementaci\u00f3n) por los que el c\u00f3digo debe pasar antes de llegar a producci\u00f3n. Cada paso puede aplicar una puerta de seguridad.<\/p>\n Por qu\u00e9 les importa a los auditores:<\/strong> La arquitectura del pipeline determina si los controles de seguridad son obligatorios<\/em> u opcionales<\/em>. Un pipeline bien dise\u00f1ado impide que el c\u00f3digo no aprobado llegue a producci\u00f3n.<\/p>\n Evidencias a buscar:<\/strong> Archivos de configuraci\u00f3n del pipeline que muestren etapas obligatorias, registros de aprobaci\u00f3n\/rechazo de puertas, registros de implementaciones bloqueadas.<\/p>\n Qu\u00e9 es:<\/strong> An\u00e1lisis automatizado del c\u00f3digo fuente para encontrar vulnerabilidades de seguridad antes<\/em> de que se ejecute el software. Lee el c\u00f3digo como lo har\u00eda un revisor, buscando patrones de vulnerabilidades conocidos.<\/p>\n Por qu\u00e9 les importa a los auditores:<\/strong> SAST proporciona evidencia de que las pruebas de seguridad se realizan de forma temprana en el desarrollo. Demuestra que la organizaci\u00f3n identifica vulnerabilidades de forma proactiva en lugar de descubrirlas en producci\u00f3n.<\/p>\n Evidencias a buscar:<\/strong> Registros de an\u00e1lisis con marcas de tiempo, aplicaci\u00f3n de pol\u00edticas que muestren compilaciones bloqueadas por hallazgos cr\u00edticos, informes de tendencias que muestren tasas de remediaci\u00f3n a lo largo del tiempo, procesos documentados de supresi\u00f3n\/excepci\u00f3n.<\/p>\n Qu\u00e9 es:<\/strong> Pruebas automatizadas de una aplicaci\u00f3n en ejecuci\u00f3n mediante la simulaci\u00f3n de ataques reales. A diferencia de SAST (que lee el c\u00f3digo), DAST prueba la aplicaci\u00f3n como lo har\u00eda un atacante, desde el exterior.<\/p>\n Por qu\u00e9 les importa a los auditores:<\/strong> DAST valida que las aplicaciones implementadas son resilientes ante patrones de ataque conocidos. Complementa a SAST al probar el comportamiento en el mundo real, no solo el c\u00f3digo.<\/p>\n Evidencias a buscar:<\/strong> Informes de an\u00e1lisis DAST con vulnerabilidades identificadas y clasificaciones de gravedad, plazos de remediaci\u00f3n, programas de an\u00e1lisis recurrentes, integraci\u00f3n con registros del pipeline CI\/CD.<\/p>\n Qu\u00e9 es:<\/strong> An\u00e1lisis automatizado de bibliotecas y dependencias de terceros utilizadas en el software. La mayor\u00eda de las aplicaciones modernas son un 70-90% de c\u00f3digo de terceros \u2014 SCA comprueba si ese c\u00f3digo tiene vulnerabilidades conocidas o riesgos de licencia.<\/p>\n Por qu\u00e9 les importa a los auditores:<\/strong> El riesgo de componentes de terceros es una preocupaci\u00f3n clave bajo el Art\u00edculo 28 de DORA y los requisitos de la cadena de suministro de NIS2. SCA proporciona visibilidad de la cadena de suministro de software.<\/p>\n Evidencias a buscar:<\/strong> Inventarios de dependencias, informes de vulnerabilidades para componentes de terceros, comprobaciones de cumplimiento de licencias, bloqueo automatizado de componentes con vulnerabilidades cr\u00edticas.<\/p>\n Qu\u00e9 es:<\/strong> Un inventario completo y legible por m\u00e1quina de cada componente (bibliotecas, marcos, dependencias) incluido en una aplicaci\u00f3n de software. Piense en \u00e9l como una etiqueta nutricional para el software.<\/p>\n Por qu\u00e9 les importa a los auditores:<\/strong> Los SBOMs son cada vez m\u00e1s obligatorios por regulaci\u00f3n. Permiten la trazabilidad de los componentes de la cadena de suministro y la evaluaci\u00f3n r\u00e1pida del impacto cuando se divulgan nuevas vulnerabilidades.<\/p>\n Evidencias a buscar:<\/strong> Archivos SBOM generados (formato SPDX o CycloneDX), generaci\u00f3n automatizada de SBOM en pipelines CI\/CD, registros de retenci\u00f3n y versionado de SBOM.<\/p>\n Qu\u00e9 es:<\/strong> Un enfoque de pruebas h\u00edbrido que monitoriza las aplicaciones desde dentro durante las pruebas. Un agente se integra en la aplicaci\u00f3n y observa las rutas de ejecuci\u00f3n de c\u00f3digo reales para identificar vulnerabilidades con alta precisi\u00f3n.<\/p>\n Por qu\u00e9 les importa a los auditores:<\/strong> IAST proporciona resultados muy precisos con menos falsos positivos que SAST o DAST por separado, lo que significa que los hallazgos son m\u00e1s accionables y auditables.<\/p>\n Evidencias a buscar:<\/strong> Registros de implementaci\u00f3n del agente IAST, informes de ejecuci\u00f3n de pruebas, hallazgos de vulnerabilidades correlacionados con rutas de c\u00f3digo espec\u00edficas.<\/p>\n Qu\u00e9 es:<\/strong> Un agente de seguridad en tiempo de ejecuci\u00f3n integrado dentro de la aplicaci\u00f3n que detecta y bloquea ataques en tiempo real. A diferencia de un firewall (que protege el per\u00edmetro), RASP protege desde dentro de la aplicaci\u00f3n.<\/p>\n Por qu\u00e9 les importa a los auditores:<\/strong> RASP demuestra protecci\u00f3n en tiempo de ejecuci\u00f3n: un control detectivo y correctivo que opera de forma continua, no solo durante las fases de prueba.<\/p>\n Evidencias a buscar:<\/strong> Configuraci\u00f3n de implementaci\u00f3n de RASP, registros de ataques bloqueados, registros de integraci\u00f3n de alertas\/incidentes, informes de cobertura.<\/p>\n Qu\u00e9 es:<\/strong> Un contenedor<\/strong> es un paquete ligero y aislado que agrupa una aplicaci\u00f3n con todo lo que necesita para ejecutarse. Una imagen<\/strong> es la plantilla utilizada para crear contenedores. Un registro<\/strong> es el repositorio donde se almacenan y distribuyen las im\u00e1genes.<\/p>\n Por qu\u00e9 les importa a los auditores:<\/strong> Los contenedores son la unidad de implementaci\u00f3n est\u00e1ndar en los entornos modernos. Las im\u00e1genes sin firmar o sin analizar representan un riesgo en la cadena de suministro. Los controles de acceso al registro determinan qui\u00e9n puede implementar qu\u00e9.<\/p>\n Evidencias a buscar:<\/strong> Informes de an\u00e1lisis de im\u00e1genes, registros de firma\/verificaci\u00f3n de im\u00e1genes, pol\u00edticas de control de acceso al registro, pol\u00edticas de actualizaci\u00f3n de im\u00e1genes base.<\/p>\n Qu\u00e9 es:<\/strong> Gesti\u00f3n de la infraestructura (servidores, redes, bases de datos) a trav\u00e9s de archivos de c\u00f3digo en lugar de configuraci\u00f3n manual. Los cambios en la infraestructura pasan por el mismo pipeline que el c\u00f3digo de la aplicaci\u00f3n.<\/p>\n Por qu\u00e9 les importa a los auditores:<\/strong> IaC hace que los cambios de infraestructura sean trazables, revisables y auditables: los mismos controles de gobernanza que se aplican al c\u00f3digo pueden aplicarse a la infraestructura.<\/p>\n Evidencias a buscar:<\/strong> Plantillas IaC en control de versiones, registros de aprobaci\u00f3n de cambios, informes de detecci\u00f3n de desviaciones, an\u00e1lisis de seguridad de plantillas IaC.<\/p>\n Qu\u00e9 es:<\/strong> La pr\u00e1ctica de almacenar, distribuir y rotar de forma segura credenciales sensibles (claves de API, contrase\u00f1as, certificados, tokens) utilizadas por aplicaciones y pipelines.<\/p>\n Por qu\u00e9 les importa a los auditores:<\/strong> Los secretos expuestos son uno de los fallos de seguridad m\u00e1s comunes y graves. Una gesti\u00f3n adecuada de secretos demuestra madurez en el control de acceso y reduce el riesgo de compromiso de credenciales.<\/p>\n Evidencias a buscar:<\/strong> Implementaci\u00f3n de b\u00f3veda\/gestor de secretos centralizado, pol\u00edticas de rotaci\u00f3n automatizada, sin secretos codificados en el c\u00f3digo (verificado mediante an\u00e1lisis), registros de auditor\u00eda de acceso.<\/p>\n Qu\u00e9 es:<\/strong> Cualquier resultado producido por el pipeline CI\/CD: c\u00f3digo compilado, im\u00e1genes de contenedores, paquetes, documentaci\u00f3n. Los artefactos son lo que se implementa en producci\u00f3n.<\/p>\n Por qu\u00e9 les importa a los auditores:<\/strong> La integridad de los artefactos garantiza que lo que se prob\u00f3 es exactamente lo que se implementa. Los artefactos manipulados o sin firmar representan un riesgo cr\u00edtico en la cadena de suministro.<\/p>\n Evidencias a buscar:<\/strong> Registros de firma de artefactos, metadatos de procedencia, sumas de verificaci\u00f3n\/hashes, almacenamiento inmutable de artefactos, trazabilidad de implementaci\u00f3n hasta ejecuciones espec\u00edficas del pipeline.<\/p>\n Qu\u00e9 es:<\/strong> Codificaci\u00f3n de pol\u00edticas de seguridad y cumplimiento como reglas legibles por m\u00e1quina que son aplicadas autom\u00e1ticamente por el pipeline CI\/CD. En lugar de un documento de pol\u00edtica en PDF, la pol\u00edtica se convierte en c\u00f3digo ejecutable.<\/p>\n Por qu\u00e9 les importa a los auditores:<\/strong> Policy-as-code transforma las pol\u00edticas de documentos aspiracionales en controles aplicados. Proporciona evidencia de que las pol\u00edticas no solo est\u00e1n escritas sino que realmente se aplican.<\/p>\n Evidencias a buscar:<\/strong> Archivos de definici\u00f3n de pol\u00edticas en control de versiones, registros de aplicaci\u00f3n que muestren resultados de evaluaci\u00f3n de pol\u00edticas, registros de implementaciones bloqueadas por violaciones de pol\u00edticas.<\/p>\n Qu\u00e9 es:<\/strong> Trasladar las pruebas de seguridad y los controles hacia etapas m\u00e1s tempranas del ciclo de vida del desarrollo de software: desde la post-implementaci\u00f3n (derecha) hasta las fases de dise\u00f1o y codificaci\u00f3n (izquierda). El objetivo es detectar problemas cuando son m\u00e1s baratos y f\u00e1ciles de solucionar.<\/p>\n Por qu\u00e9 les importa a los auditores:<\/strong> Shift-left es evidencia de una postura de seguridad proactiva y preventiva en lugar de reactiva. Las regulaciones esperan cada vez m\u00e1s que la seguridad est\u00e9 integrada en todo el SDLC, no a\u00f1adida al final.<\/p>\n Evidencias a buscar:<\/strong> Requisitos de seguridad en documentos de dise\u00f1o, SAST integrado en flujos de trabajo de desarrolladores, registros de modelado de amenazas, registros de formaci\u00f3n en seguridad para desarrolladores.<\/p>\n Qu\u00e9 es:<\/strong> Un modelo operativo que integra la seguridad en cada fase del desarrollo y la entrega de software. Define roles, responsabilidades y controles automatizados para garantizar que la seguridad sea continua, no una fase o equipo separado.<\/p>\n Por qu\u00e9 les importa a los auditores:<\/strong> DevSecOps es el marco de gobernanza que hace que la seguridad CI\/CD sea sostenible. Determina qui\u00e9n es responsable de qu\u00e9, c\u00f3mo se gestionan las excepciones y c\u00f3mo se aplican los controles.<\/p>\n Evidencias a buscar:<\/strong> Roles y responsabilidades definidos (RACI), configuraciones de puertas de seguridad, flujos de trabajo de aprobaci\u00f3n de excepciones\/supresiones, m\u00e9tricas de seguridad y cadencia de informes.<\/p>\n Qu\u00e9 es:<\/strong> Garantizar que ninguna persona pueda tanto desarrollar c\u00f3digo como aprobar su implementaci\u00f3n en producci\u00f3n. Diferentes roles gestionan diferentes etapas del proceso de entrega.<\/p>\n Por qu\u00e9 les importa a los auditores:<\/strong> La SoD es un control fundamental requerido por pr\u00e1cticamente todos los marcos de cumplimiento. Previene el fraude, reduce el riesgo de amenazas internas y garantiza una revisi\u00f3n independiente.<\/p>\n Evidencias a buscar:<\/strong> Configuraciones RBAC, registros de flujos de trabajo de aprobaci\u00f3n que muestren aprobadores distintos de los autores del c\u00f3digo, reglas de protecci\u00f3n de ramas, matrices de permisos de implementaci\u00f3n.<\/p>\n Qu\u00e9 es:<\/strong> Un modelo de control de acceso donde los permisos se asignan a roles (por ejemplo, desarrollador, revisor, deployer) en lugar de a usuarios individuales. Los usuarios heredan permisos a trav\u00e9s de su asignaci\u00f3n de rol.<\/p>\n Por qu\u00e9 les importa a los auditores:<\/strong> RBAC es la base para la segregaci\u00f3n de funciones y el principio de m\u00ednimo privilegio. Proporciona un modelo de acceso estructurado y auditable.<\/p>\n Evidencias a buscar:<\/strong> Definiciones de roles y matrices de permisos, registros de asignaci\u00f3n de usuarios a roles, revisiones peri\u00f3dicas de acceso, monitoreo de roles privilegiados.<\/p>\n Este glosario se mantiene como referencia viva. Los t\u00e9rminos se definen desde la perspectiva del auditor, centrados en la verificaci\u00f3n del control, no en los detalles de implementaci\u00f3n. Para orientaci\u00f3n t\u00e9cnica de implementaci\u00f3n, visite secure-pipelines.com<\/a>.<\/em><\/p>\n","protected":false},"excerpt":{"rendered":" Glosario de Seguridad y DevSecOps para Auditores Este glosario explica los t\u00e9rminos t\u00e9cnicos clave en lenguaje sencillo, adaptado para auditores, responsables de cumplimiento y gestores de riesgos. Para cada t\u00e9rmino, explicamos qu\u00e9 es, por qu\u00e9 les importa a los auditores y qu\u00e9 evidencias buscar. CI\/CD (Integraci\u00f3n Continua \/ Entrega Continua) Qu\u00e9 es: Un sistema automatizado … Leer m\u00e1s<\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"parent":0,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"","meta":{"footnotes":""},"class_list":["post-2095","page","type-page","status-publish"],"_links":{"self":[{"href":"https:\/\/regulated-devsecops.com\/es\/wp-json\/wp\/v2\/pages\/2095","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/regulated-devsecops.com\/es\/wp-json\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/regulated-devsecops.com\/es\/wp-json\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/regulated-devsecops.com\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/regulated-devsecops.com\/es\/wp-json\/wp\/v2\/comments?post=2095"}],"version-history":[{"count":0,"href":"https:\/\/regulated-devsecops.com\/es\/wp-json\/wp\/v2\/pages\/2095\/revisions"}],"wp:attachment":[{"href":"https:\/\/regulated-devsecops.com\/es\/wp-json\/wp\/v2\/media?parent=2095"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}CI\/CD (Integraci\u00f3n Continua \/ Entrega Continua)<\/h3>\n
Pipeline<\/h3>\n
SAST (Pruebas de Seguridad de Aplicaciones Est\u00e1ticas)<\/h3>\n
DAST (Pruebas de Seguridad de Aplicaciones Din\u00e1micas)<\/h3>\n
SCA (An\u00e1lisis de Composici\u00f3n de Software)<\/h3>\n
SBOM (Lista de Materiales de Software)<\/h3>\n
IAST (Pruebas de Seguridad de Aplicaciones Interactivas)<\/h3>\n
RASP (Autoprotecci\u00f3n de Aplicaciones en Tiempo de Ejecuci\u00f3n)<\/h3>\n
Contenedor \/ Imagen \/ Registro<\/h3>\n
IaC (Infraestructura como C\u00f3digo)<\/h3>\n
Gesti\u00f3n de Secretos<\/h3>\n
Artefacto<\/h3>\n
Policy-as-Code<\/h3>\n
Shift-Left<\/h3>\n
DevSecOps<\/h3>\n
Segregaci\u00f3n de Funciones (SoD)<\/h3>\n
RBAC (Control de Acceso Basado en Roles)<\/h3>\n