Como experimentar a segurança avançada do GitHub

O que é GitHub Advanced Security?

O GitHub Advanced Security é uma solução de segurança da aplicação centrada no desenvolvedor que moderniza e transforma a forma como a segurança da aplicação é percebida e implementada nas organizações. No ecossistema do GitHub Advanced Security, há três recursos principais.

A matriz abaixo ilustra quais recursos estão disponíveis gratuitamente durante a avaliação, dependendo do fato de você estar usando um repositório público ou privado.

Como você pode ver acima, a varredura de código e a revisão de dependências são totalmente gratuitas para uso em repositórios públicos! Em primeiro lugar, vemos clientes querendo testar a varredura de código. Portanto, vamos testar os recursos e as funcionalidades da varredura de código. Se desejar testar o conjunto completo de recursos oferecido pela verificação de segredo, não hesite em entrar em contato conosco usando o formulário na parte inferior.

Como ativar o varredura de código e o CodeQL

A varredura de código é uma abordagem nativa do GitHub, centrada no desenvolvedor, para encontrar facilmente vulnerabilidades de segurança. Com a ajuda do mecanismo de análise de código mais avançado do mundo, o CodeQL, ela examina o código à medida que ele é criado e apresenta análises de segurança acionáveis nas pull requests.

Há duas maneiras de experimentá-lo: em um repositório público que você já usa ou em um repositório de amostra baseado em sua linguagem de programação.

Opção 1: se você quiser testar a varredura de código em um repositório de código aberto que você mantém.

A varredura de código é gratuita para todos os repositórios públicos do GitHub. Mantenha uma biblioteca de código aberto ou qualquer outro repositório público ativo com código usado? Veja como configurá-la agora.

• Acesse as Configurações do repositório

• Escolha a guia Segurança e análise de código

• Na seção "Varredura de código", ao lado de "Análise de CodeQL", clique no menu suspenso Configurar, em seguida selecione Padrão"

• Clique em Ativar CodeQL

• Após uma execução bem-sucedida, clique na guia Segurança e, em seguida, clique em Exibir alertas ao lado de "Alertas de varredura de código" para ver se o CodeQL encontrou alguma vulnerabilidade em seu código."

Figura 1: imagem mostrando como ativar a varredura de código em um repositório.

Observação: você precisará ter permissões de administrador para testar completamente a varredura de código.

Opção 2: se você quiser testar a varredura de código em um repositório de amostra criado pelo GitHub.

Não tem nenhum repositório público? Não tem problema. O GitHub mantém cinco repositórios que podem orientá-lo em um exemplo simples de varredura de código. Lembre-se de que o CodeQL tratará as linguagens compiladas de forma ligeiramente diferente das interpretadas. A extração funciona monitorando o processo de compilação padrão para linguagens compiladas.

Exemplos de repositórios por idioma

• Tutorial de varredura de código para JavaScript

• Tutorial de varredura de código para Java

• Tutorial de varredura de código para C#

• Tutorial de varredura de código para Python

• Tutorial de varredura de código para Go

Quer tentar mais?

As opções acima devem dar uma noção básica da varredura de código, mas ainda há muito mais a aprender! Continue lendo abaixo para testar mais recursos e ver casos de uso mais complexos.

Varredura de código em ação com o Juice Shop

Executar sua primeira varredura é apenas o começo. O Varredura de código também se integra aos fluxos de trabalho do GitHub Actions, ou ao seu ambiente de CI/CD existente, para maximizar a flexibilidade da sua equipe. Você pode ver os fluxos de dados das vulnerabilidades, descartar rapidamente os falsos positivos e concluir outras tarefas diárias de segurança, tudo em um único repositório.

Vamos explorar como usar o repositório Juice Shop como exemplo.

Etapa 1: criar um fork do repositório

Crie um fork do repositório do Juice Shop em sua conta e configure a varredura de código seguindo o tutorial anterior.

Etapa 2: ativar o Actions

Como os fluxos de trabalho estão em um repositório com fork, eles não serão executados até que você os ative especificamente. Vá para a guia Ações e ative os fluxos de trabalho clicando no botão mostrado na captura de tela abaixo.

