Técnicas

A medida que el desarrollo de aplicaciones se vuelve cada vez más complejo y dinámico, es un desafío entregar productos usables y accesibles con un estilo consistente. Esto es particularmente más tangible en organizaciones más grandes con múltiples equipos trabajando en diferentes productos. Los sistemas de diseño definen una colección de patrones de diseños, librerías de componentes, buenas prácticas de diseño e ingeniería que aseguran productos digitales consistentes. Evolucionados a partir de los estilos de guías corporativas del pasado, los sistemas de diseños ofrecen librerías compartidas y documentos que son fáciles de encontrar y usar. Generalmente, la guía es escrita como código y se mantiene bajo control de versiones para que la guía sea menos ambigua y más fácil de mantener que simples documentos. Los sistemas de diseño se han convertido en un enfoque estándar cuando se trabaja con equipos y disciplinas en el desarrollo de productos porque permite que los equipos se concentren. Pueden abordar desafíos estratégicos relacionados al producto en sí sin tener que reinventar la rueda cada vez que necesita un nuevo componente visual.

Nuestras experiencias demuestran que los equipos rara vez aplican esta mentalidad centrada en el producto cuando desarrollan sistemas de diseño. Los principales consumidores de estas librerías y documentos compartidos son los equipos de desarrollo de productos. Cuando se aplica la mentalidad de producto, los dueños del sistema deben establecer empatía con los consumidores internos (los equipos de desarrollo) y colaborar con ellos. Encontramos que la razón por la que muchas librerías de componentes son difamadas es porque el equipo propietario no pudo brindarles a los consumidores lo que ellos necesitaban lo suficientemente rápido y no estaba preparado para aceptar contribuciones externas. Una mentalidad centrada en el producto también requiere que las organizaciones piensen en si y como las contribuciones deben ser realizadas al diseño de sistemas y cómo deben regirse estas contribuciones — sobre este tema, recomendamos aplicar la tecnica de registros de decision de los sistemas de diseño. Para nosotros, ejecutar un buen sistema de diseño o una librería de componentes requiere tanto trabajo social como trabajo técnico.

Un RFC (del inglés Request for Comments) es un documento formal que incluye diseños atados a contexto e ideas de arquitectura que facilitan la colaboración de un equipo y la toma de decisiones. Casi todas las organizaciones nativamente digitales y en expansión, utilizan RFCs para tomar decisiones sobre diseño, arquitectura, técnicas y las maneras en las que colaboran sus equipos. Organizaciones maduras han utilizado RFCs en equipos autónomos para mejorar la comunicación y colaboración, especialmente en la toma de decisiones entre equipos. Son usualmente utilizados como un proceso para examinar y ratificar los registros de decisiones de arquitectura. El resultado es un proceso transparente y colaborativo que permite dar a las personas impactadas por una decisión, la oportunidad de involucrarse y colaborar antes de que esta decisión sea ratificada. En entornos altamente dinámicos, es muy común que el razonamiento que lleva a tomar decisiones de diseño se pierde y los equipos que son responsables por implementar dicha decisión se queden con muchas interrogantes. Un RFC proporciona un registro de auditoría de decisiones que beneficia a los futuros miembros del equipo y recopila la evolución técnica y empresarial de una organización. Un RFC puede ser una herramienta valiosa para facilitar la arquitectura evolutiva. No obstante, para un mejor resultado, recomendamos tomar un enfoque ligero a los RFCs. Si no son enfocados y al grano, estos documentos tienden a crecer en extensión con el tiempo y comienzan a parecerse a documentos tradicionales de soluciones arquitecturales que son archivados y olvidados.

