Subdomainabber

Subdomainabber é uma ferramenta de varredura em Go para investigar possíveis casos de takeover de subdomínio em programas de bug bounty e avaliações de segurança autorizadas. Ela correlaciona DNS, HTTP e TLS, registra evidências reproduzíveis e mantém um histórico local em SQLite.

A versão v0.2.0 reúne recon nativo, sincronização de plataformas e inferência HTTP revisada. Consulte as notas da versão para instalação, migração e limitações.

Execute somente contra domínios incluídos no escopo do programa ou para os quais você possui autorização explícita. Respeite limites de taxa, janelas de teste e regras sobre automação.

O modo padrão não reivindica nem cria recursos. Os adaptadores de validação ativa disponíveis são os do Amazon S3 e do Amazon Route 53. O uso por meio de --aggressive exige confirmação adicional, lista de permissões exata e credenciais de escrita. Uma classificação de risco não comprova explorabilidade nem autoriza essa operação.

• coleta e correlaciona CNAME, DNAME, HTTPS/SVCB, delegação NS, MX, SRV, TXT/SPF, A/AAAA, HTTP e TLS;
• compara respostas de vários resolvedores para distinguir consenso, propagação, visão dividida e resultado inconclusivo;
• vincula assinaturas HTTP específicas ao provedor e ao CNAME observados;
• separa takeover, exposição, configuração quebrada e candidatos que ainda exigem prova de reivindicabilidade;
• armazena execuções e observações completas em SQLite para retomada, comparação e replay local;
• oferece saída em texto, JSON Lines, SARIF e bundles forenses assinados;
• roteia verificadores ativos somente para provedores e CNAMEs compatíveis;
• permite módulos ativos opcionais para exposição em nuvem, AXFR, redirecionamentos e outras verificações;
• analisa por padrão cadeias de redirect, postura HTTP→HTTPS, vhosts, TLS sem SNI, SANs relacionados e dependências web; a confirmação direta de origin continua opcional;
• correlaciona HTTP e HTTPS antes de concluir exposição, separando observação, candidato, confirmação, supressão e resultado inconclusivo;
• correlaciona histórico de certificados e provedores, CAA, DNSSEC, cookies, CORS e tokens TXT residuais;
• inclui sondas de evasão HTTP de requisição única e um laboratório separado de framing;
• oferece reivindicações reais e auditáveis para o Amazon S3 e o Amazon Route 53 no modo agressivo, com prova de controle e tentativa imediata de liberação.
• sincroniza programas e escopos acessíveis no HackerOne, Intigriti e Bugcrowd, expande os ativos DNS com recon nativo e mantém o catálogo local para novas varreduras.

Delegações seguem estados próprios: DELEGATION_BROKEN, DELEGATION_TAKEOVER_CANDIDATE, DELEGATION_CLAIMABILITY_VERIFIED e ZONE_CONTROL_CONFIRMED. A implementação passiva produz apenas os dois primeiros; o adaptador do Amazon Route 53 pode produzir o último por criação temporária e correspondência exata do conjunto de NS.

A saída humana lista todos os achados do host e coloca primeiro aquele com maior impacto ou que efetivamente causou a classificação:

[TAKEOVER PROVÁVEL] assets.example.com
  Vetor               : CNAME
  Cadeia              : assets.example.com → missing.s3.amazonaws.com
  Provedor            : AWS/S3
  Evidência           : HTTP 404 — "NoSuchBucket"
  Fonte               : linha de base
  Confiança da análise: ALTA
  Próximo passo       : valide o vínculo do recurso no provedor dentro do escopo do programa

[MX QUEBRADO] assets.example.com
  Vetor               : MX
  Destino             : mail.expired.example
  Resultado DNS       : NXDOMAIN
  Provedor            : desconhecido
  Propriedade         : EXTERNO NÃO VERIFICADO
  Registrabilidade    : expired.example (NÃO VERIFICADA)
  Reivindicabilidade  : NÃO COMPROVADA
  Impacto             : interceptação de e-mail somente após prova de registro ou vínculo no provedor
  Confiança da análise: ALTA
  Próximo passo       : valide propriedade, disponibilidade de registro e controle de entrega

[CONTROLE CONFIRMADO], [CONTROLE DO RECURSO COMPROVADO] e [CONTROLE DA ZONA CONFIRMADO] são reservados a uma prova ativa estruturada. Rótulos de quebra, revisão, recurso órfão e takeover provável continuam sendo achados de investigação.

