Resumen

  • OSPS Baseline admite la autoatestación de los proyectos y considera la conformidad un estado observado en una fecha, frente a una versión y un nivel de madurez concretos.
  • La afirmación duradera une alcance, versión, nivel, fecha, responsable, evidencia por control, excepciones y condición de reevaluación, sin presentarse como certificación ni como seguridad de cada entrega.

Análisis

Un equipo de riesgos abre su registro de software. Junto a una biblioteca aparece un campo verde: «OSPS compliant». Parece responder una pregunta, pero en realidad ha borrado varias. No muestra qué edición del Baseline se leyó, qué nivel se aplicó, cuándo terminó la revisión, qué repositorios y entregas entraron en el alcance ni quién tenía autoridad para declarar el resultado.

El propio OSPS Baseline ofrece la forma de reparar esa pérdida. Su índice identifica v2026.08.28 como la versión vigente para nuevas evaluaciones, conserva las anteriores como referencia histórica y separa el texto en desarrollo. La FAQ permite que el proyecto declare su propia conformidad, la califica como un estado en un momento determinado y propone nombrar la fecha, la versión y el nivel.

La versión congela la pregunta

El proceso de mantenimiento usa identificadores de calendario YYYY-MM-DD. Los cambios sustantivos de significado reciben un identificador de control nuevo, mientras que una alteración menor —incluso el traslado de un control a otro nivel— puede conservar el mismo código. Por eso el código del control aislado no basta para reconstruir la obligación que se evaluó. La versión completa es parte de la evidencia.

El nivel decide qué controles entran. En 2026.08.28, el nivel 1 se dirige a cualquier proyecto, tenga o no código; el nivel 2, a proyectos de código con al menos dos mantenedores y pocos usuarios constantes; el nivel 3, a proyectos con muchos usuarios constantes. Decir simplemente «cumple el Baseline» oculta la selección que dio forma al examen.

La fecha limita la vigencia de la observación. Un repositorio puede cambiar de administradores, reglas de rama, secretos, canal oficial, política de vulnerabilidades o proceso de publicación. Un manifiesto firmado de una versión no cubre automáticamente la siguiente. La fecha impide que una fotografía antigua se convierta, por repetición, en una descripción del presente.

Y el alcance convierte las tres coordenadas en una afirmación comprobable. El nombre de un proyecto puede abarcar el repositorio principal, complementos, documentación, infraestructura de compilación, un registro de paquetes y distintas ramas mantenidas. Los controles hablan de sujetos diferentes —el proyecto, el repositorio autoritativo, el sistema de versiones, el pipeline o una entrega oficial— y la prueba debe referirse al sujeto correcto.

Lo privado no es invisible por definición

La autoatestación no es una auditoría externa, pero tampoco es un gesto vacío. Permite describir configuraciones privilegiadas que un observador público no puede consultar. La FAQ diferencia controles visibles desde fuera de otros que dependen de ajustes reservados, y deja al consumidor la opción de aceptar la declaración o acordar una verificación adicional.

El registro debe nombrar al declarante y separar las clases de evidencia. Una política de seguridad, una guía de contribución o un historial pueden ser públicos. La configuración de permisos puede revisarse bajo una obligación de confidencialidad. La palabra «verificado» solo es informativa si identifica persona u organización, método, objeto y fecha. La ausencia de una URL pública no debe contarse automáticamente como éxito ni como incumplimiento.

Las correspondencias con otros marcos tienen una frontera equivalente. La versión 2026.08.28 dice que son referencias, que no garantizan coincidencia completa y que no crean una conexión funcional. La FAQ niega que demuestren conformidad con esos catálogos o sustituyan auditorías y certificaciones. Una tabla no puede otorgar por asociación una conformidad NIST, ISO o regulatoria.

Del rótulo al recibo

El recibo mínimo identifica el proyecto canónico, repositorios, subproyectos y entregas cubiertos; versión y nivel OSPS; fecha de evaluación; declarante y autoridad; inventario de controles aplicables; evidencia y hora de observación para cada uno; frontera pública o restringida; excepciones y razones de no aplicabilidad; y fecha o cambio que obliga a revisar.

La utilidad está precisamente en su modestia. El recibo no promete software sin vulnerabilidades, no aprueba una dependencia, no certifica un binario y no anticipa el resultado de un despliegue. Permite saber qué se afirmó, contra qué texto y sobre qué superficie.

Así quedan separadas las responsabilidades. Los mantenedores del Baseline publican criterios versionados. Un proyecto describe sus prácticas. Un tercero puede revisar determinadas pruebas. El propietario del producto conserva la decisión sobre una versión y un uso concretos. El lenguaje común coordina; no roba autoridad.

La celda verde puede sobrevivir, pero como enlace: «OSPS v2026.08.28, nivel 2, evaluado 2026-09-07». Detrás queda el recibo. Lo breve pasa a ser una vista de una evidencia completa y no un reemplazo de ella.

Fuentes

  1. Índice de versiones de OSPS Baseline
  2. OSPS Baseline, versión 2026.08.28
  3. Preguntas frecuentes de OSPS Baseline
  4. Proceso de mantenimiento de OSPS Baseline
  5. Gobernanza del proyecto OSPS Baseline