0
0
Quando a Casa Branca emitiu a Ordem Executiva de Segurança Cibernética para Segurança Cibernética Nacional em maio de 2021, os observadores observaram que isso transformaria muitas práticas de desenvolvimento de software. A ordem, embora aplicada a qualquer pessoa que faça negócios com o governo federal dos EUA, deveria levar as indústrias a padronizar as práticas de segurança em todo o ciclo de vida de desenvolvimento de software, e não apenas ao lidar com os federais.
Uma das diretrizes centrais do pedido era a exigência de que os fornecedores de software e produtos orientados a software certificassem que estavam em conformidade com o pedido executivo, que estabelecia requisitos para análise de composição de software (SCA), proteção da cadeia de software e listas de materiais de software (SBOM). Ele sugere que os desenvolvedores forneçam SBOMs para todos os produtos e rastreiem a proveniência de componentes de software internos e de terceiros.
Até recentemente, o setor trabalhava com a suposição de que os SBOMs são a melhor pedra angular para uma defesa contra vulnerabilidades de software e ataques à cadeia de suprimentos, duas preocupações que acenderam o fogo sob os pés do governo. Mas, enquanto trabalha para fazer cumprir o pedido (e um memorando subsequente ), a Agência de Segurança Cibernética e Infraestrutura (CISA) divulgou recentemente para comentários um Formulário de Atestado de Desenvolvimento de Software Seguro (SSDF) que os fornecedores do governo federal devem usar para relatar seus conformidade. (Você pode procurar comentários aqui .)
Isso tem causado alguma confusão. O movimento da CISA deu a alguns a ideia errada de que os SBOMs estão sendo enfatizados porque não são um artefato necessário para cumprir. Mas o formulário apenas formaliza o papel da SBOM como primeira linha de defesa .
A orientação da CISA depende fortemente do Instituto Nacional de Padrões e Tecnologia, especialmente sua Estrutura de Desenvolvimento de Software Seguro (SSDF) , que estabelece algumas práticas recomendadas fundamentais. Isso está rapidamente se tornando o modelo para construir software em conformidade com os requisitos da ordem executiva. Essa estrutura é muito boa para produtos que estão sendo desenvolvidos no futuro, mas não é tão fácil atualizar o software legado ou alterar produtos já no pipeline de desenvolvimento para estar em total conformidade com a orientação do NIST. retroativamente.
O NIST tentou resolver isso mapeando os requisitos do pedido (PDF) para a orientação do SSDF, especialmente centralizando a conformidade na necessidade de instituir ambientes seguros de desenvolvimento de software. Por exemplo, requer o fornecimento de um SBOM para cada produto e a manutenção de uma fonte confiável de cadeia de fornecimento de código.
O formulário de autoatestação da CISA eleva os SBOMs
Superficialmente, essa abordagem pode parecer minimizar o papel dos SBOMs, mas, na verdade, eles ainda são um elemento importante para atender aos requisitos federais, juntamente com as tecnologias de teste de segurança de aplicativos, incluindo testes de segurança de aplicativos estáticos (SAST), testes de segurança de aplicativos dinâmicos (DAST ), e mais. A CISA apenas propõe que os fornecedores do governo federal declarem que seguem aspectos específicos do SSDF, incluindo o uso de SBOMs, para confirmar sua detecção de vulnerabilidade e tratamento de remediação.
Ignorar o uso de SBOMs para documentar o inventário de software de terceiros e a exposição à vulnerabilidade seria uma jogada arriscada. Os SBOMs são essenciais para detalhar os componentes de software envolvidos no desenvolvimento de software e detalhar as dependências, bem como quaisquer vulnerabilidades conhecidas. Conforme declarado pela CISA: “Estabelecer e manter processos para produzir e manter um SBOM atual pode ser utilizado pelo produtor de software como um meio de documentar a conformidade com certos requisitos mínimos.”
Além disso, o requisito de autoatestação reduz as preocupações sobre a divulgação pública entre os fornecedores, que se preocupam com a exposição da segurança ou a revelação da propriedade intelectual. As instruções da CISA sugerem que os SBOMs devem estar apenas disponíveis para revisão, não publicados, portanto não diminui a necessidade deles.
O formulário também esclarece o uso de ferramentas e artefatos para melhorar a segurança da cadeia de suprimentos de software. Requer “um esforço de boa fé para manter cadeias de fornecimento de código-fonte confiáveis” usando automação e “etapas razoáveis para abordar a segurança de componentes de terceiros e gerenciar vulnerabilidades relacionadas”. Ele também vai além ao explicar o lugar da automação na detecção e correção de vulnerabilidades, estendendo seu escopo além do código de terceiros para vulnerabilidades de segurança durante o desenvolvimento, que suporta o uso não apenas de SCA, mas também de SAST, DAST e outras ferramentas.
Superando as Primeiras Impressões
Apesar das primeiras impressões, o Formulário de Autoatestação da CISA não prejudica os SBOMs como o principal artefato para os desenvolvedores de software documentarem a conformidade com o mandato de segurança cibernética da Casa Branca. Pelo contrário, eles ainda são um artefato crítico de compliance, como demonstram as instruções — e os comentários resultantes. As instruções agora explicam claramente o papel da análise de composição de software e SBOMs daqui para frente.
Os SBOMs não vão desaparecer tão cedo. Quaisquer atrasos na promulgação desses novos padrões e na melhoria da segurança da cadeia de suprimentos de software apenas aumentam os riscos de não conformidade.
FONTE: DARKREADING