📰 Informação fresquinha chegando para você!
Sua opinião é importante: leia e participe!
Apoie esse projeto de divulgacao de noticias! Clique aqui
Os invasores da cadeia de suprimentos não estão apenas tentando inserir códigos maliciosos em softwares confiáveis. Eles estão tentando roubar o acesso que torna possível o software confiável. Recentemente, três campanhas separadas atingiram npm, PyPI e Docker Hub em uma janela de 48 horas, e todos os três segredos direcionados de ambientes de desenvolvedor e pipelines de CI/CD, incluindo chaves de API, credenciais de nuvem, chaves SSH e tokens. Esta é uma preocupação constante e auto-propagadora, como pode ser visto em ataques como as campanhas “mini Shai Hulud”.
Esse padrão deve mudar a forma como as equipes de segurança pensam sobre a cadeia de fornecimento de software.
Tradicionalmente, a segurança se concentrava em sistemas compartilhados, como repositórios de código-fonte, plataformas CI/CD, registros de artefatos, gerenciadores de pacotes e ambientes de nuvem. O objetivo era proteger as cargas de trabalho e os dados de produção. Ainda precisamos de nos concentrar nestas áreas, mas é um quadro incompleto.
A entrega de software moderno começa antes do código chegar ao Git. Tudo começa na estação de trabalho do desenvolvedor, onde o código é escrito, as dependências são instaladas, as credenciais são testadas, os assistentes de IA são solicitados, os contêineres são criados e as ações confiáveis são iniciadas.
As estações de trabalho dos desenvolvedores são uma parte real da cadeia de fornecimento de software. Tratá-los como “apenas” endpoints comuns deixa lacunas entre segurança de endpoint, segurança de identidade, segurança de aplicativos e governança da cadeia de suprimentos.
Os ataques à cadeia de suprimentos tornaram-se operações de coleta de credenciais
Incidentes recentes continuam apontando para a mesma verdade operacional. Os invasores podem usar pacotes envenenados, imagens comprometidas, bots de dependência, fluxos de trabalho maliciosos ou ferramentas de desenvolvedor vulneráveis, mas o objetivo recorrente é o acesso.
Eventos como as campanhas TeamPCP e Shai-Hulud mostram como os ataques à cadeia de abastecimento convergem cada vez mais em torno do roubo de credenciais. Na campanha TeamPCP, os invasores usaram pacotes comprometidos e ferramentas de desenvolvedor para coletar tokens, credenciais de nuvem, chaves SSH, arquivos de configuração npm e variáveis de ambiente.
Shai-Hulud levou o mesmo padrão ainda mais longe, transformando ambientes de desenvolvedores infectados em pontos de coleta de credenciais que expuseram milhares de segredos no GitHub, serviços em nuvem, registros de pacotes e sistemas internos.
Isso não é apenas adulteração de software. É a coleta de credenciais em pontos onde os desenvolvedores e a automação já possuem confiança.
A cadeia de fornecimento é exposta quando os invasores obtêm acesso a credenciais e contexto que lhes permitem alterar, publicar, construir, implantar ou personificar sistemas de software confiáveis. Os pacotes alterados e publicados em um ataque moderno à cadeia de suprimentos permanecem ativos por horas, enquanto as ferramentas de automação mesclam atualizações maliciosas em minutos.
O fio condutor de muitos dos ataques recentes tem sido os segredos, seja como vetor de acesso inicial ou como alvo de coleta.
O caminho do invasor agora passa pelo contexto do desenvolvedor
A estação de trabalho do desenvolvedor é valiosa porque concentra o contexto. Geralmente contém repositórios locais, arquivos .env, histórico de shell, chaves SSH, credenciais e configurações do gerenciador de pacotes, scripts de construção, logs de depuração e sessões do navegador. Essas peças tornam-se muito mais perigosas quando vistas juntas.
Um único token de acesso pode parecer limitado isoladamente. Um token encontrado próximo a um Git remoto, script de implantação, README, perfil de nuvem e configuração de CI informa ao invasor onde o token se encaixa e o que ele pode desbloquear. Na campanha Shai-Hulud 2.0, por exemplo, as credenciais do GitHub dominaram as credenciais expostas e exfiltradas, cada uma com potencial acesso de administrador a repositórios e fluxos de trabalho de CI.
O comprometimento local não é apenas um problema de dispositivo. Ele pode servir como um mapa para controle de origem, contas em nuvem, fluxos de trabalho de publicação de pacotes, sistemas CI/CD, APIs internas e infraestrutura adjacente à produção.
Autoridade de entrega de software concentrada em máquinas de desenvolvedores
Um laptop padrão de funcionário pode expor dados corporativos. Uma estação de trabalho de desenvolvedor pode expor a capacidade de alterar software. Essa distinção é crítica quando se considera a segurança de endpoint.
Os desenvolvedores geralmente precisam de amplo acesso para realizar seu trabalho. Eles clonam repositórios privados, autenticam serviços em nuvem, publicam pacotes, acessam ambientes de teste e interagem com diversas ferramentas internas. Suas máquinas se tornam uma interseção funcional de código-fonte, credenciais, automação e autoridade de entrega.
Embora nem todos os desenvolvedores tenham acesso à produção, muitos têm acesso suficiente para influenciar os sistemas que eventualmente produzem resultados de produção. Um token de registro pode afetar pacotes. Um token GitHub pode afetar repositórios ou fluxos de trabalho. Um perfil de nuvem pode expor a infraestrutura. Uma credencial CI/CD pode afetar o comportamento de construção.
O conselho e os auditores não se importam se um desenvolvedor armazenou um segredo localmente. O risco comercial é, na verdade, que uma exposição local forneça aos invasores um caminho para sistemas que constroem
Esse padrão deve mudar a forma como as equipes de segurança pensam sobre a cadeia de fornecimento de software.
Tradicionalmente, a segurança se concentrava em sistemas compartilhados, como repositórios de código-fonte, plataformas CI/CD, registros de artefatos, gerenciadores de pacotes e ambientes de nuvem. O objetivo era proteger as cargas de trabalho e os dados de produção. Ainda precisamos de nos concentrar nestas áreas, mas é um quadro incompleto.
A entrega de software moderno começa antes do código chegar ao Git. Tudo começa na estação de trabalho do desenvolvedor, onde o código é escrito, as dependências são instaladas, as credenciais são testadas, os assistentes de IA são solicitados, os contêineres são criados e as ações confiáveis são iniciadas.
As estações de trabalho dos desenvolvedores são uma parte real da cadeia de fornecimento de software. Tratá-los como “apenas” endpoints comuns deixa lacunas entre segurança de endpoint, segurança de identidade, segurança de aplicativos e governança da cadeia de suprimentos.
Os ataques à cadeia de suprimentos tornaram-se operações de coleta de credenciais
Incidentes recentes continuam apontando para a mesma verdade operacional. Os invasores podem usar pacotes envenenados, imagens comprometidas, bots de dependência, fluxos de trabalho maliciosos ou ferramentas de desenvolvedor vulneráveis, mas o objetivo recorrente é o acesso.
Eventos como as campanhas TeamPCP e Shai-Hulud mostram como os ataques à cadeia de abastecimento convergem cada vez mais em torno do roubo de credenciais. Na campanha TeamPCP, os invasores usaram pacotes comprometidos e ferramentas de desenvolvedor para coletar tokens, credenciais de nuvem, chaves SSH, arquivos de configuração npm e variáveis de ambiente.
Shai-Hulud levou o mesmo padrão ainda mais longe, transformando ambientes de desenvolvedores infectados em pontos de coleta de credenciais que expuseram milhares de segredos no GitHub, serviços em nuvem, registros de pacotes e sistemas internos.
Isso não é apenas adulteração de software. É a coleta de credenciais em pontos onde os desenvolvedores e a automação já possuem confiança.
A cadeia de fornecimento é exposta quando os invasores obtêm acesso a credenciais e contexto que lhes permitem alterar, publicar, construir, implantar ou personificar sistemas de software confiáveis. Os pacotes alterados e publicados em um ataque moderno à cadeia de suprimentos permanecem ativos por horas, enquanto as ferramentas de automação mesclam atualizações maliciosas em minutos.
O fio condutor de muitos dos ataques recentes tem sido os segredos, seja como vetor de acesso inicial ou como alvo de coleta.
O caminho do invasor agora passa pelo contexto do desenvolvedor
A estação de trabalho do desenvolvedor é valiosa porque concentra o contexto. Geralmente contém repositórios locais, arquivos .env, histórico de shell, chaves SSH, credenciais e configurações do gerenciador de pacotes, scripts de construção, logs de depuração e sessões do navegador. Essas peças tornam-se muito mais perigosas quando vistas juntas.
Um único token de acesso pode parecer limitado isoladamente. Um token encontrado próximo a um Git remoto, script de implantação, README, perfil de nuvem e configuração de CI informa ao invasor onde o token se encaixa e o que ele pode desbloquear. Na campanha Shai-Hulud 2.0, por exemplo, as credenciais do GitHub dominaram as credenciais expostas e exfiltradas, cada uma com potencial acesso de administrador a repositórios e fluxos de trabalho de CI.
O comprometimento local não é apenas um problema de dispositivo. Ele pode servir como um mapa para controle de origem, contas em nuvem, fluxos de trabalho de publicação de pacotes, sistemas CI/CD, APIs internas e infraestrutura adjacente à produção.
Autoridade de entrega de software concentrada em máquinas de desenvolvedores
Um laptop padrão de funcionário pode expor dados corporativos. Uma estação de trabalho de desenvolvedor pode expor a capacidade de alterar software. Essa distinção é crítica quando se considera a segurança de endpoint.
Os desenvolvedores geralmente precisam de amplo acesso para realizar seu trabalho. Eles clonam repositórios privados, autenticam serviços em nuvem, publicam pacotes, acessam ambientes de teste e interagem com diversas ferramentas internas. Suas máquinas se tornam uma interseção funcional de código-fonte, credenciais, automação e autoridade de entrega.
Embora nem todos os desenvolvedores tenham acesso à produção, muitos têm acesso suficiente para influenciar os sistemas que eventualmente produzem resultados de produção. Um token de registro pode afetar pacotes. Um token GitHub pode afetar repositórios ou fluxos de trabalho. Um perfil de nuvem pode expor a infraestrutura. Uma credencial CI/CD pode afetar o comportamento de construção.
O conselho e os auditores não se importam se um desenvolvedor armazenou um segredo localmente. O risco comercial é, na verdade, que uma exposição local forneça aos invasores um caminho para sistemas que constroem
Fonte: https://thehackernews.com
#samirnews #samir #news #boletimtec #as #estações #de #trabalho #para #desenvolvedores #agora #fazem #parte #da #cadeia #de #fornecimento #de #software
🔔 Siga-nos para não perder nenhuma atualização!
Postar um comentário