Configuration Compliance:Can not manually close test results and False positive button not available

sath · 3 weeks ago

Hi,

We have recently implemented Configuration Compliance using Wiz scanner on our instance and have below questions:
1. Noticed that all the fields except assignment group and assigned to on test results record are greyed out which is the OOB setup. I understand that we can modify it by changing the ACLs but wanted to understand the repurcussions of modifying the OOB rules, I don't find information related to this on ServiceNow docs. So, should test results be closed only from the remediation tasks?

2. False positive button/UI action is not available on remediation tasks but I see False Positive approver groups, flows and notifications configured. Did SN miss creating the button? Did anyone else observed this?

3. It has been over 3 months since we implemented this on our lower instances and test results are getting created everyday from the integrations but only 5 remediation tasks were created so far with 3 to 4 test results attached to each one of them. We have enabled OOB assignment rules and remediation task rules but the assignmnet group on almost all the CIs is empty. Could this be the reason for less number of remediation tasks, I was under the impression that tasks would be created with empty assignment group. Wondering if we are missing to setup any other rules?

Appreciate your inputs on this.

william_tran · 2 weeks ago

Let me take your three questions one at a time, since each has a different root cause. Two things worth doing before troubleshooting the specifics though — they may resolve several of these at once:

First, repair your Configuration Compliance application (and related scoped apps). If Configuration Compliance is installed as a scoped app on your instance — along with the related VR Common Workspace and Exception Management scopes it depends on — run a repair on each via System Applications. If any out-of-box (OOB) artifacts (UI actions, Access Control Lists (ACLs), Business Rules, declarative actions) have been overwritten or gone out of sync during your lower-environment testing, repairing restores them. Worth doing before concluding any OOB artifact is missing. Exactly which scopes to repair depends on your release — check your System Applications list for anything in the Configuration Compliance / VR / Exception Management families.

Second, confirm exactly which Wiz integration you're running. There's a ServiceNow-built integration in the Store named "Vulnerability Response Integration with Wiz" (published by ServiceNow). If you're using a custom-built integration, a direct Wiz push, or a non-ServiceNow connector, the field population on test results (especially cmdb_ci and control) may not match what OOB Configuration Compliance expects — and that alone explains a lot of Q3. Strongly recommend running the ServiceNow-published Wiz integration from the ServiceNow Store if you aren't already — the OOB Configuration Compliance flows are designed around the field shape it produces.

Q1 — Test Result fields greyed out

That's intentional OOB behavior. The sn_vulc_result (Test Result) table has a record-level write ACL scoped to role "nobody" (sn_vulc_result.* with role=nobody), which blocks writes globally. Specific field-level ACLs then re-grant write access for narrow cases:

assignment_group / assigned_to / assignment_rule / assignment_type — writable by users with role sn_vulc.write_assignment ("Configuration Compliance Test Result's Assignment fields are writable by user with this role"), and only when state ≠ 3 (Closed).
comments / work_notes — writable by users with role sn_vulc.write, or by users with role sn_vulc.write_assigned who are assigned to the test result (enforced via an ACL script that checks assignment group / assigned user membership).

Consequence of modifying the ACLs: you'd open fields that the OOB framework assumes are controlled by scanner data and integration logic, not by direct user edits. When a Test Result's state transitions to 3 (Closed) — through whatever mechanism (integration import when the control now passes, exception approval, etc.) — the OOB "Transit to Closed" Business Rule fires and sets resolution date, age_closed, and closes the record properly. That flow assumes the record is in a consistent state to begin with; direct user edits around it can drift from what the OOB logic expects.

Should test results be closed only from remediation tasks? No — and worth clarifying the direction of propagation, because it's the opposite of how the question is framed. Test Results close individually, driven by the scanner re-reporting the control as passed. The Remediation Task doesn't close the Test Results under it. It's a tracking wrapper — it rolls up to closed once its children (the Test Results) are closed. The primary flow is: scanner re-scan → Test Result closes → once all linked Test Results on an RT are closed, the RT rolls up to closed.

A secondary pathway: the exception workflow. The sn_sec_exception framework is wired into CC (confirmed via feature configuration on sn_vulc_result_group that lists FALSE_POSITIVE as an approval rule type). An approved False Positive exception ultimately lands the Test Result in a closed state — worth verifying the exact state and substate it maps to on your release, since the specific values can differ. Either way, that's exception-driven, not the routine lifecycle.

The routine lifecycle is scanner-driven, and that's the reason for the ACL lockdown — test results aren't meant to be manually closed outside of scanner-driven state transitions or approved exceptions.

