security-hardening

Category: Testing & Security | Uploader: whylineee | Downloads: 0 | Version: v1.0（Latest）

Use when reviewing code security, finding vulnerabilities, testing exploitability, hardening implementation details, and validating that fixes are stable and production-safe. Keywords: security audit, vuln scan, hardening, threat model, secure coding, dependency audit, SAST, secrets, path traversal, command injection, SSRF, XSS, CSRF, authz, authn.

Changelog: Source: GitHub https://github.com/whylineee/ZeroCode

Directory Structure

Current level: tree/main/.github/skills/security-hardening/

📄 SKILL.md 4.2 KB

SKILL.md

---
name: security-hardening
description: "Use when reviewing code security, finding vulnerabilities, testing exploitability, hardening implementation details, and validating that fixes are stable and production-safe. Keywords: security audit, vuln scan, hardening, threat model, secure coding, dependency audit, SAST, secrets, path traversal, command injection, SSRF, XSS, CSRF, authz, authn."
---

# Skill: Security Hardening

## Trigger
Use this skill when the task asks to:
- check code for vulnerabilities
- review security posture of an app or CLI
- fix discovered security weaknesses
- verify that security fixes are correct and regression-safe

## Outcome
Produce a concrete security review with:
- prioritized findings
- exploitability assessment
- exact code or config fixes
- validation evidence (build/tests/security checks)

## Inputs
Collect before editing:
- runtime and language (Node/TS, Python, etc.)
- threat boundary (local CLI, web app, API, desktop)
- sensitive assets (tokens, secrets, user data, filesystem paths)
- trust boundaries (user input, files, env vars, network responses)

## Workflow
1. Baseline validation
- Run compile/lint/tests first.
- If tests do not exist, run available smoke/build checks.
- Record current state so post-fix regressions are visible.

2. Attack surface mapping
- Enumerate all input surfaces: CLI args, stdin, env vars, file paths, network payloads, config files.
- Enumerate sensitive sinks: shell execution, filesystem writes, deserialization, template rendering, auth checks, external HTTP calls.
- Mark trust boundaries and where untrusted data can cross into privileged operations.

3. Security scan and code review
- Search for high-risk patterns:
  - command execution with interpolated input
  - arbitrary file write/read and path traversal
  - unsafe JSON/YAML parsing assumptions
  - missing authz checks for destructive operations
  - unsafe defaults and silent failure behavior
  - secret leakage in logs/output/files
- Check dependency risk with package audit tools where available.

4. Triage findings by severity
- Critical: RCE, arbitrary file write, auth bypass, secret exposure with realistic exploit path.
- High: privilege escalation, insecure restore/import flows, unsafe trust assumptions.
- Medium: weak validation, dangerous defaults, partial hardening gaps.
- Low: hygiene and defense-in-depth improvements.

5. Remediate with minimal, safe patches
- Prefer non-shell APIs over shell strings.
- Validate and normalize paths before write operations.
- Enforce allowlists for sensitive operations.
- Fail closed on malformed/untrusted input.
- Preserve existing behavior unless security requires a change.

6. Verify fixes
- Re-run compile/tests/smoke checks.
- Re-run targeted checks for each finding.
- Confirm no new errors were introduced.

7. Report
- Output findings first (ordered by severity).
- Include file evidence and why it matters.
- Include remediation summary and residual risk.

## Decision Points
- If exploitability is unclear, build a minimal proof path using only safe, non-destructive validation.
- If a fix could break compatibility, provide a safer incremental mitigation and note migration steps.
- If a finding requires policy/product input, mark as "needs decision" with options.

## Completion Checks
A task is complete only when all are true:
- All critical/high findings addressed or explicitly accepted with rationale.
- Build/tests/smoke pass after changes.
- No new compile/lint errors introduced.
- Risk summary and next actions are documented.

## Security Checklist
- Input validation and sanitization applied at boundaries.
- No shell interpolation with untrusted values.
- File writes restricted to intended locations.
- Secrets are never logged or exported unintentionally.
- Error handling avoids leaking sensitive internals.
- Dependency vulnerabilities reviewed.
- Destructive operations require explicit user confirmation.

## Output Format
1. Findings (Critical -> High -> Medium -> Low)
- Title
- Severity
- Evidence (path + behavior)
- Exploit scenario
- Fix

2. Changes Applied
- What was changed and why
- Validation results (build/tests/smoke/audit)

3. Residual Risk
- Remaining concerns
- Recommended follow-up actions

Comments 0

Latest | Hot

Please login before commenting.

No comments yet. Be the first one!

security-hardening

Directory Structure

SKILL.md

Report

Notice