Onyedika Christopher Agada

---
name: secopsai
description: "Conversational SecOps for OpenClaw audit logs. Run the live detection pipeline, inspect findings, triage incidents, and get mitigation guidance — all from chat."
---

# SecOpsAI Skill for OpenClaw

This skill lets an OpenClaw agent:

- Run the secopsai OpenClaw detection pipeline
- List and summarise findings from the local SOC store
- Investigate and close findings by ID with the native triage workflow
- Run the native triage orchestrator, inspect queued actions, and apply approved actions
- Get structured mitigation steps for any finding
- Run a local-first threat intelligence (IOC) pipeline and match IOCs against OpenClaw replay
- Review PyPI and npm package releases for supply-chain compromise
- Suggest false-positive actions for suspicious supply-chain findings

## Assumptions

- `secopsai` is installed at `~/secopsai`, preferably via a transparent repo checkout / manual setup flow such as:
  - `git clone https://github.com/Techris93/secopsai.git ~/secopsai`
  - `cd ~/secopsai && python3 -m venv .venv && source .venv/bin/activate && pip install -r requirements.txt`
- OpenClaw audit logs are present at `~/.openclaw/logs/` on the same host.
- The agent has access to an `exec` tool to run shell commands.
- The virtualenv at `~/secopsai/.venv` is used for all commands.

If installation guidance is needed, prefer pointing users to the GitHub repo/manual setup path first. Only mention the hosted installer as an optional shortcut, not the default recommendation.

---

## Safety defaults (read this)

This skill can run shell commands and can modify the local SOC store when performing triage.

- Prefer **read-only** operations by default (`list/show/check`).
- Before any write/triage action (`triage close`, `triage orchestrate`, `triage apply-action`), require explicit user confirmation.
- If you enable scheduled jobs, ensure they run under a controlled account and that automated writes are intended.
- Backup the SOC DB (`data/openclaw/findings/openclaw_soc.db`) before enabling unattended automation.

## Command Mappings

### 1. Show findings

**User phrases:**

- "show findings"
- "show today's findings"
- "list findings"
- "what findings do we have"

**Exec command:**

```bash
cd "$HOME/secopsai" && source .venv/bin/activate && \
  secopsai list --severity info --json --cache-ttl 60
```

(`--json` also works before the subcommand, e.g. `secopsai --json list ...`.)

**Agent behaviour:**

- Parse the JSON payload from `secopsai list` (field: `findings`).
- For each finding, extract: `finding_id`, `severity`, `status`, `disposition`, `title`.
- Reply with:
  - Total count
  - Count by severity (HIGH / MEDIUM / LOW / INFO)
  - List of HIGH (and MEDIUM) findings with ID and title

---

### 2. Run daily pipeline

**User phrases:**

- "run daily pipeline"
- "run secops scan"
- "refresh findings"
- "run live"

**Exec command:**

```bash
cd "$HOME/secopsai" && source .venv/bin/activate && \
  secopsai refresh --json && \
  secopsai list --severity high --json --cache-ttl 300
```

**Agent behaviour:**

- Run the pipeline once (`refresh`) and then list current high-severity findings.
- From the `list` JSON output, highlight NEW or HIGH/CRITICAL findings (based on
  `first_seen`/`last_seen` fields when available).

Example reply:

> Daily SecOps summary: 3 high-severity findings.
>
> - HIGH: OCF-C9D2523C770B6731 — OpenClaw Dangerous Exec / Tool Burst (status=open)
> - HIGH: OCF-62FA8D1D3578BF6E — OpenClaw Sensitive Config (status=open)
>
> Reply `triage OCF-...` to mark as reviewed, or `mitigate OCF-...` for remediation steps.

---

### 3. Investigate a finding

**User phrases:**

- `investigate SCM-<ID>`
- `triage OCF-<ID>`
- `investigate EXFIL-<ID>`

**Exec command:**

```bash
cd "$HOME/secopsai" && source .venv/bin/activate && \
  secopsai triage investigate <FINDING_ID> --search-root "$HOME/secopsai" --json
```

**Agent behaviour:**

- Summarise:
  - recommended disposition
  - dependency presence
  - policy matches
  - verdict explanation
  - next actions
- For supply-chain findings, if helpful, follow with:

```bash
cd "$HOME/secopsai" && source .venv/bin/activate && \
  secopsai supply-chain suggest-fp-action <FINDING_ID> --search-root "$HOME/secopsai" --json
```

---

