Proteja sua cadeia de suprimentos de software com Bytesafe

Mantenga segura su cadena de suministro

Una cadena de suministro de código seguro comienza con saber qué código está utilizando realmente en sus aplicaciones.

Hoy en día, las aplicaciones web dependen en gran medida del código producido por desarrolladores externos. Por lo tanto, encontrará que las aplicaciones modernas se basan principalmente en software de código abierto (OSS) de terceros.

La cadena de suministro de código contiene todo el código externo del que depende una aplicación, tanto de código abierto como comercial. Y, como cualquier cadena de suministro, es fundamental asegurarse de que el código siempre entregue lo que necesita de forma segura y eficiente.

Una aplicación web puede constar de cientos o incluso miles de dependencias de código. Synopsys dice que al usar dependencias externas, hasta el 70% del código de sus aplicaciones lo escribe otra persona. Y el 99% de todas las bases de código analizadas contenían código fuente abierto.

Además, muchas empresas realmente no tienen un buen inventario o conocimiento de qué software de código abierto están usando en sus productos o el alcance total de su dependencia del código abierto.

Gartner proyecta que el nivel de gasto en seguridad global alcanzará los $170.4 billones hasta 2022. Se prevé que el costo financiero total para las empresas afectadas por el ciberdelito alcance $6 trillion nivel mundial en 2021. Por lo tanto, el desembolso para administrar y asegurar adecuadamente la cadena de suministro de códigos es a menudo minúsculo en comparación con los posibles costos financieros y la pérdida de reputación como consecuencia de una violación de la seguridad.

Para realizar un seguimiento de las vulnerabilidades en sus dependencias de código abierto, primero debe tener en cuenta que existen en su base de código. La falta de visibilidad y conocimientos sobre los paquetes que está utilizando puede afectar negativamente a su aplicación de software de varias maneras.

Además, la mayoría de las dependencias que usa tienen sus propias dependencias. Entonces, si solo está escaneando su propio código y sus dependencias, entonces su superficie de ataque es mucho más grande de lo que cree.

Evite crear una aplicación con vulnerabilidades de seguridad, problemas de dependencia o incumplimiento de las condiciones de la licencia. Bytesafe puede evitar poner en riesgo sus aplicaciones y su negocio mejorando la seguridad de su dependencia y protegiendo su cadena de suministro de código.

¿Qué es la seguridad de dependencia?

La seguridad de dependencia es el concepto de administrar el riesgo introducido en su aplicación por código externo, código sobre el que no tiene control directo.

La seguridad de las dependencias comienza con conocer y controlar las dependencias que está utilizando. Y continúa asegurándose de que las dependencias sean seguras y confiables, siempre disponibles, actualizadas, que cumplan con las políticas de seguridad de su empresa y se hayan agregado intencionalmente.

Se necesita control para poder mitigar los ataques de seguridad como Cross-Site Scripting (XSS), Cross-Site Request Forgery (CSRF), XML External Entity (XXE) y ataques de lógica empresarial, por nombrar algunos. Ataques potencialmente introducidos en su cadena de suministro a través de errores tipográficos o confusión de dependencia.

El panorama siempre cambiante del código abierto hace que la gestión y el seguimiento de las dependencias del código, la seguridad del código open source and el cumplimiento de las licencias son una tarea desafiane para las empresas que utilizan el código abierto en su base de código.

Las organizaciones deben asegurarse de que::

1. Las dependencias de código abierto son seguras
2. Los flujos de trabajo de los paquetes cumplen con las políticas comerciales y de seguridad requeridas.

Para desarrollar aplicaciones seguras, los desarrolladores deben comprender y ser conscientes de los diferentes tipos de ataques que pueden explotarse. No todo el mundo lo hace. OWASP es una gran fuente de información que le ayuda a ponerse al día: https://cheatsheetseries.owasp.org/.

¿Qué es una dependencia?

Usar y compartir bloques de código reutilizables es algo común y acelera el ciclo de vida del desarrollo de software (SDLC). Cada fragmento de código está diseñado para un propósito específico, lo que ahorra tiempo y esfuerzo a los desarrolladores de tener que escribirlo ellos mismos.

