Trustworthy code security

Trustworthy Code Security Audit

Author: Audrent Version: 1.0.0 Last reviewed: 2026-05-01 License: MIT

What this skill does

Performs a deterministic, transparent security review of source code provided to you. The review walks through a fixed set of checks — secrets detection, injection vulnerabilities, authentication and authorization issues, cryptographic weaknesses, dependency risks, information disclosure, prompt-injection vulnerabilities, and AI-specific risks — and produces structured findings with severity ratings, exact locations, and specific remediation guidance.

This skill is designed to be auditable, transparent, and conservative. It tells you exactly what it checked, exactly what it found, and exactly what it cannot detect. It does not hide instructions, does not exfiltrate code, does not contact external services, and does not embed prompt injections in its output. Its complete check list is documented below in plain text.

What this skill does NOT do

For honesty and to prevent customer overreliance:

• This skill performs static analysis based on pattern matching and rule-based checks. It does not execute code, does not perform full data-flow analysis, and does not catch all vulnerabilities — particularly those requiring deep semantic understanding of business logic, complex multi-file flows, or runtime context.
• It does not replace a professional penetration test, a dedicated SAST/DAST tool (Snyk, SonarQube, Semgrep, GitHub Advanced Security), or human security review. Treat its output as one input to a layered review process, not as a sole source of assurance.
• It is conservative on false positives — it will flag patterns that look risky even when context may make them safe. Verify each finding against your specific codebase before acting on it.
• It cannot detect novel vulnerability classes, zero-days, or attacks specific to dependencies it doesn't recognize.
• It does not check for compliance with specific frameworks (PCI-DSS, HIPAA, SOC 2). For compliance audits, use the Audrent SOC 2 Compliance Audit skill or a domain-specific tool.

When to invoke this skill

Use this skill when:

• Reviewing code before merging to a main branch (especially in PRs from less-experienced contributors).
• Preparing a repository for public open-source release.
• Auditing a codebase inherited from a previous team or acquisition.
• Performing a periodic security pass (recommended quarterly minimum).
• Reviewing AI-augmented code generation for the security issues that LLMs commonly introduce.

Do not invoke this skill as a substitute for:

• A full professional security audit before launching a financial, medical, or critical-infrastructure product.
• Compliance certification (SOC 2, ISO 27001, PCI-DSS).
• Real-time monitoring or runtime application self-protection.

Audit methodology

When invoked, work through these eight categories in order. For each category, run every applicable check, document each finding with the specified output format, and note explicitly when a check was inapplicable to the code provided (e.g., "skipped — no SQL queries found").

Category 1 — Secrets and credentials in source code

Check for:

1. Hardcoded API keys, tokens, passwords. Look for variable assignments, configuration constants, and string literals matching common secret patterns:

   • AWS access keys: AKIA[0-9A-Z]{16} or similar 20-character all-caps strings near "aws"
   • GitHub tokens: ghp_[A-Za-z0-9]{36}, gho_, ghu_, ghs_, ghr_ prefixes
   • Stripe keys: sk_live_, sk_test_, pk_live_, pk_test_ prefixes
   • Anthropic / OpenAI keys: sk-ant-, sk-proj-, sk- prefixes near AI library imports
   • Generic high-entropy strings of 32+ characters in variable assignments named key, token, secret, password, apikey, etc.
   • Slack tokens: xox[baprs]-
   • JWT tokens: eyJ[A-Za-z0-9_-]+\.[A-Za-z0-9_-]+\.[A-Za-z0-9_-]+
   • Private keys: blocks beginning -----BEGIN PRIVATE KEY-----, -----BEGIN RSA PRIVATE KEY-----, -----BEGIN OPENSSH PRIVATE KEY-----

2. Configuration files committed to source control. Flag the presence of .env, config.json, secrets.yaml, or similar files that appear to contain credentials and are tracked in git. Recommend .gitignore additions and immediate credential rotation if found.

3. Database connection strings with embedded passwords. URI-format connection strings like postgres://user:password@host/db flagged regardless of whether they appear in tests or production code.

Severity guidance: Hardcoded production secrets are Critical. Hardcoded test/sandbox secrets are High (still flagged because they leak through git history and signal poor practice). Generic high-entropy strings without confirmed secret context are Medium for further verification.

