How to Configure Dynamic Risk Ratings for Tenable Compliance Results Using the Configuration Compliance CalculatorSummaryBy default, the Tenable.io compliance API does not include any severity, criticality, CVSS, or risk-level fields in the payload. Compliance checks are inherently binary — a configuration either meets the benchmark or it doesn't. This is fundamentally different from Tenable's vulnerability API, which includes CVSS scores and severity ratings. Since the payload contains no data to read, TenableIOComplianceProcessor.js defaults to a hardcoded value. It passes "3" as the source_criticality to CriticalityMapping.mapControlCriticality(). This value is used to look up the sn_vulc_test_criticality_map table, where Source = "Tenable.io" and Source Value = "3" map to Target = "Moderate". As a result, all Tenable compliance tests are assigned the same criticality. FactsThis is a sample payload from Tenable: ============================================= { "asset_uuid": "a1b2c3d4-5678-9012-abcd-ef1234567890", "first_seen": "2025-11-12T11:47:19.637Z", "last_seen": "2025-11-12T11:47:19.637Z", "audit_file": "CIS_RedHat_Enterprise_Linux_8_L1_Server.audit", "check_id": "562ca08788da765716ac6283c66da580ae7ab26acb2672e2c4edd8d6bc49b94c", "check_name": "5.2.3 Ensure sudo log file exists", "check_info": "The Defaults logfile entry sets the path to the sudo log file. Defining a dedicated log file for sudo simplifies auditing of sudo commands.", "expected_value": "cmd: /bin/grep -rPi ... expect: ^pass$", "actual_value": "/etc/sudoers:Defaults logfile=/var/log/sudo.log\npass", "status": "PASSED", "description": "\"5.2.3 Ensure sudo log file exists: [PASSED]\"\n\nThe Defaults logfile entry sets the path to the sudo log file...\n\nSolution:\nEdit /etc/sudoers with visudo and add: Defaults logfile=\"/var/log/sudo.log\"", "solution": "Edit the file /etc/sudoers with visudo and add the following line:\nDefaults logfile=\"/var/log/sudo.log\"", "reference": [ {"framework": "800-53r5", "control": "AU-3"}, {"framework": "CSCv8", "control": "8.5"}, {"framework": "ISO-27001-2022", "control": "A.8.15"}, {"framework": "PCI-DSSv4.0", "control": "10.2.2"} ], "see_also": "https://workbench.cisecurity.org/benchmarks/23597", "plugin_id": 21157, "state": "NEW", "db_type": null, "check_error": null, "profile_name": null } ============================================= ReleaseAllInstructionsUse the Configuration Compliance Calculator to create rules that set different risk scores based on the Result field. This is an out-of-the-box, configuration-only approach that requires no script modifications and is fully upgrade-safe. Step 1: Verify the Criticality Mapping Navigate to Configuration Compliance → Criticality Maps (table: sn_vulc_test_criticality_map). Confirm a row exists for your Tenable integration: Source Source Value Target Value Tenable.io 3 Moderate If no row exists, create one. This provides the baseline test criticality for the calculator to use. Step 2: Open the Calculator Group Navigate to Configuration Compliance → Administration → Calculators. Open an existing calculator group (e.g., "Default Risk Calculator") or create a new one. Step 3: Create Calculator Rule for Failed Results In the Calculator Group, open the Calculator Rules related list and click New. Field Value Name High Risk - Failed Compliance Calculator Group Default Risk Calculator (or your custom group) Active True Order 5 Condition (When this condition is met) Result is Failed Set these values → Risk score 89 (or the weight value that maps to your desired rating) Step 4: Verify the Risk Score Weight Mapping Navigate to sn_sec_cmn_risk_score_weight.list and filter by Type = "Configuration Compliance Risk Rating". Confirm the weight threshold for your target risk rating: Type Value Weight Config Compliance Risk Rating 2 (High) 89 Important: The risk score you set in the calculator rule must meet or exceed the weight value for your desired risk rating. Risk score is the master — risk rating is auto-derived from it. Setting risk_rating explicitly without a matching risk_score will be overwritten by the system. Step 5: Reapply the Calculator New rules only apply to incoming data. To update existing test results, go to the Calculator Group record and click "Reapply Calculator". This triggers a background job that recalculates all matching test results. For single-record testing, right-click the header bar on any individual Test Result and select "Calculate Risk Score". Step 6: Validate Navigate to Configuration Compliance → Test Results (sn_vulc_result). Open a test result where Result = Failed and confirm: Risk score has been updated to 89 (or your configured value)Risk rating now shows 2 - High (auto-derived from the score) Important Notes 1. Risk score is the master, risk rating is derived. The risk_rating field is automatically derived from the risk_score using the weight thresholds in sn_sec_cmn_risk_score_weight. If you set risk_rating explicitly without setting a matching risk_score, the system will overwrite your rating based on whatever score exists. Always set the risk_score in your calculator rule. 2. Description parsing is unnecessary. The [PASSED]/[FAILED] tag in the description field is a human-readable echo of the structured status field. The integration already maps the status field to the test result's result field. Never parse the description for this purpose. 3. Criticality Map vs. Calculator are independent. The criticality mapping table (sn_vulc_test_criticality_map) sets the criticality field on the Configuration Test record during import. The CC Calculator sets the risk_score and risk_rating on individual Test Result records after import. They write to different fields on different tables and do not interact. 4. Test record vs. Test Result record. The calculator operates on Test Result records (sn_vulc_result), not on Configuration Test records (sn_vulc_compliance_test). When validating, ensure you are checking the Test Result record, not the parent Test.