¿Qué se esconde en tu código?

Incluso los proyectos simples tienden a crecer rápidamente y esa tendencia se ve amplificada por la facilidad de incorporar piezas de código o bibliotecas de nodos existentes.

Todavía es algo manejable cuando eres el único que escribe ese código, pero se vuelve más difícil cuando el código lo escriben varios desarrolladores y equipos, como suele ser el caso.

Incluso el líder del equipo, el encargado de aprobar todas las solicitudes de extracción, no puede conocer cada línea de código, cada función y cada variable.

Una cuestión de confianza

Esa es una de las razones del cambio menor de código que tuvo lugar en la aplicación Orion a finales de 2020, en el caso conocido más tarde como Vientos solares, pasó desapercibido durante tanto tiempo. Todo el cambio fue sólo unas pocas docenas de líneas de código, y estaban muy bien oculto dentro de la clase original.

El producto modificado estaba debidamente firmado, por lo que no había motivos para sospechar de ello y los equipos de desarrollo confiaron en el propietario del código.

Sólo recientemente nos hemos enterado de que la NGP tenía un “defecto lógico”que permitía a actores maliciosos hacer pasar bibliotecas no autorizadas como legítimas. Básicamente, NPM permitía agregar a cualquier persona como mantenedor de un paquete sin notificar a estos usuarios ni obtener su consentimiento. 

Esto permitió crear paquetes con malware y asignarlos a mantenedores populares y confiables sin su conocimiento. Un caso de confianza fuera de lugar podría significar una vulnerabilidad problemática oculta en su código.

Otra práctica común a considerar es que los desarrolladores copien y peguen código de bibliotecas existentes o StackOverFlow para usarlo en su propio código o volver a cargarlo en nuevas bibliotecas. Hacer eso aumenta la posibilidad de copiar también código inseguro y vulnerable que ahora esencialmente no tiene seguimiento. Incluso si el código original obtiene un CVE y eventualmente se corrige, la función problemática que copió es invisible y podría contaminar cualquier base de código que la usaría en los años venideros. 

En un estudio reciente realizado en la Universidad de Kansas (“¿Qué es el tenedor? Encontrar clones de código oculto en npm”), los investigadores ilustran cómo el uso de paquetes completamente examinados puede ser inseguro.

¿Qué puedes hacer al respecto?

Por lo tanto, no puede confiar en los productos firmados ni en las actualizaciones de los proveedores. Es posible que su propio código ya haya sido modificado o agregado, debido a todas esas bibliotecas externas y códigos incorporados en él. Entonces, ¿qué puede hacer para estar seguro de que no está instalando archivos maliciosos en su sistema?

Hay algunas cosas que puedes hacer:

1. Solicite un SBOM completo a cada propietario de biblioteca o proveedor de programas que incorpore. Un SBOM puede ayudarle a asegurarse de cuáles son todos los "ingredientes" de la biblioteca o producto. Además, si encuentra algo en la biblioteca o producto que no figura en el SBOM, debe considerarse sospechoso. Puedes conocer más sobre qué es un SBOM aquí.
2. Solicite una certificación confiable del proveedor o propietario de la biblioteca de que se ha realizado una verificación de integridad y de que está obteniendo lo que espera. No debería tener que confiar únicamente en la seguridad del propio proveedor.
   
3. Al instalar paquetes, utilice el indicador CLI npm --ignore-scripts para evitar la ejecución de scripts de paquetes de terceros durante la fase de instalación.
4. Utilizar Paquete-lock.json archivo para bloquear los números de versión del paquete. Cuando usas un Paquete-lock.json no solo bloqueas las versiones de los paquetes que estás usando, sino que también bloqueas sus dependencias. El riesgo es que no obtendrá ninguna actualización automática de paquetes que pueda incluir correcciones a varios errores. Pero, si se ha esforzado por verificar una determinada versión y no desea incluir nada más sin verificarlo primero, bloquear los números de versión es la mejor opción.

Siguiendo nuevas regulaciones, se espera que la mayoría de las personas comiencen a utilizar SBOM en un futuro muy cercano. Cuantas más empresas soliciten SBOM y otras certificaciones, más organizaciones y mantenedores tendrán que cumplir.