Lerwee Alert To Fault Handling
Security checks across static analysis, malware telemetry, and agentic risk
Overview
This skill matches its alert-remediation purpose, but it can run host remediation scripts and close alerts through external tools, with important scope checks mostly left to instructions rather than enforced controls.
Review this skill before installing. Only use it with least-privilege Lerwee and fault-handling accounts, confirm that the external helper skills are trusted, restrict allowed scripts and hosts, and remove the included execution log before sharing or deploying.
Static analysis
No static analysis findings were reported for this release.
VirusTotal
VirusTotal findings are pending for this skill version.
Risk analysis
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
If the agent or a user supplies the wrong arguments, the skill could run the wrong remediation script against a host.
The command-line path directly passes an IP and script ID into an external remediation runner. The artifacts document confirmation rules, but this code path does not itself enforce a whitelist, second confirmation, or chat/classification scope before host-impacting execution.
script_id = int(sys.argv[3]) ... cmd = ['python3', FAULT_HANDLING_DIR / 'run_script.py', '--hosts', ip, '--script-id', str(script_id)]
Enforce script ID allowlists, chat/classification checks, and explicit confirmation in the executable code before calling the remediation runner.
An alert could be closed prematurely or for the wrong incident, reducing monitoring visibility.
The standalone close command can acknowledge an alert by event ID without checking in code that a remediation script succeeded first, even though SKILL.md says automatic closure should only happen after success.
elif command == 'close': ... eventid = sys.argv[2] ... if close_alert(eventid, message):
Require a matching successful execution record or an explicit user approval immediately before closing an alert.
The reviewed package does not show the code that actually runs remediation scripts or talks to the alert API, so users cannot fully assess what will execute.
The high-impact execution and alert API behavior depend on sibling helpers outside this skill's manifest and with no install spec or declared dependency contract in the registry metadata.
FAULT_HANDLING_DIR = SCRIPT_DIR.parent / "fault-handling" LERCLEE_API_DIR = SCRIPT_DIR.parent / "lerwee-api" / "scripts"
Declare these dependencies explicitly, pin or package reviewed versions, and document the permissions and credential sources they use.
The skill may act with whatever infrastructure and alert-system permissions are available to the connected fault-handling and Lerwee API tools.
The skill is designed to use delegated operational authority to run fault-handling scripts and acknowledge alerts. This is purpose-aligned, but users should understand the privilege boundary.
使用 fault-handling skill 执行脚本 ... ./scripts/lerwee-api.sh alert problem-ack
Use least-privilege service accounts and limit allowed scripts, hosts, and alert actions.
Installing or sharing the skill may expose previous operational history and internal identifiers to people who do not need them.
A populated execution log is included in the packaged files and contains operational identifiers, including an internal IP address, alert ID, execution ID, and user ID.
"eventid": "32420610", "ip": "192.168.3.137", "execution_id": 15440, "user": "ou_db578a1d726251fd78f7d4eabdc98f54"
Do not publish populated logs; initialize the log empty, add retention controls, and avoid storing unnecessary user or host identifiers.