Download deadshot - download do código-fonte deadshot

deadshot

Outro código-fonte

Baixar

Pistoleiro

Deadshot é um scanner Pull Request que procura a introdução de segredos por meio de PRs, comparando cada linha diff com um conjunto de expressões secretas conhecidas.

Capacidades de aplicação:

O serviço é responsável por:

Processador diff Pull Request em tempo real para verificar se segredos estão sendo confirmados no Github por meio de novo código
Notificar o usuário sobre a conversa de relações públicas se ele sinalizar algo
O Slack notifica o canal da equipe de segurança quando determinados segredos são identificados no código para o qual você habilitou notificações do Slack por meio de um sinalizador em regex.json

O serviço NÃO:

Faça qualquer análise de código estática ou dinâmica

Como funciona?

Deadshot é um aplicativo multicontêiner Flask-Celery-Redis que é instalado como um aplicativo Github para ser executado em cada solicitação pull criada no branch principal de um repositório no qual o aplicativo Github está instalado.

O contêiner Flask é o ponto de entrada para o serviço, expondo rotas de API definidas em blueprints.py. Depois que uma carga útil da solicitação pull é recebida na rota da API, o serviço encaminha a carga para uma fila Redis para o contêiner Celery coletar e verificar a diferença da solicitação pull. Depois que o contêiner de aipo verifica expressões regulares de segredos especificados, ele comenta os PRs, o Slack notifica o canal da equipe de segurança ou cria um ticket JIRA para a equipe acompanhar. O aplicativo Github é configurado com o URL da API Flask e um segredo compartilhado usado para gerar a soma de verificação SHA da carga útil.

Uma maneira de configurar o URL da API é implantando esse código em um host e atribuindo um balanceador de carga de aplicativo a esse host.

Criando um aplicativo Github

Observação: ao criar o aplicativo, certifique-se de ter um DNS pronto para o host no qual você implantará contêineres Deadshot e uma string secreta segura para o segredo do webhook.

Os administradores do Github precisariam criar e instalar um aplicativo Github no Github antes de executar ou implantar o aplicativo Deadshot. Para saber mais sobre como criar um aplicativo Github, leia este guia

Nome do aplicativo: deadshot (tudo em letras minúsculas. Isso é importante porque o serviço usa esse nome para buscar comentários anteriores feitos em um PR)

URL do webhook: http(s)://your-hosted-deadshot-dns/api/v1/deadshot-webhook

Para testar isso localmente, você pode criar um endpoint ngrok para alimentar a seção de webhook do seu aplicativo Github

Permissões do aplicativo Github

Para que este aplicativo funcione, seu aplicativo Github terá que habilitar as seguintes permissões e assinaturas na página de permissões do aplicativo Github: Permissões de repositório:

Metadados: somente leitura
PullRequests: ler e escrever
Webhooks: ler e escrever

Todas as outras permissões permanecem inalteradas com o valor padrão de Sem acesso

Inscreva-se em eventos:

Solicitação pull
Revisão de solicitação pull

Por fim, clique em “Criar aplicativo GitHub”. Após a criação bem-sucedida do aplicativo, siga o link “gerar uma chave privada” na seção superior da página da web do aplicativo

Depois que a chave privada for gerada, armazene-a em um local seguro. Essa chave privada gerada é um dos dados usados para gerar um token de sessão para interação do aplicativo.

Depois de gerar a chave privada, instale o aplicativo em todas as organizações que deseja monitorar.

Correndo Pistoleiro

Este é um aplicativo de vários contêineres projetado para abrir todos os três contêineres (Flask, Celery, Redis) por meio de /bin/run.sh, portanto, a execução da imagem Dockerfile deve exibir todo o aplicativo

Variáveis de ambiente:

Nota: Para implantação usando docker-compose.yaml, preencha essas variáveis de ambiente em localdev.env. Se você estiver implantando isso criando e executando cada imagem de contêiner individualmente por meio de Dockerfile.api, Dockerfile.celery, essas variáveis de ambiente estarão nos respectivos Dockerfiles

As três variáveis abaixo são valores de string única fornecidos pelo usuário

GITHUB_URL: Este é o URL por trás do qual sua instância do Github é acessada. Forneça o DNS sem esquema ou porta. Por exemplo. se o URL da web do Github for https://github.mockcompany.com, forneça o valor github.mockcompany.com
GITHUB_API: Este é o URL da API do Github. Por exemplo. se você tiver seu DNS do Github como https://github.mockcompany.com, sua API seria algo como https://github.mockcompany.com/api/v3
JIRA_SERVER=URL da web do servidor JIRA da sua empresa

As variáveis de ambiente abaixo carregam o caminho para os arquivos com credenciais. Carregue os valores-chave do arquivo json nos arquivos disponíveis aqui antes de executar o aplicativo.

