Security Audit
slack-bot-builder
github.com/sickn33/antigravity-awesome-skillsTrust Assessment
slack-bot-builder received a trust score of 82/100, placing it in the Mostly Trusted category. This skill has passed most security checks with only minor considerations noted.
SkillShield's automated analysis identified 2 findings: 0 critical, 1 high, 1 medium, and 0 low severity. Key findings include Unsanitized user input in Slack mrkdwn blocks, Example OAuth configuration requests broad `channels:history` and `channels:read` scopes.
The analysis covered 4 layers: Manifest Analysis, Static Code Analysis, Dependency Graph, LLM Behavioral Safety. All layers scored 70 or above, reflecting consistent security practices.
Last analyzed on February 20, 2026 (commit e36d6fd3). SkillShield performs automated 4-layer security analysis on AI skills and MCP servers.
Layer Breakdown
Behavioral Risk Signals
Security Findings2
| Severity | Finding | Layer | Location | |
|---|---|---|---|---|
| HIGH | Unsanitized user input in Slack mrkdwn blocks The `build_notification_blocks` function constructs Slack Block Kit messages using f-strings to embed values from the `incident` dictionary directly into `mrkdwn` text fields. If any of these `incident` values (e.g., `title`, `description`, `service`) originate from untrusted user input, an attacker could inject Slack `mrkdwn` formatting or special characters. This could lead to message manipulation, phishing attempts, or displaying misleading information to users, effectively acting as a form of prompt injection against the human user or data exfiltration if crafted to reveal internal system state. Sanitize or escape all user-provided input before embedding it into `mrkdwn` fields. For Slack Block Kit, consider using `plain_text` type for user-controlled content where `mrkdwn` is not strictly necessary, or implement a robust sanitization function that escapes `*`, `_`, `~`, `>`, `<`, `&` and other `mrkdwn` special characters. | LLM | SKILL.md:90 | |
| MEDIUM | Example OAuth configuration requests broad `channels:history` and `channels:read` scopes The provided OAuth installation example includes `channels:history` and `channels:read` scopes. While the 'Sharp Edges' section correctly advises requesting minimum required scopes, the example itself demonstrates a configuration that grants broad access to all public and private channel history and information where the bot is a member. If a bot built using this example is compromised, or if the AI agent itself is prompted maliciously, these permissions could be leveraged for large-scale data exfiltration of sensitive conversations. Developers should be strongly cautioned to only request these scopes if absolutely essential for the bot's core functionality. Revise the example to demonstrate a more minimal set of scopes, or add a prominent warning directly alongside the scope definition explaining the security implications of `channels:history` and `channels:read` and advising developers to carefully evaluate if these are truly necessary for their specific bot's functionality. Suggest alternative, more granular scopes if available, or explain how to progressively request scopes. | LLM | SKILL.md:160 |
Scan History
Embed Code
[](https://skillshield.io/report/5125e2ee8e9b6ce0)
Powered by SkillShield