Fala pessoal!
Participei da Mesa Redonda #231 no canal Coding Night, em um formato que considero extremamente saudável para a área de tecnologia: uma conversa aberta entre profissionais de desenvolvimento, banco de dados e infraestrutura, discutindo problemas reais, decisões técnicas e os impactos práticos dessas escolhas no dia a dia.
Diferentemente de uma live focada em uma única tecnologia, essa edição teve como objetivo justamente provocar o diálogo entre áreas que, historicamente, muitas vezes se comunicam pouco — ou apenas quando algo já deu errado.
Link da transmissão:
O papel de cada área em um cenário cada vez mais integrado
Um dos pontos que ficou muito claro ao longo da conversa é que a separação rígida entre Dev, DBA e Infra já não reflete a realidade dos sistemas modernos. Containers, cloud, pipelines e automação tornaram os limites entre essas áreas cada vez mais tênues.
Hoje, decisões tomadas no código impactam diretamente segurança, custo, observabilidade e performance. Da mesma forma, escolhas feitas em infraestrutura ou banco de dados influenciam o ritmo de desenvolvimento e a capacidade de evolução do produto.
A mesa redonda girou bastante em torno dessa interdependência e da necessidade de maior maturidade técnica e comunicação entre os times.
Segurança deixou de ser um tema isolado
Um tema recorrente durante praticamente toda a live foi segurança. Não como uma responsabilidade exclusiva de uma área, mas como um problema transversal.
Falamos bastante sobre como falhas de segurança não surgem apenas de código mal escrito, mas também de:
-
Uso indiscriminado de bibliotecas de terceiros
-
Dependências desatualizadas
-
Imagens de contêiner não verificadas
-
Configurações frágeis em pipelines
-
Uso inadequado de segredos e credenciais
Ficou claro que segurança não pode ser tratada como uma etapa final do projeto. Ela precisa estar presente desde a escolha das dependências até a forma como aplicações e bancos de dados são acessados em produção.
Gerenciamento de dependências e riscos da supply chain
Um dos trechos mais densos da conversa girou em torno do gerenciamento de dependências e dos riscos associados à cadeia de suprimentos de software.
Discutimos casos reais de bibliotecas que, mesmo populares, passaram a apresentar vulnerabilidades ao longo do tempo, além de incidentes envolvendo pacotes maliciosos em repositórios públicos como NPM, Docker Hub e outros.
O ponto central foi que:
-
Popularidade não garante segurança
-
Código que não pode ser auditado deve ser tratado com cautela
-
Dependências precisam ser monitoradas continuamente, não apenas no momento da adoção
Também comentamos ferramentas e abordagens para análise de dependências, tanto open source quanto comerciais, e a importância de integrar essas verificações ao fluxo de CI/CD.
Containers não eliminam responsabilidade
Outro ponto importante foi a falsa sensação de segurança que muitas vezes surge com o uso de containers. O fato de uma aplicação rodar em Docker ou Kubernetes não elimina problemas de segurança, apenas muda a superfície de ataque.
Falamos sobre:
-
Uso de imagens base confiáveis
-
Preferência por imagens oficiais ou verificadas
-
Riscos de imagens genéricas ou mantidas por terceiros desconhecidos
-
Necessidade de entender o que está sendo executado dentro do container
Containers facilitam padronização e automação, mas não substituem entendimento técnico.
IA, LLMs e novos vetores de vulnerabilidade
A discussão avançou para um dos temas mais atuais da área: o uso de LLMs, agentes autônomos e integração de IA em sistemas corporativos.
Um ponto bastante enfatizado foi que prompt injection e ataques envolvendo LLMs representam uma evolução significativa dos problemas clássicos de injeção, como SQL Injection. Diferentemente dos ataques tradicionais, esse novo cenário amplia muito a superfície de ataque e dificulta a criação de mecanismos de defesa completamente eficazes.
Também discutimos como:
-
Agentes de IA podem executar ações em bancos de dados e serviços
-
Falhas de validação podem levar a acessos indevidos
-
A criatividade de quem tenta explorar brechas cresce mais rápido do que as defesas
Ficou claro que o uso de IA exige ainda mais cuidado com observabilidade, controle de permissões e validação de contexto.
Observabilidade como elemento essencial
OpenTelemetry surgiu diversas vezes na conversa, principalmente no contexto de observabilidade em aplicações modernas.
Falamos sobre dificuldades práticas de implementação, bibliotecas ainda em evolução e a diferença entre ter ferramentas de observabilidade instaladas e realmente utilizá-las de forma eficaz.
A observabilidade foi tratada como um pilar essencial para:
-
Entender comportamento de aplicações distribuídas
-
Monitorar interações com serviços de IA
-
Detectar falhas e anomalias
-
Apoiar decisões técnicas baseadas em dados
Sem observabilidade, boa parte dos problemas discutidos ao longo da live se tornam invisíveis até causarem impacto direto em produção.
Gerenciamento de segredos e credenciais
Outro tema recorrente foi o gerenciamento de segredos. Discutimos desde práticas mais simples, como variáveis de ambiente, até soluções mais robustas como serviços dedicados de secret management em cloud.
O ponto central foi que criptografia não elimina o problema, apenas o desloca. Sempre existe a questão de onde e como armazenar chaves, tokens e credenciais de forma segura.
Também abordamos:
-
Riscos de hardcoded secrets
-
Limitações de exemplos encontrados em documentações
-
Diferença entre segurança aparente e segurança real
Conflitos históricos entre Dev, DBA e Infra
Em vários momentos, a conversa retomou conflitos clássicos entre áreas, como decisões de modelagem, uso de chaves primárias, estratégias de geração de identificadores e impacto de escolhas antigas em sistemas legados.
Esses pontos surgiram não como críticas isoladas, mas como exemplos de como decisões técnicas aparentemente simples podem gerar problemas significativos anos depois.
A mesa redonda serviu justamente para mostrar que esses conflitos não devem ser evitados, mas discutidos de forma técnica e colaborativa.
Considerações finais
A Mesa Redonda #231 foi um excelente exemplo de como discussões técnicas ganham profundidade quando diferentes áreas participam ativamente do debate.
Mais do que defender ferramentas ou abordagens específicas, a live reforçou a importância de:
-
Entender contexto
-
Avaliar riscos
-
Comunicar decisões
-
Pensar em impacto de longo prazo
Em um cenário onde dados, containers, DevOps e IA estão cada vez mais integrados, o diálogo entre Devs, DBAs e Infra deixa de ser opcional e passa a ser essencial.
Portuguese 
English