Soporte técnico
Documentación
Inicio de sesión
Póngase en contacto con nosotros
Ataques a la cadena de suministro: percepción del riesgo frente a realidad
Joao Correia
31 de octubre de 2023 - Evangelista técnico
Los ataques a la cadena de suministro han aumentado en los últimos años, convirtiéndose gradualmente en una amenaza formidable en el panorama de la ciberseguridad. Sin embargo, a pesar de su creciente prevalencia, parece haber una desconexión entre la percepción y la realidad de su daño potencial. Un número asombroso de desarrolladores muestran una mentalidad de "no en mi patio trasero", asumiendo que sus bases de código son seguras e impenetrables. Sin embargo, las métricas reales narran una historia opuesta, revelando que una gran cantidad de software es susceptible debido a las vulnerabilidades derivadas de las dependencias.
La invisible red de dependencias
Cuando los desarrolladores integran una biblioteca en su código, rara vez se dan cuenta de la cadena de dependencias que se entrelazan silenciosamente con su software. Una sola biblioteca puede traer consigo una miríada de otras dependencias, cada una con su propio conjunto de vulnerabilidades.
Según Sonatypemientras que sólo el 10% de más de 12.000 bibliotecas presentaban una vulnerabilidad en su propio código, la cifra se disparaba hasta el 62% si se tenían en cuenta las vulnerabilidades transitivas de las dependencias. Este escenario, a menudo infravalorado o pasado por alto, expone el software a una multiplicidad de amenazas invisibles, convirtiéndolo en un objetivo maduro para los ataques a la cadena de suministro.
Un espejismo de seguridad
Irónicamente, incluso cuando las amenazas se ciernen con fuerza, una proporción sustancial de desarrolladores cree que sus aplicaciones no utilizan bibliotecas vulnerables. La encuesta de Sonatype reveló que el 68% de los desarrolladores estaban seguros de que sus aplicaciones no empleaban bibliotecas vulnerables conocidas. Sin embargo, un análisis de 55.000 aplicaciones empresariales demostró que el 68% de ellas presentaban vulnerabilidades conocidas.
Esta flagrante disparidad entre percepción y realidad plantea una pregunta crítica: ¿por qué los desarrolladores están ciegos ante los riesgos que acechan a su código?
La ilusión de que "a mí no me va a pasar
Esta disparidad suele estar alimentada por un sesgo implícito, en el que los desarrolladores, e incluso los responsables de TI, perciben que su código y sus prácticas están por encima de la media. El síndrome de "a mí no me va a pasar" echa raíces, perpetuando un ciclo de subestimación de los riesgos y exceso de confianza en las prácticas internas.
Además, la complejidad de la gestión y el seguimiento de la extensa red de dependencias, actualizaciones y vulnerabilidades se convierte en una tarea de enormes proporciones. Dado que cada aplicación Java contiene una media de 148 dependencias (20 más que el año anterior) y se actualiza 10 veces al año, los desarrolladores tienen que lidiar con la gestión de la inteligencia de casi 1500 cambios de dependencias al año por aplicación.
El peligro de la negligencia
En medio de todo esto, la amenaza de los paquetes maliciosos de código abierto aumenta de forma inquietante. En un solo año se descubrieron 88.000 paquetes maliciosos de código abierto (y sus versiones). descubiertos en un solo añolo que indica una proliferación del riesgo para los sistemas corporativos debido a vulnerabilidades intencionadas y no intencionadas. Este aumento de la actividad maliciosa es un testimonio del creciente uso de paquetes de código abierto por parte de los equipos de desarrollo con el objetivo de acelerar el tiempo de comercialización, a menudo a expensas de un examen exhaustivo de la seguridad.
Cambiar el paradigma: Mitigar los riesgos invisibles
Mitigar estos riesgos implica un cambio de paradigma en los planteamientos de los desarrolladores y las organizaciones respecto al desarrollo y la seguridad del software:
- Reconocer lo invisible: Los desarrolladores y las organizaciones deben reconocer en primer lugar las amenazas potenciales que se ocultan en las dependencias de las bibliotecas que utilizan.
- Gestión transparente de las dependencias: El empleo de herramientas y prácticas que garanticen la visibilidad y la gestión de las dependencias permite a los desarrolladores hacerse una idea clara de todas las bibliotecas integradas y sus respectivas dependencias.
- Priorizar la seguridad: La selección de componentes debe priorizar la seguridad, incluso si eso significa optar por un proyecto menos popular con menos vulnerabilidades y un árbol de dependencias más pequeño.
- Adopte medidas de seguridad proactivas: Es aconsejable dar preferencia a una fuente de confianza para sus dependencias sobre repositorios populares, pero no verificados. Servicios como SecureChain de TuxCare para Java de TuxCare ofrecen precisamente esta característica.
- Supervisión y actualización continuas: La supervisión continua de las dependencias en busca de vulnerabilidades y la actualización periódica de las bibliotecas ayudarán a proteger el software de posibles amenazas.
A medida que el panorama de las amenazas sigue evolucionando, reconocer los riesgos invisibles e integrar prácticas de seguridad sólidas en el ciclo de vida del desarrollo se convierte en una preocupación ineludible. El exceso de confianza y la subestimación inducen una forma de ceguera selectiva que protege a los atacantes el tiempo suficiente para dañar activamente el software de producción, y debe evitarse activamente para proteger el software de las crecientes amenazas de los ataques a la cadena de suministro.
Tanto los desarrolladores como las organizaciones deben navegar por la intrincada red de dependencias con ojo avizor, asegurándose de que su código permanece seguro en medio de los peligros ocultos que acechan.
