Scanning engines and coverage

Plexicus engines and what they cover

Plexicus practices Proof-Driven AppSec: AI Swarm Pentest validates what is actually exploitable, Deep Code Analysis explains what a finding affects, and Remediation prepares a fix your team reviews and merges. Scanning engines feed that loop. They give you broad, repeatable coverage of your code, dependencies, configuration and supply chain. Treat a scanner hit as a candidate, not as proof: no reproducible proof, no verified finding.

Each Plexicus engine is a managed bundle: one capability you switch on or off as a unit, which may run several underlying scanners. Every finding records the engine that produced it in its Tool field, for example plexicus-sast or plexicus-iac.

The engine catalog

Engine	What it looks for	Typical example
Plexicus SAST (plexicus-sast)	Code vulnerabilities such as injection flaws and unsafe patterns, with dataflow tracing	A login handler that concatenates the username into a SQL query
Plexicus SCA (plexicus-sca)	Vulnerable open-source dependencies across the major package managers, matched against CVE sources such as NVD and the GitHub Security Advisory database	An outdated XML parser with a published CVE in your lockfile
Plexicus Secrets (plexicus-secrets)	Hardcoded credentials, API keys and tokens in the working tree and across Git history, with live verification against the issuing service	A cloud access key committed last year, deleted later, still in history
Plexicus IaC (plexicus-iac)	Policy violations in Terraform, CloudFormation, Kubernetes, Helm, Ansible and ARM templates	A storage bucket declared with public read access
Plexicus CI/CD (plexicus-cicd)	Misconfigurations, insecure permissions and exposed credentials in pipeline definitions such as GitHub Actions, GitLab CI and Azure Pipelines	A workflow that grants its token write access to everything
Plexicus Container (plexicus-container)	Misconfigurations, insecure base images and known vulnerabilities in the Dockerfiles and container artifacts in the repository	A Dockerfile built on an outdated base image with known CVEs
Plexicus License (plexicus-license)	Copyleft, proprietary or unknown licenses across dependencies	A copyleft library inside a product you distribute
Plexicus SBOM, CBOM and AIBOM	Inventories rather than graded findings: software components (CycloneDX or SPDX), cryptographic assets with quantum readiness, and AI models, datasets and model cards	An RSA key pair the CBOM marks as quantum-vulnerable
Plexicus SCM (plexicus-scm)	Supply-chain posture and SLSA practices: signed commits, artifact provenance, build hardening	A default branch that accepts unsigned commits

Where enabled for your organization, two more engines add supporting coverage beyond the repository: Plexicus Registry scans images in connected container registries, and Plexicus Cloud checks connected cloud accounts for misconfigurations and over-broad IAM policies. Both feed the same finding model (lesson 5).

Two other Plexicus-managed cards sit in the SAST category: Plexicus AI Scan, an experimental AI-driven engine that Plexicus enables per organization (module 5), and GitHub SAST, which brings in GitHub code-scanning alerts. The category also holds SARIF Import and commercial connector cards (lesson 3). AI Swarm Pentest is not a repository engine; it appears as AI Pentest under the Pentest section (module 6).

Availability depends on your plan

SAST, SCA, Secrets and IaC are not plan-gated. Other engines, such as Container, CI/CD, License, SCM, Registry, Cloud and AI Scan, depend on your plan. When your plan does not include an engine, its card opens an upgrade prompt instead of turning on, and the backend enforces the same rule. For gated engines, an admin can request a plan change under Settings Billing (module 10). AI Scan is the exception: Plexicus enables it on request (module 5).

Picking a set for your organization and repositories

Start from what your repositories contain. Some engines can be set per repository; others apply organization-wide (lesson 2).

• A Python or Node.js service: SAST, SCA and Secrets. Add CBOM if the code handles cryptography.
• Terraform, CloudFormation or Helm definitions: add IaC.
• Pipeline definitions: add CI/CD.
• Dockerfiles: Container, plus License for license risk. Both are organization-wide.
• Supply-chain posture: SCM, also organization-wide.
• Inventory evidence: SBOM, CBOM and AIBOM. Module 8 covers how these feed the XBOM.

Configuring scans

The organization sets engine defaults, and each repository can override some of them. Get the defaults right first, then override only where a repository really differs.

Organization defaults on the Connectors page

The Connectors page catalogs the scanning engines and tool connectors by category, from SAST, SCA and Secrets / PII Scan to CI/CD Posture, License and SCM Security. Open /connector on your Plexicus host to reach it; empty XBOM inventories also link to it with Go to Connectors. Source control, registries, cloud accounts and ticketing are connected separately under Settings Integrations .

