Ticket Signal Watch
Security checks across static analysis, malware telemetry, and agentic risk
Overview
This skill matches its stated ticket-alert purpose, but it does fetch configured web pages, store local monitoring state, and optionally supports forwarding alerts to external destinations.
This appears safe for its stated purpose if you expect it to fetch ticket pages and produce alerts. Configure only trusted target URLs, keep the state file private, and review any webhook/channel settings before forwarding alerts or adding real credentials.
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.
You have fewer external signals for verifying who maintains the skill or where updates originate.
The skill code is included and there is no remote install step, but the registry metadata does not provide an upstream source or homepage for provenance checking.
Source: unknown Homepage: none
Review the included files and publisher identity before installing, especially before adding private targets or webhook credentials.
If configured carelessly, the skill can make HTTP requests to arbitrary URLs from the local environment.
The script fetches each URL supplied in the target configuration; this is central to the ticket-monitoring purpose, but the script does not restrict targets to official ticket domains.
fetch = fetch_url(target.url, user_agent=user_agent, timeout_seconds=timeout_seconds)
Use trusted, official ticket detail/search URLs, avoid internal or sensitive endpoints, and keep polling frequency reasonable.
If you replace the placeholder with a real token, that credential may be stored in a local JSON config file.
The example notifier configuration shows where a user may place a webhook bearer token. This is expected for webhook delivery, and the included script does not read this notifier file.
"headers": {
"Authorization": "Bearer replace-me"
}Use narrowly scoped webhook tokens, protect the config file, and prefer a secrets mechanism if your OpenClaw setup supports one.
The local state file can reveal what events or ticket pages you are monitoring.
The skill persists monitoring state, including target URLs, names, signal hits, and check timestamps, to support change detection.
state[target.url] = {
"name": target.name,
"platform": target.platform,
"status": fetch.get("status"),
"digest": digest,
"positive_hits": positive_hits,
"signal_level": signal_level,
"checked_at": int(time.time()),
}Store the state file in an intended private location and delete it when you no longer need monitoring history.
Alert details such as event names, URLs, signal hits, and page previews may be shared with configured downstream systems.
The documented workflow includes sending alert payloads to downstream channels or webhooks. This is purpose-aligned, but it creates an external data flow.
If `alerts` is non-empty, forward the structured result to: - an OpenClaw channel - a webhook - a file/queue processor
Forward alerts only to trusted channels/webhooks and review or reduce preview content if monitoring private backend data.