Issues

Issue specific fields

Field Description
labels Issue Labels, defined in ECS required: No type: dictionary engagement: Not used example: object, key value pairs TBD
tags Defined in ECS as a base fields (https://www.elastic.co/guide/en/ecs/current/ecs-base.html Base Fields | Elastic Common Schema (ECS) Reference [8.3] | Elastic) can be used on a source specific or customer specific way. required: No (can be blank) type: keyword array engagements: Not used example: [“Not an Issue”]
vulnerability.is_active Indicates whether this issue is active as defined by the source system. This is a calculated field defined as an issue being:
  • is_removed = false
  • is_suppressed = false
  • is_filtered = false
  • and for PenTest test is “Found”
required: Yes (calculated by the Manger) type: boolean engagements: Visible, not editable example: true
vulnerability.source_severity Best Practice Indicates the severity of the issue, can be source-specific required: No type: keyword engagements: Visible, same as Severity, Required Example: Best Practice
vulnerability.found_date When the issue was first found in an scan type: timestamp engagements: Visible, Required example: 2020-12-28T22:42:19.165783
vulnerability.id Identifier used to identify this issue from an external source (not this instance) The identification (ID) is the number portion of a vulnerability entry. It includes a unique identification number for the vulnerability. For example (Common Vulnerabilities and Exposure CVE ID type: keyword engagements: Not visible example: CVE-2019-00001
vulnerability.is_filtered Whether or not this issue is filtered or hidden type: boolean engagements: Not visible example: false
vulnerability.is_removed Indicates whether this issues has stopped appearing in scans type: boolean engagements: Visible, Required example: false
vulnerability.is_suppressed Indicates whether this issue has been suppressed type: boolean engagements: Visible, Optional example: false
vulnerability.location Location of issue (i.e. URL or file) type: keyword engagements: Visible, Optional example: myfile.js
vulnerability.location_full Full location with path of issue (i.e. URL or file) type: text engagements: Visible, Optional example: https://www.saltworks.io/myfile.js
vulnerability.removed_date When the issue stopped appearing in scans type: timestamp engagements: Visible Optional (default to when an issue is removed if not provided via GUI) example: <date field>
vulnerability.report_id Duplication of saltminer.report_id to make ECS happy Had to duplicate this for ECS and filtering across entities to both work keyword vulnerability.report_id Duplication of saltminer.report_id to make ECS happy Had to duplicate this for ECS and filtering across entities to both work Yes Yes keyword
vulnerability.test_status For Pentest, indicates status of vulnerability testing. Must be one of these: [Tested, Not Tested, Found, Not Found, Out of Scope)Definition:
  • Tested: Tested the issue but it WAS NOT found
  • Not Tested: Have not looked at it yet
  • Found: Looked for it and found it to be real.
  • Not Found (May not be needed)
  • Out of Scope
type: keyword example: Tested
vulnerability.category The type of system or architecture that the vulnerability affects. These may be platform-specific (for example, Debian or SUSE) or general (for example, Database or Firewall). For example (Qualys vulnerability categories) This field must be an array. type: keyword engagement: Not used, hard coded to Application Note:
  • This field should contain an array of value.
  • Application is the most common value for SaltMiner but some scanners may provide different values.
example: [“Application”]
vulnerability.classification CVSS The classification of the vulnerability scoring system. For example (https://www.first.org/cvss/ ) ECS – this is used at some customers for export to external systems and for SSC comes from a linked rules datasource. May need to be a list instead of a single type: keyword engagement: not used example: CVSS
vulnerability.description The description of the vulnerability that provides additional context of the vulnerability. For example (Common Vulnerabilities and Exposure CVE description) type: keyword (w/.text) Multi-fields:
  • vulnerability.description.text (type: match_only_text)
example: In macOS before 2.12.6, there is a vulnerability in the RPC… ECS – also includes vulnerability.description which is a keyword field. For SSC, will have to come from linked rules datasource The description of the vulnerability that provides additional context of the vulnerability. For example: CVE description ECS – also includes vulnerability.description which is a keyword field. For SSC, will have to come from linked rules datasource. Often long descriptive text about the specific issue goes here. engagement: Visible, Optional required: No type: keyword
vulnerability.enumeration The type of identifier used for this vulnerability. For example (https://cve.mitre.org/about/ ) required: No type: keyword engagement: Not used example: CVE
vulnerability.name Name or short description of issue required: Yes type: keyword (w/.text) engagement: Visible, Required example: SQL Injection
vulnerability.reference CVE – CVE-2019-6111 A resource that provides additional information, context, and mitigations for the identified vulnerability. This could replace sor_url from SSC, or it could be used to provide a CVE/CWE reference URL if known type: keyword engagement: Visible, Optional (different from References!) example: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-6111
vulnerability.severity Critical/High/Medium/Low, indicates the severity of the issue Critical What other factors (impact/likelihood/etc.) should be included when considering risk? Should we have a risk score? type: keyword engagement: Visible, Required example: Critical
saltminer.critical saltminer.high saltminer.medium saltminer.low saltminer.info System generated field for counting severity values. If vulnerability.severity = “Critical” then saltminer.critical = 1 else saltminer.critical = 0 This pattern continues for High through Info requires: Yes type: Integer engagement: Not visible, calculated by back end.
saltminer.custom_data Placeholder for customer custom data related to an issue type: object engagement: Not used
saltminer.attributes.<attribute_name> Custom attributes that apply to ISSUES used in visualizations and so on. Net new custom attributes only related to an issue. required: No type: keyword engagement: Not used example: saltminer.attributes.issue_name_in_french: “Quelque chose de mauvais”
vulnerability.audit.audited Whether this issue has been reviewed by an auditor. Defaults to false if null type: boolean engagement: Not Used example: false
vulnerability.audit.auditor Auditor that reviewed this issue type: keyword (w/.text) engagement: Not Used example: John Doe
vulnerability.audit.last_audit Timestamp from the last audit type: timestamp engagement: Not Used example: 2020-12-28T22:42:19.165783
vulnerability.scanner.api_url REST API URL Source specific API data reference URL, links back to source data required: No type: text engagement: Not Used
vulnerability.scanner.gui_url URL to view issue in GUI Source specific reference URL, link back to original record in source system required: No type: text engagement: Not used
vulnerability.scanner.id Unique identifier from source for this issue. required: Yes type: keyword engagement: Not Used example: 12345
vulnerability.scanner.assessment_type Scan assessment type. Must be one of these: SAST, DAST, OSS, PENTEST SAST required: Yes type: keyword engagement: Visible, Optional engagement: Not used
vulnerability.scanner.product SCA Product used to run the scan. SCA, FOD, WebInspect required: Yes type: keyword engagement: Visible, Optional engagement: Not used
vulnerability.scanner.vendor Fortify / FOD / Checkmarx Vendor for the scanner used to identify this issue type: keyword engagement: Visible, Optional example: Fortify vulnerability.scanner.vendor Vendor for the scanner used to identify this issue Yes Yes keyword Fortify / FOD / Checkmarx Fortify
vulnerability.score.base Scores can range from 0.0 to 10.0, with 10.0 being the most severe. Base scores cover an assessment for exploitability metrics (attack vector, complexity, privileges, and user interaction), impact metrics (confidentiality, integrity, and availability), and scope. For example (CVSS v3.1 Specification Document ) type: float engagement: Not Used example: 5.5 vulnerability.score.base 0 to 10 score, Base scores cover an assessment for exploitability metrics (attack vector, complexity, privileges, and user interaction), impact metrics (confidentiality, integrity, and availability), and scope. ECS – Scores can range from 0.0 to 10.0, with 10.0 being the most severe No Yes float 5.5 5.5
vulnerability.score.environmental Scores can range from 0.0 to 10.0, with 10.0 being the most severe. Environmental scores cover an assessment for any modified Base metrics, confidentiality, integrity, and availability requirements. For example (CVSS v3.1 Specification Document ) type: float engagement: Not Used example: 5.5 vulnerability.score.environmental 0 to 10 score. Environmental scores cover an assessment for any modified Base metrics, confidentiality, integrity, and availability requirements. ECS – Scores can range from 0.0 to 10.0, with 10.0 being the most severe No Yes float vulnerability.score.environmental 5.5
vulnerability.score.temporal Scores can range from 0.0 to 10.0, with 10.0 being the most severe. Temporal scores cover an assessment for code maturity, remediation level, and confidence. For example (CVSS v3.1 Specification Document ) type: float engagement: Not Used
vulnerability.score.version The National Vulnerability Database (NVD) provides qualitative severity rankings of “Low”, “Medium”, and “High” for CVSS v2.0 base score ranges in addition to the severity ratings for CVSS v3.0 as they are defined in the CVSS v3.0 specification. CVSS is owned and managed by FIRST.Org, Inc. (FIRST), a US-based non-profit organization, whose mission is to help computer security incident response teams across the world. For example (NVD – Vulnerability Metrics ) type: keyword engagement: Not Used example: 2.0
Source specific attributes
saltminer.source.analyzer Source-specific analyzer (in this case, Fortify SCA would use a SQL_Injection analyzer) No No keyword Semantic Configuration
saltminer.source.issue_status Source-specific issue status (in this case, Fortify) requires: No type: keyword example: Under Review
saltminer.source.kingdom Source-specific kingdom identifier for this issue required: No type: keyword example: Encapsulation
saltminer.source.likelihood Source-specific likelihood score (fortify-specific in this case) required: No type: float example: 3.2
The following fields are used for Engagements only (PenTest)
vulnerability.proof Pentest markdown field containing proof of found vulnerability required: No, if null can be set to ““ type: text engagement: Visible, Optional, Markdown
vulnerability.details Pentest markdown field containing details of found vulnerability required: No, if null can be set to ““ type: text engagement: Visible, Optional, Markdown
vulnerability.implication Pentest markdown field containing implications of found vulnerability required: No, if null can be set to ““ type: text engagement: Visible, Optional, Markdown
vulnerability.recommendation Pentest markdown field containing recommendation for resolution of found vulnerability required: No, if null can be set to ““ type: text engagement: Visible, Optional, Markdown
vulnerability.references Pentest markdown field containing references for found vulnerability required: No, if null can be set to ““ type: text engagement: Visible, Optional, Markdown
vulnerability.category The type of system or architecture that the vulnerability affects. These may be platform-specific (for example, Debian or SUSE) or general (for example, Database or Firewall). For example (Qualys vulnerability categories) This field must be an array. type: keyword Engagement: Not Used Note: this field should contain an array of values. example: [“Firewall”]
saltminer.is_vulnerability Whether the issue is a vulnerability or not (always has a value) true In some cases, we may end up loading ‘best practice’ or ‘fyi’ entries that aren’t actually vuls type: boolean engagement: Not Used
saltminer.report_id The unique report or scan identification number as provided by the scanning vendor type: keyword engagement: Not Used 1205
saltminer.scan_date Timestamp from the related scan where the issue was last found 2018-06-29T12:36:52.430+0000 Represents the scan date when this issue was last found / confirmed type: timestamp engagement: Not Used example: 2020-12-28T22:42:19.165783
saltminer.scan_id ??????? keyword Yes Yes Yes SaltMiner unique scan identifier
saltminer.engagement.attributes attributes that flow down from the Engagement object. Populated by enrichment

Flow down fields

Asset Inventory

  • saltminer.asset_inv.is_production
  • saltminer.asset_inv.name
  • saltminer.asset_inv.description
  • saltminer.asset_inv.version
  • saltminer.asset_inv.attributes
  • saltminer.asset_inv.key

Engagements

For Issues that were found as part of an engagement the following fields flow down
  • saltminer.engagement.publish_date
  • saltminer.engagement.name
  • saltminer.engagement.customer
  • saltminer.engagement.summary
  • saltminer.engagement.scan_id
  • saltminer.engagement.attachments[x].file_name
  • saltminer.engagement.attachments[x].url
  • saltminer.engagement.attributes

Assets

  • saltminer.asset.last_scan-days_policy
  • saltminer.asset.config_name
  • saltminer.asset.source_type
  • saltminer.asset.sub_type
  • saltminer.asset.is_retired
  • saltminer.asset.version_id
  • saltminer.asset.asset_type
  • saltminer.asset.host
  • saltminer.asset.ip
  • saltminer.asset.scheme
  • saltminer.asset.port
  • saltminer.asset.is_production
  • saltminer.asset.name
  • saltminer.asset.description
  • saltminer.asset.version
  • saltminer.asset.attributes
  • saltminer.scan.scan_date
SaltMiner: Our Solution for Enterprise Application Security ManagementLearn More
+ +