Algumas semanas atrás, um amigo me disse que " segurança SDLC " é a nova " confiança zero " no campo cibernético - um conceito de palavra da moda que abrange muitos processos e complexidades. No entanto, a maioria das organizações não
entende o que precisa ser feito na prática.

Podemos debater se meu amigo está certo ou não, mas após nossa conversa, decidi escrever este artigo para simplificar as coisas e esclarecer a névoa em torno do conceito de “segurança SDLC”.

Ao final deste artigo, você estará familiarizado com as ameaças do SDLC, tecnologias que devem ser incluídas para mitigar essas ameaças e quais soluções de código aberto estão disponíveis para ajudá-lo a melhorar seu nível de segurança do SDLC.

Por que precisamos de segurança SDLC?

À medida que mais sistemas e ferramentas se envolvem, o ciclo de vida de desenvolvimento de software (SDLC) torna-se cada vez mais complexo. Como resultado, as ameaças cibernéticas neste espaço estão aumentando à medida que os invasores procuram os pontos mais fracos no pipeline e se aproveitam deles para roubar informações confidenciais, interromper serviços, implantar arquivos maliciosos e muito mais.

Nos últimos três anos, vimos várias grandes empresas sofrerem grandes ataques cibernéticos e vazamentos de informações de hackers se aproveitando de pontos fracos em seu ciclo de vida de desenvolvimento. Em alguns desses eventos, não foi só a empresa que sofreu, mas também seus clientes e usuários. Alguns exemplos dos mais recentes incluem:
- SolarWinds
- Travis
- Codecov
- AstraZeneca
- Toyota

Para evitar esses tipos de incidentes, é vital que as empresas protejam seus processos SDLC. Para fazer isso, primeiro é importante entender as ameaças em torno do SDLC para que você possa implementar as ferramentas, metodologias e processos de segurança corretos para mitigá-los.

Parece um trabalho simples, mas muitas vezes pode exigir um investimento financeiro significativo, tanto na aquisição das ferramentas adequadas como nos recursos humanos necessários para a sua implementação e manutenção.

Neste artigo, pretendo apresentar como podemos construir um SDLC seguro com custo financeiro mínimo usando ferramentas de código aberto.
Embora algumas das coisas apresentadas aqui não sejam adequadas para todas as empresas ou situações, elas ajudarão muitas organizações a entender as ameaças SDLC e como utilizar algumas das soluções sugeridas.

SDLC (Ciclo de Vida de Desenvolvimento de Software)

Antes de falarmos sobre ameaças, proteções e ferramentas, vamos começar do básico — como é um SDLC simples e típico:

No diagrama acima, você pode ver o processo SDLC mais direto, mas vamos dividi-lo um pouco:

Design — Esta etapa detalha os recursos e operações desejados, incluindo layouts de tela, regras de negócios, diagramas de processo, pseudocódigo e outros entregáveis. Durante esse estágio, você também deseja garantir que quaisquer preocupações e requisitos de segurança sejam levantados.
Código — Durante esta fase, os desenvolvedores escrevem a codificação necessária para construir o aplicativo conforme definido no projeto.
Testes — O software criado agora passa por testes extensivos, incluindo testes de unidade, qualidade de código, testes de integração e testes de segurança (explicarei isso mais tarde).
Implantar — O aplicativo sai da fase de teste e está pronto para produção. Idealmente, a fase de implantação ocorre automaticamente (normalmente como parte do CI/CD), mas empresas com menor maturidade ou em alguns setores altamente regulamentados podem exigir aprovações manuais durante esse estágio.
Prod(\Maintenance) — Uma vez que o aplicativo está em fase de produção e sendo usado pelos clientes, é fundamental que seja continuamente monitorado. Isso garantirá que alterações e correções possam ser feitas conforme necessário para evitar atividades maliciosas.

Na maioria das organizações, etapas intermediárias adicionais, menores ou maiores podem fazer parte do SDLC. Ainda assim, vamos nos contentar com as cinco principais etapas apresentadas acima para este artigo.

Ameaças do SDLC

Agora que você entende as principais etapas do SDLC, vamos explorar as ameaças do SDLC.
Estou usando o mesmo diagrama SDLC, mas desta vez, adicionando as ameaças relevantes para cada fase:

