A pressão regulatória e authorized aumentada sobre organizações produtoras de software program para proteger suas cadeias de suprimentos e garantir a integridade de seu software program não deve ser nenhuma surpresa. Nos últimos anos, a cadeia de suprimentos de software program se tornou um alvo cada vez mais atraente para invasores que veem oportunidades de forçar a multiplicação de seus ataques por ordens de magnitude. Por exemplo, não procure além da violação do Log4j de 2021, onde o Log4j (uma estrutura de registro de código aberto mantida pela Apache e usada em uma miríade de aplicativos diferentes) foi a raiz de explorações que colocaram milhares de sistemas em risco.
A funcionalidade de comunicação do Log4j period vulnerável e, portanto, fornecia uma abertura para um invasor injetar código malicioso nos logs, que poderia então ser executado 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 algumas das pesquisas mais recentes do Gartner, perto de metade das organizações empresariais terão sido alvo de um ataque à cadeia de fornecimento de software program até 2025.
Mas o que é a cadeia de fornecimento de software program? Bem, para começar, é definido como a soma complete de todos os códigos, pessoas, sistemas e processos que contribuem para o desenvolvimento e entrega de artefatos de software program, tanto dentro quanto fora de uma organização. E o que torna a segurança da cadeia de fornecimento de software program tão desafiadora é a natureza complexa e 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, juntamente com uma variedade de repositórios de código e registros de artefatos, pipelines de CI/CD e recursos de infraestrutura usados para construir e implantar seus aplicativos.
E embora a segurança e a conformidade sejam consistentemente uma das principais preocupações das organizações empresariais, o desafio de proteger as cadeias de fornecimento de software program da organização é cada vez maior. Muitas organizações estão fazendo progressos materiais na operacionalização de práticas de DevSecOps; no entanto, muitas delas ainda se encontram nos estágios iniciais para 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 para fazer com que os esforços de segurança da cadeia de suprimentos de software program sigam na direção certa.
Considere todos os aspectos da sua cadeia de suprimentos de software program ao aplicar segurança
Dado que mais de 80% das bases de código têm pelo menos uma vulnerabilidade de código aberto, é lógico que as dependências de OSS têm sido um foco central da segurança da cadeia de fornecimento de software program. No entanto, as cadeias de fornecimento de software program modernas abrangem outras entidades cujas posturas de segurança são negligenciadas ou não são compreendidas de forma suficientemente ampla dentro da organização para serem geridas adequadamente. 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ção common de conformidade.
Estruturas como OWASP Prime-10 para CI/CD e CIS Software program Provide Chain Safety Benchmark. A adesão a essas estruturas exigirá RBAC granular, aplicação do princípio de menor privilégio, verificação de contêineres e infraestrutura como código em busca de vulnerabilidades e configurações incorretas, isolamento de compilações, integração de testes de segurança de aplicativos e gerenciamento adequado de segredos – apenas para citar alguns.
SBOMs são essenciais para remediar 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, determina que os produtores de software program forneçam aos seus clientes federais uma lista de materiais de software program (SBOMs). Os SBOMs são essencialmente registros formais destinados a fornecer visibilidade de todos os componentes que compõem um pedaço de software program. Eles fornecem um inventário detalhado e legível por máquina que lista todas as bibliotecas, dependências e componentes de código aberto e de terceiros usados na construção do software program.
Quer uma organização seja obrigada pela EO 14028 ou não, gerar e gerenciar SBOMs para artefatos de software program é uma prática valiosa. Os SBOMs são uma ferramenta indispensável para corrigir problemas de componentes ou vulnerabilidades de dia zero. Quando armazenados em um repositório pesquisável, os SBOMs fornecem um mapa de onde existe uma dependência específica e permitem que as equipes de segurança rastreiem rapidamente as vulnerabilidades até os componentes afetados.
Governe o ciclo de vida do desenvolvimento de software program com a 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 program significa que a organização tornou mais fácil fazer as coisas certas e extremamente difícil fazer as coisas erradas.
Embora muitas plataformas e ferramentas ofereçam políticas prontas para uso que podem ser aplicadas rapidamente, a política como código baseada no padrão do setor Open Coverage Agent permite a criação e a aplicação de políticas totalmente personalizáveis. Políticas que regem tudo, desde privilégios 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.
Ser capaz de verificar e garantir a confiança em seus artefatos de software program usando SLSA
Como usuários e consumidores podem saber que um pedaço de software program é confiável? Ao determinar a confiabilidade de um artefato de software program, você gostaria de saber sobre coisas como quem escreveu o código, quem o construiu e em qual plataforma de desenvolvimento ele foi construído. Saber quais componentes estão nele também seria algo que você deveria saber.
Tomar a decisão de confiar no software program é possível uma vez que a procedência – o registro das origens e da cadeia de custódia de um software program – possa ser verificada. Para isso, foi criada a estrutura Provide Chain Ranges for Software program Artifacts (SLSA). Ele oferece às organizações produtoras de software program a capacidade de capturar informações sobre qualquer aspecto da cadeia de fornecimento de software program, verificar as propriedades dos artefatos e sua construção e reduzir o risco de problemas de segurança. Na prática, é essencial que as organizações produtoras de software program adotem e cumpram os requisitos da estrutura SLSA e implementem um meio de verificar e gerar atestados de software program que são declarações autenticadas (metadados) sobre artefatos de software program em todas as suas cadeias de fornecimento de software program.
Dada a magnitude e a complexidade da segurança da moderna cadeia de fornecimento de software program, as orientações acima apenas arranham a superfície. Mas, como tudo no mundo da construção e implantação de aplicações modernas, a prática está evoluindo rapidamente. Para ajudá-lo a começar, recomendamos a leitura Como entregar software program com segurança – um e-book repleto de práticas recomendadas desenvolvidas para fortalecer sua postura de segurança e minimizar riscos para seus negócios.
