![<\/a><\/div>\nLa mayor presi\u00f3n regulatoria y legal sobre las organizaciones productoras de software para proteger sus cadenas de suministro y garantizar la integridad de su software no deber\u00eda sorprender. En los \u00faltimos a\u00f1os, la cadena de suministro de software se ha convertido en un objetivo cada vez m\u00e1s atractivo para los atacantes que ven oportunidades para multiplicar sus ataques por \u00f3rdenes de magnitud. Por ejemplo, no busquemos m\u00e1s all\u00e1 de la violaci\u00f3n de Log4j de 2021, donde Log4j (un marco de registro de c\u00f3digo abierto mantenido por Apache y utilizado en innumerables aplicaciones diferentes) fue la ra\u00edz de vulnerabilidades que pusieron en riesgo miles de sistemas. <\/p>\nLa funcionalidad de comunicaci\u00f3n de Log4j era vulnerable y, por lo tanto, proporcionaba una oportunidad para que un atacante inyectara c\u00f3digo malicioso en los registros que luego podr\u00eda ejecutarse en el sistema. Despu\u00e9s de su descubrimiento, los investigadores de seguridad vieron millones de intentos de explotaci\u00f3n, muchos de los cuales se convirtieron en ataques exitosos de denegaci\u00f3n de servicio (DoS). Seg\u00fan algunas de las \u00faltimas investigaciones de Gartner, cerca de la mitad de las organizaciones empresariales habr\u00e1n sido objeto de un ataque a la cadena de suministro de software en 2025.<\/p>\nPero \u00bfqu\u00e9 es la cadena de suministro de software? Bueno, para empezar, se define como la suma total de todo el c\u00f3digo, las personas, los sistemas y los procesos que contribuyen al desarrollo y entrega de artefactos de software, tanto dentro como fuera de una organizaci\u00f3n. Y lo que hace que asegurar la cadena de suministro de software sea tan desafiante es la naturaleza compleja y altamente distribuida del desarrollo de aplicaciones modernas. Las organizaciones emplean equipos globales de desarrolladores que dependen de una cantidad sin precedentes de dependencias de c\u00f3digo abierto, junto con una variedad de repositorios de c\u00f3digo y registros de artefactos, canalizaciones de CI\/CD y recursos de infraestructura utilizados para crear e implementar sus aplicaciones.<\/p>\nY si bien la seguridad y el cumplimiento son constantemente una de las principales preocupaciones de las organizaciones empresariales, el desaf\u00edo de proteger las cadenas de suministro de software de la organizaci\u00f3n es cada vez mayor. Muchas organizaciones est\u00e1n logrando avances materiales en la puesta en pr\u00e1ctica de las pr\u00e1cticas de DevSecOps; sin embargo, muchas de ellas todav\u00eda se encuentran en las primeras etapas para determinar qu\u00e9 hacer.<\/p>\nEs exactamente por eso que hemos elaborado este art\u00edculo. Aunque la siguiente no es de ninguna manera una lista exhaustiva, aqu\u00ed hay cuatro principios rectores para que sus esfuerzos de seguridad de la cadena de suministro de software avancen en la direcci\u00f3n correcta.<\/p>\nConsidere todos los aspectos de su cadena de suministro de software al aplicar la seguridad<\/strong><\/h2>\nDado que m\u00e1s del 80% de las bases de c\u00f3digo tienen al menos una vulnerabilidad de c\u00f3digo abierto, es l\u00f3gico que las dependencias de OSS hayan sido un foco central de la seguridad de la cadena de suministro de software. Sin embargo, las cadenas de suministro de software modernas abarcan otras entidades cuyas posturas de seguridad se pasan por alto o no se comprenden lo suficientemente ampliamente dentro de la organizaci\u00f3n como para gestionarlas adecuadamente. Estas entidades son repositorios de c\u00f3digo, canalizaciones de CI y CD, infraestructura y registros de artefactos, cada uno de los cuales requiere controles de seguridad y evaluaciones peri\u00f3dicas del cumplimiento. <\/p>\nMarcos como OWASP Top-10 para CI\/CD<\/a> y Punto de referencia de seguridad de la cadena de suministro de software CIS<\/a>. Adherirse a estos marcos requerir\u00e1 RBAC granular, aplicar el principio de privilegio m\u00ednimo, escanear contenedores e infraestructura como c\u00f3digo en busca de vulnerabilidades y configuraciones incorrectas, aislar compilaciones, integrar pruebas de seguridad de aplicaciones y una gesti\u00f3n adecuada de los secretos, solo por nombrar algunos.<\/p>\nLos SBOM son esenciales para solucionar los problemas de d\u00edas cero y otros problemas de componentes<\/strong><\/h2>\nParte de la Orden Ejecutiva 14028, emitida por la Casa Blanca a mediados de 2021 para fortalecer la postura de ciberseguridad del pa\u00eds, exige que los productores de software proporcionen a sus clientes federales una lista de materiales de software (SBOM, por sus siglas en ingl\u00e9s). Las SBOM son esencialmente registros formales destinados a brindar visibilidad sobre todos los componentes que forman una pieza de software. Proporcionan un inventario detallado y legible por m\u00e1quina que enumera todas las bibliotecas, dependencias y componentes de c\u00f3digo abierto y de terceros utilizados en la creaci\u00f3n del software. <\/p>\nYa sea que una organizaci\u00f3n est\u00e9 obligada por la EO 14028 o no, generar y administrar SBOM para artefactos de software es una pr\u00e1ctica valiosa. Los SBOM son una herramienta indispensable para solucionar problemas de componentes o vulnerabilidades de d\u00eda cero. Cuando se almacenan en un repositorio con capacidad de b\u00fasqueda, los SBOM proporcionan un mapa de d\u00f3nde existe una dependencia espec\u00edfica y permiten a los equipos de seguridad rastrear r\u00e1pidamente las vulnerabilidades hasta los componentes afectados.<\/p>\nGobierne el ciclo de vida del desarrollo de software con pol\u00edticas como c\u00f3digo<\/strong><\/h2>\nEn el mundo del desarrollo de aplicaciones moderno, las barreras de seguridad s\u00f3lidas son una herramienta esencial para eliminar errores y acciones intencionales que comprometen la seguridad y el cumplimiento. Una gobernanza adecuada en toda la cadena de suministro de software significa que la organizaci\u00f3n ha hecho que sea f\u00e1cil hacer las cosas correctas y extremadamente dif\u00edcil hacer las cosas incorrectas. <\/p>\nSi bien muchas plataformas y herramientas ofrecen pol\u00edticas listas para usar que se pueden aplicar r\u00e1pidamente, la pol\u00edtica como c\u00f3digo basada en el est\u00e1ndar de la industria Open Policy Agent permite crear y aplicar pol\u00edticas totalmente personalizables. Pol\u00edticas que rigen todo, desde privilegios de acceso hasta permitir o denegar el uso de dependencias de OSS seg\u00fan criterios como proveedor, versi\u00f3n, URL del paquete y licencia. <\/p>\nSer capaz de verificar y garantizar la confianza en sus artefactos de software utilizando SLSA<\/strong><\/h2>\n\u00bfC\u00f3mo pueden los usuarios y consumidores saber que un software es confiable? Para determinar la confiabilidad de un artefacto de software, querr\u00e1 saber cosas como qui\u00e9n escribi\u00f3 el c\u00f3digo, qui\u00e9n lo cre\u00f3 y en qu\u00e9 plataforma de desarrollo se cre\u00f3. Saber qu\u00e9 componentes contiene tambi\u00e9n ser\u00eda algo que deber\u00edas saber.<\/p>\nEs posible tomar una decisi\u00f3n sobre si se debe confiar en el software una vez que se puede verificar la procedencia (el registro de los or\u00edgenes y la cadena de custodia de un software). Para esto, el Marco de niveles de cadena de suministro para artefactos de software (SLSA)<\/a> fue creado. Brinda a las organizaciones productoras de software la capacidad de capturar informaci\u00f3n sobre cualquier aspecto de la cadena de suministro de software, verificar las propiedades de los artefactos y su construcci\u00f3n, y reducir el riesgo de problemas de seguridad. En la pr\u00e1ctica, es esencial que las organizaciones productoras de software adopten y cumplan los requisitos del marco SLSA e implementen un medio para verificar y generar certificaciones de software que son declaraciones autenticadas (metadatos) sobre artefactos de software a lo largo de sus cadenas de suministro de software.<\/p>\nDada la magnitud y complejidad de asegurar la cadena de suministro de software moderna, la gu\u00eda anterior apenas toca la superficie. Pero como todo lo dem\u00e1s en el mundo de la creaci\u00f3n e implementaci\u00f3n de aplicaciones modernas, la pr\u00e1ctica est\u00e1 evolucionando r\u00e1pidamente. Para ayudarle a empezar, le recomendamos leer C\u00f3mo entregar software de forma segura<\/a> \u2013 <\/em>un libro electr\u00f3nico lleno de mejores pr\u00e1cticas dise\u00f1adas para fortalecer su postura de seguridad y minimizar el riesgo para su negocio. <\/p>\n<\/p>\n\u00bfEncontr\u00f3 interesante este art\u00edculo? Este art\u00edculo es una contribuci\u00f3n de uno de nuestros valiosos socios.<\/span> Siga con nosotros Gorjeo \uf099<\/i><\/a> y LinkedIn<\/a> para leer m\u00e1s contenido exclusivo que publicamos.<\/div>\n<\/div>\n](\"https:\/\/teknomers.com\/es\/wp-content\/uploads\/2024\/06\/Guia-practica-para-proteger-su-cadena-de-suministro-de-software.png\"){kind=link}
La mayor presi\u00f3n regulatoria y legal sobre las organizaciones productoras de software para proteger sus cadenas de suministro y garantizar la integridad de su software no deber\u00eda sorprender. En los \u00faltimos a\u00f1os, la cadena de suministro de software se ha convertido en un objetivo cada vez m\u00e1s atractivo para los atacantes que ven oportunidades para multiplicar sus ataques por \u00f3rdenes de magnitud. Por ejemplo, no busquemos m\u00e1s all\u00e1 de la violaci\u00f3n de Log4j de 2021, donde Log4j (un marco de registro de c\u00f3digo abierto mantenido por Apache y utilizado en innumerables aplicaciones diferentes) fue la ra\u00edz de vulnerabilidades que pusieron en riesgo miles de sistemas. <\/p>\n
La funcionalidad de comunicaci\u00f3n de Log4j era vulnerable y, por lo tanto, proporcionaba una oportunidad para que un atacante inyectara c\u00f3digo malicioso en los registros que luego podr\u00eda ejecutarse en el sistema. Despu\u00e9s de su descubrimiento, los investigadores de seguridad vieron millones de intentos de explotaci\u00f3n, muchos de los cuales se convirtieron en ataques exitosos de denegaci\u00f3n de servicio (DoS). Seg\u00fan algunas de las \u00faltimas investigaciones de Gartner, cerca de la mitad de las organizaciones empresariales habr\u00e1n sido objeto de un ataque a la cadena de suministro de software en 2025.<\/p>\n
Pero \u00bfqu\u00e9 es la cadena de suministro de software? Bueno, para empezar, se define como la suma total de todo el c\u00f3digo, las personas, los sistemas y los procesos que contribuyen al desarrollo y entrega de artefactos de software, tanto dentro como fuera de una organizaci\u00f3n. Y lo que hace que asegurar la cadena de suministro de software sea tan desafiante es la naturaleza compleja y altamente distribuida del desarrollo de aplicaciones modernas. Las organizaciones emplean equipos globales de desarrolladores que dependen de una cantidad sin precedentes de dependencias de c\u00f3digo abierto, junto con una variedad de repositorios de c\u00f3digo y registros de artefactos, canalizaciones de CI\/CD y recursos de infraestructura utilizados para crear e implementar sus aplicaciones.<\/p>\n
Y si bien la seguridad y el cumplimiento son constantemente una de las principales preocupaciones de las organizaciones empresariales, el desaf\u00edo de proteger las cadenas de suministro de software de la organizaci\u00f3n es cada vez mayor. Muchas organizaciones est\u00e1n logrando avances materiales en la puesta en pr\u00e1ctica de las pr\u00e1cticas de DevSecOps; sin embargo, muchas de ellas todav\u00eda se encuentran en las primeras etapas para determinar qu\u00e9 hacer.<\/p>\n
Es exactamente por eso que hemos elaborado este art\u00edculo. Aunque la siguiente no es de ninguna manera una lista exhaustiva, aqu\u00ed hay cuatro principios rectores para que sus esfuerzos de seguridad de la cadena de suministro de software avancen en la direcci\u00f3n correcta.<\/p>\n
Considere todos los aspectos de su cadena de suministro de software al aplicar la seguridad<\/strong><\/h2>\nDado que m\u00e1s del 80% de las bases de c\u00f3digo tienen al menos una vulnerabilidad de c\u00f3digo abierto, es l\u00f3gico que las dependencias de OSS hayan sido un foco central de la seguridad de la cadena de suministro de software. Sin embargo, las cadenas de suministro de software modernas abarcan otras entidades cuyas posturas de seguridad se pasan por alto o no se comprenden lo suficientemente ampliamente dentro de la organizaci\u00f3n como para gestionarlas adecuadamente. Estas entidades son repositorios de c\u00f3digo, canalizaciones de CI y CD, infraestructura y registros de artefactos, cada uno de los cuales requiere controles de seguridad y evaluaciones peri\u00f3dicas del cumplimiento. <\/p>\n
Marcos como OWASP Top-10 para CI\/CD<\/a> y Punto de referencia de seguridad de la cadena de suministro de software CIS<\/a>. Adherirse a estos marcos requerir\u00e1 RBAC granular, aplicar el principio de privilegio m\u00ednimo, escanear contenedores e infraestructura como c\u00f3digo en busca de vulnerabilidades y configuraciones incorrectas, aislar compilaciones, integrar pruebas de seguridad de aplicaciones y una gesti\u00f3n adecuada de los secretos, solo por nombrar algunos.<\/p>\nLos SBOM son esenciales para solucionar los problemas de d\u00edas cero y otros problemas de componentes<\/strong><\/h2>\nParte de la Orden Ejecutiva 14028, emitida por la Casa Blanca a mediados de 2021 para fortalecer la postura de ciberseguridad del pa\u00eds, exige que los productores de software proporcionen a sus clientes federales una lista de materiales de software (SBOM, por sus siglas en ingl\u00e9s). Las SBOM son esencialmente registros formales destinados a brindar visibilidad sobre todos los componentes que forman una pieza de software. Proporcionan un inventario detallado y legible por m\u00e1quina que enumera todas las bibliotecas, dependencias y componentes de c\u00f3digo abierto y de terceros utilizados en la creaci\u00f3n del software. <\/p>\n
Ya sea que una organizaci\u00f3n est\u00e9 obligada por la EO 14028 o no, generar y administrar SBOM para artefactos de software es una pr\u00e1ctica valiosa. Los SBOM son una herramienta indispensable para solucionar problemas de componentes o vulnerabilidades de d\u00eda cero. Cuando se almacenan en un repositorio con capacidad de b\u00fasqueda, los SBOM proporcionan un mapa de d\u00f3nde existe una dependencia espec\u00edfica y permiten a los equipos de seguridad rastrear r\u00e1pidamente las vulnerabilidades hasta los componentes afectados.<\/p>\n
Gobierne el ciclo de vida del desarrollo de software con pol\u00edticas como c\u00f3digo<\/strong><\/h2>\nEn el mundo del desarrollo de aplicaciones moderno, las barreras de seguridad s\u00f3lidas son una herramienta esencial para eliminar errores y acciones intencionales que comprometen la seguridad y el cumplimiento. Una gobernanza adecuada en toda la cadena de suministro de software significa que la organizaci\u00f3n ha hecho que sea f\u00e1cil hacer las cosas correctas y extremadamente dif\u00edcil hacer las cosas incorrectas. <\/p>\n
Si bien muchas plataformas y herramientas ofrecen pol\u00edticas listas para usar que se pueden aplicar r\u00e1pidamente, la pol\u00edtica como c\u00f3digo basada en el est\u00e1ndar de la industria Open Policy Agent permite crear y aplicar pol\u00edticas totalmente personalizables. Pol\u00edticas que rigen todo, desde privilegios de acceso hasta permitir o denegar el uso de dependencias de OSS seg\u00fan criterios como proveedor, versi\u00f3n, URL del paquete y licencia. <\/p>\n
Ser capaz de verificar y garantizar la confianza en sus artefactos de software utilizando SLSA<\/strong><\/h2>\n\u00bfC\u00f3mo pueden los usuarios y consumidores saber que un software es confiable? Para determinar la confiabilidad de un artefacto de software, querr\u00e1 saber cosas como qui\u00e9n escribi\u00f3 el c\u00f3digo, qui\u00e9n lo cre\u00f3 y en qu\u00e9 plataforma de desarrollo se cre\u00f3. Saber qu\u00e9 componentes contiene tambi\u00e9n ser\u00eda algo que deber\u00edas saber.<\/p>\n
Es posible tomar una decisi\u00f3n sobre si se debe confiar en el software una vez que se puede verificar la procedencia (el registro de los or\u00edgenes y la cadena de custodia de un software). Para esto, el Marco de niveles de cadena de suministro para artefactos de software (SLSA)<\/a> fue creado. Brinda a las organizaciones productoras de software la capacidad de capturar informaci\u00f3n sobre cualquier aspecto de la cadena de suministro de software, verificar las propiedades de los artefactos y su construcci\u00f3n, y reducir el riesgo de problemas de seguridad. En la pr\u00e1ctica, es esencial que las organizaciones productoras de software adopten y cumplan los requisitos del marco SLSA e implementen un medio para verificar y generar certificaciones de software que son declaraciones autenticadas (metadatos) sobre artefactos de software a lo largo de sus cadenas de suministro de software.<\/p>\nDada la magnitud y complejidad de asegurar la cadena de suministro de software moderna, la gu\u00eda anterior apenas toca la superficie. Pero como todo lo dem\u00e1s en el mundo de la creaci\u00f3n e implementaci\u00f3n de aplicaciones modernas, la pr\u00e1ctica est\u00e1 evolucionando r\u00e1pidamente. Para ayudarle a empezar, le recomendamos leer C\u00f3mo entregar software de forma segura<\/a> \u2013 <\/em>un libro electr\u00f3nico lleno de mejores pr\u00e1cticas dise\u00f1adas para fortalecer su postura de seguridad y minimizar el riesgo para su negocio. <\/p>\n<\/p>\n
\u00bfEncontr\u00f3 interesante este art\u00edculo? Este art\u00edculo es una contribuci\u00f3n de uno de nuestros valiosos socios.<\/span> Siga con nosotros Gorjeo \uf099<\/i><\/a> y LinkedIn<\/a> para leer m\u00e1s contenido exclusivo que publicamos.<\/div>\n<\/div>\n
Los SBOM son esenciales para solucionar los problemas de d\u00edas cero y otros problemas de componentes<\/strong><\/h2>\nParte de la Orden Ejecutiva 14028, emitida por la Casa Blanca a mediados de 2021 para fortalecer la postura de ciberseguridad del pa\u00eds, exige que los productores de software proporcionen a sus clientes federales una lista de materiales de software (SBOM, por sus siglas en ingl\u00e9s). Las SBOM son esencialmente registros formales destinados a brindar visibilidad sobre todos los componentes que forman una pieza de software. Proporcionan un inventario detallado y legible por m\u00e1quina que enumera todas las bibliotecas, dependencias y componentes de c\u00f3digo abierto y de terceros utilizados en la creaci\u00f3n del software. <\/p>\n
Ya sea que una organizaci\u00f3n est\u00e9 obligada por la EO 14028 o no, generar y administrar SBOM para artefactos de software es una pr\u00e1ctica valiosa. Los SBOM son una herramienta indispensable para solucionar problemas de componentes o vulnerabilidades de d\u00eda cero. Cuando se almacenan en un repositorio con capacidad de b\u00fasqueda, los SBOM proporcionan un mapa de d\u00f3nde existe una dependencia espec\u00edfica y permiten a los equipos de seguridad rastrear r\u00e1pidamente las vulnerabilidades hasta los componentes afectados.<\/p>\n
Gobierne el ciclo de vida del desarrollo de software con pol\u00edticas como c\u00f3digo<\/strong><\/h2>\nEn el mundo del desarrollo de aplicaciones moderno, las barreras de seguridad s\u00f3lidas son una herramienta esencial para eliminar errores y acciones intencionales que comprometen la seguridad y el cumplimiento. Una gobernanza adecuada en toda la cadena de suministro de software significa que la organizaci\u00f3n ha hecho que sea f\u00e1cil hacer las cosas correctas y extremadamente dif\u00edcil hacer las cosas incorrectas. <\/p>\n
Si bien muchas plataformas y herramientas ofrecen pol\u00edticas listas para usar que se pueden aplicar r\u00e1pidamente, la pol\u00edtica como c\u00f3digo basada en el est\u00e1ndar de la industria Open Policy Agent permite crear y aplicar pol\u00edticas totalmente personalizables. Pol\u00edticas que rigen todo, desde privilegios de acceso hasta permitir o denegar el uso de dependencias de OSS seg\u00fan criterios como proveedor, versi\u00f3n, URL del paquete y licencia. <\/p>\n
Ser capaz de verificar y garantizar la confianza en sus artefactos de software utilizando SLSA<\/strong><\/h2>\n\u00bfC\u00f3mo pueden los usuarios y consumidores saber que un software es confiable? Para determinar la confiabilidad de un artefacto de software, querr\u00e1 saber cosas como qui\u00e9n escribi\u00f3 el c\u00f3digo, qui\u00e9n lo cre\u00f3 y en qu\u00e9 plataforma de desarrollo se cre\u00f3. Saber qu\u00e9 componentes contiene tambi\u00e9n ser\u00eda algo que deber\u00edas saber.<\/p>\n
Es posible tomar una decisi\u00f3n sobre si se debe confiar en el software una vez que se puede verificar la procedencia (el registro de los or\u00edgenes y la cadena de custodia de un software). Para esto, el Marco de niveles de cadena de suministro para artefactos de software (SLSA)<\/a> fue creado. Brinda a las organizaciones productoras de software la capacidad de capturar informaci\u00f3n sobre cualquier aspecto de la cadena de suministro de software, verificar las propiedades de los artefactos y su construcci\u00f3n, y reducir el riesgo de problemas de seguridad. En la pr\u00e1ctica, es esencial que las organizaciones productoras de software adopten y cumplan los requisitos del marco SLSA e implementen un medio para verificar y generar certificaciones de software que son declaraciones autenticadas (metadatos) sobre artefactos de software a lo largo de sus cadenas de suministro de software.<\/p>\nDada la magnitud y complejidad de asegurar la cadena de suministro de software moderna, la gu\u00eda anterior apenas toca la superficie. Pero como todo lo dem\u00e1s en el mundo de la creaci\u00f3n e implementaci\u00f3n de aplicaciones modernas, la pr\u00e1ctica est\u00e1 evolucionando r\u00e1pidamente. Para ayudarle a empezar, le recomendamos leer C\u00f3mo entregar software de forma segura<\/a> \u2013 <\/em>un libro electr\u00f3nico lleno de mejores pr\u00e1cticas dise\u00f1adas para fortalecer su postura de seguridad y minimizar el riesgo para su negocio. <\/p>\n<\/p>\n
\u00bfEncontr\u00f3 interesante este art\u00edculo? Este art\u00edculo es una contribuci\u00f3n de uno de nuestros valiosos socios.<\/span> Siga con nosotros Gorjeo \uf099<\/i><\/a> y LinkedIn<\/a> para leer m\u00e1s contenido exclusivo que publicamos.<\/div>\n<\/div>\n
En el mundo del desarrollo de aplicaciones moderno, las barreras de seguridad s\u00f3lidas son una herramienta esencial para eliminar errores y acciones intencionales que comprometen la seguridad y el cumplimiento. Una gobernanza adecuada en toda la cadena de suministro de software significa que la organizaci\u00f3n ha hecho que sea f\u00e1cil hacer las cosas correctas y extremadamente dif\u00edcil hacer las cosas incorrectas. <\/p>\n
Si bien muchas plataformas y herramientas ofrecen pol\u00edticas listas para usar que se pueden aplicar r\u00e1pidamente, la pol\u00edtica como c\u00f3digo basada en el est\u00e1ndar de la industria Open Policy Agent permite crear y aplicar pol\u00edticas totalmente personalizables. Pol\u00edticas que rigen todo, desde privilegios de acceso hasta permitir o denegar el uso de dependencias de OSS seg\u00fan criterios como proveedor, versi\u00f3n, URL del paquete y licencia. <\/p>\n
Ser capaz de verificar y garantizar la confianza en sus artefactos de software utilizando SLSA<\/strong><\/h2>\n\u00bfC\u00f3mo pueden los usuarios y consumidores saber que un software es confiable? Para determinar la confiabilidad de un artefacto de software, querr\u00e1 saber cosas como qui\u00e9n escribi\u00f3 el c\u00f3digo, qui\u00e9n lo cre\u00f3 y en qu\u00e9 plataforma de desarrollo se cre\u00f3. Saber qu\u00e9 componentes contiene tambi\u00e9n ser\u00eda algo que deber\u00edas saber.<\/p>\n
Es posible tomar una decisi\u00f3n sobre si se debe confiar en el software una vez que se puede verificar la procedencia (el registro de los or\u00edgenes y la cadena de custodia de un software). Para esto, el Marco de niveles de cadena de suministro para artefactos de software (SLSA)<\/a> fue creado. Brinda a las organizaciones productoras de software la capacidad de capturar informaci\u00f3n sobre cualquier aspecto de la cadena de suministro de software, verificar las propiedades de los artefactos y su construcci\u00f3n, y reducir el riesgo de problemas de seguridad. En la pr\u00e1ctica, es esencial que las organizaciones productoras de software adopten y cumplan los requisitos del marco SLSA e implementen un medio para verificar y generar certificaciones de software que son declaraciones autenticadas (metadatos) sobre artefactos de software a lo largo de sus cadenas de suministro de software.<\/p>\nDada la magnitud y complejidad de asegurar la cadena de suministro de software moderna, la gu\u00eda anterior apenas toca la superficie. Pero como todo lo dem\u00e1s en el mundo de la creaci\u00f3n e implementaci\u00f3n de aplicaciones modernas, la pr\u00e1ctica est\u00e1 evolucionando r\u00e1pidamente. Para ayudarle a empezar, le recomendamos leer C\u00f3mo entregar software de forma segura<\/a> \u2013 <\/em>un libro electr\u00f3nico lleno de mejores pr\u00e1cticas dise\u00f1adas para fortalecer su postura de seguridad y minimizar el riesgo para su negocio. <\/p>\n<\/p>\n
\u00bfEncontr\u00f3 interesante este art\u00edculo? Este art\u00edculo es una contribuci\u00f3n de uno de nuestros valiosos socios.<\/span> Siga con nosotros Gorjeo \uf099<\/i><\/a> y LinkedIn<\/a> para leer m\u00e1s contenido exclusivo que publicamos.<\/div>\n<\/div>\n
Dada la magnitud y complejidad de asegurar la cadena de suministro de software moderna, la gu\u00eda anterior apenas toca la superficie. Pero como todo lo dem\u00e1s en el mundo de la creaci\u00f3n e implementaci\u00f3n de aplicaciones modernas, la pr\u00e1ctica est\u00e1 evolucionando r\u00e1pidamente. Para ayudarle a empezar, le recomendamos leer C\u00f3mo entregar software de forma segura<\/a> \u2013 <\/em>un libro electr\u00f3nico lleno de mejores pr\u00e1cticas dise\u00f1adas para fortalecer su postura de seguridad y minimizar el riesgo para su negocio. <\/p>\n <\/p>\n