Figura 2: imagem mostrando como ativar o GitHub Actions em um repositório com fork

Etapa 3: executar uma varredura

Teste o fluxo de trabalho fazendo uma pequena alteração no arquivo README.md do seu repositório e, em seguida, faça o commit da alteração no branch padrão. Após a conclusão da varredura, você deverá ver cerca de 50 novas notificações na guia Segurança.

Etapa 4: verificar seus alertas

Em seguida, acesse a página de alertas de varredura de código clicando na guia Segurança e, em seguida, em Alertas de varredura de código.

Você pode usar essa API para desativar ou ativar a varredura de código de forma programática. Para grandes empresas, essa API é útil quando você está adotando a varredura de código em escala.

Figura 3: imagem mostrando como encontrar os alertas de varredura de código

Depois de clicar em alertas, você verá a página a seguir.

Figura 4: imagem mostrando a página de alertas de varredura de código

Há três seções principais nessa página: Dados de varredura mais recentes, Função de pesquisa e Exibição de alertas.

• Dados da varredura mais recente: o cartão na parte superior contém dados sobre a varredura mais recente. É uma maneira rápida e fácil de encontrar dados sobre a execução mais recente.

• Pesquisa: um mecanismo de pesquisa fácil de filtrar para procurar alertas específicos com base em metadados.

• Visualização de alertas: um formato de lista de todos os resultados encontrados no branch padrão do repositório.

Compreensão dos resultados da varredura de código

Embora os resultados das varreduras de segurança sejam gerados por ferramentas automatizadas, ainda cabe aos desenvolvedores abordá-los e corrigi-los. É por isso que as ferramentas centradas no desenvolvedor são essenciais, e é por isso que os resultados de Varredura de código do GitHub são criados com os desenvolvedores em mente. As informações que você vê priorizam o que precisa ser resolvido primeiro e, em seguida, mostram como corrigir a vulnerabilidade.

Pesquisa e filtragem de resultados

A visualização padrão mostra todos os alertas encontrados no branch padrão do seu repositório (que normalmente é o principal). Você pode usar a pesquisa ou as opções de filtro fornecidas no cabeçalho para restringir os resultados de acordo com suas necessidades.

Aprofundamento em alertas específicos

Para obter mais informações sobre um alerta específico, clique no nome do alerta para ter uma visão detalhada do que ele é e como corrigi-lo. Você também terá uma visualização da linha do tempo de onde o alerta foi encontrado pela primeira vez, onde foi encontrado e onde está agora.

Como a segurança avançada do GitHub afeta seu fluxo de trabalho

A segurança é uma responsabilidade da equipe. Muitas vezes conhecido como "alteração de segurança para a esquerda", proteger seu código contra vulnerabilidades requer a contribuição das equipes envolvidas em todas asfases do ciclo de vida de desenvolvimento de software. Com a verificação de código e a Segurança Avançada do GitHub, desenvolvedores, pessoal de segurança e administradores podem aprender e agir de acordo com os resultados demaneira significativa.

Abaixo, você pode explorar os vários recursos da verificação de código executando tarefasprojetadas para determinadas funções na organização, desde um membro da equipe de segurança até um desenvolvedor ou proprietário do produto. Confira os diferentes casos de uso, mesmo que não estejam relacionados a sua função atual e você poderá se surpreender com o que poderá aprender.

Exemplos de verificação de código para equipes de segurança

Como auditor de segurança, quero filtrar todos os alertas de verificação de código apenas para injeções de SQL. Em seguida, quero me aprofundar em uma injeção de SQL específica, observando o histórico da linha do tempo desse alerta. Os dados que procuro são quando foi cometido, quem o cometeu e todos os locais em que a vulnerabilidade foi alertada ou alterada, para que eu possa avaliar o possível impacto aolongo do tempo. - Auditor de Segurança

Vamos começar com a função de pesquisa. Clique em Regra e procure por 'injeção de código'.

Figura 5: imagem mostrando como filtrar por regra

Clique em um dos alertas retornados e esta tela deverá ser mostrada.

