> For the complete documentation index, see [llms.txt](https://docs.plextrac.com/plextrac-documentation/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.plextrac.com/plextrac-documentation/product-documentation-1/integrations-and-file-imports/nipper.md).
# Nipper
### Overview
PlexTrac supports importing XML files from **Nipper.** Nipper is a network security auditing tool used to assess the security of network devices and configurations. It scans network devices, such as routers, switches, and firewalls, and generates detailed reports on their vulnerabilities and compliance with various security standards.
Nipper output scans results in XML format. Users can import these XML files into PlexTrac to review security findings, generate reports, and conduct further analysis using various tools or custom scripts.
PlexTrac imports Nipper 3.x XML exports. PlexTrac detects older Nipper 2.x exports during import and processes them with the legacy parser. Both formats therefore use the same Nipper source.
{% hint style="info" %}
The security audit section from the Nipper export is optional for import.
{% endhint %}
### Field Mappings
Below are the field mappings from Nipper to PlexTrac, broken up by findings, evidence, and assets.
Tables include the following columns:
* **Nipper Field:** the field name in Nipper
* **Direction:** displays the direction in the flow of data occurring for the integration
* **PlexTrac Field:** the field name in PlexTrac
* **Notes:** Additional information on the business rules
#### Supported Audit Types
Nipper reports a finding under one of several audit types, and PlexTrac maps each to a finding. The audit type determines how severity is set and which custom fields are populated:
* **Security** (Nipper-rated findings)
* **Best Practice Security**
* **Vulnerability / CVE** (findings carrying a CVSS rating)
* **Cisco PSIRT** (findings carrying a Cisco SIR rating)
* **DISA STIG**
* **Compliance** — CIS, PCI DSS, and CMMC
Compliance findings for CIS, PCI DSS, and CMMC are supported. Other compliance frameworks, including NIST SP 800-171 and NIST SP 800-53, are not currently parsed.
#### Finding Field Mappings
Below are the mappings of fields. If a field is not listed, PlexTrac does not currently import it.
| Nipper Field | Direction | PlexTrac Field | Notes |
| --------------------------------------------------------------------------- | --------- | ------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Section title (``) | –> | Finding Title | For DISA STIG findings, the STIG ID is used as the title when present. For CIS, PCI DSS, and CMMC findings, the requirement ID parsed from the title is used as the title, and the full original title is preserved in the *Original Title* custom field. |
| Finding / Description / Summary subsection | –> | Finding Description | The descriptive subsection is used based on audit type (Finding, Description, Summary, or Conclusions). HTML entities are decoded. |
| Nipper rating summary (`<NIPPER><SUMMARY>`) | –> | Severity | Critical / High / Medium / Low map to the matching PlexTrac severity; unrecognized values map to Informational. |
| CVSS base severity / score (`<CVSSV3.1>`, `<CVSSV3.0>`, `<CVSSV2>`) | –> | Severity | For CVE findings. The base severity sets the PlexTrac severity; when only a score is present, the severity is derived from the score. |
| Cisco SIR rating (`<CISCO-SIR><TEXT>`) | –> | Severity | For Cisco PSIRT findings. |
| DISA category + compliance status (`<DISA-STIG><CATEGORY>`, `<COMPLIANCE>`) | –> | Severity | Category I / II / III map to Critical / High / Medium; a passing status maps to Informational. |
| Compliance status (`<COMPLIANCE>`) | –> | Severity | For CIS / PCI DSS / CMMC findings. Fail and Error map to High, Investigate to Medium, Pass and N/A to Informational. A Nipper rating, when present, takes precedence for failing and investigate findings. |
| CVSS metrics (`<CVSSV3.1>`, `<CVSSV3.0>`, `<CVSSV2>`) | –> | CVSS Risk Score | For CVE findings. The base score and vector are imported as the corresponding CVSS risk score (CVSSv3.1, CVSSv3.0, or CVSSv2). The vector is used directly when provided, or reconstructed from the individual metrics. |
| CVE ID in title (e.g. `CVE-2017-12240`) | –> | CVE | Parsed from the finding title on CVE findings. |
| CVE list in Cisco infobox | –> | CVE | Comma-separated CVEs on Cisco PSIRT findings are imported as CVE identifiers. |
| Recommendation subsection (or `<EXTRA-INFO><REC>`) | –> | Recommendations | HTML entities are decoded. |
| References subsection | –> | References | CVE findings only. |
| Impact subsection | –> | Custom Field “Impact” | Imported on Security, Best Practice Security, CVE, Cisco PSIRT, DISA STIG, and Compliance findings when the subsection is present. |
| Nipper rating ease (`<NIPPER><EASE>`) | –> | Custom Field “Ease” | Security findings. |
| Nipper rating fix (`<NIPPER><FIX>`) | –> | Custom Field “Fix” | Security findings. |
| Ease subsection (prose) | –> | Custom Field “Ease Details” | Security and Best Practice Security findings. |
| Additional Information subsection | –> | Custom Field “Additional Information” | Security and Best Practice Security findings. |
| TID within Additional Information | –> | Custom Field “TID” | Extracted from the “Additional Information” text when a `TID:` value is present. |
| Classification (`<EXTRA-INFO><CLASSIFICATION>`) | –> | Custom Field “Classification” | Security and Best Practice Security findings. |
| Audit type (`<EXTRA-INFO><AUDIT>`) | –> | Custom Field “Audit Type” | Best Practice Security and Compliance findings. |
| Related (`<EXTRA-INFO><RELATED>`) | –> | Custom Field “Related” | Best Practice Security findings. |
| Cisco advisory ID (infobox) | –> | Custom Field “Cisco Advisory ID” | Cisco PSIRT findings. |
| Cisco SIR score / rating (`<CISCO-SIR><SCORE>`, `<TEXT>`) | –> | Custom Fields “Cisco SIR Score” / “Cisco SIR Severity” | Cisco PSIRT findings. |
| DISA group / rule ID (`<EXTRA-INFO><GROUPID>`, `<RULEID>`) | –> | Custom Fields “DISA Group ID” / “DISA Rule ID” | DISA STIG findings. |
| STIG ID (infobox) | –> | Custom Field “STIG ID” | DISA STIG findings. |
| Original section title | –> | Custom Field “SRG ID” | DISA STIG findings, when the STIG ID replaces the title. |
| DISA category (`<DISA-STIG><CATEGORY>`) | –> | Custom Field “DISA Category” | DISA STIG findings. |
| Compliance status (`<COMPLIANCE>`) | –> | Custom Field “Compliance Status” | DISA STIG and Compliance findings. |
| Requirement ID (parsed from title) | –> | Custom Field “Requirement ID” | CIS, PCI DSS, and CMMC findings. |
| Original section title | –> | Custom Field “Original Title” | Compliance findings, when the requirement ID replaces the title. |
| Nipper rating summary (`<NIPPER><SUMMARY>`) | –> | Custom Field “Nipper Summary” | Compliance findings, when a Nipper rating is present. |
#### Finding Evidence
Nipper reports per-finding results in tables (for example, the affected settings or the proof/results block for a device). PlexTrac imports these as finding evidence.
| Nipper Field | Direction | PlexTrac Field | Notes |
| ----------------------------------------- | --------- | ------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Results tables (`<CONTENT type="table">`) | –> | Finding Evidence (Code Sample) | Each results table within a finding is serialized (caption, header row, and data rows) and attached to the device it describes as Code Sample evidence, viewable on the finding’s Affected Assets tab. |
Evidence tables are attached to the device they belong to. Tables that are not tied to a scanned device (for example, shared reference tables such as “Common Weakness Information”), and tables with no data rows, are not imported.
#### Asset Field Mappings
Below are the mappings of fields and any notes to provide context. If a field is not listed, PlexTrac does not currently import it.
| Nipper Field | Direction | PlexTrac Field | Notes |
| ---------------------------------------------------- | --------- | ----------------- | ------------------------------------------------------------------------------------- |
| Device name (`<DEVICE NAME>`) | –> | Asset Name | Also populates the Hostname field. |
| Operating system (`<DEVICE OS>`, `<DEVICE VERSION>`) | –> | Operating System | The OS and version are combined when both are present. |
| Device description (`<DEVICE DESCRIPTION>`) | –> | Asset Description | Defaults to “Asset discovered from Nipper audit” when the device has no description. |
| Devices listed on a finding (`<DEVICES><DEVICE>`) | –> | Affected Assets | Each device associated with a finding is linked to that finding as an affected asset. |
Nipper reports do not always include device (asset) context. When a report has no device information, its findings are still imported without affected assets.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.plextrac.com/plextrac-documentation/product-documentation-1/integrations-and-file-imports/nipper.md?ask=<question>&goal=<user_goal>
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