Open an engine card to see its configuration panel:

Tab	What it does
Tool	The Enable switch turns the engine on or off for the whole organization. Organization level only.
Severity	Chooses which severities Plexicus keeps for this engine. The default is Medium, High & Critical.
Advanced Options	Engine-specific parameters, shown only for engines that have them. Click Save to keep changes.

Changes apply to future scans.

Per-repository overrides

To change engines for one repository, open Assets Repo Scan Configure (the gear icon on the repository row). The panel shows only the categories you can set per repository, such as SAST, SCA, Secrets, IaC, CI/CD and the bill-of-materials engines. Container, License and SCM are organization-wide choices that you make on the Connectors page.

For a repository without its own selection, the panel opens with your organization’s current selection and lists what is “Enabled for this repository”. When you save, that list becomes an explicit copy for the repository, and later changes to the organization defaults no longer reach it. The console has no reset button; reverting to the organization selection is done through the REST API (module 9).

• Use the toggle on an engine card to enable or disable it for this repository. A toast confirms, for example “Plexicus IaC tool enabled for this repository”.
• Connectors that need credentials open their configuration first; the toggle stays on only once the connector is configured.
• In the console, the engine’s detail window here shows only the Severity and Advanced Options tabs, and changes there apply to the whole organization. The REST API can also set per-repository parameters and a severity filter for one engine.

When you add repositories in Manage Repositories, Launch scans each one with your organization’s default engine selection. Advanced Options instead opens “Configure Tools for Repository”, where you pick engines for each repository before launching.

The severity filter and exclude paths

The Severity tab sets which severities Plexicus keeps for that engine. Results outside the selection are dropped after the scan and never become findings, so you cannot reveal them later. The default, Medium, High & Critical, means Low and Informational results are not reported for any engine unless you add them. To see Low results, add Low and relaunch the scan. Bill-of-materials engines produce inventories and ignore this setting.

Exclude paths have no field in the console. They are bundle parameters set through the tools-configuration endpoints of the REST API (module 9), supported by most code engines but not by Secrets, SCM, AIBOM or CBOM.

Advanced options

A few engine-specific options you will use:

• SAST: baseline_commit reports only issues new since a given commit; exclude_rule switches off a noisy rule.
• SCA: fail_on sets exit-code gating; only_fixed keeps only CVEs with a fix.
• Secrets: redact hides secret values in output; include_detectors and exclude_detectors choose detectors.
• IaC: skip_check and skip_framework drop checks or whole frameworks; soft_fail reports without failing. The Plexicus CI/CD card has no Advanced Options tab.

The Autonomous Scan toggle for pull-request scans lives in Settings Platform (lesson 4).

Bringing in other results

Many teams already run other scanners, or receive reports from external testers. You don’t need to choose between them and Plexicus. Bring their output in, and it joins the same queue, the same enrichment and the same deduplication as native findings.

Upload Scan

The most direct route is Findings Repo Upload Scan . The button is only on the Repo tab.

1. Select repository: the Plexicus repository the results belong to.
2. Select tool: generic SARIF, or the export format of one of the supported commercial SAST, SCA or dynamic-testing tools; the list shows which.
3. Select file: the report your tool produced.
4. Click Upload.

When the upload is accepted you see “Data uploaded successfully”. The results are then processed like any other scan.

SARIF 2.1.0 import

Plexicus accepts SARIF 2.1.0 from any compatible analyzer, either through Upload Scan or through the SARIF Import card in the SAST category of the Connectors page. Severity is resolved in this order:

SARIF data	Plexicus severity
Rule security-severity of 9.0 or more	Critical
security-severity of 7.0 or more, below 9.0	High
security-severity of 4.0 or more, below 7.0	Medium
security-severity below 4.0	Low
No security-severity: result level error	High
Result level warning	Medium
Result level note or none	Low
No result level either	The rule’s default level, mapped the same way; Low if the rule has none

CWE identifiers are read from tags such as external/cwe/cwe-89, which later drive the OWASP mapping (lesson 5). Plexicus strips a file:// prefix and a leading slash from each location, so produce SARIF with paths relative to the repository root. Otherwise file and line will not line up with your code.

Commercial scanner connectors

The Connectors page also lists commercial scanners. Some pull results over the vendor’s API once you enter the vendor credentials on the card. Others take an uploaded export file, the same as Upload Scan. The GitHub SAST card ingests GitHub code-scanning alerts. Dynamic-testing output from a third-party tool is separate from AI Swarm Pentest. Some connectors are available only on certain plans; contact Plexicus to enable one.

