Desenvolvimento de código seguro: inviável com Agile?

As equipes ágeis são reconhecidas por produzirem, com velocidade, código confiável e de alta qualidade. No entanto, observa-se que uma pressão por tal velocidade pode resultar em revisões de código e testes limitados e, por fim, na falta de atenção a aspectos de segurança. Seria o desenvolvimento de código seguro inviável dentro de Agile?

Um estudo realizado com pequenas e médias empresas indica que as equipes ágeis não levam as questões de segurança a sério, mesmo quando estão construindo sistemas que estarão acessíveis pela web. O estudo diz:

Mesmo em casos em que a segurança é um requisito forte e a modelagem dos aspectos de segurança é solicitada à equipe, não há garantia de que o resultado final atenda aos critérios de qualidade esperados.

Adrian Lane também analisou os riscos de segurança associados ao desenvolvimento de software através de metodologias ágeis. De acordo com Lane:

As implementações de Agile, baseadas nas instruções contidas em livros, tem principalmente o foco na entrega eficiente de funcionalidades de negócio, o que ocorre à custa de uma negligência aos aspectos de segurança, deixando-os fora do escopo do desenvolvimento.

Rocky Heckman sugere que mesmo com técnicas como desenvolvimento orientado a testes (TDD) e programação em pares, o foco continua a ser principalmente sobre a entrega de funcionalidades:

O objetivo principal dos testes é a geração de código de alta qualidade, sempre com a perspectiva de novas funcionalidades e a confiabilidade na repetição das operações. Há pouca ou nenhuma atenção aos testes contra ameaças e vulnerabilidades.

O desenvolvimento ágil representa então uma total negligência às questões de segurança? Existem alternativas.

Jim Bird sugere que com um pouco de cautela é possível lidar com os riscos de maneira incremental. De acordo com Bird, as práticas de segurança devem ser inseridas no trabalho das equipes, como quaisquer outras práticas de qualidade. Por exemplo, as equipes podem utilizar de maneira incremental a análise da superfície de ataque para acompanharem as mudanças no perfil de riscos do sistema, que podem ser causadas por mudanças arquiteturais.

A modelagem contra ameaças não deve ser uma grande dificuldade para equipes que estão construindo software incrementalmente e que conhecem bem o seu código. As alterações, na sua maioria, podem ser realizadas dentro de um sprint de uma ou duas semanas. Assim sempre é possível reanalisá-las, mesmo quando se altera a superfície de ataque.

Bird também menciona o uso de sprints de segurança, em que a equipe procura por bugs que representam ameaças no código, antes de realizar alterações mais importantes. Bird cita também Adrian Lane, quando diz que a segurança deve ser essencialmente uma preocupação da equipe de desenvolvimento e não do cliente. As equipes devem assumir a responsabilidade e dar a devida atenção a estes aspectos.

Mesmo de um cliente muito bem intencionado não se pode esperar o completo entendimento das questões relacionadas a como se construir um software seguro.

Dessa forma, com boas métricas e uma atitude correta é sim possível fazer da segurança parte do processo de desenvolvimento. Bird destaca:

Não há nenhuma razão para que o desenvolvimento ágil seja um fracasso em termos de segurança. O esforço técnico, o compromisso com a qualidade e com os detalhes que são necessários para se construir software seguro, são os mesmos, independentemente das práticas de desenvolvimento utilizadas.

E você, qual sua opinião sobre o tema, baseado em suas próprias experiências? Qual a relação entre as práticas ágeis e a segurança das aplicações desenvolvidas por sua equipe?