Q2 — False Positive handling

The Mark as False Positive button does exist for Configuration Compliance remediation tasks — it's a workspace-level declarative action, not a classic UI action on the sn_vulc_result_group table directly. Specifically:

The action is registered as a declarative action on table global (label: "Mark as false positive Unified"), which means it surfaces across any record viewed in the Unified / Vulnerability Response Common Workspace — including Configuration Compliance (CC) remediation tasks.
The corresponding Modal - Mark as False Positive and Modal Injection - Mark as False Positive screen types exist in the Vulnerability Response and Vulnerability Response Common Workspace scopes. Clicking the button opens the workspace modal, which drives the approval through the sn_sec_exception framework — backed by your configured False Positive approver groups, flows, and notifications.

If the button isn't showing up for you, a few likely causes — worth walking through in order:

You're likely viewing the remediation task in the classic form view, not the workspace view. The Mark as False Positive action is declarative and lives in the workspace UI layer. Open the task from the VR Common Workspace (or your configured Unified workspace), not from a classic list / form. Declarative actions generally don't render on classic forms — verify on your instance, but this is the most common cause.
The record's state may not satisfy the action's visibility conditions. The related classic UI actions for VR / AVR / CVR gate on sn_sec_exception.StateUtils.canMarkFalsePositive(current) — a state-and-attribute check. The Unified declarative action likely uses similar logic, though worth confirming on your instance. If the task is in a state where FP marking isn't eligible, the button hides.
Exception framework configuration for CC may be off. The Request Exception UI action on sn_vulc_result_group has a condition of the shape ExceptionSettings.getSelectedException(current.getTableName()) == 'vr', and the FP modal sits in the same exception framework. CC's underlying feature configuration (in sn_vul_cmn_feature_config) is where FALSE_POSITIVE is listed as an approval rule type and where CC tables are mapped into the sn_sec_exception framework. If the buttons still don't appear after the workspace view and state checks above, look at your feature configuration records for sn_vulc_result and sn_vulc_result_group and confirm ExceptionSettings.getSelectedException returns the value the UI actions are checking for — release-to-release the exact setting key or expected value can differ.
The scoped apps that ship the button aren't installed or are out of date. The Mark as False Positive modal and the declarative action live in the Vulnerability Response Common Workspace (sn_vul_cmn_ws) and Exception Management for Unified Security Exposure Management (sn_sec_exception) scopes, plus the Unified Security Exposure Management (sn_vul_usem_common) framework. If your instance is missing any of these scopes or is on an older version, the button won't render even though everything else looks right.

So: your configured FP approver groups, flows, and notifications are almost certainly doing the right thing — the button exists OOB, it just lives in the workspace layer, and the visibility is gated by state + exception-framework settings + workspace scope presence. Walk through the four causes above in order.

Q3 — Only 5 remediation tasks in 3+ months

The OOB mechanisms at play, in the order to check them:

Test results need both cmdb_ci and control populated to be eligible for remediation task linking. The "Link to Remediation Tasks" Business Rule on test results requires both fields. If your Wiz imports aren't matching to a Configuration Management Database (CMDB) Configuration Item (CI) reliably, or if the control reference is empty on test results, those test results are invisible to the grouping step. This is the most common cause of the symptom you're describing. Worth checking: of your daily test results, how many have both cmdb_ci and control populated? If you're not on the ServiceNow-built Wiz integration (see the top of this reply), field mapping differences may be why these are empty.
Assignment rules populate the assignment_group field on the test result. The OOB "Evaluate assignment rules" Business Rule on sn_vulc_result calls sn_sec_wf.AssignmentUtils.getAssignmentInfo(current) and sets assignment_group / assignment_rule / assignment_type=1 on the test result based on the matched rule. If no rule matches your test results' criteria, the assignment_group field stays empty, and any downstream logic that groups test results into remediation tasks by assignment won't have the data it needs.
The "assignment groups empty on CIs" detail you called out is likely load-bearing. CC assignment rules commonly look up the assignment group via the CI's own assignment_group reference — though the specific conditions vary per rule. If most of your CIs don't have that populated, and your rules rely on that CI lookup, assignment won't resolve for most test results — and no remediation task gets created. This is not a platform bug — it's a CMDB data readiness issue. Pull up your actual assignment rule records and check what conditions they evaluate.
Grouping mechanism has evolved. The sn_vulc_grouping_rule table is labeled "Remediation Task Rule (Deprecated)" on current releases, so whatever aggregates test results into remediation tasks has changed. The replacement differs by release — there are Script Includes like sn_vulc.RollupTestResultsJobProcessor and sn_vulc.ResultGroup that participate, and the actual driver (a Scheduled Job, a Flow, or an Exception Rule Processor chain) depends on your release and may need to be verified by reading your Scheduled Jobs and Script Include references. Confirm in your instance which mechanism is driving remediation task creation on your release, and verify it's actually running — don't assume that because a Script Include exists it's being executed.

