Esse artigo é baseado na opinião pessoal do autor sobre o tema, tendo como fonte os artigos e livros citados na referência.

No dia 27 de Maio de 1997, o mundo conheceu o artigo de Eric S. Raymon, entitulado "The Cathedral and The Bazaar", que viria a se tornar uma das tábuas sagradas dos 10 testamentos para o mundo do software livre. Resumindo em uma maneira leviana, o artigo compara dois estilos de desenvolvimento de software: o estilo da Catedral (estilo habitual das empresas) e o estilo do Bazar (estilo habitual do software livre: desenvolvimento do software em sua versão inicial, publicação do código-fonte e evolução do software através de colaborações online). Apesar de o título por si só já ser polêmico o suficiente para causar muita discussão, o artigo também foi responsável pela criação da chamada "Lei de Linus" que dita "Given enough eyeballs, all bugs are shallow" (Raymond 1997). Podemos explicar a lei de Linus, utilizando as próprias palavras do artigo referido em tradução livre:

            "Possuindo um número grande o suficiente de beta-testers e co-desenvolvedores, quase a totalidade dos bugs serão caracterizados rapidamente e corrigidos obviamente por alguém" - Lei de Linus

A questão para que eu discorde do uso da Lei de Linus com relação a segurança (Não estou entrando na questão da engenharia em geral) é simples: O artigo de Raymon demonstra que com um número absurdo de pessoas olhando o código fonte, um grande número de erros podem ser encontrados naturalmente e, como os usuários tem acesso ao código-fonte, os erros podem chegar as mãos do programador não só com os sintomas (indicar que em determinada situação um usuário não é cadastrado por exemplo), mas sim com suas as reais causas (como indicar que o usuário não foi cadastrado devido a um problema de constraint no banco de dados), colaborando para a solução quase instantânea do problema, porém ela não conta com o simples fato de quem nem todas as funcionalidades de um sistema serão usadas ao extremo para todos os bugs serem encontrados (lembrando claro da lei 80-20 ou Príncipio de Pareto) e ainda pior: mesmo que os usuários testem a aplicação ao extremo, será que todos eles possuem conhecimento técnico avançado para identificação das vulnerabilidades?

Veja o código abaixo por exemplo (Howard and Lipner, 2006):

<%@ LANGUAGE=VBSCRIPT CODEPAGE =1252%>

<!--#include file="constant.inc"-->

<!--#include file="lib/session.inc" -->

<%SendHeader 0,1 %>

<!--#include file="lib/getrend.inc" -->

<!--#include file ="lib/pageutil.inc" -->

<%

'<!-- Microsoft Outlook Web Access -->

'<!-- Root.asp : Frameset for the inbox window -->

'<!—Copyright (c) Microsoft Corporation 1993-1997. All rights reserved. -->

On Error Resume Next

If Request.QueryString("mode") <> "" Then

            Response.Redirect bstrVirtRoot + _

                        "/inbox/Main_fr.asp?" + Request.QueryString()

End If

%>

Será que qualquer um conseguiria encontrar a vulnerabilidade (Watchfire, 2005)?

Segurança não é mágica e exige esforço. Não basta falar para os desenvolvedores que eles precisam "programar com segurança". Uma das etapas mais importantes em um desenvolvimento seguro é o treinamento de toda a equipe envolvida no projeto.

 Referências:
Raymond 1997 - www.catb.org/~esr/writings/cathedral-bazaar
Howard e LeBlanc 2002 - Howard, Michael and David LeBlanc. Writing Secure Code, 1st ed. Redmond, WA: Microsoft Press,2002
Howard e Lipner 2003 - Howard, Michael and Steve Lipner.  The Security Development Lifecycle. 1st ed. Redmond, WA: Microsoft Press 2006
Watchfire 2005 - http://www.watchfire.com/news/whitepapers.aspx

Obrigado,
Rodrigo Moreira
MCP, MCTS
Microsoft Student Partner Co-Lead
http://jackflashspot.spaces.live.com
Líder do MSRio.Net