Mecanismos de análise e cobertura

Os mecanismos do Plexicus e o que eles cobrem

O Plexicus pratica Proof-Driven AppSec: o AI Swarm Pentest valida o que é realmente explorável, o Deep Code Analysis explica o que um achado afeta e o Remediation prepara uma correção para a sua equipe revisar e fazer o merge. Os mecanismos de análise alimentam esse ciclo. Eles oferecem uma cobertura ampla e repetível do seu código, das suas dependências, da sua configuração e da sua cadeia de suprimentos. Trate cada alerta de um scanner como um candidato, não como prova: sem prova reproduzível, não há achado verificado.

Cada mecanismo do Plexicus é um pacote gerenciado: uma capacidade que você ativa ou desativa como uma unidade e que pode executar vários scanners por baixo. Cada achado registra no campo Tool o mecanismo que o gerou, por exemplo plexicus-sast ou plexicus-iac.

O catálogo de mecanismos

Mecanismo	O que ele procura	Exemplo típico
Plexicus SAST (`plexicus-sast`)	Vulnerabilidades no código, como falhas de injeção e padrões inseguros, com rastreamento do fluxo de dados	Um handler de login que concatena o nome de usuário em uma consulta SQL
Plexicus SCA (`plexicus-sca`)	Dependências de código aberto vulneráveis nos principais gerenciadores de pacotes, comparadas com fontes de CVE como o NVD e o banco de dados GitHub Security Advisory	Um parser XML desatualizado com um CVE publicado no seu lockfile
Plexicus Secrets (`plexicus-secrets`)	Credenciais, chaves de API e tokens embutidos no código, na árvore de trabalho e em todo o histórico do Git, com verificação em tempo real junto ao serviço emissor	Uma chave de acesso à nuvem incluída em um commit no ano passado, removida depois e que continua no histórico
Plexicus IaC (`plexicus-iac`)	Violações de políticas em Terraform, CloudFormation, Kubernetes, Helm, Ansible e templates ARM	Um bucket de armazenamento declarado com acesso público de leitura
Plexicus CI/CD (`plexicus-cicd`)	Configurações incorretas, permissões inseguras e credenciais expostas em definições de pipeline como GitHub Actions, GitLab CI e Azure Pipelines	Um workflow que concede ao seu token permissão de escrita em tudo
Plexicus Container (`plexicus-container`)	Configurações incorretas, imagens base inseguras e vulnerabilidades conhecidas nos Dockerfiles e nos artefatos de contêiner do repositório	Um Dockerfile construído sobre uma imagem base desatualizada com CVEs conhecidos
Plexicus License (`plexicus-license`)	Licenças copyleft, proprietárias ou desconhecidas nas dependências	Uma biblioteca copyleft dentro de um produto que você distribui
Plexicus SBOM, CBOM e AIBOM	Inventários, não achados com severidade: componentes de software (CycloneDX ou SPDX), ativos criptográficos com o seu nível de prontidão quântica, e modelos de IA, datasets e model cards	Um par de chaves RSA que o CBOM marca como vulnerável à computação quântica
Plexicus SCM (`plexicus-scm`)	Postura da cadeia de suprimentos e práticas SLSA: commits assinados, proveniência de artefatos, hardening do build	Uma branch padrão que aceita commits não assinados

Onde estiverem habilitados para a sua organização, mais dois mecanismos oferecem cobertura complementar além do repositório: o Plexicus Registry escaneia imagens em registros de contêiner conectados, e o Plexicus Cloud verifica as contas de nuvem conectadas em busca de configurações incorretas e de políticas IAM permissivas demais. Os dois alimentam o mesmo modelo de achados (lição 5).

Outros dois cards gerenciados pelo Plexicus ficam na categoria SAST: o Plexicus AI Scan, um mecanismo experimental baseado em IA que a Plexicus habilita por organização (módulo 5), e o GitHub SAST, que traz os alertas de code scanning do GitHub. A categoria também reúne o card SARIF Import e os cards de conectores comerciais (lição 3). O AI Swarm Pentest não é um mecanismo de repositório; ele aparece como AI Pentest na seção Pentest (módulo 6).

