¿Cómo calificar las bibliotecas de código abierto?

Lógica maliciosa y puertas traseras. No es probable que encuentres una herramienta automatizada para detectar automáticamente cosas como puertas traseras, lógica maliciosa, bombas de tiempo, etc. Estas son demasiado difíciles de detectar con las técnicas actuales; es demasiado fácil ocultar una puerta trasera que probablemente no encuentren las técnicas de análisis actuales. (Esto es cierto tanto para el análisis estático como para el análisis dinámico). Además, este tipo de puertas traseras son muy poco frecuentes, probablemente no son lo suficientemente comunes como para justificar una inversión significativa en la creación de una herramienta de este tipo.

Creo que deberías preocuparte más por las vulnerabilidades y los errores que por las puertas traseras colocadas maliciosamente. Son mucho más comunes. Y, si se encuentra en un entorno crítico para la seguridad en el que cree que existe una amenaza importante de que un tercero intente insertar deliberadamente una puerta trasera en un fragmento de código en particular que está utilizando, bueno, no debe usar ese fragmento de código. código a menos que confíe en el proveedor.

Hoy en día, las defensas de tiempo de desarrollo más efectivas contra puertas traseras maliciosas y bombas de tiempo son las siguientes:

• Verifique a los desarrolladores. Elija desarrolladores en los que confíe. Normalmente, querrás que sean tus propios empleados. Si utiliza proveedores externos, deberá examinarlos con cuidado.

• Revisión obligatoria del código. Todo el código debe ser revisado por una segunda persona, que no sea el desarrollador. El flujo de trabajo de desarrollo de software y el repositorio deben estar diseñados para rastrear y hacer cumplir esta política. Esto proporciona el control de dos personas: ninguna persona puede introducir un código que no se revisa, y por lo tanto, si todos se toman en serio los requisitos de revisión del código, este proceso debería dificultar que una sola persona introduzca una puerta trasera sin ser detectada. / p>

  Consulte también ¿Cómo revisar el código de las puertas traseras? para obtener información relacionada.

• Repositorio de software seguro. Bloquee el repositorio de código fuente y cree procesos para asegurarse de que ninguna persona con información privilegiada pueda introducir código malicioso en el binario.

Sin embargo, estas técnicas siguen siendo limitadas en su eficacia. Creo que también debería considerar otras defensas, como la transferencia de riesgos, el aislamiento y el sandboxing, y el monitoreo; Lo explico en otra parte de este sitio .

Errores y vulnerabilidades. Yo sugeriría que, para la mayoría de los propósitos, debería preocuparse más por los errores y las vulnerabilidades (introducidas inadvertidamente por desarrolladores bien intencionados pero falibles). Existen muchas herramientas comerciales y de código abierto para escanear el código fuente para detectar errores y vulnerabilidades. Para herramientas comerciales, ver la prensa comercial; verifique, por ejemplo, Fortify, IBM Appscan, Veracode y sus competidores. Las herramientas comerciales son generalmente mejores que las herramientas de código abierto.

Si está utilizando una biblioteca de código abierto de terceros, también le sugeriría que verifique la base de datos de vulnerabilidades de CVE en busca de informes de vulnerabilidades pasados y abiertos. Mire para ver cuántas vulnerabilidades se han notificado, con qué rapidez se informaron y si el proyecto tiene detalles técnicos sobre la naturaleza de la vulnerabilidad. Esto debería darle una idea de la postura de seguridad del proyecto.

Si desea una mirada más profunda, puede consultar la base de datos de Coverity Scan para ver si han escaneado la biblioteca. . También puede consultar el rastreador de errores de la biblioteca para ver cómo han manejado los problemas de seguridad en el pasado. Puede verificar si tienen un proceso de informe de error de seguridad claramente indicado o un lugar para informar de errores de seguridad. Esto le dará una idea de la madurez del proceso de desarrollo de software del proyecto y su actitud hacia la seguridad.

También puede encontrar el siguiente informe técnico de la industria de interés: La desafortunada realidad de las bibliotecas inseguras .

Fuente abierta. Su pregunta parece sugerir que puede estar pensando que las puertas traseras y las bombas de tiempo son una amenaza mayor en el código fuente abierto que en el código fuente cerrado. Si bien eso podría ser cierto, no estoy al tanto de ninguna evidencia de esa afirmación. Si está preocupado por las puertas traseras y las bombas de tiempo, probablemente debería preocuparse por todo el código que está utilizando, código abierto o código cerrado.

Otro repositorio de código abierto para información de seguridad y defectos que he encontrado es el de Coverity , pero hay muchos bibliotecas de código abierto utilizadas en las diversas distribuciones de Linux y bastantes bibliotecas utilizadas en el desarrollo.

Una lista negra de componentes de código abierto "inseguros" sería muy apreciada, pero no pude encontrar uno.

Puede restringir lo que puede hacer el software de Java creando una política de seguridad con la Herramienta de políticas y configurándola como la política para la máquina virtual de Java. Este es el mecanismo de seguridad utilizado para los applets de Java.

Dijiste "código abierto". Eso implica que tienes el código de Java en la mano. Por lo tanto, puede ir más lejos creando pruebas automatizadas para el software Java usando un marco como JUnit más una cantidad considerable de codificación a mano. Puede obtener una cierta cantidad de codificación automatizada para sus pruebas con herramientas como Quickcheck. Finalmente, puede usar una herramienta como Cobertura para verificar que todas las líneas y ramas del código son ejercidas por las pruebas.

Si esa prueba tiene éxito dentro de su política de seguridad, entonces usted ha verificado que el software nunca se aleja de sus restricciones. Es posible que aún no desee eliminar las restricciones de su política de seguridad a menos que realmente lea el código. Por ejemplo, si no ha logrado probar el 100% de las ramas del software (lo que a menudo es difícil de hacer), todavía existe la posibilidad de que el software detecte su política de seguridad, JUnit o Cobertura y restrinja su comportamiento en consecuencia. .