O que me chamou a atenção no livro é que ao invés de tentar apresentar trechos de códigos, técnicas de secure coding ele apresenta idéias e tópicos que todo programador deve levar em consideração.
E uma coisa que gostei foram alguns pontos que ele apresenta como inimigos do Secure Code:
Ignorance
Isto mesmo, ele apresenta a ignorância como um dos inimigos da segurança de código. Eu acredito nisto! A grande maioria dos desenvolveres cometem erros de segurança por desconhecimento. Ele desenvolve um bom código, que funciona, mas que tem uma falha de segurança. Mas um bom código pode ser inseguro? Sim! Ele pode inserir falhas de arquitetura, privacidade mesmo desenvolvendo um código de excelente qualidade.
Por este motivo é fundamental que seja disponibilizado material de estudo e um trabalho de conscientização constante.
Mess
Exatamente, muitos ambientes de desenvolvimento são uma verdadeira bagunça. Os desenvolvedores não adotam nenhuma prática de teste, integração contínua e algumas vezes nem o básico, como controle de versão.
O desenvolvimento de código de qualidade e seguro depende da adoção de práticas de desenvolvimento e organização. Eu já escrevi sobre Bug Tracking e incluo como uma excelente prática a adoção de ferramentas que implementem o processo de integração contínua.
Deadlines
Prazos são um problema sério em desenvolvimento de software e isto naturalmente afeta a segurança. Com a definição de prazos apertados o planejamento, análise e inspeção de código é deixado de lado e entra em cena as soluções mirabolantes e a popular POG (Programação Orientada a Gambiarra) ou a XGH (eXtreme Go Horse) que tem como principal característica:
1- Pensou, não é XGH.
XGH não pensa, faz a primeira coisa que vem à mente. Não existe segunda opção, a única opção é a mais rápida.
Salesmen
Vendedores, sempre eles. Vendem o que não podem entregar e depois o desenvolvedor precisa desenvolver um sistema ruim para atingir prazos e orçamentos. E sem contar aquelas features que são um atentado a segurança, mas precisam estar disponíveis pois foram vendidas ao cliente.
São pontos bem comuns, mas que afetam e muito o desenvolvimento de um bom código.
4 comentários:
Principalmente no começo da profissão muitos developers são afetados pelos pontos como "Ignorance" e "Salesman".
Parabéns pelo POST e pelo assunto abordado :)
Bacana o post.
Acho que praticamente com estes 4 pontos você resumiu todo o livro e também empacotou 90% das empresas de software brasileiras.
Se puder, eu acrescento mais um:
- Complexidade: quanto mais complexo, mais potencialmente inseguro é o código. A famosa técnica KISS (Keep It Simple Stupid) vai muito bem aqui. Desmembrar o raciocínio em etapas mais simples é essencial.
Excelente post!
Acredito que "Ignorance" e "Deadlines" são os mais comuns.
Falta de uma cultura de segurança e de um programa de segurança com processos bem definidos e conscientização com certeza ajuda.
[...] Inimigos do software seguro [...]
Postar um comentário