Auditoría de código fuente y compilaciones falsas

Todo depende del alcance de la auditoría.

Si la auditoría se basa exclusivamente en el código (es decir, entregue al auditor una copia del código, la audite y devuelve un informe), entonces podría ser muy fácil manipularlo después del hecho.

Si la auditoría es un poco más completa e incluye el desarrollo del código, la prueba y la promoción a los procedimientos del entorno real, debería poder descartar la mayoría de las oportunidades para que se produzca una manipulación indebida.

Si además audita el proceso de administración de cambios en curso, y realiza verificaciones de confirmación regulares en el código en vivo, entonces se asegura que el código en vivo es el código desarrollado y probado, y que es apropiado para propósito.

Esta es la razón por la que las auditorías de alcance limitado pueden ser esencialmente inútiles, aparte de tener una marca en la casilla (que puede ser útil ...)

Todo depende de dónde esté su límite de confianza. Recomendaría leer Reflexiones sobre la confianza en confiar por Ken Thompson [ 1 ].

Esperemos que los auditores proporcionen una firma o hash del archivo o fuente que se audita; De esta manera, al menos puede verificar que realmente está ejecutando el mismo código que se revisó.

Sin embargo, incluso si no confía en los auditores y lo compila desde la fuente que sabe que es bueno (fingiremos que es realmente bueno para detectar amenazas en el código que probablemente está diseñado para ocultarlas), Todavía tienes que confiar en tu compilador. O, en el caso de que esté descargando una versión compilada por los auditores, su compilador.

Si bien es probable que esto sea seguro, es bueno reconocer que compilarlo usted mismo no es infalible. Nunca puedes confiar completamente en nada ; debe establecer un límite de confianza y decidir en qué punto desea aceptar algo como seguro.

Es por eso que mucha gente usa GIT y Jenkings. La idea es que todo el código entra en un repositorio centralizado. Ninguna persona tiene acceso completo a la compilación completa, cuando un programador envía un fragmento de código, otro programador lo comprueba antes de que se lo suba a la rama. Un programador no puede simplemente cambiar el código o compilar a voluntad.

Normalmente, una auditoría del código fuente se realiza justo antes de compilar, el auditor verá el código del cheque justo antes de compilarlo y nadie más puede hacer modificaciones sin que el auditor lo apruebe. También tenga en cuenta que el auditor no puede introducir el código por sí mismo. Esto significa que no puedes enviar nada.

Lamentablemente, esta es la situación ideal y no se realiza en todas partes. Uno de los conceptos básicos de la gestión de cambios es tener 3 entornos:

• Desarrollo
• Garantía de calidad
• Producción

En el desarrollo, todos los programadores obtienen acceso, en el control de calidad solo unos pocos (lo menos posible) y en producción ningún programador debe tener acceso . Todo esto genera una cantidad razonable de seguridad, pero aún puede haber alteraciones. Al final, intentas cubrir el riesgo lo mejor posible, pero nada es infalible.

Diría que es básicamente imposible que un cliente confíe en que una construcción corresponde a una fuente auditada a menos que él mismo la haya creado. Incluso eso es ninguna garantía contra la presencia de puertas traseras u otras características indeseables, una puerta trasera es lo mismo que un error, nunca puedes probar que no hay ninguna.

A menudo me pregunto cómo funciona esto en situaciones donde la confianza total es problemática. Cuando los EE. UU. Venden F-16 a Pakistán, ¿cómo saben los pakistaníes que no hay una puerta trasera en la aviónica que los hará ciegos a los helicópteros ocultos? Oops.