Para as empresas de software de grande porte ou grandes corporações, como bancos ou empresas de assistência médica com grandes bases de software personalizado, investir em segurança de software pode revelar-se valioso e proporcionar um retorno mensurável sobre o investimento, mas que provavelmente não é o caso para as pequenas empresas, disse John Viega, vice-presidente executivo de produtos, estratégia e serviços da SilverSky e uma autoridade em segurança de software. Schneider sobre segurança: Segurança de software é uma perda de tempo?

Mentira.

É insensato fingir que a segurança de software é apenas um problema para as empresas ou fornecedores de software empresarial. Pequenas empresas escrevem software que as grandes empresas utilizam, o que significa que as grandes empresas estão colocando os seus clientes em risco. Isso acontece o tempo todo.

E é errado acreditar que pequenas lojas não podem fazer nada prático para a construção de software seguro. Eu não estou falando de algo como englobar todo SDL da Microsoft – para algumas pessoas, o argumento parece ser esse.

Se você não esta seguindo o SDL da Microsoft, então você não pode construir um software seguro, e ninguém além da Microsoft pode seguir o SDL, então você pode muito bem desistir.

Mas você não precisa adotar o SDL, ou qualquer outro programa de segurança de software de grande escala, caro e com qualidade de empresa. Qualquer pequena loja pode adotar algumas medidas razoáveis que ajudam muito a construir um software seguro:

1. Em primeiro lugar, leva um tempo inicial para entender os requisitos do negócio para segurança e conformidade e para a manipulação dos dados confidenciais e privados – que informações você precisa proteger, quem pode ver e alterar esses dados, quais os dados que você tem que criptografar, quais dados você não deve guardar, o que você precisar logar? Tudo isso é apenas uma parte de entender o tipo de sistema que você precisa construir.

2. Pense na arquitetura da sua aplicação e escolha um bom framework de aplicação. Por causa de todo o barulho sobre “design emergente“, quase todo mundo que constrói aplicativos de negócios – mesmo pequenas equipes que seguem métodos Agile/Lean – utilizam algum tipo de framework. É estúpido não fazer isso. Um bom framework cuida de todos os tipos de problema pra você – incluindo os problemas de segurança – o que significa que você pode ter recursos que possibilitem entregar mais rápido, o que é, afinal, o ponto.

Se você for um desenvolvedor Ruby, o Rails vai cuidar de um monte de problemas de segurança para você – desde que você garanta o uso correto do Rails e não se esqueça de manter o Rails atualizado (a comunidade Rails cometeu alguns erros em relação à segurança, mas ela parece empenhados em corrigi-los).

Play, um popular aplicativo de framework para Java e Scala, inclui recursos e controles embutidos de segurança, assim como muitos outros frameworks para Java, e frameworks para PHP e outras linguagens, e é que claro que há plataformas .NET para Microsoft, que são carregadas com recursos de segurança.

Nenhum desses frameworks vai cuidar de todos os problemas de segurança para você – mesmo se você usá-los corretamente e certificar-se de mantê-los corrigidos quando vulnerabilidades de segurança forem encontradas. Mas o uso de um bom framework irá reduzir significativamente os riscos, sem adicionar custos reais ou tempo para desenvolvimento. E quando você precisa fazer algo a respeito de segurança que não pode ser incluído no framework (como lidar corretamente com criptografia), existem boas bibliotecas de segurança disponíveis, como Apache Shiro, que irão se certificar de que você faça as coisas corretamente, além de economizarem tempo e custos.

3. Escreva um código de defesa sólido: código que funciona e não estraga quando é utilizado no mundo real. Verifique os parâmetros de entrada e os valores de retorno da API, faça um bom trabalho com tratamento de erros, use as bibliotecas seguras. Programe de forma responsável.

4. Tire vantagem das ferramentas de análise estática para capturar bugs, incluindo os de segurança. Pelo menos compreenda e utilize quaisquer verificadores de análises estáticas checadas que estejam em seu IDE e seja gratuito, é fácil usar ferramentas como Findbugs e PMD para Java, ou as ferramentas da Microsoft para .NET. Elas são gratuitas, encontram erros para que você não tenha que fazê-lo – então, por que não usá-las?

A maioria das ferramentas comerciais são muito caras para equipes pequenas, mas, se a Cigital praticar preços mais acessíveis para Secure Assist, isso pode finalmente proporcionar às pequenas equipes de desenvolvimento um feedback de alta qualidade em bugs de segurança.

 

Claro que há muito mais coisas que você pode fazer ou deve fazer se você precisar. Mas até mesmo passos modestos e razoáveis levarão a um caminho para tornar o software mais seguro para os clientes. E não há razões para as equipes pequenas não poderem – ou deverem – fazer isso.

***

Artigo traduzido pela Redação iMasters, com autorização do autor. Publicado originalmente em http://swreflections.blogspot.com.br/2013/03/yes-small-companies-can-and-should.html