SECRET_GITHUB_SECRET: esta variável carrega github_secrets.json e possui o segredo do webhook compartilhado do aplicativo Github, o ID de integração e a chave pem. Todos esses três segredos são obtidos na página de configurações do aplicativo Github webhook secret - Este é o segredo configurado durante o processo de criação do aplicativo ID de integração - Este é o ID do aplicativo mostrado na página de configurações do aplicativo github chave pem - esta é a chave privada gerada durante o processo de instalação do aplicativo
SECRET_SLACK_WEBHOOKS: Este slack_webhook.json tem o URL do webhook para o qual o aplicativo deadshot enviará notificações do Slack quando encontrar segredos em um PR para o qual você definiu slack_alert=True em regex.json
SECRET_JIRA_AUTH: carrega jira_user.json e possui o nome de usuário e a senha do ID do usuário para acessar o quadro JIRA da organização Observação: se você não fornecer valores válidos em SECRET_SLACK_WEBHOOKS e SECRET_JIRA_AUTH, o serviço falhará suavemente e imprimirá mensagens de erro sobre falha ao iniciar o slack e métodos jira nos logs do contêiner do docker

Nota: Se você não mover o local dos arquivos secretos JSON, não será necessário atualizar os três valores de variáveis de ambiente acima já presentes nos Dockerfiles ou docker-compose.yaml

Executando/servindo a imagem Docker

Este comando usará docker-compose.yaml para abrir todos os contêineres. Atualize configuration/environment/localdev.env com valores relevantes para sua organização antes de executar o comando abaixo

make serve

Depois de fazer isso e não pretender usar o Dockerfile para servir o aplicativo, vá para a seção “Server Healthcheck”

Construindo e executando o serviço usando Dockerfiles

Existem duas maneiras de construir e executar os Dockerfiles. Existem quatro Dockerfiles presentes no repositório, três dos quais são usados para gerar uma imagem individual para cada contêiner necessário para que este serviço funcione, e o quarto é uma configuração do Dockerfile para criar uma imagem que pode ser usada para abrir o Aplicativo Flask ou aipo trabalhador dependendo do valor da variável de ambiente DEADSHOT_RUN_MODE (api ou trabalhador) fornecido Para executar qualquer uma das etapas abaixo você precisa estar presente na pasta raiz do repositório

Observação: certifique-se de ter atualizado as variáveis de ambiente nos arquivos Dockerfile.api e Dockerfile.celery

Construindo imagens a partir de Dockerfiles individuais

Existem três Dockerfiles relevantes para esta etapa. Dockerfile.api, Dockerfile.celery e Dockerfile.redis

Para construir a imagem da API Flask

 docker build -f Dockerfile.api -t deadshot-api:<version> .

Para construir a imagem do aipo

 docker build -f Dockerfile.celery -t deadshot-worker:<version> .

Para construir a imagem redis

 docker build -f Dockerfile.redis -t deadshot-redis:<version> .

Executando imagens construídas

As três imagens construídas nas etapas anteriores funcionam todas em redes separadas, por isso não poderão se comunicar entre si. Para permitir comunicações entre contêineres, precisamos adicioná-los a uma rede de contêineres

Crie uma rede docker

 docker network create deadshot-network

Execute as imagens usando a rede criada na seguinte ordem: Inicie o contêiner redis:

 docker run --net deadshot-network --name redis deadshot-redis:<version>

Comece o recipiente de aipo:

 docker run --net deadshot-network deadshot-worker:<version>

Inicie o contêiner da API Flask:

 docker run --net deadshot-network -p 9001:9001 deadshot-api:<version>

Construindo e executando uma única imagem para contêiner Flask API e contêiner de trabalhador de aipo

Esta etapa só será útil se você tiver uma orquestração que permita alimentar variáveis de ambiente, segredos e outras configurações no momento da implantação. Use o método acima para executar os contêineres se você não tiver uma configuração de CI/CD configurável.

Para construir uma única imagem docker para abrir a API e o trabalhador de aipo com base na variável de ambiente DEADSHOT_RUN_MODE

make build

Este comando também criará a imagem redis necessária para o serviço

Se a imagem construída for executada com a variável de ambiente DEADSHOT_RUN_MODE=api, ela abrirá o aplicativo Flask Se a imagem for executada com a variável de ambiente DEADSHOT_RUN_MODE=worker então o celery trabalhador será iniciado

Verificação de integridade do servidor

Agora que a API está pronta para receber solicitações navegando para http://localhost:9001/api/v1/heartbeat em um navegador deve retornar uma resposta válida ou você pode fazer um curl

curl localhost:9001/api/v1/healthcheck

Ambos devem mostrar a seguinte mensagem: {"healthcheck": "ready"}

Executando uma verificação de solicitação pull

Se você tiver uma carga webhook do aplicativo Github para sua solicitação pull, poderá executar o seguinte comando curl localmente para testar seu aplicativo:

curl -X POST -H " content-type: application/json " -H " X-GitHub-Enterprise-Host: github.mockcompany.com " -H " X-Hub-Signature: sha1=85df4936c6396c149be94144befab41168149840 " -H " X-GitHub-Event: pull_request " -d @tests/fixtures/good_pr.json http://localhost:9001/api/v1/deadshot-webhook