#!/intro

A discussão sobre a segurança do código aberto comparativamente com o modelo fechado é antiga, mas continua relevante num contexto onde a dependência de software é transversal a todas as áreas da sociedade.

No rescaldo dos recentes incidentes de segurança associados a projetos de software de código aberto, a discussão sobre a sua fiabilidade voltou a ganhar destaque. Estes episódios levantam questões legítimas sobre os limites do modelo aberto, especialmente quando se verifica que projetos considerados críticos são mantidos com recursos limitados e carecem de mecanismos estruturados de auditoria e validação, comprometendo assim os objetivos de fiabilidade, integridade e segurança que deveriam orientar o seu desenvolvimento e manutenção.

Neste contexto, torna-se essencial ultrapassar posições ideológicas e analisar com rigor técnico e estratégico as diferenças entre modelos abertos e proprietários que influenciam de forma decisiva a segurança do software.

> modelo_aberto

O principal mérito do modelo de código aberto reside na transparência técnica, que possibilita o acesso integral ao código-fonte por parte de auditores, investigadores e profissionais de segurança. Esta abertura permite a realização de auditorias independentes, facilita a verificação de conformidade com boas práticas de segurança e promove uma cultura de melhoria contínua através da colaboração comunitária.

Para além disso, o modelo aberto proporciona liberdade de modificação, adaptação e integração, sendo, por isso, particularmente adequado a contextos que exigem autonomia tecnológica e controlo efetivo sobre a infra-estrutura digital.

> modelo_fechado

O desenvolvimento de software em regime fechado é, em regra, conduzido por equipas técnicas dedicadas, integradas em estruturas empresariais que operam com processos formalizados de gestão de qualidade, controlo de versões e validação interna. Este modelo de desenvolvimento permite coordenação centralizada, com potencial para uma gestão disciplinada do ciclo de vida do software, incluindo testes e correções em tempo útil.

Em contextos empresariais ou industriais, o modelo fechado pode também facilitar o cumprimento de requisitos contratuais, suportando garantias de funcionamento e suporte técnico por parte do fabricante.

> riscos

A premissa de que o código aberto é mais seguro assenta na possibilidade de escrutínio público. Esta transparência permite que investigadores, profissionais de segurança, académicos e programadores analisem o código e contribuam para a sua melhoria. Contudo, esta possibilidade não é uma garantia. Muitos projetos de código aberto, mesmo os amplamente usados, como bibliotecas criptográficas ou frameworks de desenvolvimento, são mantidos por comunidades pequenas e pouco estruturadas, compostas por voluntários e frequentemente sem financiamento ou recursos adequados. A revisão do código nem sempre acontece, e quando acontece, nem sempre é exaustiva.

A simples disponibilidade do código não garante que este seja efetivamente revisto, nem que as vulnerabilidades sejam detetadas e prontamente corrigidas. A complexidade crescente de muitos projetos faz com que mesmo código aberto seja progressivamente mais difícil de auditar. A multiplicidade de dependências, a integração com sistemas heterogéneos, a constante evolução de requisitos funcionais e técnicos e a ausência de mecanismos formais de verificação podem originar vulnerabilidades críticas que persistem sem deteção durante longos períodos. Em muitos casos, falhas graves permanecem latentes durante anos, mesmo em projetos com grande visibilidade, como foi o caso do Heartbleed no OpenSSL.

No modelo de código fechado, os desafios assumem uma natureza diferente, nomeadamente pela ausência de visibilidade externa e pela dependência exclusiva do fornecedor para a deteção e correção de falhas. As vulnerabilidades continuam a existir, mas são inacessíveis à comunidade técnica e aos utilizadores.

Exemplos notáveis incluem a vulnerabilidade MS08-067 (CVE-2008-4250), explorada pelo worm Conficker, que esteve presente no Windows durante vários anos antes de ser descoberta em 2008. Outro caso relevante é a vulnerabilidade EternalBlue (CVE-2017-0144), explorada no ataque WannaCry, um ransomware com capacidades de worm, que afetava o protocolo SMB e permaneceu desconhecida até ser revelada após uma fuga de informação da NSA em 2017. Estes casos sublinham os riscos associados à falta de transparência no modelo de desenvolvimento de código fechado.

Em contextos proprietários, poderão também existir pressões de natureza económica ou jurídica que influenciem a forma como as falhas são geridas, o que pode levar a atrasos na sua correção ou a uma menor transparência na sua divulgação. Tal cenário pode constituir um risco acrescido, especialmente quando se trata de software utilizado em sectores críticos, como banca, saúde, telecomunicações ou administração pública.

Mais ainda, em sistemas proprietários, o utilizador está sujeito a uma assimetria absoluta de informação. Não sabe como o sistema funciona internamente, não pode verificar se há mecanismos ocultos, recolha indevida de informação ou comportamentos não documentados. Esta ausência de visibilidade torna impossível aplicar uma política de segurança baseada em confiança verificável (trust but verify), substituindo-a por uma confiança cega, uma abordagem incompatível com boas práticas de cibersegurança.

Além das questões técnicas, existe também uma dimensão estratégica: o acesso ao código-fonte é um requisito essencial para a soberania digital. Estados, entidades críticas e operadores de infra-estruturas essenciais não podem depender de software opaco, muitas vezes desenvolvido fora do seu controlo, sem a capacidade de o auditar, modificar ou adaptar às suas necessidades de segurança. O modelo aberto permite auditoria independente, certificação, e personalização do software, fatores fundamentais para contextos com exigências de segurança elevadas.

Assim, o argumento de que o modelo de desenvolvimento de código fechado tem pelo menos todas as vulnerabilidades do modelo de código aberto é válido, mas vai mais longe, pois essas vulnerabilidades são mais difíceis de detetar, corrigir e, sobretudo, garantir que o venham a ser.

> conclusão

Embora o código aberto não elimine automaticamente os riscos, permite uma abordagem mais rigorosa e controlável da segurança. Dá aos utilizadores poder de verificação, capacidade de resposta, liberdade de adaptação e uma comunidade potencialmente envolvida na sua melhoria. A segurança não é garantida nem por um modelo nem por outro. Mas só o modelo aberto oferece condições técnicas e organizacionais favoráveis à implementação de práticas de segurança verificáveis e sustentáveis, desde que enquadrado num ecossistema com recursos adequados e processos bem definidos.

A segurança não pode assentar na ocultação das falhas, mas sim na sua gestão ativa, verificável e eficaz. A transparência, embora não constitua por si uma garantia de segurança, é um requisito essencial para a construção de sistemas seguros de forma verificável e responsável.

> status: vulnerable
> exit 0