Uploads from CI

The Plexicus API exposes an Upload Scan Results operation that ingests externally produced results for a repository. A pipeline can call it with a personal API token after its own scanners run; module 9 covers tokens and the REST API.

Running scans from CI/CD

Plexalyzer is the Plexicus scanner. In CI it runs inside your pipeline and sends results to your Plexicus organization, where they show up in the dashboard and in Findings like any other scan. You have three ways to set it up.

Plexicus does not start a scan on every push by itself. New scans come from your CI pipeline (including pull-request scans), from adding a repository, from Relaunch scan in the Activity Center or from Re-Scan. To scan a repository as its code changes, set up the pipeline for it.

The Plexalyzer token

Every Plexalyzer run authenticates with the organization’s Plexalyzer token, also called the CI/CD scanner token. Admins manage it under Settings Plexalyzer Token . In some releases the same token appears as the CI/CD scanner token section of Settings API Tokens . You can create a token with a Token Name and an optional Expired Date, copy it, and delete it. The token badged Default cannot be deleted while other tokens exist. Deleting a token breaks every pipeline still using it.

This token belongs to the organization and is used only by the Plexalyzer scanner, not for general API calls. Personal API tokens for scripts and the MCP server, and the CLI token, are different (module 9).

Setup Pipeline from Assets

The fastest path starts in Assets Repo Scan . The Pipeline column offers Setup Pipeline for GitHub, GitLab, Gitea, Forgejo and Bitbucket Cloud repositories; other providers show Not Available.

1. Click Setup Pipeline and confirm.
2. Plexicus opens a pull request in your repository that adds the Plexalyzer workflow. On GitHub this is .github/workflows/plexalyzer-scan.yml, and Plexicus stores the token as the repository secret PLEXALYZER_TOKEN.
3. The column reads Pipeline Pending until the pull request is accepted, then Pipeline Configured.

Nothing runs in your CI until someone on your team reviews and merges that pull request. Your team keeps merge control.

The Plexicus GitHub Action by hand

If you write the workflow yourself, use the official action plexicus/plexicus-action (listed as the Plexalyzer Action on the Plexicus site), which runs the scanner in your workflow and can report findings on the pull request.

1. Copy the Plexalyzer token from Plexicus.
2. In GitHub, add a repository secret named PLEXALYZER_TOKEN under the repository’s Secrets and variables, Actions.
3. Add the repository variable for your Plexicus repository ID, as described in the action’s README.
4. Pass the secret to the plexalyzer-token input, together with repo-id, repo-name, branch, url, pr-id and workspace-path.

If your organization turns on Autonomous Scan under Settings Platform , a completed pull-request scan from the pipeline posts an “Analysis Results” comment on the pull request (or “No issues found”), where your source-control provider supports pull-request comments. Plexicus then generates AI fixes for those findings and opens one combined pull request titled “Multiple security fixes” from a new Plexicus-AI-Remediation- branch. It never merges; your team reviews it like any other pull request.

Jenkins

The Jenkins integration runs the Plexalyzer CLI Docker image, so the build agent needs Docker. Add the token as a Jenkins credential of kind Secret text with the exact ID plexalyzer-token. Copy Jenkinsfile, .plexalyzer/jenkins-plexalyzer-cli.groovy and .plexalyzer/custom_config.yml from the plexicus/jenkins-cli-pipeline repository, then create a Pipeline job that uses Pipeline script from SCM.

Choose engines in custom_config.yml with bundle names:

# .plexalyzer/custom_config.yml
excluded_tools:
  - plexicus-iac   # no infrastructure code in this repository
  - plexicus-cicd

Use included_tools instead to restrict a scan to a fixed set. Useful build parameters:

Parameter	Purpose
PROJECT_NAME, BRANCH_NAME	Repository name and branch label shown in Plexicus
REPOSITORY_ID	Existing repository ID; leave blank on the first scan
OUTPUT_FORMAT	pretty, json or sarif; JSON and SARIF are also archived as build artifacts
ONLY_GIT_CHANGES	Scan only files changed in the last commit; needs a checkout depth of 2 or more
PLEXICUS_URL	Your Plexicus base URL, for self-hosted deployments

Exit code 0 means no findings and 1 means findings were detected. Both mark the build Success, so findings never block delivery by default. Exit code 500 is a fatal error, such as a rejected token or an unreachable backend. To fail the build on findings, edit handleExitCode() in the pipeline script and make case 1 set the build result to FAILURE.

