Compartilhamento de tecnologia

한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina

fonte:https://thehackernews.com/2024/06/practical-guidance-for-securing-your.html

Não é nenhuma surpresa que as organizações de produção de software enfrentem uma pressão regulatória e legal crescente para proteger as suas cadeias de fornecimento e garantir a integridade do seu software. Nos últimos anos, a cadeia de fornecimento de software tornou-se um alvo cada vez mais atraente para os atacantes, que veem uma oportunidade de aumentar os seus ataques em ordens de grandeza. Por exemplo, observe as vulnerabilidades do Log4j em 2021. Log4j (uma estrutura de registro de código aberto mantida pelo Apache e usada em inúmeras aplicações diferentes) foi a fonte de vulnerabilidades que colocaram milhares de sistemas em risco.

A funcionalidade de comunicação do Log4j é vulnerável, proporcionando assim uma oportunidade para os invasores injetarem código malicioso nos logs, que podem então ser executados no sistema. Após sua descoberta, os pesquisadores de segurança observaram milhões de tentativas de exploração, muitas das quais se transformaram em ataques bem-sucedidos de negação de serviço (DoS). De acordo com uma nova pesquisa do Gartner, quase metade das organizações empresariais serão alvo de ataques à cadeia de fornecimento de software até 2025.

Mas o que é uma cadeia de fornecimento de software? Primeiro, é definido como a soma de todos os códigos, pessoas, sistemas e processos dentro e fora de uma organização que contribuem para o desenvolvimento e entrega de artefatos de software. O que torna a segurança da cadeia de fornecimento de software tão desafiadora é a complexidade e a natureza altamente distribuída do desenvolvimento de aplicações modernas. As organizações empregam equipes globais de desenvolvedores que contam com um número sem precedentes de dependências de código aberto, bem como extensos repositórios de código e registros de artefatos, pipelines de CI/CD e recursos de infraestrutura para construir e implantar aplicativos.

Embora a segurança e a conformidade sempre tenham sido as principais preocupações das organizações empresariais, proteger a cadeia de fornecimento de software de uma organização é cada vez mais desafiador. No entanto, muitas organizações fizeram progressos substanciais na implementação de práticas DevSecOps, e muitas delas ainda se encontram nas fases iniciais de descobrir o que fazer.

É exatamente por isso que elaboramos este artigo. Embora a lista a seguir não seja de forma alguma uma lista exaustiva, aqui estão quatro princípios orientadores que podem fazer com que seus esforços de segurança da cadeia de suprimentos de software sigam na direção certa.

Considere todos os aspectos da cadeia de fornecimento de software ao aplicar segurança

Dado que mais de 80% das bases de código contêm pelo menos uma vulnerabilidade de código aberto, as dependências de OSS tornaram-se naturalmente um foco central da segurança da cadeia de fornecimento de software. No entanto, a moderna cadeia de fornecimento de software inclui outras entidades cuja postura de segurança é negligenciada ou não é amplamente compreendida dentro da organização para ser adequadamente gerida. Essas entidades são repositórios de código, pipelines de CI e CD, infraestrutura e registros de artefatos, cada um dos quais requer controles de segurança e avaliações regulares de conformidade.

Estruturas como o OWASP Top-10 para benchmarks de segurança da cadeia de suprimentos de software CI/CD e CIS. A conformidade com essas estruturas exigirá um RBAC refinado, aplicando o princípio do menor privilégio, verificando contêineres e infraestrutura como código em busca de vulnerabilidades e configurações incorretas, isolando compilações, integrando testes de segurança de aplicativos e gerenciando adequadamente segredos – apenas para citar alguns.

SBOM é fundamental para corrigir problemas de dia zero e outros problemas de componentes

Parte da Ordem Executiva 14028, emitida pela Casa Branca em meados de 2021 para fortalecer a postura de segurança cibernética do país, exige que os produtores de software forneçam uma Lista de Materiais de Software (SBOM) aos seus clientes federais. SBOMs são essencialmente registros formais projetados para fornecer visibilidade de todos os componentes que compõem o software. Eles fornecem uma lista detalhada legível por máquina de todas as bibliotecas, dependências e componentes de código aberto e de terceiros usados ​​para construir o software.

Independentemente de uma organização ser ou não obrigada pela EO 14028, gerar e gerenciar SBOMs para artefatos de software é uma prática valiosa. SBOM é uma ferramenta indispensável para corrigir problemas de componentes ou vulnerabilidades de dia zero. Quando armazenado em um repositório pesquisável, o SBOM fornece um mapa da presença de dependências específicas e permite que as equipes de segurança rastreiem rapidamente as vulnerabilidades até o componente afetado.

Gerenciando o ciclo de vida de desenvolvimento de software usando política como código

No mundo do desenvolvimento de aplicativos modernos, proteções sólidas são uma ferramenta essencial para eliminar erros e ações intencionais que comprometem a segurança e a conformidade. A governança adequada em toda a cadeia de fornecimento de software significa que as organizações tornaram mais fácil fazer as coisas certas e extremamente difícil fazer as coisas erradas.

Embora muitas plataformas e ferramentas forneçam políticas prontas para uso que podem ser executadas rapidamente, a Política como Código, baseada no padrão do setor Open Policy Agent, permite a criação e execução de políticas totalmente personalizáveis. Gerencie políticas que vão desde permissões de acesso até permitir ou negar o uso de dependências de OSS com base em critérios como fornecedor, versão, URL do pacote e licença.

Capacidade de verificar e garantir a confiança em seus artefatos de software usando SLSA

Como os usuários e consumidores sabem que um software é confiável? Ao determinar a confiabilidade de um artefato de software, você desejará saber quem escreveu o código, quem o construiu e em qual plataforma de desenvolvimento ele foi construído. Saber quais componentes estão dentro também é algo que você deve saber.

Depois de verificar a procedência (um registro das origens e da cadeia de custódia do software), você poderá decidir se deseja confiar no software. Para tanto, foi criada a estrutura de nível de artefatos de software da cadeia de suprimentos (SLSA). Ele permite que as organizações de produção de software capturem informações de qualquer aspecto da cadeia de fornecimento de software, verifiquem as propriedades dos artefatos e suas construções e reduzam o risco de problemas de segurança. Na prática, as organizações de produção de software devem adotar e cumprir os requisitos da estrutura SLSA e implementar um método de validação e geração de atestados de software, que são declarações autenticadas (metadados) sobre artefatos de software em toda a cadeia de fornecimento de software.