Una dependencia es un fragmento de código reutilizable del que depende una aplicación y es necesario para que funcione correctamente. Para proyectos de aplicaciones web, estas dependencias a menudo se obtienen mediante administradores de paquetes como npm. El registro publico de npm contiene aproximadamente 1.5 millones de paquetes que los desarrolladores pueden descargar en cualquier momiento, com un promedio de 1 billione de descargas por día.

Las dependencias en el ecosistema npm son particularmente interesantes desde una perspectiva de seguridad, por dos razones.

Primero, el uso de dependencias es una parte natural de JavaScript, con un espíritu de código abierto de reutilización de código que los desarrolladores practican ampliamente.

En segundo lugar, las dependencias a menudo tienen sus propias dependencias. Como tal, al agregar nuevos paquetes a su proyecto, puede incluir más dependencias de las que pensó o pretendía originalmente.

Hay dos tipos de dependencias;

• Dependencias directas cuando su aplicación usa directamente un fragmento de código y lo hace referencia directamente.
• Dependencias transitivas, que son dependencias de las dependencias directas de su aplicación (también conocidas como dependencia de una dependencia).

Una buena gestión de las dependencias significa tener visibilidad, conocimientos y control sobre todas las dependencias que utilizan sus aplicaciones. ¡Incluidas todas las dependencias transitivas!

El riesgo es que al introducir software de terceros en su aplicación, también incorporará las vulnerabilidades, fallas de seguridad y errores de software del software de terceros.

Gestionar la seguridad de las dependencias

En organizaciones más grandes con múltiples equipos de desarrollo y numerosas aplicaciones, puede ser una tarea compleja realizar un seguimiento de las dependencias que se utilizan en sus aplicaciones.

Tradicionalmente, los servicios de backend utilizan autenticación, cifrado de datos, almacenamiento seguro de tokens y credenciales, gestión de acceso, etc. Pero, la seguridad de su interfaz es tan fuerte como su eslabón más débil o dependencia externa.

Mantener sus dependencias actualizadas es fundamental, pero priorizar entre dependencias vulnerables a amenazas de seguridad y actualizaciones que no romperán su código puede resultar confuso.

Establecer un protocolo claro para la gestión de la dependencia ayudará a prevenir dolores de cabeza más adelante en el ciclo de desarrollo, cuando podría ser más costoso resolverlos.

Evite dependencias obsoletas y obsoletas

Hasta cierto punto, el software es un producto nuevo en el que desea asegurarse de que está utilizando componentes actualizados y bien mantenidos. Es posible que las nuevas versiones no solo incluyan nuevas funciones que usted, como organización, desee utilizar, sino también correcciones críticas para vulnerabilidades conocidas que cierran los posibles vectores de ataque.

Como usuario, desea evitar el deterioro del software y asegurarse de que las dependencias que está utilizando estén actualizadas con las últimas versiones. Las organizaciones deben desarrollar un enfoque sobre cómo verificar y actualizar continuamente sus dependencias. Sopesando los beneficios de las dependencias actualizadas con el trabajo necesario para probar sus aplicaciones con nuevas versiones de dependencia.

Sin un plan para evitar dependencias obsoletas, combinado con no actualizar versiones, puede perderse:

• Las últimas mejoras que mejoran el rendimiento o agregan nuevas funciones.
• Corrección de errores
• Alertas de código que ha quedado obsoleto o que ha llegado al final de su vida útil.
• Además, exponga su aplicación y sus usuarios a vulnerabilidades de seguridad conocidas.

Dependencia de desarrolladores externos

Dentro de su propia organización, probablemente tendrá políticas y controles internos para asegurarse de que el código que ha escrito se pruebe a fondo, con KPI definidos para métricas de código, etc.

Para el código de terceros, la mayor parte no está escrito por grandes empresas como Facebook o Google, con todo su poder de desarrollo sustancial detrás de ellos. En cambio, la mayoría de los paquetes son publicados por comunidades dedicadas de desarrolladores individuales que mantienen el código con sus propios objetivos en mente.

