Execute scans dentro da rede. Sem VPN, jump hosts ou portas de entrada.
O agente Sentinel inicia a conexão de saída via gRPC com mTLS e abre um túnel. Todos os analisadores da WASViking são executados contra os seus alvos internos por esse túnel, sem código específico por analisador e sem nenhuma concessão de arquitetura no lado da nuvem.
O DAST em nuvem não alcança as suas aplicações internas. A maioria das soluções de contorno piora a situação.
Expor aplicações internas por VPN, proxy reverso ou allow list de IP estático cria uma nova superfície de ataque e uma nova carga operacional. Instalar um appliance on-premise pesado, com portas de entrada, troca a cegueira nos scans por uma brecha no firewall.
O Sentinel segue o padrão oposto: um pequeno agente em Go, instalado pelo cliente, que abre um túnel mTLS de saída até a WASViking. Sem portas de entrada. Sem IPs estáticos. Sem allow list no lado da WASViking também.
# Execute no host do cliente (Linux, systemd)
$ ./wasviking-sentinel register --org acme --token wv_join_*****
[sentinel] Generating client certificate (mTLS) on this host...
[sentinel] Binding to org: acme
[sentinel] Registered. Tunnel handshake: OK
$ sudo systemctl enable --now wasviking-sentinel
● wasviking-sentinel.service - active (running)
NoNewPrivileges=true
ProtectSystem=strict
MemoryDenyWriteExecute=true
[sentinel] Tunnel established to sentinel.wasviking.com
O mesmo scanner. O mesmo formato de achado. Apenas roteado pelo túnel.
Cada analisador dinâmico roteia as suas sondagens HTTP pelo transporte do túnel de forma transparente. Os analisadores de SQLi, XSS, JWT, GraphQL, SOAP, WebSocket e de classes de injeção não precisam de código específico para o túnel. O túnel é uma propriedade da plataforma, não um recurso de um scanner.
Transporte e ciclo de vida do certificado
mTLS terminado no proxy com o certificado de cliente encaminhado por header (compatível com AWS ALB) e, depois, h2c simples no loopback interno. Vínculo com a organização pelo CN/O do certificado. O certificado de cliente é gerado no host do cliente no primeiro registro e nunca sai dele: mTLS fim a fim, do agente ao tenant. Rotacione ou revogue em Sentinel Agents no portal com um clique, com histórico completo de uso por agente.
Hardening do agente
Unit do systemd com NoNewPrivileges, ProtectSystem=strict, MemoryDenyWriteExecute, syscalls restritas. Releases assinadas com cosign. Build enterprise ofuscado opcional.
Privacidade perante o operador
Mascaramento estrito de secrets na camada de serviço gRPC. O servidor nunca registra em log o proto, o job ou a resposta completos, de modo que cookies, tokens CSRF e corpos de alvos internos não vazam para os logs do operador.
Mais do que DAST interno. O Sentinel é a borda on-premise da plataforma.
Scans de aplicações internas
Execute qualquer analisador da WASViking contra hosts internos. O formato do achado é idêntico ao de um scan externo, com rastreabilidade clara até o agente e o host que o produziram.
Ver cobertura de DASTSBOM no ambiente do cliente
O wasviking-sentinel sbom percorre os manifestos de build e envia ao seu tenant o CycloneDX 1.5 enriquecido com OSV e CISA KEV. A base para o gate de CI/CD e para o Evidence Bundle.
Descoberta local de secrets
O wasviking-sentinel secrets percorre o sistema de arquivos e o histórico do git. Os secrets brutos nunca saem do agente. Apenas o hash SHA-256 e a prévia mascarada chegam à WASViking.
Gate de CI/CD
wasviking-sentinel ci --sca, --secrets e --template para políticas de scan no escopo da organização. Exit codes determinísticos que o pipeline já entende.