A disponibilidade depende do seu plano

SAST, SCA, Secrets e IaC não dependem do plano. Outros mecanismos, como Container, CI/CD, License, SCM, Registry, Cloud e AI Scan, dependem do seu plano. Quando o seu plano não inclui um mecanismo, o card dele abre um aviso de upgrade em vez de ativá-lo, e o backend aplica a mesma regra. Para os mecanismos que dependem do plano, um administrador pode solicitar uma mudança de plano em Settings Billing (módulo 10). O AI Scan é a exceção: a Plexicus o habilita sob solicitação (módulo 5).

Como escolher um conjunto para a sua organização e os seus repositórios

Comece pelo que os seus repositórios contêm. Alguns mecanismos podem ser definidos por repositório; outros valem para a organização inteira (lição 2).

Um serviço em Python ou Node.js: SAST, SCA e Secrets. Adicione CBOM se o código lida com criptografia.
Definições em Terraform, CloudFormation ou Helm: adicione IaC.
Definições de pipeline: adicione CI/CD.
Dockerfiles: Container, mais License para o risco de licenças. Os dois valem para a organização inteira.
Postura da cadeia de suprimentos: SCM, também para a organização inteira.
Evidências de inventário: SBOM, CBOM e AIBOM. O módulo 8 mostra como eles alimentam o XBOM.

Como configurar os scans

A organização define os mecanismos padrão, e cada repositório pode sobrescrever parte deles. Acerte os padrões primeiro e só sobrescreva onde um repositório for realmente diferente.

Padrões da organização na página Connectors

A página Connectors cataloga os mecanismos de análise e os conectores de ferramentas por categoria, de SAST, SCA e Secrets / PII Scan até CI/CD Posture, License e SCM Security. Abra /connector no seu host do Plexicus para acessá-la; inventários XBOM vazios também levam até ela com Go to Connectors. Controle de código-fonte, registros, contas de nuvem e ferramentas de tickets são conectados separadamente em Settings Integrations .

Abra o card de um mecanismo para ver o painel de configuração dele:

Aba	O que ela faz
Tool	A chave Enable ativa ou desativa o mecanismo para toda a organização. Somente no nível da organização.
Severity	Define quais severidades o Plexicus mantém para este mecanismo. O padrão é Medium, High & Critical.
Advanced Options	Parâmetros específicos do mecanismo, exibidos apenas nos mecanismos que os têm. Clique em Save para manter as alterações.

As alterações valem para os próximos scans.

Configurações por repositório

Para alterar os mecanismos de um único repositório, abra Assets Repo Scan Configure (o ícone de engrenagem na linha do repositório). O painel mostra só as categorias que podem ser definidas por repositório, como SAST, SCA, Secrets, IaC, CI/CD e os mecanismos de lista de materiais. Container, License e SCM são escolhas da organização inteira, feitas na página Connectors.

Em um repositório sem seleção própria, o painel abre com a seleção atual da organização e lista o que está “Enabled for this repository”. Ao salvar, essa lista vira uma cópia explícita para o repositório, e as mudanças posteriores nos padrões da organização deixam de chegar a ele. O console não tem um botão para redefinir; a volta à seleção da organização é feita pela API REST (módulo 9).

Use a chave no card de um mecanismo para ativá-lo ou desativá-lo neste repositório. Uma notificação confirma a ação, por exemplo “Plexicus IaC tool enabled for this repository”.
Os conectores que exigem credenciais abrem primeiro a configuração deles; a chave só continua ativada depois que o conector estiver configurado.
No console, a janela de detalhes do mecanismo mostra aqui apenas as abas Severity e Advanced Options, e as alterações feitas nelas valem para toda a organização. A API REST também permite definir parâmetros por repositório e um filtro de severidade para um único mecanismo.

