Overview
Dynamic Fields are a templating language for the Nucleus Automation Engine. Dynamic Fields allow you to construct asset and/or vulnerability processing rules that dynamically include information from the assets that the rules match trigger on.
You can use asset fields dynamically in vulnerability processing rules when commenting on a vulnerability or assigning the vulnerability to a user, and in asset processing rules when adding an asset to an asset group.
How to use
Nucleus uses the standard moustache templating format combined with our field dot notation to allow users to automatically use values set dynamically from another place in the Nucleus application. For example, you could enable users to access the asset_owner field of an asset when commenting on a vulnerability.
Examples
{{asset.business_owner}}= inserts value from the Business Owner field on a Nucleus asset{{asset.metadata.cxsast.team}}= inserts value from the checkmarx field for team within the additional metadata section on a Nucleus asset
In the above examples, you can access the values from the fields associated with an asset without having to statically define or hardcode the value from that field. This allows for much more flexibility in the types of actions you can take via the Nucleus Automation Framework and improves the efficiency and accuracy of your work.
Where can Dynamic Fields be used in Nucleus?
Currently, the Nucleus Dynamic Field Templating Language is only available for the Automation Framework.
List of Available Dynamic Fields
Asset and Finding Processing Rules
Here is a complete list of dynamic fields you can use in asset and finding processing automation rules:
Field | Description | Possible Values |
|---|---|---|
app.branch | The application asset branch. | string |
app.repo_type | The application asset repo type. | string |
app.repo_url | The application asset repo URL. | string |
asset.alias | The asset’s display name. | string |
asset.business_owner | The asset's business owner. | string |
asset.business_owner_team | The asset's business owner team. | string |
asset.compliance | Whether or not the asset is in or out of compliance scope. | True or False |
asset.criticality | The criticality of the asset. | string of one of the following: Critical, High, Medium, Low |
asset.data_sensitivity | The data sensitivity of the asset. | string of one of the following: Critical, High, Medium, Low |
asset.ip | The asset’s IP address (if applicable). | IP address or Null |
asset.last_seen | The last date that the asset was seen. | date |
asset.metadata.externaltool.field | Access the custom fields from other tools which are linked to a Nucleus asset. (e.g., to access the qualys host id you would use | Depends on the field, but generally a string or int formatted as a string |
asset.metadata.metadata-key | Additional Metadata specified on the asset. | Depends on the field, but generally a string or int formatted as a string |
asset.name | The name of the asset. | string |
asset.operating_system | The asset’s operating system name | string |
asset.owner | The asset’s owner. | string |
asset.public_facing | Whether or not the asset is public facing. | True or False |
asset.risk_score | The asset’s Nucleus risk score. | Nucleus risk score on scale of 1 - 1000 |
asset.support_team | The asset's support team. | string |
image.alias | The name of this image’s repository. | string |
image.platform_arch | The CPU architecture which the binaries in this image are built to run on. | string |
image.platform_arch_variant | The variant of the CPU architecture of this image. | string |
image.platform_os | The name of the operating system which the image is built to run on. | string |
image.platform_os_version | The version of the operating system which the image is built to run on. | string |
image.registry | The primary registry that this image is stored in. | string |
image.repository | The name of this image’s repository. | string |
Ticketing Rules (Jira connector only)
Opt-in Feature
Dynamic Field support for the Jira connector is currently available as an opt-in feature, please contact support or your Customer Service Representative to enable for your organization.
Here is a complete list of dynamic fields you can use in ticketing automation rules using the Jira ticketing connector:
Field | Description | Example Values | Supported Field Types |
finding.cvss | Finding CVSS score | 9.8 | Label, Paragraph, Short Text |
finding.instance.assignee | User assigned to a vulnerability | Assignee, Label, Paragraph, Short Text | |
finding.mandiant_analysis | Summary analysis by Mandiant | text | Label, Paragraph, Short Text |
finding.mandiant_associated_malware | Names of malware associated with the CVE | URSNIF | Label, Paragraph, Short Text |
finding.mandiant_attacking_ease | Level of difficulty to exploit the vulnerability | Easy, Moderate, Difficult, Unknown | Label, Paragraph, Short Text |
finding.mandiant_exploit_in_the_wild | Known to be exploited in the wild | Yes, No, Unknown | Label, Paragraph, Short Text |
finding.mandiant_exploit_rating | Mandiant Exploit Rating | Wide, Confirmed, Available, Anticipated, No Known, Unknown | Label, Paragraph, Short Text |
finding.mandiant_exploit_vectors | Known Exploit Vectors | General Network Connectivity, File Share | Label, Paragraph, Short Text |
finding.mandiant_exploitation_consequence | Likely consequence if vulnerability is exploited | Remote Code Execution, Escalated Privileges, Data Manipulation | Label, Paragraph, Short Text |
finding.mandiant_exploited_by_malware | Known to be weaponized in malware | Yes, No, Unknown | Label, Paragraph, Short Text |
finding.mandiant_fix_urls | Links to known fixes from vendors | fix_name (fix_url) | Label, Paragraph, Short Text |
finding.mandiant_mitigations | Known mitigation approaches | Patch, Intrusion Prevention Signatures, Workaround, Fixed by Vendor | Label, Paragraph, Short Text |
finding.mandiant_risk_rating | Mandiant Risk Rating | Critical, High, Medium, Low, Unrated | Label, Paragraph, Short Text |
finding.mandiant_threat_actors | Name (Scope) of known threat actors | UNC2603 (confirmed), actor2 (scope2) | Label, Paragraph, Short Text |
finding.mandiant_zero_day | Known Zero Day attack | Yes, No, Unknown | Label, Paragraph, Short Text |
finding.scan_type | Name of the source for the finding. | NESSUS, QUALYS | Label, Paragraph, Short Text |
finding.severity | Finding severity | Critical, High, Medium, Low | Priority, Label, Paragraph, Short Text |
Important Things to Know
Dynamic fields support a maximum of 256 characters, values larger than 256 characters will be truncated.
Label type fields in Jira do not support whitespace characters. When using Dynamic Fields with Label type fields in Jira, Nucleus will not attempt to create a label if the value from a dynamic field contains whitespace characters.
The dynamic fields finding.instance.assignee and finding.severity are evaluated at the instance level, and will dynamically generate individual tickets for each distinct value associate with instances of the finding. If both are used in the same ticketing rule, individual tickets will be created for each distinct combination of values from the dynamic fields. For more information, refer to the Dynamic Ticketing in Jira topic in Jira Ticketing Integration.
Next Step: Use dynamic fields in automation
Now that you know about Dynamic Fields, visit these articles on asset processing, finding processing and ticketing rules to try using Dynamic Fields.
If you have any questions, please contact us through the help center.