¿Cómo hace para verificar las bibliotecas de código abierto para los registradores de pulsaciones de teclas?

Una persona aleatoria en Internet me dijo que una tecnología era segura (1), segura de usar y que no contenía keyloggers porque era de código abierto. Si bien puedo detectar trivialmente el registrador de pulsaciones de teclas en esta aplicación de código abierto , ¿qué pueden hacer los desarrolladores (2) para protegerse contra los enrutadores para proyectos de código abierto?

Haciendo un análisis posterior de la amenaza del sobre, si fuera un desarrollador malintencionado, bifurcaría una rama en git y promovería su descarga, ya que tendría soporte para Twitter (y un registrador de pulsaciones de teclas secreto). Si se tratara de un repositorio SVN, crearía solo crear un nuevo proyecto. Aún mejor sería poner el código malicioso en las rutinas de actualización automática.

(1) No mencionaré cuál porque solo puedo tratar con un tipo de fanático a la vez.

(2) Los usuarios comunes están a merced de su software de detección de virus y malware; es absurdo esperar que la abuela lea la fuente del código del código fuente de su procesador de textos de código abierto para encontrar el registrador de pulsaciones de teclas.

Recientemente tuve la oportunidad de realizar un análisis de seguridad de software en FileZilla, eMule y Shareaza. Ejecuté el código a través de cppcheck, RATS e ITS4. Ninguna herramienta podrá discernir si un código es benigno o dañino. Requiere inspección visual, que es lo que hice. Pasé dos semanas examinando línea por línea cada pieza de código fuente. Probablemente me perdí algo. Es por eso que mi trabajo fue respaldado por otra persona que también encontró lo mismo o más que yo. Por ejemplo, FileZilla utiliza un script PHP para determinar su dirección IP externa cuando está en modo PASV. ¿Qué hace ese script PHP? ¿Quién lo sabe realmente? Veo tu punto y punto bien entendido. Dependiendo de su estrategia, debe tomar una estrategia de mitigación de riesgos y examinar la fuente usted mismo o contratar consultores externos. De esa manera se asegurará de que el software sea seguro.

Esto entra en la categoría "confía en él, su código abierto". Si suficientes personas están mirando el código de un proyecto, es poco probable que alguien pueda pasar algo nefasto. Además, observe la reputación de la parte que respalda el proyecto. ¿Es J. Random Coder o Apache Software Foundation? Obviamente, cuanto más pequeña es la base de código, más difícil es introducir algo. ¿Y el proyecto de código abierto depende de bibliotecas externas que no sean de código abierto? Si un proyecto es una rama personalizada de un proyecto oscuro alojado en un sitio web desconocido ... bueno.

Además, no me preocuparía específicamente por los keyloggers, sino por más seguridad en general. Esto incluye infracciones de seguridad accidentales, que tienen muchas más probabilidades de ocurrir en un proyecto pequeño. Las puertas traseras, la privacidad mal implementada y el acceso necesario al sistema son riesgos que son más probables que un keylogger intencional.

Los desarrolladores pueden evitar que los delincuentes se comprometan con sus proyectos de código abierto al no otorgar privilegios a todos y a sus pingüinos. El principio distintivo del software libre / código abierto no es que el desarrollo sea de origen público (aunque puede serlo) sino que es posible bifurcar proyectos.

Las personas que descargan software deben tener un poco de cuidado, y eso es tan cierto para F / OSS como para el software propietario / de código cerrado. El software que obtiene de una fuente confiable generalmente es bueno (en cualquier caso); El software de un vuelo nocturno es más probable que tenga malware.

No es que alguien haya comprometido el acceso a ningún proyecto de código abierto. E incluso si alguien comete código malicioso, se puede descubrir ya que la fuente es pública. Si no confía en los gerentes del proyecto, siempre puede contratar a alguien como 0A0D para que inspeccione el código por usted. No es perfecto, pero es mejor que la alternativa;

Para un proyecto de código cerrado, solo tiene que confiar en el proveedor. ¿Cómo sabe que no hay puertas traseras en el software de código cerrado? Usted no El código malicioso puede haber sido agregado por un empleado descontento, alguien que busca una forma de ganar algo de dinero, un conserje malvado que resultó tener acceso al repositorio de la compañía ... En el software de código cerrado, no hay forma de saberlo.