Cuando su aplicación utiliza dependencias externas, significa que, como organización, dependerá de los desarrolladores sobre los que no puede ejercer ningún control real. Y ese es un pensamiento aleccionador. Sin tener el control, ¿cómo sabe si se mantienen los componentes de código abierto en su base de código?

Cuando tiene una dependencia de desarrolladores externos, no puede:

• Influir en la forma en que se escribe el código del componente.
• Evitar que el código se cambie en el futuro.
• Garantizar una verificación de antecedentes adecuada de los nuevos desarrolladores que ayudan con la base de código.
• Controlar si los desarrolladores administran tokens y credenciales de forma segura.
• Sepa si el código seguirá siendo compatible con sus dependencias.

Hoy en día, npm tiene una política de no publicarse, mucho más estricta , pero en el pasado ha habido incidentes debido a paquetes no publicados. Por ejemplo, hubo un caso de un desarrolador de JavaScript que extrajo sus paquetes de npm. Los programadores se quedaron mirando las compilaciones rotas y las instalaciones fallidas para una función que se usaba ampliamente en otras aplicaciones. El problema central de la falta de control sobre los componentes clave de sus aplicaciones aún persiste, y diferentes servicios pueden tener diferentes políticas de anulación de publicación.

Falta de gestión segura de tokens y credenciales para los mantenedores de paquetes

Las estatisticas de 2020 muestran que solo el 9.27% ​​de todos los mantenedores de paquetes npm usan autenticación de 2 factores (2FA) para proteger sus cuentas de ser pirateadas o usurpadas.

Con tantos mantenedores que no usan 2FA para proteger sus cuentas, existe el riesgo de que no se pueda realmente confiar si el mantenedor original o una parte con intenciones maliciosas ha publicado una nueva versión del paquete.

No existe otro ecosistema como Javascript con los mismos enormes volúmenes de usuarios, código y descargas cuando se trata de la cantidad de bibliotecas de código abierto disponibles. Un entorno ideal para los piratas informáticos que intentan atacar su cadena de suministro de código.

Suponga que sus dependencias tendrán vulnerabilidades

La seguridad de las dependencias también implica cómo administra las vulnerabilidades conocidas en las bibliotecas de terceros y evita nuevas amenazas, así como cómo administra las dependencias externas en sus aplicaciones.

Con el tiempo, las dependencias de las aplicaciones pueden quedar obsoletas o se pueden encontrar nuevas vulnerabilidades. Por lo tanto, saber qué dependencias está usando su aplicación (tanto las dependencias directas como las transitivas) es clave para poder solucionar problemas potenciales y mantenerse actualizado.

Es fácil incluir nuevas dependencias, por lo que deberá asegurarse de que las dependencias de su aplicación se administren de acuerdo con las reglas establecidas por su empresa.

Calidad de dependencia

Cuando se trata de la calidad del código abierto, no hay controles ni controles de seguridad / garantía de calidad que deban cumplirse para publicar un paquete en un registro público.

Eso significa que encontrará paquetes en los que la seguridad se ha tomado en serio, pero también hay muchos paquetes en los que la seguridad no ha sido una prioridad.

Si bien hay muchas herramientas y servicios disponibles para simplificar la detección de paquetes, también es importante decidir qué métricas buscar y evaluar antes de decidir incluir una nueva dependencia en su aplicación.

Por ejemplo, una métrica de uso frecuente es la popularidad (número de descargas, paquetes dependientes, etc.), que no es suficiente para la seguridad de las dependencias y es una señal engañosa. Otras métricas comunes a tener en cuenta pueden ser la última fecha de lanzamiento, dependencias desactualizadas, versiones estables, existencia de archivos clave (por ejemplo, README), cobertura de código de las pruebas y si hay un sitio web personalizado.

Con la gran cantidad de dependencias externas que existen, la seguridad de la dependencia debería ser algo con lo que todos los miembros de un equipo deberían trabajar y preocuparse, en lugar de tener solo una o dos personas dedicadas. ¡La seguridad de la dependencia es un problema de todos! l