Los requisitos de accesibilidad se deberían tener en cuenta durante las pruebas de componentes web. Si bien plugins de frameworks de testing como chai-a11y-axe ermiten comprobar una API para revisar que funcionan, el diseño de pruebas de componentes que tienen en cuenta la accesibilidad puede ayudar aún más ofreciendo todos los elementos semánticos que los lectores de pantalla y otras tecnologías de accesibilidad requieren. Primero, en lugar de usar test-ids o clases para encontrar y seleccionar elementos que se quieren validar, se usa el principio de identificar elementos usando roles ARIA u otros atributos semánticos que usan las tecnologías de accesibilidad. Algunas librerías de pruebas como Testing Library, incluso lo recomiendan en su documentación. Segundo, no hay que limitarse solo a probar interacciones de click; sino también considerar a las personas que no pueden usar el ratón o ver la pantalla, así como añadir pruebas adicionales para el teclado y otras interacciones. La técnica descrita está muy establecida entre nuestros equipos y deberíamos de haberla puesto en el área de Trial hace tiempo.

El análisis de rutas de ataque es una técnica de análisis de seguridad que identifica y evalúa las potenciales rutas que un atacante podría tomar para aprovechar las vulnerabilidades en los sistemas y redes de una organización. Anteriormente, la mayoría de las estrategias de análisis de seguridad o herramientas relacionadas se centraban en áreas de riesgo concretas, como configuraciones erróneas, contenedores con vulnerabilidades o alertas CVE. Este enfoque aislado conlleva a que los equipos no puedan ver cómo se pueden combinar los riesgos con las debilidades existentes en otras capas del stack de tecnología para crear rutas de ataque peligrosas. Aunque esta técnica no es novedosa, los avances recientes en las herramientas de análisis de seguridad la han hecho más accesible para los equipos de seguridad.Orca y Wiz son dos de esas herramientas. Sugerimos que los equipos que administran infraestructuras complejas consideren el uso de esta técnica al planificar una estrategia de seguridad o al seleccionar las herramientas de análisis de seguridad para su organización.

La complejidad en la cadena de suministro de software representa un riesgo significativo, y lo hemos cubierto de forma amplia, por ejemplo, en nuestros escritos en SBOM y SLSA. El talón de Aquiles para la mayoría de los equipos, sigue siendo la presencia de vulnerabilidades en las dependencias, usualmente dependencias indirectas que existen en varios niveles inferiores. Herramientas como Dependabot ayudan mediante la creación de pull requests (PRs) para actualizar dependencias. La pronta gestión de los PRs, especialmente cuando se trata de aplicaciones o servicios que no están en un proceso activo de desarrollo, demanda un alto nivel de disciplina en el ámbito de ingeniería.

Bajo las circunstancias adecuadas, ahora recomendamos la incorporación automática de PRs con actualización de dependencias. Para esto, el sistema necesita tener una cobertura de pruebas exhaustivas – no solo pruebas unitarias, sino que también pruebas funcionales y de performance. La etapa de construcción del pipeline debe ejecutar todos estos test, incluyendo escaneo de seguridad. En pocas palabras, el equipo debe tener total confianza que cuando el pipeline se ejecuta correctamente, entonces el software está listo para llegar a producción. En estos casos, la actualización de los PRs con dependencias, deberían poder ser incorporados automáticamente, aún cuando incluyan actualizaciones mayores de versión en dependencias indirectas.

El Product Thinking de Datos prioriza el tratar los consumidores de datos como clientes, de esta manera asegura que tengan una experiencia fluida a lo largo de la cadena de valor. Esto comprende la facilidad en el descubrimiento, entendimiento, confianza, acceso y consumo de la información. El “Product Thinking” no es un concepto nuevo. En el pasado lo hemos integrado en el mundo operacional mientras construimos productos operacionales o microservicios. Esto también sugiere una nueva manera de formar equipos de larga duración y multifuncionales que puedan poseer y compartir información a lo largo de la organización. Para tener una mentalidad de producto a Datos, creemos que las organizaciones pueden poner en funcionamiento los principios FAIR (findable, accessible, interoperable and reusable). Nuestros equipos utilizan catálogos de datos como Collibra y DataHub para habilitar el descubrimiento de datos. Para garantizar la confianza publicamos métricas de calidad de datos y SLI como su vigencia, integridad y consistencia para cada producto de datos, y herramientas como Soda Core y Great Expectations automatizan los controles de calidad. La Observabilidad de Datos, se puede alcanzar mediante la ayuda de plataformas como Monte Carlo.