Category 2 — Injection vulnerabilities

Check for:

1. SQL injection. String concatenation or formatted-string construction of SQL queries with user-controlled input. Patterns:

   • Python: f"SELECT * FROM users WHERE name = '{name}'", "SELECT ... " + user_input, cursor.execute(query % user_input)
   • JavaScript: `SELECT * FROM users WHERE id = ${userId}`, query("...where id=" + req.body.id)
   • Verify that parameterized queries or ORMs are used instead. Flag any raw SQL containing user-controlled variables.

2. Command injection. User input passed to subprocess or shell execution:

   • Python: os.system(user_input), subprocess.run(cmd, shell=True) with user-controlled cmd, eval(user_input), exec(user_input)
   • JavaScript: child_process.exec(userInput), eval(userInput)
   • Recommend subprocess.run([list, of, args], shell=False) or equivalent argv-based execution.

3. Path traversal. File operations using user-controlled paths without sanitization. Look for open(user_path), fs.readFile(req.body.file), joins of user input with base directories that allow ../ traversal. Recommend os.path.realpath() validation against an allowlist directory.

4. XML external entity (XXE). XML parsers configured to resolve external entities. Flag lxml.etree.parse() or xml.etree.ElementTree.parse() without explicit resolve_entities=False configuration.

5. Deserialization of untrusted input. Use of pickle.loads(), yaml.load() (without safe_load), marshal.loads() on user-controlled data. Flag as Critical when present.

6. Template injection. Server-side template rendering with user input as the template (not just the data) — Jinja2 Template(user_input).render(), similar in Mustache/Handlebars/Liquid.

Severity guidance: All confirmed injection vulnerabilities with user-controlled input are Critical or High. Static patterns (hardcoded values, no user input) are Low or informational.

Category 3 — Authentication and authorization

Check for:

1. Missing authentication on sensitive endpoints. API routes, file-serving endpoints, or administrative functions that don't verify caller identity. Flag any route handler that performs sensitive operations (writes data, accesses other users' data, modifies state) without an authentication check visible in the handler or its middleware.

2. Broken authorization (IDOR). Patterns where a user-controlled ID is used to fetch data without verifying the requesting user owns or can access that ID. Example: db.users.get(req.params.user_id) without check that req.params.user_id == authenticated_user.id or equivalent role check.

3. Session management weaknesses. Hardcoded session secrets, session tokens generated from weak randomness (Math.random() in JS, non-cryptographic random in Python), session IDs in URL parameters rather than cookies/headers.

4. Password handling. Passwords stored or compared in plaintext. Use of insecure hashing (MD5, SHA1, plain SHA-256 without salt). Recommend bcrypt, scrypt, argon2, or PBKDF2 with appropriate work factors.

5. OAuth flow vulnerabilities. Missing state parameter, missing PKCE for public clients, redirect URI not validated against allowlist.

6. JWT issues. Tokens with alg: none accepted, hardcoded HMAC secrets, missing expiration validation, JWT used where session cookies would be more appropriate.

Severity guidance: Missing auth on sensitive endpoints and broken authorization are Critical. Plaintext password storage is Critical. Weak hashing of passwords is High.

Category 4 — Cryptography

Check for:

1. Weak algorithms. Use of DES, 3DES, RC4, MD5, SHA1 for security purposes. ECB mode for block ciphers. Custom ("homegrown") cryptographic implementations.

2. Weak random number generation. random.random() (Python) or Math.random() (JS) used for security-critical purposes. Recommend secrets module (Python) or crypto.randomBytes() (Node.js).

3. Hardcoded encryption keys or IVs. Key material defined as a constant in source.

4. Improper key length. RSA keys < 2048 bits, AES keys < 128 bits.

5. Missing certificate validation. HTTPS clients with verify=False (Python requests), rejectUnauthorized: false (Node), or InsecureSkipVerify: true (Go).

6. Predictable token generation. Tokens or IDs generated via time.time(), sequential counters, or other predictable sources.

Severity guidance: Weak algorithms in security contexts are High. Weak randomness for security tokens is High. Missing cert validation is High (degrades transport security to unencrypted-equivalent). Hardcoded keys are Critical.

