🔥 Fique por dentro das novidades mais quentes do momento! 🔥
Não deixe essa passar: clique e saiba tudo!
Apoie esse projeto de divulgacao de noticias! Clique aqui
Escrito por Ivan Milenkovic, vice-presidente de tecnologia de risco EMEA, Qualys
Durante a maior parte da última década, estivemos envolvidos numa ficção confortável em torno da segurança e do desenvolvimento. Se pudéssemos apenas “virar para a esquerda” e fazer com que os programadores assumissem um pouco mais de responsabilidade pela segurança, juntamente com a sua codificação, testes e implementação de infraestruturas, o mundo digital tornar-se-ia um lugar mais seguro, mais rápido e mais barato. Em vez disso, o conflito fundamental entre velocidade e segurança piorou.
Por que isso falhou? Os desenvolvedores estão sob pressão esmagadora. O clássico triângulo do gerenciamento de projetos – Rápido, Bom, Barato; escolha dois - foi feito em pedaços.
As empresas exigem rapidez, qualidade, baixo custo e segurança. Quando chega a hora, o “rápido” sempre vence. Ao mesmo tempo, colocamos muita carga cognitiva sobre os desenvolvedores que já estavam se afogando.
Quando optam por usar imagens de contêineres públicos para acelerar o desenvolvimento, eles estão tentando atingir seus objetivos, mas também estão abertos a riscos potenciais. Então, como podemos entender qual é o verdadeiro problema e depois trabalhar para resolvê-lo?
As demandas empresariais superam as recomendações de segurança
Há uma narrativa generalizada na indústria de segurança de que os desenvolvedores são preguiçosos ou descuidados. Isto não é absolutamente verdade. Os desenvolvedores não são preguiçosos; são profissionais sobrecarregados e pragmáticos que reagem aos incentivos que lhes são apresentados. Se o bônus depender dos recursos de envio até sexta-feira e a verificação de segurança levar quatro horas para ser executada e bloquear a compilação, eles encontrarão uma maneira de contornar a verificação.
As empresas exigem resultados cada vez mais rápidos, o que criou um ambiente onde os protocolos de segurança são vistos como uma barreira à produtividade e não como parte integrante da engenharia. Quando as ferramentas de segurança são barulhentas, lentas e desconectadas do fluxo de trabalho, elas são uma barreira.
No entanto, o resultado disso é que as organizações perderam o controle sobre o que realmente está sendo executado em seus ambientes. Temos pipelines que implantam código automaticamente, infraestrutura que pode ser ampliada ou reduzida sem intervenção humana e agentes de IA que agora podem escrever e executar seus próprios scripts.
Nesse caos automatizado e de alta velocidade, tratamos os registros públicos como bibliotecas com curadoria, presumindo que, por estar no Docker Hub, uma imagem deve ser segura. Mas retirar um contêiner de um registro público como o Docker Hub é uma decisão de confiança.
Empresas como Docker, Amazon, Google e Microsoft operam registros de contêineres públicos, portanto, há uma suposição natural de que eles são seguros.
Essa confiança é equivocada. No momento em que a imagem do contêiner chega ao pipeline de implantação, ela já é um artefato confiável, incorporado ao aplicativo.
Mudando para o CNAPP? Obtenha a visão da Forrester sobre como proteger seu futuro na nuvem
O 2026 Forrester Wave™ for Cloud-Native Application Protection Platforms (CNAPP) fornece análises objetivas sobre segurança na nuvem.
Descubra por que a Qualys é hoje uma das líderes do mercado.
Leia o Livro Branco
A verificação da realidade de 34.000 imagens
A Unidade de Pesquisa de Ameaças Qualys (TRU) conduziu recentemente uma análise exaustiva de mais de 34.000 imagens de contêineres extraídas de repositórios públicos para ver o que realmente está acontecendo abaixo do manifesto.
Desse total, cerca de 2.500 imagens – aproximadamente 7,3% da amostra – eram maliciosas. Das imagens maliciosas, 70% continham software de criptomineração.
Além disso, 42% das imagens continham mais de cinco segredos que poderiam ser usados para obter acesso a outros recursos ou contas. Isso inclui itens valiosos como chaves de acesso da AWS, tokens de API do GitHub e credenciais de banco de dados inseridas diretamente nas camadas de imagem.
Qualys Research – composição de imagens maliciosas com base na análise de mais de 2.500 contêineres maliciosos confirmados detectados no DockerHub
Na nossa análise, os maiores problemas em torno dos contentores maliciosos ainda são muito simples. Typosquatting é um dos métodos mais comuns que os invasores usam para baixar seus contêineres maliciosos. O conselho padrão de “verificar a ortografia” é essencial, sim, mas também é uma resposta de baixo consumo de energia a um problema de alto risco.
Dizer a um desenvolvedor para “ter mais cuidado” não é uma estratégia de segurança. Embora os registros públicos sejam úteis para aumentar a velocidade, não deveríamos permitir que os desenvolvedores extraissem registros públicos de forma alguma.
Em um ambiente maduro, cada imagem externa deve ser proxy por meio de um repositório interno de artefatos que atue como uma zona de quarentena. No entanto, essa necessidade de velocidade não irá desaparecer. Em vez disso, temos que trabalhar para ajudar os desenvolvedores a avançar mais rapidamente e, ao mesmo tempo, manter a segurança em vigor.
Isso significa mais trabalho para a equipe de infraestrutura, mas esse trabalho deverá permitir que os desenvolvedores avancem mais rapidamente e com menos riscos.
Deslocar para baixo
A lógica é que é mais barato corrigir um bug durante o design ou a codificação do que na produção. Portanto, mover a segurança mais cedo no Soft
Durante a maior parte da última década, estivemos envolvidos numa ficção confortável em torno da segurança e do desenvolvimento. Se pudéssemos apenas “virar para a esquerda” e fazer com que os programadores assumissem um pouco mais de responsabilidade pela segurança, juntamente com a sua codificação, testes e implementação de infraestruturas, o mundo digital tornar-se-ia um lugar mais seguro, mais rápido e mais barato. Em vez disso, o conflito fundamental entre velocidade e segurança piorou.
Por que isso falhou? Os desenvolvedores estão sob pressão esmagadora. O clássico triângulo do gerenciamento de projetos – Rápido, Bom, Barato; escolha dois - foi feito em pedaços.
As empresas exigem rapidez, qualidade, baixo custo e segurança. Quando chega a hora, o “rápido” sempre vence. Ao mesmo tempo, colocamos muita carga cognitiva sobre os desenvolvedores que já estavam se afogando.
Quando optam por usar imagens de contêineres públicos para acelerar o desenvolvimento, eles estão tentando atingir seus objetivos, mas também estão abertos a riscos potenciais. Então, como podemos entender qual é o verdadeiro problema e depois trabalhar para resolvê-lo?
As demandas empresariais superam as recomendações de segurança
Há uma narrativa generalizada na indústria de segurança de que os desenvolvedores são preguiçosos ou descuidados. Isto não é absolutamente verdade. Os desenvolvedores não são preguiçosos; são profissionais sobrecarregados e pragmáticos que reagem aos incentivos que lhes são apresentados. Se o bônus depender dos recursos de envio até sexta-feira e a verificação de segurança levar quatro horas para ser executada e bloquear a compilação, eles encontrarão uma maneira de contornar a verificação.
As empresas exigem resultados cada vez mais rápidos, o que criou um ambiente onde os protocolos de segurança são vistos como uma barreira à produtividade e não como parte integrante da engenharia. Quando as ferramentas de segurança são barulhentas, lentas e desconectadas do fluxo de trabalho, elas são uma barreira.
No entanto, o resultado disso é que as organizações perderam o controle sobre o que realmente está sendo executado em seus ambientes. Temos pipelines que implantam código automaticamente, infraestrutura que pode ser ampliada ou reduzida sem intervenção humana e agentes de IA que agora podem escrever e executar seus próprios scripts.
Nesse caos automatizado e de alta velocidade, tratamos os registros públicos como bibliotecas com curadoria, presumindo que, por estar no Docker Hub, uma imagem deve ser segura. Mas retirar um contêiner de um registro público como o Docker Hub é uma decisão de confiança.
Empresas como Docker, Amazon, Google e Microsoft operam registros de contêineres públicos, portanto, há uma suposição natural de que eles são seguros.
Essa confiança é equivocada. No momento em que a imagem do contêiner chega ao pipeline de implantação, ela já é um artefato confiável, incorporado ao aplicativo.
Mudando para o CNAPP? Obtenha a visão da Forrester sobre como proteger seu futuro na nuvem
O 2026 Forrester Wave™ for Cloud-Native Application Protection Platforms (CNAPP) fornece análises objetivas sobre segurança na nuvem.
Descubra por que a Qualys é hoje uma das líderes do mercado.
Leia o Livro Branco
A verificação da realidade de 34.000 imagens
A Unidade de Pesquisa de Ameaças Qualys (TRU) conduziu recentemente uma análise exaustiva de mais de 34.000 imagens de contêineres extraídas de repositórios públicos para ver o que realmente está acontecendo abaixo do manifesto.
Desse total, cerca de 2.500 imagens – aproximadamente 7,3% da amostra – eram maliciosas. Das imagens maliciosas, 70% continham software de criptomineração.
Além disso, 42% das imagens continham mais de cinco segredos que poderiam ser usados para obter acesso a outros recursos ou contas. Isso inclui itens valiosos como chaves de acesso da AWS, tokens de API do GitHub e credenciais de banco de dados inseridas diretamente nas camadas de imagem.
Qualys Research – composição de imagens maliciosas com base na análise de mais de 2.500 contêineres maliciosos confirmados detectados no DockerHub
Na nossa análise, os maiores problemas em torno dos contentores maliciosos ainda são muito simples. Typosquatting é um dos métodos mais comuns que os invasores usam para baixar seus contêineres maliciosos. O conselho padrão de “verificar a ortografia” é essencial, sim, mas também é uma resposta de baixo consumo de energia a um problema de alto risco.
Dizer a um desenvolvedor para “ter mais cuidado” não é uma estratégia de segurança. Embora os registros públicos sejam úteis para aumentar a velocidade, não deveríamos permitir que os desenvolvedores extraissem registros públicos de forma alguma.
Em um ambiente maduro, cada imagem externa deve ser proxy por meio de um repositório interno de artefatos que atue como uma zona de quarentena. No entanto, essa necessidade de velocidade não irá desaparecer. Em vez disso, temos que trabalhar para ajudar os desenvolvedores a avançar mais rapidamente e, ao mesmo tempo, manter a segurança em vigor.
Isso significa mais trabalho para a equipe de infraestrutura, mas esse trabalho deverá permitir que os desenvolvedores avancem mais rapidamente e com menos riscos.
Deslocar para baixo
A lógica é que é mais barato corrigir um bug durante o design ou a codificação do que na produção. Portanto, mover a segurança mais cedo no Soft
#samirnews #samir #news #boletimtec #por #que #o #sonho #da #mudança #para #a #esquerda #se #tornou #um #pesadelo #para #segurança #e #desenvolvedores
💡 Compartilhe e ajude nosso projeto a crescer!
Postar um comentário