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
- A Estrutura de Desenvolvimento Seguro de Software (SSDF) do NIST (Instituto Nacional de Padrões e Tecnologia) recomenda que você continue verificando os componentes de terceiros, incluindo os de código aberto, em relação aos seus próprios requisitos.
- Uma varredura de vulnerabilidades é apenas parte do processo de verificação, e os exemplos do SSDF também abrangem o status de manutenção e a integridade.
- No código aberto, geralmente não há um fornecedor obrigado a comprovar que um componente atende aos seus requisitos; portanto, cabe à sua equipe reunir essas evidências.
- Essas evidências incluem a proveniência, ou seja, um registro da origem e das alterações de cada componente. Uma lista de componentes, por si só, não é suficiente para capturar essas informações.
- A verificação resume-se a quatro decisões: requisitos, evidências, medidas de segurança antes da construção e um plano para componentes sem manutenção. Comece pelos requisitos.
Se um cliente perguntar como você verifica as bibliotecas de código aberto em seu produto, é provável que a Estrutura de Desenvolvimento de Software Seguro (SSDF) do NIST tenha influenciado essa pergunta. Uma de suas tarefas, a PW.4.4 do grupo “Produzir Software Bem Protegido”, exige que os produtores verifiquem os componentes de terceiros, incluindo os de código aberto, em relação aos requisitos que eles próprios definem.
Um relatório de verificação completo abrange as vulnerabilidades conhecidas, mas os exemplos do PW.4.4 também indicam se um componente ainda recebe manutenção e se é possível confirmar sua integridade. A tarefa em si não define o que significa “verificar”, não indica uma ferramenta específica nem especifica quais evidências devem ser mantidas.
Isso significa que cabe a você redigir os requisitos e apresentar a comprovação. E, no caso de componentes de código aberto, geralmente não há nenhum contrato por trás da biblioteca; portanto, nenhum fornecedor é obrigado a lhe entregar essa comprovação.
A situação atual do SSDF do NIST em 2026
O NIST publica o SSDF como Publicação Especial (SP) 800-218. A versão final atual é a “Estrutura de Desenvolvimento Seguro de Software (SSDF) Versão 1.1: Recomendações para Mitigar o Risco de Vulnerabilidades de Software”, de fevereiro de 2022. Ele classifica suas práticas em quatro grupos, cada um com um código de duas letras: Preparar a Organização (PO), Proteger o Software (PS), Produzir Software Bem Protegido (PW) e Responder a Vulnerabilidades (RV). Cada prática possui um ID, como PW.4, e suas tarefas recebem um número adicional, como PW.4.4.
A versão 1.1 foi elaborada para produtores e adquirentes de software e estabelece que organizações não governamentais podem utilizá-la voluntariamente. Ela descreve suas práticas como base para o planejamento baseado em riscos e esclarece que elas não se destinam a servir como uma lista de verificação. O NIST apresenta o SSDF como um vocabulário comum que os adquirentes podem utilizar com seus fornecedores; assim, um requisito geralmente chega até você por meio de uma política do comprador ou de um contrato que faça referência a ele.
Nota: O NIST divulgou uma versão preliminar pública da SP 800-218 Revisão 1, Estrutura de Desenvolvimento Seguro de Software (SSDF) Versão 1.2, em 17 de dezembro de 2025, em resposta ao Decreto Presidencial 14306. Em outubro de 2026, a versão 1.1 ainda era a versão final. A versão preliminar mantém a PW.4.4 e a tarefa de proveniência, PS.3.2, com a mesma numeração e redação, e acrescenta duas novas práticas, juntamente com um texto de exemplo, sob a PW.4.4. Este artigo segue a versão 1.1.
O que o PW.4.4 diz e o que ele deixa em aberto
A PW.4.4 solicita que os produtores verifiquem se os componentes de software adquiridos — comerciais, de código aberto e de terceiros — estão em conformidade com os requisitos definidos pela organização ao longo de seus ciclos de vida. Essa redação deixa a definição dos requisitos a cargo de você e menciona explicitamente os componentes de código aberto. Além disso, mantém a verificação em vigor enquanto você utilizar o componente, indo muito além de uma revisão única no momento da adoção.
Além disso, o NIST apresenta sete exemplos hipotéticos de implementação.
| Exemplo de PW.4.4 | O que está coberto | Base |
|---|---|---|
| Exemplos 1 e 2: verificar se há vulnerabilidades conhecidas publicamente que os fornecedores ainda não tenham corrigido, incluindo a detecção automática na cadeia de ferramentas | Falhas conhecidas no componente | SP 800-218, versão 1.1, conceitual |
| Exemplo 3: utilizar resultados já disponíveis de serviços comerciais de verificação | Resultados da avaliação externa | SP 800-218, versão 1.1, conceitual |
| Exemplo 4: confirmar se o componente ainda recebe manutenção ativa e não atingiu o fim da vida útil (EOL), incluindo a verificação de que as vulnerabilidades recém-descobertas estão sendo corrigidas | Status do suporte e correção de novas falhas | SP 800-218, versão 1.1, conceitual |
| Exemplo 5: elaborar um plano de ação para componentes que não recebem mais manutenção ou que em breve não estarão mais disponíveis | Sua resposta quando o suporte terminar | SP 800-218, versão 1.1, conceitual |
| Exemplo 6: confirmar a integridade por meio de assinaturas digitais ou outros mecanismos | Integridade do artefato | SP 800-218, versão 1.1, conceitual |
| Exemplo 7: revisar, analisar ou testar o código | O próprio código | SP 800-218, versão 1.1, conceitual |
A verificação de vulnerabilidades conhecidas abrange dois desses sete exemplos; portanto, um relatório de varredura, por si só, já responde a parte da tarefa. Uma varredura em busca de falhas conhecidas geralmente não indica se um artefato está intacto ou se alguém ainda mantém o componente, e os Exemplos 4 e 6 abordam essas questões.
A versão preliminar 1.2 do SSDF acrescenta um oitavo exemplo à seção PW.4.4: revisar regularmente as bibliotecas de terceiros para verificar se houve mudanças de propriedade e avaliar o impacto de cada mudança. Uma verificação de vulnerabilidades conhecidas geralmente não sinaliza uma mudança de propriedade; portanto, esse exemplo precisaria de uma verificação específica.
No caso de um componente sem manutenção, o plano de ação do Exemplo 5 geralmente assume uma das três formas a seguir: substituí-lo, aplicar um patch na versão que você utiliza ou aceitar o risco por escrito. A opção do meio significa que alguém precisa escrever e testar a correção, e essa pessoa é você, a menos que tenha combinado com outra pessoa para que ela o faça.
O código aberto muitas vezes não tem um fornecedor que possa apresentar provas
O PO.1.3, que trata das atribuições do SSDF no que diz respeito ao relacionamento com fornecedores, abrange a comunicação de requisitos a terceiros que fornecem componentes comerciais. Entre os exemplos citados estão a inclusão de requisitos nos contratos, a exigência de que os fornecedores atestem que seu software atende a esses requisitos e a exigência de dados de proveniência e mecanismos de verificação de integridade para todos os componentes de seu software.
O código-fonte aberto que você distribui se enquadra na PW.4.4, mas não na PO.1.3; portanto, o SSDF solicita que você o verifique sem que haja uma tarefa para definir termos com seus autores. Na prática, uma biblioteca geralmente vem sem contrato; portanto, normalmente não há uma contraparte obrigada a fornecer a você evidências de proveniência ou integridade. Alguém do seu lado precisa produzi-las ou coletá-las.
Suas necessidades vêm em primeiro lugar, e o PO.1.1 é o próprio ponto de partida do SSDF para defini-las. Seu segundo exemplo é definir políticas para proteger seus processos de desenvolvimento, incluindo aquelas relacionadas a componentes de código aberto e de terceiros. Defina-as antes de avaliar qualquer ferramenta. O PW.4.4 avalia os componentes em relação às suas necessidades, e as verificações padrão de uma ferramenta tendem a substituí-las caso você pule essa etapa.
Um breve documento de requisitos pode abordar quais atividades de manutenção são aceitáveis, o que ocorre quando um componente perde o suporte do fornecedor, quem aprova uma exceção e como a integridade é confirmada. O quinto exemplo do PO.1.3 descreve um processo para lidar com requisitos que um componente não atende, incluindo a revisão periódica das exceções aprovadas. É possível aplicar o mesmo processo a componentes de código aberto.
De acordo com o SSDF: PW.4.1, a tarefa do SSDF para aquisição de componentes inclui dois exemplos que descrevem medidas que sua equipe pode tomar sem recorrer a um fornecedor. Uma delas é obter informações de proveniência, como uma lista de materiais de software (SBOM) ou uma análise de composição, para cada componente. A outra é hospedar componentes de código aberto aprovados e verificados em um ou mais repositórios.
Sem um fornecedor intermediário, geralmente não há nada entre o lançamento do mantenedor e sua compilação, a menos que você adote uma medida de segurança. As opções incluem confirmar as assinaturas quando os editores as fornecem, recompilar a partir do código-fonte ou filtrar o que chega antes que chegue ao seu ambiente de compilação. Os exemplos ilustrativos do SSDF mencionam alguns deles, incluindo assinaturas na PW.4.4 e a compilação a partir do código-fonte na PW.4.1.
A proveniência, conforme a norma PS.3.2, é mais do que uma lista de componentes
A norma PS.3.2 faz parte do grupo “Protect the Software” do SSDF. Ela solicita que os produtores coletem, protejam, mantenham e compartilhem dados de proveniência para todos os componentes de cada versão, e cita a SBOM como um exemplo de onde esses dados podem ser armazenados. No caso de componentes de código aberto, geralmente não há nenhum fornecedor obrigado a fornecer esses dados a você.
O NIST define proveniência, com base na Publicação Especial 800-53, como a cronologia da origem, desenvolvimento, propriedade, localização e alterações de um componente. Segundo essa definição, uma lista de nomes e versões indica o que está incluído em uma versão, enquanto a cronologia indica de onde cada elemento veio e o que aconteceu com ele. Uma lista de componentes não inclui automaticamente essa segunda informação; portanto, verifique se a sua SBOM registra esse histórico ou apenas a lista.
Os exemplos apresentados na seção PS.3.2 incluem o compartilhamento dos dados com adquirentes e com suas próprias equipes de resposta, a proteção de sua integridade para que os destinatários possam verificá-los e a atualização dos dados sempre que um componente for atualizado. A seção PS.3.2 menciona “todos os componentes” e não utiliza a palavra “transitivo”. Aplicá-la a dependências que você nunca escolheu diretamente é uma inferência, mas que decorre da palavra “todos”. Decida se as dependências transitivas estão no escopo com base em seus requisitos e registre a decisão.
Outros dois termos surgem em conjunto com as SBOMs. O SLSA (Níveis da Cadeia de Suprimentos para Artefatos de Software) é uma especificação separada de segurança da cadeia de suprimentos, e seu Nível de Compilação 3 descreve uma plataforma de compilação reforçada que protege contra adulterações durante a compilação. Os documentos VEX (Vulnerability Exploitability eXchange), conforme descritos pela Agência de Segurança Cibernética e de Infraestrutura (CISA), indicam o status de um produto em relação a uma determinada vulnerabilidade, como afetado, não afetado ou corrigido. Ambos fornecem evidências para as tarefas do SSDF. A proveniência do SLSA registra quem compilou um pacote, com qual processo e a partir de quais entradas, o que faz parte do histórico que a seção PS.3.2 exige que você mantenha. Um registro VEX mostra se uma vulnerabilidade conhecida afeta um componente, que é o que o primeiro exemplo da PW.4.4 solicita.
O que o Formulário de Atestado Federal perguntava sobre os componentes
Os compradores federais costumavam solicitar informações diretamente sobre componentes de terceiros. De acordo com os memorandos M-22-18 e M-23-16 do Escritório de Gestão e Orçamento (OMB), as agências eram obrigadas a obter atestados dos fabricantes de software, e a CISA e o OMB divulgaram o Formulário de Atestado de Desenvolvimento Seguro de Software para esse fim em 11 de março de 2024.
A Seção III do formulário exige que os produtores atestem um esforço de boa-fé para manter cadeias de suprimento confiáveis de código-fonte, utilizando ferramentas automatizadas ou processos equivalentes que garantam a segurança de componentes de terceiros e gerenciem as vulnerabilidades relacionadas. Além disso, exige que atestem a manutenção da proveniência dos componentes de terceiros “na medida do possível”. O apêndice do formulário relaciona esses itens às tarefas do SSDF, que incluem PW.4.4 e PS.3.2.
O formulário não abrange os componentes de código aberto e proprietários de terceiros incorporados ao produto utilizado pela agência. No entanto, os produtores que utilizam esses componentes ainda assim atestam que tomaram as medidas previstas na Seção III para reduzir o risco de depender deles.
Em 23 de janeiro de 2026, o memorando M-26-05 do OMB revogou os memorandos M-22-18 e M-23-16. As agências ainda podem utilizar o formulário e exigir SBOMs por meio de contrato, e o memorando cita a norma SP 800-218 como referência que elas podem utilizar. Ele afirma que “não existe um método universal e único” para proteger o software e o hardware utilizados pelas agências, deixando a cargo de cada agência a definição de políticas de garantia que se adequem ao seu perfil de risco.
| Documento | O que diz | Situação atual | Base |
|---|---|---|---|
| SP 800-218, versão 1.1 | Define PW.4.4 e PS.3.2 | Final, fevereiro de 2022 | Orientações do NIST |
| SP 800-218 Revisão 1 – versão preliminar (SSDF 1.2) | Mantém ambas as tarefas e adiciona material novo | Versão preliminar para divulgação pública | Versão preliminar das orientações do NIST |
| OMB M-22-18 e M-23-16 | Exigiu que os órgãos obtivessem atestados | Revogado em 23 de janeiro de 2026 | Política do OMB |
| Formulário de atestado | Os produtores atestam a adoção de práticas inspiradas no SSDF | Opcional para agências | Formulário da agência (CISA e OMB) |
| OMB M-26-05 | As agências definem suas próprias políticas de garantia | Atual | Política do OMB |
Com a revogação das normas M-22-18 e M-23-16, o fato de um comprador perguntar como você verifica os componentes ou rastreia sua proveniência depende da política e do contrato desse comprador.
Decidir o que a verificação significa para suas dependências
Na prática, a verificação se resume a quatro decisões: quais requisitos um componente deve atender, quais provas você mantém, o que se interpõe entre um lançamento do upstream e sua compilação, e o que você faz quando um mantenedor do upstream deixa de oferecer suporte a esse componente. As duas primeiras são questões de política que somente sua equipe pode definir. Nas duas últimas, as ferramentas podem assumir o trabalho repetitivo.
O SecureChain da TuxCare atua entre as versões do projeto original e sua compilação. Ele analisa o código-fonte de pacotes de código aberto em busca de malware e padrões suspeitos, recompila os pacotes a partir desse código-fonte em ambientes isolados e reforçados de segurança e continua a aplicar correções a eles sob um acordo de nível de serviço enquanto o projeto original estiver ativo. O Suporte de Ciclo de Vida Ilimitado (ELS) continua a fornecer correções após o término da manutenção do projeto original, abrangendo a opção “aplicar a correção à versão que você executa” descrita anteriormente. A cobertura abrange JavaScript, Python, Java, Go, Rust e PHP. A TuxCare também fornece SBOMs, registros VEX e proveniência SLSA Nível 3 para cada pacote.
Se você está decidindo como lidar com pacotes de código aberto que não passam por verificação ou não recebem manutenção, pergunte-nos o que o SecureChain abrange.
Perguntas frequentes
O que é o SSDF do NIST?
O NIST SSDF é a Estrutura de Desenvolvimento Seguro de Software (Secure Software Development Framework), publicada pelo NIST, a agência de padronização dos Estados Unidos, como Publicação Especial (SP) 800-218. Ela agrupa as práticas de desenvolvimento seguro nas seguintes categorias: Preparar a Organização, Proteger o Software, Produzir Software Bem Protegido e Responder a Vulnerabilidades. A versão final atual é a 1.1, de fevereiro de 2022.
A quem se destina o SSDF do NIST?
Os produtores de software, como fornecedores comerciais e equipes de desenvolvimento internas, e os adquirentes de software, incluindo órgãos federais e outras organizações, são os dois principais públicos-alvo. O NIST, a agência de padronização dos EUA, afirma que organizações não governamentais podem utilizar a Estrutura de Desenvolvimento Seguro de Software (SSDF) de forma voluntária. Uma empresa que desenvolva produtos com base em componentes de código aberto é considerada um produtor.
O SSDF abrange software de código aberto?
Em parte. Na Estrutura de Desenvolvimento Seguro de Software (SSDF), tanto a tarefa de verificação de componentes de terceiros (PW.4.4) quanto a tarefa de aquisição desses componentes (PW.4.1) mencionam componentes de código aberto. A tarefa de comunicar requisitos aos fornecedores (PO.1.3) menciona apenas componentes comerciais. O NIST (a agência de padronização dos EUA) lista uma linha de base do SSDF para software de código aberto entre as ações que está considerando, mas, até outubro de 2026, ainda não havia publicado nenhuma.
O que são exemplos hipotéticos de implementação no SSDF?
Na Estrutura de Desenvolvimento Seguro de Software (SSDF), os exemplos de implementação hipotéticos são ferramentas, processos ou métodos ilustrativos que poderiam ajudar na execução de uma tarefa. O NIST, órgão norte-americano de padronização, afirma que nenhum exemplo ou combinação é obrigatória e que esses não são as únicas opções.
O NIST certifica alguma coisa no âmbito do SSDF?
O NIST, agência de padronização dos Estados Unidos, publica a Estrutura de Desenvolvimento Seguro de Software (SSDF) como orientação, e seus materiais sobre a SSDF não descrevem nenhum programa de certificação. O formulário de atestado federal aceita tanto o autoatestado do produtor quanto uma avaliação realizada por terceiros, e o Escritório de Gestão e Orçamento (OMB) não exige mais o preenchimento desse formulário em todo o governo.
