Integrations: every screen, column and action¶
Complements Setting up each integration. This page covers the screens themselves — the mapping tables, the sync queues and the vulnerability catalogues behind them.
Project mapping — the screen most tickets are about¶
Every code-scanning integration shows the same table: the tool's projects on the left, your NxSAM assets on the right, and whether they are joined.
| Column | What it holds |
|---|---|
| Project Details / Original Project Details / ProjectVersion Details | The project as the tool names it |
| Asset Details / Mapped Asset Details / SSC Project | The NxSAM asset it feeds |
| Account | Which tool account it came from, where the integration serves several |
| Mapping Status | Whether a mapping exists |
| Sync Status | Whether the last sync succeeded |
| Last Sync Time | When it last ran |
Unmapped means collected and discarded
A project with no mapping is visible to the integration and has nowhere to file its findings. The sync reports success, and nothing appears in the module.
"The scan ran but there are no findings in NxSAM" is this, far more often than it is a credential or a parsing problem. Check Mapping Status before anything else.
Mapping Status and Sync Status are independent. A mapped project can fail to sync, and an unmapped project can sync successfully and file nothing. Reading only one of the two gives the wrong diagnosis.
Checkmarx additionally distinguishes Original Project Details from Project Details — the project as first discovered against its current name — so a renamed project stays recognisable rather than appearing as a new one.
Container and cloud sync queues¶
Prisma reports Sync Type, Image Type, Status, Initiated at, Completed at.
Image Type separates deployed images from those merely present in the registry. Syncing everything in a registry produces findings on images nobody runs, which is the usual cause of a container backlog that nobody can prioritise.
Cortex XDR endpoints¶
| Column | What it holds |
|---|---|
| Endpoint Name | The host as the agent reports it |
| IP Address(es) | Every address it has — plural because endpoints move |
| Status | Whether the agent is connected |
| Platform | Operating system |
| Group | The agent's grouping |
| Alias | An alternative name |
| First Seen / Last Seen | The window over which the agent has reported |
IP Address(es) and Alias together are why endpoint matching is harder than host matching. A laptop has several addresses over time and may be known by a different name in your CMDB. An endpoint that will not match an existing asset usually needs the alias, not the address.
Connection tables¶
Each tool integration lists its configured connections:
| Column | What it holds |
|---|---|
| ID | The connection |
| Clients / Organization | Which of your organisations it serves |
| URL / Base URL and Port | Where the tool is |
| Last Sync / Latest Config Sync | When data and configuration were last pulled |
Last Sync and Latest Config Sync are different clocks. Configuration sync pulls the tool's projects, policies and scanner definitions; data sync pulls findings. A connection with recent findings and stale configuration will not know about projects created since, which is a common cause of a new project never appearing for mapping.
Clients matters because one scanner installation often serves several organisations. A connection scoped to the wrong client files findings against the wrong tenant.
Severity mapping¶
Qualys and Tenable both expose a Risk to Risk Rating table: the tool's own risk value
on the left, the NxSAM severity it becomes on the right. Qualys additionally maps by
Scanner, Org and BU, with Configured showing whether a mapping has been set.
Changing this re-classifies existing findings, because severity is derived rather than stored — the same trap as the CVSS configuration.
Qualys also carries Asset Property Name / Asset Property Value, which copies a scanner
attribute onto the NxSAM asset during sync, so scanner-side grouping survives the import.
Policy mapping¶
Policy ID, Policies, Created On, Modified On, Audit Files, Configuration —
maps a Policy Compliance benchmark to the tool policy that implements it. Audit Files
are the source reports; Modified On is what tells you a mapping changed between two
runs that produced different numbers.
Audit Files opens a dialog listing each file behind the mapping: Title, Type,
Template, File Name, Created On, Modified On. It exists so that "which benchmark
file did this policy actually run" can be answered from the mapping rather than from the
scanner — two mappings with the same policy name and different audit files are different
benchmarks, and produce different numbers legitimately.
On the Tenable configuration, postures that came from a Tenable scan rather than from an uploaded report are marked Scanned by Tenable, which is how to tell the two sources apart when both feed the same audit.
Nexpose configuration reference¶
Character, Description, Example — the escaping and wildcard syntax accepted in
Nexpose configuration fields, with a worked example for each. It is reference material
rather than a working screen, and it is there because the syntax is not guessable.
Scan profiles¶
Where an integration launches scans rather than only collecting them, Sync Profile pulls the profile definitions from the tool and Profile Details shows what a profile contains — which checks it runs, and against what.
Reading the profile matters when results look thin: a scan that completed against a profile covering forty checks is not evidence of a clean host, and the profile is the only place that distinguishes "nothing found" from "little looked for".
Vulnerability master catalogues¶
One per tool. The richest are the network scanners:
Qualys — QID, Title, Vuln type, Category, Group, Sub Group, Severity,
Exploitable, Patchable, False Positive.
Nexpose — VID, Nexpose ID, Title, Category, Group, Sub Group, Severity,
Exploitable, False Positive.
Nessus — ID, Name, Group, Sub Group, Version, Exploitable, Risk,
False Positive, plus Family ID, Family Name and Family Type. Nessus organises
plugins into families, and the family is often the useful unit: excluding a whole family is
a single decision where excluding its plugins individually is dozens.
Snyk Code — Rule ID, NAME. Acunetix — VID, VNAME. Dependency Track —
UUID, Name. Network and Red Teaming — ID, Title.
AppScan and Netsparker carry Audit Exception and Client Exception — whether an
issue is excluded for one audit or for the whole client. The two are separate because a
finding irrelevant to one assessment is not necessarily irrelevant everywhere, and
recording it at the wrong level either suppresses too much or too little. Netsparker also
carries Issue Type.
Exploitable, Patchable and False Positive are catalogue-level flags
They apply to the vulnerability definition, not to one occurrence. Marking a QID as a false positive in the catalogue affects every finding of that QID, across every host and every audit, including ones imported in future.
That is the right tool for a check your environment genuinely never fails, and the wrong one for a single host where the finding does not apply — use the finding's own status for that.
Patchable is Qualys-specific and worth using: it separates findings a patch resolves from those needing a configuration change, which are different pieces of work assigned to different people.
Qualys detail¶
ID, URL, Threat Intel, Remote, Authentication Type, Additional Info, Type,
Section, Description, SRC NAME, REF, Link, MW TYPE, MW PLATFORM, MW ALIAS,
MW RATING, Comments.
The MW fields are malware association — type, platform, alias and rating. A vulnerability
with a malware rating is one being actively used, which outranks a higher CVSS score with
no known exploitation.
Remote and Authentication Type say whether the check ran across the network or needed credentials. An unauthenticated scan that found nothing on a host is much weaker evidence than an authenticated one, and this is where you confirm which it was.
Nexpose detail¶
Solution Type, Summary, Title, Description — Solution Type distinguishes a
patch from a workaround from a configuration change.
Vulnerability mapping tables¶
One per tool, all the same shape: ID., <Tool> Issue, Issue Master.
This is what makes the same weakness from two scanners one finding rather than two. The tool's own issue identifier on the left, the NxSAM master entry on the right. Acunetix, Burp Suite, Checkmarx, Checkmarx SCA, Dependency Tracker, Fortify, Gitleaks, JFrog X-Ray and Netsparker each have one — the JFrog X-Ray Issue column, for example, holds the identifier as Xray reports it.
An unmapped tool issue produces findings that do not deduplicate against anything, so the same vulnerability found by Checkmarx and Burp appears twice with separate SLAs. When a customer reports duplicate findings across tools, this table is the answer.