Random IRC quote :      <madalenasbuen-1> el taxista avanza si no se le combate

Software 100% Bug free

Después de escuchar un breve comentario de un periodista sobre la seguridad del nuevo Windows Vista, en relación con el SpyWare y Virus, cuya conclusion fue que nunca se logrará construir software libre de fallos, no he podido evitar dirigirme aqui y escribir este post.

Empecere diferenciando las tres clases de fallos que se dan en toda construccion software:

  1. Bugs en los requisitos: Son aquellos que afectan a la funcionalidad requerida por el cliente y que no han sabido ser entendidos por las personsas encargadas de esta fase. Un par de ejemplos podria ser incluir solo el tipo de moneda en pesetas o que el motor no debe superar las 3000 rpm.
  2. Bugs en el diseño: Aqui es donde empiezan a surgir los fallos que nos interesan, aquellos relacionados con la seguridad o funcionalidad crítiticas de la aplicacion. Los fallos surgen por considerar triviales, hacer caso omiso o por simple desconocimiento de los casos en los que se está trabajando. Ejemplos serían el fallo de seguridad que hace poco se presento en freeVNC o no contemplar el caso en que si el cohete supera la inclinacion permitida hay que reectificar la trayectoria.
  3. Bugs en la implementación: En este ultimo tipo entrarían los fallos de tipo tecnologico, es decir, provocados por no entender las herramientas con las que se está trabajando. Los archiconocidos overflows o fallos en el parseo de cadenas son simplemente algunos, de los que seguramente sabreís mas que yo.

Desde mi punto de vista, estoy seguro que se conseguiran reducir los bugs en las aplicaciones a medida que se van estandarizando las tecnicas para construir las mismas, llegando a alcanzar aplicaciones 100% libres de bugs en la mayoria de los casos.

Solucionar el primer tipo de bugs, el relativo a la fase de requisitos, quizás sea el mas dificil de todos, ya que el factor humano es completamente imprescindible. Si bien existen multiples técnicas que aplicadas correctamente ayudan a depurar los bugs en esta fase, este tipo de fallos son los que menos nos interesan porque suelen afectar solo a lo que el cliente necesita.

Nuevos avances para solucionar el segundo tipo de fallos están surgiendo a la par que se soluciones se van necesitando. El subconjunto que más me llama la atención son aquellos que tienen que ver con los metodos formales, los cuales permiten estables modelos matematicos, mediante los cuales se puede demostrar que nuestro diseño concuerda perfectamente con los requisitos de la aplicación que estamos modelando.

En cuanto al último tipo una solucion fácil y directa seria hacer que los programadores tuvieran la formación necesaria para realizar su trabajo correctamente. Complicado? Por supuesto dado el gran y creciente numero de tecnologías disponibles y utilizadas en un proyecto concreto. De la misma manera que con el diseño surgen nuevos metodos que ayudan a automatizar la generación de código, lo cual se asemeja a la producción de hardware bastante madura y casi 100% bug free.

Obviamente lo comentado hasta ahora solo es aplicable al desarrollo en el que nosotros estamos trabajando y no mejorara la seguridad total del usuario final si el sistema operativo y el resto de servicios en los cuales confiamos no son seguros. Quizás esta sea la fase mas «facil» de llevar a cabo, pero depende de que alguien se ponga manos a la obra con mucho dinero por medio.

La solucion pasaria por construir una base de la que se pueda afirmar su seguridad y que exporte las funcionalidades minimas para crear sobre él servicios seguros aplicando el principle of less authority. Pudiendo ofrecer al usuario un control fino del software que el mismo ejecuta.

Espero que la ensalada de ideas que he escrito os ayude a refrescaros un poco este verano 🙂 A pasarlo bien!