Cada análise também possui um estado de resultado independente da classificação histórica:

• OBSERVATION: fato útil, sem resultado priorizado;
• CANDIDATE: há evidência suficiente para priorizar validação;
• CONFIRMED: o impacto foi observado ou comprovado;
• SUPPRESSED: a observação é verdadeira, mas uma regra contextual descartou exposição;
• INCONCLUSIVE: a coleta não sustentou uma conclusão;
• HEALTHY: a postura avaliada apresentou o comportamento esperado.

Para HTTP, a saída estruturada separa confiança da observação, da classificação e do impacto. http_correlation preserva status, tipo de conteúdo, hashes, tamanhos, servidores, Locations, similaridade e prioridade de transporte. A pontuação de prioridade serve somente para ordenar validações; ela não altera severidade ou CVSS.

• Go 1.26.6 ou superior para compilar; os binários da release não exigem Go instalado.

Os pacotes para Linux, Windows e macOS, em amd64 e arm64, estão na página de releases. Extraia o pacote da sua plataforma e confira seu SHA-256 com o arquivo SHA256SUMS da mesma release.

Para instalar pelo módulo Go:

go install github.com/amchdd/subdomainabber@latest

O Go grava o executável em GOBIN ou, quando essa variável não está definida, em $(go env GOPATH)/bin. Inclua esse diretório no PATH. No PowerShell, um executável compilado na pasta atual deve ser chamado com o prefixo .\.

Para compilar a partir do código-fonte:

git clone https://github.com/amchdd/subdomainabber.git
cd subdomainabber
go build -o subdomainabber .

No PowerShell, compile e execute o binário local desta forma:

git clone https://github.com/amchdd/subdomainabber.git
Set-Location subdomainabber
go build -o subdomainabber.exe .
.\subdomainabber.exe --version

Confirme o executável:

subdomainabber --version
# v0.2.0

O comando scan aceita argumentos, arquivo e entrada padrão (stdin). Entradas duplicadas são removidas. Quando a entrada é fornecida diretamente ao comando raiz, scan é assumido automaticamente; portanto, subdomainabber -l hosts.txt e subdomainabber scan -l hosts.txt são equivalentes.

# Argumentos
subdomainabber scan api.example.com assets.example.com

# Arquivo, um host por linha
subdomainabber scan --list hosts.txt

# Forma curta equivalente
subdomainabber -l hosts.txt

# Pipeline
printf "api.example.com\nassets.example.com\n" | subdomainabber scan

# JSON Lines para automação
subdomainabber scan -l hosts.txt --json --silent

# Explicação da classificação
subdomainabber scan -l hosts.txt --explain

# Lista extensa com memória limitada e checkpoint no SQLite
subdomainabber scan -l hosts.txt --stream --batch-size 1000

# Consenso DNS entre vários resolvedores
subdomainabber scan -l hosts.txt --dns-consensus

# Política de saída para CI
subdomainabber scan -l hosts.txt --fail-on-severity high

recon cria um inventário de subdomínios sem invocar Subfinder, Amass ou qualquer outro executável. A coleta, a resolução, as alterações e a persistência são implementadas no próprio binário. As fontes online continuam opcionais e fornecem dados passivos; a cobertura DNS ativa funciona sem credenciais externas.

O motor consulta crt.sh, Common Crawl, Wayback Machine, AlienVault OTX, CertSpotter e URLScan. Com SABBER_SECURITYTRAILS_TOKEN, acrescenta SecurityTrails. Depois correlaciona A, AAAA, CNAME, MX, NS e SRV, tenta aproveitar AXFR no modo exaustivo, extrai SANs TLS e referências em HTML, JavaScript, CSS, JSON e source maps da mesma origem.

A wordlist interna inclui serviços, ambientes, infraestrutura e regiões. O modo exaustivo permuta prefixos e sufixos, insere termos entre labels, troca ambientes e regiões observados, explora sequências numéricas e aprende labels já encontrados. A recursão ocorre em zonas com a densidade configurada, distribuindo cada termo entre todas as zonas elegíveis antes de avançar. Cada nome mantém suas origens e o resultado de DNS no SQLite.

# Cobertura ampla com os limites padrão
subdomainabber --db programa.db recon -d example.com

# Coleta passiva, sem geração ativa de nomes
subdomainabber --db programa.db recon -d example.com --mode passive