Ao adicionar repositórios em Manage Repositories, Launch escaneia cada um com a seleção padrão de mecanismos da organização. Já Advanced Options abre “Configure Tools for Repository”, onde você escolhe os mecanismos de cada repositório antes de iniciar.

O filtro de severidade e os caminhos excluídos

A aba Severity define quais severidades o Plexicus mantém para aquele mecanismo. Os resultados fora da seleção são descartados depois do scan e nunca viram achados, então não é possível exibi-los mais tarde. O padrão, Medium, High & Critical, significa que os resultados Low e Informational não são reportados em nenhum mecanismo, a menos que você os adicione. Para ver os resultados Low, adicione Low e execute o scan de novo. Os mecanismos de lista de materiais geram inventários e ignoram essa configuração.

Os caminhos excluídos não têm um campo no console. Eles são parâmetros do pacote, definidos pelos endpoints de configuração de ferramentas da API REST (módulo 9), e são aceitos pela maioria dos mecanismos de código, mas não por Secrets, SCM, AIBOM nem CBOM.

Opções avançadas

Algumas opções específicas de mecanismo que você vai usar:

SAST: baseline_commit reporta apenas os problemas novos desde um determinado commit; exclude_rule desativa uma regra ruidosa.
SCA: fail_on define o bloqueio pelo código de saída; only_fixed mantém apenas os CVEs que têm correção.
Secrets: redact oculta os valores dos segredos na saída; include_detectors e exclude_detectors escolhem os detectores.
IaC: skip_check e skip_framework removem verificações ou frameworks inteiros; soft_fail reporta sem falhar. O card Plexicus CI/CD não tem a aba Advanced Options.

A chave Autonomous Scan para scans de pull requests fica em Settings Platform (lição 4).

Como trazer outros resultados

Muitas equipes já usam outros scanners ou recebem relatórios de testadores externos. Você não precisa escolher entre eles e o Plexicus. Traga a saída deles, e ela entra na mesma fila, com o mesmo enriquecimento e a mesma deduplicação dos achados nativos.

Upload Scan

O caminho mais direto é Findings Repo Upload Scan . O botão só existe na aba Repo.

Select repository: o repositório do Plexicus ao qual os resultados pertencem.
Select tool: SARIF genérico ou o formato de exportação de uma das ferramentas comerciais compatíveis de SAST, SCA ou testes dinâmicos; a lista mostra quais são.
Select file: o relatório gerado pela sua ferramenta.
Clique em Upload.

Quando o upload é aceito, você vê “Data uploaded successfully”. Em seguida, os resultados são processados como os de qualquer outro scan.

Importação de SARIF 2.1.0

O Plexicus aceita SARIF 2.1.0 de qualquer analisador compatível, seja pelo Upload Scan, seja pelo card SARIF Import na categoria SAST da página Connectors. A severidade é definida nesta ordem:

Dado do SARIF	Severidade no Plexicus
`security-severity` da regra igual ou maior que 9,0	Critical
`security-severity` igual ou maior que 7,0 e menor que 9,0	High
`security-severity` igual ou maior que 4,0 e menor que 7,0	Medium
`security-severity` menor que 4,0	Low
Sem `security-severity`: nível do resultado `error`	High
Nível do resultado `warning`	Medium
Nível do resultado `note` ou `none`	Low
Também não há nível do resultado	O nível padrão da regra, mapeado da mesma forma; Low se a regra não tiver um

Os identificadores CWE são lidos de tags como external/cwe/cwe-89, que depois orientam o mapeamento OWASP (lição 5). O Plexicus remove o prefixo file:// e a barra inicial de cada localização, então gere o SARIF com caminhos relativos à raiz do repositório. Caso contrário, o arquivo e a linha não vão corresponder ao seu código.

Conectores de scanners comerciais