Recommendation order

Repair the Configuration Compliance and related scoped applications first. Cheap, fast, may resolve the UI-action, ACL, or declarative-action behavior you're seeing without further changes. Always the first step when OOB artifacts behave unexpectedly after extended lower-environment configuration work. Check your System Applications list for the CC, VR Common Workspace, and Exception Management scopes — repair each that's installed.
Confirm your Wiz integration is the ServiceNow-published one. Search the ServiceNow Store for "Vulnerability Response Integration with Wiz" (published by ServiceNow) and verify you're running that integration. If you're on a custom or third-party connector, switching to the ServiceNow-built integration is the cleanest path to getting CI and control matching right — which directly addresses Q3 at the root.
Don't modify the OOB ACLs on sn_vulc_result. The lockdown is deliberate and protects the assumed test-result lifecycle. Opening it up creates drift from OOB that compounds over upgrades.
Verify CC's exception framework configuration. The feature configuration records in sn_vul_cmn_feature_config for sn_vulc_result and sn_vulc_result_group control how the exception framework applies to CC. FALSE_POSITIVE is natively supported as an approval rule type for CC, and the tables are mapped into sn_sec_exception. If the buttons still don't appear after checking workspace view and record state, walk through those feature configuration records and confirm they return the value the UI action conditions expect on your release.
Audit your test result data. Pull a sample of recent test results and check what percentage have populated cmdb_ci, control, and assignment_group. That audit may explain the low remediation task volume without touching any rules or customization.
Audit your assignment rules against the actual test result data. If the rules evaluate CI-derived assignment groups and most CIs don't have that populated, you've found your blocker — and the fix is upstream CMDB data quality, not CC configuration.
Confirm your release's remediation task creation mechanism (deprecated grouping rules vs. rollup job vs. something newer) by checking current Configuration Compliance documentation.

Validate everything above against current ServiceNow documentation for your release and confirm the behavior on your own instance before making changes.

View solution in original post

william_tran · 2 weeks ago

Let me take your three questions one at a time, since each has a different root cause. Two things worth doing before troubleshooting the specifics though — they may resolve several of these at once:

First, repair your Configuration Compliance application (and related scoped apps). If Configuration Compliance is installed as a scoped app on your instance — along with the related VR Common Workspace and Exception Management scopes it depends on — run a repair on each via System Applications. If any out-of-box (OOB) artifacts (UI actions, Access Control Lists (ACLs), Business Rules, declarative actions) have been overwritten or gone out of sync during your lower-environment testing, repairing restores them. Worth doing before concluding any OOB artifact is missing. Exactly which scopes to repair depends on your release — check your System Applications list for anything in the Configuration Compliance / VR / Exception Management families.

Second, confirm exactly which Wiz integration you're running. There's a ServiceNow-built integration in the Store named "Vulnerability Response Integration with Wiz" (published by ServiceNow). If you're using a custom-built integration, a direct Wiz push, or a non-ServiceNow connector, the field population on test results (especially cmdb_ci and control) may not match what OOB Configuration Compliance expects — and that alone explains a lot of Q3. Strongly recommend running the ServiceNow-published Wiz integration from the ServiceNow Store if you aren't already — the OOB Configuration Compliance flows are designed around the field shape it produces.

Q1 — Test Result fields greyed out

That's intentional OOB behavior. The sn_vulc_result (Test Result) table has a record-level write ACL scoped to role "nobody" (sn_vulc_result.* with role=nobody), which blocks writes globally. Specific field-level ACLs then re-grant write access for narrow cases:

assignment_group / assigned_to / assignment_rule / assignment_type — writable by users with role sn_vulc.write_assignment ("Configuration Compliance Test Result's Assignment fields are writable by user with this role"), and only when state ≠ 3 (Closed).
comments / work_notes — writable by users with role sn_vulc.write, or by users with role sn_vulc.write_assigned who are assigned to the test result (enforced via an ACL script that checks assignment group / assigned user membership).