# Wordlist própria complementando as permutações internas
subdomainabber --db programa.db recon -d example.com --wordlist palavras.txt

# Proveniência em texto ou um candidato estruturado por linha
subdomainabber --db programa.db recon -d example.com --format sources
subdomainabber --db programa.db recon -d example.com --format jsonl

# Inventário observado, incluindo nomes sem resolução e coincidências de wildcard
subdomainabber --db programa.db recon -d example.com --include all

O modo padrão do comando é exhaustive. Ele coordena rodadas, profundidade, volume de candidatos, consultas DNS, recursão e leitura de assets. standard usa um orçamento menor e passive não gera candidatos. Uma wordlist informada complementa a lista interna. Os ajustes individuais anteriores continuam aceitos para compatibilidade, mas não aparecem na ajuda básica.

A detecção de wildcard é feita em cada nível da árvore DNS, e nomes que resolvem somente por IPv6 são preservados. Nomes observados em fontes, páginas ou certificados que coincidam com wildcard permanecem no JSON com wildcard: true, mas ficam fora da saída acionável. Use --include wildcards para inspecioná-los.

O progresso salva ao fim de cada rodada o catálogo, a fronteira e os nomes já testados. Uma interrupção pode ser retomada pelo mesmo comando, pois --resume fica ativo por padrão. Use --resume=false para iniciar outra execução.

A saída textual contém somente subdomínios que resolveram por A, AAAA ou CNAME e pode ser usada diretamente em pipes. --format seleciona text, sources, json ou jsonl. Nomes históricos que não resolvem continuam preservados no inventário e no JSON; use --include unresolved para incluí-los na saída textual ou JSON Lines. Quando uma fonte falha ou algum limite é atingido, o comando marca o resultado como parcial, informa o motivo no stderr e mantém ativos os nomes do catálogo anterior.

sync consulta todos os programas visíveis pelas credenciais configuradas, importa os escopos paginados, expande os wildcards com o recon nativo e executa uma varredura com o perfil completo. URLs e domínios exatos entram diretamente, sem ampliar o escopo. Programas, ativos, vínculos e checkpoints ficam no mesmo SQLite usado pelo restante da ferramenta.

export SABBER_HACKERONE_USERNAME="usuario-api"
export SABBER_HACKERONE_TOKEN="token-api"
export SABBER_INTIGRITI_TOKEN="token-pesquisador"
export SABBER_BUGCROWD_TOKEN="usuario:segredo"

# Sincronização pesada: catálogo, recon exaustivo e scan completo
subdomainabber --db bounty.db sync

# Uma plataforma específica
subdomainabber --db bounty.db sync --platform hackerone

# Atualiza o catálogo e expande somente escopos novos ou alterados
subdomainabber --db bounty.db sync --incremental --scan=false

# Revalida depois os hosts já analisados, sem repetir o sync pesado
subdomainabber --db bounty.db verify

Sem --platform, são usadas todas as plataformas que possuem credenciais. HackerOne usa a Hacker API e os structured_scopes; Intigriti usa a Researcher API e os domínios versionados; Bugcrowd usa a API autenticada de programas, briefs, grupos e targets. Na Bugcrowd, a credencial tem o formato usuario:segredo exibido ao criar o token.

O catálogo só envia ao recon e ao scan os ativos marcados como elegíveis ou pertencentes a grupos in_scope. Limites de automação positivos da Intigriti reduzem o limitador global quando forem mais restritivos. User-Agent e headers de identificação retornados nas regras do programa são aplicados por hostname às requisições HTTP. Se requisitos de programas diferentes entrarem em conflito no mesmo hostname, a CLI informa o conflito no stderr.

Durante a sincronização, o stderr informa a etapa atual, cada raiz de recon e a quantidade final de alvos; resultados e achados continuam no stdout. Se alguma fonte falhar ou um limite truncar a descoberta, a execução termina como PARTIAL, registra os motivos no SQLite e preserva os vínculos obtidos em sincronizações anteriores. Uma coleta completa substitui esses vínculos de forma atômica. As chamadas oficiais respeitam os limites documentados de 50 requisições por minuto da HackerOne e 60 da Bugcrowd, além do limitador global configurado.

