ethan-andrews/threatintel-aggregatorPlataforma de threat intelligence auto-hospedada — agregação de feeds, triagem por IA, cobertura MITRE ATT&CK e engenharia de deteção integrada com o Sentinel. Funciona de forma autónoma ou totalmente integrada no Azure.
Uma plataforma de threat intelligence auto-hospedada que agrega feeds RSS de mais de 60 fornecedores de segurança, executa triagem por IA, correlaciona descobertas com seu inventário de ativos RunZero e exibe alertas acionáveis por meio de um painel web em modo escuro.
Criada para rodar de forma autônoma com zero dependência de nuvem, ou totalmente integrada a um ambiente Azure/Entra/Sentinel — escolha o nível que corresponde ao que você tem.
| Nível | Script | Triagem por IA | Autenticação | Armazenamento | O que você obtém |
|---|---|---|---|---|---|
| Basic | scripts/setup-basic.sh | Desligada | Chave de API local | Postgres local (Docker) | Agregação de feeds, extração de IOC, matriz MITRE, painéis — sem IA, sem nuvem, nada para se cadastrar |
| Basic + API | scripts/setup-basic-api.sh | Anthropic (direto) | Chave de API local | Postgres local (Docker) | Tudo acima, mais triagem de severidade/TTP/resumo por IA |
| Azure + API | scripts/setup-azure.ps1 | Azure AI Foundry | SSO do Microsoft Entra ID | Seu próprio Postgres (Azure DB for PostgreSQL, etc.) | Implantação completa no Azure Container Apps, SSO com funções por usuário. (A integração do pipeline detections.ai chegará em uma versão futura — veja abaixo.) |
Os três executam exatamente o mesmo código da aplicação — a única coisa que muda é quais variáveis de ambiente estão definidas. Consulte Variáveis de Ambiente para a referência completa.```bash
./scripts/setup-basic.sh
./scripts/setup-basic-api.sh
./scripts/setup-azure.ps1
Os dois scripts bash criam um contentor Postgres local, aplicam o esquema e geram `backend/.env` / `frontend/.env.local` por ti — depois imprimem os dois comandos para realmente iniciar a aplicação (`pip install` + executar backend, `npm install` + executar servidor de desenvolvimento frontend). `setup-azure.ps1` é um wrapper fino em torno de `infra/provision.ps1`, o verdadeiro runbook de implementação do Azure Container Apps.
---
## Funcionalidades
- **Agregação de feeds** — consulta mais de 60 feeds RSS de segurança Tier 1/2/3 numa agenda; deduplica e filtra conteúdo promocional automaticamente
- **Triagem por IA** — classifica cada entrada com severidade (Critical/High/Medium/Low/Informational), TTPs MITRE ATT&CK e um resumo em linguagem simples. Modular por fornecedor: API Anthropic direta ou Azure AI Foundry, alternável através de uma variável de ambiente sem perda de funcionalidade em qualquer dos casos
- **Extração de IOC** — extrai automaticamente IPs, domínios, URLs, hashes de ficheiros e CVEs de cada entrada
- **Integração RunZero** — sincroniza o teu inventário de ativos e correlaciona threat intel com ativos em tempo real; corresponde por CVEs, nomes de software, versões de SO e endereços IP. Três sub-separadores sob `RUNZERO`: **Matches** (entradas correlacionadas com o teu inventário, filtráveis por severidade/data/confiança/KEV), **Exposure** (posição confirmada/possível ao nível da organização com acompanhamento de remediação) e **Metrics** (tendências de ingestão vs. remediação ao longo do tempo)
- **Your Stack** — define o software/SO no teu ambiente; reclassifica todas as entradas por relevância
- **Livro de registo de IOC** — registo pesquisável de todos os indicadores extraídos com referências cruzadas de entradas e exportação STIX/CSV
- **Matriz MITRE ATT&CK** — mapa de calor da cobertura de TTPs em toda a threat intel ingerida
- **Dashboard de saúde dos feeds** — estado de consulta por feed, acompanhamento de falhas consecutivas e volume de artigos em 7 dias
- **Detections** — uma superfície de revisão com 9 separadores (ver abaixo) que cobre tudo o que está registado como deteção, seja gerado por IA, importado dos teus próprios ficheiros ou sincronizado de um workspace Sentinel em tempo real
- **Autenticação modular** — Microsoft Entra ID SSO com acesso baseado em funções, ou uma única chave de API local partilhada com zero dependência do Azure. Detetada automaticamente pelo frontend; ver [Auth modes](#auth-modes)
### Duas funcionalidades relacionadas com deteções
Este repositório na verdade disponibiliza duas coisas relacionadas mas utilizáveis de forma independente sob o guarda-chuva "detections":
1. **O separador `DETECTIONS`** — uma superfície de revisão autónoma, dividida em nove sub-separadores:
- **All Detections** — o catálogo completo de analíticas registadas, filtrável por técnica/disposição/estado de revisão, cada uma expansível para a sua descrição e KQL completo.
- **Defender Custom Detections** — o mesmo catálogo, limitado a deteções destinadas às regras de deteção personalizadas do Microsoft Defender for Endpoint em vez de regras analíticas do Sentinel.
- **Alignment Reviews** — sempre que uma analítica de deteção é registada contra uma técnica MITRE, uma verificação por IA compara a sua cobertura real com a própria descrição da técnica pelo MITRE. Quando diverge ou cobre apenas parcialmente a técnica, aparece aqui como um item de revisão humana com o raciocínio da IA, uma correção KQL sugerida e o próprio resultado de validação dessa correção (gate estático + backtest) — nunca uma sugestão cega.
- **Disposition Alerts** — uma fila de deteção de apodrecimento: uma analítica aprovada cuja telemetria decai ou cuja regra subjacente começa a dar erro é sinalizada aqui para re-revisão, nomeada pela sua própria deteção em vez de apenas pela técnica MITRE partilhada.
- **Generated Hunts** — as deteções são agrupadas em hunts (uma por ficheiro importado atualmente; uma por artigo de TI/projeto detections.ai de origem assim que essa integração for lançada), correspondendo à própria funcionalidade Hunts do Microsoft Sentinel. Um hunt pode ser sincronizado para um workspace Sentinel real como um objeto `Microsoft.SecurityInsights/hunts` mais as suas consultas de pesquisa guardadas constituintes (controlado por `SENTINEL_HUNTING_SYNC_ENABLED` e um `mode` — off/manual/auto — configurável por equipa em Settings > API Settings; nunca um envio automático silencioso a menos que optes por isso).
- **Sentinel Hunts** — o inventário em tempo real do que está realmente implementado na funcionalidade Hunting do teu workspace Sentinel, obtido diretamente do ARM em vez do próprio histórico de sincronização desta aplicação; inclui sugestões de teste/ajuste por consulta que podes aplicar ou dispensar no local.
- **Sentinel Analytics Rules** — a mesma ideia para as Analytics Rules do Microsoft Sentinel (`Microsoft.SecurityInsights/alertRules`) — um tipo de recurso Sentinel distinto do Hunting, uma vez que são estas que realmente disparam incidentes/alertas numa agenda — com o mesmo fluxo de trabalho de aplicar/dispensar sugestões de ajuste.
- **Local Detections** — ver [Running without Sentinel or an AI provider](#running-without-sentinel-or-an-ai-provider-local-detections-import) abaixo.
- **Audit Log** (apenas admin) — um registo transversal de pipeline de cada verificação que esta aplicação realmente executou: resultados de gate/control-probe de deteções geradas por IA, tentativas de sincronização de hunt do Sentinel e execuções de teste de consultas de hunt/regras analíticas do Sentinel, combinados numa única lista paginada e filtrável — cobrindo deliberadamente o que nenhum separador de revisão individual faz por si só.
É executado inteiramente dentro do backend principal, sem necessidade de implementação extra para a própria superfície de revisão. O seu próprio design de API segue deliberadamente as convenções do detections.ai abaixo, mesmo sendo totalmente autónomo.
2. **Orquestrador de pipeline detections.ai — brevemente.** O detections.ai tem uma API pública em desenvolvimento para geração de deteções assistida por IA, e este repositório tem uma integração real construída para ela (`backend/detection_pipeline/orchestrator.py`) que recebe threat intel triada, verifica-a contra a cobertura de deteção existente e gera KQL preliminar para o teu workspace Sentinel como uma tarefa agendada. Esta integração suportará essa API assim que estiver disponível, e ainda não faz parte deste lançamento público. Entretanto, **não precisas dela para usar o separador Detections de todo** — [Local Detections Import](#running-without-sentinel-or-an-ai-provider-local-detections-import) abaixo cobre o mesmo objetivo de "colocar deteções reais nesta aplicação" para configurações sem geração por IA e sem Sentinel hoje.
### Executar sem Sentinel ou um fornecedor de IA: Local Detections Import
Dado o nome da aplicação e o seu argumento principal, a pergunta mais comum de um self-hoster no nível **Basic** provavelmente será *"Não tenho Sentinel nem um fornecedor de IA configurado — ainda consigo tirar algo dos separadores Detections/Hunts?"* A resposta é sim: aponta a aplicação para uma pasta dos teus próprios ficheiros de regras de deteção (escritos à mão, exportados de um tenant Sentinel/Defender real, ou obtidos de um repositório público de regras Sigma/Sentinel) e ela irá catalogá-los, etiquetá-los com MITRE e validá-los estaticamente — sem necessidade de conexão Sentinel e sem necessidade de `DETECTIONS_AI_API_KEY`/chave Anthropic para nada disso.
- **Formatos suportados, desde o primeiro dia:** ficheiros brutos `.kql`/`.txt`/`.yar`/`.spl`-ou-qualquer-extensão, cada um opcionalmente emparelhado com um sidecar `.json`/`.yaml` (`{"file": "myrule.kql", "title": "...", "description": "...", "technique_id": "T1059.001"}`) para metadados que a própria exportação da Microsoft não precisa de declarar separadamente; YARA; Suricata; Sigma YAML (documento único ou múltiplo); Splunk SPL; e o próprio JSON nativo exportado de Analytics Rule/Hunting Query da Microsoft (apenas regras do tipo `Scheduled` transportam uma consulta KQL bruta que esta aplicação consegue avaliar — todos os outros tipos são reconhecidos e reportados, não ignorados silenciosamente).
- **O que realmente é executado num ficheiro importado:** validação estática (o mesmo motor de durabilidade/findings que o caminho de geração por IA usa) para conteúdo KQL; uma verificação de alinhamento MITRE também, se *tiveres* um fornecedor de IA configurado (um eixo independente do Sentinel — podes ter um, ambos, ou nenhum); tudo o que depende do Sentinel (backtesting, sondas de telemetria, acompanhamento de disposição) fica fora do âmbito e é apresentado como "no Sentinel connection configured" em vez de uma célula em branco enganadora.
- **Onde aparece:** o conteúdo importado torna-se uma linha normal de hunt/deteção — mesmas tabelas, mesmo fluxo de trabalho de revisão, mesma exibição de técnica MITRE que qualquer coisa que o pipeline de IA gere — por isso também aparece nas vistas regulares `ALL DETECTIONS`/`GENERATED HUNTS`, não apenas no seu próprio separador. O sub-separador dedicado **Local Detections** (sob `DETECTIONS`, apenas admin para acionar uma importação) é onde apontas para uma pasta e acompanhas o progresso/resultados por ficheiro.
- **Configuração:** define `LOCAL_IMPORT_DIR` para um caminho absoluto no sistema de ficheiros do backend (um volume montado, numa implementação em contentor) — tudo o que for importado tem de residir sob essa raiz; a UI permite-te escolher um sub-caminho por baixo dela, nunca uma localização arbitrária do sistema de ficheiros. Ver [Environment Variables](#environment-variables).
- **Experimenta imediatamente:** `examples/local-detections-samples/` disponibiliza uma pequena pasta pronta a importar — duas regras KQL válidas (uma emparelhada com um sidecar `.json` para mostrar esse mecanismo), uma regra deliberadamente inválida (para ver o banner de sinalização como inválida) e um ficheiro não reconhecido (para ver o banner de importação falhada). Aponta `LOCAL_IMPORT_DIR` para ela para ver os três estados de resultado na tua primeira importação, sem necessidade de escrever regras.
**Local Detections** — uma execução de importação concluída: o banner de resumo destaca ficheiros que foram catalogados mas sinalizados como inválidos pela análise estática (aqui, uma regra que alerta sobre um único hash codificado) ao lado dos que foram importados sem problemas, e cada ficheiro torna-se uma linha normal de hunt/deteção abaixo
---
## Capturas de ecrã
Todas as capturas de ecrã abaixo usam dados sintéticos (nomes de organizações falsos, IPs de exemplo RFC 5737, domínios `.example`) gerados para documentação — nenhuma threat intel real ou dados de clientes.
**Feed** — navega e filtra entradas de threat intel triadas com severidade, tags, IOCs e TTPs
<br>
**Dashboard** — desagregação de severidade num relance e principais técnicas MITRE ATT&CK
<br>
**MITRE ATT&CK** — mapa de calor da matriz completa da cobertura de técnicas em toda a intel ingerida
<br>
**Your Stack** — define o teu ambiente; as entradas do feed são reclassificadas por relevância
<br>
**IOCs** — registo pesquisável de todos os indicadores extraídos com exportação STIX/CSV
<br>
**Integrations** — visão geral dos conectores para Sentinel, Defender e RunZero: estado configurado/ativado e atalhos para o separador próprio de cada um
<br>
**RunZero** — correlação de ativos, acompanhamento de exposição ao nível da organização e métricas de remediação, tudo proveniente do teu inventário RunZero
<br>
**Exposure** — organizações classificadas por contagem de correspondências de ameaças; clica em qualquer cartão para ver as entradas correspondentes
<br>
**Detections** — o catálogo completo de analíticas registadas (geradas por IA e importadas localmente), cada uma com o seu estado de gate estático/backtest/revisão e técnica MITRE
<br>
**Settings** — controlos de triagem por IA, monitorização de saúde dos feeds, pontuações de confiança das fontes e gestão de utilizadores
---
## Arquitetura```
┌─────────────────────────────────────────┐
│ Next.js 16 frontend (port 3000) │
│ Tailwind CSS · dark theme │
└──────────────┬──────────────────────────┘
│ REST API (Bearer token)
┌──────────────▼──────────────────────────┐
│ FastAPI backend (port 8000) │
│ APScheduler · slowapi rate limiting │
└──┬──────────┬──────────┬────────────┬───┘
│ │ │ │
Postgres AI provider RunZero API detections.ai
(modular: (asset sync) (coming soon --
Anthropic or see Features below)
Azure AI Foundry)
Backend (backend/) — Python 3.12 + FastAPI. Postgres para todo o armazenamento (SQLite e Azure Blob Storage foram totalmente descontinuados). O provedor de IA e o método de autenticação são ambos selecionados por variáveis de ambiente, não codificados — veja abaixo.
Frontend (frontend/) — Next.js 16, JavaScript puro, Tailwind CSS. Detecta automaticamente o modo de autenticação a partir do backend no momento do carregamento.
Infra (infra/) — Templates Azure Bicep para Container Apps, Key Vault e Container Registry (apps.bicep + platform.bicep + app-stack.bicep, implantados via provision.ps1). Relevante apenas para o nível Azure + API.
AZURE_AD_TENANT_ID definido → Modo Entra: SSO do Microsoft Entra ID, funções por usuário (o primeiro login torna-se admin, todos os outros assumem o padrão de visualizador).
AZURE_AD_TENANT_ID não definido → Modo Local: uma única LOCAL_API_KEY compartilhada concede acesso de admin a quem a possuir. Sem gerenciamento de usuários, sem dependência do Azure. O frontend chama GET /api/auth/mode no carregamento e renderiza a tela de login correspondente automaticamente — nada a configurar no lado do frontend.
Ambos os modos emitem o mesmo tipo de JWT assinado pela aplicação posteriormente, portanto todas as outras rotas (require_auth/require_admin) funcionam de forma idêntica independentemente do modo que emitiu o token.
Execute scripts/setup-basic.sh ou scripts/setup-basic-api.sh (veja Níveis de implantação) — eles cuidam do Postgres e da geração do .env para você. Depois:```bash
cd backend && pip install -r requirements.txt && uvicorn main:app --reload --port 8000
cd frontend && npm install && npm run dev
### Configuração manual```bash
cd backend
python -m venv .venv
source .venv/bin/activate # Windows: .venv\Scripts\activate
pip install -r requirements.txt
cp env.example .env # fill in required values — see Environment Variables below
uvicorn main:app --reload --port 8000
# Clone o repositório
git clone https://github.com/yourusername/kitploit.git
cd kitploit
# Instale as dependências
pip install -r requirements.txt
# Execute a ferramenta
python kitploit.py --help
# Compile a imagem Docker
docker build -t kitploit .
# Execute o contêiner
docker run -it --rm kitploit --help
pip install kitploit
# Exibir ajuda
kitploit --help
# Executar uma verificação básica
kitploit scan --target example.com
# Executar com opções avançadas
kitploit scan --target example.com --verbose --output results.json
| Opção | Descrição |
|---|---|
--help | Exibir mensagem de ajuda |
--version | Exibir informações da versão |
--target | Especificar o alvo |
--verbose | Ativar saída detalhada |
--output | Especificar o arquivo de saída |
# Verificar um único alvo
kitploit scan --target 192.168.1.1
# Verificar vários alvos
kitploit scan --target 192.168.1.1,192.168.1.2
# Verificar a partir de um arquivo
kitploit scan --input targets.txt
# Exportar resultados
kitploit scan --target example.com --output results.json
A ferramenta pode ser configurada através de um arquivo de configuração ou variáveis de ambiente.
# config.yaml
target: example.com
verbose: true
output: results.json
threads: 10
timeout: 30
export KITPLOIT_TARGET=example.com
export KITPLOIT_VERBOSE=true
export KITPLOIT_OUTPUT=results.json
Problema: A ferramenta não inicia.
Solução: Certifique-se de que todas as dependências estão instaladas:
pip install -r requirements.txt
Problema: Erros de permissão.
Solução: Execute com privilégios elevados ou ajuste as permissões de arquivo:
sudo python kitploit.py scan --target example.com
Problema: A verificação é muito lenta.
Solução: Aumente o número de threads:
kitploit scan --target example.com --threads 20
Se você encontrar problemas:
### Docker Compose (ambos os serviços)```bash
cp backend/env.example backend/.env # fill in required values
docker compose up --build
Frontend → http://localhost:3000 Backend API docs → http://localhost:8000/docs
Copie backend/env.example para backend/.env e preencha. Agrupadas por qual camada precisa delas:
Sempre obrigatórias:
| Variável | Descrição |
|---|---|
PG_DSN | String de conexão do Postgres |
JWT_SECRET_KEY | Segredo para assinar tokens de sessão da aplicação (python -c "import secrets; print(secrets.token_hex(32))") |
Autenticação — escolha um modo:
| Variável | Descrição |
|---|---|
LOCAL_API_KEY | Modo local: chave compartilhada que concede acesso de administrador. Deixe AZURE_AD_TENANT_ID não definida para ativar este modo |
AZURE_AD_TENANT_ID | Modo Entra: ID do tenant para SSO. Defini-la ativa o modo Entra |
AZURE_AD_CLIENT_ID | Modo Entra: client ID do registro do aplicativo |
AZURE_AD_CLIENT_SECRET | Modo Entra: segredo do registro do aplicativo (somente frontend) |
NEXTAUTH_SECRET | Modo Entra: segredo de criptografia de sessão do NextAuth (somente frontend) |
Triagem por IA — opcional, escolha um provedor (omita ambos para executar com a triagem desabilitada):
| Variável | Descrição |
|---|---|
AI_PROVIDER | anthropic (padrão) ou azure |
ANTHROPIC_API_KEY | Chave da API Anthropic direta |
AZURE_FOUNDRY_ENDPOINT | Endpoint do Azure AI Foundry, ex.: https://<resource>.services.ai.azure.com/anthropic |
AZURE_FOUNDRY_API_KEY | Chave da API do Azure AI Foundry |
AZURE_FOUNDRY_DEPLOYMENT | Nome da implantação do Foundry (padrão claude-haiku-4-5) |
AZURE_FOUNDRY_API_VERSION | Versão da API do Foundry (padrão 2025-05-01) |
Opcionais:
| Variável | Descrição |
|---|---|
RUNZERO_API_TOKEN | Habilita a sincronização e correlação de ativos do RunZero |
ALLOWED_ORIGINS | Lista de permissões CORS separada por vírgulas (padrão http://localhost:3000) |
ENABLE_SCHEDULER | Defina como false para desabilitar o poller de feeds em segundo plano (padrão true) |
ARCHIVE_AFTER_DAYS | Limite de arquivamento automático em dias (padrão 90) |
PG_POOL_MIN / PG_POOL_MAX / PG_POOL_TIMEOUT | Ajuste do pool de conexões do Postgres (padrões 1 / 10 / 30) |
LOCAL_IMPORT_DIR | Habilita a Importação de Detecções Locais — caminho absoluto no sistema de arquivos do backend ao qual toda importação é confinada. Não definida desabilita o recurso completamente (sua aba exibe uma mensagem de "não configurado") |
Frontend (frontend/.env.local ou frontend/env.local.example):
| Variável | Descrição |
|---|---|
NEXT_PUBLIC_API_URL | URL do backend conforme vista pelo navegador. Incorporada ao bundle JS em tempo de build. Deixe não definida para rotear chamadas de API através do proxy de mesma origem integrado (frontend/pages/api/[...proxy].js) — necessário sempre que o backend não tiver ingresso público (ex.: o Container App somente interno da camada Azure + API) |
BACKEND_URL | URL do backend conforme vista pelo próprio servidor Next.js. Usada pela troca de login do NextAuth e, quando NEXT_PUBLIC_API_URL não está definida, pelo proxy de mesma origem que encaminha toda requisição de navegador /api/* no lado do servidor |
Orquestrador detections.ai — em breve (ainda não faz parte desta versão pública; documentado aqui para quando for lançado. Camada Azure + API, implantável separadamente — veja backend/detection_pipeline/orchestrator.py):
| Variável | Descrição |
|---|---|
DETECTIONS_AI_API_KEY | Obrigatória para executar o orquestrador |
SENTINEL_WORKSPACE_ID | ID de cliente (GUID) do workspace do Log Analytics, para backtesting. Opcional |
PIPELINE_BATCH_SIZE | Entradas por execução (padrão 5) |
PIPELINE_DRY_RUN | true para reivindicar e registrar sem chamar a API |
PIPELINE_LANGUAGE | Linguagem de consulta de detecção (padrão kql) |
Sincronização do Sentinel Hunts (opcional, desativada por padrão — veja Configurações > Configurações de API para o modo ligado/desligado/manual/automático):
| Variável | Descrição |
|---|---|
SENTINEL_HUNTING_SYNC_ENABLED | true para permitir qualquer tentativa de sincronização de hunt. Não definida/false é um no-op puro — zero chamadas ARM |
AZURE_SUBSCRIPTION_ID | Assinatura que contém o workspace do Sentinel |
AZURE_RESOURCE_GROUP | Grupo de recursos que contém o workspace do Sentinel |
SENTINEL_WORKSPACE_NAME | O nome do workspace, não seu ID de cliente — um valor diferente de SENTINEL_WORKSPACE_ID acima, que o cliente de plano de dados de backtesting usa em vez disso |
O IaC real e atual é infra/apps.bicep + infra/platform.bicep + infra/app-stack.bicep, implantado via infra/provision.ps1 (ou o wrapper fino scripts/setup-azure.ps1). Ele provisiona Container Apps, segredos respaldados pelo Key Vault e identidades gerenciadas — o Postgres em si não é provisionado por este repositório; aponte PG_DSN (armazenada como o segredo pg-dsn do Key Vault) para qualquer servidor Postgres acessível.```powershell
./scripts/setup-azure.ps1
cd infra cp migration.psd1.example migration.psd1 # fill in your resource group, apps, etc. ./provision.ps1
`provision.ps1` é idempotente — seguro para reexecutar após editar o manifesto. Consulte o comentário de cabeçalho do próprio ficheiro para obter o passo a passo completo (plataforma → pilha de aplicações → segredos → Easy Auth → importação de imagens → aplicações → verificações posteriores).
O orquestrador detections.ai (um Container Apps Job agendado, controlado por um bloco `Orchestrator` em `migration.psd1` — consulte `migration.psd1.example` para ver a estrutura, e guarde a sua chave como o segredo `DETECTIONSAIAPIKEY` no Key Vault) ainda não faz parte desta versão pública — consulte [Duas funcionalidades relacionadas com detecções](#two-detections-related-features) acima.
---
## Estrutura do Projeto```
├── backend/
│ ├── main.py # FastAPI app, all endpoints
│ ├── db.py # Postgres queries
│ ├── pgcompat.py # connection pool + SQLite-style placeholder translation
│ ├── feed_manager.py # RSS polling, AI triage (provider-modular), scheduler
│ ├── enrichment.py # IOC extraction, KEV cache, stack rematch
│ ├── runzero_sync.py # RunZero asset sync and correlation engine
│ ├── dedup.py # CVE deduplication logic
│ ├── auth.py # Entra ID SSO + local API-key auth, app JWT sign/verify
│ ├── ioc_export.py # STIX 2.1 and CSV export
│ ├── stack_presets.py # Pre-built tech stack templates
│ ├── detection_pipeline/ # detections.ai orchestrator, MITRE alignment-check,
│ │ # Sentinel hunts/analytics-rules sync + tuning,
│ │ # audit log, local_import.py (Local Detections Import)
│ └── tests/ # pytest test suite, incl. fixtures/local_import/
├── frontend/
│ ├── pages/
│ │ ├── index.js # Main app shell + tab routing
│ │ └── login.js # Entra ID or local API-key login, auto-detected
│ ├── lib/
│ │ ├── authMode.js # GET /api/auth/mode, cached per page load
│ │ ├── authFetch.js # Bearer auth + 401-retry wrapper
│ │ └── authSession.js # token storage, JWT decode/expiry helpers
│ └── components/
│ ├── layout/ # TopBar, Sidebar, TabBar, TopFilterBar, TimeRangeToggle
│ ├── feed/ # FeedList, FeedCard
│ ├── integrations/ # IntegrationsPanel, ExposurePanel, RunZeroPanel,
│ │ # RunZeroMatchesPanel, RunZeroMetricsPanel
│ ├── detections/ # DetectionsPanel (tab shell) + one component per
│ │ # sub-tab: DetectionsCatalogPanel, AlignmentReviewPanel,
│ │ # DispositionAlertsPanel, HuntsPanel, SentinelHuntsPanel,
│ │ # SentinelAnalyticsRulesPanel, LocalDetectionsPanel,
│ │ # AuditPanel, plus shared TuningSuggestionBadge
│ ├── settings/ # SettingsPanel, CadencePicker, SeverityCards
│ └── mitre/ # MitreMatrix
├── infra/ # Azure Bicep templates + provision.ps1
├── scripts/ # Tiered setup scripts (see Deployment tiers)
└── docker-compose.yml
63 feeds em três níveis:
Authorization: Bearer <token>secrets.compare_digest) para a chave de autenticação local.env / Azure Key VaultMIT — consulte LICENSE.