Soporte técnico
Documentación
Inicio de sesión
Contáctenos
Ir directamente al resumen generado por IA de esta entrada del blog 
Principales conclusiones
- A falta de una evaluación realizada por un tercero, el director general o un empleado designado por él y autorizado para comprometer a la empresa firma el formulario.
- El firmante certifica, según su leal saber y entender, que el productor aplica actualmente de forma sistemática las prácticas descritas en el formulario.
- Según el memorándum M-26-05 de la OMB, ahora cada organismo federal decide si solicita el formulario, por lo que un organismo al que le vendas productos aún puede exigírtelo.
- El software de código abierto de terceros queda fuera del ámbito de aplicación directo del formulario; no obstante, los fabricantes siguen declarando que gestionan los riesgos asociados al mismo.
Si una agencia federal solicita el formulario de certificación de desarrollo de software seguro y su empresa realiza una autocertificación en lugar de adjuntar una evaluación realizada por un tercero, el firmante debe ser su director ejecutivo (CEO) o una persona designada por él que sea empleada de la empresa y tenga autoridad para comprometer a la sociedad. En virtud del memorándum M-26-05 de la Oficina de Gestión y Presupuesto (OMB), de fecha 23 de enero de 2026, ahora es decisión de cada agencia si solicita o no dicho documento.
Es posible que esa persona nunca se haya fijado en cómo se incorporan las dependencias de código abierto a tus compilaciones, pero su nombre acaba figurando en una declaración sobre cómo gestiona tu empresa el riesgo que supone el código que tu equipo no ha escrito.
El formulario solicita que una persona certifique las prácticas que llevan a cabo varios equipos. Esa certificación incluye condiciones, y varios de sus términos dejan en manos del responsable decidir qué cumple con ellos. Un firmante que comprenda tanto las condiciones como los términos abiertos estará en una posición mucho mejor para firmar un documento preciso.
Cómo pasó a ser opcional el formulario de certificación de desarrollo seguro de software
La Agencia de Ciberseguridad y Seguridad de las Infraestructuras (CISA) publicó el formulario el 11 de marzo de 2024. Los productores de software —es decir, las empresas que crean o compilan el software— lo utilizan para certificar que el producto que comercializan se ha desarrollado de conformidad con unas prácticas de desarrollo seguro específicas.
Durante algunos años, la OMB hizo obligatoria dicha certificación. El memorándum M-22-18, publicado el 14 de septiembre de 2022 y actualizado por el memorándum M-23-16 el 9 de junio de 2023, permite a un organismo utilizar el software afectado únicamente después de que su fabricante certifique que aplica prácticas de desarrollo seguro alineadas con el Marco de Desarrollo Seguro de Software (SSDF).
Posteriormente, el 23 de enero de 2026, la circular M-26-05 derogó ambos memorandos. Ahora, los organismos pueden optar por utilizar o no el formulario de la CISA. También pueden incluir cláusulas contractuales que exijan al fabricante facilitar una lista de componentes de software (SBOM) actualizada cuando se le solicite. El formulario en sí no se ha revisado y sigue citando los dos memorandos derogados como fundamento jurídico, por lo que algunas de sus instrucciones ya no son aplicables.
En el caso de un productor que no pueda dar fe de todas las prácticas, el formulario describe, no obstante, un plan de acción y unos hitos (POA&M) para subsanar las deficiencias, respaldado por una prórroga o una exención de la OMB. La norma M-26-05 no establece ningún sustituto para ese proceso, por lo que un productor que se encuentre en esa situación debería preguntar a la agencia solicitante qué alternativa acepta.
Lo que afirma el firmante y lo que queda en el aire
La sección III del formulario, titulada «Certificación y firma», solicita que una persona declare, en nombre del productor, que el software se ha desarrollado de conformidad con las prácticas que en ella se enumeran. En ella se recogen cuatro afirmaciones numeradas, precedidas de dos condiciones. El firmante certifica que, «según mi leal saber y entender», el productor «utiliza de forma sistemática» dichas prácticas en el desarrollo del software mencionado en la sección I. Dichas prácticas abarcan el entorno de compilación, la cadena de suministro del código, la procedencia (registros del origen del código y de cómo se ha compilado) y la forma en que el productor detecta y gestiona las vulnerabilidades. Ninguna disposición de la sección III exige al firmante que declare que el software está libre de vulnerabilidades.
Ambos calificativos restringen el alcance de la declaración. «En la actualidad» se refiere a las prácticas vigentes en el momento de la firma del formulario, y «según mi leal saber y entender» limita la declaración a lo que el firmante conoce. Ni las instrucciones ni la sección III especifican qué debe hacer el firmante para confirmar que las prácticas se están aplicando, y la persona designada no necesita ocupar ningún cargo concreto. Por lo tanto, el responsable decide quién da fe de las prácticas —por ejemplo, los equipos que gestionan las compilaciones— antes de que nadie firme. Una firma basada en ese fundamento solo es tan fundamentada como lo sean esos equipos.
Tabla 1. Lo que especifica el formulario sobre la firma
| Artículo | Lo que dice el formulario | Fundamentos |
|---|---|---|
| Firmante | El director general de la empresa de software, o una persona designada por él que sea empleado y tenga autoridad para obligar a la sociedad | Instrucciones para rellenar el formulario |
| Alcance | A nivel de toda la empresa, un producto concreto, varios productos o versiones específicas de un producto | Formulario, Sección I |
| Alternativa | Si se adjunta al formulario un informe de evaluación realizado por un tercero, el productor no tiene que firmarlo. | Instrucciones para rellenar el formulario y sección III |
Un productor puede adjuntar una evaluación realizada por un tercero en lugar de firmar. El evaluador debe ser una organización de evaluación independiente (3PAO) que esté certificada en el marco del Programa Federal de Gestión de Riesgos y Autorizaciones (FedRAMP) o que cuente con la aprobación por escrito de un funcionario competente de la agencia correspondiente. Asimismo, debe realizar la evaluación con arreglo a las directrices pertinentes del Instituto Nacional de Estándares y Tecnología (NIST), que incluyen todos los elementos del formulario. FedRAMP se refiere ahora a estas organizaciones como evaluadores independientes, aunque el formulario de la CISA sigue utilizando el término 3PAO. Para utilizar una evaluación, el productor marca una casilla en la sección III y la adjunta.
Dónde se incluyen los componentes de terceros en el estado financiero
La sección I enumera cuatro categorías que el formulario no cubre. Una de ellas es lo que denomina «componentes de código abierto y propietarios de terceros», es decir, aquellos incorporados al producto de software final que utiliza una agencia. Una nota en la misma sección indica que los firmantes certifican el cumplimiento de las prácticas de la sección III para el código desarrollado por el productor. Sin embargo, las instrucciones indican que los productores que utilicen componentes de terceros deben certificar que han tomado las medidas específicas de la sección III para minimizar los riesgos derivados de su uso. Leídas en conjunto, la exclusión y las instrucciones implican que el firmante no responde del código de terceros en sí mismo, sino únicamente de las medidas adoptadas por el productor para gestionar ese riesgo.
Las declaraciones 2 y 3 son aquellas en las que se mencionan expresamente los componentes de terceros. La declaración 2 exige un «esfuerzo de buena fe» para mantener cadenas de suministro de código fuente fiables, utilizando «herramientas automatizadas o procesos equivalentes» para abordar la seguridad del código interno y de los componentes de terceros, así como para gestionar las vulnerabilidades relacionadas. La declaración 3 exige al productor que mantenga la procedencia del código interno y de los componentes de terceros «en la mayor medida posible». A modo de referencia, el anexo del formulario se corresponde con las tareas del SSDF, incluida la tarea de verificar los componentes de código abierto.
Ambas afirmaciones dejan margen para la interpretación. El formulario nunca define qué se entiende por «cadenas de suministro de código fuente fiables» o «procesos comparables», y tampoco especifica qué grado de trazabilidad se considera viable. Cada productor debe determinar por sí mismo qué significan esos términos para su propio software, y el firmante da fe del resultado únicamente según su leal saber y entender.
Además, dependen de saber qué código de terceros contiene una compilación, y el formulario deja que sea el productor quien decida el método a seguir. Un productor que no pueda enumerar ese código no tiene forma de saber si cumple con alguno de los dos requisitos.
La sección III tampoco dice nada sobre los componentes cuyo mantenimiento por parte del desarrollador original haya finalizado. La afirmación 4 sigue exigiendo una política o un proceso para abordar las vulnerabilidades detectadas antes del lanzamiento. En el caso de un componente cuyos mantenedores hayan dejado de publicar correcciones, dicha política no puede basarse en una versión del desarrollador original. Esto deja opciones como sustituir el componente o aplicar parches a la versión en uso, ya sea internamente o a través de un proveedor que adapte las correcciones a versiones anteriores.
Lo que viene después de la firma
La firma del formulario implica compromisos que se extienden más allá de la fecha de firma. La sección III incluye una declaración en la que el fabricante se compromete a notificar a cualquier organismo que haya recibido el formulario «en caso de que» deje de aplicar de forma sistemática dichas prácticas. Una nota al pie añade que dicha declaración es vinculante para las futuras versiones del producto mencionado hasta que el fabricante comunique a dichas agencias que sus prácticas de desarrollo ya no se ajustan a lo establecido. La obligación de notificación recae del fabricante hacia las agencias, y el formulario no especifica cómo se comunicará al firmante la noticia de un incumplimiento. Es probable que los equipos que gestionan las prácticas sean los primeros en detectar un incumplimiento. El fabricante necesita un proceso para que dichos equipos lo comuniquen al firmante.
La declaración relativa a la Ley de Protección de Datos Personales que figura en el formulario, redactada para el Departamento de Seguridad Nacional, detalla dos consecuencias. El hecho de no facilitar la información solicitada puede llevar a la agencia a dejar de utilizar el software. Facilitar de forma deliberada información falsa o engañosa puede constituir una infracción del artículo 1001 del título 18 del Código de los Estados Unidos (18 U.S.C. § 1001).
Nota: Cada organismo que utilice el formulario debe proporcionar su propia declaración relativa a la Ley de Protección de Datos, por lo que el texto sobre las consecuencias que vea el firmante puede variar según el organismo.
Un firmante que desee que la certificación sea precisa debería averiguar, antes de firmar, qué equipos avalan cada práctica, cómo ha definido el productor términos como «procesos comparables» y «viable», y cómo informarán dichos equipos en caso de incumplimiento.
Saber qué se incluye en tus compilaciones
SecureChain, de TuxCare, analiza el código de cada paquete de código abierto en busca de malware oculto y vuelve a compilar el paquete a partir del código fuente en entornos aislados y reforzados. Los paquetes que no superan la comprobación no se incorporan a su entorno. Cada paquete que recibe incluye una SBOM en la que se detallan sus contenidos y un registro de procedencia. Mientras el desarrollador original siga manteniendo un paquete, SecureChain le aplica parches en virtud de un acuerdo de nivel de servicio (SLA), y el servicio Endless Lifecycle Support (ELS) continúa proporcionando correcciones una vez finalizado el mantenimiento por parte del desarrollador original. SecureChain cubre las dependencias de código abierto en JavaScript, Python, Java, Go y PHP.
Si tu equipo no sabe qué contienen las dependencias de código abierto que se incorporan a tus compilaciones, ni quién las actualiza una vez que el desarrollador original deja de hacerlo, SecureChain responde a ambas preguntas.
PREGUNTAS FRECUENTES
¿Qué es el formulario de certificación de desarrollo de software seguro de la CISA?
Es el formulario que utilizan los fabricantes de software para certificar que su software se ha desarrollado de conformidad con las prácticas derivadas del Marco de Desarrollo de Software Seguro (SSDF). La Agencia de Ciberseguridad y Seguridad de las Infraestructuras (CISA) lo publicó el 11 de marzo de 2024. Cuando el fabricante realiza la autocertificación, la firma la realiza el director ejecutivo (CEO) o una persona designada que sea un empleado con autoridad para obligar a la empresa. El fabricante también puede adjuntar una evaluación realizada por un tercero.
¿El formulario de certificación de desarrollo seguro de software es opcional o sigue siendo obligatorio?
Ya no es un requisito aplicable a toda la Administración. El memorándum M-26-05 de la Oficina de Gestión y Presupuesto (OMB), con fecha del 23 de enero de 2026, derogó los memorandos M-22-18 (14 de septiembre de 2022) y M-23-16 (9 de junio de 2023), que permitían a los organismos utilizar el software afectado únicamente tras la certificación del fabricante. Ahora cada organismo decide si utiliza el formulario, por lo que es posible que algún organismo concreto te lo siga solicitando.
¿Qué programas incluye el formulario?
Las instrucciones se aplican al software desarrollado a partir del 14 de septiembre de 2022 (fecha del memorándum M-22-18 de la OMB), al software anterior que haya sufrido un cambio de versión importante después de esa fecha y al software cuyo fabricante realice actualizaciones continuas, como el software como servicio. Dichas normas procedían de los memorandos M-22-18 y M-23-16, que fueron derogados por el M-26-05, por lo que una agencia que solicite el formulario ahora puede establecer su propio ámbito de aplicación. Hay que consultar las instrucciones y las condiciones contractuales de la agencia solicitante. La sección I del formulario también enumera cuatro categorías que no están cubiertas por el mismo, entre ellas los componentes de terceros integrados en el producto.
¿Cómo gestiona el formulario los componentes de terceros y de código abierto?
Quedan excluidos de su ámbito de aplicación los componentes de código abierto y propietarios de terceros integrados en el producto. Sus instrucciones también indican que los fabricantes que utilicen componentes de terceros deben certificar que han tomado las medidas enumeradas en la sección de certificación del formulario, la Sección III, para minimizar los riesgos derivados de su uso. Dos de esas medidas, relativas a la seguridad de la cadena de suministro y a la procedencia, mencionan los componentes de forma directa.
¿Qué indica el formulario sobre la información falsa o incompleta?
En su declaración relativa a la Ley de Privacidad, redactada para el Departamento de Seguridad Nacional, se indica que, si no se facilita la información solicitada, la agencia podría dejar de utilizar el software. Facilitar de forma deliberada información falsa o engañosa puede constituir una infracción del artículo 1001 del título 18 del Código de los Estados Unidos (18 U.S.C. § 1001), una disposición penal. Cada agencia que utiliza el formulario proporciona su propia declaración relativa a la Ley de Privacidad.
¿Puede una evaluación realizada por un tercero sustituir a la firma?
Sí. Un productor puede adjuntar una evaluación realizada por una organización de evaluación de terceros (3PAO) que esté certificada en el marco del Programa Federal de Gestión de Riesgos y Autorizaciones (FedRAMP) o que cuente con la aprobación por escrito de un funcionario competente de la agencia correspondiente. La 3PAO debe evaluar todos los elementos del formulario con arreglo a las directrices pertinentes del NIST. A continuación, el productor marca la casilla de la sección III, adjunta la evaluación y no firma.
¿Qué ocurre con una certificación cuando el software pasa a una nueva versión?
Una certificación es vinculante para las futuras versiones del producto mencionado hasta que el fabricante notifique a los organismos que sus prácticas de desarrollo ya no cumplen con los requisitos. Esto concuerda con un compromiso que figura en la propia sección de firma, en la que el fabricante se compromete a notificar a cualquier organismo que haya recibido el formulario en caso de que deje de aplicar de forma sistemática dichas prácticas.