Por padrão, a ferramenta aceita até 50 hosts em processamento simultâneo, tempo limite de rede de 5 segundos por operação e limite global de 10 operações por segundo. Quando o limite de taxa está ativo, a quantidade efetiva de hosts em processamento é limitada ao menor valor entre --concurrency e --rl; portanto, --concurrency 50 --rl 10 executa dez hosts simultaneamente e evita que algum host fique indefinidamente sem oportunidade de execução. O tempo aguardando uma permissão do limitador não consome o tempo limite de rede.

Os valores finais de concorrência, tempo limite e taxa precisam ser positivos. Nas opções de scan, zero apenas mantém o valor seguro da configuração ou o padrão; ele não desabilita o limitador. O modo --daemon aceita intervalos a partir de um minuto, e enum --concurrency aceita valores entre 1 e 1000.

Em terminal interativo — ou sempre com --verbose — o progresso inicial é exibido imediatamente em stderr e atualizado a cada dez segundos, com hosts processados, confirmados, candidatos, hosts ativos, operações concedidas ou aguardando, tempo decorrido, velocidade e previsão de término (ETA). O resumo final também separa observações, suprimidos, saudáveis e inconclusivos por motivo. A previsão fica em calibração até dez hosts terminarem para evitar estimativas iniciais enganosas. Resultados e JSON Lines continuam em stdout.

Ajuste os limites às regras do programa:

subdomainabber scan -l hosts.txt --concurrency 10 --timeout 8 --rl 5

--check-all é deliberadamente intensivo. Cada host pode gerar consultas para vários tipos DNS, HTTP/TLS, delegação, DNSSEC e AXFR. Como todos os módulos compartilham o mesmo limitador global, listas grandes ainda podem levar vários minutos. A ferramenta reutiliza consultas DNS idênticas, executa NS, DNSSEC e AXFR por corte de zona e enumera os seis nomes SRV comuns uma vez por domínio registrável. A enumeração SRV em cada nome de host só ocorre com --srv-exhaustive.

Cadeias de redirect, comparação de vhost, dependências web passivas, TLS sem SNI e descoberta passiva de SANs fazem parte da análise padrão. As opções booleanas padrão aceitam =false. Destinos HTTP/HTTPS publicados em Location são acompanhados automaticamente; --related-hosts continua controlando somente a consulta adicional de assets e dependências web.

Framing experimental deve ser usado apenas em laboratório próprio e controlado:

subdomainabber scan lab.example \
  --check-framing \
  --framing-confirm-controlled \
  --framing-allowlist lab.example

Não execute framing em infraestrutura de terceiros sem autorização específica. Uma diferença de interpretação não é evidência de provedor ou de takeover. Consulte a auditoria técnica do HTTP Mutator.

O modo agressivo existe para programas que autorizam explicitamente a criação temporária do recurso. Há validação ativa para o Amazon S3 e para zonas do Amazon Route 53. MX, SRV, SPF, TXT, A/AAAA, Azure, Google Cloud e outros provedores permanecem não suportados enquanto não houver um adaptador capaz de criar, provar controle e liberar o recurso.

export SABBER_AWS_ACCESS_KEY="..."
export SABBER_AWS_SECRET_KEY="..."
# export SABBER_AWS_SESSION_TOKEN="..." # se usar credenciais temporárias
export SABBER_AWS_REGION="us-east-1"

subdomainabber scan bucket.example.com \
  --aggressive \
  --aggressive-confirm-auto-claim \
  --aggressive-allowlist bucket.example.com

Quando o host chega a uma classificação elegível e possui um candidato compatível, o fluxo S3:

1. registra ATTEMPTING no SQLite, com a identidade esperada e o token de prova, antes de alterar o estado externo;
2. extrai o nome exato do bucket do endpoint S3 publicado no CNAME e recusa endpoints ambíguos ou regiões incompatíveis;
3. grava um objeto privado com o token aleatório;
4. verifica o token por HeadObject;
5. registra CLAIM_SUCCESS somente após a prova;
6. tenta remover o objeto e o bucket imediatamente;
7. registra RELEASE_SUCCEEDED ou mantém RELEASE_FAILED para reconciliação na próxima execução agressiva.

