Security Audit

Security audit is a workflow that scans your codebase for vulnerabilities that are easy to introduce and hard to spot in code review — things like eval() on untrusted input, file paths built without validation, API keys committed to source control, and injection risks in queries or shell commands.

How it works

SecurityAuditWorkflow coordinates four specialized subagents — vuln-scanner, secret-detector, auth-reviewer, and remediation-planner — each focused on a distinct domain. After all four finish, the workflow synthesizes their output into a single report structured around three sections:

• Summary — an overall security score (0–100) and a short executive summary of your security posture
• Security — consolidated findings organized by severity (CRITICAL, HIGH, MEDIUM, LOW)
• Suggestions — actionable remediation steps ordered by priority, with estimated effort for each fix

Findings cite file paths and line numbers where possible.

On the security side, the security module exposes SecretsDetector, PIIScrubber, and AuditLogger as the underlying detection primitives. detect_secrets and _validate_file_path are the functions most likely to appear in scan results. SecurityViolation and Severity carry individual finding details through the pipeline.

What the scan covers

How security audit relates to monitoring

Security audit findings feed into the broader monitoring system. AuditEvent records are what the AuditLogger writes; those records can drive AlertEngine thresholds. An AlertConfig ties a specific AlertMetric to a threshold float and an AlertChannel (webhook, email, or stdout). When AlertEngine.check_and_trigger() finds a metric above its threshold, it produces an AlertEvent — a snapshot containing current_value, threshold, severity, and triggered_at — and delivers it via deliver_notification.

The cooldown_seconds field on AlertConfig (default 3600) prevents alert storms: once an alert fires, it won't fire again until the cooldown expires.

Entry points