{"id":2063,"date":"2026-02-09T19:40:59","date_gmt":"2026-02-09T18:40:59","guid":{"rendered":"https:\/\/regulated-devsecops.com\/uncategorized\/arquitectura-del-articulo-28-de-dora-controles-de-riesgo-ict-de-terceros-en-ci-cd-y-cloud-perspectivas-del-auditor-e-ingeniero\/"},"modified":"2026-03-26T09:36:09","modified_gmt":"2026-03-26T08:36:09","slug":"arquitectura-del-articulo-28-de-dora-controles-de-riesgo-ict-de-terceros-en-ci-cd-y-cloud-perspectivas-del-auditor-e-ingeniero","status":"publish","type":"post","link":"https:\/\/regulated-devsecops.com\/es\/regulatory-frameworks-es\/arquitectura-del-articulo-28-de-dora-controles-de-riesgo-ict-de-terceros-en-ci-cd-y-cloud-perspectivas-del-auditor-e-ingeniero\/","title":{"rendered":"Arquitectura del Art\u00edculo 28 de DORA: Controles de Riesgo ICT de Terceros en CI\/CD y Cloud (Perspectivas del Auditor e Ingeniero)"},"content":{"rendered":"\n<h2 class=\"wp-block-heading\">Introducci\u00f3n<\/h2>\n\n\n\n<p>El Art\u00edculo 28 de DORA exige a las entidades financieras que gestionen los riesgos derivados de los proveedores de servicios ICT de terceros.<\/p>\n\n\n\n<p>En la entrega de software moderna, estos proveedores no son perif\u00e9ricos \u2014 est\u00e1n integrados directamente en los pipelines CI\/CD y los entornos de ejecuci\u00f3n cloud.<\/p>\n\n\n\n<p>Este art\u00edculo presenta una vista arquitect\u00f3nica pr\u00e1ctica del Art\u00edculo 28 de DORA, mostrando:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>d\u00f3nde intervienen los proveedores de terceros a lo largo del ciclo de vida CI\/CD,<\/li>\n\n\n\n<li>qu\u00e9 controles deben aplicarse para mantener el cumplimiento,<\/li>\n\n\n\n<li>y c\u00f3mo debe producirse la evidencia para satisfacer a los auditores.<\/li>\n<\/ul>\n\n\n\n<p>El objetivo no es describir herramientas, sino clarificar los <strong>l\u00edmites de control<\/strong>, los <strong>puntos de aplicaci\u00f3n<\/strong> y las <strong>expectativas de auditor\u00eda<\/strong>.<\/p>\n\n\n\n<p>Tambi\u00e9n establece un puente entre las perspectivas de los <strong>auditores<\/strong> y los <strong>ingenieros<\/strong> \u2014 dos audiencias que leen la misma arquitectura de forma muy diferente, y cuya alineaci\u00f3n es esencial para el cumplimiento exitoso.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">La Cadena de Suministro CI\/CD Real bajo DORA<\/h2>\n\n\n\n<p>Un pipeline CI\/CD empresarial t\u00edpico depende de m\u00faltiples proveedores ICT externos, frecuentemente sin que se traten expl\u00edcitamente como tales.<\/p>\n\n\n\n<p>Bajo el Art\u00edculo 28 de DORA, los siguientes componentes deben considerarse servicios ICT de terceros:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Alojamiento de c\u00f3digo fuente<\/strong> (Git SaaS \/ Git gestionado)<\/li>\n\n\n\n<li><strong>Orquestaci\u00f3n CI\/CD<\/strong> (plataforma CI SaaS o gestionada)<\/li>\n\n\n\n<li><strong>Runners \/ ejecuci\u00f3n de builds<\/strong> (runners autohospedados o gestionados)<\/li>\n\n\n\n<li><strong>Registros de artefactos y contenedores<\/strong><\/li>\n\n\n\n<li><strong>Ecosistema de dependencias<\/strong> (paquetes, mirrors, generadores de SBOM)<\/li>\n\n\n\n<li><strong>Runtime cloud \/ plataformas gestionadas<\/strong><\/li>\n\n\n\n<li><strong>Observabilidad<\/strong> (logs, trazas, SIEM)<\/li>\n\n\n\n<li><strong>Herramientas ITSM \/ ticketing \/ aprobaciones<\/strong> (gesti\u00f3n de cambios)<\/li>\n<\/ul>\n\n\n\n<p>El Art\u00edculo 28 aplica porque cada uno de estos proveedores puede afectar a:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>la confidencialidad e integridad del c\u00f3digo fuente y los artefactos,<\/li>\n\n\n\n<li>la disponibilidad de los pipelines de entrega,<\/li>\n\n\n\n<li>la trazabilidad y auditabilidad de los cambios.<\/li>\n<\/ul>\n\n\n\n<p>Cualquier componente de terceros involucrado en la construcci\u00f3n, prueba, despliegue o ejecuci\u00f3n de software est\u00e1 dentro del alcance del Art\u00edculo 28.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Dos Perspectivas sobre la Misma Arquitectura<\/h2>\n\n\n\n<p>El Art\u00edculo 28 de DORA exige a las entidades financieras que gestionen el riesgo ICT de terceros de una manera verificable, aplicable y auditable. Sin embargo, los auditores y los ingenieros no leen las arquitecturas de la misma manera.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Perspectiva del Auditor (Gobernanza y Evidencia)<\/h3>\n\n\n\n<p>Un auditor que revisa el cumplimiento del Art\u00edculo 28 de DORA no eval\u00faa herramientas o pipelines directamente. Verifica que el riesgo est\u00e9 <strong>controlado, documentado y gestionado continuamente<\/strong>.<\/p>\n\n\n\n<p>Desde la perspectiva del auditor, la arquitectura debe responder:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>\u00bfTiene un inventario completo de proveedores ICT de terceros?<\/li>\n\n\n\n<li>\u00bfLos proveedores est\u00e1n clasificados por criticidad?<\/li>\n\n\n\n<li>\u00bfLos contratos son exigibles e incluyen derechos de auditor\u00eda, notificaci\u00f3n de incidentes y cl\u00e1usulas de salida?<\/li>\n\n\n\n<li>\u00bfSe produce evidencia de forma continua y se retiene?<\/li>\n\n\n\n<li>\u00bfPuede salir de proveedores cr\u00edticos bajo presi\u00f3n?<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Perspectiva del Ingeniero (Implementaci\u00f3n y Aplicaci\u00f3n)<\/h3>\n\n\n\n<p>Un ingeniero que mira la misma arquitectura ve un <strong>plano de control<\/strong> \u2014 un conjunto de mecanismos de aplicaci\u00f3n que deben construirse, configurarse y mantenerse.<\/p>\n\n\n\n<p>Su enfoque incluye:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>\u00bfD\u00f3nde est\u00e1n integrados los servicios de terceros en los pipelines?<\/li>\n\n\n\n<li>\u00bfC\u00f3mo se aplican t\u00e9cnicamente los controles de acceso, aprobaciones y aislamiento?<\/li>\n\n\n\n<li>\u00bfC\u00f3mo se generan los SBOMs, la firma y la procedencia?<\/li>\n\n\n\n<li>\u00bfC\u00f3mo se recopilan los logs, m\u00e9tricas y alertas de plataformas de terceros?<\/li>\n\n\n\n<li>\u00bfQu\u00e9 sucede si un proveedor falla o debe ser reemplazado?<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">La Misma Arquitectura, Dos Lecturas<\/h3>\n\n\n\n<figure class=\"wp-block-table\"><table><thead><tr><th>Aspecto<\/th><th>Perspectiva del Auditor<\/th><th>Perspectiva del Ingeniero<\/th><\/tr><\/thead><tbody><tr><td>Enfoque<\/td><td>Riesgo, gobernanza, cumplimiento<\/td><td>Automatizaci\u00f3n, aplicaci\u00f3n, fiabilidad<\/td><\/tr><tr><td>Pregunta principal<\/td><td>\u00ab\u00bfPuede probar el control?\u00bb<\/td><td>\u00ab\u00bfD\u00f3nde aplico el control?\u00bb<\/td><\/tr><tr><td>Pipeline CI\/CD<\/td><td>Superficie de riesgo<\/td><td>Plano de control<\/td><\/tr><tr><td>Proveedores de terceros<\/td><td>Proveedores a gobernar<\/td><td>Plataformas a integrar de forma segura<\/td><\/tr><tr><td>Evidencia<\/td><td>Requisito expl\u00edcito<\/td><td>Salida autom\u00e1tica<\/td><\/tr><tr><td>Estrategia de salida<\/td><td>Obligatoria<\/td><td>A menudo pasada por alto<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p>El Art\u00edculo 28 de DORA exige que ambas perspectivas se satisfagan simult\u00e1neamente.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Principios de Arquitectura para el Cumplimiento del Art\u00edculo 28<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">1. Tratar las Herramientas de Terceros como Activos de Grado Producci\u00f3n<\/h3>\n\n\n\n<p>Las plataformas CI\/CD y los registros deben seguir las reglas de producci\u00f3n: hardening, control de acceso, logging, monitoreo y continuidad probada.<\/p>\n\n\n\n<p>No son herramientas de desarrollo \u2014 son <strong>sistemas ICT regulados<\/strong>.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">2. Hacer que los Contratos Apliquen los Controles<\/h3>\n\n\n\n<p>Las cl\u00e1usulas contractuales deben habilitar (o al menos apoyar): derechos de auditor\u00eda, notificaci\u00f3n de incidentes, retenci\u00f3n de evidencia, transparencia del procesamiento de datos y estrategias de salida.<\/p>\n\n\n\n<p>Los contratos por s\u00ed solos no son suficientes bajo el Art\u00edculo 28 de DORA. Las pol\u00edticas definidas contractualmente deben ser <strong>aplicadas t\u00e9cnicamente<\/strong>:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>aprobaciones obligatorias,<\/li>\n\n\n\n<li>puertas de seguridad,<\/li>\n\n\n\n<li>rutas de ejecuci\u00f3n restringidas,<\/li>\n\n\n\n<li>capacidades de auditor\u00eda e inspecci\u00f3n.<\/li>\n<\/ul>\n\n\n\n<p>Los pipelines CI\/CD son la capa de aplicaci\u00f3n natural para estas pol\u00edticas.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">3. La Evidencia Debe Dise\u00f1arse, No \u00abRecopilarse Despu\u00e9s\u00bb<\/h3>\n\n\n\n<p>La evidencia debe ser generada por la plataforma y retenida autom\u00e1ticamente: logs, aprobaciones, SBOM\/procedencia, registros de acceso, cronolog\u00edas de incidentes y pruebas de salida.<\/p>\n\n\n\n<p>Si la evidencia requiere ensamblaje manual durante una auditor\u00eda, es improbable que cumpla las expectativas del auditor en cuanto a objetividad y continuidad.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Capas de Control a lo Largo del Ciclo de Vida CI\/CD<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Control de Acceso y Aislamiento<\/h3>\n\n\n\n<p>Bajo el Art\u00edculo 28 de DORA, las organizaciones deben demostrar que las plataformas de terceros no pueden ser utilizadas indebidamente o con privilegios excesivos.<\/p>\n\n\n\n<p>Los principios clave incluyen:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>control de acceso basado en roles,<\/li>\n\n\n\n<li>segregaci\u00f3n de funciones entre desarrollo, aprobaci\u00f3n y despliegue,<\/li>\n\n\n\n<li>acceso de m\u00ednimos privilegios para pipelines y automatizaci\u00f3n.<\/li>\n<\/ul>\n\n\n\n<p>El aislamiento de acceso aplica en:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>repositorios Git,<\/li>\n\n\n\n<li>pipelines CI\/CD y runners,<\/li>\n\n\n\n<li>repositorios de artefactos,<\/li>\n\n\n\n<li>entornos de ejecuci\u00f3n cloud.<\/li>\n<\/ul>\n\n\n\n<p>La evidencia debe demostrar que ning\u00fan actor o sistema \u00fanico puede eludir los controles de extremo a extremo.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Aplicaci\u00f3n de Pol\u00edticas Contractuales<\/h3>\n\n\n\n<p>Las pol\u00edticas definidas contractualmente deben aplicarse t\u00e9cnicamente a trav\u00e9s de los pipelines CI\/CD:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>las aprobaciones se aplican antes de la liberaci\u00f3n,<\/li>\n\n\n\n<li>policy-as-code previene cambios no autorizados,<\/li>\n\n\n\n<li>las plataformas de terceros operan bajo restricciones definidas y auditables.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Integridad de la Cadena de Suministro<\/h3>\n\n\n\n<p>El Art\u00edculo 28 de DORA exige visibilidad de la cadena de suministro de software, especialmente cuando se involucran componentes de terceros.<\/p>\n\n\n\n<p>Esto incluye:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>seguimiento de dependencias y an\u00e1lisis de composici\u00f3n de software (SCA),<\/li>\n\n\n\n<li>generaci\u00f3n de SBOM (Software Bill of Materials),<\/li>\n\n\n\n<li>firma de artefactos y verificaci\u00f3n de procedencia,<\/li>\n\n\n\n<li>escaneo de im\u00e1genes de contenedores y verificaciones de integridad.<\/li>\n<\/ul>\n\n\n\n<p>Los auditores esperan pruebas de que los artefactos producidos a trav\u00e9s de sistemas CI\/CD de terceros no han sido manipulados.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Monitoreo y Respuesta a Incidentes<\/h3>\n\n\n\n<p>Los servicios de terceros deben monitorearse continuamente:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>indicadores de disponibilidad y rendimiento,<\/li>\n\n\n\n<li>detecci\u00f3n y escalada de incidentes,<\/li>\n\n\n\n<li>integraci\u00f3n con logging centralizado o SIEM.<\/li>\n<\/ul>\n\n\n\n<p>Los auditores verifican que el monitoreo aplica a los proveedores de terceros, no solo a los sistemas internos. Los flujos de trabajo de incidentes deben referenciar a los proveedores de terceros afectados y demostrar una escalada trazable.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Estrategia de Salida y Continuidad<\/h3>\n\n\n\n<p>La planificaci\u00f3n de la salida es un requisito regulatorio bajo el Art\u00edculo 28, no un ejercicio opcional.<\/p>\n\n\n\n<p>Los auditores cuestionar\u00e1n:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>si existen planes de salida documentados para proveedores cr\u00edticos,<\/li>\n\n\n\n<li>si estos planes han sido probados o ejercitados,<\/li>\n\n\n\n<li>si la organizaci\u00f3n podr\u00eda realizar la transici\u00f3n de forma realista bajo presi\u00f3n.<\/li>\n<\/ul>\n\n\n\n<p>Los ingenieros apoyan las estrategias de salida mediante:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>evitar el bloqueo estricto por proveedor,<\/li>\n\n\n\n<li>documentar rutas de reemplazo o alternativas,<\/li>\n\n\n\n<li>mantener la reproducibilidad de infraestructura como c\u00f3digo,<\/li>\n\n\n\n<li>participar en pruebas de DR, BCP y salida.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">Qu\u00e9 Solicitan Habitualmente los Auditores<\/h2>\n\n\n\n<p>Bajo el Art\u00edculo 28 de DORA, los auditores esperan evidencia en cinco dominios:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li><strong>Inventario de proveedores<\/strong> \u2014 lista completa de proveedores ICT de terceros, clasificados por criticidad, mapeados a componentes CI\/CD y cloud<\/li>\n\n\n\n<li><strong>Cl\u00e1usulas contractuales<\/strong> \u2014 derechos de auditor\u00eda, SLAs de incidentes, retenci\u00f3n de evidencia, visibilidad de subprocesadores, obligaciones de salida<\/li>\n\n\n\n<li><strong>Evidencia de controles CI\/CD<\/strong> \u2014 logs de acceso, registros de aprobaciones, SBOM\/procedencia, definiciones de pol\u00edticas de pipeline<\/li>\n\n\n\n<li><strong>Evidencia de monitoreo<\/strong> \u2014 dashboards, tickets de incidentes referenciando proveedores de terceros, integraci\u00f3n con SIEM<\/li>\n\n\n\n<li><strong>Evidencia de estrategia de salida<\/strong> \u2014 planes de salida documentados, resultados de pruebas DR\/BCP, documentaci\u00f3n de reemplazo de dependencias<\/li>\n<\/ol>\n\n\n\n<p>La evidencia debe ser:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Trazable<\/strong> \u2192 vinculada a un proveedor o control espec\u00edfico<\/li>\n\n\n\n<li><strong>Repetible<\/strong> \u2192 generada consistentemente por los sistemas<\/li>\n\n\n\n<li><strong>Temporalmente acotada<\/strong> \u2192 muestra cu\u00e1ndo los controles estaban activos<\/li>\n\n\n\n<li><strong>Resistente a manipulaciones<\/strong> \u2192 los logs y la evidencia est\u00e1n protegidos<\/li>\n<\/ul>\n\n\n\n<p>Las hojas de c\u00e1lculo manuales por s\u00ed solas raramente cumplen estos criterios.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Brechas Comunes y Patrones de Desalineaci\u00f3n<\/h2>\n\n\n\n<p>Muchas organizaciones fallan las revisiones del Art\u00edculo 28 de DORA no porque falten controles, sino porque:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>los ingenieros implementaron controles <strong>sin respaldo contractual<\/strong>,<\/li>\n\n\n\n<li>la evidencia existe pero <strong>no es claramente atribuible<\/strong>,<\/li>\n\n\n\n<li>las estrategias de salida existen <strong>solo sobre el papel<\/strong>,<\/li>\n\n\n\n<li>las dependencias de terceros son <strong>impl\u00edcitamente confiables<\/strong>,<\/li>\n\n\n\n<li>las plataformas CI\/CD SaaS est\u00e1n <strong>excluidas del alcance de proveedores<\/strong>,<\/li>\n\n\n\n<li>los logs est\u00e1n disponibles pero <strong>no se retienen suficiente tiempo<\/strong>.<\/li>\n<\/ul>\n\n\n\n<p>Separando expl\u00edcitamente la Perspectiva del Auditor y la Perspectiva del Ingeniero, se garantiza que:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>cada control est\u00e1 respaldado por una base contractual,<\/li>\n\n\n\n<li>cada aplicaci\u00f3n t\u00e9cnica se mapea a una pista de evidencia auditable,<\/li>\n\n\n\n<li>la preparaci\u00f3n para la salida se valida, no se asume.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">Conclusi\u00f3n<\/h2>\n\n\n\n<p>La arquitectura del Art\u00edculo 28 de DORA no consiste en listar herramientas \u2014 consiste en definir <strong>d\u00f3nde reside el riesgo ICT de terceros<\/strong>, <strong>c\u00f3mo se controla<\/strong> y <strong>c\u00f3mo se prueba el cumplimiento<\/strong>.<\/p>\n\n\n\n<p>La arquitectura debe apoyar tanto la necesidad del auditor de evidencia como la necesidad del ingeniero de controles aplicables y automatizados. Cuando ambas perspectivas est\u00e1n alineadas, el cumplimiento del Art\u00edculo 28 se convierte en una propiedad estructural del sistema de entrega, no en un ejercicio peri\u00f3dico.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Recursos Relacionados<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li><a href=\"https:\/\/regulated-devsecops.com\/compliance\/dora-article-28-evidence-pack-what-to-show-auditors\/\" data-type=\"post\" data-id=\"347\">DORA Article 28 Evidence Pack (Auditor &amp; Engineer Views)<\/a><\/li>\n\n\n\n<li><a href=\"https:\/\/regulated-devsecops.com\/compliance\/dora-article-28-auditor-checklist-yes-no-evidence\/\" data-type=\"post\" data-id=\"353\">DORA Article 28 \u2014 Auditor Checklist<\/a><\/li>\n\n\n\n<li><a href=\"https:\/\/regulated-devsecops.com\/compliance\/third-party-risk-in-ci-cd-pipelines-under-dora-article-28\/\" data-type=\"post\" data-id=\"368\">Third-Party Risk in CI\/CD Pipelines under DORA Article 28<\/a><\/li>\n\n\n\n<li><a href=\"https:\/\/regulated-devsecops.com\/ci-cd-security\/continuous-compliance-via-ci-cd-pipelines\/\" data-type=\"post\" data-id=\"334\">Continuous Compliance via CI\/CD Pipelines<\/a><\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n    <section class=\"rds-author-box rds-author-box--audit\"\r\n             dir=\"ltr\" lang=\"es\"\r\n             style=\"border:1px solid rgba(100,116,139,.35);border-radius:14px;padding:16px 18px;margin:26px 0 18px;background:rgba(148,163,184,.08);\">\r\n      <strong style=\"margin:0 0 8px; font-size:14px; font-weight:700; letter-spacing:.02em;\">Contexto \u201caudit-ready\u201d<\/strong>\r\n      <p style=\"margin:0; font-size:14px; line-height:1.55;\">Contenido pensado para entornos regulados: controles antes que herramientas, enforcement en CI\/CD y evidencia por dise\u00f1o para auditor\u00edas.<\/p>\r\n      <p style=\"margin:0; font-size:14px; line-height:1.55;\">Enfoque en trazabilidad, aprobaciones, gobernanza de excepciones y retenci\u00f3n de evidencia de extremo a extremo.<\/p>\r\n      <p style=\"margin:0; font-size:14px; line-height:1.55;\">\r\n        <a href=\"https:\/\/regulated-devsecops.com\/es\/es\/about\/\">Ver la metodolog\u00eda en la p\u00e1gina About.<\/a>\r\n      <\/p>\r\n    <\/section>\r\n    \n","protected":false},"excerpt":{"rendered":"<p>Vista arquitect\u00f3nica pr\u00e1ctica del Art\u00edculo 28 de DORA: controles de riesgo ICT de terceros a lo largo del ciclo de vida CI\/CD y cloud, desde las perspectivas del auditor y del ingeniero.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[135,132],"tags":[],"post_folder":[],"class_list":["post-2063","post","type-post","status-publish","format-standard","hentry","category-regulatory-frameworks-es","category-ci-cd-governance-es"],"_links":{"self":[{"href":"https:\/\/regulated-devsecops.com\/es\/wp-json\/wp\/v2\/posts\/2063","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/regulated-devsecops.com\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/regulated-devsecops.com\/es\/wp-json\/wp\/v2\/types\/post"}],"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=2063"}],"version-history":[{"count":0,"href":"https:\/\/regulated-devsecops.com\/es\/wp-json\/wp\/v2\/posts\/2063\/revisions"}],"wp:attachment":[{"href":"https:\/\/regulated-devsecops.com\/es\/wp-json\/wp\/v2\/media?parent=2063"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/regulated-devsecops.com\/es\/wp-json\/wp\/v2\/categories?post=2063"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/regulated-devsecops.com\/es\/wp-json\/wp\/v2\/tags?post=2063"},{"taxonomy":"post_folder","embeddable":true,"href":"https:\/\/regulated-devsecops.com\/es\/wp-json\/wp\/v2\/post_folder?post=2063"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}