Como implementar um analisador estático no desenvolvimento para que todos fiquem felizes?

No processo, muitas vezes nos perguntam: como implementar um analisador estático no desenvolvimento para que tudo esteja bem. Já falamos sobre por que um analisador estático é necessário para o desenvolvimento seguro. Este artigo será útil se você estiver escolhendo um analisador estático ou se já planeja implementá-lo. Como configurar o processo para que as vulnerabilidades descobertas no código sejam finalmente corrigidas? Neste artigo, tentaremos ajudá-lo a lidar com esse problema.

O que está por vir?

A implementação do analisador de forma que as vulnerabilidades sejam corrigidas de maneira estável não é uma questão rápida. Por experiência, podemos dizer que leva de algumas semanas a vários meses. Se você estiver implementando o analisador em uma grande empresa, prepare-se para uma série de aprovações. Afinal, são centenas de bases de código que precisam ser analisadas e dezenas de equipes com suas próprias ordens de desenvolvimento.

Para adicionar um novo estágio de desenvolvimento - análise estática, você terá que estudar como o processo de cada equipe funciona e propor uma solução que seja conveniente para todos. Nas pequenas empresas, a ordem de desenvolvimento estabelecida pode não existir. A implementação do analisador pode ser uma desculpa para construir um processo. Para que a integração seja mais suave, recomendamos que você descubra qual analisador possui os recursos para isso.

Quais são as opções de integração?

Normalmente, o analisador assume uma interface não gráfica (CLI, REST) ​​para integração em qualquer processo. Existem analisadores com integrações prontas: com ferramentas de construção e ambientes de desenvolvimento, com sistemas de controle de versão (Git, SVN), servidores de CI / CD (Jenkins, TeamCity, TFS), sistemas de gerenciamento de projetos (Jira) e gerenciamento de usuários (Active Directory). Quanto mais útil para sua empresa, mais fácil será configurar tudo.

Como você pode construir um processo?

Considere a situação padrão: os departamentos envolvidos são segurança da informação, gerenciamento de liberação e desenvolvimento. Como regra, o cliente da implementação do analisador é a segurança da informação (IS). A tarefa é concordar com quem, quando e o que fará. Distinguimos as seguintes etapas: iniciar a análise, processar os resultados da análise, criar uma solicitação para corrigir a vulnerabilidade, corrigir a vulnerabilidade, verificar a correção . Considere cada etapa com mais detalhes.

Etapa 1. Execute a análise

Você pode executar a análise manual ou automaticamente. As abordagens têm seus prós e contras.

Manualmente

Ele próprio lembrou-se do analisador, baixou o código pessoalmente e foi ver os resultados.



Se houver cerca de uma dúzia de projetos na empresa e um oficial de segurança estiver encarregado de monitorar a segurança, esse cenário é possível. Se houver cerca de cem projetos, você precisará configurar a automação.

Automatizado

Decida com que frequência e em que momento você precisará analisar o código. Por exemplo, antes de entrar em um ambiente produtivo, de acordo com um determinado cronograma (uma vez por semana) ou após cada alteração.

Se o aplicativo raramente for atualizado, mas você também precisar monitorar sua segurança, configure a análise se houver alguma alteração.

Se muitas pessoas trabalham no código, muitas ramificações são criadas, as mudanças geralmente ocorrem - é melhor analisar com frequência, mas não interfere no desenvolvimento. Por exemplo, no momento da criação de uma solicitação de mesclagem com a ramificação principal ou quando o status da tarefa nessa ramificação é alterado. A integração com um sistema de controle de versão ou com um sistema de gerenciamento de projetos o ajudará com isso. A integração com o CI / CD fará da análise uma das etapas de compilação.

Defina a programação para que você tenha tempo para processar os resultados.

Etapa 2. Processar os resultados da análise

Não instrua os desenvolvedores a corrigir imediatamente todas as vulnerabilidades encontradas. Deixe o oficial de segurança verificá-los primeiro. Os resultados da primeira análise podem parecer deploráveis: dezenas de vulnerabilidades críticas, centenas de menos críticas e milhares de falsos positivos. O que fazer aqui? Recomendamos corrigir as vulnerabilidades gradualmente. O objetivo final é alcançar a ausência de vulnerabilidades no código antigo e no novo. No estágio inicial, verifique as vulnerabilidades críticas (ainda inseguras com elas) e novas (o novo código é mais fácil de corrigir).

Use filtros. Classifique as vulnerabilidades por gravidade, idioma, arquivo e diretório. Ferramentas mais avançadas mostrarão vulnerabilidades apenas no novo código, ocultarão vulnerabilidades em bibliotecas de terceiros. Os filtros foram aplicados, mas ainda existem muitas vulnerabilidades?

Veja as vulnerabilidades mais prováveis. Existem analisadores que avaliam a probabilidade de um falso positivo. Se houver muitas vulnerabilidades e o nível de criticidade for quase o mesmo para todos, filtre os resultados usando essa métrica. Então você processa rapidamente as vulnerabilidades mais prováveis ​​(veja a captura de tela abaixo).



