Pregunta y escenario
Diseña un servicio de transparencia para evidencia de la cadena de suministro de software. Un constructor puede atestiguar sobre un entorno de compilación y el digest de un artefacto, un publicador puede atestiguar sobre un lanzamiento y su código fuente, y un integrador puede anexar resultados de pruebas o de cumplimiento. Un consumidor debe verificar quién firmó una declaración, si se superó la política de registro y si existe un recibo de historial verificable.
El límite clave se encuentra entre los registros verificables y una base de datos empresarial: el servicio demuestra que una declaración fue registrada y verificada en un momento determinado. No reemplaza el almacenamiento de objetos, un registro de paquetes ni un solucionador de dependencias completo.
Qué está evaluando el entrevistador
Límites de confianza
Una respuesta sólida separa a los emisores, el servicio de transparencia, los auditores y las partes usuarias de confianza (relying parties), y luego establece qué puede y qué no puede demostrar cada parte.
Material criptográfico e historial
Explica cómo se relacionan las declaraciones firmadas, los resultados de políticas, un registro de solo anexado (append-only log) y los recibos. Escribir una fila en una base de datos por sí solo no constituye evidencia a prueba de manipulaciones.
Gobernanza operable
Cubre la rotación de claves, revocación, envíos duplicados, versiones de políticas, aislamiento de inquilinos (tenants), privacidad y recuperación ante desastres en lugar de dibujar únicamente la ruta de escritura.
Confiabilidad y escala
Analiza el registro idempotente, la verificación por lotes, las lecturas de pruebas, la replicación multirregión y la reproducción para auditoría frente a un alto volumen de publicaciones y ráfagas de consumidores.
Preguntas de aclaración antes de responder
- ¿Las declaraciones se limitan a artefactos de software o incluyen hardware, modelos y entornos de despliegue?
- ¿El servicio es operado por una sola organización o lo comparten múltiples inquilinos que deben verificarse entre sí?
- ¿Los consumidores requieren lecturas fuertemente consistentes o pueden observar un estado de "registrado pero prueba no replicada"?
- ¿Qué campos son sensibles y puede la vista pública exponer únicamente digests, marcas de tiempo e identificadores de emisor?
- ¿La revocación apunta a una clave, a una declaración o solo a una decisión de política?
- ¿Cuáles son el rendimiento objetivo, el período de retención de evidencia y el punto de recuperación multirregión?
Estructura de respuesta en 30 segundos
"Dividiría el sistema en una API de registro de declaraciones, un verificador de políticas, un registro de transparencia, un servicio de recibos y un SDK de verificación. Un emisor envía una declaración firmada con COSE; el servicio comprueba una política versionada y la registra bajo una clave de idempotencia en un log de solo anexado. El log devuelve un recibo con una prueba de inclusión. Los consumidores verifican la firma, la inclusión en el log, la versión de la política y el tiempo de forma offline utilizando la declaración, el recibo y la ruta de auditoría. Los campos sensibles permanecen como digests o referencias cifradas. La rotación y revocación de claves utilizan raíces de confianza y registros de estado, mientras que la replicación entre regiones publica solo después de que el log y los resultados de políticas sean consistentes."
Respuesta detallada paso a paso
Paso 1: Definir declaraciones y roles
Una declaración contiene un identificador de sujeto, emisor, tipo, tiempo de validez, versión de política y digest del contenido; el emisor la firma con COSE_Sign1. El servicio de transparencia acepta únicamente emisores autenticados y vincula cada declaración a un inquilino, espacio de nombres y fuente. Los consumidores, auditores y administradores de políticas cuentan con permisos separados.
Paso 2: Diseñar el registro
El cliente llama a POST /statements con la declaración firmada, una clave de idempotencia y una sugerencia de política. El servicio valida la firma, la ventana de tiempo, el esquema y el estado del emisor, y luego evalúa la política. Una declaración aprobada se anexa al log de transparencia. El mismo contenido y clave devuelven el recibo original; un conflicto devuelve el registro actual en lugar de sobrescribirlo silenciosamente.
POST /statements
Idempotency-Key: build-123
Content-Type: application/cbor
{ signedStatement, policyVersion }Paso 3: Emitir un recibo verificable
El servicio crea un recibo que contiene la versión del árbol del log, el digest de la hoja, la ruta de prueba y la firma del servicio. Un lector verifica el recibo con la clave pública del servicio, recalcula el digest de la declaración y comprueba la inclusión. Un recibo demuestra que el servicio registró y se comprometió con un registro en un momento dado; no demuestra que el artefacto sea seguro.
Paso 4: Manejar políticas, revocación y tiempo
Una política está versionada y fijada en cada registro de inscripción. Una política posterior no reescribe el resultado anterior; crea una nueva declaración de evaluación. La rotación de claves conserva las claves públicas históricas con sus tiempos de activación. Los registros de estado pueden revocar un emisor, clave o declaración. Los verificadores comprueban el tiempo de la declaración, el tiempo del recibo y las ventanas de validez de la raíz de confianza.
Paso 5: Aislar privacidad e inquilinos
El log público conserva únicamente digests, tipos, identificadores de emisor y marcas de tiempo necesarias. El código fuente, los dominios internos y los detalles de vulnerabilidades residen en un almacenamiento de objetos cifrado y se referencian por dirección de contenido. Las políticas de inquilino, cuotas y autorización de lectura se aplican en la API; los índices del log pueden particionarse por inquilino manteniendo formatos de prueba interoperables.
Paso 6: Escalar, recuperar y operar
Aplica sharding a los logs y procesa inserciones en lotes en la ruta de escritura; almacena en caché claves públicas, esquemas y recibos en la ruta de lectura. Replica logs ordenados y puntos de control entre regiones. Una región de destino permanece en modo de solo lectura hasta que el estado del log, los resultados de políticas y el estado de las claves converjan. Monitorea el éxito de registros, rechazos por política, latencia de recibos, retraso de replicación, fallos de verificación y tiempo de propagación de revocaciones.
Respuesta de ejemplo de alta calidad
"Expondría una API de registro de declaraciones y un SDK de verificación offline. Un sistema de compilación envía una declaración COSE_Sign1 que contiene el digest del artefacto, emisor, tipo, tiempo y versión de política. El servicio valida la firma y el esquema, evalúa la política del inquilino, anexa el digest a un log de transparencia de solo anexado y devuelve un recibo con prueba de inclusión. El registro es idempotente, por lo que los reintentos devuelven el mismo recibo.
Los consumidores descargan la declaración, el recibo y la raíz de confianza, y verifican la firma, la inclusión en el log, el estado del emisor y la versión de la política localmente. El resultado de una verificación puede convertirse en otra declaración firmada, formando una cadena trazable. El contenido sensible permanece tras referencias cifradas. Las raíces de confianza históricas siguen disponibles tras la rotación de claves, y la revocación se propaga mediante declaraciones de estado. La replicación multirregión copia los datos ordenados del log, los puntos de control y los resultados de políticas antes de habilitar lecturas de verificación fuerte. El sistema demuestra el registro y la trazabilidad; no reemplaza el escaneo de malware ni la seguridad en tiempo de ejecución."
Errores comunes
- Almacenar declaraciones en una tabla editable → un administrador puede reescribir el historial → utiliza un log de solo anexado, recibos firmados y un verificador independiente.
- Tratar un recibo de transparencia como un veredicto de seguridad → el registro no significa que un artefacto esté libre de vulnerabilidades → separa la procedencia, los resultados de políticas y el riesgo en tiempo de ejecución.
- Sobrescribir registros antiguos cuando cambia la política → las auditorías no pueden reproducir decisiones → fija las versiones de políticas y anexa nuevas evaluaciones.
- Rotar únicamente la clave actual → las declaraciones antiguas no pueden verificarse → conserva claves históricas y raíces de confianza con tiempos de activación.
- Publicar todos los campos de la declaración → se filtran metadatos de código fuente y vulnerabilidades → expón digests y cifra referencias sensibles.
- Permitir que los reintentos creen registros duplicados → historial inestable y desperdicio de almacenamiento → vincula una clave de idempotencia al inquilino y al contenido firmado.
- Habilitar una réplica antes de que converjan las pruebas → rutas de inclusión incompletas → replica el log, los puntos de control y el estado de las claves antes de servir lecturas.
- Exigir una API central para cada verificación → las auditorías offline fallan → distribuye declaraciones, recibos, raíces de confianza y un verificador offline.
Preguntas de seguimiento y respuestas
Pregunta de seguimiento 1: ¿Cómo demuestras que el log no eliminó un registro intermedio?
Los auditores obtienen y comparan periódicamente puntos de control firmados. Los verificadores exigen un tamaño de árbol monotónico, raíces históricas consistentes y pruebas de inclusión válidas; una bifurcación (fork) hace que se deje de confiar en el log.
Pregunta de seguimiento 2: ¿Pueden los recibos de dos servicios de transparencia verificarse entre sí?
Pueden compartir digests de declaraciones y un formato de recibo estandarizado, pero cada servicio sigue firmando con su propia raíz de confianza. La equivalencia entre servicios requiere una declaración cruzada adicional; la clave pública de un servicio no otorga confianza automáticamente al otro.
Pregunta de seguimiento 3: ¿Cómo revocas una declaración ya registrada?
Conserva la declaración y el recibo originales, y luego anexa una declaración de revocación o de estado de riesgo. El verificador aplica el tiempo y las políticas para decidir la aceptación actual, mientras que los auditores conservan el hecho del registro original.
Pregunta de seguimiento 4: ¿Qué sucede cuando el registro no está disponible durante un lanzamiento?
El cliente almacena la declaración firmada y el digest localmente y etiqueta el lanzamiento como "sin recibo de transparencia todavía". Una vez restaurado el servicio, se registra con la misma clave de idempotencia; nunca se presenta una prueba faltante como verificada.
Pregunta de seguimiento 5: ¿Cómo evitas que el log se convierta en una fuga de privacidad?
Registra el mínimo de campos públicos, aplica políticas de acceso a nivel de inquilino y utiliza referencias cifradas. Agrega tiempo, emisor y tipo de artefacto solo según sea necesario, preservando al mismo tiempo digests verificables para auditorías.
Fuente 1: Arquitectura SCITT de RFC 9943
La RFC 9943 define declaraciones firmadas, servicios de transparencia, recibos y pruebas de estructuras de datos verificables. También distingue la evidencia de registro del almacenamiento de artefactos y la resolución de dependencias. Esos límites fundamentan los roles, el flujo de registro y el diseño de recibos aquí expuestos.
Fuente 2: Descripción general del proyecto SCITT
El proyecto SCITT describe un historial auditable, trazable y verificable para declaraciones de la cadena de suministro. La verificación de inquilinos, la gobernanza de políticas y las operaciones regionales en esta respuesta convierten ese objetivo en compensaciones explícitas de diseño.
Fuente 3: Investigación sobre entrevistas de ingeniería de software
La investigación sobre la preparación para entrevistas técnicas de ingeniería de software enfatiza el equilibrio entre la comunicación, la clarificación de restricciones y el razonamiento técnico. Las preguntas de aclaración, el marco conciso y el seguimiento de fallos están diseñados para evidenciar esas habilidades en lugar de premiar el recuerdo de terminología.