Seguridad de Software de Código Abierto

Un proyecto de software es una implementación de un algoritmo en general. Aunque estas implementaciones sólo pueden ser probadas, y las pruebas sólo pueden demostrar la presencia de errores (y no la ausencia de estos), los algoritmos pueden ser probados correctamente. En el cifrado de clave secreta, una de las premisas es que el algoritmo debe ser conocido y sólo una pequeña parte de la información debe mantenerse en secreto: La clave secreta. Es decir, para que un cifrado se considere seguro, se debe de demostrar que el algoritmo es correcto y la prueba de esto debe estar disponible para cualquier persona que quiera utilizar el cifrado. Por lo tanto, en seguridad computacional, hay un consenso de que los algoritmos deben estar abiertos, sin embargo hay un debate sobre si sus implementaciones deben de ser de código abierto (público) o software propietario (secreto).

El esfuerzo de probar (auditar) una implementación se reduce considerablemente, si se centra en la verificación que corresponde al algoritmo correcto (probado previamente). Teniendo en cuenta que el que realiza las pruebas (auditor) tiene acceso al código fuente, esto sólo se puede hacer si el software es de código abierto o software propietario.

Es muy importante entender que la auditoría de software depende del acceso al código fuente. Debido a eso, una nueva auditoría de un software propietario depende de lo que desee el propietario del software, mientras que la auditoría en el software de código abierto se puede hacer en cualquier momento por cualquier persona que lo desee.

Esta preocupación se ha vuelto más y más severa ya que se dejan puertas traseras, en consecuencia, zonas de seguridad de software bien establecidas han sido reveladas. Además de esto, hay un debate en curso sobre si el software de código abierto aumenta la seguridad del software, o afecta a la misma, pero se ha vuelto inútil. A pesar de que algunos de los argumentos de ambos lados son subjetivos y no hay relación entre el número de vulnerabilidades en una aplicación y como es que si es código abierto/propiedad influye, cada uno de ellos puede contener puertas traseras. Sin embargo, sólo el software de código abierto puede ser auditado libremente y por lo tanto, el software propietario debe considerarse inherentemente inseguro

• Más personas pueden inspeccionar el código fuente para encontrar y solucionar una posible vulnerabilidad. Esto puede llevar tanto al descubrimiento de vulnerabilidad de seguridad intencional rápidamente como a la prevención de vulnerabilidades intencionales (puertas traseras) localizadas en el código, el cual es puesto allí por los propios desarrolladores.
• El Software propietario obliga al usuario a aceptar el nivel de seguridad que el proveedor de software está dispuesto a ofrecer y a aceptar la cantidad de "parches" y actualizaciones disponibles.^[1]
• El usuario final del código abierto tiene la capacidad de cambiar y modificar la fuente para implementar cualquier "característica" extra de seguridad que quiera para un uso específico, que puede extenderse hasta el nivel de kernel si así lo desea.
• Se asume que cualquier compilador que es utilizado crea código confiable, pero se ha demostrado por Ken Thompson que un compilador puede ser subvertido utilizando un Thompson hack para crear ejecutables defectuosos que se producen involuntariamente por un desarrollador sin malas intenciones.^[2] Con el acceso al código fuente para el compilador, el desarrollador tiene por lo menos la capacidad de descubrir si hay alguna mala intención.
  • David A. Wheeler demuestra que la existencia de dos diferentes compiladores de auto-compilación de código abierto (que deben de ser capaz de compilar entre sí) se puede utilizar para establecer un binario para uno de ellos que es conocido por no ser subvertido por el Thompson hack.^[3]
• El principio de Kerckhoffs se basa en la idea de que un enemigo puede robar un sistema militar seguro, pero no es capaz de poner en peligro la información. Sus ideas fueron la base para muchas de las prácticas modernas de seguridad , y dice que la seguridad por obscuridad son malas prácticas.^[4]

• Los atacantes pueden encontrar vulnerabilidades más fáciles con el código fuente.
• Simplemente, al crear un código fuente no se garantiza que exista una revisión. Un buen ejemplo de que esto ocurre fue cuando Marcus Ranum, un experto en el diseño de sistemas de seguridad y aplicaciones, lanzó su primer kit de herramientas firewall públicas. Hubo una época en la que había más de 2,000 sitios que usaban este kit de herramientas, pero solo 10 personas dieron algún comentario de retroalimentación o algún parche.^[5]
• Tener una gran cantidad de ojos revisando el código puede "hacer que un usuario tenga una falsa sensación de seguridad".^[6] Tener muchos usuarios mirando el código fuente no garantiza que los problemas de seguridad se vayan a encontrar y arreglar.