Para o Amazon Route 53, o mecanismo só aceita uma delegação publicada pela zona pai quando todos os NS falharam de forma conclusiva, não há DS na zona pai e todos os servidores de nomes pertencem ao mesmo provedor. Um simples NS_PROVIDER_MATCH nunca autoriza a criação. Depois dessas condições, o mecanismo cria uma zona hospedada temporária para o corte de zona, compara o conjunto completo de NS atribuído com a delegação publicada pela zona pai e só emite ZONE_CONTROL_CONFIRMED quando os conjuntos são idênticos; depois, tenta remover a zona. Se os conjuntos forem diferentes e a limpeza for confirmada, produz DELEGATION_CLAIMABILITY_NOT_DEMONSTRATED e rebaixa o caso para DELEGATION_BROKEN. Uma falha de limpeza permanece auditada para reconciliação e interrompe a execução agressiva. O mesmo corte de zona só é testado uma vez por execução, mesmo quando muitos hosts descendentes aparecem na entrada.

As confirmações, a lista permitida e as credenciais são verificadas antes da varredura. Já as condições derivadas das evidências, como delegação pai, DS, falha conclusiva e vínculo com o provedor, são avaliadas durante a análise; candidatos que não as atendem são ignorados ou registrados como não suportados, sem criação externa. Não use credenciais administrativas: aplique uma política dedicada e limite a conta ou região conforme as regras do programa. O modo agressivo não pode ser combinado com --daemon: cada execução com escrita precisa ser única e explícita. Um host já registrado no SQLite pode ser informado novamente em uma varredura agressiva; varreduras comuns também atualizam o histórico em vez de abandonar observações repetidas.

Cada varredura usa subdomainabber.db por padrão. Escolha outro caminho com --db.

subdomainabber --db programa.db scan -l hosts.txt
subdomainabber --db programa.db verify --only-risky
subdomainabber --db programa.db db stats
subdomainabber --db programa.db db export --format json
subdomainabber --db programa.db db export --format sarif --out resultados.sarif
subdomainabber --db programa.db db history
subdomainabber --db programa.db db diff EXECUCAO_A EXECUCAO_B
subdomainabber --db programa.db db replay EXECUCAO
subdomainabber --db programa.db scan --resume EXECUCAO

Cada scan registra os alvos como pendentes antes do processamento. Uma interrupção mantém os alvos não concluídos disponíveis para --resume; repita as mesmas opções do perfil original. db replay reexecuta somente classificação e confiança sobre as observações armazenadas, sem acesso à rede.

Para preservar uma execução como evidência verificável, gere as chaves uma vez, assine o bundle e valide-o com uma chave pública confiável:

subdomainabber --db programa.db db keygen --private-out bundle.key --public-out bundle.pub
subdomainabber --db programa.db db bundle EXECUCAO --out evidencias.json --signing-key bundle.key
subdomainabber db verify-bundle evidencias.json --public-key bundle.pub

verify revalida os hosts já armazenados no banco; ele não recebe uma lista de entrada. A varredura inicial envia achados relevantes como DISCOVERED, e o verify envia mudanças posteriores. Configure o Discord com --discord-webhook ou SABBER_DISCORD_WEBHOOK; o Telegram usa SABBER_TELEGRAM=bot_token:chat_id.

A CLI e o Discord usam a mesma seleção de evidência causal em vez da primeira evidência coletada. Achados do mesmo hostname aparecem em um único bloco, com o principal primeiro e os demais como relacionados. Configurações incorretas mostram o vetor e a causa concreta, como HTTP_OPEN_REDIRECT ou SPF_BROKEN_INCLUDE; ausência isolada de HSTS/CSP permanece apenas como postura ou hardening. Respostas HTTP 401/403/404/5xx sem exposição são suprimidas. Delegações e AXFR são agrupadas pela zona. Assim, dezenas de hosts abaixo de projects.example.com geram apenas um achado por corte de zona. Na saída humana da CLI, observações, suprimidos e inconclusivos ficam ocultos por padrão; use --show-inconclusive para revisão. Eles nunca são enviados como descobertas ao Discord, inclusive quando o limiar é info.

Exemplo mantendo apenas prioridade média ou superior:

subdomainabber -l hosts.txt \
  --check-all \
  --min-severity medium \
  --discord-min-severity medium \
  --discord-webhook "$SABBER_DISCORD_WEBHOOK"

subdomainabber fingerprints validate
subdomainabber fingerprints list
subdomainabber fingerprints coverage
subdomainabber benchmark synthetic
subdomainabber benchmark corpus
subdomainabber benchmark regression datasets/regression
subdomainabber benchmark mutator