Use status de verificação. Para capturar os resultados da verificação, geralmente os analisadores se oferecem para trabalhar com status da vulnerabilidade: confirmar ou rejeitar como um falso positivo. Como regra, o trabalho realizado deve ser preservado durante a nova verificação.

Etapa 3. Crie uma solicitação de correção de vulnerabilidade

Se o desenvolvedor iniciar a análise de seu código e corrigir imediatamente as vulnerabilidades, é claro que você não precisará criar solicitações desnecessárias.

Se o oficial de segurança revisar e verificar os resultados, para a correção adicional das vulnerabilidades confirmadas, geralmente é necessário definir uma tarefa. Temos enfrentado repetidamente o fato de que foi nessa etapa que surgiram dificuldades.

Formulário de solicitação

Existem empresas nas quais grandes tarefas para o estágio são fixadas no sistema de gerenciamento de projetos (por exemplo, Jira). E para subtarefas e bugs, por exemplo, os problemas do GitLab são usados, acesso ao qual apenas o líder da equipe e sua equipe têm acesso. Também acontece que a montagem é impossível sem criar uma tarefa separada no sistema de gerenciamento de projetos. O analisador pode ter integrações com as quais você pode criar as consultas necessárias imediatamente na interface.

Freqüentemente, na mesma empresa com vários grupos de desenvolvimento, cada um deles tem seu próprio procedimento para implementar tarefas de trabalho. E você precisa se adaptar a todos. Surgem perguntas:

• Vale a pena alocar um projeto separado para corrigir vulnerabilidades ou criar tarefas nas existentes?
• A vulnerabilidade é um bug familiar ou uma nova entidade?
• Criar uma tarefa separada para cada vulnerabilidade ou agrupar outras semelhantes?
• O que devo fornecer como descrição do problema: um link para uma vulnerabilidade na interface do analisador ou um local no código e descrever brevemente o problema?
• E o desenvolvedor precisa acessar os resultados - basta enviar um relatório em PDF com o texto “consulte página 257 "e basta?

Obviamente, depende de como o processo da equipe é ajustado, quais sistemas de rastreamento de erros são usados.

Se o código for escrito por contratados para os quais o acesso aos sistemas internos é mínimo, um esquema com um relatório em PDF é adequado. Normalmente, para um relatório, você pode selecionar vulnerabilidades que são do seu interesse e enviá-las imediatamente para o endereço desejado na interface do analisador.

Se uma empresa não puder dar um único passo sem criar um projeto para um determinado tipo de tarefas com uma certa quantidade de recursos, você deverá procurar uma ferramenta com integração ao seu sistema. As integrações mais flexíveis gerarão uma descrição da tarefa para você (elas nem esquecerão o link para o código-fonte no sistema de controle de versão) e permitirão que você preencha todos os campos obrigatórios. Escolha o tipo de tarefa, especifique o pai, os artistas e até a versão de lançamento.

Custos e condições de trabalho

Se a equipe decidiu fazer uma avaliação dos custos de mão-de-obra para cada tarefa, a tarefa de corrigir a vulnerabilidade precisa ser feita da mesma maneira. Ao longo do caminho, os desenvolvedores verificam as vulnerabilidades. Às vezes, nesta etapa, verifica-se que a vulnerabilidade é falsa ou impossível de explorar.

Mas, como regra, os recursos ainda não são suficientes para corrigir imediatamente todas as vulnerabilidades. Portanto, também é necessário coordenar suas prioridades.

As tarefas foram determinadas pelos custos e prioridades de mão-de-obra - então os responsáveis ​​pelas datas de lançamento (este pode ser o gerente do projeto ou o mesmo líder da equipe) decidem o que corrigir e quando. Inicialmente, usando o analisador, recomendamos que você não adie a versão, se nem todas as vulnerabilidades estiverem corrigidas.

Etapa 4. Corrija as vulnerabilidades

Como alocar recursos adequadamente: conectar novas pessoas ou confiar àqueles que já estão envolvidos no desenvolvimento é uma questão orçamentária. Uma coisa é verdadeira: se a empresa alocar recursos para a instalação do analisador, você precisa se preparar para os custos de correção de vulnerabilidades. Uma maneira possível é estabelecer a porcentagem de tempo para corrigir vulnerabilidades como um trabalho com dívida técnica.

Existem dois cenários: corrija imediatamente no processo de desenvolvimento ou a pedido de um oficial de segurança. Corrigir vulnerabilidades durante o desenvolvimento é um cenário ideal. Encontrado imediatamente - corrigido imediatamente. O desenvolvedor verifica sua ramificação de recursos antes de solicitar uma mesclagem com a ramificação principal. Isso também pode ser automatizado por meio de integrações: com o ambiente de desenvolvimento, com ferramentas de construção, sistema de controle de versão ou com CI / CD.