Hemos visto productos de datos convertirse en la base de múltiples casos de uso durante un tiempo. Esto viene acompañado de un tiempo de lanzamiento más rápido para posteriores casos de uso, a la vez que progresamos en la identificación e implementación de productos de datos enfocados a la entrega de valor. Es por esto que nuestro consejo es adoptar el product thinking de datos para datos FAIR.

Una de las técnicas que recomendamos para implementar seguridad de confianza cero para CI/CD es autenticar tus pipelines de entrega contínua para el acceso a servicios en la nube via mecanismos federados de identificación como OpenID Connect (OIDC). Dado que GitHub Actions es ampliamente utilizado — y que esta importante técnica permanece poco utilizada — queremos llamar la atención sobre OIDC para GitHub Actions. De esta manera puedes evitar almacenar tokens de acceso de larga duración para tus recursos en la nube, y tus pipelines de entrega contínua no tendrán acceso directo a secretos. No obstante, asegúrate de limitar el acceso cuidadosamente de modo que las acciones se ejecuten realmente con el menor privilegio.

Infraestructura como código (IaC) es ahora un enfoque ampliamente aceptado para definir y provisionar entornos de alojamiento. Incluso con la continua evolución de herramientas y técnicas en esta área, Terraform sigue siendo la herramienta dominante para hacer IaC en recursos nativos de la nube. Sin embargo, la mayoría de los entornos de alojamiento actuales son combinaciones complejas de servicios nativos del proveedor de la nube, servicios de terceros y código personalizado. En estos entornos, hemos descubierto que los ingenieros a menudo recurren a una mezcla de Terraform para los recursos en la nube y scripts personalizados para el resto. Esto puede conducir a una falta de coherencia y repetibilidad en el proceso de aprovisionamiento. De hecho, muchos de los servicios de terceros que se utilizan comúnmente en entornos de alojamiento — incluyendo Splunk, Datadog, PagerDuty y New Relic — tienen proveedores Terraform que se pueden utilizar para aprovisionar y configurar estos servicios. Por eso recomendamos que, además de los recursos en la nube, los equipos también suministren monitores y alertas con Terraform. Esto conduce a IaC con una mejor modularidad que es más fácil de entender y mantener. Como ocurre con todos los IaC, existe el riesgo de introducir inconsistencias cuando la configuración se modifica a través de otras interfaces. Para asegurar que el código de Terraform sigue siendo la fuente de la verdad, recomendamos que se deshabiliten los cambios de configuración a través de interfaces de usuario y APIs.

ReAct prompting es un método de prompting para LLMs destinado a mejorar la precisión de sus respuestas sobre otros métodos como chain-of-thought (CoT). Publicado en un paper del 2022, funciona unificando razonamiento y acción (de ahí ReAct). Este enfoque ayuda a que las respuestas de los LLMs sean más entendibles y reducir las alucinaciones en comparación con CoT, dándole a los prompters una mejor oportunidad de conseguir lo que quieren.LangChain se desarrolló originalmente para soportar este estilo de prompting. Los agentes autónomos basados en ReAct prompting han demostrado ser algunas de las aplicaciones más ampliamente utilizadas de LLMs que nuestros equipos han estado construyendo. Recientemente, OpenAI ha introducido function calling en sus APIs para facilitar la implementación de ReAct y otros estilos de prompting similares sin tener que recurrir a herramientas externas como LangChain. Aún estamos en las primeras fases de definición de esta disciplina, pero hasta ahora, ReAct y sus descendientes han señalado el camino hacia algunas de las aplicaciones más interesantes de los LLMs.

