revisoes manuais de codigo apenas. Ferramentas de analise estatica de codigo verificam a aderencia a padroes. Alguns produtos tem seguranca como foco exclusivo.Uma coisa que pode ajudar a manter a consistencia na adesao a padroes de codigo e a configuracao de um processo de integracao continua para executar ferramentas de analise estatica de codigo. Mas nao devemos nos apoiar apenas na revisao de codigo - os requisitos nao funcionais contra vulnerabilidades especificas de dominio, como manipulacao de parametros HTTP, exigem o entendimento do dominio de negocio subjacente. Uma combinacao de testes de regressao manuais e automaticos, que validem cenarios especificos de ataques, pode ajudar a construir um sistema resiliente a vulnerabilidades especificas ao dominio.VisibilidadeOutro fator que inibe a integracao de seguranca nos projetos ageis e a falta de visibilidade. Cerimonias com os clientes, tais como Revisoes de Sprint do Scrum, favorecem o trabalho com historias de usuario ou correcao de defeitos que melhorem a experiencia do usuario. Alguns atributos nao funcionais, como usabilidade e desempenho, possuem efeito tangivel sobre a experiencia do usuario e podem ser facilmente demonstradas. Outras, como seguranca, raramente resultam em efeitos positivos sobre a experiencia do cliente em uma Revisao de Sprint.Na verdade, algumas funcionalidades de seguranca, como o travamento de contas em caso de uso indevido, tem efeito negativo na experiencia do usuario. A maioria das funcionalidades de seguranca nao tem impacto perceptivel sobre os usuarios comuns. Portanto, NFRs de seguranca sao invisiveis e precisam competir, com funcionalidades mais visiveis, por ciclos preciosos de desenvolvimento nas iteracoes. O custo de oportunidade de se trabalhar em requisitos invisiveis e particularmente alto nos estagios iniciais do desenvolvimento da aplicacao, exatamente quando os desenvolvedores deveriam embutir a seguranca no sistema.Tornando a seguranca visivelNao existem balas de prata que tornem a seguranca uma prioridade para uma equipe agil no comeco do desenvolvimento, mas ha duas maneiras de tornar NFRs de seguranca visiveis para os clientes e/ou product owners:Criar graficos para historias de seguranca: Caso se tenha conhecimento suficiente sobre seguranca de aplicacoes, pode-se produzir um conjunto de controles de seguranca paravulnerabilidades conhecidas. Pode-se entao utilizar os controles que mapeiam para historias de usuario de NFRs (em vez de restricoes) e criar um grafico simples ilustrando as historias de seguranca implementadas e nao implementadas no sistema. Esse grafico seria entao afixado no quadro junto com os demais grandes graficos visiveis (veja a figura abaixo).Grafico de historias de segurancaEsse grafico, claro, nao precisa estar restrito as historias de seguranca. Pode-se escolher outros requisitos nao funcionais importantes para exibir no mesmo grafico, alem de utilizar pontos de historias no lugar de numero de historias para refletir o esforco. Pode-se mostrar graficos apenas para historicas de alta prioridade e para controles de aspectos de seguranca de alto risco. Toda historia implementada ajudara a aumentar a contagem de "Implementado" e consequentemente contribuira para tornar o progresso mais visivel para o cliente e/ou dono do produto.Demonstrar fragilidades: Nada leva as pessoas a entender bem as implicacoes de uma vulnerabilidade de seguranca quanto demonstrar uma fragilidade na pratica. Essa e a diferenca fundamental entre um teste de invasao