O seu processo de desenvolvimento está produzindo software seguro? Garantir que seu software atenda os requerimentos de negócios e que esteja pronto dentro do prazo são demandas que os desenvolvedores precisam lidar diariamente, mas dentre as principais prioridades nesse processo está também assegurar que o software entregue é seguro.

Para isso não é suficiente apenas testar o software nos estágios finais. É preciso pensar em segurança durante todo o ciclo de vida dos projetos de desenvolvimento, e evitar em todos os momentos que se permita brechas nos sistemas que algum invasor possa explorar. Uma das principais estratégias que pode usada para proteger o software é tratar o assunto de forma estruturada ao longo de cada passo do processo de desenvolvimento, incorporando táticas e ferramentas de segurança no chamado secure software development lifecycle (SDLC), ou ciclo de vida do desenvolvimento de software seguro.

Secure SDLC: o ciclo do desenvolvimento de software seguro 

O SDLC é uma estruturação para o processo de planejamento, construção, testes e implementação de programas e aplicativos, desde sua definição até a implantação em definitivo. Ao longo dos anos, vários modelos de SDLC surgiram — modelo cascata, modelo iterativo, em espiral, em ‘V’, ou mesmo o modelo ágil e CI/CD (integração contínua/entrega contínua), aumentando a velocidade de implantação de sistemas.

O SDLC é dividido em fases que vão do planejamento de requisitos à liberação e manutenção. No passado, as organizações geralmente executavam atividades relacionadas à segurança apenas como parte da fase de testes — logo, imediatamente antes da liberação do sistema. Como resultado, eles não encontrariam bugs, falhas e outras vulnerabilidades até que consertá-los se tornasse muito caro e demorado. Isso se encontrassem.

De acordo com a IBM, o custo para corrigir bugs encontrados durante a fase de teste pode ser 15 vezes maior do que o custo de corrigir aqueles encontrados durante o design. Em outras palavras, é mais rápido e barato pensar na segurança do software desde o início, do que construi-lo e depois checar se ele é seguro.

Por que o Secure SDLC importa?

Usar uma abordagem como o Secure SDLC oferece diversos benefícios. Seu software se torna mais seguro, pois a segurança passa a ser uma preocupação contínua, e não uma questão pontual. Mas no que isso se traduz na prática?

Em primeiro lugar, o Secure SDLC evita que você gaste mais por causa de retrabalho. Já pensou em construir um código inteiro para descobrir só no final que ele tem uma falha de segurança básica?

Em segundo lugar, com o Secure SDLC você aumenta suas chances de evitar que sua empresa passe por riscos de segurança – e um vazamento de dados pode custar muito caro, tanto em dinheiro como em imagem. Basta ver alguns casos que aconteceram nos últimos anos.

Veja o incidente da Equifax, por exemplo. A Equifax é um birô de avaliação de crédito dos Estados Unidos — similar à Serasa no Brasil. Como tal, é possível imaginar o tipo de dado sensível que o sistema da empresa guardava em 2017. Naquele ano, quase 150 milhões de cidadãos nos EUA tiveram seus dados vazados em uma violação de segurança que teve a Equifax como foco. Como forma de remediar o ocorrido, a empresa teve que assinar acordos que chegaram a várias centenas de milhões de dólares, isso sem contar os danos à reputação da organização. Mas o que aconteceu?

• A empresa foi inicialmente hackeada por meio de um portal de reclamação do consumidor, com os atacantes usando uma vulnerabilidade amplamente conhecida que deveria ter sido corrigida, mas que não foi, devido a falhas nos processos relacionados a sistemas da Equifax;

• Os invasores conseguiram se mover do portal da web para outros servidores porque os sistemas não estavam segmentados adequadamente, e foram capazes de encontrar nomes de usuário e senhas que possibilitaram acessar ainda mais sistemas, e a partir daí retiraram dados da rede de forma criptografada sem serem detectados por meses, porque a Equifax falhou para renovar um certificado de criptografia em uma de suas ferramentas internas.

Apesar de o problema não ter sido só por uma razão, a origem foi uma falha no sistema do portal de reclamação. Se esta falha tivesse sido corrigida ao longo do processo de desenvolvimento — considerando inclusive que já era uma vulnerabilidade conhecida — todo o resto poderia ter sido evitado.

A Equifax não é o único exemplo. Canva, Adobe e LinkedIn são outros casos de grandes empresas que foram alvo de um ataque com consequências graves na última década, como podemos ver aqui.

Os problemas podem ser ainda maiores quando se avalia o uso de open source no desenvolvimento de sistemas das grandes organizações. Não é o caso de considerar componentes de software aberto pouco seguros, o problema é se assegurar que a versão utilizada na empresa é a mais atual e corrigida contra qualquer vulnerabilidade recém-descoberta. E adicionalmente, que as licenças de open source estão sendo obedecidas como devem.

Nessa linha, temos o case da Panasonic, gigante japonesa que, por falhas no processo de desenvolvimento, não controlou adequadamente o licenciamento de código aberto incorporado aos seus sistemas, e teve que gastar mais de 100 milhões de dólares por conta disto.

Portanto, é preciso mudar a mentalidade e aceitar que os riscos com o software sendo desenvolvido sempre estão presentes, devendo ser gerenciados e mitigados em todas as fases do SDLC.

Dada a natureza diferente dos vários sistemas que construímos, não existe um manual que nos diga exatamente o que fazer para mitigar os riscos que podem existir para cada um deles. Mas existem práticas e ferramentas que nos ajudam a encontrar maneiras de reduzir os riscos para cada um deles.

Aliás, neste link temos disponível uma destas ferramentas, um ‘self assessment’ gratuito para avaliação da situação do controle de componentes open source no seu ambiente de desenvolvimento, espero que seja útil.

Artigo de Augusto Campos, CEO da Nova8 para CISO Advisor