Skill: ivangdavila/security-best-practices (version 1.0.0)

--- name: Security Best Practices slug: security-best-practices version: 1.0.0 homepage: https://clawic.com/skills/security-best-practices description: Review code with secure-by-default standards, prioritize exploitable risks, and deliver minimal-diff fixes with evidence and regression checks. changelog: Added a complete security review workflow with evidence standards, severity modeling, and minimal-risk remediation guidance. metadata: {"clawdbot":{"emoji":"🛡️","requires":{"bins":[],"config":["~/security-best-practices/"]},"os":["linux","darwin","win32"]}} --- ## Setup On first use, read `setup.md` for integration guidelines. If local memory is needed, ask for consent before creating `~/security-best-practices/`. ## When to Use Use this skill for secure-by-default implementation, targeted vulnerability reviews, and prioritized security reports with actionable fixes. Activate when the user requests security guidance, hardening, risk triage, or remediation planning. ## Architecture Memory lives in `~/security-best-practices/`. See `memory-template.md` for setup. ```text ~/security-best-practices/ |- memory.md # Stable context, preferences, and activation boundaries |- findings-log.md # Findings registry with severity and status `- exceptions.md # Approved security exceptions and review dates ``` ## Quick Reference Load only the minimum file needed for the current request. | Topic | File | |-------|------| | Setup process | `setup.md` | | Memory template | `memory-template.md` | | Full review workflow | `review-playbook.md` | | Severity model and scoring | `severity-model.md` | | Safe remediation patterns | `remediation-patterns.md` | | Risk exception log | `exceptions.md` | ## Core Rules ### 1. Establish Scope and Evidence First Before any conclusions, confirm: - System boundary (service, module, endpoint, or workflow) - Stack evidence (language, framework, deployment context) - Threat assumptions (external attacker, internal misuse, privilege level) No evidence, no finding. ### 2. Map Risks to a Repeatable Baseline Evaluate every review against a consistent baseline: - Authn/authz boundaries - Input validation and output encoding - Secrets handling and configuration safety - Dependency and supply chain posture - Logging, error handling, and data exposure controls Use `review-playbook.md` to keep scans systematic instead of ad hoc. ### 3. Produce Findings That Are Verifiable Each finding must include: - Severity from `severity-model.md` - File path and line references - Concrete evidence snippet - Impact statement in plain language - Minimal safe fix direction Avoid speculative findings without repository evidence. ### 4. Prioritize Exploitability Over Theory Rank by practical risk, not by checklist volume: - Reachability from untrusted inputs - Privilege required by attacker - Blast radius if exploited - Ease of abuse and repeatability High confidence, exploitable issues come first. ### 5. Remediate With Minimal Product Risk Fix one finding at a time: - Prefer small diffs that preserve existing behavior - Add tests when security fixes alter code paths - Flag expected behavior changes before implementing - Re-run project validation after each fix batch Use `remediation-patterns.md` for safe rollouts. ### 6. Respect Explicit Exceptions and Ownership If the user accepts a known risk: - Record rationale in `exceptions.md` - Define expiry or next review date - Keep the exception scoped to the specific context Never apply broad silent overrides. ## Security Review Traps - Reporting generic best practices without file evidence -> low-trust output that teams cannot action. - Flooding with low-severity noise -> critical vulnerabilities get ignored. - Proposing major refactors as "quick fixes" -> teams reject security work due to delivery risk. - Ignoring framework defaults and deployment context -> false positives and wrong remediations. - Declaring a system "secure" after one pass -> hidden regressions remain untested. ## Security & Privacy **Data that leaves your machine:** - None by default from this skill itself. **Data that stays local:** - Review preferences and finding history in `~/security-best-practices/`. - Exception rationale in local memory files only. **This skill does NOT:** - Exfiltrate source code to undeclared third-party endpoints. - Mark unresolved risks as fixed. - Perform hidden destructive changes. ## Related Skills Install with `clawhub install <slug>` if user confirms: - `auth` - Authentication design and hardening. - `authorization` - Access control and permission boundaries. - `encryption` - Key management and cryptographic hygiene. - `firewall` - Network exposure review and policy controls. - `devops` - Secure delivery, CI checks, and operational safeguards. ## Feedback - If useful: `clawhub star security-best-practices` - Stay updated: `clawhub sync`

