Static application security testing tells you where insecure code lives before it ships. The problem is rarely a shortage of SAST output. Most enterprise AppSec programs run more than one static analysis engine, and each one reports findings in its own format, with its own severity scale and its own idea of what counts as critical. SonarQube grades a hotspot one way. Checkmarx ranks a query result another way. Fortify assigns its own priority. When those streams stay siloed in three separate consoles, no one can answer the simplest question a security leader asks: across all our SAST tooling, what are the static code issues that actually matter right now?
PMAP treats that question as an integration problem first and a normalization problem second. It connects to the SAST engines your teams already run, pulls their results into one finding model, and applies a single severity scale across every source. This article looks at how PMAP ingests SonarQube, Checkmarx and Fortify, how SARIF fits in, and how the platform keeps static analysis output consistent without flattening the detail your engineers depend on.
If you want the wider context first, the security integration layer explains how PMAP connects to vulnerability scanners as a category. This piece narrows the lens to SAST specifically.
Why SAST Output Is Hard to Compare Across Tools
Two SAST engines can scan the same repository and produce findings that look nothing alike on paper. That is not a defect. It reflects genuine differences in how each tool models the world.
A SonarQube security hotspot is a review prompt. It flags code that touches a sensitive operation and asks a human to decide whether it is actually exploitable. A Checkmarx query result is a traced data-flow path from source to sink, ranked by the query’s risk weighting. A Fortify issue carries its own analysis confidence and exploitability dimensions. Each engine speaks a different dialect of “this is a problem,” and each attaches a severity label drawn from its own taxonomy.
The result is that severity does not travel cleanly between tools. A “high” in one engine is not a “high” in another. Deduplication is harder too, because the same underlying weakness can surface with different rule identifiers, different file-line anchors and different descriptions depending on which engine found it. Teams that try to reconcile this by hand end up maintaining spreadsheets that go stale within a sprint.
There is also a structural divide in how SAST results even reach a central platform. Some engines expose an API that lets you trigger and orchestrate scans remotely. Others expect you to run the analysis in your own pipeline and then pull the completed results out. PMAP accounts for both patterns rather than forcing every vendor into one mold. The OWASP guidance on source code analysis tools is a useful reference for understanding how broadly these engines vary in approach and output.
The point of a normalization layer is not to pretend these differences away. It is to give security and engineering teams one consistent surface to triage against, while preserving each finding’s original evidence so an engineer can always trace back to the source.
The SAST Connectors PMAP Supports
PMAP’s integration domain is built as a universal connector hub. A single integration record stores the credentials and configuration for an external system, and the platform dispatches vendor-specific logic through a registry of connector archetypes. For static analysis, that registry covers four SAST engine types.
In the supported vendor catalog, the SAST category contains cxsast, checkmarx_one, sonarqube and fortify_sast. That maps to the four real engines AppSec teams run most often: Checkmarx CxSAST, Checkmarx One, SonarQube and Fortify Static Code Analyzer. Each one has its own connector sub-package with a dedicated client and mapper, so the logic for reading a SonarQube result is isolated from the logic for reading a Checkmarx result.
What matters for a buyer evaluating this is that you do not configure SAST tooling through a generic import script you have to maintain yourself. You add an integration of the right type, supply credentials, and the platform knows how to talk to that engine. The type catalog is schema-driven, so the connection wizard renders the correct authentication and configuration fields for each vendor without anything being hardcoded in the interface.
SonarQube as a Remote Scan Connector
SonarQube sits in PMAP’s ScannerConnector archetype, the same family used by the network and DAST scanners that PMAP can orchestrate directly. That archetype implements remote scan operations plus a results fetch. In practice, this means PMAP can interact with SonarQube as an engine whose analysis it reads and imports into the finding model, with the SonarQube connector handling the specifics of authenticating, reading project results, and mapping them into PMAP’s normalized shape.
The SonarQube sub-package ships its own client, importer and mapper. The mapper is the piece that translates SonarQube’s native severity and issue structure into PMAP’s NormalizedFinding, which we return to below. If your organization standardizes on SonarQube for broad code quality and security coverage, this connector brings that output into the same console as everything else.
Checkmarx One and CxSAST as Pull-Only Connectors
Checkmarx is handled differently, and the difference is deliberate. Both Checkmarx One and CxSAST sit in PMAP’s PullOnlyConnector archetype. A pull-only connector does not orchestrate the scan. It performs a scheduled, project-level pull of results that the Checkmarx platform has already produced.
This fits how most Checkmarx deployments actually run. Teams trigger Checkmarx scans inside their own CI pipelines or through Checkmarx’s own scheduling, and the completed results live on the Checkmarx side. PMAP’s job is to reach in on a schedule, pull the latest project-level findings, normalize them, and fold them into the same finding set as every other source. The checkmarx_one and checkmarx_sast sub-packages each carry their own client and mapper for this.
On the recurring question of Checkmarx One versus CxSAST, PMAP does not force a choice. Both are first-class connector types. CxSAST is the established on-premise engine many enterprises still run, and Checkmarx One is the newer cloud-oriented platform. Teams mid-migration can connect both at once and see results from each side in one normalized view, which removes a common blocker to actually completing a platform move.
Where Fortify Fits
Fortify follows the same pattern as Checkmarx. The fortify_sast type is a PullOnlyConnector, with its own client and mapper. PMAP pulls completed Fortify analysis results on a schedule rather than driving the scan engine itself.
That consistency is the point. Whether your static analysis stack is SonarQube, Checkmarx, Fortify, or all three, PMAP folds each engine’s output into one model. The connector archetype determines how results arrive. The normalization layer determines what they look like once they land.
Pull-Only vs Remote Scan: Two Ways SAST Results Arrive
The split between ScannerConnector and PullOnlyConnector is the single most useful concept for understanding how PMAP handles SAST, so it is worth making explicit.
A ScannerConnector exposes remote scan operations along with a results fetch. PMAP can list, create and control scans on that engine, then pull the findings. SonarQube and MobSF sit here on the static and mobile side, alongside the VM and DAST scanners PMAP orchestrates.
A PullOnlyConnector performs a scheduled, project-level results pull and nothing more. It does not create or control scans. Checkmarx One, CxSAST, Fortify, Snyk, Black Duck, Sonatype and Prisma Cloud all sit here. The assumption is that the scan already happened, driven by the team’s own pipeline or the vendor’s own scheduler, and PMAP’s role is to collect and normalize the output.
This distinction is not bureaucratic. It reflects how each vendor’s platform is built and how teams actually operate it. Forcing a pull-only engine to behave like a fully orchestrated scanner would mean fighting the vendor’s intended workflow. PMAP instead matches each engine to the archetype that fits it, which is why the same platform can handle a SonarQube it reads results from and a Checkmarx it pulls results from without the two models colliding.
For a security leader, the practical upshot is simple. You do not need to know the archetype to use it. You configure the integration, set a schedule where it applies, and results show up normalized. The archetype is the engineering reason it works cleanly, not a configuration step you have to reason about.
Scheduled Project-Level Results Pull
For the pull-only SAST engines, scheduling is where the value compounds. A PullOnlyConnector is built around a scheduled project-level pull, and PMAP drives that with a per-integration cron schedule.
Each integration carries its own schedule_cron and schedule_enabled state. A background scheduler ticks every minute, evaluates which integrations are due, and fires the appropriate import pipeline for any whose cron has come up. Every run writes a schedule-log entry that records status, how many findings were imported, and how long it took. Operators can review that log to confirm the pull is healthy, and there is a run-now control to trigger an immediate import without waiting for the next scheduled tick.
This means your Checkmarx, Fortify and SCA-adjacent results stay current automatically. You set the cadence once per integration, and PMAP keeps pulling the latest project-level findings on that rhythm. There is no separate cron host to babysit and no glue script to keep alive. The schedule lives with the integration, and the schedule log gives you the audit trail to prove the pull ran when it was supposed to.
The schedule cadence is yours to set. A nightly pull suits engines that produce a fresh full analysis daily. A more frequent pull suits teams that scan on every significant merge. Either way, the mechanism is the same per-integration cron, evaluated by one background scheduler across every connected SAST source.
Importing SARIF From Any SAST Tool
Not every static analysis tool a team uses is one of the four first-class SAST connector types, and not every workflow wants a live connection. PMAP covers that gap with file-based import, and for static analysis the format that matters is SARIF.
SARIF, the Static Analysis Results Interchange Format, is an OASIS standard designed to be the common output format for static analysis tools. A large and growing number of SAST engines, linters and security scanners can emit SARIF, which makes it the universal on-ramp for any tool PMAP does not have a dedicated connector for. PMAP’s file import accepts SARIF, and the parser targets SARIF 2.1.
The import is idempotent, which is the property that makes file-based ingestion safe to repeat. Upload the same SARIF file twice and you do not get duplicate findings. The pipeline matches on fingerprint and upserts rather than re-creating, so re-running an import after a failed pipeline or a corrected file does not pollute the finding set. The same fingerprint logic that protects connector imports protects file imports.
The practical pattern this unlocks is broad. If your CI job already produces SARIF from a CodeQL run, an ESLint security ruleset, a Semgrep policy or any other SARIF-capable analyzer, that output can flow into the same normalized finding model as your SonarQube and Checkmarx results. You are not limited to the engines with named connectors. SARIF is the bridge for everything else, and it lands in the same place. For teams who want the step-by-step on this, the guide on importing SAST results from SonarQube and Checkmarx walks through both connector setup and SARIF file import end to end.
Normalizing SAST Severity Into One Scale
Normalization is the reason all of this consolidates into something usable rather than a federated pile of three vendors’ opinions. The core rule in PMAP is firm: vendor severity is never authoritative.
Every connector produces a NormalizedFinding, and its severity is set by that connector’s own mapper. The SonarQube mapper translates SonarQube’s severity model. The Checkmarx mappers translate Checkmarx’s. The Fortify mapper translates Fortify’s. The output of all of them lands on one shared PMAP severity scale. So when an engineer looks at a triage queue spanning multiple SAST engines, “high” means the same thing regardless of which tool reported it. That single shared scale is what makes a cross-tool finding list comparable at all.
The import pipeline then applies an import_severity_threshold configured on the integration. Findings below the configured minimum are discarded at import time rather than cluttering the finding store. If you only want to act on high and critical static findings from a given engine, you set the threshold on that integration and the noise never lands. This is per-integration, so you can pull everything from a high-signal engine while filtering a noisier one to its top tier.
There is one more layer. After import, PMAP’s rule engine can override severity further. The mapper produces a normalized starting point, the threshold filters out what you do not want, and a rule can adjust the final severity based on your own logic, asset context or business rules. The vendor’s original label is preserved as evidence on the finding, so nothing is lost, but it never drives triage on its own. Cross-referencing normalized severity against a weakness taxonomy like the MITRE CWE list is straightforward once every engine reports into the same model.
Deduplicating Code Findings Across Tools
Normalization makes severity comparable. Deduplication makes the finding count honest. Both matter when two or three SAST engines overlap on the same codebase.
Every import pipeline in PMAP is idempotent, and findings are matched by fingerprint. Re-importing the same scan produces no duplicates. Raw vendor payloads are archived so an import can be replayed without data loss. The mechanism is the same whether results arrive through a connector pull or a SARIF file upload, which means the protection is consistent across every way SAST output can enter the platform.
In a multi-tool SAST program, this is what keeps the numbers trustworthy. If a nightly Checkmarx pull and a SonarQube import both surface findings on the same code, the fingerprint logic prevents the platform from counting the same underlying issue as two unrelated problems on re-import. Your remediation backlog reflects real distinct issues to fix, not a tally inflated by overlapping coverage and repeated import runs.
For a security leader, the honest count is the whole point. A backlog that double-counts is a backlog no one trusts, and a backlog no one trusts is one no one works. Deduplication by fingerprint is the quiet mechanism that keeps the SAST queue believable enough to actually drive remediation.
SAST in the CI/CD Auto-Scan Flow
SAST is most valuable when it runs close to the code, which means inside the pipeline. PMAP connects static analysis to CI/CD through its auto-scan orchestrator, and the way it does so respects the boundary between this article and the operational pipeline setup.
When a CI event arrives from a connected pipeline, the orchestrator applies a branch filter, then fans out to the configured targets. That fan-out can include SAST integrations. So a push or merge on a watched branch can trigger the relevant SAST integration as part of the automated flow, with the orchestrator always emitting a runbook trigger event regardless of the auto-scan configuration. This is how static analysis becomes a routine part of the development loop rather than a periodic batch job.
This article deliberately stops at the conceptual link. The full operational walkthrough of wiring pipelines, configuring webhooks, and setting up pipeline-triggered scanning lives in the dedicated piece on CI/CD security and webhooks. What matters here is that SAST is a first-class target in that flow. The connectors covered above are exactly the integrations the orchestrator can fan out to, so the same normalized, deduplicated results you get from a scheduled pull are also what you get from a pipeline-triggered SAST run. The OWASP DevSecOps guideline is a solid reference for where static analysis fits in a mature pipeline.
Choosing SAST Alongside DAST and SCA
SAST is one of three application security testing approaches, and a complete program usually runs all three. Static analysis reads the source code without executing it. Dynamic testing probes the running application from the outside. Software composition analysis examines the open-source dependencies your code pulls in. Each catches a class of problem the others miss.
PMAP treats all three as categories in its connector catalog, which is what lets a single platform consolidate findings from a SAST engine, a DAST scanner and an SCA tool into one normalized model. The integration mechanics differ by category, but the destination is shared: one finding set, one severity scale, one deduplicated backlog.
This article owns the SAST integration angle. The decision of which testing type to use where, and how SAST, DAST and SCA complement each other in a coverage strategy, is a category question rather than an integration question. That comparison lives in the dedicated piece on SAST vs DAST vs SCA. If you are choosing where static analysis sits in your overall application security coverage, start there, then come back here for how PMAP brings the SAST half of that strategy into one console.
How PMAP Normalizes Static Analysis Results
Pulling the threads together, PMAP’s approach to SAST rests on a small set of consistent mechanics.
It connects to the four major SAST engine types: SonarQube, Checkmarx CxSAST, Checkmarx One and Fortify. It matches each engine to the connector archetype that fits how the vendor actually works, reading results from SonarQube as a ScannerConnector and pulling project-level results from Checkmarx and Fortify as PullOnlyConnector types. It schedules those pulls with a per-integration cron driven by one background scheduler, and it logs every run.
For everything outside the named connectors, it accepts SARIF 2.1 file import as a universal on-ramp, with the same idempotent fingerprint protection that connector imports get. It normalizes every engine’s severity through a per-connector mapper onto one shared scale, filters at import with a per-integration severity threshold, and allows a rule engine to override severity after the fact while preserving the vendor’s original label as evidence. It deduplicates by fingerprint so the finding count stays honest across overlapping tools. And it makes SAST a first-class target of the CI/CD auto-scan orchestrator so static analysis runs inside the pipeline.
The combined effect is one normalized finding model instead of three vendor consoles. Severity means the same thing everywhere, the backlog counts real distinct issues, and the results stay current on a schedule you control. That is what “normalized” means in practice for static analysis output, and it is what turns a collection of SAST tools into a single program you can actually manage.
Read the integration platform datasheet and normalize SonarQube, Checkmarx and Fortify into one finding model.
Frequently Asked Questions
Which SAST tools does PMAP integrate with?
PMAP supports four SAST engine types in its vendor catalog: SonarQube, Checkmarx CxSAST, Checkmarx One and Fortify Static Code Analyzer. Each has a dedicated connector sub-package with its own client and severity mapper. For static analysis tools outside this list, PMAP accepts SARIF 2.1 file import, which covers any engine that can emit the SARIF format.
What is the difference between a pull-only and a remote scan SAST connector?
SonarQube uses PMAP’s ScannerConnector archetype, which reads results from the engine. Checkmarx One, CxSAST and Fortify use the PullOnlyConnector archetype, which performs a scheduled, project-level pull of results the engine has already produced rather than orchestrating the scan. PMAP matches each engine to the archetype that fits how that vendor’s platform is actually run.
How does PMAP normalize SAST severity across different tools?
Every connector produces a NormalizedFinding whose severity is set by that connector’s own mapper, landing all engines on one shared PMAP severity scale. PMAP never treats vendor severity as authoritative. An import-time severity threshold discards findings below a configured minimum per integration, and a rule engine can override severity afterward while the original vendor label is kept as evidence.
Can PMAP import SARIF files from any SAST tool?
Yes. PMAP’s file-based import accepts SARIF, with the parser targeting SARIF 2.1. This makes SARIF the universal on-ramp for any static analysis tool that can emit it, including engines without a dedicated PMAP connector. The import is idempotent, so re-uploading the same SARIF file produces no duplicate findings.
Can I connect both Checkmarx One and CxSAST at the same time?
Yes. Both are first-class connector types in PMAP. Teams migrating from CxSAST to Checkmarx One can connect both at once and see normalized results from each side in one view, which removes a common blocker to completing the platform move. Neither is forced on you, and findings from both flow into the same finding model.
How often does PMAP pull SAST results?
For pull-only SAST connectors, PMAP uses a per-integration cron schedule. A background scheduler evaluates every integration each minute and fires the import for any whose cron is due, writing a schedule-log entry with status and findings-imported counts. You set the cadence per integration, and a run-now control triggers an immediate import without waiting for the next scheduled tick.
How does PMAP avoid duplicate findings when multiple SAST tools overlap?
Every import pipeline is idempotent and matches findings by fingerprint, so re-importing the same scan produces no duplicates. Raw vendor payloads are archived so imports can be replayed safely. This protection is consistent whether results arrive through a connector pull or a SARIF file upload, which keeps the remediation backlog reflecting real distinct issues rather than an inflated count.