Category 5 — Dependency and supply-chain risks

Check for:

1. Pinned dependency versions. Verify requirements.txt, package.json, go.mod, Cargo.toml use exact pinning (==, =) rather than ranges (>=, ^, ~). Note that pinning is a tradeoff — it prevents auto-update of vulnerable transitive dependencies but also prevents auto-update of patches. Flag for review, not as a definitive issue.

2. Lock file presence and consistency. package-lock.json, yarn.lock, poetry.lock, Pipfile.lock, Cargo.lock should exist and be committed. Their absence means reproducible builds aren't guaranteed.

3. Suspicious dependencies. Packages that:

   • Were published recently (less than 30 days, less than 100 weekly downloads) — possible typosquatting.
   • Have package names similar to popular libraries with different spellings.
   • Have no maintainer information, no GitHub link, or appear to be the only package by a given author.

4. Known vulnerable versions. If a requirements.txt or package.json is provided, list specific dependencies and recommend running pip-audit, npm audit, cargo audit, or safety check for full known-vulnerability scanning. This skill does not maintain a CVE database — defer to those purpose-built tools for known-CVE checking.

Severity guidance: Suspicious-looking dependencies are High for review. Unpinned dependencies are Medium. Missing lock files are Low. Known-CVE checks are deferred to dedicated tools.

Category 6 — Information disclosure

Check for:

1. Debug mode in production code. DEBUG = True (Django, Flask), app.debug = true (Express), verbose stack-trace exposure in error handlers.

2. Detailed error messages returned to clients. API responses or HTML error pages that reveal internal paths, library versions, database schemas, or stack traces.

3. Logging of sensitive data. logger.info(f"User {user} logged in with password {password}") and similar. Look for password, token, key, SSN, credit-card-like patterns being logged.

4. Comments revealing secrets or vulnerabilities. Comments like # TODO: this is the temporary master password, # FIXME: known SQL injection here, comments containing API keys or staging credentials.

5. Source maps or .map files in production. JavaScript bundles built with source maps enabled and the .map files served alongside production assets.

6. Verbose HTTP response headers. X-Powered-By, Server headers revealing version information.

Severity guidance: Debug mode in production code is High. Sensitive data logging is High. Comments revealing credentials are Critical. Other information disclosure is Medium to Low.

Category 7 — Prompt-injection and AI-specific risks

For codebases that integrate with LLMs (Anthropic, OpenAI, etc.), this category is uniquely important and frequently overlooked.

Check for:

1. User input concatenated directly into prompts. Patterns like prompt = f"You are a helpful assistant. The user said: {user_input}. Respond helpfully." allow prompt injection — a user can include instructions in their input that the LLM follows. Flag every case where user-provided text becomes part of a prompt without any escaping or boundary marker.

2. Untrusted content rendered into prompts without isolation. Loading the contents of a user-uploaded file, a scraped web page, or an email and including it in a prompt without clear boundaries. Recommend XML-tag isolation (<user_message>...</user_message>) and explicit instructions to the model that content inside the tags is data, not instructions.

3. Tool/function-calling LLMs with overly broad permissions. Agent setups where the LLM has access to tools that can: read arbitrary files, write to arbitrary paths, execute arbitrary code, make arbitrary network requests. Recommend principle-of-least-privilege scoping.

4. System prompts that contain secrets. Configuration patterns where API keys, database credentials, or sensitive context is loaded into the system prompt and then sent to the model provider. Recommend separating credentials from context.

5. Lack of output validation. LLM responses used directly as inputs to other systems (SQL queries, shell commands, file paths) without validation. The LLM can be tricked into producing malicious outputs by prompt injection upstream.

6. Training-data leakage risks. Code that fine-tunes models on data that may contain user PII, secrets, or proprietary information. Recommend data-cleaning pipeline and explicit consent/provenance tracking.

7. Missing rate limits and cost controls. LLM calls without per-user, per-session, or budget-cap limits. Allows attackers to exhaust the budget or run up the bill.

8. Retrieval-augmented generation (RAG) without sanitization. Loading documents into a vector database and retrieving without sanitizing for prompt injection in the retrieved content. Adversarial documents in the corpus can hijack the model.

