Construímos um desenvolvimento seguro em um varejista. Experiência de um grande projeto

Há algum tempo, concluímos a construção de um processo de desenvolvimento seguro baseado em nosso analisador de código de aplicativo em uma das maiores empresas de varejo da Rússia. Devemos admitir que esta experiência foi difícil, longa e deu um grande avanço para o desenvolvimento da ferramenta em si e das competências de nossa equipe de desenvolvimento para a implementação de tais projetos. Gostaríamos de compartilhar essa experiência com você em uma série de artigos sobre como isso aconteceu na prática, em qual rake pisamos, como saímos da situação, o que isso deu ao cliente e a nós no final. Em geral, vamos falar sobre a essência da implementação em si. Hoje vamos nos concentrar no desenvolvimento seguro de portais de varejo e aplicativos móveis.







Para começar, em geral sobre o projeto. Construímos um processo de desenvolvimento seguro em uma grande empresa comercial na qual o departamento de TI tem uma equipe enorme e está dividido em muitas áreas que estão minimamente correlacionadas entre si. Convencionalmente, essas áreas podem ser divididas em 3 grupos principais. O primeiro, um grupo muito grande, é o software de caixa registradora, que é escrito principalmente em Java (90% dos projetos). O segundo e mais amplo grupo de sistemas em termos de quantidade de código são os aplicativos SAP. E, finalmente, o terceiro bloco era uma "miscelânea" de portais e aplicativos móveis: vários sites externos para os clientes da empresa, aplicativos móveis para esses sites, bem como recursos internos - aplicativos móveis e portais da web para a equipe do varejista.



O cliente do projeto - o departamento de segurança da informação - formulou a tarefa geral de forma bastante padronizada para os três grupos: “queremos ter menos vulnerabilidades e o desenvolvimento seguro de todos os sistemas criados dentro da empresa”. Mas, na prática, em cada departamento específico, tudo parecia muito diferente dos outros colegas, porque a cada etapa da implementação do desenvolvimento seguro, tínhamos que fazer um milhão de compromissos diferentes. Algumas nuances ajudaram a construir o processo, enquanto outras, ao contrário, interferiram. No final, ainda conseguimos criar uma abordagem mais ou menos geral para a maioria dos projetos.



Formulamos essa abordagem da forma mais simples possível: o código mais relevante para todos os desenvolvedores é verificado. Se falamos em termos de Gitflow, e todos os grupos de projeto, com exceção do SAP, tinham ramos de desenvolvimento no Gitflow, o ramo de desenvolvimento principal é verificado em um cronograma.



Mas, como sempre, há exceções a qualquer regra: a abordagem geral não poderia ser aplicada em todos os lugares “como está” por uma série de razões. Em primeiro lugar, nossa ferramenta (analisador de código) tem várias limitações devido ao fato de que queremos ser capazes de fazer a análise mais aprofundada de algumas linguagens de programação, se necessário. Portanto, no caso do Java, o bytecode de análise é muito mais profundo do que o código-fonte. Conseqüentemente, a varredura de projetos Java exigia a montagem preliminar do bytecode e somente então o envio para análise. No caso dos aplicativos C ++, Objective C e iOS, o analisador foi integrado ao processo no estágio de construção. Também tivemos que levar em consideração os vários requisitos individuais dos desenvolvedores de todos os projetos. Abaixo está como construímos o processo para portais e aplicativos móveis.



Portais e aplicativos móveis



