Scan secrets, dependencies, and code patterns with ak:security-scan

Use ak:security-scan for a fast, read-only pass over hardcoded credentials, dependency advisories, and common vulnerable code patterns. It combines search patterns with surrounding-code analysis so likely matches can be separated from obvious placeholders and false positives.

Choose ak:security-scan for fast triage

Use ak:security-scan when

• You want a pre-release check for secrets and known dependency issues.
• A focused directory needs a quick OWASP-style pattern review.
• You need findings and fix recommendations without changing code.
• You want to decide whether a deeper threat-modelled audit is warranted.

Choose another workflow when

• You need STRIDE coverage, attacker personas, or iterative remediation. Use ak:security.
• You need penetration testing, runtime security analysis, infrastructure validation, or a compliance audit; those are outside this Skill's scope.
• You want findings fixed automatically. Hand confirmed evidence to ak:fix or run ak:security with explicit fix authority.

Prepare the scan

Before you start:

• Complete Onboarding, and confirm Engineer Kit is installed for the current runtime and scope.
• Run from the project root or provide a specific directory such as src/api/.
• Make manifests, lockfiles, .gitignore, and the relevant source available.
• If dependency evidence matters, ensure npm audit or pip audit is available for the documented Node.js and Python paths.
• Approve network access only if the selected package audit requires its advisory service.

Select a scan mode

With no arguments, the Skill scans the current project. Secret scanning always runs first in the normal full workflow.

/ak:security-scan src/api/

/ak:security-scan src/api/

$ak:security-scan src/api/

Use --secrets-only when credential exposure is the only question. Use --deps-only when you intentionally accept the package auditor's network and process behavior.

Understand what the scanner observes

1. The Skill detects the project type. It checks Node.js, Python, Go, and Rust manifests to understand the repository surface.
2. It scans secrets first. Structured and generic patterns cover provider tokens, private keys, connection strings, passwords, and bearer tokens while excluding obvious examples, tests, docs, dependencies, and build output.
3. It audits supported dependencies. Node.js uses npm audit; Python uses pip audit when available. Failures remain explicit rather than becoming a clean result.
4. It searches vulnerable patterns. SQL injection, XSS, command injection, path traversal, insecure randomness, dynamic evaluation, unsafe deserialization, disabled TLS, and sensitive logging receive targeted checks.
5. It reads context. Each likely code match is inspected around the source location to distinguish a vulnerability from a safe use or fixture.
6. It checks .env exposure. Git tracking and .gitignore patterns are inspected for common environment files.
7. It returns the report. Findings are grouped by category and severity with locations and fix recommendations.

Keep the scan read-only and evidence redacted

• The standalone workflow does not modify code, commit, push, open a pull request, merge, release, or deploy.
• When another automatic cook workflow invokes the scanner, it can save a Markdown report under that workflow's configured report path; otherwise the report is returned directly in chat.
• Package audit tools may read manifests and lockfiles, contact registries, populate caches, and consume provider resources. The Skill defines no independent external charge.
• A regex match is not proof of exploitability. Preserve the pattern, location, context, and reasoning used to classify it.

Verify the report

A complete scan should provide:

• Project identity, scan date, scope, and number of files checked.
• Critical, High, Medium, and Low counts for secrets, dependencies, and code.
• Redacted findings with category, source location, context, severity, and a specific fix recommendation.
• The dependency-audit result or a clear missing-tool or network failure.
• .env tracking and ignore evidence.
• Explicit boundaries for categories, directories, or tools that were skipped.

The release packages contain the same ak:security-scan source and references. No directly scoped end-to-end test proves live package-registry results or cross-runtime scanner parity, so treat the report as evidence from the actual commands and files observed in the current run.

Troubleshoot and interpret limits

Continue with ak:security when triage shows a trust boundary that needs deeper threat modelling.