Introducción
El software se encuentra entre el satélite, la red terrestre, los operadores, los clientes y los reguladores. Los sistemas de control de misión planifican contactos, validan y transmiten comandos, reciben y procesan telemetría, monitorean el estado de las naves espaciales, calculan órbitas, administran programas de carga útil y preservan el registro operativo. Un defecto, una dependencia no disponible o una clave de firma inaccesible pueden interrumpir los ingresos y debilitar la autoridad de mando incluso cuando la nave espacial subyacente permanece técnicamente en buen estado.
Por lo tanto, una adquisición implica más que una revisión convencional de un producto de software. El comprador debe comprender el sistema de misión tal como se opera. Ese sistema incluye repositorios de origen, canalizaciones de construcción, datos de configuración, entornos de implementación, material criptográfico, interfaces terrestres, runbooks, servicios de proveedores, criterio de ingeniería y derechos contractuales. Varios de estos elementos pueden estar fuera de la entidad jurídica del objetivo o depender de personas identificadas.
Este documento establece un marco de transacciones para ese problema. Está diseñado para compradores estratégicos, inversores en infraestructura, empresas de capital privado, operadores de satélites, prestamistas y juntas directivas que evalúan una transacción espacial basada en software. Se centra en la evidencia que cambia el control, la continuidad, el precio, las condiciones y el diseño de la integración.
1 Definir la capacidad adquirida
El comprador debería comenzar con una declaración de capacidad. La declaración identifica qué misiones, naves espaciales, cargas útiles, sitios terrestres, servicios al cliente y decisiones operativas respalda el software. Registra ventanas de servicio, expectativas de disponibilidad, consecuencias para la seguridad, obligaciones regulatorias y dependencias de ingresos. Los nombres de los productos por sí solos proporcionan un perímetro poco confiable porque una plataforma de marca puede depender de servicios separados de dinámica de vuelo, planificación, identidad, base de datos, monitoreo y estación terrestre.
La declaración de capacidad debe distinguir el software de vuelo del software terrestre. Las adquisiciones de control de satélites generalmente se centran en el segmento terrestre, mientras que el valor operativo puede depender de interfaces de vuelo integradas y bases de datos de comando específicas de las naves espaciales. El comprador necesita pruebas de que el objetivo puede utilizar, modificar y transferir todas las interfaces necesarias para continuar con las operaciones.
El perímetro también debería identificar los servicios excluidos. La identidad corporativa compartida, las suscripciones a la nube, los enlaces de comunicaciones, los servicios de gestión de claves, los centros de datos o el personal de la empresa matriz pueden ser esenciales desde el primer día. Cada exclusión se convierte en un requisito de transición, una dependencia continua o un ajuste de valor.
2 Propiedad, acceso y control separados
La propiedad legal es un elemento de control. El comprador también necesita acceso físico o lógico, derechos suficientes para modificar e implementar, conocimiento para operar y autoridad sobre las credenciales y las decisiones de liberación. Estos elementos pueden divergir. Un objetivo puede poseer un código fuente personalizado y al mismo tiempo depender de una biblioteca no transferible. Puede poseer un repositorio, mientras que la compilación de producción depende de la cadena de herramientas privada de un consultor. Puede tener licencias amplias mientras un cliente gubernamental controla la aprobación de la implementación.
El modelo de diligencia debe registrar por separado la propiedad, posesión, acceso, derechos de modificación, derechos de distribución, autoridad operativa y derechos de terminación. Cada artículo necesita evidencia documental. La evidencia relevante incluye asignaciones, términos de empleo, acuerdos de contratistas, cronogramas de licencias, permisos de repositorio, registros de implementación, contratos de clientes y confirmaciones de proveedores.
El control también tiene una dimensión temporal. El acceso que existe durante la diligencia puede expirar al momento del cierre. El comprador debe identificar las acciones exactas necesarias para preservar el acceso al repositorio, la tenencia de la nube, la autoridad de firma, las credenciales de administrador, el historial de monitoreo y el soporte del proveedor a través del límite de la transacción.
3 Construya el software y el inventario de dependencias
El inventario debe identificar aplicaciones, servicios, repositorios, sucursales, sistemas de compilación, paquetes de implementación, bases de datos, interfaces, productos comerciales, componentes de código abierto, bibliotecas criptográficas y scripts operativos. Debe conectar cada componente con la función de la misión que respalda y el entorno en el que se ejecuta.
Un SBOM puede acelerar el descubrimiento de componentes. No reemplaza el inventario operativo. Un útil inventario de adquisiciones vincula el nombre y la versión del componente con la fuente, la licencia, el mantenedor, el estado de la vulnerabilidad, el artefacto de compilación, la configuración implementada, la dependencia de los datos y la ruta de reemplazo. Los componentes integrados en contenedores, firmware o dispositivos de proveedores requieren atención porque pueden estar ausentes de una lista de aplicaciones convencional.
El comprador debe conciliar tres puntos de vista: qué dice la ingeniería que existe, qué contienen los repositorios y qué muestra la telemetría de producción en funcionamiento. Las diferencias son hallazgos de diligencia. Un servicio no registrado puede ser crítico. Un repositorio listado puede estar obsoleto. Es posible que un binario de producción no se rastree hasta una confirmación de fuente aprobada.
4 Pruebe la integridad del código fuente
El acceso al repositorio debe cubrir el producto completo y su historial. El comprador debe inspeccionar el origen, la configuración, las definiciones de infraestructura, los esquemas de bases de datos, los activos de prueba, los scripts de compilación, la automatización de la implementación, la documentación y el historial de problemas. Una instantánea de los archivos seleccionados no puede demostrar que esté completa.
Las pruebas de integridad comienzan con los artefactos implementados. El equipo identifica contenedores o binarios de producción representativos y los rastrea hasta revisiones de origen, versiones de dependencia, parámetros de compilación y registros de aprobación. Luego construye el software en un entorno controlado y compara el resultado con el artefacto implementado o su procedencia documentada. Las diferencias requieren explicación.
El código generado merece un tratamiento aparte. La guía de la NASA reconoce que el mantenimiento a largo plazo puede requerir acceso a modelos, simulaciones, definiciones de datos, generadores, datos de construcción, scripts de prueba y resultados esperados. La posesión de la fuente generada puede resultar insuficiente cuando falta el generador, modelo o configuración calificada.
5 Reproducir la construcción
Una construcción reproducible es una prueba de diligencia de alto valor. El objetivo es demostrar que un equipo autorizado puede crear una versión desplegable a partir de entradas controladas sin intervención indocumentada. La prueba debe utilizar un entorno limpio y el procedimiento documentado del objetivo. Los observadores de compradores deben registrar los requisitos previos, las descargas externas, las credenciales, los pasos manuales, las versiones de las herramientas, las advertencias y las desviaciones.
No es necesario que el resultado sea idéntico bit a bit cuando el proceso existente no admite la compilación determinista. Debe ser rastreable y funcionalmente equivalente según las pruebas acordadas. El comprador debe comprender por qué surge cualquier diferencia y si el proceso preserva la integridad.
Los errores de compilación pueden revelar licencias faltantes, certificados caducados, repositorios de paquetes no disponibles, parches no documentados o dependencia de un ingeniero designado. Estos hallazgos se conectan directamente con el costo de transición y el riesgo de continuidad. El acuerdo de compra puede requerir una construcción limpia exitosa antes del cierre o colocar la contraprestación en depósito de garantía hasta que se cumpla la condición.
6 Autoridad de liberación e implementación de seguimiento
El acceso a la fuente no establece la capacidad de operar la producción. El comprador debe rastrear la autoridad desde la aprobación del código hasta la construcción, firma, lanzamiento, implementación y reversión. El seguimiento identifica quién puede aprobar cambios, quién posee las credenciales de firma, dónde se almacenan los paquetes, cómo se promueven los entornos y cómo se controlan las liberaciones de emergencia.
Los cambios en el control de los satélites pueden tener consecuencias para la seguridad de la misión. La evidencia de liberación debe incluir resultados de verificación, revisión de la preparación operativa, aprobación de la configuración, consentimiento del cliente o de la autoridad, cuando corresponda, y una ruta de recuperación probada. El comprador debe distinguir las versiones de aplicaciones de rutina de los cambios en la validación de comandos, la dinámica de vuelo, la interpretación de telemetría o la confianza criptográfica.
La transferencia de credenciales requiere un proceso diseñado. Las claves privadas y las credenciales privilegiadas no deben copiarse casualmente durante el cierre. Las partes deben acordar rotación, revocación, reinscripción, control dual, preservación de auditoría y retroceso. El plan de cierre debe indicar cuándo cambia la autoridad operativa y cómo se evita la responsabilidad ambigua.
7 Examinar los datos de configuración de la misión.
El software de control de misión se basa en una configuración que puede ser tan valiosa como el código fuente. Diccionarios de comandos, definiciones de telemetría, límites, datos de calibración, modelos de naves espaciales, planes de contacto, parámetros orbitales, reglas de automatización y enrutamiento de clientes determinan cómo interactúa el software genérico con una flota real.
El comprador debe identificar la fuente autorizada para cada clase de configuración, su proceso de aprobación, historial de versiones y método de recuperación. Debería probar si se puede poblar un nuevo entorno a partir de registros controlados. La configuración basada en hojas de cálculo o almacenada localmente crea riesgos cuando carece de revisión, linaje y respaldo.
Los derechos de configuración también importan. Un cliente, fabricante de naves espaciales o integrador de sistemas puede poseer o restringir parte de los datos. El acuerdo de adquisición debe abordar la transferencia, el uso continuo, la confidencialidad, las restricciones a la exportación y las obligaciones de eliminación. La falta de configuración puede inutilizar el software que de otro modo estaría completo para una misión específica.
8 Evaluar la evidencia de aseguramiento del software
La evidencia de garantía de software muestra si el producto fue desarrollado y mantenido mediante prácticas controladas. El SSDF del NIST organiza el desarrollo seguro en torno a la preparación de la organización, la protección del software, la producción de software bien seguro y la respuesta a las vulnerabilidades. La guía de garantía de software de la NASA agrega evidencia objetiva para los contextos de seguridad y misión.
El comprador debe revisar la trazabilidad de los requisitos, las decisiones de arquitectura, la revisión del código, el análisis estático, el escaneo de dependencias, la cobertura de las pruebas, la aprobación de la versión, el historial de defectos y la respuesta a las vulnerabilidades. La evidencia debe corresponder a las versiones en producción. Un documento de política sin registros ejecutados proporciona una seguridad limitada.
El equipo de diligencia debe tomar muestras de rutas críticas como la generación de comandos, la autenticación, la gestión de privilegios, la determinación de la órbita y la recuperación. Debería examinar si las pruebas cubren condiciones adversas y límite. Los hallazgos abiertos deben clasificarse según las consecuencias de la misión, la explotabilidad, la recuperabilidad y la dependencia de la remediación.
9 Mapear la cadena de suministro de software
La cadena de suministro incluye proveedores comerciales, proyectos de código abierto, proveedores de nube, servicios de construcción, repositorios de paquetes, proveedores de hardware, consultores y operadores especializados. El comprador debe identificar qué partes pueden cambiar, interrumpir, acceder o restringir el producto.
Para cada proveedor crítico, la diligencia debe cubrir el soporte contractual, la resiliencia financiera, las prácticas de seguridad, los privilegios de acceso, la notificación de incidentes, el control de cambios, la política de fin de vida útil, la ubicación de los datos y el plazo de sustitución. Un proveedor que admite varios componentes de misión crítica genera concentración incluso cuando el gasto anual es pequeño.
NIST SP 800-161 trata el riesgo de la cadena de suministro como un problema de gobierno organizacional en lugar de una lista de verificación de adquisiciones. El equipo de transacciones debe conectar la evidencia del proveedor con la criticidad del sistema y la propiedad planificada. Los proveedores de materiales pueden requerir consentimiento, novación o acuerdo directo antes del cierre.
10 Analizar la exposición al código abierto
Los componentes de código abierto pueden mejorar la capacidad y reducir el tiempo de desarrollo. También crean obligaciones de licencia, mantenimiento y seguridad. El comprador debe conciliar los componentes declarados con el escaneo de códigos y los manifiestos de compilación. Debe identificar los términos de la licencia, modificaciones, avisos, prácticas de distribución y vulnerabilidades conocidas.
La exposición al copyleft requiere un análisis legal basado en el uso y la distribución reales. Una etiqueta de licencia por sí sola no establece la obligación. El equipo debe documentar cómo se vinculan, implementan, modifican y proporcionan los componentes a los clientes. La remediación puede implicar la corrección de avisos, ofertas de origen, reemplazo de componentes o comunicación con el cliente.
El estado de mantenimiento afecta el valor. Una biblioteca crítica sin un mantenedor activo o una versión compatible puede requerir propiedad interna. El comprador debe evaluar la estrategia de bifurcación, la cobertura de pruebas, la capacidad de parches y la dependencia de la comunidad. Una lista de materiales de software debe permanecer actualizada después del cierre en lugar de convertirse en un artefacto estático de diligencia.
11 Revisar la procedencia de la propiedad intelectual
Cada contribución de código material debe tener una ruta de procedencia defendible. Las invenciones de los empleados deben estar dentro de las condiciones laborales adecuadas. El trabajo del contratista debe asignarse con suficiente alcance. El código adquirido o aportado debe tener los derechos necesarios. El desarrollo financiado por universidades, gobiernos o clientes puede incluir restricciones que requieren una revisión detallada.
El equipo debe comparar el historial de compromisos con los registros y contratos de los contribuyentes. Autores no reconocidos, relatos personales o importaciones masivas inexplicables merecen investigación. La revisión debe incluir documentación, modelos, datos de prueba, interfaces de usuario y algoritmos, porque la valiosa propiedad intelectual se extiende más allá de los archivos fuente.
El análisis de patentes y secretos comerciales debe centrarse en el producto real y el plan comercial. El comprador debe comprender los registros defensivos, la libertad de operación del trabajo, los controles de confidencialidad y cualquier divulgación que pueda debilitar la protección de los secretos comerciales. Los documentos de transacción pueden asignar riesgos de procedencia específicos a través de garantías, indemnizaciones, depósitos en garantía o contraprestaciones contingentes.
12 Pruebe el acceso privilegiado y la segregación
Los entornos de control de misiones concentran poderosos privilegios. Los administradores pueden controlar comandos, identidad, bases de datos, recursos de la nube, claves de firma y monitoreo. El comprador debe obtener un inventario privilegiado que cubra cuentas humanas, de servicio y de emergencia en entornos de desarrollo, prueba, producción y recuperación.
La revisión debería poner a prueba los controles de entrada, salida y salida; autenticación multifactor; aprobación; registro de sesiones; rotación de credenciales; acceso a prueba de rotura de cristales; y segregación entre desarrollo y producción. Las cuentas compartidas o inactivas reducen la rendición de cuentas. Las cuentas de servicio requieren controles de propiedad y ciclo de vida.
El cierre crea un mayor riesgo de acceso. El personal saliente puede conservar sus credenciales o conocimientos sobre las rutas de recuperación. El plan de transición debe rotar las credenciales confidenciales, revocar el acceso antiguo, preservar la evidencia y mantener una cobertura operativa dual. Estas acciones deben ensayarse cuando la pérdida de acceso pueda afectar una misión en vivo.
13 Revisar la gestión de vulnerabilidades
El comprador debe comprender cómo se descubren, clasifican, solucionan y comunican las vulnerabilidades. Las fuentes incluyen análisis estático, escaneo de dependencias, pruebas de penetración, informes de clientes, avisos de proveedores y monitoreo operativo. El programa debe definir la gravedad, las consecuencias de la misión, el momento de la remediación, la aprobación de excepciones y la repetición de pruebas.
El análisis del trabajo pendiente puede revelar requisitos de mantenimiento ocultos. El comprador debe examinar la edad, la recurrencia, las versiones afectadas y la calidad del cierre. Un recuento bajo puede reflejar una detección débil. Un recuento alto puede reflejar un descubrimiento activo. La medida útil es la capacidad de la organización para identificar la exposición relevante y reducirla dentro de plazos basados en el riesgo.
Los sistemas de vuelo y terrestres pueden tener ventanas de parcheo limitadas. El objetivo debe mostrar cómo aplica controles compensatorios y planifica liberaciones seguras. Las vulnerabilidades conocidas en componentes inaccesibles o al final de su vida útil pueden justificar una deducción de precio específica o una reserva de remediación financiada.
14 Evaluar interfaces e interoperabilidad
El software de control de satélites depende de interfaces con naves espaciales, estaciones terrestres, redes, sistemas de identidad, plataformas de clientes, datos meteorológicos, datos orbitales y servicios regulatorios. El comprador debe inventariar el protocolo, la versión, el propietario, los requisitos de rendimiento, el control de seguridad, el entorno de prueba y el proceso de cambio para cada interfaz.
La documentación de la interfaz debe probarse con el tráfico observado y las configuraciones actuales. Las interfaces propietarias o no documentadas crean un bloqueo. Un protocolo estándar aún puede contener extensiones específicas del cliente que complican el reemplazo.
El equipo debería probar los modos de falla. Debería observar datos retrasados, mensajes duplicados, errores de reloj, entradas corruptas, interrupción de la red y pérdida parcial del servicio. El comportamiento de recuperación afecta el valor operativo. Los planes de integración deben preservar la observabilidad de la interfaz y evitar cambiar varias dependencias críticas a la vez.
15 Evaluar los derechos y registros de datos
Los datos operativos respaldan el monitoreo, el análisis de anomalías, la mejora de modelos, los informes de clientes y la evidencia regulatoria. El comprador debe distinguir los derechos de propiedad, custodia, uso permitido, retención y exportación de telemetría, comandos, productos derivados, registros, información del cliente y datos de capacitación.
El perímetro de transacción debe incluir datos históricos necesarios para operar y mejorar el sistema. Un comprador puede recibir software sin suficiente historial operativo para sintonizar alertas o investigar anomalías. La migración de datos debe preservar las marcas de tiempo, la procedencia, los controles de acceso y la integridad probatoria.
Las obligaciones de privacidad y localización pueden aplicarse a los datos del personal y de los clientes. Los controles de exportación y las restricciones de seguridad nacional pueden afectar los datos técnicos y el acceso de personas extranjeras. El análisis legal debe mapear las obligaciones con conjuntos de datos y ubicaciones operativas reales.
16 Examinar la resiliencia operativa y la recuperación
Las pruebas de resiliencia deben mostrar cómo continúa el servicio a través de fallas de infraestructura, software, proveedores y humanos. El comprador debe revisar la redundancia, las copias de seguridad, los entornos de recuperación, las alternativas de comunicación, los procedimientos manuales, los objetivos de recuperación y los resultados del ejercicio.
Una copia de seguridad sólo es útil cuando se puede restaurar dentro de la tolerancia de la misión. El equipo de diligencia debe observar a un representante restaurar y validar la configuración, las credenciales, las dependencias y la integridad de los datos. La recuperación debe incluir la capacidad de reconstruir sistemas cuando el entorno primario o el proveedor no están disponibles.
La adquisición en sí debe tratarse como un evento de resiliencia. Los sistemas corporativos, dominios, cuentas en la nube y contratos de soporte pueden cambiar. Un plan de transición detallado, criterios de reversión, autoridad de mando y un proceso conjunto de incidentes reducen el riesgo de transición.
17 Evaluar personas y concentración de conocimientos
La continuidad del software depende de personas que comprendan la arquitectura, las misiones, las anomalías, los clientes y el criterio operativo. El comprador debe asignar roles a procesos críticos e identificar puntos únicos de conocimiento. Los organigramas proporcionan evidencia limitada; el mapa debe reflejar quién realmente resuelve los incidentes y aprueba las liberaciones.
Las decisiones de retención deben considerar tanto la importancia técnica como la independencia. El conocimiento concentrado se puede reducir mediante el emparejamiento, la documentación, el ensayo y la sucesión. Los pagos de retención sin hitos de transferencia de conocimientos pueden preservar la dependencia en lugar de reducirla.
El modelo de transacción debe incluir costos de contratación, retención, conversión de contratistas y capacitación. El riesgo de la persona clave puede afectar la valoración cuando la capacidad no puede transferirse dentro del período de transición. La dirección debe informar el progreso en comparación con la evidencia de transferencia de conocimiento nombrada.
18 Revisar la aceptación regulatoria y del cliente
Los contratos con los clientes pueden definir el rendimiento del software, la seguridad, la auditoría, la aprobación y las obligaciones de cambio. El comprador debe identificar los contratos que requieren consentimiento, notificación, recertificación o personal designado. Debe separar los ingresos que se transfieren automáticamente de los ingresos que dependen de la aceptación del cliente.
Los clientes gubernamentales y de infraestructura crítica pueden imponer restricciones en materia de datos técnicos, autorización de seguridad, alojamiento o cadena de suministro. El comprador debe evaluar si su propiedad, financiación, personal y modelo operativo siguen siendo elegibles. Las licencias regulatorias y los derechos de espectro pueden quedar fuera de la entidad de software y, al mismo tiempo, seguir siendo esenciales para la prestación de servicios.
El modelo comercial debería ponderar la probabilidad de las renovaciones y consentimientos inciertos. La contraprestación puede depender de la transferencia verificada o de los ingresos retenidos. El comprador debe evitar pagar el valor total de contratos cuyos requisitos previos operativos no se transfieren.
19 Conectar la diligencia con la valoración
La diligencia del software cambia el valor a través del flujo de caja, el tiempo, el riesgo y la vida de la opción. La remediación aumenta el costo. La falta de derechos puede reducir los ingresos direccionables. la fragilidad operativa puede aumentar la probabilidad de interrupción. Un control de construcción débil puede retrasar el desarrollo de productos. Hay pruebas contundentes que pueden respaldar menores reservas de integración y una mayor confianza en la renovación.
El puente de valoración debería evitar la duplicación de ajustes. Un costo de soporte recurrente pertenece al flujo de caja previsto. Una reconstrucción única pertenece a usos de transacción o integración. Un defecto de derechos binarios puede requerir exclusión, depósito en garantía o una condición en lugar de una prima de tasa de descuento.
El comprador debe mostrar casos básicos, negativos y graves. Cada caso debe identificar supuestos operativos, evidencia y acciones de gestión. El valor terminal debe reflejar el mantenimiento continuo, la obsolescencia de los componentes, la concentración de proveedores y la capacidad de actualizar el producto.
20 Traducir los hallazgos en mecanismos de transacción
Los hallazgos materiales deben tener un propietario y una respuesta de transacción. Las posibles respuestas incluyen reducción de precio, retención, depósito en garantía, ganancia, indemnización, condición de cierre, convenio, servicio de transición, novación de licencia, acuerdo con persona clave o activo excluido.
Las condiciones deben ser objetivamente comprobables. El requisito de proporcionar una fuente completa es débil sin repositorios, ramas, artefactos y pruebas de aceptación definidos. Una condición de compilación puede especificar el entorno, las entradas, el conjunto de pruebas exitoso y el paquete de implementación. Una condición de acceso puede especificar identidades, privilegios, claves e inicio de sesión verificado.
El proceso de divulgación debe preservar la evidencia versionada. El comprador deberá registrar qué artefactos respaldan cada representación y quiénes aceptaron excepciones. Los cronogramas técnicos necesitan revisión por parte de ingenieros y abogados para que el lenguaje legal corresponda a la realidad operativa.
21 Diseñar la sala de control de cierre
El cierre debe gestionarse como un cambio operativo. La sala de control coordina la finalización legal, la transferencia de credenciales, la novación de proveedores, el arrendamiento de la nube, los repositorios de códigos, la autoridad de firma, los avisos a los clientes, el monitoreo y la cobertura de incidentes.
El plan debe utilizar criterios explícitos de ir, mantener y revertir. Cada paso identifica la evidencia, el momento oportuno, la persona responsable y el recurso alternativo. El acceso crítico debe probarse antes de que se produzcan acciones irreversibles. Las partes deben mantener una cobertura conjunta durante la ventana de mayor riesgo.
El comprador debe conservar los registros y las instantáneas de configuración. Estos registros establecen el estado en el momento de la transferencia y respaldan la investigación posterior. La primera liberación posterior al cierre debe seguir el proceso de garantía acordado en lugar de convertirse en una prueba de integración improvisada.
22 Establecer los primeros 100 días
Los primeros 100 días deberían estabilizar el control, cerrar las brechas de evidencia prioritaria y reducir la concentración. Las primeras acciones incluyen recertificación de acceso, rotación de credenciales, compilaciones limpias, confirmación de dependencia, corrección de atrasos críticos, pruebas de recuperación, retención de personal y gobernanza de proveedores.
Los cambios de arquitectura deben seguir la evidencia. Una migración inmediata de plataforma puede combinar la transición de propiedad con cambios técnicos y crear riesgos evitables. El equipo de integración debe secuenciar los cambios en torno a las ventanas de la misión, los compromisos del cliente y la capacidad de recuperación.
La junta debe recibir un panel conciso que cubra la reproducibilidad de la construcción, las vulnerabilidades críticas, el acceso a claves, las novaciones de proveedores, los consentimientos de los clientes, las pruebas de recuperación, la transferencia de conocimientos y el gasto. La finalización reportada debe requerir evidencia objetiva.
23 Gobernar el valor continuo del software
La gobernanza posterior al cierre debería conectar la salud del software con los resultados comerciales y financieros. Las medidas de ingeniería incluyen confiabilidad de la implementación, escape de defectos, antigüedad de la vulnerabilidad, integridad de la compilación, rendimiento de recuperación y estado de dependencia. Las medidas comerciales incluyen disponibilidad del servicio, renovación, latencia de entrega y costo de soporte.
La hoja de ruta del producto debe distinguir el mantenimiento obligatorio, los compromisos del cliente, la corrección de la seguridad y la inversión en crecimiento. El mantenimiento diferido puede inflar las ganancias a corto plazo y al mismo tiempo debilitar la generación futura de efectivo. Los comités de inversiones deberían entender esa distinción.
El comprador debe mantener un registro de evidencia de derechos, configuraciones y proveedores críticos. Los cambios de titularidad, licencia, soporte o arquitectura pueden alterar la tesis de adquisición. Las revisiones anuales de garantía y periódicas de preparación de las transacciones preservan la opcionalidad de refinanciamiento o salida.
24 Caso de transacción hipotética
El objetivo hipotético admite 18 satélites en misiones de comunicaciones, observación de la Tierra y carga útil alojada. Su plataforma incluye planificación de misiones, validación de comandos, procesamiento de telemetría, dinámica de vuelo, automatización y entrega al cliente. Los ingresos se generan a través de contratos anuales de software y operaciones.
La diligencia confirma una fuerte retención de clientes y una ingeniería capaz. También identifica cinco exposiciones de transacciones. Las construcciones de producción requieren una herramienta comercial no documentada. Dos bibliotecas tienen licencia para la empresa matriz del vendedor y no pueden transferirse automáticamente. Un administrador controla los procesos clave de producción y firma. La corrección de vulnerabilidades críticas se ha aplazado hasta las ventanas de la misión. Un adaptador específico del cliente contiene contribuciones con evidencia de asignación incompleta.
El comprador fija el precio de estos hallazgos mediante una deducción agregada USD 25 million del valor principal USD 84 million. Una ganancia adicional USD 6 million está disponible cuando se alcanzan los umbrales de evidencia definidos. La estructura preserva la participación del vendedor en la remediación y al mismo tiempo protege el efectivo del comprador al momento del cierre.
25 principios de decisión
Primero, definir la capacidad de misión adquirida y su perímetro operativo. En segundo lugar, rastrear cada artefacto crítico implementado hasta la fuente controlada, la evidencia de construcción y aprobación. En tercer lugar, propiedad separada, acceso, derechos y autoridad operativa. Cuarto, asignar la concentración de proveedores y personas a la continuidad. Quinto, prueba de recuperación y transferencia de transacciones. En sexto lugar, traducir cada dependencia no resuelta en efectivo, condición o protección contractual.
Estos principios crean un lenguaje común para los equipos de ingeniería, finanzas, operaciones y legal. También mejoran la velocidad de las transacciones porque las solicitudes de pruebas y las pruebas de aceptación se vuelven específicas.
El objetivo del comprador es un control demostrable de los resultados de la misión. Ese control respalda la continuidad, la confianza del cliente, la integración y la valoración defendible.
26 Revisión de arquitectura y deuda técnica
La diligencia de la arquitectura debe explicar cómo el sistema separa la planificación de la misión, la dinámica de vuelo, la validación de comandos, la telemetría, la automatización, la identidad, los almacenes de datos y las interfaces externas. El comprador debe identificar los límites de confianza, los dominios de falla, los servicios compartidos y los componentes cuyo cambio podría afectar varias misiones. Los diagramas de arquitectura deben conciliarse con la topología implementada, los flujos de red y la propiedad del repositorio.
La deuda técnica debe expresarse a través de consecuencias. Un lenguaje de programación antiguo puede seguir siendo manejable cuando se dispone de experiencia, pruebas y cadenas de herramientas. Un servicio moderno puede resultar frágil cuando carece de propiedad, observabilidad o recuperación. El equipo de diligencia debe estimar el costo, la secuenciación y el riesgo operativo de cada elemento importante de la deuda.
La clasificación de la deuda debe distinguir mantenibilidad, seguridad, rendimiento, escalabilidad, obsolescencia y cumplimiento. El modelo comercial debe reflejar las categorías que limitan el crecimiento o la retención de clientes. Los planes de remediación deben identificar dependencias y ventanas de misión en lugar de presentar un trabajo atrasado indiferenciado.
27 Evaluar la observabilidad y la evidencia de incidentes.
El valor del control de la misión depende de la capacidad de detectar y explicar comportamientos anormales. El comprador debe revisar registros, métricas, seguimientos, alertas, paneles, retención, sincronización de relojes y registros de incidentes. Debe identificar dónde se generan los datos, quién puede acceder a ellos y si los registros sobreviven a una falla del sistema o del proveedor.
La calidad de las alertas merece un muestreo. Grandes volúmenes de alertas inaccionables pueden ocultar eventos importantes. Las alertas escasas pueden reflejar una cobertura limitada. El equipo debe comparar los incidentes seleccionados con la telemetría registrada, las acciones de respuesta, el análisis de la causa raíz y el trabajo correctivo. Los incidentes repetidos sin una solución duradera indican debilidad en el control.
La planificación de transacciones debe preservar la continuidad del seguimiento. La migración de cuentas, la separación de la nube o el reemplazo de herramientas pueden crear períodos ciegos. El plan de cierre debe definir qué alertas permanecen activas, quién las recibe y cómo el equipo conjunto maneja un evento durante la transición. La evidencia de un monitoreo estable puede respaldar un período de transición de servicios más corto.
28 Pruebe la escalabilidad y la expansión de la flota
El rendimiento histórico no establece que la plataforma pueda soportar la flota planificada del comprador. El equipo debe identificar los factores de escala, como satélites, contactos, volumen de telemetría, carga de comando, interfaces de clientes, operadores concurrentes y sitios terrestres. Debería revisar la utilización máxima observada y los márgenes de capacidad.
Las pruebas de carga deben utilizar patrones de mensajes y condiciones de falla representativos. Las operaciones espaciales pueden crear períodos cortos de intensa actividad en torno al lanzamiento, la puesta en servicio, anomalías y ventanas de contacto. La utilización promedio puede ocultar colas, contención de bases de datos o sobrecarga del operador durante estos períodos.
El argumento del crecimiento debería incluir costos de infraestructura, licencias, soporte y personal. Una plataforma que escala técnicamente puede enfrentar límites comerciales debido a los precios de los proveedores por satélite o a la escasez de especialistas. El modelo de valoración debe alinear el crecimiento de los ingresos con el capital y los costos operativos necesarios para lograrlo.
29 Evalúe cuidadosamente las características de la inteligencia artificial
Los objetivos pueden utilizar el aprendizaje automático para la detección de anomalías, la programación, el procesamiento de imágenes, el mantenimiento predictivo o la asistencia al operador. La diligencia debe identificar la decisión exacta respaldada, el propietario del modelo, los derechos de los datos de capacitación, la validación, el monitoreo, la supervisión humana y la respuesta ante fallas. Las descripciones de marketing proporcionan evidencia limitada de valor operativo.
El comprador debe comparar el desempeño reclamado con una línea de base definida y datos representativos de la misión. Debe examinar los falsos positivos, los falsos negativos, la deriva, el reentrenamiento, el control de versiones y los casos extremos. Un modelo que mejora la detección promedio puede seguir siendo inadecuado para decisiones de comando cuando sus modos de falla son opacos.
Las herramientas generativas utilizadas en ingeniería u operaciones necesitan gobernar los datos confidenciales, la procedencia del código y la revisión de los resultados. La hoja de ruta del producto debe separar el valor demostrado para el cliente de la capacidad experimental. La valoración debe reconocer los ingresos relacionados con AI solo cuando se demuestren los derechos, el desempeño, el despliegue y la conversión de efectivo.
30 Revisar el control de exportaciones y las restricciones de acceso soberano
El software, los datos técnicos y los servicios satelitales pueden estar sujetos a controles de exportación, sanciones, clasificaciones de seguridad y requisitos de acceso soberano. El comprador debe mapear los artículos controlados, las licencias, las nacionalidades, las ubicaciones, las regiones de la nube y las restricciones de los clientes. El abogado especialista debe interpretar el régimen jurídico aplicable.
El acceso operativo puede verse limitado incluso cuando se transfiere la propiedad. Ciertos clientes pueden requerir personal autorizado, hosting nacional o soporte segregado. La propiedad y la estructura financiera del comprador pueden dar lugar a una revisión o consentimiento. Estos factores afectan el diseño de integración y la capacidad de centralizar operaciones.
El modelo de transacción debe incluir personal de cumplimiento, entornos segregados, plazos de licencia y posibles restricciones de ingresos. Las condiciones de cierre deben abordar las aprobaciones que son necesarias para la continuidad. La dirección debería evitar garantías amplias e identificar el ámbito preciso que cubre cada autorización.
31 Crear un paquete de evidencia para el comité de inversiones
El comité de inversiones necesita una conexión concisa entre los resultados técnicos y las decisiones económicas. El paquete debería comenzar con la capacidad adquirida, la dependencia de los ingresos y los puntos críticos de control. Debe presentar la fuente y generar evidencia, la posición de los derechos, el mapa de proveedores, la resiliencia operativa, los consentimientos de los clientes y la concentración de personas.
Cada hallazgo material debe mostrar el estado de la evidencia, las consecuencias en efectivo, el mecánico propuesto, el propietario responsable y el riesgo residual. El comité debería poder distinguir una brecha verificada de una estimación de la gestión y una promesa de remediación futura. El análisis de escenarios debería mostrar el efecto de los retrasos y los fracasos combinados.
La aprobación debe indicar las condiciones, las autoridades delegadas y los informes posteriores al cierre. El paquete de evidencia se convierte entonces en la base para la gobernanza de la integración. Esta continuidad reduce el riesgo de que los hallazgos de la diligencia desaparezcan después del cierre y respalda la responsabilidad posterior por la creación de valor.
32 Plan de separación del vendedor
Una exclusión requiere un modelo de separación que abarque aplicaciones, infraestructura, identidades, redes, contratos, datos y personas. El comprador debe identificar los servicios que permanecen con el vendedor, los servicios que se transfieren y los servicios que deben reconstruirse. Cada línea debe tener un método operativo provisional, un estado objetivo, un costo, una dependencia y un criterio de salida.
Los acuerdos de servicios de transición deben describir servicios mensurables y responsabilidades operativas. Deben identificar los niveles de servicio, las obligaciones de seguridad, la coordinación de incidentes, el acceso, el control de cambios, la devolución de datos, los derechos de auditoría, los precios y la terminación. Un compromiso amplio de brindar asistencia razonable puede dejar sin resolver necesidades críticas de la misión.
El calendario de separación debe ajustarse a las limitaciones de la misión. Los cambios de identidad o de red pueden afectar las rutas de monitoreo y comando. La migración de datos puede afectar el historial y la evidencia de auditoría. La novación de proveedores puede cambiar los derechos de soporte. Las partes deben realizar cambios de alto riesgo y preservar la reversión hasta que se cumplan los criterios de aceptación.
La preparación para la salida debe probarse antes de que finalice un servicio de transición. El comprador debe demostrar acceso, construcción, implementación, monitoreo, soporte y recuperación independientes. También debe confirmar que las cuentas y los datos del vendedor se pueden eliminar sin interrumpir el servicio. Cualquier extensión debe tener un motivo, un precio y un propietario de remediación definidos.
El costo de separación pertenece al modelo de transacción. Incluye infraestructura duplicada, licencias temporales, ingeniería de migración, pruebas de seguridad, validación de clientes y superposición operativa. La estimación debe distinguir las cotizaciones comprometidas de los supuestos de gestión. Un plan de separación financiado y gobernado protege la continuidad e impide que la transacción tenga una dependencia indefinida del vendedor.
La junta debería recibir un panel de separación semanal hasta que todos los servicios de misión crítica funcionen de forma independiente. El panel debe identificar las dependencias vencidas, las salidas probadas, las obligaciones no resueltas del cliente, el costo previsto y la próxima acción irreversible. El cierre debe requerir evidencia de ingeniería, operaciones, seguridad, finanzas y el propietario del servicio correspondiente.
Apéndice A Registro de pruebas de diligencia
El registro de evidencia debe identificar la pregunta, el artefacto solicitado, el propietario de la fuente, la versión, el resultado de la revisión, la excepción, la consecuencia financiera y la respuesta de la transacción. Debe permanecer vinculado a la sala de datos virtual para que se puedan reproducir las conclusiones.
La evidencia de alta prioridad incluye el inventario de producción, el mapa del repositorio, el resultado de la compilación limpia, el seguimiento de la implementación, el inventario de privilegios, el cronograma de licencias, el SBOM, el trabajo pendiente de vulnerabilidad, la prueba de recuperación, el mapa de consentimiento del cliente y el plan de la persona clave. Cada elemento debe identificar los sistemas y configuraciones exactos cubiertos.
El muestreo debe basarse en el riesgo. El equipo debe elegir misiones representativas de altas consecuencias, interfaces críticas, lanzamientos recientes, cambios de emergencia y componentes más antiguos. Las muestras deben probar tanto el diseño del control como la ejecución real.
Apéndice B Método de valoración
El método ilustrativo comienza con el valor empresarial derivado del modelo comercial del comprador. Luego ajusta el flujo de caja previsto para los costos recurrentes de mantenimiento y proveedores. Los costos únicos de remediación, separación y transición se incluyen en los usos. Los ingresos sujetos al consentimiento del cliente están ponderados por probabilidad. Los defectos de los derechos y las condiciones operativas se abordan mediante deducciones, plicas o contraprestaciones contingentes.
El análisis de escenarios debe combinar los riesgos relacionados. Un retraso del proveedor también puede retrasar la remediación y la aceptación del cliente. La salida de una persona clave puede debilitar tanto la continuidad como la transferencia de conocimientos. Los inconvenientes correlacionados merecen un tratamiento explícito.
Ningún número hipotético en este documento representa una transacción identificada. El caso demuestra cómo se pueden conectar las pruebas con la valoración y la estructura de la transacción.
Apéndice C Pruebas de aceptación de cierre
Las pruebas de aceptación deben cubrir el acceso al repositorio, compilación limpia, ejecución de pruebas, firma de paquetes, implementación no productiva, restauración de configuración, monitoreo, acceso privilegiado, soporte y recuperación del proveedor. Las partes deben acordar los datos de prueba, el entorno, los criterios de aprobación y las pruebas antes de firmar.
Las pruebas deben evitar interrupciones operativas en vivo. Los cambios de producción requieren la aprobación de la misión y controles separados. Una prueba que no sea de producción aún puede validar la cadena desde la fuente controlada hasta el artefacto implementable.
Las pruebas fallidas deberían tener consecuencias predefinidas. Estos pueden incluir subsanación, depósito en garantía, cierre retrasado, contraprestación reducida o exclusión de un activo. La respuesta debe coincidir con la importancia operativa y financiera del fracaso.
Apéndice D Cifras y tablas de decisión
Progresión de evidencia ilustrativa; Los valores son hipotéticos y no representan una empresa identificada.
Puntuaciones más altas indican una mayor dependencia en el caso hipotético.
Secuencia propuesta; El momento real depende de los hechos de la transacción y de las limitaciones de la misión.
Valores totalmente hipotéticos; USD millones.
Secuencia propuesta sujeta a ventanas de misión y obligaciones del cliente.
| Evidencia | Pregunta de transacción | Indicador de aceptación | Respuesta a la brecha |
|---|---|---|---|
| Inventario del repositorio | ¿Está controlada toda la fuente de materiales? | Seguimiento de componentes de producción hasta repositorios nombrados | Condición de finalización o exclusión de alcance |
| Definición de compilación | ¿Puede un ambiente limpio producir una liberación? | Construcción controlada exitosa con entradas documentadas | Plan de retención y remediación |
| Procedencia | ¿Se pueden rastrear los artefactos desplegados? | Versión, dependencias, aprobación y firma vinculadas | Reserva de riesgos y remediación de controles |
| Artefactos generados | ¿Hay modelos y generadores disponibles? | Es posible reconstruir a partir de fuentes controladas | Condición de transferencia de licencia o activo |
Requisitos de evidencia de transacciones propuestos.
| Dependencia | Evidencia | Exposición principal | Tratamiento de transacciones |
|---|---|---|---|
| código de empleado | Condiciones de empleo e invención | Brecha de propiedad | Cesión y garantía |
| Trabajo de contratista | Declaración de trabajo y asignación | Modificación o transferencia restringida | Cesión específica o indemnización |
| software comercial | Términos de licencia y soporte | No transferencia, rescisión o reposición de precios | Novación, sustitución o deducción |
| Software de código abierto | SBOM, licencia y registro de distribución. | Cumplimiento y mantenimiento | Plan de curación y gobernanza continua |
| Interfaz del cliente | Historial de contratos y contribuciones | Uso restringido a clientes existentes | Consentimiento o valor contingente |
Propuesta de clasificación de dependencia jurídica y operativa.
| Artículo | USD millones | Base de evidencia | Tratamiento |
|---|---|---|---|
| Valor empresarial principal | 84 | Modelo comercial | Valor inicial |
| Remediación y transición | -9 | Plano de construcción, vulnerabilidad y separación. | Deducción de cierre |
| Derechos y dependencias | -7 | Brechas de licencia y procedencia | Deducción o depósito en garantía |
| Concentración y fragilidad | -5 | Acceso y revisión de persona clave | Reserva de integración |
| Aceptación del cliente | -4 | Consentimiento y evidencia de interfaz | Consideración contingente |
| Valor en efectivo al cierre | 59 | Marco agregado | Resultado ilustrativo |
Totalmente hipotético; USD millones.
| Control | Pruebas antes del traslado | Acción de cierre | Verificación posterior al cierre |
|---|---|---|---|
| Repositorios | Lista de acceso y sucursales protegidas | Administradores de transferencia | Conciliar acceso y registros |
| Firma | Inventario clave y cadena de aprobación | Rotar o volver a registrar claves | Lanzamiento de prueba firmado que no es de producción |
| Acceso a la producción | Inventario de privilegios | Revocar cuentas exclusivas de vendedor | Recertificar el acceso humano y de servicios |
| Proveedores | Cronograma de contrato y consentimiento | Ejecutar novaciones | Confirmar contactos de soporte e incidencias |
| Recuperación | Último ejercicio y inventario de respaldo | Conservar instantáneas | Ejecutar restauración controlada |
Controles propuestos; la secuenciación real depende de las limitaciones de la misión.
| Medida | Evidencia del día 30 | Evidencia del día 60 | Prueba del día 100 |
|---|---|---|---|
| Control de construcción | Ambiente limpio establecido | Productos críticos reproducidos | Evidencia de liberación de rutina completa |
| Acceso | Administradores recertificados | Cuentas de servicio asignadas | Excepciones cerradas o aceptadas |
| Vulnerabilidades | Trabajo pendiente crítico validado | Curas prioritarias probadas | Niveles de servicio sostenibles operativos |
| Proveedores | Dependencias críticas confirmadas | Progresaron las novaciones y suplentes | Aprobados planes de gobernanza y salida |
| Conocimiento | Funciones clave retenidas | Runbooks y emparejamiento en marcha | Cobertura operativa independiente probada |
Hitos de evidencia propuestos.
| Descubrimiento | Efecto efectivo | mecanico contratado | Pruebas de liberación |
|---|---|---|---|
| Dependencia intransferible | USD 7 million | Depósito en garantía o deducción de precio | Novación ejecutada o sustitución calificada |
| Construir fragilidad | USD 4 million | condición de cierre | Construcción y prueba limpias exitosas |
| Dependencia de persona clave | USD 3 million | Retención vinculada a la retención | Hitos de la transferencia de conocimientos |
| Derechos específicos del cliente | USD 4 million | Ganar | Consentimiento y cobro de efectivo retenido |
Efectos de efectivo totalmente hipotéticos; USD millones.
| Área de decisión | Evidencia verde | Condición ámbar | Condición roja |
|---|---|---|---|
| control de fuente | Repositorios completos rastreables | Brechas menores controladas | Falta fuente o historial crítico |
| Construir | Liberación controlada repetible | Pasos manuales con cura financiada. | La compilación no se puede reproducir |
| Derechos | Derechos documentados transferibles | Consentimiento pendiente con protección | Derecho material no disponible |
| Operaciones | Cobertura con personal independiente | Concentración con transición probada. | Dependencia de una persona designada sin respaldo |
| Recuperación | Restauración exitosa reciente | Ejercicio de alcance parcial o antiguo. | Recuperación no probada o no disponible |
Umbrales de decisión propuestos.
Fuentes
- Instituto Nacional de Estándares y Tecnología, SP 800-218 Marco de desarrollo de software seguro versión 1.1, 2022. Lea la fuente principal
- Instituto Nacional de Estándares y Tecnología, SP 800-161 Revisión 1 Prácticas de gestión de riesgos de la cadena de suministro de ciberseguridad para sistemas y organizaciones, 2022. Lea la fuente principal
- Instituto Nacional de Estándares y Tecnología, Guía de seguridad de software en las cadenas de suministro, actualizada en 2024. Lea la fuente principal
- Instituto Nacional de Estándares y Tecnología, Marco de Ciberseguridad 2.0, 2024. Lea la fuente principal
- Instituto Nacional de Estándares y Tecnología, NISTIR 8401 Segmento terrestre de satélites que aplica el marco de ciberseguridad al comando y control de satélites, 2022. Lea la fuente principal
- Instituto Nacional de Estándares y Tecnología, SP 800-53 Revisión 5 Controles de seguridad y privacidad para organizaciones y sistemas de información. Lea la fuente principal
- Administración Nacional de Aeronáutica y del Espacio, Manual de garantía e ingeniería de software de la NASA NASA-HDBK-2203. Lea la fuente principal
- Administración Nacional de Aeronáutica y del Espacio, Acceso electrónico al código fuente SWE-042. Lea la fuente principal
- Administración Nacional de Aeronáutica y del Espacio, SWE-158 Evaluación de software para detectar vulnerabilidades de seguridad. Lea la fuente principal
- Administración Nacional de Aeronáutica y del Espacio, Entradas de software de generación automática SWE-206. Lea la fuente principal
- Administración Nacional de Aeronáutica y del Espacio, NPR 7150.2 Requisitos de ingeniería de software de la NASA. Lea la fuente principal
- Administración Nacional de Aeronáutica y del Espacio, NASA-STD-8739.8 Estándar de seguridad y garantía de software. Lea la fuente principal
- Administración Nacional de Aeronáutica y del Espacio, Estándar de protección del sistema espacial NASA-STD-1006A. Lea la fuente principal
- Administración Nacional de Aeronáutica y del Espacio, Guía de mejores prácticas de seguridad espacial. Lea la fuente principal
- Agencia de Seguridad de Infraestructura y Ciberseguridad, Prácticas recomendadas para desarrolladores para garantizar la cadena de suministro de software, 2023. Lea la fuente principal
- Agencia de Ciberseguridad y Seguridad de Infraestructura, Lista de Materiales de Software. Lea la fuente principal
- Agencia de Ciberseguridad y Seguridad de Infraestructuras, Secure by Design. Lea la fuente principal
- Agencia de Seguridad de Infraestructura y Ciberseguridad, Manuales de estrategia de respuesta a vulnerabilidades e incidentes de ciberseguridad del gobierno federal. Lea la fuente principal
- Agencia Espacial Europea, Productos de software para operaciones de misiones. Lea la fuente principal
- Agencia Espacial Europea, SPACE-SHIELD Capacidades maliciosas de la cadena de suministro y vulnerabilidades de software. Lea la fuente principal
- Agencia de Ciberseguridad de la Unión Europea, ENISA Space Threat Landscape 2025. Lea la fuente principal
- Comité Consultivo para Sistemas de Datos Espaciales, Operaciones de Misiones y Servicios de Gestión de Información. Lea la fuente principal
- Comité Consultivo para Sistemas de Datos Espaciales, Publicaciones del Grupo de Trabajo de Seguridad. Lea la fuente principal
- Oficina de Comercio Espacial de los Estados Unidos, Directiva de política espacial 5 Principios de ciberseguridad para sistemas espaciales. Lea la fuente principal
- Centro Nacional de Seguridad Cibernética del Reino Unido, Conjunto de herramientas de seguridad cibernética para juntas directivas. Lea la fuente principal
- Proyecto abierto mundial de seguridad de aplicaciones, estándar de verificación de componentes de software. Lea la fuente principal
- Proyecto abierto mundial de seguridad de aplicaciones, modelo de madurez de Software Assurance. Lea la fuente principal
- The Linux Foundation, intercambio de datos del paquete de software SPDX. Lea la fuente principal
- Organización Internacional de Normalización, ISO IEC 27001 Sistemas de gestión de seguridad de la información. Lea la fuente principal
- Cooperación europea para la estandarización espacial, Estándares de ingeniería de software ECSS. Lea la fuente principal