¿Es seguro usar el código de fuente abierto?

No, no por defecto.

En teoría “el código abierto permite tener mas atención en el código” significa que más personas están “mirando” el código, lo que implica un mejor nivel de seguridad que, por ejemplo, el código cerrado propietario, que limita el acceso y la visibilidad.

Si bien es cierto que más personas están mirando el código, es un mito que todos estén escudriñando las líneas del código, buscando diligentemente eliminar las arrugas. Con tantos proyectos de código abierto que se ejecutan en millones de líneas de código, no hay suficientes personas debidamente calificadas en seguridad con la capacidad de verificar y revisar el código de manera exhaustiva.

Y lo que es peor, en situaciones en las que el software que rara vez o nunca se examina o actualiza, las vulnerabilidades del código pueden aprovecharse para actividades maliciosas.

El uso de paquetes del registro público de npm se ha convertido en un proceso tan sencillo que ha contribuido al aumento de las descargas y la productividad del software. Pero, con el ritmo vertiginoso que se espera de los desarrolladores para producir aplicaciones, muchos nunca han mirado su código y las dependencias de terceros.

Ocultos a plena vista

Los desafíos con la gestión de dependencias y la seguridad no son exclusivos del ecosistema de JavaScript. La enormemente popular biblioteca de código abierto OpenSSL fue mantenida por solo dos desarrolladores. Muchos sitios de todo el mundo se vieron afectados por suHeartbleed vulnerabilidad. El error había estado fuera durante 2 años antes de ser parcheado, a pesar de que la biblioteca era de código abierto.

Ataques a las cadenas de suministro de códigos

Los ataques a la cadena de suministro están en aumento y lo han sido en los últimos años. En lugar de intentar piratear y explotar las vulnerabilidades existentes en el código, los piratas informáticos están dirigiendo cada vez más sus intentos de incluir su código malicioso en sus aplicaciones como parte del proceso de compilación.

Ataques a la cadena de suministro que debe conocer y tener en cuenta:

• Adquisición de paquetes y cuentas (con intenciones malintencionadas)
• Typosquatting y combosquatting
• Confusión de dependencia

El reciente SolarWinds ataque a la cadena de suministro es quizás el ejemplo más conocido de un ataque a la cadena de suministro, en el que se insertó un código malicioso en uno de los productos de SolarWinds y se distribuyó como una actualización a muchos de sus clientes. Pero también hay muchos ejemplos recientes de paquetes maliciosos de ataques similares en elnpm ecosystem.

Con este tipo de ataques e intentos en aumento, ahora es más importante que nunca proteger su cadena de suministro de código.

Package and account takeover attacks

Una forma de que los piratas informáticos accedan a su aplicación es a través de la cadena de suministro, explotando un paquete npm legítimo de la larga lista de dependencias que ya está utilizando.

Con acceso al token de mantenimiento de un paquete, se puede publicar fácilmente una nueva versión que incluya una debilidad específica lista para ser explotada. Estos ataques a menudo conservan toda la funcionalidad original del paquete original, ya que lo hace compatible con versiones anteriores y más difícil de detectar. Con la reutilización generalizada de paquetes npm, una[cuenta comprometida puede afectar a muchos usuarios en todo el mundo).

Una forma de obtener acceso a un paquete legítimo es aprovechar el hecho de que muchos mantenedores de paquetes no están asegurando sus credenciales, creando contraseñas seguras o usando autenticación de dos factores con npmjs.

También se utiliza la ingeniería social tradicional, donde los desarrolladores maliciosos inicialmente contribuyen a la base del código, pero una vez que se agregan como mantenedores, agregan código malicioso y publican nuevas versiones o incluso eliminan el mantenedor original (lo que se conoce como toma de control de la cuenta).

Ataques Typosquatting y combosquatting

Ataques de typosquatting que engañan a los desarrolladores para que instalen paquetes maliciosos con nombres similares a los paquetes oficiales. Combosquatting es similar a typosquatting, pero utiliza nombres reales en lugar de depender de errores tipográficos.