Glossário de ameaças

Design inseguro — o design inseguro é a falta de controles de segurança integrados ao aplicativo durante todo o ciclo de desenvolvimento.
Inadequação com as regulamentações — Algumas regulamentações (HIPPA, PCI, etc.) exigem políticas e processos de segurança específicos. A inadequação com os requisitos regulatórios pode levar a multas, sanções e incidentes de segurança.
Código vulnerável — O código que foi escrito sem pensar na segurança e seguindo as melhores práticas de segurança pode levar a diferentes pontos fracos e, como resultado, a incidentes de segurança. Você pode dar uma olhada no projeto OWASP Top 10 para obter mais informações sobre os riscos mais relevantes em torno do código vulnerável)
IAC vulnerável —A infraestrutura como código (IaC) é o gerenciamento e o provisionamento da infraestrutura por meio de código, em vez de processos manuais.
As consequências de ignorar a segurança do IAC podem ser graves. Eles podem levar à exposição de dados confidenciais a usuários não autorizados, vazamento de dados, acesso não autorizado a ativos e recursos críticos para os negócios e aumento da superfície de ataque.
Terceiras bibliotecas vulneráveis ​​— Existem duas causas principais de risco em bibliotecas de código aberto:

• Vulnerabilidades . Isso pode incluir vulnerabilidades diretas conhecidas, vulnerabilidades herdadas de outras bibliotecas (dependências), vulnerabilidades que foram corrigidas, mas reaparecem devido ao controle de versão da biblioteca e vulnerabilidades de dia zero.
• Malware . Os invasores sofisticados agora estão usando técnicas simples para criar bibliotecas que parecem inocentes, mas na verdade contêm código mal-intencionado ou são atualizadas com código mal-intencionado posteriormente.
  Algumas das técnicas comuns usadas por atores mal-intencionados incluem confusão de dependência, sequestro de dependência, typosquatting e brandjacking.

Cada ameaça acima é um risco real para nosso aplicativo e negócios. As implicações de explorar os pontos fracos em cada etapa do SDLC são enormes e podem levar a perdas de dinheiro, danos à reputação, clientes frustrados, ações coletivas, impacto no preço das ações e muito mais.

Tecnologias relevantes

Antes de passarmos para as ferramentas que podem mitigar essas ameaças, pensei em primeiro explorar alguns dos termos técnicos e acrônimos usados.
Vamos fazer uma rápida introdução a cada um deles (Obrigado à Synopsys por suas ótimas definições):

• Modelagem de ameaças — A modelagem de ameaças é um processo estruturado para identificar requisitos de segurança, identificar ameaças de segurança e vulnerabilidades potenciais, quantificar a criticidade de ameaças e vulnerabilidades e priorizar métodos de remediação.
• SAST — Static Application Security Testing (SAST), ou análise estática, é uma metodologia que analisa o código-fonte para encontrar vulnerabilidades de segurança que tornam os aplicativos de sua organização suscetíveis a ataques. O SAST varre um aplicativo antes que o código seja compilado.
• SCA — Software Composition Analysis (SCA) é um processo automatizado que identifica software de código aberto em uma base de código. Essa análise avalia a segurança, a conformidade da licença e a qualidade do código.
• Varredura de contêineres — A segurança de contêineres é a prática, os processos e as ferramentas usadas para proteger os contêineres. Os ambientes conteinerizados são muito mais complexos do que os perímetros tradicionais de segurança cibernética e exigem ferramentas e estratégias mais especializadas.
• Detecção de segredos — A verificação secreta é uma prática de verificação automática de textos e arquivos em busca de segredos, como senhas ou chaves de API.
• SBOM — Uma lista de materiais de software (SBOM) lista todos os componentes de código aberto e de terceiros em uma base de código. Um SBOM também lista as licenças que regem esses componentes, as versões dos componentes usados ​​na base de código e seu status de patch.
• DAST — Dynamic Application Security Testing (DAST) é um método de teste de AppSec no qual os testadores examinam um aplicativo enquanto ele está em execução, mas não têm conhecimento das interações ou projetos internos do aplicativo no nível do sistema e nenhum acesso ou visibilidade no programa de origem .
• Fuzz Testing — O teste Fuzz ou fuzzing é um método automatizado de teste de software que injeta entradas inválidas, malformadas ou inesperadas em um sistema para revelar defeitos e vulnerabilidades de software
• IAST — As soluções de teste de segurança de aplicativos interativos ajudam as organizações a identificar e gerenciar riscos de segurança associados a vulnerabilidades descobertas em aplicativos da Web em execução usando técnicas de teste dinâmico (geralmente chamadas de teste de tempo de execução)
• RASP — Runtime Application Self-Srotection (RASP) é uma tecnologia de segurança criada ou vinculada a um aplicativo ou ambiente de tempo de execução do aplicativo. Ele é capaz de controlar a execução de aplicativos e detectar e prevenir ataques em tempo real.
• WAF — Um Web Application Firewall ajuda a proteger os aplicativos da Web, filtrando e monitorando o tráfego HTTP entre um aplicativo da Web e a Internet.
• PT — Um teste de penetração (PT) é um ataque simulado autorizado realizado em um sistema de computador para avaliar sua segurança.
• Varredura IAC — Automatizando o processo de revisão do código IaC em busca de vulnerabilidades de segurança e problemas de conformidade.
• Ferramentas de segurança de CI/CD — Às vezes chamadas de ferramentas de segurança da cadeia de suprimentos de software. Essa ferramenta fornece visibilidade completa e rastreabilidade de ponta a ponta sobre a segurança do pipeline de software, do código à nuvem.
  A ferramenta pode detectar configurações incorretas em componentes de pipeline, como GitHub, Jenkins etc. e, dependendo do fornecedor, fornecer outros recursos, como detecções secretas, SBOM, SCA e SAST.
