Resumo

  • O OSPS Baseline aceita autoatestação pelo projeto e define conformidade como condição pontual vinculada a uma versão e a um nível de maturidade.
  • Uma alegação auditável registra escopo, versão, nível, data, responsável, evidência por controle, exceções e gatilho de reavaliação sem se vender como certificação ou garantia de cada release.

Análise

Uma planilha de componentes exibe uma célula verde: “OSPS compliant”. O campo pode alimentar um painel ou uma decisão de compra, mas não diz qual edição foi aplicada, qual nível foi escolhido, quando a verificação terminou, quem fez a declaração e quais repositórios, pipelines ou artefatos entraram no exame.

As fontes oficiais fornecem essas coordenadas. O índice do OSPS Baseline marca v2026.08.28 como versão atual para novos esforços de conformidade, mantém edições anteriores para consulta histórica e separa o texto em desenvolvimento. A FAQ permite que projetos se autoatestem, chama a conformidade de estado em um ponto do tempo e recomenda declarar data, versão e nível.

A versão preserva o significado

O processo de manutenção adota identificadores de calendário no formato YYYY-MM-DD. Alterações substanciais de sentido geram novo identificador de controle; alterações menores, inclusive a mudança de nível, podem manter o código. Assim, guardar apenas OSPS-… não reconstrói sempre a obrigação que existia durante a avaliação. É preciso fixar a versão.

O nível seleciona o conjunto aplicável. Na edição 2026.08.28, o nível 1 alcança qualquer projeto de código ou não; o nível 2 corresponde a um projeto de código com pelo menos dois mantenedores e poucos usuários consistentes; o nível 3, a um projeto com muitos usuários consistentes. “Atende ao Baseline” sem nível apaga a fronteira de maturidade.

A data limita a vida da evidência. Colaboradores, proteções de branch, canais de distribuição, contatos e processos de release mudam. Um manifesto assinado pode cobrir um release sem dizer nada sobre o seguinte. A fotografia antiga não vira fato presente só porque a célula continua verde.

O escopo completa a declaração. Um nome pode reunir repositório principal, subprojetos, documentação, registro de pacotes, infraestrutura de build e linhas de manutenção. Os controles usam sujeitos diversos: projeto, repositório autoritativo, controle de versão, pipeline ou release oficial. A evidência precisa seguir o sujeito e não substituir o todo pela parte mais visível.

Autoatestação é uma fronteira de divulgação

Autoatestação não equivale a auditoria independente, mas permite expor práticas que um scanner público não enxerga. A FAQ reconhece controles publicamente observáveis e outros ligados a configurações privilegiadas. O usuário upstream pode aceitar a declaração ou combinar verificação alternativa.

O registro deve identificar o atestante e a visibilidade da prova. Política de segurança, histórico e manifesto podem ser públicos. Permissões sensíveis podem ser examinadas sob confidencialidade por fundação, patrocinador ou cliente. “Verificado” só informa quando registra quem verificou, por qual método, qual objeto e em que data. Falta de URL pública não é aprovação nem reprovação automática.

Crosswalks também têm limite. A versão 2026.08.28 os trata como referências, sem garantir correspondência integral ou conexão funcional. A FAQ afirma que eles não demonstram conformidade com catálogos externos nem substituem auditoria ou certificação. Uma junção de planilha não produz conformidade NIST, ISO ou regulatória.

Um recibo curto, não um selo absoluto

O recibo reúne nome canônico, repositórios, subprojetos e releases cobertos; versão e nível; data; atestante e autoridade; controles aplicáveis; prova e horário de observação por controle; limite público ou restrito; exceções, não aplicabilidades e condição de nova análise.

Ele não promete ausência de vulnerabilidades, não aprova dependência, não certifica binário e não prevê implantação. Faz algo mais contido: permite descobrir o que foi afirmado, diante de qual texto, sobre qual superfície e até quando.

Os mantenedores do Baseline publicam a linguagem comum. O projeto descreve seu estado. Um terceiro pode revisar provas. O dono do produto decide sobre versão e uso concretos. Coordenação não precisa transferir essas autoridades.

A célula verde deve virar link: “OSPS v2026.08.28, nível 2, avaliado em 2026-09-07”. A concisão passa a representar o registro completo, sem substituí-lo.

Fontes

  1. Índice de versões do OSPS Baseline
  2. OSPS Baseline versão 2026.08.28
  3. FAQ do OSPS Baseline
  4. Processo de manutenção do OSPS Baseline
  5. Governança do projeto OSPS Baseline