### 4. Close a finding (WRITE)

Important: this modifies the local SOC store. Confirm with the user before running.

**User phrases:**

- `close SCM-<ID> as expected_behavior`
- `close OCF-<ID> as needs_review note "..."`

**Exec command pattern:**

```bash
cd "$HOME/secopsai" && source .venv/bin/activate && \
  secopsai triage close <FINDING_ID> --disposition <TYPE> --note "<analyst note>" --json
```

**Agent behaviour:**

Confirm back with the final status and disposition.

---

### 5. Show a single finding in detail

**User phrases:**

- `show OCF-<ID>`
- `details OCF-<ID>`

**Exec command:**

```bash
cd "$HOME/secopsai" && source .venv/bin/activate && \
  secopsai show OCF-<ID> --json
```

**Agent behaviour:**

Parse and summarise the JSON: title, severity, status, disposition, rule IDs,
number of events, first/last seen. Prefer the structured fields from
`secopsai show` and avoid re-parsing raw text.

---

### 6. Run the triage orchestrator (WRITE)

Important: this can auto-close clearly safe findings. Confirm with the user before running.

**User phrases:**

- `run triage orchestrator`
- `orchestrate findings`
- `process open findings`

**Exec command:**

```bash
cd "$HOME/secopsai" && source .venv/bin/activate && \
  secopsai triage orchestrate --search-root "$HOME/secopsai" --limit 20 --json
```

**Agent behaviour:**

- Summarise:
  - `processed`
  - `auto_applied`
  - `queued`
  - top per-finding outcomes
- If queued actions exist, offer:

```bash
cd "$HOME/secopsai" && source .venv/bin/activate && \
  secopsai triage queue --json
```

and, after approval:

```bash
cd "$HOME/secopsai" && source .venv/bin/activate && \
  secopsai triage apply-action ACT-0001 --yes --json
```

---

### 7. Check for malware or exfil

**User phrases:**

- "check malware"
- "check exfil"
- "check both"
- "any malware findings?"

**Exec command pattern:**

```bash
cd "$HOME/secopsai" && source .venv/bin/activate && \
  secopsai check --type <malware|exfil|both> --severity medium --json --cache-ttl 60
```

**Agent behaviour:**

Parse the JSON (`check` payload: `findings_total`, `matched_count`,
`high_or_above`, `top_matches`) and reply with a compact summary:

> Malware check: 2 matching findings (1 HIGH).
> Top: OCF-C9D2523C770B6731, HIGH — OpenClaw Dangerous Exec / Policy Denials.

---

### 8. Mitigate a finding (recommended actions)

**User phrases:**

- `mitigate OCF-<ID>`
- `show mitigation OCF-<ID>`
- `what should I do for OCF-<ID>`

**Exec command:**

```bash
cd "$HOME/secopsai" && source .venv/bin/activate && \
  secopsai mitigate OCF-<ID> --json --cache-ttl 60
```

**Expected JSON fields:** `finding_id`, `title`, `severity`, `status`,
`disposition`, `rule_ids`, `recommended_actions` (list of strings).

**Agent behaviour:**

Reply with a numbered list of the `recommended_actions`. Example:

> Mitigation steps for **OCF-C9D2523C770B6731** (HIGH — OpenClaw Dangerous Exec / Tool Burst):
>
> 1. Identify which agent or skill issued the dangerous execs and confirm business justification.
> 2. If unauthorized, disable or restrict that skill/tool configuration in OpenClaw.
> 3. Rotate any secrets used in the commands (tokens, SSH keys, API keys).
> 4. Add stricter policy/approval requirements for high-risk exec operations.

If `recommended_actions` is empty or missing:

> No curated mitigation steps are available yet for this finding.
> Recommended next steps: review the associated events, confirm if the behaviour is expected, and restrict any over-permissive skills or credentials used.

---

## Threat Intel (IOCs)

### 7. Refresh IOC feeds

**User phrases:**

- "refresh intel"
- "update iocs"
- "pull threat intel"

**Exec command:**

```bash
cd "$HOME/secopsai" && source .venv/bin/activate && \
  secopsai intel refresh --json
```

**Agent behaviour:**

- Parse JSON and report total IOCs and any feed errors.
- Do not call external paid enrichment APIs by default.

### 8. Match IOCs against OpenClaw replay

**User phrases:**

- "match intel"
- "check iocs"
- "any intel matches"

**Exec command:**