Retrieval-Augmented Generation (RAG) es una técnica que combina memoria paramétrica y no-paramétrica, previamente entrenadas, para la generación de lenguaje. Nos permite tomar el conocimiento que poseen los LLMs pre-entrenados y aumentarlo con el conocimiento privado y contextual de nuestro dominio o industria. Con RAG, primero obtenemos un conjunto de documentos relevantes a partir de la memoria no-paramétrica (usualmente a través de una búsqueda similar en un almacenamiento de datos vectorial) para después usar la memoria paramétrica de los LLMs y generar una salida que es consistente con los documentos obtenidos inicialmente. Concluimos que RAG es una técnica efectiva para una variedad de tareas que requieren un intenso conocimiento sobre procesamiento de lenguaje natural – incluyendo responder preguntas, resumir y generar historias.

El modelamiento de fallos basado en el riesgo es un proceso utilizado para entender el impacto, probabilidad y la habilidad de detectar las diferentes maneras en que un sistema puede fallar. Los equipos de entrega están empezando a utilizar esta metodología para diseñar y evaluar los controles necesarios para evitar dichos fallos. El enfoque se basa en la práctica de Análisis Modal de Fallos y Efectos (AMFE), una técnica de puntuación de riesgo que existe desde los años 40 y con un historial de éxito en industrias que construyen sistemas físicos complejos como la aeroespacial y la automovilística. Como en estas industrias, las fallas de software también puede tener graves consecuencias — comprometiendo, por ejemplo, la salud y la privacidad — razón por lo que se ve un incremento en la necesidad de que los sistemas sean sometidos a rigurosos análisis. El proceso inicia identificando los posibles modos de fallo. Luego el equipo realiza un análisis a la causa principal y asigna puntaje a la probabilidad de que la falla ocurra, la magnitud del impacto y la probabilidad de detectar la causa del fallo. Hemos comprobado que esto es más eficaz cuando los equipos interfuncionales repiten este proceso a medida que el sistema evoluciona. Hablando de seguridad, el modelamiento de fallos basado en el riesgo puede ser un gran complemento para modelado de amenazas y del análisis de rutas de ataque.

Hemos tenido éxito en varias aplicaciones que hacen uso de lenguaje natural semi-estructurado para LLMs. Las entradas de datos estructuradas, como documentos JSON, son claras y precisas, y le dan al modelo una indicación del tipo de respuestas que se buscan. Limitar la respuesta de esta forma ayuda a estrechar el problema y puede producir resultados más certeros, particularmente cuando la estructura se ajusta a lenguaje específico de dominio (DSL) cuya sintaxis o esquema se proporciona al modelo. También hemos visto que acompañando la entrada estructurada de datos con comentarios en lenguaje natural o anotaciones produce una mejor respuesta que procesándolos de forma separada. Normalmente, el lenguaje natural simplemente se intercala con contenido estructurado al construir la instrucción. Al igual que con otros comportamientos de LLMs, no sabemos exactamente por qué funciona, pero la experiencia nos ha demostrado que añadir comentarios de lenguaje natural en código escrito por humanos también mejora la calidad de la salida de datos para los asistentes de código basados en LLMs.

Seguimos observando las mejoras de los equipos en sus ecosistemas al tratar el índice de salud de la misma forma que los otros objetivos de nivel de servicio (SLOs) y priorizando mejoras en consecuencia, en vez de solamente enfocarse en hacer seguimiento de la deuda técnica. Al asignar recursos eficientemente para abordar los problemas con mayor impacto en la salud, equipos y organizaciones pueden reducir costos de mantenimiento a largo plazo y evolucionar productos de manera más eficiente. Este enfoque también mejora la comunicación entre stakeholders tanto técnicos como no técnicos, fomentando un entendimiento común del estado del sistema. A pesar de que las métricas pueden variar entre organizaciones (Ver este artículo para ejemplos) al final contribuyen a una sostenibilidad a largo plazo y se aseguran de que el software se mantenga adaptable y competitivo. En un panorama digital que cambia rápidamente, enfocarse en el seguimiento de la salud sobre la deuda técnica de los sistemas proporciona una estrategia estructurada y basada en evidencias para mantenerlos y mejorarlos.

