0 
0 Assim como os desenvolvedores e as equipes de segurança estavam se preparando para descansar e iniciar o churrasco para o fim de semana de férias, as agências de segurança mais prestigiadas dos EUA (NSA, CISA e ODNI) lançaram um guia prático recomendado de mais de 60 páginas, Securing the Software Supply Cadeia para Desenvolvedores .
Minha primeira reação foi que é ótimo ver essas agências contribuindo para o discurso público nestes dias ainda inebriantes em que todos estamos classificando as melhores práticas de segurança da cadeia de suprimentos de software. Esta é uma voz importante para sacudir os muitos requisitos, estruturas e práticas recomendadas, e parabéns a eles por compartilhar algumas de suas duras lições aprendidas.
Mas acho que também é importante para os desenvolvedores em geral pesar o que faz sentido nos ambientes de segurança nacional mais extraordinariamente sensíveis, versus o que faz sentido para o desenvolvedor corporativo médio e a equipe de segurança.
Aqui está o que me chamou a atenção como as implicações boas, ruins e feias do relatório.
O bom
Existem algumas recomendações prescritivas excelentes no relatório onde essas agências estão defendendo estruturas específicas como Níveis da Cadeia de Suprimentos para Artefatos de Software (SLSA, pronunciado “salsa”) e Estrutura de Desenvolvimento de Software Seguro (SSDF). O relatório menciona essas estruturas 14 e 38 vezes, respectivamente, e para desenvolvedores e equipes de segurança que percebem que têm um problema de segurança na cadeia de suprimentos de software, mas não sabem por onde começar, agora eles têm um caminho claro para dar os primeiros passos.
O resultado dessas estruturas é que elas fornecem aos desenvolvedores orientações claras sobre (1) como desenvolver código seguro, desde questões de design até questões de estrutura organizacional para software mais seguro; (2) integridade do sistema de compilação (certificando-se de que código malicioso não está sendo injetado em nossos sistemas de compilação); e (3) o que acontece depois que o software é construído e como operar a segurança dos sistemas (remediação de vulnerabilidades, monitoramento, esses tipos de aspectos).
Também acho que o relatório faz um excelente trabalho ao enfatizar o que a assinatura de software compra aos desenvolvedores em termos de segurança de artefatos e como, ao investir em assinatura e verificação no início do ciclo de vida de desenvolvimento de software, você pode economizar muito trabalho e não ter que se preocupar com a segurança dos gerenciadores de pacotes mais adiante.
O mal
O guia sugere que “todos os sistemas de desenvolvimento devem ser restritos apenas às operações de desenvolvimento” … e continua dizendo que “nenhuma outra atividade, como e-mail, deve ser realizada para negócios ou uso pessoal”.
Não consigo ver um futuro em que os desenvolvedores sejam informados de que não podem usar Slack, e-mail e navegação na web em suas máquinas de desenvolvimento, e aqui está um exemplo em que o que é obrigatório em ambientes air-gapped como a NSA não é realmente mapeado para o mainstream cenários do desenvolvedor.
Também acho que a orientação da SBOM tem ótimos pontos, mas também perde ameaças concretas e exemplos de mitigação. No geral, a indústria continua a dizer a todos para usar SBOMs, mas não explica realmente o que fazer com eles ou quais são os benefícios reais. E embora eu goste da orientação para comparar SBOMs com resultados de análise de composição de software (SCA), a realidade é que os scanners de vulnerabilidade de hoje realmente perdem muitas das dependências transitivas que tornam as cadeias de suprimentos de software uma superfície de ameaça atraente em primeiro lugar.
O feio
Embora o código aberto seja mencionado 31 vezes no guia, trata-se principalmente de referências superficiais, sem novas recomendações. Todos nós sabemos que a maior parte do código-fonte usado hoje é de código aberto e tem aspectos exclusivos de segurança – o relatório não se preocupa em como escolher quais projetos de código aberto usar, o que procurar ao decidir sobre uma nova dependência , abordagens para sistemas de pontuação ou como saber a integridade da segurança de um projeto OSS.
Há um pouco de sobrecarga de informação. Metade do documento explica quais são seus conteúdos, e a outra metade apresenta alguns frameworks e as interseções desses frameworks. Acho que o que veremos a seguir é um maremoto de branqueamento de produtos de fornecedores de segurança, alegando ter os primeiros recursos em conformidade com essas diretrizes – mas é importante lembrar que não há processo de credenciamento, e a maior parte disso será simplesmente alarido de marketing.
Qual é o próximo
A segurança da cadeia de suprimentos de software é bastante única – você tem muitos tipos diferentes de ataques que podem atingir muitos pontos diferentes no ciclo de vida do software. Você não pode simplesmente pegar um software de segurança, ligá-lo e ficar protegido de tudo.
Guias e recomendações como esta que vêm das organizações mais sofisticadas que passaram pelos primeiros passos dão muitas dicas para os desenvolvedores em geral, e espero que a NSA/CSA/ODNI continue a divulgar esse tipo de insight… se isso pode exigir alguma decodificação para o que se aplica a cenários de desenvolvedores mais convencionais fora do Pentágono.
FONTE: HELPNET SECURITY