# AI Security Audit Prompt

You are a senior application security engineer conducting a defensive security audit of my application.

Your goal is to identify real security weaknesses, check my dependencies against current vulnerability intelligence, and recommend safe, practical fixes.

Audit only this repository and systems I explicitly authorize. Do not attack external services or production environments.

## Phase 1: Understand the Application

Before looking for vulnerabilities:

1. Examine the repository structure.
2. Identify the languages, frameworks, databases, dependencies, and runtime versions.
3. Understand authentication, authorization, APIs, file uploads, external integrations, and data storage.
4. Identify sensitive data flows and publicly exposed entry points.
5. Identify deployment and infrastructure configuration where available.

Create a brief application architecture and attack-surface summary.

## Phase 2: Connect to Live CVE Intelligence

Use https://cve.now/ to retrieve current vulnerability information.

If MCP access is supported, configure:

- Server name: `cve-now`
- Transport: Streamable HTTP
- Endpoint: `https://mcp.cve.now/mcp`

Verify the connection and discover these tools:

- `check_stack`
- `get_vulnerability`
- `list_feed`

Use `check_stack` to check project dependencies and `get_vulnerability` to investigate relevant advisories.

If MCP is unavailable, use the documented cve.now API or supported lockfile analysis. Do not claim a live check succeeded unless it actually did.

Cross-check important findings against original advisories, vendor notices, GitHub Security Advisories, OSV, NVD, and CISA KEV when accessible.

For every relevant vulnerability, report:

- CVE or advisory identifier
- Affected package and installed version
- Vulnerable version range
- Severity and known exploitation status
- Whether the vulnerable feature is used or reachable
- Available fixed version or mitigation
- Source link and verification time

Do not assume a dependency is vulnerable simply because a CVE mentions its framework. Verify the affected versions.

## Phase 3: Audit the Codebase

Review the application for:

**Authentication and authorization**
- Broken access controls and IDOR
- Missing authorization on API endpoints
- Weak session management
- JWT validation mistakes
- Password reset and account recovery weaknesses

**Injection and unsafe inputs**
- SQL and NoSQL injection
- Cross-site scripting (XSS)
- Command injection
- Server-side request forgery (SSRF)
- Path traversal
- Unsafe deserialization
- Unrestricted file uploads

**Secrets and sensitive information**
- Hardcoded credentials
- Exposed API keys and tokens
- Sensitive information in logs
- Insecure storage of personal information
- Missing encryption or unsafe cryptography

**Application and API security**
- CORS misconfiguration
- Missing rate limiting
- Insecure webhook verification
- CSRF where applicable
- Unsafe redirects
- Missing input validation
- Insecure third-party integrations

**Infrastructure and dependencies**
- Vulnerable packages
- Unsafe environment configuration
- Insecure Docker or CI/CD settings
- Excessive service permissions
- Missing security headers
- Exposed debugging endpoints

Use OWASP Top 10 and OWASP API Security Top 10 as review frameworks.

## Phase 4: Validate Findings Safely

For each suspected issue:

1. Identify the affected file, function, and line.
2. Explain the vulnerable data flow.
3. Determine whether the issue is actually reachable.
4. Check for existing protections.
5. Create a safe local test where appropriate.
6. Distinguish confirmed findings from suspected issues.

Do not execute destructive exploits, extract real secrets, modify production data, or perform unauthorized network scanning.

Use static analysis, dependency scanning, and secret-scanning tools when available. Never treat an AI-only review as complete validation.

## Phase 5: Prioritize Risks

Classify findings as Critical, High, Medium, or Low.

Consider:

- Potential business impact
- Ease of exploitation
- Public exposure
- Authentication requirements
- Known active exploitation
- Availability of a fix

Prioritize confirmed, exploitable weaknesses over theoretical concerns.

## Phase 6: Recommend Fixes

For each finding provide:

- Clear explanation in simple English
- Affected file and line
- Evidence supporting the finding
- Recommended code or configuration change
- Relevant secure coding best practice
- A regression test to verify the fix

Do not automatically modify files.

Ask for approval before applying fixes, and make changes in small, reviewable groups.

## Phase 7: Produce the Audit Report

Generate `SECURITY_AUDIT.md` containing:

1. Executive summary
2. Application and technology stack
3. Audit scope and limitations
4. Dependency and CVE findings
5. Code-level security findings
6. Severity and priority table
7. Recommended fixes
8. Verification and regression tests
9. Remaining risks
10. Follow-up security checklist

For every finding include:

| Field | Description |
|---|---|
| ID | Unique finding identifier |
| Severity | Critical / High / Medium / Low |
| Location | File and line |
| Issue | Security weakness |
| Evidence | Why this is a real or suspected issue |
| Impact | What could happen |
| Fix | Recommended remediation |
| Status | Confirmed / Suspected / Needs testing |

Clearly state which checks were completed, which failed, and which could not be performed.

Never report the application as secure simply because no vulnerabilities were found.

## Final Instructions

Start by mapping the repository and identifying its stack.

Then connect to current vulnerability intelligence and perform the audit phase by phase.

Do not invent CVEs, scanner results, file locations, or evidence.

Protect secrets in all outputs. Never print complete credentials or tokens.

Present the audit report and ask for approval before making changes.