NIST SSDF (SP 800-218)

Os quatro grupos de práticas

O SSDF organiza as suas práticas em quatro grupos. Cada prática enuncia um resultado, e o NIST é explícito ao afirmar que não é uma lista de verificação: é uma base para um planeamento assente no risco.

Grupo	Objetivo	Exemplos
Prepare the Organization (PO)	Pessoas, processos e ferramentas estão preparados	Definir requisitos de segurança, atribuir funções, proteger o ambiente de desenvolvimento
Protect the Software (PS)	O código e as versões estão a salvo de adulteração	Proteger todas as formas de código, verificar a integridade das versões, arquivar cada versão
Produce Well-Secured Software (PW)	Poucas vulnerabilidades no que lança	Conceber a pensar na segurança, reutilizar software bem protegido, rever e testar o código
Respond to Vulnerabilities (RV)	Encontrar as falhas restantes e tratá-las	Identificar vulnerabilidades continuamente, priorizá-las e corrigi-las, analisar as causas raiz

As práticas que envolvem a sua cadeia de abastecimento

• PO.3, cadeias de ferramentas de apoio, e PO.5, ambientes seguros. O seu sistema de CI faz parte do que tem de proteger. Consulte a lista de verificação de segurança de pipelines de CI/CD.
• PS.3, arquivar e proteger cada versão. Isto inclui recolher dados de proveniência dos componentes de cada versão, e o SSDF indica a SBOM como uma forma de o fazer.
• PW.4, reutilizar software bem protegido. Os componentes de terceiros devem ser avaliados e mantidos atualizados, e é aqui que entra a análise de composição de software.
• RV.1, identificar vulnerabilidades de forma contínua. É um dever contínuo, não um controlo de lançamento, pelo que exige a monitorização do que já distribuiu.
• RV.2, avaliar, priorizar e corrigir. Consulte como priorizar vulnerabilidades.

O SSDF é obrigatório?

Por si só, não. É uma publicação do NIST, não uma lei. Durante alguns anos teve importância direta para os fornecedores federais dos EUA, porque os memorandos M-22-18 e M-23-16 do OMB os obrigavam a atestar práticas dele retiradas. Isso mudou a 23 de janeiro de 2026: o memorando M-26-05 do OMB revogou ambos e adotou uma abordagem baseada no risco. As agências podem continuar a usar o formulário comum de atestação e as normas do NIST, mas já não são obrigadas a fazê-lo, pelo que os fornecedores devem contar com requisitos que variam de agência para agência.

Fora da contratação pública federal, o SSDF continua a ser útil como linguagem comum. Os clientes inspiram-se nele nos seus questionários de segurança, e tem correspondência com outras normas.

Versões do SSDF

• A versão 1.1, SP 800-218, publicada em fevereiro de 2022, é a versão final atual.
• A versão 1.2, SP 800-218 Revision 1, foi publicada como rascunho em dezembro de 2025.
• O SP 800-218A é um perfil comunitário que alarga o SSDF à IA generativa e aos modelos de base de dupla utilização.

Como adotar o SSDF

1. Mapeie o que faz hoje. Percorra as práticas e registe onde já as cumpre e com que evidências.
2. Ordene as lacunas por risco. O SSDF espera que o aplique de acordo com o seu próprio risco, pelo que nem todas as práticas merecem a mesma profundidade.
3. Automatize as evidências. As evidências que saem do pipeline mantêm-se atuais sem trabalho adicional. As evidências escritas à mão ficam desatualizadas.
4. Atribua responsáveis. Cada prática precisa de alguém responsável. A maioria ficará com a engenharia e não com a segurança.
5. Reveja a intervalos definidos. Atualize o mapeamento à medida que as suas ferramentas mudam e que a versão 1.2 avança.

SSDF, SLSA e CRA

O SSDF diz o que um programa de desenvolvimento seguro deve alcançar. O SLSA aprofunda uma parte dele, a integridade do build. O Cyber Resilience Act da UE é uma lei com obrigações próprias. O trabalho feito para um transita para os outros, porque todos esperam que saiba o que está no seu software e que trate as vulnerabilidades nele presentes.

Onde se enquadra o CRACI

O SSDF é um programa amplo e nenhuma ferramenta o cobre. O CRACI fornece evidências para as práticas que dependem do build e do que foi distribuído: SBOM de cada job de GitHub Actions, jobs isolados e controlo de egress no ambiente de build, monitorização contínua do software distribuído e triagem do que encontra. O CRACI não torna a sua empresa conforme, e o mapeamento e a atestação continuam a ser da sua responsabilidade. Consulte segurança da cadeia de abastecimento de software com o CRACI.

NIST SSDF: perguntas frequentes

O que é o NIST SSDF?

O Secure Software Development Framework, publicado como NIST SP 800-218. É um conjunto de práticas para desenvolver software seguro, organizado em quatro grupos: preparar a organização, proteger o software, produzir software bem protegido e responder a vulnerabilidades.

O que significa SSDF?

Secure Software Development Framework.

O SSDF é obrigatório?

Não. São orientações, não uma lei. Os fornecedores federais dos EUA tinham de atestar práticas dele retiradas, mas o memorando M-26-05 do OMB revogou essa exigência em janeiro de 2026. As agências podem ainda pedir atestações.

Qual é a versão mais recente do SSDF?

A versão 1.1 (SP 800-218, fevereiro de 2022) é a versão final atual. A versão 1.2 foi publicada como rascunho em dezembro de 2025, pelo que deve consultar o site do NIST para saber o seu estado.

Qual é a diferença entre o SSDF e o SLSA?

O SSDF cobre o desenvolvimento seguro como um todo, abrangendo pessoas, processos e tecnologia. O SLSA aprofunda a integridade do build e a proveniência. Funcionam bem em conjunto.

O SSDF exige uma SBOM?

Pede que recolha e partilhe dados de proveniência dos componentes de cada versão e indica a SBOM como uma forma de o fazer. Descreve resultados em vez de impor uma ferramenta específica.