Em setembro de 2022, o Escritório de Gestão e Orçamento dos Estados Unidos (OMB) emitiu um memorando histórico sobre as etapas necessárias para proteger sua cadeia de fornecimento de software em um nível aceitável pelo governo federal dos EUA. Qualquer empresa que deseje fazer negócios com o governo e qualquer agência federal que produza software precisa cumprir os requisitos e o cronograma estabelecidos no Memorando M-22-18.
M-22-18 concentrou-se na segurança e integridade da cadeia de fornecimento de software, prestando especial atenção ao papel do SBOMs. Incluía uma lista de requisitos e um cronograma para implementar as etapas necessárias para conformidade.
O memorando estabeleceu dois documentos principais produzidos pelo NIST: a Estrutura de Desenvolvimento de Software Seguro (SSDF), SP 800-218 e Orientação de segurança da cadeia de suprimentos de software como orientação do NIST sobre desenvolvimento seguro de software. O memorando também descreve a responsabilidade dos produtores de software de auto-atestarem a sua conformidade com as orientações do NIST antes que as agências federais sejam livres para usar os seus produtos. Este auto-atestado deverá assumir a forma de um “formulário comum” de auto-atestado assinado. Três categorias de software exigem este formulário de auto-atestado: novas compras de software, atualizações de versões principais e renovações de software.
M-22-18 exigiu que a CISA estabelecesse este “formulário comum” de autocertificação padrão no prazo de 120 dias a partir da data desse memorando (14 de setembro de 2022). Esses 120 dias se passaram em janeiro de 2023, mas o formulário ainda está em rascunho de formulário embora o período para comentários tenha encerrado em 26 de junho de 2023. Foi aproximadamente quando o Memorando do OMB originalmente orientou as agências a começarem a coletar atestados para software crítico.
Com base em alguns dos comentários recebidos para esse formulário de atestado comum, o OMB considerou adequado divulgar uma alteração ao M-22-18 em 9 de junho de 2023. Esta alteração é intitulada M-23-16. O novo memorando estende o cronograma publicado em M-22-18 para que as agências coletem atestados de produtores de software. As agências agora são obrigadas a coletar os auto-atestado “formulário comum” dos produtores de software para software “crítico” no prazo máximo de três meses após o formulário comum de autocertificação da CISA ser aprovado pelo OMB. Todos os demais produtores de software têm seis meses após a aprovação do formulário de autocertificação pelo OMB.
Uma vez que este formulário padrão de auto-atestado parece estar no centro das atenções, vamos examinar o que está incluído nele com um pouco mais de detalhes. Também veremos quem exatamente deve assiná-lo e o que tal assinatura significaria.
Formulário comum de auto-atestado de software seguro
Seguindo a cadeia de regulamentação desde a EO 14028 até os documentos de orientação do NIST e os memorandos do OMB, fica claro que o governo pretende proteger todos, tanto agências federais como empresas do setor privado, de vulnerabilidades da cadeia de suprimentos de software e intrusões. Como o setor privado não fez o suficiente (na opinião do governo), o governo decidiu criar novas regulamentações que todos (que vendem para o governo federal) devem seguir.
Claro, mesmo que você não venda para o governo federal (ainda), é do seu interesse seguir essas regras e atestar que você está “seguro”, uma vez que essas empresas serão um parceiro de negócios mais atraente. Quem gostaria de fazer negócios com uma empresa que não pode confirmar que está fazendo tudo o que pode para proteger seus produtos e usuários?
Como já estabelecemos que a orientação do NIST é a base para a nova regulamentação e melhores práticas, não é surpresa que as mesmas sugestões que aparecem, por exemplo, no SSDF também aparecem no formulário de auto-atestado.
Aqui está um pequeno exemplo do documento preliminar:
Retirado do rascunho do Formulário Comum de Auto-Atestado de Software Seguro
Podemos ver o requisito à esquerda seguido pela seção EO relacionada e depois pelas práticas e tarefas do SSDF. Esta é uma lista bastante abrangente de requisitos (uma página e meia) que não seria necessariamente totalmente clara se o leitor não estivesse no ramo de segurança cibernética e/ou DevOps ou DevSecOps.
O documento exige que o signatário da empresa ateste PESSOALMENTE que todos os requisitos descritos no formulário são mantidos de forma consistente e que a empresa notificará as agências impactadas se algum elemento da lista não for mais válido.
O documento não especifica quem na empresa deve assinar o documento, mas como este formulário é o requisito para a empresa fazer negócios com o governo federal e suas agências, é lógico que o CEO é a pessoa que deve assumir a responsabilidade aqui. O CEO provavelmente não o assinará cegamente e pedirá ao CTO e ao CISO que verifiquem (possivelmente por escrito) se a empresa segue todas essas diretrizes e requisitos.
Como não existe um produto ou modo de operação estabelecido para coletar e atestar todos esses requisitos, de certa forma, cada empresa signatária precisa “reinventar a roda” por si mesma e torcer para que nada de ruim aconteça.
Se algo ruim acontecer, o governo federal irá atrás do signatário para mostrar e provar que pode respaldar todos os requisitos dos formulários.
O que acontece se eu não assinar?
Primeiro, toda essa coisa de atestado atualmente só é relevante se o seu software estiver sendo usado por uma agência federal, se você pretende vender seu software ao governo federal ou se o seu software estiver sendo usado por um fornecedor cujo software esteja em uso ou se destina a ser vendido ao governo federal.
Observe que eu disse “atualmente”, pois há todos os indícios de que a conformidade com o SSDF, seja como auto-atestado ou de alguma outra forma verificável, se tornará uma nova “melhor prática” no campo da produção de software.
Então, supondo que sua empresa se enquadre no grupo citado acima e você não consiga encontrar a forma de assinar esse documento com a consciência tranquila, nem tudo está perdido ainda. Contanto que você possa explicar onde está a falha no atestado e oferecer uma resposta satisfatória Plano de Ação e Marcos (POA&M) a agência federal em questão ainda pode comprar/usar seu produto e buscar uma extensão para seu software em seu nome junto ao OMB.
A má notícia é que, com ou sem um plano POA&M, você eventualmente precisará fornecer um formulário de atestado completo, o que significa que você precisa ser capaz de verificar em um tribunal federal se todas as etapas exigidas pelo formulário foram seguidas pela sua empresa e que seu o processo de desenvolvimento de software é pelo menos tão seguro quanto os requisitos do formulário.
O único software atualmente isento desta forma de atestado é o software desenvolvido por agências federais e o software disponível gratuitamente, também conhecido como software de código aberto. Claro, a maioria segurança da cadeia de suprimentos de software falhas podem ser atribuídas de alguma forma a algum pacote de código aberto em seu código, mas há um problema real em tentar forçar os desenvolvedores e mantenedores de código aberto, que trabalham de graça, a fornecer uma garantia juridicamente vinculativa para seu software. Deveria caber a qualquer pessoa que use software de código aberto verificar sua segurança tanto em geral quanto no que diz respeito ao software no qual está incorporado em particular.
Pior Cenário
Toda essa preocupação com a segurança da cadeia de suprimentos de software começou depois do famoso SolarWinds cortar. Sem entrar em muitos detalhes, no momento do hack, mais de 18,000 mil clientes da empresa foram impactados, incluindo 9 agências federais.
Só agora, anos depois, começamos a ver alguns dos resultados legais deste incidente. O segundo, Comissão de Valores Mobiliários dos EUA, está indo atrás da empresa como um todo, bem como depois de vários executivos de nível C. Isso pode ser visto como um exemplo das intenções do governo caso um incidente desse tipo ou semelhante acontecesse com um produtor de software que atestasse suas práticas de desenvolvimento seguro e ainda assim fosse vítima de um hack.
No caso da SolarWinds, a empresa apoia totalmente qualquer funcionário que seja alvo de tal ação legal. Conhecendo o sistema jurídico dos EUA, tais casos provavelmente levarão anos e custarão muito dinheiro. As multas não estão fora de questão e podem atingir somas na casa dos milhões com base numa estimativa do danos sofridos.
Você pode imaginar que nem todas as empresas, especialmente as pequenas e médias, protegem seus funcionários tão firmemente quanto a SolarWinds. O problema é que, se a parte acusada for o CEO da empresa, há uma probabilidade real de que a confiança do mercado na empresa e no seu produto seja gravemente prejudicada. Enfrentar a SEC sem o apoio de uma grande empresa com recursos financeiros poderia arruinar um CEO desavisado, bem como sua empresa. É claro que a intenção é fazer com que as pessoas assumam seriamente a sua responsabilidade de garantir o desenvolvimento, mas o medo pode levar as pessoas a errar para o lado da autopreservação. Isso significa que as pessoas preferem ocultar incidentes de segurança cibernética se acharem que não podem ganhar um potencial caso da SEC ou se temem que o custo e a má publicidade de tal caso sejam tão graves que é melhor ocultá-los, independentemente do resultado do processo judicial.
Como posso assinar?
A orientação SSDF do NIST está repleta de sugestões e práticas recomendadas, mas é leve em aspectos práticos. Como cada empresa é única, é muito difícil criar um produto ou sistema que funcione para todos. Neste caso, o sector privado está a intervir para preencher o vazio, criando um ecossistema para o ajudar a cumprir os requisitos.
Por exemplo, nos Scribe construiu uma plataforma baseado no conceito de criar atestados, assiná-los e oferecer a possibilidade de verificá-los. Em breve lançaremos um documento sob medida para o Formulário de autocertificação CISA, demonstrando como a solução Scribe pode ajudá-lo em cada seção dos requisitos. Fique atento.
Experimentar A plataforma do Scribe é gratuita. Encorajo você a experimentar e ver como você pode adequar a plataforma às suas necessidades e, ao mesmo tempo, assinar o formulário de autocertificação da CISA com a consciência tranquila.
Este conteúdo é oferecido a você pela Scribe Security, um fornecedor líder de soluções de segurança de cadeia de suprimentos de software ponta a ponta – fornecendo segurança de última geração para artefatos de código e processos de desenvolvimento e entrega de código em todas as cadeias de suprimentos de software. Saiba mais.
Artigos Relacionados