```bash
cd "$HOME/secopsai" && source .venv/bin/activate && \
  secopsai intel match --limit-iocs 500 --json
```

**Agent behaviour:**

- Parse `matched_findings`.
- If matches exist, list the top 3 `TI-...` finding IDs and titles and offer `show TI-...`.

## Supply Chain Monitoring

### 9. Scan a package release

**User phrases:**

- "scan this PyPI package release"
- "check this npm package version"
- "review package diff"

**Exec command:**

```bash
cd "$HOME/secopsai" && source .venv/bin/activate && \
  secopsai supply-chain scan --ecosystem pypi --package requests --version 2.32.0 --json
```

**Agent behaviour:**

- Parse `result.verdict`, `result.finding_id`, and `result.report_path`.
- If verdict is `malicious`, offer `show <finding_id>`.

### 10. Scan recent top-package releases

**User phrases:**

- "check recent package releases"
- "run supply chain monitor"
- "scan recent PyPI and npm releases"

**Exec command:**

```bash
cd "$HOME/secopsai" && source .venv/bin/activate && \
  secopsai supply-chain once --top 1000 --lookback 600 --json
```

**Agent behaviour:**

- Parse `total_scanned`, `malicious`, `benign`, `errors`, and `results`.
- If malicious findings exist, list the `SCM-...` IDs and package versions.

## Daily Summary (OpenClaw cron)

Configure an OpenClaw cron job to drive the `secopsai` CLI and produce a
concise chat summary.

- **Schedule:** `30 7 * * *` (07:30 local)
- **Action (systemEvent text):**

```text
[SECOPS_DAILY_SUMMARY_TRIGGER] Run the SecOpsAI pipeline and summarise new/high
findings for this chat.

Suggested steps for the agent:
1) cd "$HOME/secopsai" && source .venv/bin/activate
2) secopsai refresh --json
3) secopsai list --severity high --json --cache-ttl 300
4) Focus on high/critical findings first_seen in the last 24h.
5) Post a compact summary back into this conversation.
```

When this fires the agent should:

1. Execute the `secopsai` commands via `exec`.
2. Parse the JSON findings payload from `secopsai list --severity high --json`.
3. Post a summary: total count, HIGH/CRITICAL breakdown, and top finding IDs with
   titles and status.
4. Invite the user to `triage OCF-...` or `mitigate OCF-...` any flagged item.

FILE:CHANGELOG.md
SecOpsAI skill 0.3.6
- Switched from legacy soc_store triage steps to native secopsai triage investigate/close flow.
- Added native orchestrator, queue, and apply-action guidance.
- Added supply-chain false-positive action guidance.
- Updated safety language for write operations.

---
name: rate-limit-validator
description: >
  Test whether an HTTP endpoint enforces rate limiting. Sends a
  burst of requests and checks for 429 responses, Retry-After, and
  X-RateLimit headers. Useful for validating gateway and API
  throttling before going to production.
metadata:
  openclaw:
    requires:
      bins:
        - curl
---
# Rate Limit Validator

Tests whether an HTTP endpoint actually enforces rate limiting.

Most rate-limit skills help you *add* rate limiting. This one helps
you *check* if it's working — or if it's missing entirely.

## What it checks

- Whether the server returns HTTP 429 under burst load
- Presence of `Retry-After` header
- Presence of `X-RateLimit-Limit` and `X-RateLimit-Remaining` headers
- Response time degradation under sustained requests

## When to use it

- Before deploying an API or gateway to production
- After adding rate-limit middleware, to confirm it works
- When auditing a third-party service you depend on
- Validating threat model mitigations (e.g. T-IMPACT-002)

## Example prompts

- "Test if my gateway has rate limiting"
- "Validate rate limiting on http://localhost:18789"
- "Check if my API throttles requests"

## Test script

```bash
#!/bin/bash
TARGET="-http://localhost:18789/"
COUNT="-50"
TMP="/tmp/ratelimit-test-$$.txt"

echo "Target: $TARGET"
echo "Requests: $COUNT"
echo ""

for i in $(seq 1 $COUNT); do
  curl -s -o /dev/null -w "%{http_code}" "$TARGET" >> "$TMP"
  echo "" >> "$TMP"
done

TOTAL_200=$(grep -c '200' "$TMP" || echo 0)
TOTAL_429=$(grep -c '429' "$TMP" || echo 0)

echo "Allowed (200): $TOTAL_200"
echo "Throttled (429): $TOTAL_429"
echo ""

HEADERS=$(curl -sI "$TARGET")
echo "$HEADERS" | grep -qi "retry-after" && echo "Retry-After: present" || echo "Retry-After: missing"
echo "$HEADERS" | grep -qi "x-ratelimit" && echo "X-RateLimit: present" || echo "X-RateLimit: missing"

echo ""
if [ "$TOTAL_429" -gt 0 ]; then
  echo "Result: rate limiting is active ($TOTAL_429/$COUNT throttled)"
else
  echo "Result: no rate limiting detected ($TOTAL_200/$COUNT allowed through)"
fi

rm -f "$TMP"
```