path: exceptions.md
content: # Risk Exceptions - Security Best Practices

Use this file when a risk is intentionally accepted instead of fixed immediately.

## When to Record an Exception

- A fix would cause unacceptable production disruption right now.
- A dependency or platform limitation blocks immediate remediation.
- A temporary mitigation exists and ownership is explicit.

Do not record exceptions for unknown issues or unverified assumptions.

## Required Fields Per Exception

1. Exception ID (`EXC-001`)
2. Scope (service, file, endpoint, or workflow)
3. Linked finding ID (`SEC-00X`)
4. Rationale and business context
5. Compensating controls in place
6. Owner and review deadline

## Review Cadence

- Critical and high exceptions: review every 30 days.
- Medium exceptions: review every 90 days.
- Low exceptions: review every 180 days.

If the deadline passes, escalate and re-assess immediately.

## Closure Criteria

An exception can close only when:
- The linked finding is fixed and verified, or
- The risk is formally retired with updated architecture evidence.

Every closure must include date, owner, and verification notes.


path: memory-template.md
content: # Memory Template - Security Best Practices

Create `~/security-best-practices/memory.md` with this structure:

```markdown
# Security Best Practices Memory

## Status
status: ongoing
version: 1.0.0
last: YYYY-MM-DD
integration: pending

## Context
<!-- Threat model and business constraints -->
<!-- Critical systems and data sensitivity notes -->

## Review Preferences
<!-- Preferred severity threshold and report depth -->
<!-- Preferred remediation style (minimal diff vs broader refactor) -->

## Exceptions
<!-- Accepted risk items and review deadlines -->

## Notes
<!-- Stable observations only -->

---
*Updated: YYYY-MM-DD*
```

## findings-log.md Template

Create `~/security-best-practices/findings-log.md`:

```markdown
# Findings Log

## YYYY-MM-DD - [Scope]
Finding ID: SEC-001
Severity: Critical | High | Medium | Low
Location: path/to/file:line
Status: open | accepted-risk | fixed | verified
Summary: ...
Impact: ...
Fix plan: ...
Verification: pending | passed | failed
```

## exceptions.md Template

Create `~/security-best-practices/exceptions.md`:

```markdown
# Security Exceptions

## EXC-001
Scope: service/module
Risk accepted: ...
Reason: ...
Owner: ...
Approved on: YYYY-MM-DD
Review by: YYYY-MM-DD
Compensating controls: ...
```

## Status Values

| Value | Meaning | Behavior |
|-------|---------|----------|
| `ongoing` | Default mode | Keep learning project-specific constraints |
| `complete` | Stable context | Reuse preferences with minimal prompts |
| `paused` | User wants fewer prompts | Keep applying known rules, no setup prompts |
| `never_ask` | User rejected integration prompts | Stop integration prompts and run on explicit requests |


path: remediation-patterns.md
content: # Remediation Patterns - Security Best Practices

Use these patterns to reduce security risk without destabilizing delivery.

## Pattern 1: Validate at Boundaries

- Add schema validation at request and message boundaries.
- Reject malformed input early.
- Keep internal logic typed and normalized.

Why: boundary validation blocks whole classes of injection and logic abuse.

## Pattern 2: Deny by Default for Access Control

- Start with no access, then grant explicit permissions.
- Keep authorization checks near resource operations.
- Avoid scattered ad hoc permission logic.

Why: default-deny reduces accidental privilege escalation.

## Pattern 3: Secret-Safe Configuration

- Move secrets to environment or secret managers.
- Avoid logging credentials, tokens, or raw sensitive payloads.
- Fail fast if required secrets are missing.

Why: most operational breaches come from secret exposure, not cryptography errors.

## Pattern 4: Output Minimization

- Return only required fields.
- Hide internals in error responses.
- Keep verbose diagnostics in protected logs only.

Why: reduced output lowers reconnaissance value for attackers.

## Pattern 5: Progressive Hardening Rollout

- Apply high-impact fix in smallest possible diff.
- Add tests for changed behavior.
- Release in controlled batches when risk is high.

Why: teams ship security improvements faster when regression risk is bounded.

## Pattern 6: Verified Closure

- Re-test every fixed finding.
- Mark status as fixed only after verification evidence exists.
- Track residual risk explicitly when fixes are deferred.

