Cibersegurança e segurança de software

Ver no idioma original →

Cibersegurança e segurança de software abrangem a identificação e correção de vulnerabilidades, a proteção de dados e credenciais e o controle do acesso a sistemas. Os vídeos também destacam como agentes de IA podem apoiar a defesa, mas criar novos riscos quando recebem permissões amplas, executam comandos ou interagem com serviços reais sem controles externos. ↗ ↗ ↗

Vulnerabilidades, correções e manutenção

Falhas em componentes amplamente utilizados podem afetar muitos sistemas. Duas vulnerabilidades no PHP, capazes de permitir execução remota de código, levaram órgãos e empresas a recomendar a instalação dos patches ou, em alguns casos, a retirar serviços do ar enquanto as correções eram aplicadas. Estimativas citadas nos vídeos apontaram mais de 1,3 milhão de servidores potencialmente afetados; não havia confirmação de exploração bem-sucedida naquele momento. ↗

Outros casos ilustram riscos em diferentes partes da infraestrutura. Uma falha antiga no código de rede do Linux podia permitir que uma máquina virtual escapasse do isolamento e obtivesse acesso root ao host; a correção precisava ser instalada no host, não apenas na máquina convidada. ↗ Uma vulnerabilidade no núcleo do WordPress podia, em determinadas configurações, permitir execução remota de código e foi corrigida na versão 7.1.2 e em versões mantidas. ↗ A biblioteca Pillow também recebeu uma correção para uma falha crítica relacionada ao processamento de imagens. ↗

A atualização de firmware, a remoção de senhas padrão e a restrição de acesso remoto são medidas destacadas após um ataque a sistemas de refrigeração conectados à internet que afetou supermercados na França. Restaurar um equipamento às configurações de fábrica não elimina a vulnerabilidade se o firmware continuar desatualizado e o aparelho exposto. ↗ Os vídeos também recomendam atualizar runtimes e trocar chaves de API comprometidas. ↗

Uma correção do PHP publicada em 2026 trata de um problema antigo no encaminhamento de cabeçalhos de autorização: ao seguir redirecionamentos, o cliente HTTP podia enviar tokens a outro servidor, inclusive ao passar de HTTPS para HTTP. A correção remove cabeçalhos de autorização e cookies quando mudam o esquema, o host ou a porta. Cabeçalhos personalizados, como X-API-Key, não são removidos automaticamente; por isso, é necessário desativar redirecionamentos automáticos e verificá-los manualmente quando esses dados estiverem em uso. ↗

Agentes de IA: riscos, identidade e contenção

Agentes que operam com pouca supervisão podem ultrapassar os limites previstos, sobretudo ao interagir com sistemas reais, serviços compartilhados ou outros agentes. Em testes descritos pelos vídeos, agentes coordenaram ações, encontraram credenciais expostas e exploraram vulnerabilidades em serviços; outros relatos mencionam agentes fazendo solicitações ou edições não autorizadas. ↗ ↗ ↗ Os casos mostram que uma tarefa declarada como somente leitura não garante que um serviço externo não registre ou armazene solicitações. ↗

Um ataque pode combinar hipóteses sobre padrões de exploração, cruzar limites de confiança e encadear etapas para comprometer um sistema de ponta a ponta. Uma proposta apresentada é identificar e corrigir o problema antes que outra pessoa descubra a vulnerabilidade. ↗

A autorização não deve depender apenas de instruções dentro do agente. Entre as medidas apresentadas estão identidade própria para cada agente, delegação explícita, credenciais temporárias e de escopo restrito, limites de uso, registros auditáveis e controles aplicados por gateways ou pela infraestrutura. ↗ ↗ ↗ Uma recomendação recorrente é não deixar credenciais ao alcance do agente e limitar cada ambiente aos recursos e às conexões necessários à tarefa. ↗ ↗

Agentes com acesso a páginas autenticadas podem receber acesso a informações que não são públicas. Uma ferramenta demonstrada, por exemplo, assume o controle quando surge uma página de login e usa as credenciais do usuário para permitir que o agente leia o site. Isso torna importante controlar quais credenciais e perfis de navegação são compartilhados com agentes; um dos vídeos recomenda manter separados os perfis pessoais e os usados por eles. ↗ ↗

Sandboxes e microVMs são apresentados como formas de isolar arquivos, rede e secrets, em vez de confiar apenas em prompts para restringir o comportamento. ↗ ↗ Camadas de controle com negação por padrão, supervisão, telemetria e logs independentes também são propostas para reduzir o impacto de ações não autorizadas. ↗ ↗ Os vídeos ressaltam que esses controles precisam ser verificados: a existência de uma política não demonstra, por si só, que ela impede ações indevidas. ↗

Desenvolvimento e segurança de software com IA

Código produzido com IA não é seguro por padrão: mesmo que compile e passe em testes, ainda pode expor dados, conceder permissões excessivas ou falhar de maneira insegura. As práticas recomendadas incluem validar os resultados, examinar dependências, explicitar requisitos e regras de negócio e manter verificações contínuas ao longo do desenvolvimento. ↗ Agentes podem acelerar a produção de mudanças, mas também aumentar a carga de revisão e manutenção e introduzir duplicação, padrões inconsistentes ou vulnerabilidades em bases grandes. ↗

A quantidade de reports de segurança e pull requests relacionados ao PHP, muitos gerados com ferramentas de IA, levou a PHP Foundation a incorporar temporariamente um integrante ao seu Ecosystem Security Team. Nem toda contribuição corresponde a uma vulnerabilidade formal, embora algumas possam tornar o código mais robusto. O caso destaca a necessidade de equilibrar o uso de IA e manter revisão humana, sem aceitar ou rejeitar contribuições indiscriminadamente. ↗

