O desenvolvimento de software é uma prática na qual cada vez mais pessoas em todo o mundo estão engajadas. Existem empresas e indivíduos criando software, alguns deles proprietários, alguns gratuitos ou de código aberto, e alguns são um amálgama dos dois. Como as ameaças à segurança dos usuários ou de seus softwares não se materializam assim que algo é declarado completo e enviado para produção, parece ser o momento certo para falar sobre práticas de segurança que ajudariam a gerenciar riscos de segurança que possam surgir. seu software durante o processo de desenvolvimento. Existem várias estruturas SSDLC (Ciclo de Vida de Desenvolvimento de Software Seguro), incluindo algumas de OWASP, CISA e NIST (SSDF). Neste artigo, pegaremos emprestado um pouco de todos eles para destacar algumas práticas que visam ajudá-lo a gerenciar o risco inerente ao desenvolvimento de software. Não viva com uma falsa sensação de segurança pensando que isso não pode acontecer com você. O relatório de segurança cibernética semestral da Check Point 2023 revela um aumento de 8% nos ataques cibernéticos globais ao longo de 2022, e a tendência não parece estar se invertendo.
Qual é o ciclo de vida de desenvolvimento de software
Os desenvolvedores de software visam construir software com rapidez, precisão e segurança. Claro, você nem sempre consegue todos os três. Com o tempo, o processo de desenvolvimento foi dividido em diversas fases distintas que podem se adequar a qualquer desenvolvimento de software. Essas fases podem ser divididas em:
- Análise de requisitos – o que vamos construir e por quê
- Planeamento – como vamos construí-lo em termos gerais
- Design de software – como vamos construí-lo em termos específicos, como projeto arquitetônico
- Desenvolvimento de software – escrever e compilar o software
- Ensaios – certifique-se de que funciona conforme planejado
- desenvolvimento – enviá-lo ou publicá-lo para que o usuário final possa usá-lo
Existem algumas outras versões deste ciclo, mas no geral são muito semelhantes. É importante lembrar que o ciclo não é algo único – ele geralmente não termina depois que você envia para o cliente ou publica na nuvem. Quase sempre há problemas com os quais você precisa lidar e que podem exigir um redesenho (de volta à estaca zero), bugs que você precisa corrigir, recursos que deseja adicionar e assim por diante. Você também pode trabalhar em alguns estágios em paralelo ou parar no meio do passo para voltar atrás. Como nenhuma das etapas é inerentemente centrada na segurança, isso deixa a segurança constantemente em dia com o processo de desenvolvimento e, nas atuais velocidades de desenvolvimento frenéticas, isso não é suficiente.
A importância de proteger seu SDLC
O desenvolvimento seguro de software visa incluir considerações de segurança em todas as etapas do processo, não tratando a segurança como um complemento do processo. Dessa forma, a segurança deve ser sempre levada em consideração, independentemente da fase do processo em que você esteja envolvido – pensando nos requisitos do projeto, planejando a arquitetura, considerando os blocos de construção e a infraestrutura necessária e sentando-se para desenvolver o código. Essa abordagem às vezes é chamada de segurança shift-left abordagem.
Aqui, shift-left refere-se à distribuição das preocupações de segurança ao longo do processo de desenvolvimento e ao envolvimento dos desenvolvedores no design, implementação e testes de segurança.
Pode ser intimidante para desenvolvedores que nunca pensaram realmente em questões de segurança ter que lidar com isso de repente. É significativamente mais fácil de lidar se os requisitos forem divididos em múltiplas práticas recomendadas bem definidas. Você pode pensar nisso como adquirir um novo IDE.
Quanto mais bem definidos os requisitos e mais automação e ferramentas abrangentes você puder empregar, mais fáceis se tornarão as tarefas.
Melhores práticas de segurança SDLC
Aqui estão algumas práticas recomendadas para ajudá-lo a proteger seu processo de desenvolvimento sem uma ordem específica:
Formação – Muitos desenvolvedores não se sentiriam à altura da tarefa de aplicar considerações de segurança e testar o código que estão escrevendo. A maioria dos desenvolvedores está ciente de que permitir dados de entrada contaminados em seu back-end pode resultar na ativação remota de código, muito parecido com as conhecidas “tabelas descartadas”. No entanto, menos pessoas estariam familiarizadas com testes de buffer overflow ou verificação de vulnerabilidades para dependências terciárias (ou adicionais). Os desenvolvedores podem preencher essas lacunas de conhecimento com o uso de treinamento. Os desenvolvedores estão mais bem equipados para incorporar preocupações de segurança em sua codificação e testes diários quando têm uma compreensão mais profunda dos desafios de segurança e vulnerabilidades potenciais. Também faz muito mais sentido para o desenvolvedor que escreveu o código e está intimamente familiarizado com sua função considerar suas lacunas de segurança e planejar os testes de acordo.
Exploração – Você pode usar vários tipos de verificação para tornar seu código mais seguro em geral. Análise estática, dinâmica e interativa são algumas delas. A análise estática procura falhas de codificação evidentes ou possíveis vulnerabilidades de segurança no código-fonte. Ele pode ser usado para procurar vulnerabilidades potenciais, práticas de código inseguras e violações de padrões de codificação. Ele não considera eventos de tempo de execução porque examina apenas a sintaxe do código. A análise dinâmica procura falhas de segurança, falhas de codificação e outros problemas no aplicativo enquanto ele está em execução. Ele pode ser usado para identificar vazamentos de memória, operações abaixo da média e possivelmente entradas ou processos instáveis. Lembre-se de que, como esse tipo de teste é realizado em um determinado momento e com insumos específicos, a qualidade dos testes depende inteiramente de quem os idealizou. O objetivo é encontrar os problemas antes que os usuários o façam. A análise interativa examina o aplicativo para encontrar possíveis falhas de segurança e outros problemas de ruptura. Ele pode procurar possíveis vulnerabilidades, problemas de usabilidade e problemas com a interface do usuário. Quanto mais ferramentas de varredura abrangentes você utilizar, mais protegido você estará, mas a desvantagem está, obviamente, na velocidade de desenvolvimento. Como cada aplicativo é único, cabe a você encontrar o equilíbrio entre a quantidade certa de digitalização e a velocidade de desenvolvimento desejada. Além disso, recomendamos a criação de um SBOM completo do seu aplicativo e a aplicação de diversas verificações e relatórios também a essa fonte de dados. Ter um legado SBOM do seu aplicativo é uma boa maneira de manter informações muito detalhadas sobre componentes e pacotes que podem ser inestimáveis por vários motivos de segurança.
Revisões de código – O exame do código-fonte para encontrar falhas de segurança, erros de codificação e outras falhas de software antes de ser combinado com o ramo de desenvolvimento ativo é conhecido como revisão de código. Normalmente, um desenvolvedor com maior experiência do que aquele que criou o código conduz essa revisão. Essas revisões podem ajudar a garantir que o código esteja bem escrito e que o aplicativo seja seguro. Além disso, eles suportam a manutenção de um único padrão e convenções de codificação (como nomes de funções e variáveis) em toda a base de código.
Permitir a integração do código na ramificação principal após pelo menos dois pares de olhos revisá-lo é considerado uma prática recomendada. O desenvolvedor que criou o código é, obviamente, o primeiro par de olhos. Pode ser benéfico até mesmo para engenheiros altamente qualificados, como líderes de equipe, ter outra pessoa avaliando seu código. No mínimo, isso garante que mais de uma pessoa esteja familiarizada com cada seção do código. Tenha em mente que em momentos de grande estresse ou de crise, as pessoas podem considerar renunciar a esse elemento. Se possível, considere adicionar esta regra como um elemento codificado do seu CI/CD para que ela não possa ser ignorada.
Ensaios – Não precisamos dizer o quanto é importante testar seu código para descobrir falhas de segurança antes que elas se tornem um problema. A maioria dos projetos de código são complexos e interconectados, portanto é impossível prever como uma única e pequena lacuna pode eventualmente impactar a segurança de toda a base de código.
Ao escrever testes automatizados, leve em consideração a funcionalidade do código produzido recentemente, bem como quaisquer interações significativas de back-end e front-end com outras partes da base de código.
Vulnerabilidades como injeção de SQL, scripts entre sites, armazenamento de dados inseguro e alocação inadequada de memória (que pode resultar em buffer overflows) são exemplos de problemas de segurança que normalmente são abordados em testes. Os testes devem abordar vazamentos de memória, desempenho lento ou não confiável e usabilidade. Os testes devem ser automáticos e integrados ao pipeline de CI/CD para que nenhuma nova versão ou atualização possa ser publicada sem passar por testes unitários e de integração.
Teste de caneta independente – Ninguém consegue pensar em tudo e, como desenvolvedores, às vezes desenvolvemos pontos cegos em relação ao código que escrevemos. Semelhante à revisão de código, o pen test independente permite uma nova abordagem e outro olhar para examinar criticamente o que fizemos e as precauções que tomamos para proteger nosso aplicativo e nossos usuários. Esses testes são recomendados pelo menos uma vez por ano e devem incorporar a avaliação da infraestrutura, bem como as vulnerabilidades dos aplicativos.
Use código aberto com segurança – Quase todos os softwares em desenvolvimento hoje incluem software de código aberto em maior ou menor grau. Componentes de código aberto são algumas das principais causas de vulnerabilidades importadas para seu aplicativo, diretamente ou por meio de dependências transitórias. Além disso, não são apenas as bibliotecas que você usa que podem colocá-lo em perigo – mas também a falha em atualizar bibliotecas antigas ou em se manter atualizado com os CVEs publicados mais recentes que podem afetá-lo. Recomendamos criar uma lista de pacotes de código aberto aprovados para uso pela organização e verificá-la e atualizá-la constantemente. Impedir que os desenvolvedores adicionem qualquer pacote que queiram, mesmo que apenas como teste, pode ajudar a reduzir o número de vulnerabilidades com as quais você precisa lidar.
Certifique-se de que as vulnerabilidades não se transformem em explorações – Quase não existe base de código sem vulnerabilidades. Qualquer varredura decente resultaria em centenas a milhares deles. É impossível eliminar todos eles. Também é importante lembrar que vulnerabilidades não são explorações. Certifique-se de ter um processo de filtragem para garantir que qualquer vulnerabilidade descoberta não seja uma ameaça explorável e mantenha esta lista constantemente atualizada. Dessa forma, você pode tranquilizar terceiros ou usuários preocupados com o CVE mais recente de que ele não terá absolutamente nenhum impacto em seu aplicativo.
A segurança começa com sua mentalidade
Provavelmente existem tantas maneiras diferentes de desenvolver software quanto desenvolvedores, estruturas e linguagens de codificação. Ou seja, não é fácil encontrar práticas recomendadas para proteger seu processo de desenvolvimento que sejam relevantes, independentemente da linguagem, área ou IDE que você esteja empregando. Além de uma infinidade de ferramentas, algumas proprietárias e outras gratuitas, todas clamando por sua atenção como “a próxima ferramenta de segurança insubstituível”, a ferramenta de segurança mais importante que você pode empregar é a sua mentalidade.
Pense nas suas escolhas de design, arquitetura e armazenamento. Você já considerou a opção de crescimento exponencial em sua base de usuários? Você segmentou adequadamente os privilégios de acesso para diferentes partes de sua base de código e infraestrutura? Você considerou um ataque direcionado contra seus dados ou segredos e um ataque “indireto” à cadeia de fornecimento de software?
Todas essas questões e muito mais devem ser consideradas antes mesmo de você planejar seu aplicativo e devem ser reinspecionadas rotineiramente à medida que a base de código e o aplicativo crescem e evoluem.
É considerado um axioma que a parte mais vulnerável de qualquer software é o ser humano que o executa (ou o escreve). Não deixe que seu aplicativo, software ou biblioteca de códigos faça parte das estatísticas crescentes de uma nova onda de ataques cibernéticos. Com planejamento, ferramentas e automação adequados, você pode encontrar o equilíbrio certo entre gerenciar riscos cibernéticos, proteger seu ciclo de vida de desenvolvimento e produzir código bem documentado, abrangente e eficiente.