¿Vender software al gobierno de los EE. UU.? Conozca la atestación de seguridad primero

En los últimos meses, el gobierno de EE. UU. ha introducido varios requisitos nuevos que afectan a las organizaciones que venden software a agencias gubernamentales. Debido a que estos nuevos requisitos son complejos, muchos líderes aún no están seguros de cómo se verá afectada su organización. En este artículo, compartiré algunos de los conceptos más importantes que deberá comprender para poder proteger su negocio gubernamental y cumplir con las normas.

Nuevos requisitos de seguridad del software: ¿Qué ha cambiado?

En los últimos años, incidentes de seguridad de alto perfil como los que afectaron Vientos solares y el paquete de código abierto log4j han aumentado la atención del gobierno en la seguridad del software. Empezando con Orden Ejecutiva de la Casa Blanca 14028 sobre la mejora de la seguridad cibernética de la nación en mayo de 2021, una serie de acciones durante los últimos dos años han llevado a un conjunto de requisitos claros que impactan a cualquier proveedor de software del gobierno.

En el futuro, cualquier organización que venda software al gobierno de EE. UU. deberá autocertificar que cumple con las prácticas de desarrollo de software seguro descritas por el gobierno en el Marco de desarrollo de software seguro NIST.

Una de las cosas más importantes que hay que entender es que las organizaciones no deben simplemente atestiguar que siguen estas prácticas para el código de software que escriben, sino también que los componentes de código abierto que introducen en sus aplicaciones también siguen estas prácticas.

A principios de junio, el gobierno reafirmó estos requisitos en Memorándum OGP M-23-16 (PDF) y establecer fechas límite para el cumplimiento que se acercan rápidamente; es probable que lleguen en el cuarto trimestre de este año (para software crítico) y el primer trimestre del próximo año (para el resto del software).

Esto significa que en los próximos meses, las organizaciones se esforzarán por comprender estos nuevos requisitos de certificación y determinar cómo cumplirá su organización, tanto para el código que escriben ellos mismos como para los componentes de código abierto que incorporan a sus productos de software.

Según la M-23-16, la sanción por incumplimiento es severa:

“La agencia [federal] debe suspender el uso del software si la agencia considera que la documentación del productor de software no es satisfactoria o si la agencia no puede confirmar que el productor haya identificado las prácticas de las que no puede dar fe…”

Caso particularmente desafiante de código abierto

A medida que muchas organizaciones profundizan más en los requisitos de certificación, descubren que el cumplimiento, especialmente cuando se trata de plazos ajustados, puede resultar un desafío. El NIST SSDF es un marco complejo para la seguridad, y llevará tiempo que las organizaciones no solo se aseguren de cumplir con estas prácticas, sino que también documenten sus prácticas en detalle.

Pero aún más desalentador es que el gobierno está pidiendo a los proveedores que certifiquen las prácticas de seguridad de todo su producto de software, que incluye los componentes de código abierto en ese software. Hoy en día, el software moderno a menudo se compone en gran parte de componentes de código abierto que se han improvisado, junto con algún software personalizado. En nuestra investigación hemos encontrado que más del 90% de las aplicaciones contienen componentes de código abierto, y en muchos casos el código abierto constituye más del 70% de la base de código.

Su organización puede dar fe de sus propias prácticas de seguridad, pero ¿cómo puede dar fe exactamente de las prácticas de seguridad seguidas por los mantenedores de código abierto que escriben y mantienen el código fuente abierto que utiliza en sus aplicaciones?

Es un gran desafío, y las organizaciones están buscando mantenedores de código abierto para obtener más información sobre sus prácticas de seguridad. Desafortunadamente, muchos de estos mantenedores de código abierto son voluntarios no remunerados que trabajan en código abierto como pasatiempo durante las noches y los fines de semana. Por lo tanto, pedirles que hagan el trabajo adicional para validar que sus prácticas de seguridad coincidan con los altos estándares establecidos por NIST SSDF no es práctico.

Una forma en que las organizaciones pueden evitar este desafío es simplemente no usar código abierto en sus aplicaciones. Y si bien eso suena como una solución simple a primera vista, también es una alternativa cada vez más inviable, ya que el código abierto en muchos sentidos se ha convertido en la plataforma de desarrollo moderna de facto.

Una mejor manera de resolver este problema es asegurarse de que los mantenedores de los paquetes en los que confía reciban un pago por realizar este importante trabajo de seguridad.

Esto puede requerir que realice una investigación adicional para asegurarse de que los componentes de código abierto que está utilizando tengan mantenedores detrás de ellos a quienes se les paga, ya sea por benefactores corporativos, fundaciones o esfuerzos comerciales, para validar que sus paquetes cumplan con estos importantes estándares de seguridad. O incluso puede comunicarse con los mantenedores usted mismo y convertirse en un patrocinador corporativo de su trabajo. Al diseñar su enfoque, tenga en cuenta que la mayoría de las aplicaciones modernas no triviales tienen miles de dependencias de código abierto distintas, cada una creada y mantenida por una persona o equipo diferente, por lo que el esfuerzo manual para escalar este enfoque es considerable.

Un paso adelante desafiante pero necesario

Estos requisitos pueden ser dolorosos de cumplir, pero en el contexto de las crecientes vulnerabilidades de seguridad que causan daños masivos a los sectores público y privado, son un paso necesario. El gobierno de EE. UU. es el mayor comprador de bienes y servicios del mundo, y eso es cierto tanto para TI como para otros dominios. Al utilizar su poder adquisitivo para forzar mejoras en el estándar de seguridad general para el software, el gobierno está ayudando a garantizar un futuro más seguro.

• Distribución de relaciones públicas y contenido potenciado por SEO. Consiga amplificado hoy.
• PlatoData.Network Vertical Generativo Ai. Empodérate. Accede Aquí.
• PlatoAiStream. Inteligencia Web3. Conocimiento amplificado. Accede Aquí.
• PlatoESG. Automoción / vehículos eléctricos, Carbón, tecnología limpia, Energía, Ambiente, Solar, Gestión de residuos. Accede Aquí.
• Desplazamientos de bloque. Modernización de la propiedad de compensaciones ambientales. Accede Aquí.
• Fuente: https://www.darkreading.com/application-security/selling-software-government-know-security-attestation-first