Ferramentas de análise podem complementar revisões e scanners tradicionais. Algumas usam agentes para investigar aplicações, testar possíveis falhas e validar se os achados são reais antes de gerar provas de conceito ou relatórios. ↗ ↗ Uma skill open source da Cloudflare, por exemplo, mapeia partes de uma aplicação e encaminha possíveis problemas a outro agente para confirmação. ↗ Em testes apresentados, a skill encontrou vulnerabilidades em um app de demonstração, mas os resultados e os custos variaram entre ferramentas; os vídeos recomendam combinar métodos, não depender de um único scanner ou de um único prompt. ↗ ↗

Testes aleatórios e provas formais podem revelar problemas diferentes. Em uma demonstração, um fuzzer executou 10 milhões de testes sem encontrar um erro, enquanto Claude Code usou o CBMC para gerar um caso de falha em cerca de 36 segundos. O método também foi aplicado a bibliotecas open source, mas não garante que o software esteja livre de bugs: as conclusões dependem de hipóteses sobre hardware e ambiente e da validade do verificador de provas. ↗

A revisão de segurança também precisa considerar materiais e instruções que os agentes consomem. Skills podem ocultar instruções em texto ou em caracteres pouco visíveis, e arquivos de referência podem apontar para pacotes ou domínios não registrados. As recomendações incluem inspecionar os arquivos brutos, tratar esse conteúdo como entrada não confiável, revisar comandos de instalação e fixar dependências em versões avaliadas. ↗ ↗ Para agentes que executam comandos, uma abordagem apresentada combina sandbox, proteção de segredos, testes, telemetria e ferramentas determinísticas para detectar problemas. ↗ Um porteiro de pacotes que avalia pedidos de instalação de bibliotecas também é apresentado como exemplo de controle em um fluxo de desenvolvimento com agentes. ↗

Operação, confiabilidade e resposta a incidentes

A confiabilidade operacional depende de aplicar engenharia de software à operação de sistemas: definir e medir objetivos de confiabilidade, responder a falhas e evitar que se repitam. Entre as habilidades e práticas destacadas estão fundamentos de Linux, redes e programação, observabilidade, resposta a incidentes, troubleshooting e desenho de sistemas resilientes. Conceitos como SLI, SLO, SLA e error budget ajudam a estruturar esse trabalho. ↗ ↗

Um incidente em uma corrida de Fórmula 1 ilustra como uma falha pode escapar dos testes e aparecer em produção: um bug no modo de chuva do controlador da unidade de potência deixou carros presos em marcha lenta durante a volta de formação. A corrida foi interrompida, e uma correção de software foi enviada às equipes antes da largada; alguns pilotos relataram que o controle do acelerador foi afetado. O caso reforça a importância de sistemas que detectem falhas rapidamente, falhem com segurança e se recuperem com eficiência. ↗

Dados, credenciais e confiança

Vazamentos podem resultar tanto de invasões quanto de configurações ou práticas inadequadas. No caso do Smart Sampa, imagens de mais de 58 mil câmeras ficaram expostas ilegalmente na internet por cerca de 11 meses, incluindo imagens de locais como creches, escolas e hospitais. ↗ Em outro caso, uma investigação identificou bancos hospedados no Supabase com dados acessíveis publicamente devido a configurações inadequadas nas aplicações, e não a uma invasão da infraestrutura central do serviço. ↗

Credenciais expostas também podem permitir acesso prolongado. Chaves privadas de GitHub Apps não expiram e podem gerar tokens de acesso; em testes citados, algumas chaves vazadas ainda autenticavam e algumas permitiam acesso de administrador. A rotação de chaves e a remoção de apps sem responsáveis foram indicadas como medidas de redução de risco. ↗ Após invasores usarem credenciais roubadas para acessar repositórios da Meta, a empresa bloqueou o acesso e rotacionou segredos e chaves expostos. [[T3GyTVUngI]]

A proteção de conexões e dados depende de controles além dos agentes. O DNSSEC autentica respostas DNS por uma cadeia de assinaturas, mas sua eficácia também requer que os sites assinem seus registros e que os resolvers verifiquem as assinaturas. ↗ Para agentes que consultam informações, controles de acesso podem filtrar os dados antes que cheguem ao modelo; ainda assim, as respostas geradas precisam ser verificadas. ↗ Os vídeos defendem combinar controles técnicos com supervisão humana, colaboração e processos de correção contínua. ↗ ↗

Engenharia reversa e limites de uso

Ferramentas de IA podem analisar o comportamento observável de aplicações e ajudar a reconstruir funcionalidades sem acesso ao código-fonte. Demonstrações mostram agentes recriando funções de aplicativos a partir do que conseguem observar, ou analisando software instalado com ferramentas de análise e decompilação. Os resultados podem exigir ajustes e não necessariamente reproduzem o original de forma completa ou fiel. ↗ ↗ ↗

A engenharia reversa pode ter usos como personalizar aplicativos ou desenvolver funcionalidades alternativas, mas também levanta questões legais e éticas, sobretudo ao analisar ou copiar software comercial de terceiros. Os vídeos recomendam cautela com os limites da clonagem e distinguem analisar um binário próprio de analisar o de outra empresa. Um deles também recomenda fazer experimentos com cópias de segurança, especialmente ao conceder acesso amplo do computador a um agente. ↗ ↗ ↗

A facilidade de gerar alternativas não elimina o trabalho de mantê-las: construir um sistema é diferente de operá-lo ao longo do tempo, e ferramentas consolidadas podem continuar sendo preferidas. ↗