Al confiar en errores humanos a través de errores tipográficos o esperar que los desarrolladores no se molesten en revisar las dependencias, los piratas informáticos quieren que sus paquetes se incluyan en sus proyectos y cadena de suministro.

Al descargar y usar paquetes de código abierto, esencialmente confía en su editor, aunque ninguno de los servicios de alojamiento de paquetes puede garantizar que todo el código cargado esté libre de malware.

La mayoría de los desarrolladores y organizaciones confían ciegamente en que las dependencias utilizadas no contienen contenido malicioso (intencionalmente o no). Y al instalar paquetes desde npm o cualquier otro repositorio, los usuarios descargan e instalan automáticamente un paquete junto con todas las dependencias relacionadas.

Para estar seguro, debe asegurarse de que está sacando los paquetes que desea.

Ataques de confusión de dependencia

La confusión de dependencias (a veces conocida como ataques de sustitución) confunde a los administradores de paquetes sobre qué versión del paquete incluir en su proyecto. Los ataques apuntan a vulnerabilidades o fallas de diseño en herramientas de construcción o instalación automatizadas que permiten que las dependencias públicas se confundan con dependencias internas con el mismo nombre exacto.

El ataque comprende la carga de malware en repositorios de código abierto y los paquetes se distribuyen automáticamente en las aplicaciones internas de una empresa, con el paquete público obteniendo prioridad y siendo retirado sin necesidad de ninguna acción del desarrollador.

Si el ataque tiene éxito, se incluirá un paquete de una fuente no deseada en sus aplicaciones, con la posibilidad de ejecutar scripts y código arbitrario en el servidor.

Asegurando su cadena de suministro de código

Asegurar su cadena de suministro supone que tiene los procesos en su lugar para asegurarse de que se agreguen intencionalmente nuevas dependencias o versiones. También implica tener acceso a las herramientas adecuadas que le brindan la profundidad adecuada de transparencia y descripción general, además de ayudarlo a proteger su organización de códigos maliciosos.

Al igual que con el control de calidad (QA), donde es mejor encontrar errores antes de que se implementen, es mejor bloquear y detectar problemas de seguridad y licencia antes de que se conviertan en problemas.

Secure su cadena de suministro con:

• Escanee continuamente las dependencias para encontrar vulnerabilidades.
• Uso de políticas de seguridad de Bytesafe para administrar sus dependencias de acuerdo con sus reglas comerciales.
• Creando un firewall de dependencia
• Tener el mismo nivel de seguridad para todos los paquetes.

Escanee continuamente las dependencias para encontrar vulnerabilidades

Si bien sus dependencias pueden estar seguras cuando las agrega a sus aplicaciones, se encuentran nuevas vulnerabilidades todo el tiempo. Escanee continuamente sus dependencias, en lugar de depender únicamente de escaneos puntuales y asegúrese de que las fallas de seguridad críticas no lleguen a sus aplicaciones.

The escáner de vulnerabilidades de Bytesafe detecta vulnerabilidades de seguridad conocidas en sus dependencias. Cuando el escáner identifica vulnerabilidades, se enviarán notificaciones a los usuarios y se agregarán insignias de seguridad para marcar las dependencias afectadas.

Las insignias de seguridad muestran la gravedad de la vulnerabilidad y se vinculan al aviso que contiene información adicional, como una recomendación sobre cómo solucionar el problema de seguridad.

El escáner de vulnerabilidades lo ayuda a mantenerse actualizado con la seguridad de sus dependencias al encontrar y resaltar las vulnerabilidades. Para restringir paquetes, lea sobre cómo usar las políticas de seguridad de Bytesafe.

Uso de políticas de seguridad de Bytesafe para administrar sus dependencias de acuerdo con las reglas comerciales prescritas

Las políticas de seguridad en Bytesafe le permiten administrar sus dependencias de manera homogénea en todo su entorno de acuerdo con sus reglas comerciales existentes. Las políticas de seguridad de Bytesafe son reglas que se ejecutan antes de cualquier acción de registro, evitando que se incluyan versiones de paquetes no deseados en sus registros.

