Security Audit & Scan

Before you hand off a project to a client, you need to be certain the codebase is clean — no hardcoded credentials, no vulnerable packages, no obvious injection points. Sun Agent Kit’s security scanning agents automate the entire compliance check, generating a structured report with severity-graded findings that you can attach directly to your delivery email.

Overview

Goal: Produce a signed-off security report before any client release or code handoff
Time: 5–15 minutes (vs 2–4 hours of manual review)
Agents used: scout, reviewer, debugger
Commands: /sk:security-scan, /sk:security-scan --full, /sk:security-scan --secrets-only, /sk:security-scan --deps-only

Prerequisites

  • Sun Agent Kit installed and authenticated (installation guide)
  • A git repository with committed source code (unstaged changes are also scanned)
  • package.json, requirements.txt, Gemfile, or go.mod present for dependency auditing
  • Node.js ≥ 18 or Python ≥ 3.10 in PATH (for native audit runners)

Step-by-Step Workflow

Step 1: Run the baseline secrets scan

Start with the fastest, highest-impact check — secrets and credentials leaked into source files.

/sk:security-scan --secrets-only

What happens: The agent:

  1. Scans the source tree using regex patterns to detect hardcoded API keys, tokens, private keys, and database connection strings
  2. Checks recent git history for secrets that may have been committed and removed
  3. Filters out false positives from test fixtures and example values
  4. Reports findings categorized by severity

Step 2: Run the dependency audit

Check all packages against known vulnerability databases.

/sk:security-scan --deps-only

What happens: The agent:

  1. Resolves the full dependency tree including transitive dependencies
  2. Runs npm audit, pip audit, or equivalent for your package manager
  3. Checks for license compliance issues
  4. Reports vulnerable packages with severity and recommended upgrade paths

Step 3: Run OWASP pattern analysis on application code

Detect common vulnerability patterns — SQL injection, XSS vectors, insecure deserialization, and path traversal.

/sk:security-scan --full

What happens: The agent:

  1. Combines secrets scanning, dependency auditing, and code pattern analysis in one pass
  2. Analyzes code for OWASP Top 10 patterns using grep and Claude’s reasoning
  3. Cross-references findings to identify exploit chains
  4. Produces a consolidated report saved to plans/reports/

Step 4: Fix findings and re-scan

For each finding, use /sk:fix to apply targeted remediation.

/sk:fix "fix the security findings from the scan report in plans/reports/"

What happens: The agent:

  1. Reads the scan report and prioritizes CRITICAL and HIGH findings
  2. Applies fixes — rotating hardcoded keys to environment variables, upgrading vulnerable packages, parameterizing raw queries
  3. Re-scans patched code to confirm the fix

Step 5: Re-scan and confirm clean state

After fixing, run a final verification pass before attaching the report to the delivery.

/sk:security-scan --full

What happens: The agent re-runs the full scan and produces an updated report. Confirm that no CRITICAL or HIGH findings remain before delivery.

Complete Example: Japanese PM Requests Security Audit Before Release

Scenario

Your team has spent six weeks building a SaaS dashboard for a Japanese enterprise client. The PM sends a Slack message at 10 PM: “Our compliance officer needs a security report by tomorrow morning before we approve the production release.” You have the codebase, no dedicated security engineer, and eight hours.

Commands chained

# 1. Full scan to triage the situation
/sk:security-scan --full

# 2. Fix anything CRITICAL or HIGH
/sk:fix "fix all CRITICAL and HIGH findings from the security scan report"

# 3. Re-scan to confirm clean state
/sk:security-scan --full

# 4. Generate client-facing documentation
/sk:docs "generate security audit summary for client delivery"

Result

Within an hour you have a clean security audit report. Executive summary in clean markdown, severity breakdown, per-finding remediation notes. The PM attaches it to the compliance submission and the release goes live on schedule.

Time Comparison

TaskManualWith Sun Agent Kit
Secrets grep across repo + git history45 minminutes
npm audit / pip-audit + CVE triage60 minminutes
OWASP pattern review (manual code read)90 minminutes
Writing consolidated client report45 minminutes
Applying fixes and re-scanning30 minminutes
Total~4.5 hoursunder 30 minutes

Best Practices

1. Scan before every PR merge to production ✅

Run /sk:security-scan --secrets-only as a pre-merge check, not just at release time. Catching a hardcoded key in a PR is a two-minute fix; catching it after a production deploy is a two-day incident.

2. Use --secrets-only and --deps-only for fast targeted checks ✅

The full scan covers everything but takes longer. During development, use the targeted flags to check specific categories quickly. Save --full for pre-release gates.

3. Never suppress CRITICAL findings without a written justification ❌

It is tempting to mark a CRITICAL as “accepted risk” to ship faster. Do not do this without a written note in the report explaining the compensating control. Clients — especially Japanese enterprise clients — will ask, and “we ignored it” is never an acceptable answer.

4. Do not scan on developer machines and call it done ❌

Always run the final verification scan in CI or on the same environment that will build the release artifact. Developer machines may have .env files excluded by local .gitignore rules that do not reflect what is actually committed.

Troubleshooting

Problem: Scanner reports findings in node_modules/ or vendor directories

Solution: Scope the scan to your application source by specifying the directory: /sk:security-scan src/. The dependency auditor handles vendored packages separately via npm audit.

Problem: CVE database query times out

Solution: Check your network connection. If behind a corporate proxy, set the HTTP_PROXY environment variable. You can also run npm audit or pip audit manually and paste the output to /sk:ask for analysis.

Problem: False positive on a test fixture that contains a dummy API key

Solution: Review the findings in the report and note the false positive. You can re-run with a more targeted scope that excludes test directories: /sk:security-scan src/ --secrets-only.

Problem: Dependency audit shows a vulnerability in a transitive dependency

Solution: Run /sk:fix "upgrade transitive dependency [package-name] to resolve CVE-XXXX". For transitive conflicts that cannot be resolved directly, the agent will suggest an override or alternative package.

Next Steps

  • Code Review — Run a full quality gate alongside the security scan before delivery
  • Generate Documentation — Attach handoff docs to the same delivery package as the security report
  • Refactor Legacy Code — Eliminate structural issues that repeatedly produce security findings

Key takeaway: A security audit that used to consume half a working day can run unattended in under 20 minutes — giving your team the confidence to ship on tight client deadlines without skipping compliance.