14 Comentarios para “Software 100% Bug free”

  1. Comment por mballano | 08/15/06 at 5:48 am

    Bueno, estoy de acuerdo en bastante parte de lo que expone Gabriel, yo también creo que es posible desarrollar software 100% libre de fallos y esto es porque el software puede y debería ser perfecto. Creo que en esta línea es por donde irán surgiendo (y se intentará vender/promocionar) cada vez más el uso de herramientas CASE como solución a algunos de los problemas que plantea Gabriel.

    De cualquier modo pienso que en todo proyecto de software hay puntos críticos que son más propensos a contener errores de programación o diseño cuya modelación quizá es muy dificil incluir en herramientas de «diseño de software» … a lo que me refiero es que no me imagino por ejemplo a alguien haciendo un driver para un nuevo hardware con una herramienta que trabaje con una sintaxis tipo UML (cuando sea viejo me fustigaré por haber dicho esto). Es por esto por lo que cuando me pregunto… ¿llegará a ser el software algun dia 100% libre de bugs?, creo que no, es imposible, porque como bien se apunta en el post la mayor parte de los desarrollos de software serios poseen y poseerán en mayor o menor medida de una serie de «CriticalSections xDD» que siempre van a depender de un lado humano, la cara o el punto de vista del programador que los ha diseñado.

    Con estos proyectos de software de los que hablo me refiero a sistemas que requieren, y creo que siempre lo van a hacer, de una programación orientada a bajo nivel, en el otro lado tendríamos apilcaciones de gestión o similares las cuales supongo que podrían progresar de una manera más eficiente en este campo, quién sabe quizá algun día exista una certificacion «oficial» que asegure que tu software está libre de bugs, o incluso un «validador» automatizado de aplicaciones,,, ¿os lo imaginaís? 🙂

  2. Comment por Zohiartze | 08/16/06 at 8:52 am

    Gabriel, la impresión que a mi me da es que todo esto que comentas es demasiado técnico para la mayoría de la gente. En mi ambito de trabajo, veo proyectos en los que participan un huevo de personas sin conocimientos informáticos, que se supone deben conocer la lógica del negocio para el que se desarrolla el software. Además, son estas personas las que suelen gestionar los proyectos, asi que en lo que se refiere a las aplicaciones de gestión, veo lejos la posibilidad de mejorar la calidad del código para minimizar los bugs. O aparecen herramientas muy potentes y muy secillitas de utilizar, o la cosa no avanzará.

    También es cierto que he visto interfaces graficas de desarrollo, (con arquitecturas especificas propietarias) que minimizando el código que tiene que picarse el desarrollador, hacen el software menos propenso a determinados bugs… pero son un puto toston de la muerte con otros cientos de problemas añadidos.

  3. Comment por Gabriel Gonzalez | 08/16/06 at 9:52 am

    Lo que tiene que regularse es quien puede dedicarse a la gestion y coordinacion (management/analisis) de proyectos. Obviamente se deberian requerir unos conocimientos minimos para poder ejercer esa profesion, como en cualquier otra que requiere un poco de profesionalidad. Pero hasta que no se estabilice un poco el negocio va a ser dificil que se consiga.

  4. Comment por pedrolt | 09/04/06 at 8:46 am

    Según se trabaja en las empresas informáticas en las que sólo les importa la «forma» delante del cliente y no el contenido. Me temo que va a ser imposible. Lo primero que hay que hacer es cambiar la mentalidad de las empresas de software.
    Vamos a desarrollar una nueva técnología revolucionaria en tres meses porque otra empresa de la competencia lo va a hacer en cuatro. Y vamos ha hacerlo más barato porque somos los mejores por eso vamos a contratar cinco becarios más y después les decimos que no han rendido lo suficiente.
    ¿Señores gestores? ¿Saben lo que es la ingeniería del software? ¿Saben los costes de mantenimiento, solución de incidencias en el cliente, y de posibles ampliaciones de un software: mal diseñado, sin suficiente tiempo para desarrollarlo, con programadores sin formar, con módulos reparcheados por un montón de gente que ni sabe lo que está haciendo ni que implicaciones tiene en el diseño?

    Lo siento pero soy pesimista, creo que el software cada vez estará peor hecho.

  5. Comment por Diego Bauche | 09/05/06 at 3:52 am

    No existe software 100% libre de bugs, al menos no en proyectos de gran impacto.

    Existen muchas razones por las cuales seguimos viendo bugs y bugs:

    1. Los creadores de software en el mercado grande (como serian Microsoft, Oracle, IBM, etc.) tienen un factor llamado «time-to-market» que basicamente presiona a los programadores a entregar su trabajo en una fecha.
    2. La cantidad de codigo que se realiza en estas empresas es bastante grande, por lo tanto buscar bugs y parcharlos no es una tarea facil.

    y 4. A estas empresas, lo que no les haga perder dinero, no es importante.

    Vamos a tomar un caso de ejemplo: Microsoft. y vamos a hablar de un tema en especifico: bugs de seguridad.

    Primero que nada, recuerden que microsoft no lucra con updates y parches para bugs, microsoft obtiene sus ganancias de vender sus productos, y punto. El costo para Microsoft por perdidas generadas por bugs era insignificante… era.

    Porque era y no es?, en 2 palabras, los medios. La respuesta masiva a los errores de seguridad fue
    aumentando mas y mas conforme pasaban los meses, hasta el punto en que un noticiero de TV comun tenia como noticia importante el hecho de que habia 3 Gusanos rondando que estaban generando perdidas multimillonarias a empresas y usuarios, 3 gusanos que se aprovechaban de bugs en el software de Microsoft… Microsoft por fin fue el culpable, y no los empleados de la empresa afectada.

    Que genero esto?, Microsoft aumento su presupuesto para la seguridad se sus productos de forma impresionante, pero el propio microsoft se dio cuenta de algo: Buscar y parchar bugs es una tarea dificil. Y despues de a~os (Desde Windows 2000, pasando por Explorer 6) hasta Windows XP SP2 y Windows 2003 SP1), se dieron cuenta que la solucion a los problemas de seguridad desde un aspecto de programacion no se encontraba necesariamente en eliminar estos mismos, sino en hacerlos inmunes, o incluso evadirlos.

    MS empezo a desarrollo una tecnologia llamada DEP (Data Execution Prevention), Esta tecnologia se encarga de hacerle la vida CASI imposible a los programadores de pruebas de concepto (como son los exploits y los gusanos) en su tarea de aprovecharse de fallas de seguridad, resultado?, una disminucion de casi el 90% de las quejas de sus clientes y de gusanos.

    Conclusion?, una muy deprimente en realidad, las empresas nunca van a enfocarse en parchar sus bugs, cuesta mucho dinero y tienen cosas mas importantes con que lucrar =\

    Saludos.

  6. Comment por Diego Bauche | 09/05/06 at 3:55 am

    Cuantos errores gramaticales me avente?, RECORD

  7. Comment por Gabriel Gonzalez | 09/05/06 at 11:06 am

    Diego Bauche, la solucion no es parchear los bugs que existen, si no producir software libre de bugs. Ese es el salto cuantitativo que creo se debe producir si queremos que se tome nuestra profesion en serio.

  8. Comment por Diego Bauche | 09/05/06 at 10:56 pm

    Gabriel Gonzalez: Creo que todos somos humanos, y crear software libre de bugs no se trata de programar un software desde 0 que este completamente limpio, ya que eso es imposible, la mejor solucion para crear software libre de bugs, es parcharlos, ya que no existe otro metodo.

    Saludos.

  9. Comment por Gabriel Gonzalez | 09/06/06 at 10:01 am

    Diego Bauche, parece que no has entendido del todo el post, o quizas no me he expresado bien, lo que en el fondo propongo es que con la introduiccion de metodos automatizados y, en algunos casos, formales en los ciclos de vida de la aplicacion, se podra reducir el numero de bugs, sobre todo los que cometemos los programadores.

    Esta claro que ni hoy ni mañana se van a llevar a cabo lo que propongo, te aseguro que a muchas empresas les saldria mucho mas barato realizar una auditori ade codigo exaustiva que los costos que con lleva descubrir el fallo, crear el parche y distribuirlo. Como ejemplo en OpenBSD revisaron el nucleo en busca de fallos, lo que les llevo apenas un año, )obviamente no todo el mundo trabaja full-time ).

    Otra cosa diferente que intentaba explicar en el post es que los sistemas operativos, dicho sea Windows, deberian implementar politicas de seguridad de grano fino, ademas de la separacion adecuada de privilegios, etc. De esta manera, se podria evitar la propagacion de los fallos de una aplicacion.

    Espero que haya quedado un poco mas claro.

  10. Comment por Diego Bauche | 09/06/06 at 5:46 pm

    Estoy completamente de acuerdo contigo, y tenia muy claro lo que intentabas explicar.

    El problema es que esto ya existe, se entiende «Metodos automatizados» como:
    1. Algoritmia, la solucion a muchisimos de tus problemas.
    2. Especificaciones (RFCs, documentacion de protocolos, etc.)
    3. Reusar codigo.
    4. Bibliotecas.

    Y el problema es que, aun usando todo esto, el codigo especifico de una aplicacion, el codigo reusado, el algoritmo, la biblioteca, o las especificaciones tambien suelen tener fallas. Otro problema es que siempre existen protocolos nuevos, algoritmos nuevos, herramientes nuevas, y todo tipo de cosas que hacen que las bibliotecas, el codigo reusado, y hasta las especificaciones, sean relativamente nuevas y tengan fallos, es una carrera contra el tiempo.

    En alucion a esto:
    > «Esta claro que ni hoy ni mañana se van a llevar a cabo lo que propongo, te aseguro que a muchas empresas les saldria mucho mas barato realizar una auditori ade codigo exaustiva que los costos que con lleva descubrir el fallo»

    No se que tipo de programador seas, o si tengas experiencia en la auditoria de codigo, pero en lo que respecta al resto de nosotros, hacer una busqueda de fallos en un codigo, sea una auditoria exhaustiva o parcial, es con el proposito de encontrar bugs Y PARCHARLOS, a final de cuentas, no entiendo como es esto diferente, yo nunca hable de como encontrar bugs, yo hable de reparar bugs.

    Estoy de acuerdo con tu propuesta de la separacion de privilegios en Windows, el problema es que siempre existe un punto en la aplicacion en la que la mayoria de los servicios de, svchost.exe por ejemplo, tienen que comunicarse al kernel, por lo tanto no se puede hacer una separacion de privilegios de servicios criticos que realmente necesiten tener privilegios altos. La idea de separacion de privilegios se creo para aplicaciones en user-land. Pero a final de cuentas, es una propuesta buena, de la que estoy seguro que Microsoft ya debe estar estudiando. Tal vez estoy equivocado y puede haber alguna solucion para este problema de la comunicacion con el kernel o hasta RING-0.

    Saludos.

    PD: Tienen algun IRC o algo parecido esta comunidad?, tienen temas bastante interesantes y de habla hispana, eso es dificil de encontrar en mi opinion.

  11. Comment por mballano | 09/07/06 at 4:45 pm

    tenemos foros, y IRC aunque este último no lo estamos usando mucho ultimamente (y no está levantado ahora mismo), pasate por los foros Diego, tienes un enlace en la parte superior de esta web.

    Un saludo! 🙂

  12. Comment por Zohiartze Herce | 09/08/06 at 10:20 am

    En relación con algunos comentarios anteriores, os dejo este link del blog de Bruce Schneier:

    http://www.schneier.com/blog/archives/2006/09/microsoft_and_f.html

    Para las empresas, arreglar bugs unicamente supone perdidas (a no ser que sean empresas de servicios que vendan un mantenimiento posterior a la instalacion del producto). Creo que Schneier lo explica bien: si no fuese por la cada vez mayor notoriedad que se les da a los bugs hoy en dia, las empresas no parchearian o lo seguirian haciendo tan mal como lo hacian antes. Las grandes compañias prefieren que los bugs se les notifiquen a ellas y que ademas se les deje decidir cuando parchear.

    http://www.securityfocus.com/columnists/415

    Ademas dicen que quien encuentra un bug y lo detalla de cara al publico, esta actuando mal. Y sin embargo gracias a esta actitud estas empresas se han visto forzadas a mejorar sus medidas para distribuir patchs. Mas aun, como hoy en dia estan obligadas a parchear y a hacerlo rapido y como hemos dicho que eso solo les supone perdidas, ahora se encuentran con el siguiente dilema: ¿Que sale mas barato, realizar bien el software desde el principio o verse obligadas a parchear gratuitamente mas adelante? Si deciden desarrollar bien el software desde el principio, podran calcular cuanto dinero les va a costar desarrollar el producto y calcular el precio adecuado de venta, pero ¿quien puede calcular de antemano las perdidas que les generara el parchear bugs gratuitamente? Por lo tanto, cuanto mejor este desarrollado el software, menos incertidumbre tendra el fabricante sobre los costes de mantenimiento de su producto.

    La solucion ideal para estas grandes empresas seria tal vez una tercera: que sean terceras empresas las que desarrollen soluciones a sus fallos (soluciones temporales), dandoles tiempo a las ratitas a parchear su software en los plazos que crean preciso y haciendolo por lo tanto algo mas rentable. Empreas como iDefense, representan en el fondo una idea similar.

  13. Comment por Nacho.V | 12/22/06 at 6:20 pm

    Los bugs son inherentes a la programación, cuanto mas se automaticen las tareas (teoricamente) menos bugs habrá.
    Con la apariciòn de lenguajes y herramientas como .NET ( y anteriormente Java ) se prima mas el esfuerzo en el analisis y diseño que en la implementación final. y progresivamente se tiende a dejar las menores responsabilidades posibles al programador.
    Obviamente, como apunta mballano, codear un driver es más que rellenar el codigo de unas clases (aunque sinteticamente se podria reducir a eso) y no se podrian aplicar frameworks o generadores de codigo facilmente.

    En caso de bugs, es mas facil buscar solo en el codigo que has escrito tu que en el de la aplicacion completa. si el fallo es de la herramienta se parchea y se regeneran todas las aplicaciones.. de esta forma se tiene la seguridad que ese bug no estara presente y no habra que parchear cada aplicacion generada por separado.

    Por cierto, es la primera vez que me paso por aqui y me he llevado una grata sorpresa, se tocan temas interesantes y hay gente de mucho nivel de la que se pueden aprender cosas 🙂

  14. Comment por Alfredo | 09/05/08 at 2:38 pm

    Cuando la cantidad de Bugs tiende a cero, el costo tiende a infinito. El software 100% libre de errores, no existe.
    La prueba de esto esta en que para descubrir todos los errores de por ej, internet explorer, hacen falta tantos «testers» como usuarios tiene. y aun así, nadie puede decir que ya se hayan encontrado todos los bugs posibles.

Se han cerrado los comentarios