One finding model

Whatever the source (a Plexicus engine, a CI run, Upload Scan, a connector, a registry or a cloud account), every result ends up in one common finding model, so you can filter, prioritize and report across all of them at once.

Normalization

A per-tool processor reads each scanner’s raw output (JSON, SARIF, CSV or XML) and writes it into the common schema: tool, rule ID, title, description, file, line and columns, CWE, and a severity on five levels: Critical, High, Medium, Low and Informational. The Activity Center shows this as “Processing results” (“Normalizing and ingesting findings”), then Completed, then “Enriched” (“AI analysis and prioritization applied”). A run marked Partial had some tools fail. Its findings are real, but coverage is incomplete; use Relaunch scan in the Activity Center to scan again and keep your findings (module 2).

Each finding also gets a type derived from its engine, such as SAST, SCA, Secrets, License, Configuration or Cryptography. Container findings are typed SCA when they carry a CVE or package, and Configuration otherwise. Results imported as SARIF are typed SAST.

Enrichment

Field	What it adds
CWE and OWASP	Findings with a CWE are mapped to an OWASP Top 10 category with a short rationale, for example CWE-89 under A03 Injection. Findings are also mapped to the OWASP CI/CD Top 10 and to your enabled compliance frameworks.
CVE and EPSS	EPSS, the probability that a CVE is exploited in the wild, is filled in only for findings with a CVE. Others show No data.
CVSS	CVSS v3 and v4 score and vector, available as table columns.
Priority and more	A 0 to 100 priority score, language and remediation type. Module 4 explains priority and reachability.

SARIF 2.1.0 is also the export format for findings; module 8 covers exports and what they include.

Deduplication

A new finding becomes a Duplicate of an earlier one in the same repository when it sits at the same file and line, and it either shares the CVE and CWE (dependency findings) or has the same finding type (code findings without a CVE). The surviving finding inherits the worst severity and CVSS of its duplicates, so deduplication never understates risk.

Sub-findings

Dependency findings for the same library, version and CVE at the same location are grouped under a main finding as sub-findings. A sub-finding’s detail view shows Go to Parent Finding instead of its own remediation button. By default the findings list hides duplicates, sub-findings, false positives, deleted findings and findings still being enriched (module 4); Dashboard totals are covered in module 2.

Registries and cloud accounts as supporting sources

Depending on your plan and the providers enabled for your organization, registries and cloud accounts add supporting coverage that lands in the same finding model. Container registries are connected in Settings Integrations Registry : Docker Hub, JFrog Artifactory, Amazon ECR, Google GCR, Google GAR, Azure ACR, GitHub GHCR, GitLab Container Registry and Quay.io. Enter the credentials on the Setup tab and click Connect; Plexicus tests the connection before saving. On the List tab, use Discover images, then Scan images. After that, Plexicus re-syncs every connected registry once a day, so use these buttons only when you need an immediate refresh. Images whose Lifecycle is Old get a Medium “Outdated registry image” finding. Use Link to repo with a Dockerfile path to tie an image to its source, which enables Remediate in repo. Results land on the Registry tab of Findings.

Cloud accounts are added in Settings Integrations Cloud Deployment , which lists the supported cloud providers, such as AWS, Azure and Google Cloud Platform. Saving one creates an asset under Assets Cloud Assessment ; Scan Now runs the scan, and results land on the Cloud tab with Provider, Region and Resource filters. Cloud and SCM findings never offer AI remediation, because there is no repository file to patch.

Key takeaways

• Engines are managed bundles. Set organization defaults on the Connectors page and override SAST, SCA, Secrets, IaC, CI/CD and bill-of-materials engines per repository with Configure; Container, License and SCM stay organization-wide.
• Saving a per-repository selection runs a Re-Scan that clears that repository’s findings, and Severity and Advanced Options changes in the console apply to the whole organization.
• The Severity filter drops results after the scan, so by default Low and Informational results are not reported for any engine; code scans already skip common test and docs paths, except for secrets.
• Upload Scan, SARIF 2.1.0 import and commercial connectors bring outside results into the same model, as candidates that still need proof.
• In CI, every Plexalyzer run authenticates with the organization’s Plexalyzer token; Setup Pipeline opens a pull request your team reviews, and Jenkins builds pass on findings unless you change handleExitCode().
• Every result is normalized, enriched with CWE, OWASP, CVE, EPSS and CVSS, deduplicated with the worst severity kept, and grouped into sub-findings, whatever its source.