A página Connectors também lista scanners comerciais. Alguns buscam os resultados pela API do fornecedor depois que você informa as credenciais do fornecedor no card. Outros recebem um arquivo de exportação enviado por upload, assim como o Upload Scan. O card GitHub SAST importa os alertas de code scanning do GitHub. A saída de testes dinâmicos de uma ferramenta de terceiros é independente do AI Swarm Pentest. Alguns conectores estão disponíveis apenas em determinados planos; entre em contato com a Plexicus para habilitar um deles.

Uploads a partir do CI

A API do Plexicus expõe a operação Upload Scan Results, que importa para um repositório os resultados gerados externamente. Um pipeline pode chamá-la com um token de API pessoal depois que os próprios scanners forem executados; o módulo 9 trata dos tokens e da API REST.

Como executar scans a partir do CI/CD

O Plexalyzer é o scanner do Plexicus. No CI, ele roda dentro do seu pipeline e envia os resultados para a sua organização no Plexicus, onde eles aparecem no dashboard e em Findings como os de qualquer outro scan. Há três formas de configurá-lo.

O Plexicus não inicia um scan a cada push por conta própria. Os novos scans vêm do seu pipeline de CI (incluindo os scans de pull requests), da adição de um repositório, do Relaunch scan no Activity Center ou do Re-Scan. Para escanear um repositório à medida que o código muda, configure o pipeline para ele.

O token do Plexalyzer

Toda execução do Plexalyzer se autentica com o token do Plexalyzer da organização, também chamado de token do scanner de CI/CD. Os administradores o gerenciam em Settings Plexalyzer Token . Em algumas versões, o mesmo token aparece na seção do token do scanner de CI/CD em Settings API Tokens . Você pode criar um token com um Token Name e uma Expired Date opcional, copiá-lo e excluí-lo. O token com o selo Default não pode ser excluído enquanto houver outros tokens. Excluir um token quebra todos os pipelines que ainda o usam.

Este token pertence à organização e é usado apenas pelo scanner Plexalyzer, não em chamadas gerais à API. Os tokens de API pessoais para scripts e para o servidor MCP, assim como o token da CLI, são diferentes (módulo 9).

Setup Pipeline a partir de Assets

O caminho mais rápido começa em Assets Repo Scan . A coluna Pipeline oferece Setup Pipeline para repositórios do GitHub, GitLab, Gitea, Forgejo e Bitbucket Cloud; os outros provedores mostram Not Available.

Clique em Setup Pipeline e confirme.
O Plexicus abre no seu repositório um pull request que adiciona o workflow do Plexalyzer. No GitHub, esse arquivo é .github/workflows/plexalyzer-scan.yml, e o Plexicus armazena o token como o segredo de repositório PLEXALYZER_TOKEN.
A coluna mostra Pipeline Pending até o pull request ser aceito e, depois, Pipeline Configured.

Nada roda no seu CI até que alguém da sua equipe revise e faça o merge desse pull request. A sua equipe mantém o controle do merge.

A Plexicus GitHub Action configurada manualmente

Se você mesmo escrever o workflow, use a action oficial plexicus/plexicus-action (listada como Plexalyzer Action no site da Plexicus), que executa o scanner no seu workflow e pode reportar os achados no pull request.

Copie o token do Plexalyzer no Plexicus.
No GitHub, adicione um segredo de repositório chamado PLEXALYZER_TOKEN em Secrets and variables, Actions, no repositório.
Adicione a variável de repositório com o ID do seu repositório no Plexicus, conforme descrito no README da action.
Passe o segredo para o input plexalyzer-token, junto com repo-id, repo-name, branch, url, pr-id e workspace-path.

Se a sua organização ativar o Autonomous Scan em Settings Platform , um scan de pull request concluído pelo pipeline publica um comentário “Analysis Results” no pull request (ou “No issues found”), quando o seu provedor de controle de código-fonte oferece suporte a comentários em pull requests. Em seguida, o Plexicus gera correções com IA para esses achados e abre um único pull request combinado, intitulado “Multiple security fixes”, a partir de uma nova branch Plexicus-AI-Remediation-. Ele nunca faz o merge; a sua equipe o revisa como qualquer outro pull request.

