Sueños y pesadillas

En Dreams and Nightmares algunas ideas sobre un taller donde se analizaba la tensión permanente entre hacer cosas que tengan valor y la necesidad de invertir en crear una buena infraestructura que les de soporte. El debate entre la técnica y la economía.

Se propone incluir en la planificación escenarios terroríficos (la pesadilla) que pueden suceder si algo va mal y no se ha invertido suficiente en que la base sea sólida: se estima el coste, el esfuerzo necesario en caso de que algo vaya mal…

El problema de algunos requisitos no funcionales de este tipo es que no encajan siempre bien con las historias de usuario y por lo tanto son complicados de integrar en el proceso. Pero estos requisitos han de tenerse en cuenta y no perderse de vista en las sucesivas iteraciones.

Interesante.

Anuncios

Desarrolladores y desarrollo seguro

Como ya llevamos años con el tema es agradable ver como, de vez en cuando, más gente lo dice. En este caso lo vi en Los desarrolladores de software necesitan saber hacer software seguro.

Yo estoy bastante convencido de eso, pero como dice el autor no todo el mundo lo tiene claro y en los equipos ágiles es fundamental:

La conclusión a la que se llegó es que los desarrolladores de software necesitan formación en seguridad para que puedan diseñar y desarrollar software seguro, al menos, en cuanto a unos requisitos mínimos se refiere. Y es que estamos hablando de calidad del software.

Integración de la seguridad en el ciclo de desarrollo

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.

El tamaño (del código) importa

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.

Formación en Ingeniería del Software

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.

Desarrollo ágil y seguridad

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.

Estudio sobre la comunidad de Android

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.

Informe sobre el progreso del Ciclo de Desarrollo Seguro de Microsoft

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.

Seguimiento y comprensión de fallos relacionados con la seguridad

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 …).

Seis formas de empezar a programar software libre

Lo veo en 6 Easy Ways To Get Started Programming Open Source y habla de 6 Easy Ways To Get Started Programming Open Source:

  1. Implicarse en los proyectos que utilizamos
  2. Hacer lo que nos gusta
  3. Aprender las herramientas
  4. Fijarse en las dinámicas sociales del proyecto
  5. Empezar por cosas pequeñas
  6. Empezar nuestro propio proyecto