La observabilidad y monitorización son esenciales para los equipos de desarrollo de software. Dada la naturaleza impredecible de ciertos eventos, es crucial crear mecanismos de alerta precisos con reglas complejas. Sin embargo, la validación de estas reglas sólo se produce cuando estos escenarios suceden. La técnica de tests unitarios para reglas de alerta permite a los equipos mejorar la definición de reglas mediante el testeo proactivo y redefinirlas incrementando la confianza en la forma en que las reglas se crean. Esto ayuda a reducir falsas alarmas y asegura que los verdaderos incidentes son identificados. Herramientas como Prometheus dan soporte a los tests unitarios para reglas; nuestros equipos ya estan reportando sus beneficios en entornos del mundo real.

Si no está debidamente asegurada, la infraestructura y las herramientas que ejecutan nuestros pipelines de build y despliegue, pueden convertirse en una gran riesgo. Las pipelines requieren acceso a datos críticos y sistemas como el código fuente, credenciales y secretos para compilar y desplegar software. Esto hace que estos sistemas sean muy atractivos para actores maliciosos. Por lo tanto, recomendamos aplicar seguridad de confianza cero para pipelines CI/CD e infraestructura — confiando en ellas tan poco como sea posible. Esto abarca una serie de técnicas: Si está disponible, autentifica tus pipelines con tu proveedor en la nube a través de mecanismos de identidad federada como OIDC, en lugar de darles acceso directo a los secretos; implementa el principio de mínimo privilegio minimizando el acceso de cuentas individuales de usuario o runners, en lugar de emplear “cuentas de usuario god” con acceso ilimitado; utiliza tus ejecutores de forma efímera en lugar de reutilizarlos, para reducir el riesgo de exponer secretos de trabajos anteriores o ejecutar trabajos en ejecutores comprometidos; mantén el software de tus agentes y ejecutores actualizado; y monitoriza la integridad, confidencialidad y disponibilidad de tus sistemas CI/CD de la misma forma que monitorizarías tu software de producción.

Hemos visto que los equipos se olvidan de este tipo de prácticas, particularmente cuando están acostumbrados a trabajar con infraestructura de CI/CD auto-gestionada en redes internas. Si bien todas estas prácticas son importantes en tus redes internas, estas se vuelven incluso más cruciales cuando se usa un servicio gestionado, ya que amplía el área de ataque y el radio de impacto aún más.

Asegurar la cadena de distribución de software se ha convertido en una preocupación común entre los equipos de delivery, esto se refleja en el crecimiento del número de herramientas y técnicas en este ámbito, varias de las cuales, ya hemos cubierto anteriormente en el Radar. La creciente popularidad del uso de herramientas basadas en GenAI para ayudar en el proceso de desarrollo de software, ha introducido un nuevo vector de ataque a la cadena de distribución del software: package hallucinations. Creemos que es importante que los equipos que utilizan este tipo de herramientas, como GenAI, en su proceso de desarrollo, se mantengan alertas contra estos riesgos. Para lograr esto, los equipos pueden realizar Health checks de dependencias para contrarrestar los package hallucinations : mirar las fechas en las que fueron creadas, número de descargas, comentarios y calificaciones, el número de personas contribuidoras, el historial de la actividad, etc, antes de elegir adoptarlos. Algunas de estas revisiones pueden ser ejecutadas en los repositorios de dependencias y en GitHub, herramientas como deps.dev y Snyk advisor, también pueden proporcionar información adicional. A pesar de que esto no es una técnica nueva, está adquiriendo una relevancia cada vez mayor a medida que los equipos experimentan cada vez más con herramientas GenAI en el ciclo de desarrollo de software