Parece que todos esses aplicativos são combinados em um grupo lógico, mas na realidade eles eram uma bagunça terrível. Havia mais de 120 portais (!). A empresa é muito grande, com muitos departamentos comerciais, administrativos e técnicos, e de vez em quando cada um deles decide que precisa de seu próprio portal e aplicativo móvel. Este portal e aplicativo são criados, usados ​​por algum tempo e então abandonados com segurança. Como resultado, na fase inicial, era necessário realizar um inventário para o cliente, pois mesmo os desenvolvedores dessas aplicações não possuíam uma lista única de bases de código. Por exemplo, para gerenciar os repositórios neste grupo, os desenvolvedores usaram dois GitLabs com administradores diferentes. Além disso, entre portais e aplicativos móveis, parte significativa dos projetos foi implementada com desenvolvimento externo.Portanto, quando o tempo de lançamento se aproximava, os empreiteiros frequentemente transferiam os códigos-fonte da nova versão para a empresa quase em uma unidade flash USB. Como resultado, a empresa tinha um zoológico de vários aplicativos e uma confusão completa em seu código. Tivemos que fazer uma lista de todos os projetos, encontrar todos os responsáveis ​​por eles - proprietários técnicos, chefes de equipe e, em seguida, acertar com o cliente principal - o departamento de segurança da informação, qual deles iremos analisar.



Como resultado, escolhemos sistemas de produção e software compatível para análise e não mexemos nos sistemas de arquivamento. Algumas aplicações internas foram consideradas não críticas, uma vez que não podiam causar prejuízos financeiros à empresa, e não foram selecionadas para análise. Por exemplo, um sistema de gerenciamento para embaladores em um armazém ou carregadores. Não há nada vulnerável a clientes externos da empresa neles, e sua invasão por um dos funcionários internos só causará pequenos inconvenientes internos a vários departamentos.



O serviço IS formulou a introdução da análise de código para vulnerabilidades como uma tarefa prioritária para este grupo de software e os desenvolvedores - para construir um processo de verificação conveniente integrado aos ciclos de desenvolvimento.



Integração de acordo com o esquema padrão



O GitLab de duas versões diferentes foi usado como um sistema de controle de versão no grupo de portais e aplicativos móveis.





Configurando a integração com GitLab



Nem todos os aplicativos usavam CI / CD e, onde não estava, tínhamos que insistir em usá-lo. Porque se você deseja realmente automatizar o processo de verificação de vulnerabilidades no código (e não apenas carregar manualmente um link para análise) para que o próprio sistema faça o download para o repositório e forneça os resultados aos especialistas necessários, então você não pode fazer sem instalar os runners. Os executores, neste caso, são agentes que contatam automaticamente os sistemas de controle de versão, baixam o código-fonte e o enviam para o Solar appScreener para análise.



Os desenvolvedores do portal e do grupo de aplicativos móveis queriam organizar o desenvolvimento seguro como um processo semiautomático para que o código fosse verificado em busca de vulnerabilidades sem qualquer envolvimento de sua parte. Para que o oficial de segurança verifique os resultados da análise de vulnerabilidades e atribua tarefas aos desenvolvedores em Jira se ele considerar as vulnerabilidades críticas, ou envie-as aos desenvolvedores para esclarecimento. Os desenvolvedores decidirão se precisam corrigir a vulnerabilidade com urgência ou não. E, se necessário, eles planejam em qual versão podem incluir as correções.



Jira foi usado principalmente como um rastreador de bug, no qual o analisador de código fornecia automaticamente informações sobre as vulnerabilidades encontradas.





Configuração de integração Jira



Em casos raros, os líderes de equipe olhavam os resultados do rastreamento por conta própria e iniciavam as tarefas no Jira manualmente.





Criação de uma tarefa em Jira



Também registramos esses casos nos regulamentos como um recurso separado. Em alguns projetos, em geral, todas as correções foram discutidas no Slack ou Telegram e as tarefas foram definidas em tempo real.



Como resultado, o processo de desenvolvimento seguro após a implementação do Solar appScreener começou a ficar assim: os portais são verificados diariamente em busca de alterações no código do ramo de desenvolvimento principal. Se o branch principal e mais relevante não for atualizado em 24 horas, nada acontecerá. Se tiver sido atualizado, então este branch é enviado para análise ao projeto correspondente para este repositório. O repositório no GitLab correspondia a um projeto específico no analisador de código, e foi neste projeto que o branch principal foi escaneado. Depois disso, o oficial de segurança revisou os resultados da análise, verificou-os e iniciou as tarefas de correção em Jira.





Resultados de análise e tarefas de correção de vulnerabilidade criadas em Jira