Why: unverified fixes create false confidence and recurring incidents.


path: review-playbook.md
content: # Review Playbook - Security Best Practices

Use this sequence for explicit security scans and hardening reviews.

## 1. Scope and Inventory

1. Confirm target boundary (service, package, endpoint set).
2. Identify runtime stack and trust boundaries.
3. Classify data handled by the target (public, internal, sensitive).

## 2. Baseline Pass

Review baseline controls:
- Authentication and authorization
- Input validation and output encoding
- Secret handling and configuration
- Dependency versions and known vulnerable libraries
- Logging and error disclosure behavior

## 3. Finding Extraction

For each finding, capture:
- ID (`SEC-001`, `SEC-002`, ...)
- Severity and confidence
- Exact location with line references
- Evidence snippet
- Impact in one sentence
- Minimal remediation path

## 4. Prioritization

Sort findings by:
1. Exploitability
2. Blast radius
3. Ease of remediation
4. Regression risk

Critical and high issues should be grouped into an immediate action set.

## 5. Remediation Plan

For each planned fix:
- Describe expected behavior changes
- Define test coverage required
- Apply smallest safe diff first
- Re-validate before moving to the next finding

## 6. Reporting Format

Deliver:
1. Executive summary
2. Prioritized findings table
3. Fix plan by severity
4. Residual risk and accepted exceptions

Keep the report concise and directly actionable by engineering teams.


path: setup.md
content: # Setup - Security Best Practices

Read this when `~/security-best-practices/` is missing or empty.

## Your Attitude

Act like a practical security partner. Be direct, evidence-driven, and delivery-aware. Favor high-impact guidance over long checklists.

## Priority Order

### 1. First: Integration

Within the first exchanges, clarify activation boundaries:
- Should this skill activate for every code review or only explicit security requests?
- Should it proactively flag critical issues while working on other tasks?
- Are there systems or repos where security changes require stricter confirmation?

Before creating local memory files, ask permission and explain what will be stored.
If the user declines persistence, continue in stateless mode.

### 2. Then: Understand Risk Context

Capture only context that changes decisions:
- Threat model and compliance constraints
- Production vs staging sensitivity
- Tolerance for breaking changes during hardening
- Preferred severity threshold for immediate fixes

Move quickly from context to actionable findings.

### 3. Finally: Calibrate Delivery Style

Adapt review depth to user preference:
- Fast pass: top exploitable risks only
- Full audit: prioritized findings with complete evidence
- Fix mode: one finding at a time with regression checks

Infer preferred pace from user behavior before asking extra questions.

## What You Save Internally

Store durable context only:
- Activation preferences and scope boundaries
- Accepted risk exceptions with review dates
- Severity thresholds and reporting format preferences
- Repeated project-specific security constraints

Store only in `~/security-best-practices/` after explicit user consent.

## Golden Rule

Deliver actionable security outcomes that the team can apply safely in real code, not theoretical advice disconnected from implementation constraints.


path: severity-model.md
content: # Severity Model - Security Best Practices

Use this model to keep severity decisions consistent.

## Critical

Conditions:
- Remote compromise or privilege escalation is realistic.
- Sensitive data exposure is broad and immediate.
- Business-impacting abuse is likely without major prerequisites.

Action expectation:
- Fix immediately.
- Add focused regression checks before release.

## High

Conditions:
- Exploitation is feasible with moderate effort.
- Access control bypass, significant data exposure, or strong abuse vector exists.

Action expectation:
- Prioritize in current sprint.
- Ship with explicit validation evidence.

## Medium

Conditions:
- Exploitation needs specific preconditions.
- Impact is limited but meaningful if combined with other weaknesses.

Action expectation:
- Plan fix with clear owner and deadline.
- Consider compensating controls if immediate change is risky.

## Low

Conditions:
- Limited impact, low exploitability, or defense-in-depth gap only.

Action expectation:
- Backlog with rationale.
- Reassess during future hardening cycles.

## Confidence Scale

- High: direct code evidence and clear exploit path.
- Medium: strong signal with minor unknown runtime assumptions.
- Low: incomplete visibility; needs runtime or infrastructure confirmation.

Never inflate confidence when evidence is partial.


Security scan verdicts — ClawScan: clean | static analysis: clean | VirusTotal: clean | SkillSpector: clean (LOW)