feat: Add database compliance rules system

[remyluslosius]

Summary

• Implement database-driven compliance rules system
• Enable dynamic rule management without code changes
• Support for custom compliance frameworks

Changes

• Add database models for compliance rules
• Create API endpoints for rule management
• Implement rule evaluation engine
• Add UI for compliance rule configuration
• Create migration scripts for initial rules

Testing

• Unit tests for rule evaluation
• Integration tests for API endpoints
• E2E tests for UI workflows

To fix the issue, remove only the import of capabilities from the import statement on line 22 of backend/app/main.py. This involves editing the multi-item import statement to exclude capabilities, leaving all other imported modules untouched. No other code changes, imports, or additional definitions are required; only edit the import statement to remove the unused module.

To fix the log injection vulnerability, sanitize any user-provided strings being logged. For log files that are plain text, removal of newline characters (\r, \n, etc.) is recommended (e.g., using .replace("\n", "").replace("\r", "")). In this case, the host_id parameter (which is tainted) should be sanitized before inclusion in the log entry.

Specifically, in backend/app/routes/host_network_discovery.py, line 116, update the logger call to sanitize host_id by removing newline characters. Ideally, use a helper function to safely sanitize loggable user inputs if possible; for this snippet, use the string replace approach directly. No new imports are needed, and code edits are limited to this exception handler block.

---

To fix this error, supply a value for the missing required third parameter to the check_permission function call. As the context does not specify what this third argument should be, but considering typical usage in an RBAC system, the third argument may represent a resource or an action on a specific target. Since this is a bulk operation over hosts, with the actual list of affected hosts available in request.host_ids, the third argument should likely be the list of host IDs (or resources) on which the permission check is being performed.

Make the following change in backend/app/routes/host_network_discovery.py:

• At line 139, change check_permission(current_user, "hosts:read") to check_permission(current_user, "hosts:read", request.host_ids).

No new methods or imports are required, as the objects and variables needed (current_user, "hosts:read", request.host_ids) are already available.

To resolve this vulnerability, you should sanitize the user input (host_id) before incorporating it into any log messages. The specific risk for log injection is the presence of newline (\n, \r) characters, which can be removed using string replacement: host_id.replace('\r', '').replace('\n', ''). It is best to do this as close as possible to the log statement. Only the log message construction should change; the program's logic should remain unaffected.

Steps:

• On line 191, sanitize host_id by replacing/removing any carriage return and newline characters before interpolating it into the log message.
• No dependencies or additional library imports are required for this string sanitization; use Python's built-in string methods.
• Prefer not to mutate host_id globally, just use the sanitized version in the logging call.
• Contextually, other error messages (such as those returned in HTTP responses or populated in error dicts) could also be considered for sanitization, but CodeQL has only flagged the logging sink, so only that should be changed for this fix.

The fix is to remove the unused List import from the import statement on line 15 in backend/app/services/unified_ssh_service.py. Since the code might still use other types from typing such as Dict, Optional, Tuple, Any, and Union, we should preserve those in the import statement and only delete List. Ensure the edit leaves the import statement syntactically correct and retains the other imported types for current and future use.

The best way to fix this problem is to remove the unused import SSHException from the line from paramiko import SSHClient, SSHException, leaving only the use of SSHClient. This can be done by editing that line to from paramiko import SSHClient. Ensure that semantics are not changed elsewhere; no references to SSHException should exist in the file.

Edit only line 19 in backend/app/services/unified_ssh_service.py:

• Change: from paramiko import SSHClient, SSHException
• To: from paramiko import SSHClient

No additional changes, imports, or dependencies are necessary.

---

To fix the issue, remove the unused import of format_validation_message from the statement on line 21-24. Only the format_validation_message part should be deleted, leaving the rest (parse_ssh_key, validate_ssh_key, SSHKeyError, SSHKeyValidationResult) as is, assuming those have legitimate uses found elsewhere in the code. The code change will be localized to lines 21-24 in backend/app/services/unified_ssh_service.py. No new imports or definitions are required; it is a simple removal.

---

To address this vulnerability, we must ensure that the SSH client's missing host key policy is always set to paramiko.RejectPolicy. This means rejecting connections when the host key is not recognized, which is the secure default behavior. The best way to fix the problem is to replace usage of self._get_host_key_policy() at line 369 with a direct reference to paramiko.RejectPolicy, guaranteeing safe handling regardless of any possible overrides or future changes to _get_host_key_policy. The change is localized to line 369 in the file backend/app/services/unified_ssh_service.py, where the host key policy is set.
No additional imports are necessary, as the code already imports paramiko and relevant classes.
Optional: If _get_host_key_policy() is used elsewhere, consider removing or refactoring it to prevent unsafe policies in the future.

---

The best way to fix this problem is to ensure that asyncio is always imported at the module level (top of the file), and remove any inner import asyncio statements inside functions (including inside try/except blocks). This prevents Python from treating asyncio as a local variable within the function, which causes the UnboundLocalError.

Specifically, in backend/app/tasks/scan_tasks.py, move (or remove) all import asyncio from inner blocks (lines 315 and 379) so that only the top-level (line 7) import remains. Ensure no other local imports of asyncio exist in this file in the code snippets shown, as we can't change code outside the supplied snippets.

[sonarqubecloud]

Quality Gate failed

Failed conditions
12 Security Hotspots
E Reliability Rating on New Code (required ≥ A)

See analysis details on SonarQube Cloud

Catch issues before they fail your Quality Gate with our IDE extension SonarQube for IDE

The best way to fix this issue is to replace the empty except: block with one that catches all exceptions (using except Exception as e:), and logs the exception with a suitable log level and message. This way, if something goes wrong during the connection close process, there is a record in the logs, which aids debugging but does not interfere with the main exception handling logic. The fix should only modify lines 177-178 of backend/app/services/host_monitor.py, replacing the bare except:/pass block with proper logging. No new imports or methods are needed, as logging is already imported and in use.

To fix the problem, the bare except: should be replaced with except Exception:. This ensures only ordinary exceptions are caught, and special signals like KeyboardInterrupt and SystemExit used for process control remain unaffected.

This change should be made within the method found in file backend/app/services/host_monitor.py, specifically at the block after if connection_result.connection:, changing except: to except Exception: at line 177. No new imports or definitions are needed; this is just an improvement to exception handling.

---

To fix the problem, simply remove the line that imports the re module (import re) in backend/app/services/scap_datastream_processor.py at line 13. No additional changes or imports are needed, because the re module is not referenced anywhere in the provided code.

The ideal fix is to avoid printing the generated password directly to standard output, where it could be accidentally captured in logs or exposed. If the intent is for the administrator to acquire the credential, the script should instead write the password to a secure file with restricted permissions, display a warning about where the password is stored, and prompt the admin to retrieve it manually (and then securely delete it). Alternatively, require manual password input or sourcing via environment variable, never auto-generating and outputting the value. In this case, we will:

• Replace the line that prints Generated Password: {password} with code that writes the generated password to a file (e.g., admin_password.txt) with restrictive permissions.
• Print a strong warning about the destination file and recommend secure handling (deletion after use, setting permissions).
• Ensure that password is not printed to stdout.
• Only change lines within the provided snippet.
• Import/define the necessary code to securely write to a file and set permissions.

---