Para evitar que una o varias personas responsables de la seguridad de la dependencia, transfiera la responsabilidad de los desarrolladores individuales a sus equipos mediante herramientas eficientes como Bytesafe.

Utilice la gama de políticas de seguridad en Bytesafe para establecer el control de las dependencias. Un ejemplo es la política de Freeze que se puede utilizar para hacer que los registros sean de solo lectura (temporal o permanentemente). O lapolítica de seguridad que evita que las versiones de paquetes con vulnerabilidades conocidas se incluyan en sus registros.

Lapolítica de bloqueo se puede utilizar para bloquear paquetes completos o rangos de versiones para que no se incluyan en un registro.

Al bloquear los nombres de los paquetes internos en un registro de firewall, los paquetes externos que sustituyen a los paquetes internos ya no son una opción.

Creación de un cortafuegos de dependencia

La idea es simple, crear un enlace al registro público de npm que funcione como un único punto de contacto con el mundo exterior.

Todos los demás registros internos utilizarán este registro de cortafuegos único como fuente de paquete. Esto habilita un punto central donde los equipos de seguridad pueden monitorear y garantizar que solo se incluyan los paquetes aprobados.

Al usar un firewall de dependencia de esta manera, los nuevos paquetes y versiones no se filtran automáticamente a todos los demás usuarios y aplicaciones de una organización.

Tener el mismo nivel de seguridad para todos los paquetes.

Utilice Bytesafe para reunir a sus diferentes equipos (Dev / DevOps / DevSecOps) para colaborar en torno a la seguridad de su dependencia.

A menos que haya configurado explícitamente el uso de un registro privado, el valor predeterminado es usar el registro público directamente. El cliente npm realmente permite la instalación de paquetes desde un registro npm o directamente desde un repositorio git.

Para agregar una capa de seguridad, debe asegurarse de que toda la organización esté usando registros privados para sus propios paquetes que apoyan los paquetes del registro público de npm.

De esta manera, obtiene información sobre qué paquetes se utilizan en una aplicación y tiene la flexibilidad para decidir y controlar el nivel de seguridad.

Al configurar una jerarquía de registros con diferentes niveles de seguridad (conservación y separación de registros), puede aplicar políticas y complementos de Bytesafe en todos sus paquetes, independientemente de si provienen de un registro npm o un repositorio de git.

Por lo tanto, todos los desarrolladores y sistemas que usan paquetes npm deben configurarse para usar registros privados Bytesafe con mayor seguridad y control.

¿Qué seguridad puede agregar Bytesafe?

Tener todos sus propios paquetes y dependencias de código externo en Bytesafe permite el monitoreo, escaneo y control continuos del código que está utilizando.

Saber qué código (y de quién) está utilizando es fundamental para asegurar su cadena de suministro de código. Desplácese hacia la izquierda e identifique cualquier problema al principio del SDLC.]

El uso de Bytesafe proporciona acceso a:

• Registros privados. Comparta sus paquetes dentro de los equipos en registros de artefactos completamente administrados. Almacene en caché las dependencias externas para asegurarse de que siempre estén disponibles
• Identificación de todas las dependencias. Sepa qué dependencias está utilizando. Detecte inmediatamente si alguna dependencia directa y transitiva está marcada como obsoleta
• Firewall de dependencia. Restrinja qué paquetes están permitidos en sus registros con políticas y complementos
• Escaneo de seguridad. Desplácese a la izquierda y detecte las vulnerabilidades con anticipación mediante el escaneo continuo de todos los paquetes
• Cumplimiento de la licencia. Analice qué licencias incluye en sus aplicaciones y sepa si tiene algún problema con la licencia
• Resultados deterministas. Asegúrese de utilizar Bytesafe en su canalización de CI / CD en diferentes entornos. Los probadores podrán probar exactamente las mismas versiones que pretendían los desarrolladores. No más configuraciones erróneas
• Reúna a su equipo. Permita que los desarrolladores, el control de calidad, los expertos en seguridad y los equipos comerciales utilicen las mismas herramientas para evitar una desconexión interna entre los diferentes roles. ¡La seguridad es un esfuerzo de equipo!