mondoohq/secure-stack/secure-coding

Secure Coding

Proactively avoid generating vulnerable code. When writing, reviewing, or modifying code, check against the pattern tables in this skill to use safe alternatives instead of dangerous patterns.

When to Use

• Reviewing code for security issues
• Writing new code that handles user input, secrets, HTTP requests, file I/O, or crypto
• Answering "is this safe?" or "how do I securely..." questions
• Generating code that touches authentication, authorization, or data validation

When NOT to Use

• Authoring detection rules (use the author-detections skill)
• Triaging existing SAST scan findings (use the triage-findings skill)
• Non-security code questions (algorithms, performance, etc.)

Detecting Intent

Code review: User shares code or asks to review a file/PR for security issues. Secure alternative: User asks how to do something safely ("how do I compare secrets in Go?"). Proactive: User is writing code that touches a security-sensitive area.

Quick Reference -- Most Critical Patterns

Never Do This

References

• Full per-language pattern tables: references/patterns.md
• Real CVE code examples: references/cve-examples.md

OWASP Top 10:2025 alignment

This skill is the write-it-securely-first layer for the application categories of OWASP Top 10:2025. The patterns above map to:

A06:2025 Insecure Design is a design/threat-modeling concern no static check can decide — this skill reduces it proactively, but it stays a review-and-design item.

OWASP Top 10 for LLM & GenAI 2025 (when the code is an LLM/GenAI app)

Two categories are code-level and belong here:

• LLM02 Sensitive Information Disclosure — never put secrets or PII in prompts, model

inputs, logs, or error text; the "no secrets in log output" check applies to prompts too.

• LLM05 Improper Output Handling — treat an LLM's output as untrusted input. Never

pass it into eval/exec, a shell, SQL, a file path, or raw HTML/markup without the same validation you would apply to user input.

The full engine coverage (what xgrep and cnspec detect, with honest Strong/Partial/N/A levels) is in `docs/owasp.md`; once code is written, the secure-pipeline skill scans, gates, and fixes it before it ships.

If xgrep guard Blocks an Action

When the xgrep guard hook blocks a prompt or tool call, it names the rule and where it matched (never the value). Treat that as a security finding, not an obstacle:

• Never work around it. Don't rephrase, split, encode or move the command into a

script to get past the guard, and don't edit, disable or uninstall the hook.

• Explain and ask. Tell the user which rule fired, why it is risky, and offer a

safe alternative (download, inspect, then run; read a secret from the environment).

• Treat a flagged secret as exposed. Recommend rotating it and remove it from the

content instead of retrying.

• The allowlist is the user's call. Only the user adds rule ids to

.xgrep/guard-allow.txt.

Review Checklist

When reviewing code, check for these in order:

Security Review:
- [ ] Secret comparison uses constant-time function
- [ ] SQL queries use parameterized placeholders
- [ ] No eval/exec/compile on untrusted input
- [ ] HTTP requests validate URLs against allowlist
- [ ] File paths validated against base directory
- [ ] Deserialization uses safe loaders with type restrictions
- [ ] JWT decoding specifies allowed algorithms
- [ ] TLS >= 1.2, certificate validation enabled
- [ ] Crypto RNG used for security values (not math/rand)
- [ ] No secrets in log output
- [ ] CORS restricted to specific origins
- [ ] HTTP response headers don't include unsanitized user input
- [ ] File creation uses atomic mode setting (no chmod race)
- [ ] XSS: output encoded for context (HTML, JS, URL)