¡Hola, chicos!

yo participé en Mesa Redonda #231 en el canal Noche de codificación, en un formato que considero sumamente saludable para el área de tecnología: una conversación abierta entre profesionales del desarrollo, de bases de datos e infraestructura, discutiendo problemas reales, decisiones técnicas y los impactos prácticos de estas elecciones en el día a día.

A diferencia de un directo centrado en una sola tecnología, esta edición pretendía precisamente provocar el diálogo entre áreas que, históricamente, muchas veces se comunican poco o sólo cuando algo ya salió mal.

Enlace de transmisión:

 

El papel de cada área en un escenario cada vez más integrado

Uno de los puntos que quedó muy claro a lo largo de la conversación es que la rígida separación entre Dev, DBA e Infra ya no refleja la realidad de los sistemas modernos. Los contenedores, la nube, los oleoductos y la automatización han hecho que los límites entre estas áreas sean cada vez más borrosos.

Hoy en día, las decisiones tomadas en código impactan directamente en la seguridad, el costo, la observabilidad y el rendimiento. Asimismo, las decisiones tomadas en infraestructura o base de datos influyen en el ritmo de desarrollo y la capacidad del producto para evolucionar.

La mesa redonda giró en gran medida en torno a esta interdependencia y la necesidad de una mayor madurez técnica y comunicación entre los equipos.

La seguridad ya no es un tema aislado

Un tema recurrente durante prácticamente todo el concierto fue la seguridad. No como responsabilidad exclusiva de un área, sino como un problema transversal.

Hablamos mucho sobre cómo los fallos de seguridad no sólo surgen de un código mal escrito, sino también de:

  • Uso indiscriminado de bibliotecas de terceros

  • Dependencias obsoletas

  • Imágenes de contenedores no verificadas

  • Configuraciones frágiles en tuberías

  • Uso inapropiado de secretos y credenciales.

Quedó claro que la seguridad no puede considerarse una etapa final del proyecto. Debe estar presente desde la elección de dependencias hasta la forma en que se accede a las aplicaciones y bases de datos en producción.

Dependencia de la cadena de suministro y gestión de riesgos

Una de las partes más densas de la conversación giró en torno a la gestión de la dependencia y los riesgos asociados con la cadena de suministro de software.

Discutimos casos reales de bibliotecas que, aunque populares, comenzaron a presentar vulnerabilidades con el tiempo, así como incidentes que involucran paquetes maliciosos en repositorios públicos como NPM, Docker Hub y otros.

El punto central fue que:

  • La popularidad no garantiza la seguridad

  • El código que no se puede auditar debe tratarse con precaución

  • Las dependencias deben ser monitoreadas continuamente, no solo en el momento de la adopción.

También analizamos herramientas y enfoques para el análisis de dependencia, tanto de código abierto como comercial, y la importancia de integrar estas comprobaciones en el flujo de CI/CD.

Los contenedores no eliminan la responsabilidad

Otro punto importante fue la falsa sensación de seguridad que muchas veces surge con el uso de contenedores. El hecho de que una aplicación se ejecute en Docker o Kubernetes no elimina los problemas de seguridad, solo cambia la superficie de ataque.

Hablamos de:

  • Usar imágenes base confiables

  • Preferencia por imágenes oficiales o verificadas.

  • Riesgos de imágenes genéricas o mantenidas por terceros desconocidos

  • Necesidad de comprender qué se ejecuta dentro del contenedor.

Los contenedores facilitan la estandarización y la automatización, pero no reemplazan la comprensión técnica.

IA, LLM y nuevos vectores de vulnerabilidad

La discusión avanzó hacia uno de los temas de mayor actualidad en el área: el uso de LLM, agentes autónomos e integración de IA en sistemas corporativos.

Un punto que se destacó mucho fue que inyección inmediata y los ataques que involucran LLM representan una evolución significativa de los problemas de inyección clásicos, como la inyección SQL. A diferencia de los ataques tradicionales, este nuevo escenario amplía enormemente la superficie de ataque y dificulta la creación de mecanismos de defensa completamente efectivos.

También discutimos cómo:

  • Los agentes de IA pueden realizar acciones sobre bases de datos y servicios

  • Los fallos de validación pueden provocar un acceso inadecuado

  • La creatividad de quienes intentan explotar las brechas crece más rápido que las defensas.

Quedó claro que el uso de la IA requiere aún más cuidado con la observabilidad, el control de permisos y la validación del contexto.

La observabilidad como elemento esencial

OpenTelemetry surgió varias veces en la conversación, principalmente en el contexto de la observabilidad en aplicaciones modernas.

Hablamos de dificultades prácticas de implementación, bibliotecas que aún evolucionan y la diferencia entre tener herramientas de observabilidad implementadas y usarlas de manera efectiva.

La observabilidad fue tratada como un pilar esencial para:

  • Comprender el comportamiento de las aplicaciones distribuidas

  • Supervisar las interacciones con los servicios de IA

  • Detectar fallos y anomalías

  • Respaldar decisiones técnicas basadas en datos

Sin observabilidad, la mayoría de los problemas discutidos a lo largo del directo se vuelven invisibles hasta que tienen un impacto directo en la producción.

Gestión de secretos y credenciales.

Otro tema recurrente fue la gestión secreta. Analizamos todo, desde prácticas más simples, como variables de entorno, hasta soluciones más sólidas, como servicios dedicados de gestión de secretos en la nube.

La conclusión es que el cifrado no elimina el problema, sólo lo desplaza. Siempre existe la cuestión de dónde y cómo almacenar claves, tokens y credenciales de forma segura.

También cubrimos:

  • Riesgos de los secretos codificados

  • Limitaciones de los ejemplos encontrados en la documentación.

  • Diferencia entre seguridad aparente y seguridad real

Conflictos históricos entre Dev, DBA e Infra

En varios momentos, la conversación volvió a los conflictos clásicos entre áreas, como las decisiones de modelado, el uso de claves primarias, las estrategias de generación de identificadores y el impacto de las viejas elecciones en los sistemas heredados.

Estos puntos surgieron no como críticas aisladas, sino como ejemplos de cómo decisiones técnicas aparentemente simples pueden generar problemas importantes años después.

La mesa redonda sirvió precisamente para mostrar que estos conflictos no deben evitarse, sino discutirse de forma técnica y colaborativa.

Consideraciones finales

La Mesa Redonda #231 fue un excelente ejemplo de cómo las discusiones técnicas ganan profundidad cuando diferentes áreas participan activamente en el debate.

Más que defender herramientas o enfoques específicos, el directo reforzó la importancia de:

  • entender el contexto

  • Evaluar riesgos

  • Comunicar decisiones

  • Piense en el impacto a largo plazo

En un escenario donde los datos, los contenedores, DevOps y la IA están cada vez más integrados, el diálogo entre Devs, DBAs e Infra deja de ser opcional y se vuelve imprescindible.