agentleFS
Sign inStart free
Google CloudKnown publisherGoogleCloudPlatform/cloud-solutions/projects/build-with-gemini-demo/build-with-antigravity/.agents/skills/security-scan/SKILL.md

security-scan

Skill138 starsChanged 5 months agoApache-2.0View on GitHub

Performs a security audit of the project source code and dependencies to identify vulnerabilities and recommend remediations. Use when scanning the codebase for security issues. Don't use for functional unit testing or style-only code formatting.

We split this skill into the rules it gives an agent

5 rules. 0 are common, 2 are distinctive, and 3 are very specific to this project.

  • 0

    Common

    Most of the 74 edited versions we read keep these.

  • 2

    Distinctive

    This author's own choices. Worth a look.

  • 3

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Failure handling: If no source code or configuration files are found in the workspace, halt execution and notify the user.

    line 30
  2. Very specific:

    Injection flaws (CWE-89, CWE-78): Check for string concatenation or f-strings in SQL queries, shell commands (os.system or subprocess with …

    line 50
  3. Very specific:

    Hardcoded secrets and credentials (CWE-798): Check for hardcoded API keys, passwords, Flask secret_key literals, or tokens in source files.

    line 57
  4. Very specific:

    Authentication, authorization, and session security: Check cookie flags (HttpOnly, Secure, SameSite), access control on sensitive …

    line 59
  5. Distinctive:

    Ask the user which findings they want to remediate before modifying source files.

    line 81

“Common” is measured: kept by at least 6 in 10 of the 74 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Run security code scan

<!-- Disabling markdownlint MD029 to provide explicit ordering to avoid confusing the LLM. --><!-- markdownlint-disable MD029 --><!-- Disabling markdownlint MD030 to allow the list overflowing to numbers >=10. --><!-- markdownlint-disable MD030 -->

Prerequisites

  • Project source files: Application source code, templates, and dependency manifests (requirements.in and requirements.txt) present in the workspace.
  • Development standards: Workspace rules defined in .agents/rules/dev-rules.md.
  • Failure handling: If no source code or configuration files are found in the workspace, halt execution and notify the user.

Workflow

1. Discover attack surface and scope

  1. Enumerate all application source files, HTML templates, configuration files, and dependency manifests in the project (excluding venv/, .venv/, and __pycache__/).
  2. Identify trust boundaries, database queries, external service calls, and user input entry points such as HTTP query parameters, form submissions, JSON payloads, file uploads, and headers.

2. Analyze code for security vulnerabilities

Inspect the codebase against common vulnerability classes from the Open Worldwide Application Security Project (OWASP) Top 10 and Common Weakness Enumeration (CWE):

  1. Injection flaws (CWE-89, CWE-78): Check for string concatenation or f-strings in SQL queries, shell commands (os.system or subprocess with shell=True), or template rendering (render_template_string).
  2. Cross-Site Scripting (XSS, CWE-79) and Cross-Site Request Forgery (CSRF, CWE-352): Check HTML templates for unescaped variables (| safe or Markup) and verify state-changing POST/PUT/DELETE forms and routes enforce CSRF protection.
  3. Hardcoded secrets and credentials (CWE-798): Check for hardcoded API keys, passwords, Flask secret_key literals, or tokens in source files.
  4. Authentication, authorization, and session security: Check cookie flags (HttpOnly, Secure, SameSite), access control on sensitive endpoints, and input validation.
  5. Insecure configuration and error exposure (CWE-209, CWE-489): Check for debug mode enabled in code (debug=True), overly permissive CORS or host bindings, and raw stack traces returned to clients.
  6. Dependency and container hygiene: Review requirements.in and requirements.txt for unpinned packages, missing hashes, or known insecure library versions, and verify Dockerfile configurations (if present) against .agents/rules/dev-rules.md.

3. Generate security findings report

Present a structured security assessment report categorized by severity (Critical, High, Medium, Low):

  • Severity and category: Severity level and vulnerability class / CWE ID.
  • Location: File path and line numbers.
  • Impact: Explanation of how the issue could be exploited.
  • Recommended fix: Concrete code or configuration change to remediate the vulnerability.

Ask the user which findings they want to remediate before modifying source files.

4. Remediate and verify

  1. Upon user approval, apply the recommended security fixes to the affected files following .agents/rules/dev-rules.md.
  2. Re-inspect the modified files and run the project's test suite (if present) to verify that all vulnerabilities are resolved without breaking application functionality.
  3. Summarize the remediated vulnerabilities and verification results for the user.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

Reviews can't be read right now.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free