Un comprador solicita la procedencia SLSA: ¿qué servicio solicita?
Un comprador menciona la procedencia de SLSA durante la incorporación sin nombrar el artefacto, la plataforma, el nivel o la prueba de aceptación. Utilice un registro de cinco campos para dirigir la solicitud al servicio correcto.
No necesariamente la procedencia que construirías primero. Cuando un comprador solicita la procedencia de SLSA durante la incorporación, generalmente nombra un objetivo de cumplimiento en lugar de un entregable, y cuatro servicios podrían satisfacer esa oración: generación de procedencia, fortalecimiento del sistema de construcción, implementación de políticas de verificación y revisión de evidencia, ninguno de ellos intercambiable. La solicitud se dirige al correcto solo después de identificar cinco campos: el artefacto y su resumen, la plataforma de construcción, el nivel SLSA objetivo, el firmante-constructor o verificador y la prueba de aceptación del comprador.
La respuesta corta: ruta por lo que la solicitud omite
Niveles de cadena de suministro para artefactos de software (SLSA) v1.2, la especificación publicada por el proyecto SLSA y consultada el 3 de agosto de 2026 en slsa.dev/spec/v1.2/, describe garantías de seguridad de la cadena de suministro de software cada vez más sólidas organizadas en pistas y niveles. La procedencia, como la define SLSA v1.2 en el página de procedencia del proyecto SLSA (consultado el 3 de agosto de 2026), es información verificable que rastrea un artefacto a lo largo de la cadena de suministro hasta dónde, cuándo y cómo se produjo. Una atestación es la declaración firmada que contiene esa información; SLSA recomienda formatos de certificación que incluyan la procedencia.
Por qué esto es importante para un responsable de ventas de seguridad de la cadena de suministro de software: un comprador que menciona SLSA ha nombrado un estándar objetivo, no un servicio. La misma frase puede preceder, con toda legitimidad, a cuatro alcances de trabajo distintos. Encamine la solicitud según lo que todavía omita:
- Se nombra artefacto, resumen y plataforma de compilación, pero nada da fe de la generación de compilación → procedencia.
- La plataforma no puede registrar honestamente entradas, comandos y salidas → fortalecimiento del sistema de compilación, antes de que cualquier certificación pueda ser honesta.
- Existe una atestación, pero ninguna regla de verificación relaciona la prueba de aceptación del comprador → implementación de la política de verificación.
- Ya se envió una atestación y fue rechazada → revisión de la evidencia.
- Dos o más campos desconocidos → enviar un registro aclaratorio, luego enrutar.
Los hechos de la versión 1.2 que anclan la conversación
La versión 1.2 esquema de procedencia de construcción (publicada por el proyecto SLSA, consultada el 3 de agosto de 2026) requiere dos campos de nivel superior para el nivel 1 de compilación de SLSA: buildDefinition y runDetails, y runDetails, a su vez, requiere un constructor. Concretamente:
- buildDefinition describe qué se compiló y cómo, incluidos los parámetros externos desde los que comenzó la compilación.
- runDetails registra cómo se ejecutó la compilación y nombra al constructor: la identidad del sistema que produjo el artefacto.
- El esquema también mantiene el sujeto del artefacto (el artefacto producido y su resumen), los metadatos de invocación y las reglas de verificación como partes distintas.
El punto a tener en cuenta: producir un documento con estos campos no otorga un nivel SLSA. Los campos son un requisito de formato; Que su contenido sea confiable depende de la plataforma de construcción y del firmante detrás de la identidad del constructor. Es por eso que el registro de cinco campos decide entre servicios: la generación completa los campos, el endurecimiento hace que la plataforma pueda completarlos honestamente, la política de verificación decide qué debe verificar un verificador y la revisión de evidencia verifica lo que ya se produjo.
Cuatro servicios, cinco criterios
Compare los cuatro servicios con los mismos cinco criterios, utilizando un registro compartido por comprador.
| Servicio | Artefacto y resumen | construir plataforma | Nivel objetivo | Firmante-constructor o verificador | Prueba de aceptación del comprador |
|---|---|---|---|---|---|
| Generación de procedencia | Necesario desde el principio como sujeto de la certificación | Se supone capaz de registrar la construcción. | Decide qué campos lleva la certificación. | Usted firma como constructor | Produce evidencia que la prueba puede aceptar. |
| Endurecimiento del sistema de construcción | Produce un artefacto reproducible y lo digiere primero. | El objeto de la obra. | Decide qué garantías de construcción debe agregar la plataforma. | Cambias lo que ejecuta el constructor. | Hace posible la evidencia aceptable |
| Implementación de la política de verificación | Necesita una certificación con un asunto verificable | Relevante sólo cuando la política hace referencia a ello. | Decide qué reglas de verificación se aplican | Configuras el verificador | Define cómo se evalúa la prueba. |
| Revisión de evidencia | Vuelve a verificar el resumen en una atestación existente | Lee los registros existentes | Se compara con el nivel indicado por el comprador | Usted revisa; no firma | Relaciona la evidencia rechazada con la prueba |
Matriz de decisión
Una matriz de enrutamiento compacta en los mismos campos:
| Si la solicitud… | …y | Ruta |
|---|---|---|
| Nombra un artefacto, un resumen y una plataforma. | no existe ninguna certificación | generación de procedencia |
| Nombra un nivel que la plataforma no puede registrar honestamente | el comprador espera campos reales | endurecimiento del sistema de construcción |
| Cita una atestación | ninguna regla de verificación se asigna a la prueba de aceptación | implementación de la política de verificación |
| Informa una certificación rechazada | sin decir que campo falló | revisión de evidencia |
| Deja la mayoría de los campos abiertos | espera un nombre de servicio hoy | aclarar el registro primero |
| Cuando la prueba de aceptación del comprador se lee como una solicitud de evidencia SOC 2 (un tipo de evidencia con nombre sin más detalles), se aplica el patrón de nuestro análisis Solicitudes de evidencia de incorporación SOC 2: la solicitud nombra un tipo de evidencia, no los campos necesarios para evaluarla. |
Ejemplo resuelto: una solicitud de incorporación compuesta
Mensaje compuesto ilustrativo Telegram: no es un registro de cliente; sin comprador real, cotización comercial ni fecha límite:
“Para la incorporación necesitamos la procedencia SLSA de los artefactos que envía. Nuestro equipo de seguridad lo validará según nuestros criterios de aceptación antes de aprobar al proveedor. ¿Puede confirmar que proporciona esto?”
Ejecute la verificación de cinco campos:
- Artefacto y resumen: sin nombre.
- Plataforma de compilación: sin nombre.
- Nivel de destino: sin nombre.
- Firmante-constructor o verificador: el equipo del comprador “validará”, lo que implica que usted actuará como firmante-constructor: una inferencia, no un hecho declarado.
- Prueba de aceptación del comprador: denominado como “criterio de aceptación” sin contenido.
Faltan dos o más campos, por lo que la respuesta correcta hoy es el registro aclaratorio, no una promesa de servicio: solicite el artefacto y el resumen, la plataforma de construcción, el nivel objetivo, cualquier certificación existente y la prueba de aceptación exacta: quién verifica, con qué regla, contra qué nivel.
Seguimiento ilustrativo (aún compuesto): si el comprador luego nombra una imagen de contenedor y su resumen, una plataforma de CI alojada, nivel de compilación 1 objetivo y no hay ninguna certificación existente, la ruta es la generación de procedencia. Si, en cambio, nombran un nivel objetivo y confirman que la plataforma no puede registrar las entradas de compilación, la ruta se está endureciendo. El método no resuelve la ambigüedad; las respuestas del comprador sí.
Por qué es importante: prometer el servicio equivocado desperdicia el ciclo del comprador y su credibilidad. Si genera la procedencia de la cotización comercial y el verdadero obstáculo es que la plataforma no puede registrar la construcción, la entrega falla a su llegada. El registro de cinco campos también le brinda una razón defendible para hacer preguntas: está completando el registro que necesitará la prueba de aceptación del propio comprador, no estancando.
Lo que aún se desconoce y quién debe verificarlo: el nivel objetivo y la prueba de aceptación pertenecen al equipo de seguridad del comprador; La capacidad de la plataforma para registrar compilaciones debe ser verificada por su equipo de ingeniería en lugar de asumirse desde la página de un producto; y se debe cotejar la existencia de cualquier certificación previa con el registro de artefactos. Ninguno de estos puede confirmarse únicamente con el mensaje de incorporación.
Si el canal del comprador en sí es un grupo Telegram monitoreado, se aplica la misma disciplina que cubrimos en nuestro análisis de Telegram controla las comprobaciones de DPA del proveedor: el canal muestra lo que se dijo; no lo certifica. El propio política de privacidad de Telegram (consultado el 3 de agosto de 2026) afirma que los bots son servicios independientes de terceros, que el acceso a los mensajes es opcional y la interfaz muestra qué modo se aplica, y que los desarrolladores de bots de terceros deben solicitar permiso antes de acceder a los datos. TOP Prospect aplica ese límite en la práctica: procesa solo grupos Telegram a los que el usuario se conecta intencionalmente y está autorizado a acceder, produce candidatos para revisión humana en lugar de certificación de hechos, deja la decisión a una persona y no contacta a los miembros del grupo automáticamente. Para saber cómo la revisión del canal se mantiene separada de la evidencia de artefactos, consulte Telegram pilar de inteligencia de señales comerciales.
Hechos clave: fechas, números y lo que no prueban
-
Especificación SLSA v1.2: publicada por el proyecto SLSA, consultado el 3 de agosto de 2026 (slsa.dev/spec/v1.2/); SHA-256 46edf6…e7e3ae. Describe garantías de seguridad de la cadena de suministro cada vez más sólidas en pistas y niveles.
-
Procedencia, v1.2: consultado el 3 de agosto de 2026 (slsa.dev/spec/v1.2/procedencia); SHA-256 9a176a…0e51e44. Información verificable que rastrea un artefacto hasta dónde, cuándo y cómo se produjo; crear seguimientos de procedencia generar resultados en el código fuente, seguimientos de procedencia del origen, revisiones del código fuente y gestión de cambios.
-
Procedencia de la construcción, v1.2: consultado el 3 de agosto de 2026 (slsa.dev/spec/v1.2/build-provenance); SHA-256 04a97c…170f647. El nivel de compilación 1 requiere buildDefinition y runDetails; runDetails requiere un constructor.
-
Política de privacidad de Telegram: página de política actual consultada el 3 de agosto de 2026 (telegram.org/privacy); SHA-256 9ae1e9…253786b. Los bots son servicios independientes de terceros; el acceso a mensajes es opcional y se muestra en la interfaz; Los desarrolladores de bots de terceros deben pedir permiso.
Contexto de medición: los valores SHA-256 son huellas digitales de contenido para confirmar que una página citada coincide con la versión recuperada en la fecha de acceso. Las versiones y fechas anclan la evidencia; no miden la intención del comprador y una fecha de acceso no es una fecha límite de cumplimiento por parte del comprador.
Preguntas frecuentes
¿Un comprador que nombra SLSA significa que necesita generación de procedencia? No. La denominación SLSA nombra un estándar objetivo y la generación de procedencia es solo una de las cuatro rutas. Diríjase por el registro de cinco campos (artefacto y resumen, plataforma de compilación, nivel objetivo, firmante-constructor o verificador, prueba de aceptación) y envíe primero un registro aclaratorio cuando falten la mayoría de los campos.
¿Puede un documento por sí solo obtener un nivel SLSA? No. El esquema de procedencia de compilación v1.2 requiere buildDefinition y runDetails, con un constructor, para el nivel de compilación 1, pero esos campos son requisitos de formato. La confiabilidad depende de la plataforma de construcción y del firmante detrás de la identidad del constructor: un documento describe un nivel, no otorga ninguno.
¿Qué debo enviar antes de prometer un servicio? Un breve registro aclaratorio que enumera los cinco campos: artefacto y resumen, plataforma de compilación, nivel SLSA objetivo, cualquier certificación existente y la prueba de aceptación exacta: quién verifica, con qué regla y con qué nivel.
El siguiente paso que vale la pena realizar esta semana: convertir el registro de cinco campos en una plantilla de una página con un mensaje aclaratorio de copiar y pegar, de modo que la próxima solicitud de incorporación nombre las rutas SLSA en un intercambio en lugar de tres.
Preguntas frecuentes
¿Un comprador que nombra SLSA significa que necesita generación de procedencia?
No. La denominación SLSA nombra un estándar objetivo y la generación de procedencia es solo una de las cuatro rutas. Diríjase por el registro de cinco campos (artefacto y resumen, plataforma de compilación, nivel objetivo, firmante-constructor o verificador, prueba de aceptación) y envíe primero un registro aclaratorio cuando falten la mayoría de los campos.
¿Puede un documento por sí solo obtener un nivel SLSA?
No. El esquema de procedencia de compilación v1.2 requiere buildDefinition y runDetails, con un constructor, para el nivel de compilación 1, pero esos campos son requisitos de formato. La confiabilidad depende de la plataforma de construcción y del firmante detrás de la identidad del constructor: un documento describe un nivel, no otorga ninguno.
¿Qué debo devolver antes de prometer un servicio?
Un breve registro aclaratorio que enumera los cinco campos: artefacto y resumen, plataforma de compilación, nivel SLSA objetivo, cualquier certificación existente y la prueba de aceptación exacta: quién verifica, con qué regla y con qué nivel. El siguiente paso que vale la pena realizar esta semana: convertir el registro de cinco campos en una plantilla de una página con un mensaje aclaratorio de copiar y pegar, de modo que la próxima solicitud de incorporación nombre las rutas SLSA en un intercambio en lugar de tres.
Fuentes y lecturas adicionales
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.