• Diretrizes\Estruturas — Este é um conjunto de documentos que descrevem as diretrizes, padrões e práticas recomendadas projetadas para o gerenciamento de riscos de segurança SDLC.

Mapeamento de tecnologias para etapas SDLC

Todas as tecnologias mencionadas acima têm uma finalidade única, por isso é crucial que sejam usadas no estágio correto do SDLC.
O diagrama a seguir oferece um exemplo de como integrar essas ferramentas em cada etapa:

Um lembrete rápido: o título do artigo é “ Como proteger seu SDLC com despesas mínimas”, então vamos falar sobre como evitar custos e ainda poder usar todas as ferramentas e tecnologias de que você precisa.

Proteja seu SDLC com a ajuda de ferramentas de código aberto.

Várias empresas fornecem as tecnologias mencionadas acima. Alguns deles até oferecem uma plataforma que combina algumas soluções, por exemplo, uma plataforma que inclui varredura SAST e SCA, juntamente com varredura de contêineres e IAC. Normalmente, porém, essas plataformas custam muito dinheiro, dependendo do tamanho da sua organização, do número de desenvolvedores e de outros critérios.

Na tabela a seguir, quero apresentar ferramentas gratuitas e/ou de código aberto para cada tecnologia necessária para proteção contra ameaças SDLC.

Observe que nem todas as tecnologias apresentadas aqui são adequadas para todas as organizações. Esta é apenas uma breve visão geral e há muitas tecnologias semelhantes não listadas.

Espere, onde estão as ferramentas de segurança PT e CI/CD?

Você tem razão; esses dois não estão na mesa por um motivo. Alguns processos de segurança ainda são parcialmente executados manualmente porque não existem ferramentas gratuitas neste campo e porque muitas vezes diferem de uma organização para outra.
Embora existam algumas ferramentas gratuitas para executar o PT (algumas delas são mostradas na tabela na coluna DAST), geralmente requer um processo manual adaptado à necessidade organizacional, à pilha de tecnologia e muito mais.
Existem, é claro, empresas comerciais que fornecem ferramentas para realizar PT automático para qualquer organização, em qualquer pilha de tecnologia e para todas as situações, mas este artigo é sobre reduzir custos e não aumentá-los :)  Em relação às ferramentas de segurança CI/CD
,essas são tecnologias relativamente novas e difíceis de encontrar gratuitas — essas são tecnologias relativamente novas e hoje é difícil encontrar ferramentas gratuitas que ofereçam uma alternativa válida às ferramentas comerciais. No entanto, as partes essenciais das ferramentas de segurança CI/CD podem ser facilmente implementadas manualmente.
Por exemplo, para fortalecer a segurança do Jenkins, você pode usar as instruções do Jenkins — aqui , proteção de ações do GitHub — aqui .
Github Hardening — aqui e Gitlab Hardening — aqui .