Figura 6: imagem mostrando um alerta específico

Esta é a página que mostra tudo sobre um alerta. Para esta etapa, as informações críticas estão na parte inferior.

Figura 7: imagem mostrando o cronograma/histórico de auditoria de alertas

Este recurso oferece uma visão cronológica ou histórico de auditoria de onde a vulnerabilidade foi detectada pela primeira vez e quem a cometeu. ((Isso permite rastrear o histórico e os committers de vulnerabilidades.) Se você ou qualquer outra pessoa pegar essa vulnerabilidade, alterá-la em uma ramificação ou empurrá-la para cima, a linha do tempo será atualizada de acordo.

As a security engineer reviewing an alert, I want to see the data flow of the user-provided value from source to sink, so I can understand the true (positive or negative) nature of thisvulnerability. - Engenheiro de Segurança

Você pode encontrar a origem, o coletor e o caminho fornecido pelo usuário na página de alerta único. Clique no botão Mostrar caminhos para começar.

Figura 8: imagem mostrando como encontrar o botão mostrar caminho.

Um pop-up deve ser mostrado, semelhante ao seguinte.

Figura 9: imagem mostrando o caminho fonte/sumidouro

Pronto! Daqui, você pode ver a fonte na parte superior, em que os dados estão chegando e o coletor, em que os dados são executados. Percorra as diferentes etapas para ver o caminho para a execução. Isso permite que você consulte se a injeção de SQL é algo para se preocupar. Esta etapa também mostrará a entrada exata do usuário. Na Figura 9, clique no hiperlink Valor fornecido pelo usuário. Deve mostrar exatamente em que está o valor de entrada.

Exemplos de digitalização de código para desenvolvedores

Como desenvolvedor júnior, gostaria de saber mais sobre injeções de SQL para entender melhor como corrigi-las. Desenvolvedor Júnior

Continuando na página detalhada do alerta único, vamos tentar descobrir mais informações sobre uma injeção de SQL.

Clique em Mostrar mais.

Figura 10: imagem que mostra ao usuário como ver mais informações sobre um alerta

Feito. Isso é tudo que você precisa fazer. O objetivo disso é ajudar os desenvolvedores a aprender mais sobre uma vulnerabilidade potencial. Se for a primeira vez que um desenvolvedor encontra um, ele gostaria de saber:

• Resumo da vulnerabilidade

• Recomendação de como abordar a vulnerabilidade

• Exemplo de como consertar

• Referências externas

Todos esses detalhes são fornecidos na visão geral mostrada na imagem expandida acima.

Como desenvolvedor, quero descobrir rapidamente quais resultados são alertas de testes, para poder marcá-los como fechados e concentrar-se em alertas relacionados ao códigofonte. - Desenvolvedor

Esse assunto surge o tempo todo. "Vulnerabilidades" encontradas, mas em arquivos de teste. Primeiro, volte para a tela inicial para ver todos os alertas. Deveria ser assim.

Figura 11: imagem mostrando a página de alertas de varredura de código

Execute um filtro por regra, mas desta vez, filtre por credenciais codificadas. Agora você deve obter uma lista de todas as vulnerabilidades que mostram credenciais embutidas em código. Immediately, we know which ones are found in tests because there is a (Test) prefix on the vulnerability Você pode ver um exemplo abaixo.

Figura 12: imagem mostrando uma vulnerabilidade encontrada em um teste.

Clique em uma dessas vulnerabilidades. Em seguida, clique no botão Dispensar -> Usado em botões de testes. A vulnerabilidade deve fechar automaticamente.

Figura 13: imagem que mostra como um desenvolvedor pode marcar um resultado de verificação de código como fechado.

É tão fácil quanto isso: os desenvolvedores podem vir aqui para ver se uma vulnerabilidade é um teste e depois fechá-la. Você também pode adotar uma abordagem semelhante para marcar uma vulnerabilidade como Não será corrigida ou Falso positivo.

Observação:

• Após clicar em Usado em testes, observe a linha do tempo/histórico de auditoria na parte inferior da página de alerta. Deverá ser atualizado com informações sobre o evento.

• Quando você clica no botão Usado em testes, um webhook de alerta de verificação de código é disparado. O que isso significa? Bem, se você deseja que apenas certas pessoas fechem alertas de verificação de código, você pode ter o código em execução naquele evento de webhook que verifica quem ofechou — e se não fosse um identificador do GitHub em uma lista aprovada, você poderia reabri-lo automaticamente. ((Isso também será atualizado na linha do tempo.)

Etapas extras

• Fazer o procedimento acima manualmente em um grande repositório mono pode ser um pouco tedioso. Então use a API! Use a API de verificação de código para obter todos os resultados. Filtre aqueles que correspondem às credenciais codificadas do ID da regra e observe o nome do arquivo. Se houver "testes/" no início, você poderá fechá-los automaticamente clicando em Atualizar API de verificação de código.

• Como este é um projeto JavaScript, você pode criar um arquivo codeql-análise.yml e adicionar uma seção para ignorar caminhos a esse arquivo. Isso vai ignorar o diretório de teste. Envie esse arquivo e observe se as descobertas nessa pasta não são sinalizadas.

Como desenvolvedor, quero ajustar o tipo de verificação ao nível de risco de um repositório,para que meus repositórios de alto e baixo risco não executem no mesmo nível. - Desenvolvedor

No arquivo .github/workflows/codeql-analysis.yml, especificamente na ação github/codeql-action/init@v1, se nenhuma configuração for fornecida, o conjunto padrão de consultas será executado. O que isso significa?

Cada linguagem com suporte do CodeQL vem com um conjunto padrão de três pacotes: padrão (segurança), segurança estendida e segurança e qualidade.

• Padrão

  Se nada mais for especificado, o pacote padrão executará consultas de alta exatidão. Isso significa que os resultados obtidos serão extremamente precisos e práticos, e algo que você provavelmente gostaria de examinar. No entanto, ele não executará todas as consultas disponíveis.

• Segurança estendida 

  Contém um conjunto mais amplo de consultas (que ainda focam na segurança), mas pode retornar resultados que não são tão aplicáveis a você. As consultas executadas neste pacote ainda são precisas e precisas com o objetivo de retornar resultados práticos, mas abrangem cenários que nem todas as equipes considerariam relevantes.

• Segurança e qualidade

  O pacote de segurança e qualidade executa todas as consultas em segurança estendida, com algumas consultas adicionais de qualidade de código semelhantes ao que você veria em uma ferramenta de linting. Este pacote seria relevante apenas para equipes interessadas em resultados de qualidade de código, não apenas em segurança. O objetivo é poder diversificar o tipo de consultas executadas de acordo com as necessidades do repositório e não mais executar o mesmo tipo de varreduras para projetos completamente diferentes.

Observação: há muitos benefícios na criação de pacotes de consultas. Você pode criar um pacote de consultas específico para um tipo de aplicação (SPA, API, por exemplo) ou um que inclua apenas consultas do SANS 25 ou OWASP Top 10. Para esta etapa, usaremos os pacotes de consultas integrados com base na exatidão e precisão das consultas.

Como desenvolvedor, quero configurar meu fluxo de trabalho para executar verificações de segurança em alterações em arquivos markdown e apenas nas ramificações principal e de controle de qualidade, para não perder tempo esperando por resultados desnecessários. - Desenvolvedor

O aspecto mais frustrante das ferramentas de segurança padrão são as verificações desnecessárias. Isso retarda o lançamento ou a mesclagem de uma solicitação pull. É aqui que entra o GitHub Actions. O GitHub Actions integra-se facilmente com o GitHub Advanced Security, o que significa que podemos facilmente configurar uma verificação para, por exemplo, ignorar certos tipos de arquivo. Então, vamos modificar o arquivo ..github/workflows/codeql-analysis.yml para não executar uma verificação em arquivos markdown, o que é uma solicitação comum dos desenvolvedores.

Siga as etapas para evitar verificações desnecessárias de arquivos. Após terminar, deve ficar parecido com isto.

Figura 15: imagem mostrando como você pode configurar o GitHub Actions para ignorar caminhos/tipos de arquivo.

Vá para README.md e faça uma alteração no arquivo. Nenhum fluxo de trabalho é iniciado, o que significa que as verificações só são executadas em alterações relevantes. Além disso, como as alterações ocorrem apenas na ramificação principal, se você fizer uma alteração em uma ramificação chamada feature/123, novamente, um fluxo de trabalho não será disparado.

Consulte a sintaxe de ações do GitHub para obter mais configurações

Como desenvolvedor e defensor da segurança, gostaria de habilitar e aplicar políticas de segurança para que meu código atenda aos requisitos de minha organização. Desenvolvedor

Após a configuração inicial da verificação de código, os usuários podem configurar integrações de terceiros para estender a funcionalidade padrão, como a Ferramenta/Ação de Conformidade de Segurança Avançada, que permite aos usuários definir políticas como código.

Confira em como adicionar a ação acima a .github/workflows/codeql-analysis.yml. Um exemplo de política que convém adicionar é bloquear solicitações pull que introduzem uma licença específica. Seja criativo: isso permitirá que você especifique o que é aprovado ou reprovado em uma compilação devido a uma política do ponto de vista do código.

Exemplos de varredura de código para proprietários de produtos

Como proprietário de um produto, quero gerar um relatório em PDF que mostre a postura de segurança de uma versão, para que eu possa anexá-lo como evidência de apoio em minha documentação interna de versão. Proprietário do produto

Os PDFs são práticos para empresas maiores, pois suas visões gerais de segurança podem acompanhar a documentação oficial como prova de suporte. Para criar um PDF usando a Ação do relatório do GitHub Security, crie um novo fluxo de trabalho no repositório que seja executado em uma versão, crie uma versão e veja o novo relatório que é introduzido. Em seguida, você pode obter a documentação de suporte necessária, que mostrará se você está ou não em conformidade com determinados requisitos de segurança.

Exemplos de varredura de código para proprietários de produtos

Como proprietário de um produto, quero gerar um relatório em PDF que mostre a postura de segurança de uma versão, para que eu possa anexá-lo como evidência de apoio em minha documentação interna de versão. Proprietário do produto

Os PDFs são práticos para empresas maiores, pois suas visões gerais de segurança podem acompanhar a documentação oficial como prova de suporte. Para criar um PDF usando a Ação do relatório do GitHub Security, crie um novo fluxo de trabalho no repositório que seja executado em uma versão, crie uma versão e veja o novo relatório que é introduzido. Em seguida, você pode obter a documentação de suporte necessária, que mostrará se você está ou não em conformidade com determinados requisitos de segurança.

Exemplos de verificação de código para arquitetos DevSecOps

Como administrador/arquiteto de ferramentas de segurança de terceiros, quero fazer upload dos resultados da minha ferramenta de terceiros atual para o GitHub Segurança Avançada ,para que os desenvolvedores possam permanecer no GitHub para encontrar todos os resultados e não precisar alternar entre várias ferramentas. - Arquiteto DevSecOps

Para este exemplo, você pode usar qualquer ferramenta de verificação de segurança ou qualidade de código de terceiros que desejar, desde que seja compatível com SARIF. Isso significa que você pode ter três ou quatro ferramentas atuais junto com a verificação de código do GitHub.

Já tem uma ferramenta em mente? Gere o SARIF e exporte-o da maneira padrão e use a Upload SARIF API para fazer upload dos dados. Confira como fica na GUI.

Se você não estiver usando uma ferramenta específica, há muitas ferramentas no GitHub Actions Marketplace. Você pode usar a ação Aqua Security Trivy como exemplo se não encontrar nenhuma outra. Trivy é uma ferramenta de contêiner de terceiros que se integra facilmente à digitalização de código.

Quando a verificação terminar e os dados forem carregados, você poderá filtrar os resultados pela ferramenta. Basta voltar para a guia Alertas de verificação de código em Segurança e filtrar por Ferramenta, conforme mostrado na captura de tela abaixo:

Figura 16: imagem mostrando como você pode filtrar resultados por ferramentas.