En un entorno acelerado de desarrollo de productos en donde las necesidades del usuario evolucionan constantemente, el diseño es un área en constante cambio. Esto significa que seguiremos requiriendo aportaciones para las decisiones de diseño. Tomando la idea de documentar decisiones de arquitectura mediante ADRs, comenzamos a adoptar un formato similar — el registro de decisiones del sistema de diseño — para documentar estas decisiones junto a su correspondiente razonamiento, resultados de la investigación y resultados de los experimentos. Comunicar las decisiones del sistema de diseño parecería ser una necesidad emergente en los equipos de producto. Hacerlo de esta sencilla manera también lo recomienda zeroheight. Esta técnica nos ha ayudado a reducir la curva inicial de aprendizaje en los equipos, así como avanzar en conversaciones y alinear el trabajo de equipos que comparten el mismo sistema de diseño.

GitOps Es una técnica para el despliegue de aplicaciones a través del patrón control loop. Un operador mantiene sincronizado el despliegue de la aplicación con la configuración, generalmente un repositorio de Git. La última vez que escribimos acerca de GitOps quedaba pendiente la definición del término, o nombre, por parte de la comunidad. En ese momento nos preocupaban las interpretaciones comunes de la técnica que se incluían acercamientos tipo “rama por ambiente” para la configuración, que podrían causar snowflakes as code. Además, las conversaciones en respecto a GitOps como alternativa a la entrega continua eran confusas. Desde entonces, los cuatro principios de GitOps han aclarado el alcance y la naturaleza de la técnica. Cuando se va más allá del alboroto y confusión, GitOps es una técnica útil que aprovecha la funcionalidad de un cúmulo, o clúster, de Kubernetes y crea oportunidades para separar las preocupaciones entre configurar una aplicación y la implementación del proceso de despliegue. Algunos de nuestros equipos han implementado GitOps como parte de su proceso de entrega continua con experiencias positivas, y es por esto que recomendamos su evaluación.

A medida que continúa el desarrollo de grandes modelos de lenguaje, existe un gran interés en crear agentes de IA autónomos. AutoGPT, GPT-Engineer y BabyAGI son ejemplos de agentes autónomos impulsados por LLM que desarrollan un LLM subyacente para comprender el objetivo que se les ha asignado y trabajar para lograrlo. El agente recuerda hasta dónde ha progresado, utiliza el LLM para razonar sobre qué hacer a continuación, toma acciones y comprende cuándo se ha cumplido el objetivo. Esto a menudo se conoce como razonamiento en cadena de pensamientos y, de hecho, puede funcionar. Uno de nuestros equipos implementó un chatbot de atención al cliente como agente autónomo. Si el chatbot no puede lograr el objetivo del cliente, reconoce su propia limitación y, en su lugar, redirige al cliente hacia un humano. Este enfoque definitivamente se encuentra en una etapa temprana de su ciclo de desarrollo: los agentes autónomos a menudo sufren una alta tasa de fallas e inciden en costosas tarifas de servicios de IA, y al menos una startup de IA se ha alejado del enfoque basado en agentes.

Con la adopción generalizada de la ingeniería de plataformas, estamos viendo una nueva generación de herramientas que van más allá del modelo tradicional de plataforma como servicio (PaaS) y ofrecen contratos publicados entre desarrolladores y equipos de plataforma. El contrato podría implicar el aprovisionamiento de entornos en la nube, bases de datos, monitoreo, autenticación y más en un entorno diferente. Estas herramientas hacen cumplir los estándares organizacionales al tiempo que otorgan a los desarrolladores acceso de autoservicio a las variaciones a través de la configuración. Ejemplos de estos orquestación de plataformas sistemas incluyen Kratix y Humanitec Platform Orchestrator. Recomendamos que los equipos de plataforma evalúen estas herramientas como alternativa a la creación de su propia colección única de scripts, herramientas nativas e infraestructura como código. También hemos notado una similitud con los conceptos del Modelo de Aplicación Abierta (OAM) y su orquestador de referencia KubeVela, aunque OAM afirma ser más centralizado en la aplicación que en la carga de trabajo.

