{"id":711,"date":"2026-01-20T09:40:51","date_gmt":"2026-01-20T08:40:51","guid":{"rendered":"https:\/\/secure-pipelines.com\/ci-cd-security\/ci-cd-threat-modeling-trust-boundaries-attack-paths-2\/"},"modified":"2026-03-25T06:49:18","modified_gmt":"2026-03-25T05:49:18","slug":"ci-cd-threat-modeling-trust-boundaries-attack-paths-2","status":"publish","type":"post","link":"https:\/\/secure-pipelines.com\/es\/threats-attacks\/ci-cd-threat-modeling-trust-boundaries-attack-paths-2\/","title":{"rendered":"CI\/CD Threat Modeling: Identificaci\u00f3n de Trust Boundaries y Attack Paths"},"content":{"rendered":"<p>El threat modeling es una pr\u00e1ctica bien establecida en la seguridad de aplicaciones. Los equipos modelan amenazas de forma rutinaria contra APIs, servicios backend y entornos de producci\u00f3n.<\/p>\n<p>Sin embargo, los pipelines de CI\/CD a menudo se excluyen de los ejercicios formales de threat modeling, a pesar de ser uno de los componentes m\u00e1s cr\u00edticos de los sistemas de software modernos.<\/p>\n<p>Esta es una brecha peligrosa.<\/p>\n<p>Los pipelines de CI\/CD se encuentran en la intersecci\u00f3n de entradas no confiables, privilegios elevados y salidas confiables. Son precisamente el tipo de sistema donde el threat modeling proporciona el mayor valor, y sin embargo, con frecuencia se tratan como \u00absimple automatizaci\u00f3n\u00bb.<\/p>\n<p>Este art\u00edculo explica c\u00f3mo realizar threat modeling de pipelines de CI\/CD de manera efectiva, con un enfoque en la identificaci\u00f3n de trust boundaries, la comprensi\u00f3n de attack paths y la priorizaci\u00f3n de controles que realmente reducen el riesgo.<\/p>\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n<h2 class=\"wp-block-heading\">Por qu\u00e9 el threat modeling de pipelines de CI\/CD es diferente<\/h2>\n<p>Los enfoques tradicionales de threat modeling a menudo asumen un l\u00edmite de sistema relativamente estable: una aplicaci\u00f3n ejecut\u00e1ndose en producci\u00f3n, con usuarios, flujos de datos y activos definidos.<\/p>\n<p>Los pipelines de CI\/CD rompen muchas de estas suposiciones.<\/p>\n<p>Un pipeline no es un sistema \u00fanico. Es una cadena din\u00e1mica de sistemas que:<\/p>\n<ul class=\"wp-block-list\">\n<li>Consume entradas de m\u00faltiples fuentes<\/li>\n<li>Ejecuta c\u00f3digo no confiable<\/li>\n<li>Opera con privilegios elevados<\/li>\n<li>Produce artefactos en los que los sistemas posteriores conf\u00edan impl\u00edcitamente<\/li>\n<\/ul>\n<p>En otras palabras, los pipelines no son solo parte del proceso de entrega \u2014 son un mecanismo de transformaci\u00f3n de confianza.<\/p>\n<p>El threat modeling de pipelines de CI\/CD, por lo tanto, requiere un cambio de mentalidad:<\/p>\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\">\n<p>El objetivo no es solo prevenir compromisos, sino comprender d\u00f3nde se crea, amplifica o viola la confianza.<\/p>\n<\/blockquote>\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n<h2 class=\"wp-block-heading\">Lo que realmente estamos protegiendo<\/h2>\n<p>Antes de identificar amenazas, es esencial clarificar qu\u00e9 activos es responsable de proteger un pipeline de CI\/CD.<\/p>\n<p>Los activos comunes del pipeline incluyen:<\/p>\n<ul class=\"wp-block-list\">\n<li><strong>Integridad del c\u00f3digo fuente<\/strong> \u2014 asegurar que el c\u00f3digo no sea modificado inesperadamente<\/li>\n<li><strong>Integridad del build<\/strong> \u2014 asegurar que los builds se ejecuten seg\u00fan lo previsto<\/li>\n<li><strong>Integridad de los artefactos<\/strong> \u2014 asegurar que las salidas coincidan con las entradas<\/li>\n<li><strong>Secrets y credenciales<\/strong> \u2014 tokens, claves e identidades utilizadas por la automatizaci\u00f3n<\/li>\n<li><strong>Autenticidad de los releases<\/strong> \u2014 asegurar que los releases sean leg\u00edtimos y atribuibles<\/li>\n<\/ul>\n<p>Un ataque exitoso a un pipeline no siempre implica robar datos o colapsar sistemas. A menudo, el objetivo del atacante es mucho m\u00e1s sutil:<\/p>\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\">\n<p>Introducir comportamiento malicioso preservando la apariencia de legitimidad.<\/p>\n<\/blockquote>\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n<h2 class=\"wp-block-heading\">Comprender los trust boundaries en CI\/CD<\/h2>\n<p>Un trust boundary existe cuando datos o control cruzan de un contexto menos confiable a uno m\u00e1s confiable.<\/p>\n<p>En los pipelines de CI\/CD, los trust boundaries est\u00e1n en todas partes, pero rara vez son expl\u00edcitos.<\/p>\n<p>El threat modeling comienza identificando estos l\u00edmites y haciendo una pregunta simple:<\/p>\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\">\n<p>\u00bfQu\u00e9 suposiciones estamos haciendo sobre la confianza en este punto?<\/p>\n<\/blockquote>\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n<h3 class=\"wp-block-heading\">1. Entradas de c\u00f3digo fuente<\/h3>\n<p>Los pipelines consumen c\u00f3digo fuente de repositorios, ramas, tags y pull requests. No todas estas entradas tienen el mismo nivel de confianza.<\/p>\n<ul class=\"wp-block-list\">\n<li>Las ramas principales pueden estar restringidas y revisadas<\/li>\n<li>Las ramas de features pueden estar controladas de forma laxa<\/li>\n<li>Los pull requests pueden incluir contribuciones no confiables<\/li>\n<\/ul>\n<p>Sin embargo, muchos pipelines tratan todas las entradas de c\u00f3digo como igualmente confiables.<\/p>\n<p>Esto crea una superficie de ataque donde c\u00f3digo no confiable puede influir en procesos de build y deployment confiables.<\/p>\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n<h3 class=\"wp-block-heading\">2. Resoluci\u00f3n de dependencias<\/h3>\n<p>Los builds modernos resuelven dependencias din\u00e1micamente desde ecosistemas externos: registros de paquetes, registros de contenedores y repositorios de artefactos.<\/p>\n<p>Cada paso de resoluci\u00f3n de dependencias cruza un trust boundary:<\/p>\n<ul class=\"wp-block-list\">\n<li>Del control interno a la infraestructura externa<\/li>\n<li>De entradas verificadas a c\u00f3digo de terceros<\/li>\n<\/ul>\n<p>El threat modeling debe considerar:<\/p>\n<ul class=\"wp-block-list\">\n<li>Dependency confusion<\/li>\n<li>Typosquatting<\/li>\n<li>Paquetes upstream comprometidos<\/li>\n<\/ul>\n<p>Ignorar las dependencias en el threat modeling deja un attack path importante sin explorar.<\/p>\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n<h3 class=\"wp-block-heading\">3. Runners de CI\/CD y entornos de ejecuci\u00f3n<\/h3>\n<p>Los runners son donde la l\u00f3gica del pipeline realmente se ejecuta. Son uno de los trust boundaries m\u00e1s cr\u00edticos \u2014 y m\u00e1s incomprendidos.<\/p>\n<p>Los runners ejecutan:<\/p>\n<ul class=\"wp-block-list\">\n<li>C\u00f3digo fuente<\/li>\n<li>Scripts de build<\/li>\n<li>Acciones o plugins de terceros<\/li>\n<\/ul>\n<p>Si los runners se tratan como infraestructura confiable, pero ejecutan entradas no confiables, el trust boundary colapsa.<\/p>\n<p>El threat modeling debe considerar expl\u00edcitamente:<\/p>\n<ul class=\"wp-block-list\">\n<li>Aislamiento de runners<\/li>\n<li>Persistencia entre jobs<\/li>\n<li>Acceso a red y sistema de archivos<\/li>\n<li>Acceso a secrets<\/li>\n<\/ul>\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n<h3 class=\"wp-block-heading\">4. Configuraci\u00f3n y orquestaci\u00f3n del pipeline<\/h3>\n<p>Los archivos de configuraci\u00f3n de CI\/CD definen qu\u00e9 se ejecuta, cu\u00e1ndo se ejecuta y con qu\u00e9 permisos.<\/p>\n<p>Son efectivamente <em>planos de control<\/em> para el proceso de entrega.<\/p>\n<p>Cualquier cambio en la configuraci\u00f3n del pipeline puede:<\/p>\n<ul class=\"wp-block-list\">\n<li>Alterar el flujo de ejecuci\u00f3n<\/li>\n<li>Expandir privilegios<\/li>\n<li>Introducir nuevos attack paths<\/li>\n<\/ul>\n<p>El threat modeling debe tratar los cambios de configuraci\u00f3n con el mismo rigor que los cambios de c\u00f3digo de producci\u00f3n.<\/p>\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n<h3 class=\"wp-block-heading\">5. Artefactos y traspaso al deployment<\/h3>\n<p>El trust boundary final es el traspaso del pipeline a producci\u00f3n.<\/p>\n<p>En este punto, los entornos de producci\u00f3n a menudo asumen:<\/p>\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\">\n<p>Si vino del CI\/CD, es seguro.<\/p>\n<\/blockquote>\n<p>Esta suposici\u00f3n es precisamente lo que los atacantes explotan.<\/p>\n<p>Sin verificaci\u00f3n de integridad y comprobaciones de procedencia, producci\u00f3n no puede distinguir artefactos leg\u00edtimos de los envenenados.<\/p>\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n<h2 class=\"wp-block-heading\">Identificaci\u00f3n de attack paths comunes en CI\/CD<\/h2>\n<p>Una vez identificados los trust boundaries, el siguiente paso es mapear attack paths realistas.<\/p>\n<p>El objetivo no es enumerar cada amenaza te\u00f3rica, sino comprender c\u00f3mo los atacantes se mueven a trav\u00e9s del sistema.<\/p>\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n<h3 class=\"wp-block-heading\">Attack path 1: Pull request a exfiltraci\u00f3n de secrets<\/h3>\n<p>Un attack path com\u00fan involucra:<\/p>\n<ol class=\"wp-block-list\">\n<li>Un atacante env\u00eda un pull request<\/li>\n<li>El pipeline ejecuta el c\u00f3digo del PR<\/li>\n<li>Los secrets se exponen al entorno de build<\/li>\n<li>El atacante exfiltra credenciales<\/li>\n<\/ol>\n<p>Este ataque no requiere explotar una vulnerabilidad \u2014 explota una suposici\u00f3n impl\u00edcita de confianza.<\/p>\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n<h3 class=\"wp-block-heading\">Attack path 2: Compromiso de dependencia a envenenamiento de build<\/h3>\n<p>Otro path com\u00fan:<\/p>\n<ol class=\"wp-block-list\">\n<li>Una dependencia se compromete upstream<\/li>\n<li>El pipeline resuelve la dependencia<\/li>\n<li>C\u00f3digo malicioso se ejecuta durante el build<\/li>\n<li>Los artefactos se modifican antes de la publicaci\u00f3n<\/li>\n<\/ol>\n<p>Sin comprobaciones de integridad o procedencia, el artefacto envenenado puede parecer completamente leg\u00edtimo.<\/p>\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n<h3 class=\"wp-block-heading\">Attack path 3: Manipulaci\u00f3n de la configuraci\u00f3n del pipeline<\/h3>\n<p>Los archivos de configuraci\u00f3n del pipeline a menudo reciben menos escrutinio que el c\u00f3digo de la aplicaci\u00f3n.<\/p>\n<p>Un atacante que puede modificar la configuraci\u00f3n puede:<\/p>\n<ul class=\"wp-block-list\">\n<li>A\u00f1adir pasos de ejecuci\u00f3n ocultos<\/li>\n<li>Expandir permisos silenciosamente<\/li>\n<li>Redirigir las salidas de artefactos<\/li>\n<\/ul>\n<p>Este attack path es especialmente peligroso porque puede persistir a trav\u00e9s de m\u00faltiples builds.<\/p>\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n<h3 class=\"wp-block-heading\">Attack path 4: Compromiso de runner y movimiento lateral<\/h3>\n<p>Si los runners son compartidos, persistentes o est\u00e1n mal aislados, un atacante puede:<\/p>\n<ul class=\"wp-block-list\">\n<li>Persistir entre jobs<\/li>\n<li>Robar secrets de otros pipelines<\/li>\n<li>Modificar builds futuros<\/li>\n<\/ul>\n<p>En algunos casos, el compromiso del runner proporciona acceso a redes internas o entornos cloud.<\/p>\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n<h2 class=\"wp-block-heading\">Mapeo visual de trust boundaries<\/h2>\n<p>El threat modeling efectivo se beneficia de representaciones visuales.<\/p>\n<p>Para pipelines de CI\/CD, los diagramas deben enfocarse en:<\/p>\n<ul class=\"wp-block-list\">\n<li>D\u00f3nde entran las entradas no confiables<\/li>\n<li>D\u00f3nde aumentan los privilegios<\/li>\n<li>D\u00f3nde se producen y consumen los artefactos<\/li>\n<\/ul>\n<p>Cada flecha en el diagrama representa una transici\u00f3n de confianza. Cada transici\u00f3n es candidata para la aplicaci\u00f3n de controles.<\/p>\n<p>La pregunta clave en cada l\u00edmite es:<\/p>\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\">\n<p>\u00bfQu\u00e9 garant\u00edas tenemos en este punto y c\u00f3mo se aplican?<\/p>\n<\/blockquote>\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n<h2 class=\"wp-block-heading\">Priorizaci\u00f3n de controles basada en threat modeling<\/h2>\n<p>El threat modeling solo es valioso si informa la acci\u00f3n.<\/p>\n<p>Para pipelines de CI\/CD, los controles de mayor impacto generalmente incluyen:<\/p>\n<h3 class=\"wp-block-heading\">1. Reducir la confianza impl\u00edcita<\/h3>\n<p>Distinguir expl\u00edcitamente entre entradas confiables y no confiables. No exponer secrets o acciones privilegiadas a contextos no confiables.<\/p>\n<h3 class=\"wp-block-heading\">2. Aplicar el principio de m\u00ednimo privilegio<\/h3>\n<p>Las identidades del pipeline deben estar limitadas por job, por stage y por entorno. Evitar tokens de larga duraci\u00f3n y amplio alcance.<\/p>\n<h3 class=\"wp-block-heading\">3. Aislar los entornos de ejecuci\u00f3n<\/h3>\n<p>Los runners deben ser ef\u00edmeros o estar fuertemente aislados. Las cargas de trabajo no confiables nunca deben compartir contexto de ejecuci\u00f3n con las confiables.<\/p>\n<h3 class=\"wp-block-heading\">4. Verificar la integridad de los artefactos<\/h3>\n<p>Los artefactos deben estar firmados, atestados y verificados antes del deployment. Producci\u00f3n debe confiar en la verificaci\u00f3n \u2014 no en suposiciones.<\/p>\n<h3 class=\"wp-block-heading\">5. Tratar la configuraci\u00f3n del pipeline como c\u00f3digo de alto riesgo<\/h3>\n<p>Aplicar revisiones, pol\u00edticas y validaci\u00f3n a los cambios de configuraci\u00f3n de CI\/CD. Prevenir la expansi\u00f3n silenciosa de ejecuci\u00f3n o privilegios.<\/p>\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n<h2 class=\"wp-block-heading\">Errores comunes en el threat modeling de CI\/CD<\/h2>\n<p>Incluso cuando las organizaciones intentan realizar threat modeling de pipelines, a menudo caen en trampas predecibles.<\/p>\n<ul class=\"wp-block-list\">\n<li>Enfocarse solo en herramientas, no en relaciones de confianza<\/li>\n<li>Asumir que \u00abinterno\u00bb significa \u00abconfiable\u00bb<\/li>\n<li>Ignorar componentes de terceros<\/li>\n<li>Modelar arquitecturas idealizadas en lugar de pipelines reales<\/li>\n<\/ul>\n<p>El threat modeling efectivo debe reflejar c\u00f3mo operan realmente los pipelines, no c\u00f3mo deseamos que operen.<\/p>\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n<h2 class=\"wp-block-heading\">Conclusi\u00f3n<\/h2>\n<p>Los pipelines de CI\/CD no son sistemas perif\u00e9ricos. Son centrales para la integridad, seguridad y confianza del software.<\/p>\n<p>El threat modeling de pipelines revela attack paths que los modelos de amenazas de aplicaciones tradicionales no detectan, porque el objetivo del atacante no es explotar el comportamiento en tiempo de ejecuci\u00f3n, sino controlar lo que se entrega en primer lugar.<\/p>\n<p>Al identificar trust boundaries, mapear attack paths realistas y priorizar controles aplicables, las organizaciones pueden reducir significativamente el riesgo de ataques a la cadena de suministro de software.<\/p>\n<p>El cambio m\u00e1s importante es conceptual:<\/p>\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\">\n<p>Si no modelas expl\u00edcitamente la confianza en tu pipeline, est\u00e1s confiando en suposiciones \u2014 y los atacantes explotan las suposiciones.<\/p>\n<\/blockquote>\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n<div class=\"secure-pipelines-author-box\" >\n        <strong>Sobre el autor<\/strong><\/p>\n<p>Este art\u00edculo est\u00e1 escrito por un arquitecto senior de DevSecOps y seguridad con m\u00e1s de 15 a\u00f1os de experiencia en ingenier\u00eda de software y seguridad de aplicaciones. El contenido refleja un enfoque pragm\u00e1tico e impulsado por la ingenier\u00eda, basado en restricciones del mundo real.<\/p>\n<\/p><\/div>\n<p><script type=\"application\/ld+json\">\n{\n  \"@context\": \"https:\/\/schema.org\",\n  \"@type\": \"FAQPage\",\n  \"mainEntity\": [\n    {\n      \"@type\": \"Question\",\n      \"name\": \"\u00bfQu\u00e9 es el CI\/CD threat modeling?\",\n      \"acceptedAnswer\": {\n        \"@type\": \"Answer\",\n        \"text\": \"El CI\/CD threat modeling es el proceso de identificar trust boundaries, attack paths y riesgos de seguridad dentro de los pipelines de integraci\u00f3n y entrega continua para prevenir compromisos en la cadena de suministro de software.\"\n      }\n    },\n    {\n      \"@type\": \"Question\",\n      \"name\": \"\u00bfPor qu\u00e9 son importantes los trust boundaries en los pipelines de CI\/CD?\",\n      \"acceptedAnswer\": {\n        \"@type\": \"Answer\",\n        \"text\": \"Los trust boundaries definen d\u00f3nde las entradas no confiables se convierten en salidas confiables. En los pipelines de CI\/CD, no modelar estos l\u00edmites permite a los atacantes explotar la confianza impl\u00edcita e inyectar c\u00f3digo malicioso.\"\n      }\n    },\n    {\n      \"@type\": \"Question\",\n      \"name\": \"\u00bfCu\u00e1les son los attack paths comunes en los pipelines de CI\/CD?\",\n      \"acceptedAnswer\": {\n        \"@type\": \"Answer\",\n        \"text\": \"Los attack paths comunes en CI\/CD incluyen abuso de pull requests, compromiso de dependencias, manipulaci\u00f3n de la configuraci\u00f3n del pipeline, compromiso de runners y envenenamiento de artefactos.\"\n      }\n    },\n    {\n      \"@type\": \"Question\",\n      \"name\": \"\u00bfEn qu\u00e9 se diferencia el CI\/CD threat modeling del threat modeling de aplicaciones?\",\n      \"acceptedAnswer\": {\n        \"@type\": \"Answer\",\n        \"text\": \"El threat modeling de aplicaciones se enfoca en el comportamiento en tiempo de ejecuci\u00f3n, mientras que el CI\/CD threat modeling se enfoca en c\u00f3mo se establece, amplifica y transfiere la confianza antes de que el software llegue a producci\u00f3n.\"\n      }\n    }\n  ]\n}\n<\/script><\/p>\n","protected":false},"excerpt":{"rendered":"<p>El threat modeling es una pr\u00e1ctica bien establecida en la seguridad de aplicaciones. Los equipos modelan amenazas de forma rutinaria contra APIs, servicios backend y entornos de producci\u00f3n. Sin embargo, los pipelines de CI\/CD a menudo se excluyen de los ejercicios formales de threat modeling, a pesar de ser uno de los componentes m\u00e1s cr\u00edticos &#8230; <a title=\"CI\/CD Threat Modeling: Identificaci\u00f3n de Trust Boundaries y Attack Paths\" class=\"read-more\" href=\"https:\/\/secure-pipelines.com\/es\/threats-attacks\/ci-cd-threat-modeling-trust-boundaries-attack-paths-2\/\" aria-label=\"Leer m\u00e1s sobre CI\/CD Threat Modeling: Identificaci\u00f3n de Trust Boundaries y Attack Paths\">Leer m\u00e1s<\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[60,55],"tags":[],"post_folder":[],"class_list":["post-711","post","type-post","status-publish","format-standard","hentry","category-threats-attacks","category-ci-cd-security"],"_links":{"self":[{"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/posts\/711","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/comments?post=711"}],"version-history":[{"count":0,"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/posts\/711\/revisions"}],"wp:attachment":[{"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/media?parent=711"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/categories?post=711"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/tags?post=711"},{"taxonomy":"post_folder","embeddable":true,"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/post_folder?post=711"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}