Security Audit cautions

What to watch for

SecurityAuditWorkflow coordinates four specialized subagents (vuln-scanner, secret-detector, auth-reviewer, remediation-planner) and synthesizes their output into a single report. The risks below apply to how you configure the scan, handle its findings, and act on its alerts.

Risk areas

Secrets detected during a scan may appear in telemetry

SecretDetection findings flow through the same LLMCallRecord and WorkflowRunRecord pipeline as all other telemetry. If you have configured an OTELBackend or a webhook-channel AlertConfig, raw finding data — including matched secret strings — can reach external endpoints. Before running a scan in an environment with telemetry backends enabled, verify that MultiBackend.get_active_backends() returns only backends you trust with sensitive content. Use MultiBackend.remove_backend() to detach any backend you don't want receiving findings.

detect_secrets operates on the literal file content it is given

detect_secrets from security.__init__ does not follow symlinks or resolve .. path components on its own. If you pass a path built from user input without first calling _validate_file_path, a traversal can silently scan files outside your intended scope. Always validate paths before passing them to the scan.

Alert cooldown_seconds can suppress repeated findings

AlertConfig.cooldown_seconds defaults to 3600. If the same threshold is breached multiple times within an hour — for example, a high error-rate metric that stays elevated — AlertEngine.check_and_trigger() fires only once per cooldown window. You will not receive a second AlertEvent until the window expires, even if current_value keeps climbing. Reduce cooldown_seconds when you need per-occurrence visibility, or poll AlertEngine.get_metrics() directly for the live value.

Deleting an alert also removes its history

AlertEngine.delete_alert() removes the AlertConfig and its associated AlertEvent rows from the SQLite database at .attune/alerts.db. Call AlertEngine.get_alert_history() and export the results before deleting any alert you may need for an audit trail.

PIIScrubber runs separately from SecretsDetector

PIIScrubber and SecretsDetector are independent classes in security.__init__. Running one does not invoke the other. If you need both PII redaction and secret detection in a pipeline, you must call each explicitly — relying on detect_secrets alone leaves PII patterns unexamined.

How to avoid problems

1. Audit active telemetry backends before scanning. Call MultiBackend.get_active_backends() and confirm that no backend will forward finding data to an unintended destination. If in doubt, call MultiBackend.flush() then MultiBackend.remove_backend() for any backend that should not receive security findings.

2. Validate file paths before passing them to the workflow. Use _validate_file_path (exported from security.__init__) on any path derived from user input before invoking SecurityAuditWorkflow.execute().

3. Check alert history before deleting an alert. Run attune alerts history --alert-id <id> (or call AlertEngine.get_alert_history(alert_id=..., limit=100)) and save the output before calling delete_alert().

4. Treat _validate_webhook_url and _validate_file_path as internal. Both are exported in __all__ for convenience, but names starting with _ are not covered by the public API stability guarantee. Wrap them rather than depending on their signatures directly.

5. Pair PIIScrubber with SecretsDetector explicitly. In any pipeline that processes user-generated content, instantiate both classes and run both checks. Do not assume one covers the other's detection patterns.

Source files

• src/attune/workflows/security_audit.py
• src/attune/security/**
• src/attune/monitoring/**

Tags: security, audit, owasp, scanning, cve

Unresolved references

Auto-generated by attune-author fact-check. Review and either fix the source code, fix this doc, or add an override.