Processos manuais que ainda precisam ser levados em consideração:
Certos processos ainda precisam ser realizados manualmente, como a identificação de comportamentos incomuns nos processos de CI/CD.
Por exemplo, um desenvolvedor que repentinamente clona dezenas de repositórios em um breve período, um repositório com informações confidenciais que passa de privado para público etc. . Outros precisarão de uma ferramenta comercial para fechar a brecha de segurança dessa área.

Diretrizes e Estruturas

Existem algumas Diretrizes e Estruturas sobre a Segurança do SDLC, e dei alguns exemplos na tabela acima.
Acho que também vale a pena mencionar o documento da CISA&NSA — “ Securing the Software Supply Chain ”.
Quanto ao “ CIS Software Supply Chain Security Guide ”, tive a honra de participar deste guia e contribuir com meu conhecimento. Eu acho que é um ótimo guia e é muito profissional e prático.

Combinou tudo

Sei que é um artigo longo, mas estamos chegando à linha de chegada, então espere.
O último diagrama é aquele que combina algumas das ferramentas de código aberto no local apropriado ao longo do processo SDLC.
(Este é apenas um exemplo e você pode substituir qualquer ferramenta aqui apresentada por outras ferramentas semelhantes da tabela, ou em outro lugar)

Deslocar para a Esquerda

É impossível escrever um artigo sobre segurança SDLC sem discutir “Shift Left”. Essa é a prática de mover testes, qualidade e avaliação de desempenho para o início do processo de desenvolvimento e, em nosso caso, mover verificações de segurança o mais cedo possível.
Por exemplo, por que devemos esperar pela verificação noturna do SAST se podemos executar a verificação a cada pull request, ou melhor ainda, antes do PR quando o desenvolvedor está escrevendo o código?

Isso pode parecer bom demais para ser verdade, mas é realmente o caso.
Alguns plug-ins de segurança podem ser instalados no IDE do desenvolvedor e enviar alertas ao vivo para cada violação de segurança, como código vulnerável ou fraqueza em terceiras bibliotecas.
Essas ferramentas dependem da sua linguagem de programação, mas para o SAST, você pode usar o plug-in SonarLint , o plug-in SSVChecker , o plug-in Aside e o plug-in Findbugs .
Para SCA, você pode usar o plug-in Snyk .
Checkov tem um plug-in IDE para digitalização IAC.
O plug-in Trivy IDE pode fornecer SCA, IAC, verificação de contêineres e muito mais

Além dos plug-ins IDE, podemos mudar nossa verificação de segurança de outra maneira.
Por exemplo, em uma de minhas empresas anteriores, criamos um git hook para cada commit feito pelos desenvolvedores. O gancho git enviou o código para a varredura do Sonarqube e, com base nos resultados do Sonarqube aprovados/não aprovados no commit, o desenvolvedor obteve feedback de segurança imediato em seu código, em vez de esperar pela varredura noturna.

Conclusões

Este artigo apresenta várias opções para criar um processo SDLC seguro a um custo mínimo.
Tenho certeza de que alguns leitores podem não concordar com tudo o que está escrito, tanto na apresentação das ameaças, processos e ferramentas quanto na forma como eles são combinados no SDLC. Não pretendi explicar o processo SDLC mais seguro nem a estratégia final que toda organização deve ter; o objetivo era fornecer uma solução possível.
Se ao ler este artigo você concluiu que a segurança da informação em torno do ciclo de vida do desenvolvimento pode ser feita sem gastar muito dinheiro e com a ajuda de ferramentas de código aberto, então eu fiz a minha parte :)

Recursos adicionais

• Lista de ferramentas OWASP SAST
• Lista de ferramentas OWASP SCA
• Lista de ferramentas OWASP DAST
• Segurança CI/CD OWASP Top 10
• OWASP Top 10 de segurança de API
• OWASP Top 10 Segurança da Web
• OWASP — Folha de dicas de modelagem de ameaças
• Lista de verificação de segurança do contêiner
• Awesome-api-security
• Shift Left Security O que, por que e como
• O que é um Security Champion e por que você precisa de um