--- title: "Finding Processing Rules" slug: "finding-processing-rules" tags: ["automation", "mandiant", "rules", "threat intelligence", "vulnerabilities", "vulnerability intelligence", "workflows"] updated: 2026-06-15T18:25:34Z published: 2026-06-15T18:25:34Z canonical: "help.nucleussec.com/finding-processing-rules" --- > ## Documentation Index > Fetch the complete documentation index at: https://help.nucleussec.com/llms.txt > Use this file to discover all available pages before exploring further. # Finding Processing Rules ## Overview

Using the Nucleus Automation Engine, you can create Finding Processing Rules based on all of the available finding and asset criteria to automatically set due dates, make assignments, update statuses, and much more. For example, rules can be configured to set a due date as a specified number of days, weeks, or months from the time of ingestion, or the finding's discovered date.

 ## Create Finding Processing Rules **Finding Processing Rules** enable you to dynamically manage vulnerability and compliance type findings as they're ingested into Nucleus. 1. From within a project, navigate to the **Automation** page. 2. Select the **Finding Processing** tab and click the **Add Rule** button. 3. Enter the rule information as shown below. > [!NOTE] > ⚠️ Case Sensitivity > > When using exact match conditions (e.g., “is,” “is not,” or “equals”), *case sensitivity is required.* > > For example, if your rule condition is set to match the value Production, it will not match production or PRODUCTION. ### Step 1 - Rule name and criteria ### Rule Name Enter a name to recognize the rule, specify how it is used, and describe the parameters that trigger this rule. This rule name will be included in some of the notifications, for example: "Exploitable vulns (or compliance findings) on assets in IP range X to Y." ### Finding Criteria Finding criteria enable you to choose the conditions that activate the rule. You can set rules to match the following conditions: | Condition | Description | Field Type | | --- | --- | --- | | Severity - Original | Indicates a vulnerability severity defined by the scanning tool | Dropdown with the following choices: Critical, High, Medium, Low, Informational | | Severity - Current | Indicates a vulnerability severity in it's current state within Nucleus. This will take into account manual, or automated adjustments to a finding's severity made within Nucleus | Dropdown with the following choices: Critical, High, Medium, Low, Informational | | Name | A search field where you can search for strings in the name of the vulnerability for additional granular triggering | Freeform text field. Examples: Microsoft, Adobe, Apache, Oracle | | Exploitable | Indicates if a newly discovered vulnerability has existing public exploit code | Boolean: Yes, No | | Description | Search field where you can search for strings in the description of the vuln for additional granular triggering | Freeform text field | | Solution | Search field where you can search for strings in the solution of the vuln for additional granular triggering | Freeform text field | | Discovered | Field to enter a number for days since discovery | Number | | CVE | Field to enter a number for CVEs | Number | | CVSS Score | Field to enter a number for CVSS | Number | | Source | The scanning tool that discovered the vulnerability | Freeform text field | | CISA BOD 22-01 Vulnerability | Indicates if a vulnerability is included in CISA BOD 22-01 | Boolean: Yes, No | | EPSS Score | Field to enter a number for EPSS score | Number or range | | Result | Indicates status of a compliance finding | Dropdown with the following choices: Passed, Failed, Warning | | Port (contact support for enablement) | Indicates the port for a particular finding | Freeform text field to specify a port (eg 443) | | Output (contact support for enablement) | Keys off of the first 1000 characters in a finding's output field | Free form text. Specify a specific phrase, or key word that the finding output contains or does not contain up to the first 1000 characters. | For example: ![](https://cdn.document360.io/3888970a-6501-459e-acc9-c47b71c6d64c/Images/Documentation/Screenshot 2025-07-28 at 3.51.46 PM.png) ### Asset Criteria Asset criteria enable you to specify the conditions on the assets that activate the rule. You can set rules to match asset model-specific information (e.g. name, IP, group, type), asset metadata attributes (business owner, business owner team, etc.), and asset additional metadata ingested from your asset inventory tools into Nucleus. 1. When you finish entering the rule information, click the **Next** button to go to Step 2. ### Step 2 - Rule actions ![](https://cdn.document360.io/3888970a-6501-459e-acc9-c47b71c6d64c/Images/Documentation/Screenshot 2025-07-28 at 3.45.49 PM(1).png) Clarification An important difference between actions on finding instances and finding attributes is that instances affect specific instances of findings while attributes affect whole unique findings. An example use of a unique finding action would be to automatically mark an instance of a finding as exploitable if the Recorded Future risk score is above a 65. With Finding Processing Rules, you can choose from a wide set of actions to perform once a finding's instances and attributes are ingested into Nucleus. For example, Finding Processing Rules make it fast and easy to set due dates on findings using the security policies in your organisation. Finding Processing Rules improve workflow efficiency as shown below. #### Finding Instances - Set the due date of a finding. ![](https://cdn.document360.io/3888970a-6501-459e-acc9-c47b71c6d64c/Images/Documentation/Screenshot 2025-07-28 at 3.46.14 PM.png) Specify the due date: ![](https://cdn.document360.io/3888970a-6501-459e-acc9-c47b71c6d64c/Images/Documentation/Screenshot 2025-07-28 at 3.46.32 PM.png) Your new finding processing rule now appears in the **Automation > Finding Processing**list. Use the search to easily find your new processing rule as shown below: ![](https://cdn.document360.io/3888970a-6501-459e-acc9-c47b71c6d64c/Images/Documentation/Screenshot 2025-07-28 at 3.53.29 PM(1).png) - Assign a finding to a user and/or a [team](/v1/docs/teams). ![](https://cdn.document360.io/3888970a-6501-459e-acc9-c47b71c6d64c/Images/Documentation/image-1639000330020.png) - Change the finding’s status (e.g. if you want to always mark a finding as False Positive or Risk Accepted). - Comment on the finding. #### Finding Attributes - Set the finding as exploitable/not exploitable. - Pin select vulnerabilities to the top of the **Active Vulnerabilities** page. - Set a different severity on the finding. You can include all of the above actions into a single rule in order to orchestrate many outcomes based on the same criteria. Simply create a new rule, choose the finding and asset criteria, and add action cards with the **+** add button to your heart’s content! Finding Processing Rules can be particularly useful for actions that are specific to your organisational context, such as normalising severities based on your internal triage framework, assigning findings to teams and users based on names and underlying assets, or setting SLA due dates accordingly to organisational security policies. 1. When you've finished adding action cards, click the **Save & Finish** button. #### Select Behavior ![](https://cdn.document360.io/3888970a-6501-459e-acc9-c47b71c6d64c/Images/Documentation/image(575).png) These options control which finding instances a Set Finding Status action is allowed to overwrite, based on how that finding's current status was last assigned **Overwrite "Active" statuses set by scans** Applies the new status to findings whose current status is **Active** and was set automatically during scan ingestion. This is the most common behavior. Use it when you want the rule to act on newly discovered or re-confirmed findings that have not yet been reviewed or triaged. *Example: A scan ingests a finding and assigns it Active. This rule will overwrite that with the configured status (e.g., Accepted Risk).* **Overwrite non-Active statuses set by scans (e.g., Potential)** Applies the new status to findings whose current status was set by a scan to something other than Active — for example, **Potential**. Some scan connectors assign intermediate statuses to findings that are detected but not yet fully confirmed. Enable this if you want the rule to also act on those findings. *Example: A scan assigns a finding the status Potential. With this option enabled, the rule will overwrite it with the configured status.* **Overwrite statuses set by workflow** *(disabled by default)* Applies the new status to findings whose current status was previously set by an automation workflow or processing rule. By default, one workflow will not overwrite another's changes. Enable this only if you want this rule to take deliberate precedence over prior workflow-assigned statuses. *Example: A prior workflow set a finding to In Progress. This rule will overwrite it with the configured status.* ⚠️ Use with caution — enabling this across multiple rules can cause conflicts where rules overwrite each other unpredictably. **Overwrite statuses manually set by user** *(disabled by default)* Applies the new status to findings whose current status was manually set by a user through the interface. Manual changes represent deliberate, human-reviewed decisions. This option is off by default to protect those decisions from being automatically overridden. *Example: An analyst manually set a finding to Exception Requested. Enabling this allows the rule to overwrite that decision.* ⚠️ Use with caution — only enable this for high-confidence rules where automation should take precedence over analyst input. If you have any questions, please contact us through the [support center](https://nucleussec.atlassian.net/servicedesk/customer/portal/3). ## Related - [Automation Workflows](/automation-workflows.md) - [Mandiant Vulnerability Intelligence](/mandiant.md) - [Dynamic Fields in Automation](/dynamic-fields-automation.md) - [Dynamic Field Templating Language](/dynamic-field-templating-language.md)