## Notes

- Only sends GET requests, no payloads
- Meant for testing your own deployments, not for attacking others
- In OpenClaw's trust model, rate limiting is a hardening measure,
  not a security boundary (authenticated callers are trusted operators)

## References

- [OpenClaw threat model (T-IMPACT-002)](https://github.com/openclaw/trust)
- [OpenClaw security policy](https://github.com/openclaw/openclaw/security/policy)

---
name: credential-hygiene-validator
description: >
  Checks whether credentials and tokens are stored safely. Validates
  file permissions, plaintext exposure, git repo contamination, log
  redaction coverage, and token rotation status. Works with OpenClaw
  and general dotfile directories.
metadata:
  openclaw:
    requires:
      bins:
        - grep
        - stat
        - git
---
# Credential Hygiene Validator

Checks whether credentials and tokens in config files are stored
with reasonable hygiene. Catches common mistakes before they become
incidents.

## What it checks

1. **File permissions** -- config files should be 600 or 700, not world-readable
2. **Plaintext tokens** -- scans for hex tokens, JWTs (base64url with dots), Bearer strings, and API keys
3. **Git repo contamination** -- whether the config directory sits inside a git working tree
4. **Gitignore coverage** -- whether .gitignore excludes credential paths
5. **Log file leaks** -- tokens appearing in log output (checks all formats: hex, JWT, Bearer per RFC 6750)
6. **Token age** -- warns if tokens have not been rotated recently
7. **Atomic write safety** -- checks if config backup exists (indicator of safe write patterns)

## When to use it

- After setting up a new tool or service
- Before pushing dotfiles to a public repo
- As part of a regular security hygiene review
- When onboarding a new machine
- After rotating credentials, to confirm the old token is gone

## Example prompts

- "Check if my OpenClaw tokens are stored safely"
- "Audit my dotfiles for leaked credentials"
- "Is my config directory in a git repo?"
- "Check file permissions on my credentials"
- "Are my tokens showing up in any log files?"

## Checks run

```bash
# 1. File permissions
stat -c '%a %n' ~/.openclaw/openclaw.json
# Expected: 600

# 2. Plaintext tokens (full token68 charset per RFC 7235)
grep -rnP '("token"\s*:\s*")[^"]{8,}"|[Bb]earer\s+[\w\-\.+/=~]{16,}|[a-f0-9]{32,}' \
  ~/.openclaw/ --include="*.json" 2>/dev/null

# 3. Git repo check
git -C ~/.openclaw rev-parse --is-inside-work-tree 2>/dev/null
# Expected: error (not in a repo)

# 4. Gitignore coverage
grep -q '.openclaw' ~/.gitignore 2>/dev/null && echo "covered" || echo "not covered"

# 5. Log file leaks (full token68 charset)
grep -rnP '[Bb]earer\s+[\w\-\.+/=~]{16,}|[a-f0-9]{32,}' \
  ~/.openclaw/logs/ --include="*.log" 2>/dev/null

# 6. Token age (check config file modification time)
find ~/.openclaw/openclaw.json -mtime +90 -print 2>/dev/null
# If output: token has not been rotated in 90+ days

# 7. Backup file exists (atomic write indicator)
ls ~/.openclaw/openclaw.json.bak 2>/dev/null && echo "backup present" || echo "no backup"
```

## Notes

- Read-only checks, does not modify any files
- Token patterns match hex, JWT (header.payload.signature), base64url,
  and Bearer headers case-insensitively per RFC 6750
- Works with any tool that stores credentials in dotfiles
- Aligns with T-ACCESS-003 in the OpenClaw threat model

## References

- [OpenClaw threat model (T-ACCESS-003)](https://github.com/openclaw/trust)
- [OpenClaw security policy](https://github.com/openclaw/openclaw/security/policy)
- [RFC 6750 - Bearer Token Usage](https://www.rfc-editor.org/rfc/rfc6750)