Security Checker

Security scan Python skills before publishing to ensure code safety.

Quick Start

CODEBLOCK0

Examples:
CODEBLOCK1

What It Checks

Dangerous Imports

• - os - System-level operations
• INLINECODE1 - Command execution
• INLINECODE2 - File operations
• INLINECODE3 - Network operations
• INLINECODE4 / requests - HTTP requests

Why dangerous? These imports enable system command execution, file manipulation, and network access that could be exploited.

Dangerous Functions

• - os.system() - Executes shell commands
• INLINECODE7, subprocess.run(), subprocess.Popen() - Command execution
• INLINECODE10 - Executes arbitrary code
• INLINECODE11 - Executes arbitrary code

Why dangerous? These can execute arbitrary commands or code, leading to remote code execution vulnerabilities.

Hardcoded Secrets

• - API keys
• Auth tokens (including ClawHub tokens)
• Passwords
• Private keys
• JWT-like tokens

Why dangerous? Secrets leaked in published code can be stolen and abused.

Unsafe File Operations

• - Absolute file paths outside expected directories
• Parent directory traversal (..)
• Writing to system directories

Why dangerous? Could lead to unintended file access, data loss, or system modification.

Usage Pattern: Pre-Publish Checklist

Before publishing any skill:

CODEBLOCK2

Interpretation of Results

✅ "No security issues found"

⚠️ "Warning" (Yellow)

• - Is it legitimate? Document why in code comments or SKILL.md
• Can it be avoided? Refactor to safer alternatives
• Is it necessary? Clearly document the risk and purpose

🔴 "Possible hardcoded secret"

• - Remove the secret
• Use environment variables instead: INLINECODE13
• Document required env variables in SKILL.md
• Never commit real secrets

Examples

Legitimate os module usage (documented)

Scan result: ⚠️ Warning about os import
Action: Document safe usage pattern in code comments

Hardcoded secret (must fix)

Scan result: 🔴 Possible hardcoded secret
Action: Remove and use environment variable:
CODEBLOCK5

Safe pattern (no issues)

Scan result: ✅ No issues

Best Practices

1. 1. Always scan before publishing - Make it part of your workflow
2. Review warnings manually - The scanner can't judge context
3. Use environment variables for secrets - Never hardcode
4. Prefer json over eval - Safe parsing vs code execution
5. Document necessary risks - If dangerous code is required, explain why
6. Minimize dangerous imports - Only use what's truly necessary
7. Keep code simple - Complex code is harder to audit

Integration with Development Workflow

Before committing to repo

Automated pre-publish check

Limitations

This scanner:

• - Can't judge context - Some dangerous code may be legitimate
• Static analysis only - Doesn't execute code
• Python-focused - Other languages need different tools
• Basic patterns - Sophisticated obfuscation may evade detection

Complement with:

• - Manual code review
• Testing in isolated environment
• Reading through all code before publishing
• Using additional tools: bandit, INLINECODE15

Trust Building

Publishing skills that pass security scans builds trust in the community:

• - Users know you care about safety
• Your reputation improves
• Skills get adopted more readily
• ClawHub may highlight safe skills

Examples of Published Skills (All Scanned)

CODEBLOCK9

All three skills passed security scans before publishing to ClawHub.