Jenkins

A integração com o Jenkins executa a imagem Docker da CLI do Plexalyzer, então o agente de build precisa ter Docker. Adicione o token como uma credencial do Jenkins do tipo Secret text com o ID exato plexalyzer-token. Copie Jenkinsfile, .plexalyzer/jenkins-plexalyzer-cli.groovy e .plexalyzer/custom_config.yml do repositório plexicus/jenkins-cli-pipeline e, em seguida, crie um job do tipo Pipeline que use Pipeline script from SCM.

Escolha os mecanismos em custom_config.yml pelos nomes dos pacotes:

# .plexalyzer/custom_config.yml
excluded_tools:
  - plexicus-iac   # não há código de infraestrutura neste repositório
  - plexicus-cicd

Use included_tools em vez disso para restringir um scan a um conjunto fixo. Parâmetros de build úteis:

Parâmetro	Finalidade
`PROJECT_NAME`, `BRANCH_NAME`	Nome do repositório e rótulo da branch exibidos no Plexicus
`REPOSITORY_ID`	ID de um repositório existente; deixe em branco no primeiro scan
`OUTPUT_FORMAT`	`pretty`, `json` ou `sarif`; JSON e SARIF também são arquivados como artefatos do build
`ONLY_GIT_CHANGES`	Escaneia apenas os arquivos alterados no último commit; exige uma profundidade de checkout de 2 ou mais
`PLEXICUS_URL`	A URL base do seu Plexicus, para implantações auto-hospedadas

O código de saída 0 significa que não há achados, e o 1 significa que foram detectados achados. Os dois marcam o build como Success, então, por padrão, os achados nunca bloqueiam a entrega. O código de saída 500 é um erro fatal, como um token rejeitado ou um backend inacessível. Para fazer o build falhar quando houver achados, edite handleExitCode() no script do pipeline e faça o case 1 definir o resultado do build como FAILURE.

Um único modelo de achados

Seja qual for a origem (um mecanismo do Plexicus, uma execução de CI, o Upload Scan, um conector, um registro ou uma conta de nuvem), cada resultado acaba em um modelo de achados comum, para que você possa filtrar, priorizar e gerar relatórios sobre todos eles de uma só vez.

Normalização

Um processador específico para cada ferramenta lê a saída bruta de cada scanner (JSON, SARIF, CSV ou XML) e a grava no esquema comum: ferramenta, ID da regra, título, descrição, arquivo, linha e colunas, CWE e uma severidade em cinco níveis: Critical, High, Medium, Low e Informational. O Activity Center mostra isso como “Processing results” (“Normalizing and ingesting findings”), depois Completed e, em seguida, “Enriched” (“AI analysis and prioritization applied”). Em uma execução marcada como Partial, algumas ferramentas falharam. Os achados dela são reais, mas a cobertura está incompleta; use Relaunch scan no Activity Center para escanear de novo e manter os seus achados (módulo 2).

Cada achado também recebe um tipo derivado do seu mecanismo, como SAST, SCA, Secrets, License, Configuration ou Cryptography. Os achados de Container recebem o tipo SCA quando têm um CVE ou um pacote, e Configuration nos demais casos. Os resultados importados como SARIF recebem o tipo SAST.

Enriquecimento

Campo	O que ele acrescenta
CWE e OWASP	Os achados com CWE são mapeados para uma categoria do OWASP Top 10 com uma breve justificativa, por exemplo CWE-89 em A03 Injection. Os achados também são mapeados para o OWASP CI/CD Top 10 e para os frameworks de compliance que você habilitou.
CVE e EPSS	O EPSS, a probabilidade de um CVE ser explorado em ambientes reais, só é preenchido nos achados com CVE. Os demais mostram No data.
CVSS	Pontuação e vetor do CVSS v3 e v4, disponíveis como colunas da tabela.
Prioridade e mais	Uma pontuação de prioridade de 0 a 100, a linguagem e o tipo de remediação. O módulo 4 explica a prioridade e a alcançabilidade.