benchmark gold acessa somente as entradas marcadas como verificadas no conjunto informado e deve obedecer às mesmas regras de autorização da ferramenta. Os arquivos em datasets/gold são modelos inativos com domínios reservados; substitua-os apenas por infraestrutura controlada e registre data, autorização, referência e evidência esperada. benchmark mutator é totalmente local e mede sondas executadas, rejeições, diferenças, assinaturas, falsos positivos e falsos negativos em comportamentos controlados de borda e origem. Os nomes das pilhas descrevem comportamentos simulados, não alegações de vulnerabilidade de fornecedores. benchmark corpus reclassifica o conjunto versionado em datasets/corpus, agrupa os resultados por vetor e também falha quando um caso ultrapassa seu orçamento de requisições.

A precedência é: padrões internos, arquivo YAML, variáveis SABBER_* e flags CLI. Veja config.example.yaml e .env.example. Nunca versione tokens, webhooks ou bancos de resultados.

.env.example é apenas uma referência: a ferramenta não carrega arquivos .env automaticamente. Defina as variáveis no processo ou no mecanismo de segredos do ambiente de execução.

Sem --config, o arquivo padrão é subdomainabber/config.yaml dentro do diretório de configuração do usuário, como %APPDATA%\subdomainabber\config.yaml no Windows ou ${XDG_CONFIG_HOME:-$HOME/.config}/subdomainabber/config.yaml no Linux.

no_color: false
discord_min_severity: medium

A saída humana da CLI, a ajuda, o progresso, os erros e as notificações são apresentados em PT-BR, sem opção de idioma. A estrutura JSON e os identificadores técnicos de classificações e evidências permanecem estáveis para automação; apenas os textos descritivos humanos são emitidos em PT-BR.

• assinaturas podem ficar desatualizadas ou produzir falsos positivos ou negativos;
• validação ativa real está limitada a Amazon S3 e Amazon Route 53;
• o motor grava uma tentativa preventiva antes de criar recursos e tenta reconciliá-la na execução agressiva seguinte; no Amazon S3, uma interrupção entre a criação do bucket e a gravação do objeto de prova ainda exige inspeção manual da conta;
• WAFs, CDNs, respostas DNS curinga e diferenças regionais podem alterar as observações;
• o benchmark local atual demonstra os invariantes do Mutator, mas não substitui medições contra versões reais de Nginx, HAProxy, Envoy, Traefik e Apache;
• MX/SRV/SPF/TXT/A/AAAA continuam candidatos até que exista um adaptador de criação, prova de controle e liberação para o provedor;
• algumas verificações dependem de conectividade e APIs de terceiros;
• consenso DNS requer pelo menos dois resolvedores clássicos e fica indisponível quando DoH está ativo;
• --timeout limita a operação de rede após a permissão do limitador de taxa; ele não é um prazo total para concluir todos os módulos de um host;
• apenas TAKEN_OVER, ZONE_CONTROL_CONFIRMED e resultados com prova ativa estruturada significam controle comprovado; as demais classificações representam achados para investigação.

go fmt ./...
go mod verify
go vet ./...
go run github.com/rhysd/actionlint/cmd/actionlint@v1.7.12 .github/workflows/ci.yml .github/workflows/release.yml
go run honnef.co/go/tools/cmd/staticcheck@v0.7.0 ./...
go run golang.org/x/vuln/cmd/govulncheck@v1.6.0 ./...
go test ./... -count=1
go test -race ./... -count=1
go run . fingerprints validate --strict
go run . benchmark synthetic
go run . benchmark corpus
go run . benchmark regression datasets/regression
go run . benchmark mutator
go build ./...

O detector de condições de corrida depende de CGO. No Windows, instale um compilador C compatível antes de executar go test -race; sem esse requisito, use o resultado da etapa equivalente da CI em Linux e não considere a validação local concluída.

Leia CONTRIBUTING.md antes de enviar mudanças. Vulnerabilidades no próprio projeto devem seguir SECURITY.md.

O código original do projeto é disponibilizado sob a MIT License com a Commons Clause License Condition v1.0. A Commons Clause restringe a venda do Software conforme a definição presente no texto da licença, tornando o projeto source-available.

A versão v0.1.0 e os commits publicados antes da adoção da Commons Clause permanecem sob os termos da licença MIT que os acompanhava. Consulte LICENSING.md para o histórico e o resumo dos termos.

O catálogo inclui material derivado sujeito aos avisos e às condições descritos em THIRD_PARTY_NOTICES.md.