Findings are the most common object in PlexTrac and contain data detailing an exploit.
Findings also exist in client asset information in the form of an affected asset and contain the relationship information about which client assets are affected, which is tracked in the affected_assets field.
For each client asset, the finding affects, an object exists in that field's list containing information and metadata about the client asset and how it relates to the finding. Since the objects stored in affected_assets contain this extra relationship metadata, these items are considered separate objects called affected asset objects.
The following table explains the fields and data types stored for a finding. Fields are presented in alphabetical order by object field name.
The required fields when creating a finding are title, severity, and description.
affected_assets
name of affected assets
dict {str, {AFFECTED ASSET Object}
assignedTo
email address of user that finding is assigned to
string
client_id
client that the finding belongs to
integer
closedAt
when finding was closed
integer in epoch milliseconds, such as "1662588579026"
common_identifiers
includes CVE scores, CWE scores, and code that is related to the finding (added in the Code Sample tab when editing a finding)
"CVE": [{ "name": str, "year": int, "id": int, "link": str } ], "CWE": [ { "name": str, "id": int, "link": str } ] }, "code_samples": [ { "caption": str, "code": str, "id": str } ] }
createdAt
when finding was created in
integer in epoch milliseconds, such as "1662588579026"
description
description of finding
string
doc_type
field in database to identify object
string
doc_version
version of PlexTrac when finding was created. Should not be added to create or update requests
string
exhibits
an image or video related to the finding (added in the Screenshots/Video tab when editing a finding)
array: {"assets": [ { "asset": str, "id": str } ], "caption": str, "exhibitID": str:, "index": int, "type": str: MIME type image, such as .png}
fields
includes any added custom fields, plus any CVSS 3.0 score, CVSS 2.0 score, and 'general' score values entered for a finding
dict {str, dict {label: str, value: str}, "scores": { "cvss", { "type": "cvss", "value": str, "label": str, "calculation": str }, "cvss3", { "type": "cvss3", "value": str, "label": str, "calculation": str }, "general", { "type": "general", "value": str, "label": str, "calculation": str } } },
flaw_id
the unique identifier of a finding and is generated based on the finding title, but since a finding with the same title can exist in different reports, this means flaw_id is not unique across the platform
integer
last_update
when finding was last modified
integer in epoch milliseconds, such as "1662588579026"
repoenedAt
when finding was reopened
integer in epoch milliseconds, such as "1662588579026
report_id
ID of report finding is associated with
integer
report_name
name of report
string
risk_score
the total risk score of the finding for CVSS v3.1, CVSS v3.0, CVSS v2.0, and CWSS
"CVSS3": "overall": int, "vector": str, "subScore": "base": int
selectedScore
the identified selected score for the finding
string
severity
severity of finding
string
slaData
SLA status of finding
{"title": str, "timeToExpire": str }
source
source of finding
string
status
status of finding
string
subStatus
substatus of finding
string
tags
any tags associated with finding
string array
title
title of finding
string
visibility
visibility of finding
string
The finding object stored in the database is a nested JSON object. Below are screenshots and a sample downloadable file that displays the structure of different database objects.
continued
