SAST scans
Varre o repositório para localizar injection, XSS, autorização ausente, segredos expostos e outros padrões inseguros antes da execução.
Este guia reúne o fluxo de Repository view, re-scan, classificação DAST/SAST/SCA, recomendações com IA local, gestão de acessos, integrações e proteção de credenciais com Vault.
Varre o repositório para localizar injection, XSS, autorização ausente, segredos expostos e outros padrões inseguros antes da execução.
Mapeia bibliotecas, versões instaladas e CVEs para priorizar atualização, mitigação ou troca do componente afetado.
Valida endpoints e superfícies web em execução para detectar headers inseguros, XSS refletido, CSRF e outros sinais visíveis em runtime.
Compara o novo scan com a baseline para mostrar o que foi resolvido, o que persiste e o que reapareceu como regressão.
Selecione o repositório, rode o scan completo e use o re-scan para comparar a execução atual com a baseline anterior.
Abra um finding, gere recomendação local com IA, marque como resolvido ou aceite o risco com rastreabilidade.
Conecte Snyk, Slack e provedores SCM, sincronize catálogos e importe apenas os repositórios que o tenant pode processar.
O processamento roda localmente e as credenciais ficam protegidas na Vault, sem envio do código para cloud externa ou IA pública.
Para dúvidas operacionais, incidentes de acesso, onboarding de tenants ou necessidade de apoio na execução de scans, entre em contato pelo e-mail abaixo.
contato@loglan.com.brAs respostas abaixo seguem o comportamento atual do produto. Onde o modelo é por papéis do tenant, isso está descrito explicitamente para não confundir com um recurso de grupos independentes.
Como iniciar análises e interpretar o diff entre uma baseline e a execução mais recente.
No dashboard autenticado, abra o quadrante Repository view, selecione o repositório e o branch desejado e use o botão Trigger scan completo. O pipeline executa SAST, SCA e DAST e publica os findings no scan selecionado.
Use o Trigger re-scan quando quiser comparar um novo processamento com uma baseline já existente. O serviço de re-scan classifica o diff em RESOLVED, PERSISTENT e REGRESSION para facilitar priorização de correções e validação de regressões.
Os findings aparecem por scan e também nos indicadores consolidados do tenant. Cada item traz severidade, OWASP, status, origem do scan e metadados técnicos para separar claramente DAST, SAST e SCA.
O painel organiza as vulnerabilidades por origem para diferenciar análise estática, dependências e comportamento em runtime.
SAST representa a análise estática do código-fonte. Os findings normalmente incluem arquivo, trecho de código, linha afetada, CWE, OWASP e sugestão de remediação técnica.
SCA cobre componentes de terceiros e bibliotecas do projeto. Os findings destacam pacote, versão instalada, versão fixa sugerida, CVE associada e impacto da dependência vulnerável.
DAST valida o comportamento da aplicação em execução. Os findings tendem a refletir problemas observáveis em endpoints, headers, cookies, CSRF e superfícies web expostas.
No detalhe da vulnerabilidade, o AppScan exibe descrição, remediação base e, quando solicitado, uma recomendação gerada localmente pela IA. O conteúdo é ajustado ao contexto do finding, independentemente de ser DAST, SAST ou SCA.
Fluxo para gerar orientação de correção, registrar tratamento e transferir o contexto para times operacionais.
Abra o Vulnerability details do finding e use a ação de gerar recomendação. O AppScan consulta o motor local de IA e grava a sugestão para consulta posterior no próprio detalhe do finding.
No mesmo detalhe da vulnerabilidade, use Mark as resolved quando a correção já estiver aplicada, ou Accept risk quando a exceção precisar ser formalizada. Esses estados passam a compor os KPIs e o diff de re-scan.
O AppScan facilita o handoff montando um texto pronto com severidade, OWASP, origem, descrição e recomendação. Você pode copiar a descrição preparada e colar diretamente no Jira, ServiceNow ou outra fila ITSM do processo interno.
O modelo atual é RBAC por tenant, com papéis operacionais claros para administração, desenvolvimento e auditoria.
Na implementação atual, o AppScan trabalha com papéis por tenant em vez de grupos independentes. Os papéis disponíveis são ADMIN, DEV e AUDITOR, e cada papel define quais ações o usuário pode executar no dashboard e nas APIs.
Usuários com papel ADMIN acessam a área Gestão de acessos, informam nome, e-mail e papel do novo membro e enviam o convite. O destinatário recebe token por e-mail para concluir o acesso ao tenant.
O isolamento é feito por tenant e reforçado por papéis. ADMIN gerencia integrações, convites e configurações; DEV executa scans e trata findings; AUDITOR consulta resultados, recomendações e trilhas de evidência sem alterar configurações administrativas.
Como conectar ferramentas externas, armazenar tokens e sincronizar catálogos de repositórios de forma controlada.
Na seção Integrações, crie ou edite a conexão correspondente e informe o token do provedor. O token fica armazenado de forma segura e a conexão passa a ser usada para enriquecimento de findings, automações ou notificações.
Depois de cadastrar a conexão SCM, sincronize o catálogo de repositórios e selecione apenas o repositório desejado. A importação respeita o escopo configurado para o tenant, como público, privado ou ambos.
Sempre que você abre ou sincroniza uma conexão, o AppScan consulta o provedor configurado para listar os repositórios disponíveis. A partir daí, o operador escolhe o que será efetivamente trazido para o tenant.
Princípios de execução local para ambientes com restrição de dados e exigência de controle sobre credenciais.
Os serviços de scan e recomendação executam na stack local do AppScan. O código, os metadados e os findings ficam dentro do ambiente controlado do cliente, sem necessidade de compartilhar o repositório com uma IA pública ou com cloud externa.
Tokens e segredos operacionais são mantidos com apoio da Vault, que centraliza o armazenamento seguro das credenciais usadas nas integrações e nos serviços internos.
Não no fluxo previsto desta implantação. A proposta é on-premise e com IA local, justamente para atender requisitos de compliance, soberania de dados e restrição de compartilhamento com serviços externos.