Suporte Técnico
Documentação
Entrar
Entre em contato conosco
Vá direto para um resumo gerado por IA desta postagem do blog 
Principais conclusões
- Na ausência de uma avaliação independente, o diretor executivo ou um funcionário por ele designado e autorizado a representar a empresa assina o formulário.
- O signatário atesta, de acordo com o que tem conhecimento, que o produtor atualmente adota de forma consistente as práticas descritas neste formulário.
- De acordo com o memorando M-26-05 do OMB, cada órgão federal decide agora se solicita ou não o formulário; portanto, um órgão para o qual você forneça produtos ainda pode exigi-lo.
- O código-fonte de terceiros não está diretamente abrangido pelo formulário; no entanto, os produtores afirmam que gerenciam os riscos a ele associados.
Caso uma agência federal solicite o formulário de atestado de desenvolvimento seguro de software e sua empresa opte por fazer um autoatestado em vez de anexar uma avaliação de terceiros, o signatário deverá ser o diretor executivo (CEO) ou uma pessoa designada por ele, que seja funcionário da empresa e tenha autoridade para vincular a corporação. A decisão de solicitar ou não esse documento cabe agora à própria agência, de acordo com o memorando M-26-05 do Escritório de Gestão e Orçamento (OMB), datado de 23 de janeiro de 2026.
É possível que esse signatário nunca tenha analisado como as dependências de código aberto são incorporadas às suas compilações, mas seu nome acaba constando em uma declaração sobre como sua empresa gerencia o risco associado ao código que sua equipe não escreveu.
O formulário solicita que uma pessoa ateste práticas realizadas por várias equipes. Esse atestado vem acompanhado de restrições, e vários de seus termos deixam a cargo do produtor decidir o que se enquadra neles. Um signatário que compreenda tanto as restrições quanto os termos abertos está em uma posição muito melhor para assinar um documento preciso.
Como o Formulário de Atestado de Desenvolvimento Seguro de Software Passou a Ser Opcional
A Agência de Segurança Cibernética e de Infraestrutura (CISA) divulgou o formulário em 11 de março de 2024. Os produtores de software — ou seja, as empresas que desenvolvem ou compilam o software — utilizam-no para atestar que o produto que comercializam foi desenvolvido em conformidade com práticas específicas de desenvolvimento seguro.
Por alguns anos, o OMB tornou a certificação obrigatória. O memorando M-22-18, emitido em 14 de setembro de 2022 e atualizado pelo memorando M-23-16 em 9 de junho de 2023, permite que uma agência utilize o software abrangido somente após o fabricante atestar a adoção de práticas de desenvolvimento seguro alinhadas com a Estrutura de Desenvolvimento Seguro de Software (SSDF).
Em seguida, em 23 de janeiro de 2026, o M-26-05 revogou ambos os memorandos. Agora, os órgãos podem optar por utilizar ou não o formulário da CISA. Eles também podem incluir cláusulas contratuais que exijam que um fabricante forneça uma lista de materiais de software (SBOM) atualizada, mediante solicitação. O formulário em si não foi revisado e ainda cita os dois memorandos revogados como base jurídica, de modo que algumas de suas instruções não se aplicam mais.
Para um produtor que não possa comprovar todas as práticas, o formulário ainda descreve um plano de ação e marcos (POA&M) para sanar as lacunas, respaldado por uma prorrogação ou isenção do OMB. A norma M-26-05 não estabelece nenhum substituto para esse processo; portanto, um produtor nessa situação deve perguntar à agência solicitante o que ela aceita em seu lugar.
O que o signatário afirma e o que permanece em aberto
A Seção III do formulário, intitulada “Atestado e Assinatura”, solicita que uma pessoa declare, em nome do produtor, que o software foi desenvolvido em conformidade com as práticas nela listadas. Ela apresenta quatro declarações numeradas, precedidas por duas ressalvas. O signatário atesta que, “até onde é do meu conhecimento”, o produtor “atualmente faz uso consistente” dessas práticas no desenvolvimento do software mencionado na Seção I. Essas práticas abrangem o ambiente de compilação, a cadeia de suprimentos de código, a proveniência (registros de onde o código veio e como foi compilado) e como o produtor identifica e lida com vulnerabilidades. Nada na Seção III exige que o signatário declare que o software está isento de vulnerabilidades.
Ambas as ressalvas restringem a afirmação. “Atualmente” abrange as práticas em vigor no momento da assinatura do formulário, e “até onde sei” limita a declaração ao que o signatário tem conhecimento. Nem as instruções nem a Seção III especificam o que o signatário deve fazer para confirmar que as práticas estão em vigor, e a pessoa designada não precisa ter nenhum cargo específico. Portanto, o produtor decide quem atesta as práticas — como as equipes responsáveis pelas compilações — antes que alguém assine. Uma assinatura com base nisso reflete apenas o nível de conhecimento dessas equipes.
Tabela 1. O que o formulário especifica sobre a assinatura
| Item | O que consta no formulário | Base |
|---|---|---|
| Signatário | O diretor executivo da produtora de software, ou um representante designado que seja funcionário com autoridade para vincular a empresa | Instruções para preenchimento do formulário |
| Escopo | Em toda a empresa, produto específico, vários produtos ou versões específicas de produtos | Formulário, Seção I |
| Alternativa | Se houver uma avaliação de terceiros anexada ao formulário, o produtor não precisa assiná-lo | Instruções para o preenchimento do formulário e Seção III |
Um produtor pode anexar uma avaliação de terceiros em vez de assinar. O avaliador deve ser uma Organização Avaliadora de Terceiros (3PAO) certificada pelo Programa Federal de Gestão de Riscos e Autorizações (FedRAMP) ou aprovada por escrito por um funcionário competente da agência. Além disso, a avaliação deve ser realizada de acordo com as orientações relevantes do Instituto Nacional de Padrões e Tecnologia (NIST), que abrangem todos os elementos do formulário. O FedRAMP agora se refere a essas organizações como avaliadores independentes, embora o formulário da CISA ainda utilize a sigla 3PAO. Para utilizar uma avaliação, o produtor marca uma opção na Seção III e a anexa.
Onde os componentes de terceiros se situam no balanço patrimonial
A Seção I lista quatro categorias que o formulário não abrange. Uma delas é o que se denomina “componentes de código aberto e proprietários de terceiros”, ou seja, aqueles incorporados ao produto final de software utilizado por uma agência. Uma nota na mesma seção indica que os signatários atestam o cumprimento das práticas da Seção III para o código desenvolvido pelo produtor. As instruções, no entanto, estabelecem que os produtores que utilizam componentes de terceiros devem atestar ter tomado medidas específicas previstas na Seção III para minimizar os riscos decorrentes do uso desses componentes. Lidas em conjunto, a exclusão e as instruções significam que o signatário não se responsabiliza pelo código de terceiros em si, mas apenas pelas medidas tomadas pelo produtor para gerenciar esse risco.
As declarações 2 e 3 são onde os componentes de terceiros são mencionados nominalmente. A declaração 2 exige um “esforço de boa-fé” para manter cadeias de suprimento confiáveis de código-fonte, utilizando “ferramentas automatizadas ou processos equivalentes” para garantir a segurança do código interno e dos componentes de terceiros e gerenciar as vulnerabilidades relacionadas. A declaração 3 solicita que o produtor mantenha a proveniência do código interno e dos componentes de terceiros “na medida do possível”. A título de referência, o apêndice do formulário se alinha às tarefas do SSDF, incluindo a tarefa de verificar componentes de código aberto.
Ambas as declarações deixam margem para interpretação. O formulário nunca define o que são “cadeias de suprimento de código-fonte confiáveis” ou “processos comparáveis”, nem especifica até que ponto a proveniência é considerada viável. Cada produtor precisa determinar o que esses termos significam para seu próprio software, e o signatário atesta o resultado apenas de acordo com o melhor de seu conhecimento.
Elas também dependem do conhecimento sobre qual código de terceiros uma compilação contém, e o formulário deixa a escolha do método a cargo do produtor. Um produtor que não consiga listar esse código não tem como saber se ele atende a qualquer um dos dois critérios.
A Seção III também não menciona nada sobre componentes cuja manutenção no upstream tenha sido encerrada. A Declaração 4 ainda exige uma política ou processo para lidar com vulnerabilidades descobertas antes do lançamento. Para um componente cujos mantenedores tenham parado de disponibilizar correções, essa política não pode contar com um lançamento do upstream. Isso deixa opções como substituir o componente ou aplicar patches à versão em uso, seja internamente ou por meio de um fornecedor que faça o backport de correções.
O que vem depois da assinatura
A assinatura do formulário dá início a compromissos que se estendem além da data da assinatura. A Seção III inclui uma declaração de que o fabricante notificará qualquer órgão que tenha recebido o formulário “se e quando” deixar de utilizar as práticas de forma consistente. Uma nota de rodapé acrescenta que essa declaração vincula as versões futuras do produto mencionado até que o produtor informe às agências que suas práticas de desenvolvimento não estão mais em conformidade. A promessa de notificação é do produtor para as agências, e o formulário não especifica como a notícia de um descumprimento chega ao signatário. É provável que as equipes responsáveis pela aplicação das práticas sejam as primeiras a perceber um descumprimento. O produtor precisa de um processo para que essas equipes comuniquem o descumprimento ao signatário.
A declaração relativa à Lei de Privacidade constante do formulário, redigida para o Departamento de Segurança Interna, enumera duas consequências. A não apresentação das informações solicitadas pode levar a agência a interromper o uso do software. O fornecimento deliberado de informações falsas ou enganosas pode constituir violação de uma lei penal federal, 18 U.S.C. § 1001.
Observação: Cada órgão que utiliza o formulário deve fornecer sua própria declaração relativa à Lei de Privacidade; portanto, o texto sobre as consequências exibido ao signatário pode variar de acordo com o órgão.
Um signatário que deseje que a certificação permaneça precisa deve verificar, antes de assinar, quais equipes atestam cada prática, como o produtor definiu termos como “processos comparáveis” e “viável” e como essas equipes irão relatar uma falha.
Sabendo o que entra nas suas compilações
O SecureChain da TuxCare analisa o código de cada pacote de código aberto em busca de malware oculto e recompila o pacote a partir do código-fonte em ambientes isolados e fortificados. Um pacote que não for aprovado na verificação é impedido de entrar no seu ambiente. Cada pacote que você recebe vem acompanhado de um SBOM listando seu conteúdo e um registro de proveniência. Enquanto o desenvolvedor original ainda mantiver o pacote, o SecureChain aplica patches nele sob um acordo de nível de serviço (SLA), e o Suporte de Ciclo de Vida Ilimitado (ELS) continua a fornecer correções após o término da manutenção pelo desenvolvedor original. O SecureChain abrange dependências de código aberto em JavaScript, Python, Java, Go e PHP.
Se sua equipe não consegue dizer o que há nas dependências de código aberto que entram em suas compilações, nem quem aplica os patches nelas quando o desenvolvimento original é interrompido, o SecureChain responde a ambas as perguntas.
Perguntas frequentes
O que é o Formulário de Atestado de Desenvolvimento Seguro de Software da CISA?
É o formulário que os produtores de software utilizam para atestar que seu software é desenvolvido em conformidade com as práticas derivadas da Estrutura de Desenvolvimento Seguro de Software (SSDF). A Agência de Segurança Cibernética e de Infraestrutura (CISA) divulgou o documento em 11 de março de 2024. Quando o fabricante realiza a autocertificação, o diretor executivo (CEO) ou um representante designado — que seja um funcionário com autoridade para vincular a empresa — assina o documento. O fabricante também pode anexar uma avaliação realizada por terceiros.
O Formulário de Atestado de Desenvolvimento Seguro de Software é opcional ou ainda é obrigatório?
Essa exigência não é mais válida para todo o governo. O memorando M-26-05 do Escritório de Gestão e Orçamento (OMB), datado de 23 de janeiro de 2026, revogou os memorandos M-22-18 (14 de setembro de 2022) e M-23-16 (9 de junho de 2023), que permitiam que os órgãos utilizassem o software abrangido somente após atestado do fabricante. Cada órgão decide agora se deseja utilizar o formulário; portanto, um órgão específico ainda pode solicitá-lo a você.
Quais softwares estão abrangidos pelo formulário?
As instruções abrangem softwares desenvolvidos após 14 de setembro de 2022 (data do memorando M-22-18 do OMB), softwares mais antigos que passaram por uma mudança significativa de versão após essa data e softwares cujo desenvolvedor realiza atualizações contínuas, como o software como serviço (SaaS). Essas regras tinham origem nos memorandos M-22-18 e M-23-16, que foram revogados pelo M-26-05; portanto, uma agência que solicitar o formulário agora pode definir seu próprio escopo. As instruções e os termos contratuais da agência solicitante são o local onde se deve verificar essas informações. A Seção I do formulário também lista quatro categorias que não são abrangidas pelo formulário, incluindo componentes de terceiros incorporados ao produto.
Como o formulário lida com componentes de terceiros e de código aberto?
A cobertura exclui componentes de código aberto e proprietários de terceiros incorporados ao produto. As instruções também indicam que os fabricantes que utilizam componentes de terceiros devem atestar ter tomado as medidas listadas na seção de atestado do formulário, Seção III, para minimizar os riscos decorrentes do uso desses componentes. Duas dessas medidas, relativas à segurança da cadeia de suprimentos e à proveniência, mencionam os componentes diretamente.
O que o formulário diz sobre informações falsas ou ausentes?
Sua declaração relativa à Lei de Privacidade, elaborada para o Departamento de Segurança Interna, afirma que a não apresentação das informações solicitadas pode levar a agência a interromper o uso do software. O fornecimento deliberado de informações falsas ou enganosas pode constituir violação do artigo 1001 do título 18 do Código dos Estados Unidos (18 U.S.C. § 1001), uma disposição penal. Cada agência que utiliza o formulário apresenta sua própria declaração relativa à Lei de Privacidade.
Uma avaliação realizada por terceiros pode substituir a assinatura?
Sim. Um produtor pode anexar uma avaliação realizada por uma Organização Avaliadora de Terceiros (3PAO) certificada pelo Programa Federal de Gestão de Riscos e Autorizações (FedRAMP) ou aprovada por escrito por um funcionário competente da agência. A 3PAO deve avaliar todos os elementos do formulário de acordo com as orientações relevantes do NIST. Em seguida, o produtor marca a caixa na Seção III, anexa a avaliação e não assina.
O que acontece com um certificado quando o software recebe uma nova versão?
Um atestado vincula as versões futuras do produto mencionado até que o fabricante notifique os órgãos de que suas práticas de desenvolvimento não estão mais em conformidade. Isso está de acordo com uma promessa contida na própria seção de assinatura, na qual o fabricante se compromete a notificar qualquer órgão que tenha recebido o formulário caso deixe de utilizar essas práticas de maneira consistente.