Começamos a consertar vulnerabilidades, via de regra, desde as críticas, que precisavam ser eliminadas com urgência. Quando essas vulnerabilidades terminaram, a equipe passou a corrigir novos erros encontrados no código. E já na terceira fase, por exemplo, no âmbito do encerramento de alguma dívida técnica, foram também eliminadas as antigas vulnerabilidades remanescentes.



Fora do padrão como padrão



Este processo, à primeira vista, não tão complicado, tinha duas limitações sérias. Primeiro, para analisar os aplicativos Android (ou seja, escritos em Java), precisávamos de um assembly. E em segundo lugar, o iOS precisava de máquinas macOS nas quais nosso agente fosse instalado e haveria um ambiente que nos permitiria construir aplicativos. Tratamos os aplicativos Android de forma bastante simples: escrevemos nossas partes nos scripts já disponíveis para os desenvolvedores, que também foram lançados de acordo com o cronograma. Nossas partes dos scripts pré-iniciaram a construção do projeto na configuração mais ampla, que foi enviada ao Solar appScreener para análise. Para verificar os aplicativos iOS, instalamos nosso agente MacOS em uma máquina Mac, que montou o código e também enviou o código para o analisador para digitalização via GitLab CI. Além disso, como no caso de outros tipos de software,o oficial de segurança revisou os resultados da análise, verificou-os e enviou os problemas de correção para Jira.



Também nos referimos a portais e aplicativos móveis como quaisquer projetos escritos em Java - os coletamos e analisamos de maneira semelhante.



Nos projetos em que não havia CI / CD, que era um pré-requisito para nós, a gente dizia simplesmente: “Gente, se quiserem analisar, colete manualmente e carregue você mesmo no scanner. Se você não tiver Java ou linguagens semelhantes a JVM - Scala, Kotlin e outros, você pode simplesmente fazer upload do código para o repositório a partir do link e tudo ficará bem. "



Complexidade do projeto



Como você pode ver acima, nesta pilha de aplicativos, o principal problema era a falta de CI / CD em muitos projetos. Os desenvolvedores geralmente faziam compilações à mão. Começamos a integrar nosso analisador com portais do Sharepoint em C #. Agora o C # mudou mais ou menos para sistemas Linux, embora não totalmente desenvolvido. E quando o projeto estava em pleno andamento, essa linguagem ainda funcionava no Windows, e tivemos que instalar um agente no Windows para o GitLab. Este foi um verdadeiro desafio, pois nossos especialistas estão acostumados a usar comandos do Linux. Soluções especiais foram necessárias, por exemplo, em alguns casos foi necessário especificar o caminho completo para o arquivo exe, em alguns - não, algo teve que ser escapado, etc. E após a implementação da integração com o Sharepoint, a equipe do projeto de aplicativo móvel em PHP disse:que eles também não têm um runner e desejam usar C #. Tive que repetir as operações para eles.



Resumo



Como resultado, apesar de um parque de tecnologias, equipes e processos tão heterogêneo, conseguimos agrupar os principais casos deste caso em diversos pipelines, automatizar sua execução, quando apropriado, e implementá-los. Em nosso exemplo, pudemos ter certeza de que:



  • A solução que estamos implementando é antiga o suficiente para fornecer a flexibilidade de que você precisa para construir processos DevSecOps em ambientes de implementação radicalmente diferentes. A flexibilidade é alcançada por meio de um grande conjunto de integrações embutidas e personalizadas, sem as quais os custos de mão de obra para implementação aumentariam significativamente ou a tornariam impossível;
  • . 3-4 ;
  • DevSecOps DevOps , , . win-win - .


Lembre-se: esta é a primeira parte de uma série de artigos sobre a construção de um processo de desenvolvimento seguro em um grande varejista. No próximo post, revelaremos os detalhes da implementação deste projeto no grupo de aplicativos da família SAP.



Você já teve sua própria experiência na implementação de projetos semelhantes? Ficaremos felizes se você compartilhar conosco seus casos de implementação de práticas de desenvolvimento seguro nos comentários!



Autor: Ivan Staroselsky, Chefe do Departamento de Operação e Automação de Sistemas de Informação



All Articles