Outro cenário é analisar o principal ramo de desenvolvimento após todas as alterações. Um oficial de segurança ou líder de equipe analisa os resultados e cria tarefas para corrigir vulnerabilidades. Este cenário é mais demorado. Na entrada do desenvolvedor está o código fonte, a tarefa de correção e os resultados da análise. Para um desenvolvedor, a tarefa de corrigir uma vulnerabilidade não é muito diferente de corrigir um bug.

Etapa 5. Verifique a correção

Você precisa garantir que a vulnerabilidade seja realmente corrigida e que uma nova não apareça em seu lugar. Existem resultados da análise do código corrigido. O que procurar? Número de arquivo e linha da vulnerabilidade? Ou pesquise pelo nome da vulnerabilidade? É possível e assim. Mas se o código fosse alterado, a linha com a vulnerabilidade poderia mudar e ainda haveria muitas ocorrências de uma vulnerabilidade. Alguns analisadores podem mostrar vulnerabilidades "corrigidas". Concorde, para que você possa verificar a correção da vulnerabilidade mais rapidamente (veja a captura de tela).

Exemplos

Aqui estão dois cenários possíveis.

Cenário 1

A equipe usa Git para controle de versão, Jira para gerenciamento de projetos e tarefas. Jenkins configura o cronograma de compilação. Por exemplo, uma vez por dia, se houver alterações na ramificação. Como uma etapa adicional, o início do analisador é indicado.

O oficial de segurança analisa os resultados da análise da ramificação principal (mestre ou desenvolvimento) e os desenvolvedores revisam suas ramificações de recursos.

Os desenvolvedores corrigem vulnerabilidades, se necessário. Se o analisador puder filtrar vulnerabilidades sob demanda: mostre apenas novas vulnerabilidades ou não em bibliotecas de terceiros, mostre vulnerabilidades em um diretório ou arquivo específico - o desenvolvedor poderá visualizar rapidamente os resultados que lhe interessam. Portanto, a probabilidade de correção é maior.

O oficial de segurança analisa os resultados da análise da filial principal. Usando a integração com o Jira, o oficial de segurança cria tarefas de gerenciamento de vulnerabilidades a partir da interface do analisador. Em seguida, é a coordenação de prazos e prioridades.

Quando a vulnerabilidade é corrigida e o novo código passa por todos os estágios internos de desenvolvimento (revisão do líder da equipe, usuário e teste de regressão), o oficial de segurança deve garantir que a vulnerabilidade não esteja mais lá. O autor fecha a tarefa concluída.

Cenário 2

O código da empresa é escrito por um grupo de contratados. O Timlid interage com os desenvolvedores por email e usa o GitLab para controle de versão. Os contratados não têm acesso aos sistemas internos de gerenciamento de projetos (Jira).

O oficial de segurança ou o próprio líder da equipe revisa os resultados da análise do principal ramo de desenvolvimento. Os contratados não têm acesso ao analisador. Se houver vulnerabilidades que precisem ser corrigidas, o oficial de segurança envia um relatório em PDF com os resultados da análise ao líder da equipe ou imediatamente ao desenvolvedor.

No relatório, o desenvolvedor descobre onde a vulnerabilidade é encontrada, em que consiste e como pode ser corrigida. É importante que, para as vulnerabilidades associadas ao fluxo de dados inseguros (por exemplo, injeção SQL), o esquema de distribuição seja descarregado no relatório: da fonte de dados ao seu uso na chamada de função / método (veja a captura de tela).



Após corrigir a vulnerabilidade, o líder da equipe informa ao oficial de segurança que é hora de verificar os resultados da nova varredura.

O que mais é importante?

Estabelecer a interação entre segurança e desenvolvimento da informação. É importante que ambas as partes estejam interessadas em corrigir vulnerabilidades. Bem, se serão não apenas pedidos, mas também comunicação ao vivo.

Não negligencie as funções de usuário. Um bom analisador deve ter a capacidade de diferenciar direitos. É improvável que um contratado precise de direitos de administrador ou dos resultados de uma análise de sistemas internos. Para editar os resultados - para alterar a criticidade e o status - é suficiente permitir ao oficial de segurança e ao líder da equipe. O princípio dos privilégios mínimos não foi cancelado.

Se a empresa for grande e usar um sistema de gerenciamento de usuários (por exemplo, Active Directory), considere ferramentas com integração pronta. Você poderá reutilizar as funções e grupos aceitos na empresa e conceder a eles os direitos necessários.

Conclusão

Depois de escolher um analisador, prepare-se para o fato de ele ainda precisar ser implementado corretamente. Não tenha medo de reuniões e coordenação com os participantes: quanto melhor você entender no processo, mais útil será o resultado. É importante que o cenário de trabalho não seja apenas aprovado, mas também comece a seguir.

Publicado por Elizaveta Kharlamova, Analista Líder, Solar appScreener