O SARIF 2.1.0 também é o formato de exportação dos achados; o módulo 8 trata das exportações e do que elas incluem.

Deduplicação

Um novo achado é marcado como Duplicate de um achado anterior do mesmo repositório quando está no mesmo arquivo e na mesma linha e, além disso, compartilha o CVE e o CWE (achados de dependências) ou tem o mesmo tipo de achado (achados de código sem CVE). O achado que permanece herda a pior severidade e o pior CVSS das suas duplicatas, então a deduplicação nunca subestima o risco.

Subachados

Os achados de dependências com a mesma biblioteca, versão e CVE no mesmo local são agrupados como subachados sob um achado principal. A tela de detalhes de um subachado mostra Go to Parent Finding no lugar do seu próprio botão de remediação. Por padrão, a lista de achados oculta as duplicatas, os subachados, os falsos positivos, os achados excluídos e os achados que ainda estão sendo enriquecidos (módulo 4); os totais do Dashboard são abordados no módulo 2.

Registros e contas de nuvem como fontes complementares

Dependendo do seu plano e dos provedores habilitados para a sua organização, os registros e as contas de nuvem oferecem uma cobertura complementar que chega ao mesmo modelo de achados. Os registros de contêiner são conectados em Settings Integrations Registry : Docker Hub, JFrog Artifactory, Amazon ECR, Google GCR, Google GAR, Azure ACR, GitHub GHCR, GitLab Container Registry e Quay.io. Informe as credenciais na aba Setup e clique em Connect; o Plexicus testa a conexão antes de salvar. Na aba List, use Discover images e depois Scan images. A partir daí, o Plexicus ressincroniza cada registro conectado uma vez por dia, então use esses botões apenas quando precisar de uma atualização imediata. As imagens cujo Lifecycle é Old recebem um achado Medium “Outdated registry image”. Use Link to repo com o caminho de um Dockerfile para vincular uma imagem ao código-fonte dela, o que habilita Remediate in repo. Os resultados aparecem na aba Registry de Findings.

As contas de nuvem são adicionadas em Settings Integrations Cloud Deployment , que lista os provedores de nuvem compatíveis, como AWS, Azure e Google Cloud Platform. Salvar uma conta cria um ativo em Assets Cloud Assessment ; Scan Now executa o scan, e os resultados aparecem na aba Cloud com os filtros Provider, Region e Resource. Os achados de nuvem e de SCM nunca oferecem remediação com IA, porque não há um arquivo de repositório para corrigir.

Principais pontos

Os mecanismos são pacotes gerenciados. Defina os padrões da organização na página Connectors e sobrescreva por repositório, com Configure, os mecanismos SAST, SCA, Secrets, IaC, CI/CD e de lista de materiais; Container, License e SCM continuam valendo para a organização inteira.
Salvar uma seleção por repositório executa um Re-Scan que apaga os achados desse repositório, e as alterações em Severity e Advanced Options feitas no console valem para toda a organização.
O filtro Severity descarta resultados depois do scan, então, por padrão, os resultados Low e Informational não são reportados em nenhum mecanismo; os scans de código já ignoram caminhos comuns de testes e de documentação, exceto no caso de segredos.
Upload Scan, a importação de SARIF 2.1.0 e os conectores comerciais trazem resultados externos para o mesmo modelo, como candidatos que ainda precisam de prova.
No CI, toda execução do Plexalyzer se autentica com o token do Plexalyzer da organização; o Setup Pipeline abre um pull request que a sua equipe revisa, e os builds do Jenkins passam mesmo com achados, a menos que você altere handleExitCode().
Todo resultado, seja qual for a origem, é normalizado, enriquecido com CWE, OWASP, CVE, EPSS e CVSS, deduplicado mantendo a pior severidade e agrupado em subachados.