Consequence of modifying the ACLs: you'd open fields that the OOB framework assumes are controlled by scanner data and integration logic, not by direct user edits. When a Test Result's state transitions to 3 (Closed) — through whatever mechanism (integration import when the control now passes, exception approval, etc.) — the OOB "Transit to Closed" Business Rule fires and sets resolution date, age_closed, and closes the record properly. That flow assumes the record is in a consistent state to begin with; direct user edits around it can drift from what the OOB logic expects.

Should test results be closed only from remediation tasks? No — and worth clarifying the direction of propagation, because it's the opposite of how the question is framed. Test Results close individually, driven by the scanner re-reporting the control as passed. The Remediation Task doesn't close the Test Results under it. It's a tracking wrapper — it rolls up to closed once its children (the Test Results) are closed. The primary flow is: scanner re-scan → Test Result closes → once all linked Test Results on an RT are closed, the RT rolls up to closed.

A secondary pathway: the exception workflow. The sn_sec_exception framework is wired into CC (confirmed via feature configuration on sn_vulc_result_group that lists FALSE_POSITIVE as an approval rule type). An approved False Positive exception ultimately lands the Test Result in a closed state — worth verifying the exact state and substate it maps to on your release, since the specific values can differ. Either way, that's exception-driven, not the routine lifecycle.

The routine lifecycle is scanner-driven, and that's the reason for the ACL lockdown — test results aren't meant to be manually closed outside of scanner-driven state transitions or approved exceptions.

Q2 — False Positive handling

The Mark as False Positive button does exist for Configuration Compliance remediation tasks — it's a workspace-level declarative action, not a classic UI action on the sn_vulc_result_group table directly. Specifically:

The action is registered as a declarative action on table global (label: "Mark as false positive Unified"), which means it surfaces across any record viewed in the Unified / Vulnerability Response Common Workspace — including Configuration Compliance (CC) remediation tasks.
The corresponding Modal - Mark as False Positive and Modal Injection - Mark as False Positive screen types exist in the Vulnerability Response and Vulnerability Response Common Workspace scopes. Clicking the button opens the workspace modal, which drives the approval through the sn_sec_exception framework — backed by your configured False Positive approver groups, flows, and notifications.

If the button isn't showing up for you, a few likely causes — worth walking through in order:

You're likely viewing the remediation task in the classic form view, not the workspace view. The Mark as False Positive action is declarative and lives in the workspace UI layer. Open the task from the VR Common Workspace (or your configured Unified workspace), not from a classic list / form. Declarative actions generally don't render on classic forms — verify on your instance, but this is the most common cause.
The record's state may not satisfy the action's visibility conditions. The related classic UI actions for VR / AVR / CVR gate on sn_sec_exception.StateUtils.canMarkFalsePositive(current) — a state-and-attribute check. The Unified declarative action likely uses similar logic, though worth confirming on your instance. If the task is in a state where FP marking isn't eligible, the button hides.
Exception framework configuration for CC may be off. The Request Exception UI action on sn_vulc_result_group has a condition of the shape ExceptionSettings.getSelectedException(current.getTableName()) == 'vr', and the FP modal sits in the same exception framework. CC's underlying feature configuration (in sn_vul_cmn_feature_config) is where FALSE_POSITIVE is listed as an approval rule type and where CC tables are mapped into the sn_sec_exception framework. If the buttons still don't appear after the workspace view and state checks above, look at your feature configuration records for sn_vulc_result and sn_vulc_result_group and confirm ExceptionSettings.getSelectedException returns the value the UI actions are checking for — release-to-release the exact setting key or expected value can differ.
The scoped apps that ship the button aren't installed or are out of date. The Mark as False Positive modal and the declarative action live in the Vulnerability Response Common Workspace (sn_vul_cmn_ws) and Exception Management for Unified Security Exposure Management (sn_sec_exception) scopes, plus the Unified Security Exposure Management (sn_vul_usem_common) framework. If your instance is missing any of these scopes or is on an older version, the button won't render even though everything else looks right.

So: your configured FP approver groups, flows, and notifications are almost certainly doing the right thing — the button exists OOB, it just lives in the workspace layer, and the visibility is gated by state + exception-framework settings + workspace scope presence. Walk through the four causes above in order.

Q3 — Only 5 remediation tasks in 3+ months

The OOB mechanisms at play, in the order to check them:

Test results need both cmdb_ci and control populated to be eligible for remediation task linking. The "Link to Remediation Tasks" Business Rule on test results requires both fields. If your Wiz imports aren't matching to a Configuration Management Database (CMDB) Configuration Item (CI) reliably, or if the control reference is empty on test results, those test results are invisible to the grouping step. This is the most common cause of the symptom you're describing. Worth checking: of your daily test results, how many have both cmdb_ci and control populated? If you're not on the ServiceNow-built Wiz integration (see the top of this reply), field mapping differences may be why these are empty.
Assignment rules populate the assignment_group field on the test result. The OOB "Evaluate assignment rules" Business Rule on sn_vulc_result calls sn_sec_wf.AssignmentUtils.getAssignmentInfo(current) and sets assignment_group / assignment_rule / assignment_type=1 on the test result based on the matched rule. If no rule matches your test results' criteria, the assignment_group field stays empty, and any downstream logic that groups test results into remediation tasks by assignment won't have the data it needs.
The "assignment groups empty on CIs" detail you called out is likely load-bearing. CC assignment rules commonly look up the assignment group via the CI's own assignment_group reference — though the specific conditions vary per rule. If most of your CIs don't have that populated, and your rules rely on that CI lookup, assignment won't resolve for most test results — and no remediation task gets created. This is not a platform bug — it's a CMDB data readiness issue. Pull up your actual assignment rule records and check what conditions they evaluate.
Grouping mechanism has evolved. The sn_vulc_grouping_rule table is labeled "Remediation Task Rule (Deprecated)" on current releases, so whatever aggregates test results into remediation tasks has changed. The replacement differs by release — there are Script Includes like sn_vulc.RollupTestResultsJobProcessor and sn_vulc.ResultGroup that participate, and the actual driver (a Scheduled Job, a Flow, or an Exception Rule Processor chain) depends on your release and may need to be verified by reading your Scheduled Jobs and Script Include references. Confirm in your instance which mechanism is driving remediation task creation on your release, and verify it's actually running — don't assume that because a Script Include exists it's being executed.

Recommendation order

Repair the Configuration Compliance and related scoped applications first. Cheap, fast, may resolve the UI-action, ACL, or declarative-action behavior you're seeing without further changes. Always the first step when OOB artifacts behave unexpectedly after extended lower-environment configuration work. Check your System Applications list for the CC, VR Common Workspace, and Exception Management scopes — repair each that's installed.
Confirm your Wiz integration is the ServiceNow-published one. Search the ServiceNow Store for "Vulnerability Response Integration with Wiz" (published by ServiceNow) and verify you're running that integration. If you're on a custom or third-party connector, switching to the ServiceNow-built integration is the cleanest path to getting CI and control matching right — which directly addresses Q3 at the root.
Don't modify the OOB ACLs on sn_vulc_result. The lockdown is deliberate and protects the assumed test-result lifecycle. Opening it up creates drift from OOB that compounds over upgrades.
Verify CC's exception framework configuration. The feature configuration records in sn_vul_cmn_feature_config for sn_vulc_result and sn_vulc_result_group control how the exception framework applies to CC. FALSE_POSITIVE is natively supported as an approval rule type for CC, and the tables are mapped into sn_sec_exception. If the buttons still don't appear after checking workspace view and record state, walk through those feature configuration records and confirm they return the value the UI action conditions expect on your release.
Audit your test result data. Pull a sample of recent test results and check what percentage have populated cmdb_ci, control, and assignment_group. That audit may explain the low remediation task volume without touching any rules or customization.
Audit your assignment rules against the actual test result data. If the rules evaluate CI-derived assignment groups and most CIs don't have that populated, you've found your blocker — and the fix is upstream CMDB data quality, not CC configuration.
Confirm your release's remediation task creation mechanism (deprecated grouping rules vs. rollup job vs. something newer) by checking current Configuration Compliance documentation.

Validate everything above against current ServiceNow documentation for your release and confirm the behavior on your own instance before making changes.

sath · 2 weeks ago

Thank you so much @william_tran for providing detailed information. Will follow the steps provided.

I did it on platform view by accessing the UI page 'trg_request_exception' but the changes are not reflected on IT Remediation Workspace and Vulnerability Manager Workspace. Can you please let me know where do I need to make the changes. I just need to update the description on the top and update Justification Notes field to Notes(requirement from our internal csoc team).

sath · 2 weeks ago

Nevermind on exception request form. I have figured it out, it is designed on UX Macroponent Definition table.

Appreciate your assistance.

william_tran · 2 weeks ago

I recommend, if you haven't already, to look at migrating over to USEM.

https://www.servicenow.com/community/secops-articles/essential-information-vr-to-usem-upgrade-guidan...

Please mark as helpful if you found my response valuable!