Devido a demandas por adequação a padrões, o processo de segurança em desenvolvimento de software é hoje um assunto em alta. Isto me preocupa, afinal, de onde surgiram tantos especialistas? Cheguei a comentar com um amigo: tem mais especialista que aplicação vulnerável.

São inúmeras palestras e promessas milagrosas. Pessoas citam os touchpoints de Gary McGraw ^[1] e o processo de SDL da Microsoft ^[2] como se fossem íntimos e tenham implementado em vários cenários e organizações, sem contar a falácia da ISO/IEC 15.408 ^[3], que muitos acreditam cegamente ser uma proposta para segurança em desenvolvimento.

Tudo isto para buscar ser "cool" e/ou tentar abocanhar uma fatia de um mercado que vem surgindo. A pesquisa, o estudo e disseminação de conhecimento são super importantes, mas que, os que se aventuram pelo tema tenham convicção de uma coisa: não é nenhum pouco simples e fácil implementar e ter bons resultados com processos de SDL.

Wagner, você está traindo "o movimento"? Você não acredita mais em segurança em desenvolvimento?

Muito pelo contrário, acredito e muito, mas sei muito bem o caminho a ser percorrido e as dificuldades que encontrarei. Há pelo menos cinco anos eu estudo e vivencio como consultor, a realidades das organizações frente à segurança de software.

Muitas organizações não conseguem justificar mais uma área de desenvolvimento interno, como irão justificar o investimento em segurança de software? Os sábios logo dirão: Cobre do fornecedor o processo de SDL.

Sim, você pode cobrar do fornecedor, só não se assuste se o seguinte cenário lhe for apresentado: Eu cobro R$ 500,00 por hora de desenvolvimento, com segurança eu preciso incluir um pequeno adicional, fica R$ 600,00 por hora.

Como diria o Zé: não existe almoço grátis! Alguém tem que pagar a conta.

Como equacionar esta dificuldade de justificar e conscientizar as empresas a investir recursos em segurança em desenvolvimento?

Não existe resposta pronta, sugestões como: conscientize, treine, mostre o ROI, etc... Servem para uns e não servem para outros. Se eu pudesse sugerir algo, eu começaria pelo básico, não acredite em soluções milagrosas, não acredite em quem lhe promete entregar o que você não conseguiu a vida toda em um mês de trabalho e ao preço de um almoço.

Um processo como este leva tempo e no mínimo os seguintes aspectos devem ser considerados:

• Compliance é o mínimo do requerido, não espere que esta demanda justifique o processo de segurança em desenvolvimento;
• Identifique de que maneira a sua organização é afetada pela insegurança de software;
• Tenha ciência que a maioria dos impactos relacionados a incidentes envolvendo falhas de software impacta indiretamente a organização e os valores são intangíveis. A famosa fórmula de ROI pode não lhe ajudar nestes cenários;
• Envolva todos no processo, não seja apenas o auditor que aponta as falhas e cobra uma solução;
• Não trate um processo de SDL como um projeto que você desenvolve meia dúzia de documentos e está feito. Busque a melhoria contínua, crie e acompanhe métricas que possam viabilizar e melhorar o processo.

Com estes pontos você terá muito trabalho, a parte fácil é desenhar os fluxos e escrever cartilhas e procedimentos.

[Update - 25 de Setembro] O Fernando Cima escreveu um post com excelentes referências para quem deseja implementar um SDL:  Retorno Sobre o Investimento de um Processo Seguro de Desenvolvimento ^[4]

2 Comments To "SDL (Secure Development Lifecycle) – Tão simples quanto parece?"

#1 Comment By Fernando Cima On 25 25UTC September, 2009 @ 12:03 am

#2 Comment By Elias Wagner On 25 25UTC September, 2009 @ 10:03 am