Un comprador federal solicitó una certificación de software. ¿Qué versión cubre?
Únase a la solicitud federal, certificación CISA, versión del producto y evidencia de publicación antes de analizar el alcance del trabajo de garantía de software seguro.
Señales que conviene observar
- Un comprador federal o contratista principal nombra un producto de software y solicita una certificación de software seguro CISA actual antes de un evento de lanzamiento o adjudicación.
- El productor tiene una política corporativa de desarrollo seguro, pero no puede asignar el alcance de la certificación al producto exacto y a la versión que se entrega.
- Una agencia solicita por separado un SBOM, evaluación u otro artefacto y el registro de ventas lo trata incorrectamente como parte del formulario de certificación.
Una solicitud federal para una certificación de software seguro solo tiene alcance cuando se puede unir a una agencia solicitante, un productor, un producto o línea de productos y la autorización que se entrega. Una política corporativa de desarrollo seguro, una lista de materiales de software (SBOM) o un formulario antiguo para otro producto no se unen. En agosto de 2026, la política de aseguramiento actual de la agencia y el lenguaje del contrato también importan: CISA dice que las agencias pueden usar el formulario común en lugar de presentarlo como un requisito automático para cada compra.
Esa respuesta es importante para los grupos Telegram de garantía de seguridad, contratistas federales autorizados, proveedores de software y líderes de desarrollo empresarial de un proveedor de garantía de la cadena de suministro de software. El útil Signal no es “se necesita certificación federal”. Es un producto con nombre, un comprador o principal con nombre, un límite de versión no resuelto y un lanzamiento, propuesta o evento de aceptación con fecha. Verlo mañana puede ser demasiado tarde para unirse a la reunión donde ingeniería, el departamento legal y el firmante autorizado del productor deciden qué cubre la declaración.
El formulario es una declaración sobre la práctica de desarrollo, no un certificado de autorización.
El Página del formulario de certificación de desarrollo de software seguro CISA dice que el formulario se basa en la publicación especial 800-218 del Instituto Nacional de Estándares y Tecnología, el marco de desarrollo de software seguro (SSDF) versión 1.1. El forma común permite a un productor identificar el software cubierto y dar fe de las prácticas de desarrollo seguro enumeradas o identificar prácticas para las que no puede dar fe.
El formulario no certifica que una versión no tenga vulnerabilidad. No convierte a CISA en el evaluador del producto. Tampoco contiene todos los artefactos que una agencia podría solicitar. La declaración, el alcance del producto y cualquier evidencia de respaldo deben permanecer como objetos separados en el registro de ventas.
La historia de las políticas explica por qué los mensajes antiguos pueden inducir a error. OMB M-22-18, emitido el 14 de septiembre de 2022, ordenó a las agencias que obtuvieran una autocertificación para software específico y basó ese trabajo en prácticas de desarrollo seguro NIST. M-23-16, emitido el 9 de junio de 2023, actualizó el cronograma de implementación y el proceso de formulario común. La página actual de CISA ahora apunta a OMB M-26-05: las agencias deben mantener inventarios de software y hardware y establecer políticas de aseguramiento alineadas con el riesgo y la misión; ellos mayo utilizan recursos creados bajo M-22-18, incluido el formulario, y pueden contratar un SBOM actual.
La regla práctica para las ventas es simple: fechar la solicitud. Un memorando de 2023 explica el origen del formulario. La política actual de la agencia, la solicitud, la cláusula del contrato o la instrucción de aceptación determinan lo que el comprador pide ahora.
Cree la unión de atestación a liberación
Utilice un registro corto con seis campos. Es más pequeña que una lista de verificación de evaluación porque su propósito es localizar la tarea comercial, no realizar la revisión de aseguramiento.
- Solicitante: agencia, oficina de contratación o contratista principal, más la fuente de la solicitud.
- Productor: la entidad legal responsable del software, no simplemente el revendedor que envía el archivo.
- Software cubierto: producto o línea de productos como se indica en el formulario.
- Lanzamiento: versión exacta, compilación, imagen de entrega o familia de lanzamiento que recibirá el comprador.
- Declaración: fecha del formulario, que acredite al individuo y las prácticas de las que el productor da fe o no da fe.
- Artefactos separados: SBOM, informe de vulnerabilidad, evaluación de terceros, plan de acción u otro elemento expresamente solicitado fuera del formulario.
El cuarto campo es la contribución original de este artículo. La forma común puede cubrir un producto o línea de productos, mientras que las adquisiciones y la ingeniería operan sobre lanzamientos. Unir esas capas evita que un formulario que parezca válido se adjunte a una versión que nunca admitió.
Por ejemplo, un documento de política puede decir que la empresa revisa el código fuente y protege los entornos de compilación. Esos son antecedentes útiles. No establece qué repositorio, servicio de compilación, identidad de firma o rama de lanzamiento produjo la aplicación entregada a una agencia. Por el contrario, un SBOM específico de la versión enumera los componentes pero no certifica que el productor sigue todas las prácticas mencionadas en el formulario.
Ejemplo: tres archivos, todavía no hay una versión cubierta
Considere este compuesto ilustrativo, no un mensaje de cliente:
“Prime necesita la certificación CISA antes del corte de imagen del viernes. Tenemos el formulario del año pasado y un SBOM de 4.8. Legal dice que la política no ha cambiado. ¿Es eso suficiente?”
El fragmento contiene una solicitud de contratista principal, un evento del viernes, un formulario anterior y un SBOM para la versión 4.8. No identifica la agencia, el nombre del producto en el formulario anterior, el lanzamiento previsto para el viernes, el firmante, si la solicitud actual todavía utiliza el formulario común o si SBOM corresponde a la imagen de entrega.
No respondas sí o no del grupo. Escribe la unión con espacios en blanco:
Solicitante: nombrado principal, agencia no confirmada; productor: entidad jurídica no confirmada; software cubierto en formato anterior: aún no leído; autorización de entrega: sin confirmar; fecha de la declaración y firmante: aún no verificado; Artefacto separado: SBOM etiquetado como 4.8, se desconoce la relación con la imagen del viernes.
Ahora la ruta de servicio se hace visible. Si el formulario anterior cubre la misma línea de productos pero el propietario de la evidencia no puede conectarlo con la nueva versión, el trabajo puede ser un mapeo de publicación-evidencia. Si el productor no puede hacer una de las declaraciones, la forma común incluye un camino para identificar esa brecha en lugar de ocultarla. Si el único elemento que falta es un SBOM solicitado por la agencia para la imagen final, dirija la solicitud a la producción o validación del inventario de componentes, no a “renovar un certificado”.
Solicitar pruebas sin recopilar secretos en un grupo público
Una primera conversación necesita el texto de la solicitud, el alcance del formulario y el identificador de la versión. No necesita código fuente, credenciales, detalles de vulnerabilidad ni registros privados de un cliente federal en Telegram. Trasladar las pruebas permitidas al canal autorizado del comprador y registrar quién puede inspeccionarlas.
Las preguntas de seguimiento útiles son concretas:
- ¿Qué agencia o principal envió la solicitud y dónde está la instrucción actual?
- ¿Qué nombre del productor y producto o línea de productos aparecen en el formulario propuesto?
- ¿Qué versión o imagen de entrega se acepta y cuándo se toma la decisión?
- ¿Quién está autorizado a dar fe en nombre del productor?
- ¿Qué declaraciones necesitan una revisión de respaldo y cuáles no se pueden hacer actualmente?
- ¿Se requiere por contrato un SBOM o una evaluación por separado y para qué versión?
Cuando el problema sea evidencia de control de sucursales en lugar del formulario federal, use el registro de evidencia de riesgo de proveedor de protección de sucursales. Para el problema adyacente de probar qué dependencias ingresaron a una versión, use archivo de bloqueo de dependencia registro de evidencia de riesgo de proveedor.
TOP Prospect puede filtrar y combinar fragmentos incompletos de grupos Telegram a los que un usuario se conecta deliberadamente y está autorizado a acceder. Puede preservar la fuente y el tiempo, eliminar duplicados obvios y explicar por qué la versión del nombre de un producto, “formulario CISA”, y la versión del viernes aparecieron juntas. No puede leer repositorios privados, determinar la política de la agencia, firmar una certificación, auditar las prácticas SSDF, contactar a los participantes ni prometer aceptación. Opciones de precios y acceso describe la capa de descubrimiento, no una opinión de garantía.
Hechos clave
- CISA dice que el formulario común se basa en NIST SP 800-218, SSDF versión 1.1.
- El formulario común identifica al productor, el software cubierto o la línea de productos y al individuo que lo certifica.
- M-22-18 creó la dirección federal de autocertificación en septiembre de 2022; Implementación actualizada del M-23-16 en junio de 2023.
- La página de CISA, consultada el 14 de agosto de 2026, dice que las agencias pueden usar el formulario según sus políticas de garantía basada en riesgos y pueden solicitar por separado un SBOM actual.
- Un SBOM es un inventario de componentes; no es la certificación de desarrollo seguro del productor.
- La combinación de lanzamiento (alcance del producto más la versión exacta o imagen de entrega) debe verificarse en lugar de inferirse.
FAQ
¿Es obligatorio el formulario de certificación de software seguro CISA para cada compra de software federal?
Ninguna reclamación universal será segura en agosto de 2026. CISA ahora dice que OMB M-26-05 exige que las agencias mantengan inventarios y políticas de garantía basadas en riesgos; Las agencias pueden elegir recursos para todo el gobierno creados bajo M-22-18, incluido el formulario, y pueden establecer requisitos contractuales. Consulta la agencia solicitante y el contrato.
¿Qué necesita identificar la certificación?
El formulario común identifica al productor de software, el software o línea de productos cubiertos y la persona que da fe. Un registro de ventas útil debe agregar el lanzamiento o versión exacta, la agencia solicitante, la entrega y el propietario de la evidencia que respalda la declaración.
¿Es un SBOM lo mismo que la certificación de software seguro?
No. Un SBOM es un inventario de componentes. La certificación es una declaración del productor sobre prácticas de desarrollo seguro. Una agencia puede solicitar ambos, pero uno no reemplaza al otro.
¿Puede un revendedor firmar por el productor de software?
No infieras eso del canal de ventas. El formulario concierne al productor de software y a una persona autorizada que da fe. Verifique el productor, el producto cubierto y la autoridad firmante de la presentación real.
La transferencia comercial se completa cuando el equipo puede señalar la solicitud actual del comprador, la declaración del productor y la liberación exacta en la misma línea, sin pretender que un archivo pruebe los otros dos.
Preguntas frecuentes
¿Es obligatorio el formulario de certificación de software seguro CISA para cada compra de software federal?
Ninguna reclamación universal será segura en agosto de 2026. CISA ahora dice que OMB M-26-05 exige que las agencias mantengan inventarios y políticas de garantía basadas en riesgos; Las agencias pueden elegir recursos para todo el gobierno creados bajo M-22-18, incluido el formulario, y pueden establecer requisitos contractuales. Se debe comprobar la agencia solicitante y el contrato.
¿Qué necesita identificar la certificación?
El formulario común identifica al productor de software, el software o línea de productos cubiertos y la persona que da fe. Un registro de ventas útil debe agregar el lanzamiento o versión exacta, la agencia solicitante, la entrega y el propietario de la evidencia que respalda la declaración.
¿Es un SBOM lo mismo que la certificación de software seguro?
No. Una lista de materiales de software es un inventario de componentes. La certificación es una declaración del productor sobre prácticas de desarrollo seguro. Una agencia puede solicitar ambos, pero uno no reemplaza al otro.
¿Puede un revendedor firmar por el productor de software?
No infieras eso del canal de ventas. El formulario concierne al productor de software y a una persona autorizada que da fe. Se debe verificar el productor, el producto cubierto y la autoridad firmante para la presentación real.
Fuentes y lecturas adicionales
- CISA, Formulario de certificación de desarrollo de software seguro y nota de política actual, consultado el 14 de agosto de 2026.
- CISA, Formulario común de certificación de desarrollo de software seguro, abril de 2024
- Memorando OMB M-22-18, Mejora de la seguridad de la cadena de suministro de software mediante prácticas seguras de desarrollo de software, 14 de septiembre de 2022
- OMB Memorando M-23-16, Actualización a M-22-18, 9 de junio de 2023
Cómo se descubre una Signal que merece atención
La metodología muestra cómo Top Prospect encuentra y organiza Signals que conviene revisar, conserva el contexto original de Telegram, elimina duplicados y ayuda a decidir qué mirar primero. Tú decides si hacer seguimiento y qué hacer después.
