En [PDF] Integrating Software Security Into The. Software Development Lifecycle un artículo con ideas generales sobre el tema. Puede ser valioso para ordenar ideas o como introducción preliminar donde no se haya pensado mucho aún en estas cosas.
En Size is the best predictor of code quality un par de enlaces y punteros a estudios sobre el tema (cuando los lea tal vez volvamos sobre ello).
Comenta sobre las métricas de código y su impacto en la robustez y fiabilidad del código y cómo parece que el tamaño sigue siendo un buen predictor.
Creo que habíamos hablado del tema en algún momento, pero no lo encuentro.
A pesar de que me dedico a ello, en esta bitácora no suelo hablar mucho de formación y enseñanza. En todo caso, vi If You’re Going to Teach an Undergrad Intro to Software Engineering… y pensé que aunque no es un tema de mi especialidad debería guardarlo en algún sitio. ¿Cuál mejor que este?
Además, me ha interesado que varias referencias tratan sobre desarrollo de software libre, lo que me parece un plus.
Ya hace algún tiempo que tenía estos enlaces. pero necesitaba un ratito para recopilarlos porque andaban dispersos por ahí. Llevamos unos años hablando de metodologías ágiles de desarrollo (en contraposición con otras metodologías más pesadas y tradicionales). Pero yo no había visto mucho de cómo introducir la seguridad en estos contextos. Hasta que encontré estos textos, que comparto aquí:
Agile Security – Requirements. En el resumen:
As a product owner you have scores of tools and processes to help you find vulnerabilities after they’ve been coded. Adopting security throughout the SDLC is cost effective, but difficult in practice to implement for agile shops. Security requirements, in particular, are difficult to prioritize or scope in early iterations. You can make the task more manageable by prioritizing requirements that prevent exploitable flaws, sorted by risk.
En Agile Security – Product Owner’s Perspective continúa, en este caso con lecturas recomendadas, motivaciones y consejos. Aunque prometen más, parece que la serie no ha seguido, siendo el último articulito uno genérico, que no habla de seguridad ágil, sino algo más genérico: Software Security Throughout the Life Cycle: 9 Steps.
Ahora ustedes podrían sentirse decepcionados por la escasez de los recursos aportados (o no). Para que eso no suceda, y como tenía más artículos recopilados, van a continuación.
En Secure software development and agile methods – notes unas notas sobre el tema, a partir de una sesión dedicada al tema en Finlandia, en la que participaba gente de Nokia (¿Nokia ágil?) y de F-Secure. Está resumida pero va bastante al grano y además se pueden descargar las presentaciones que se utilizaron.
Haciendo una búsqueda en Google encuentro el The Agile Security Forum al que habrá que echar un ojillo con más calma. Microsoft también tiene un documento en Streamline Security Practices For Agile Development donde tratan de encajarlo con su SDL (Secure Development Cycle). Finalmente (por acabar, no porque no haya más documentos sobre el tema), en Agile Security Engineering J.D. Meier también aporta su punto de vista.
En Brief study of the Android community:
Having a look at the name of the domains, it is very surprising that Nokia is one of the most active contributors. This is a real paradox, the company that states that Android is its main competition helps it!. One of the effects of using libre software licenses for your work is that even your competition can use your code…
Curioso.
Aunque parece claro que en un estudio de este tipo sólo se pueden leer bondades, me ha parecido interesante por la revisión de tendencias (al menos en el contexto de Microsoft) y los diferentes asuntos a los que han ido prestando atención a lo largo del tiempo. Lo presentan en For your consideration: The SDL Progress Report y se puede descargar en Microsoft SDL Progress Report.
Uno de los problemas cuando nos entra la preocupación por el desarrollo seguro es integrarlo en las rutinas habituales de ingeniería del software: a los fallos y sus medidas habituales (pruebas y todo lo relacionado) se añaden los fallos de seguridad que también son fallos, con características un poco especiales. Robert Auger nos cuenta en Tracking and understanding security related defects algunas ideas sobre el tema: básicamente integrarlos en el sistema de seguimiento de fallos (bug tracking) y marcarlos adecuadamente (o además) como fallos de seguridad para que podamos hacer un seguimiento (sin olvidar que algunos fallos de seguridad no se marcarán como tales) y también hacer algo de pedagogía (proporcionando listas de fallos frecuentes, apoyo a los desarrolladores que controlen todavía mucho de estos temas, vigilancia sobre si se están tratando adecuadamente …).
Lo veo en 6 Easy Ways To Get Started Programming Open Source y habla de 6 Easy Ways To Get Started Programming Open Source:
Internet nos ofrece un mundo de datos por explorar. Teniendo en cuenta que son aproximaciones (porque los datos no son completos, o tienen sus propias dinámicas, …) podemos aprender algunas cosas. En este caso en Evaluating Open Source Participation by Email Traffic nos hablan de una recopilación de listas de correo de proyectos de software libre y un análisis sencillo, basado en el origen de los mensajes (buscando los dominios de los mails corporativos de algunas empresas) que nos da algunas ideas de quién y cuánto ha contribuido (a través de la participación de sus empleados en las listas de correo).
Además de los datos sobre algunas empresas conocidas, podemos ver que gmail es el servicio favorito de los desarrolladores de software libre (gana por goleada a hotmail y Yahoo!) y también podemos hacer nuestras propias indagaciones: por ejemplo participación de gente del dominio unizar.es.
Esta entrada claramente era dudosa entre esta bitácora y la otra pero como el otro día puse allí la entrada Sensores como nosotros y aquí se habla un poco de software libre, he preferido ponerla aquí.
Diaspora es el autoproclamado proyecto de un sistema de redes sociales (como Facebook, por ejemplo) respetuoso con nuestra intimidad y privacidad. Se trata de un proyecto de código libre y recientemente liberaron las primeras muestras que ya han provocado algún comentario. En particular, en Security Lessons Learned From The Diaspora Launch muestran algunas pegas.
Es interesante porque, en este caso, contradice aquel aviso típico de que aunque se tenga el código fuente, no tiene porque mirarlo nadie, puesto que en este caso alguien ha mirado el código.
Naturalmente, el tratarse de software libre no le proporciona poderes mágicos y, en este caso, parece que los desarrolladores están más preocupados por la privacidad que por la efectividad de su código a la hora de salvaguardar los contenidos del sitio y esas cosas.
Vale la pena echarle un ojo porque son ejemplos de código con errores concretos que nos puede servir para aprender.