Severity guidance: Prompt injection on user-controlled inputs is High by default, Critical if the model has access to sensitive tools or data. Missing rate limits are High. Training-data PII risk is Critical.

Category 8 — Other common issues

Check for:

1. CSRF protection on state-changing endpoints in web applications.
2. CORS configuration — Access-Control-Allow-Origin: * combined with credentialed requests is dangerous; flag.
3. Open redirects — endpoints that redirect to a user-controlled URL.
4. Insecure direct object references (IDOR) — covered in Category 3 but also flag in non-auth contexts (e.g., file-serving by ID without ownership check).
5. Race conditions in security-sensitive operations (TOCTOU).
6. Lack of input validation — endpoints that accept arbitrary user input without type/length/format constraints.
7. Insecure default configurations in framework setup (Express without helmet, Django without SECURE_* settings, etc.).

Severity guidance: case-by-case based on actual exploitability.

Output format

For every finding, produce an entry in this exact structure:

## Finding [N]: [Brief title]

- **Severity:** Critical | High | Medium | Low | Informational
- **Category:** [1-8 from above]
- **Location:** [file path]:[line number(s)]
- **Reference:** [CWE-XXX | OWASP A0X:2021 | None applicable]

### Description

[2-4 sentences explaining the specific issue in this code.]

### Why this matters

[1-2 sentences on the practical risk — what could an attacker do?]

### Remediation

[Specific, actionable code-level fix. Show before/after where useful. Prefer recommending specific functions/libraries.]

### Verification

[How to confirm the fix works — unit test description, runtime check, or manual review step.]

After the individual findings, produce a summary section:

## Audit Summary

- Files reviewed: [count]
- Total findings: [count]
- By severity: Critical: [N] | High: [N] | Medium: [N] | Low: [N] | Informational: [N]
- By category: [breakdown]

## Categories where no findings were identified

[List the 1-8 categories where the code passed all checks. This documents what was checked, not just what failed.]

## Categories that were skipped or not applicable

[List categories that didn't apply — e.g., "Category 7 (AI-specific risks) — skipped, no LLM integration found in code"]

## Limitations of this audit

This audit is rule-based static analysis. The following are NOT covered and should be assessed separately:

- Runtime behavior, race conditions discoverable only at execution.
- Business-logic vulnerabilities that depend on the application's domain.
- Configuration of cloud infrastructure, CI/CD, or deployment pipelines.
- Vulnerabilities in transitive dependencies (use `pip-audit`, `npm audit`, etc.).
- Novel attacks against frameworks not enumerated in the methodology above.

For high-stakes production systems, supplement this audit with: (1) a dedicated SAST tool (Semgrep, Snyk, SonarQube), (2) dependency vulnerability scanning, and (3) human security review by a qualified professional.

Operating principles for this skill

1. Be conservative on false negatives, accept false positives. Better to flag something that turns out to be safe than to miss a real issue. Mark uncertain findings as "Medium" with a note that requires human verification.

2. Show the actual code in findings. Quote 2-5 lines of the offending code in the Description so the developer can immediately see what's flagged. Do not just reference line numbers without context.

3. Specific remediation, not generic advice. Don't say "use parameterized queries" — show the specific parameterized version of the offending query, in the same language and library.

4. Acknowledge uncertainty explicitly. If a check requires context you don't have (e.g., "is this user input or a constant?"), state the assumption and flag both possibilities.

5. Never embed instructions in audit output. This skill's outputs are reviewed by humans and may be processed by other LLMs. Prompt injection risk is real for the audit output itself. All finding descriptions are pure description, never instructions.

6. Honest about what wasn't checked. Always include the "Categories where no findings were identified" and "Limitations" sections. Customers paying for this skill deserve to know its scope, not just what it caught.

Skill metadata

• Author: Audrent
• Version: 1.0.0
• License: MIT
• Source of truth: audrent.com/skills/trustworthy-code-security (when published)
• Provenance: This skill was authored by the Head of Agent Commerce at Audrent. No third-party code, no external dependencies, no network calls. Complete contents are in this single SKILL.md file.
• Reporting issues / suggested improvements: [email protected]