Los modelos grandes de lenguaje (LLMs, por sus siglas en inglés) generalmente requieren una infraestructura significativa de GPU para funcionar, pero ha habido un fuerte impulso para que funcionen en un hardware más modesto. La cuantización de un modelo grande puede reducir los requisitos de memoria, permitiendo que un modelo de alta fidelidad se ejecute en un hardware menos costoso o incluso en una CPU. Esfuerzos como llama.cpp hacen posible ejecutar LLMs en hardware que incluye Raspberry Pis, ordenadores portátiles y servidores de uso general.

Muchas organizaciones están desplegando LLMs auto-hospedados. Esto se debe a menudo a preocupaciones de seguridad o privacidad, o a veces, a la necesidad de ejecutar modelos en dispositivos periféricos. Ejemplos de código abierto incluyen GPT-J, GPT-JT y Llama. Este enfoque ofrece un mejor control del modelo al ajustarlo finamente para un caso de uso específico, una mayor seguridad y privacidad, así como acceso sin conexión. Aunque hemos ayudado a algunos de nuestros clientes a auto-hospedar LLMs de código abierto para completar código, te recomendamos que evalúes cuidadosamente las capacidades organizativas y el costo de operación de tales LLMs antes de tomar la decisión de auto-hospedarlos.

El Top 10 de OWASP ha sido durante mucho tiempo una referencia de los riesgos de seguridad más críticos para las aplicaciones web. A pesar de ser ampliamente conocido hemos escrito anteriormente sobre su poca utilización en el proceso de desarrollo de software y advertido acerca de ignorar el TOP 10 de OWASP.

Algo que es menos conocido, es que OWASP también publica listas top 10 para otras categorías. La lista Top 10 de OWASP para LLMs, cuya primera versión estable fue liberada a principios de agosto, destaca riesgos como la inyección de comandos, el manejo de salidas inseguras y la contaminación de datos de entrenamiento entre otros, que personas y equipos que construyen este tipo de aplicaciones LLM deberían tener muy en cuenta. OWASP también ha lanzado recientemente la segunda versión de su lista Top 10 de OWASP para APIs. Dada la gran cobertura de información que estas listas dan para aplicaciones web, APIs, LLMs y más, ademas de su calidad y relevancia para el panorama de seguridad en constante cambio, extendemos nuestra recomendación para advertir a los equipos sobre no ignorar las listas Top 10 de OWASP.

Desde que los mencionamos en el 2014, los componentes web se han hecho populares y en general, nuestra experiencia ha sido positiva. Del mismo modo, hemos apoyado el renderizado de HTML en el servidor advirtiendo sobre el uso de SPA por defecto e incluyendo frameworks como Next.js y htmx, además de frameworks tradicionales del lado del servidor. Sin embargo, aunque es posible combinar ambos, también puede resultar muy problemático; por eso sugerimos evitar los componentes web para aplicaciones web renderizadas en servidor. Siendo una tecnología de navegador, no es trivial usar componentes en el servidor. Los frameworks han surgido para facilitar este proceso. A veces incluso usan un motor de navegador, pero la complejidad se mantiene. Peor aún que los problemas en la experiencia del desarrollador, es la experiencia del usuario: El rendimiento de la carga de página se ve impactado cuando los componentes web personalizados tienen que ser cargados e hidratados en el navegador, y aún con el uso de pre-renderización y retoques cuidadosos del componente, unflash de contenido sin estilos o algún movimiento inesperado en el diseño es inevitable. La decisión de privarse de componentes web puede tener consecuencias de gran impacto, como la que experimentó uno de nuestros equipos, cuando tuvieron que cambiar el diseño del sistema, basado en componentes web Stencil.