Security Audit
azure-communication-common-java
github.com/sickn33/antigravity-awesome-skillsTrust Assessment
azure-communication-common-java received a trust score of 85/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 3 findings: 0 critical, 0 high, 2 medium, and 1 low severity. Key findings include Example code demonstrates token access and placeholders for sensitive tokens, Entra ID authentication example includes placeholders for sensitive configuration, Documentation includes sensitive environment variable placeholder.
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 Findings3
| Severity | Finding | Layer | Location | |
|---|---|---|---|---|
| MEDIUM | Example code demonstrates token access and placeholders for sensitive tokens The skill provides multiple code examples that involve handling user access tokens. This includes direct assignment of placeholder tokens (`<user-access-token>`), methods for refreshing tokens (`fetchNewTokenFromServer()`, `refreshToken()`), and explicit access to `AccessToken` objects. While a 'Best Practices' section warns against logging or exposing full tokens, the examples themselves show how to access and print token data (even if partially redacted in one instance). An LLM generating code based on these examples might replace placeholders with actual sensitive tokens or implement the token refresh logic in a way that inadvertently logs, stores, or transmits full tokens insecurely, leading to credential harvesting or data exfiltration. Emphasize secure handling of tokens more prominently within the code examples themselves, perhaps by adding comments directly next to token assignments/access points. Provide a secure placeholder implementation for `fetchNewTokenFromServer()` that does not expose tokens. Reinforce the 'Never log or expose full tokens' best practice directly in the relevant code snippets. | LLM | SKILL.md:30 | |
| MEDIUM | Entra ID authentication example includes placeholders for sensitive configuration The example for Entra ID authentication uses placeholders for `clientId`, `tenantId`, and `redirectUrl`. These are sensitive configuration parameters for OAuth flows. If an LLM replaces these placeholders with actual values and the generated code is executed or logged without proper security considerations, these credentials could be exposed. An insecure `redirectUrl` could also lead to token leakage in an OAuth flow. Add explicit warnings within the code comments for these placeholders, advising against hardcoding sensitive values and recommending secure configuration management (e.g., environment variables, secret stores). Highlight the importance of a secure `redirectUrl`. | LLM | SKILL.md:75 | |
| LOW | Documentation includes sensitive environment variable placeholder The skill documents `AZURE_COMMUNICATION_USER_TOKEN=<user-access-token>` as an environment variable. While using environment variables is generally a more secure practice than hardcoding, the explicit documentation of a placeholder for a sensitive token means an LLM might suggest using this variable and, if not handled carefully by the user or the LLM's generated code, could still lead to exposure (e.g., in shell history, logs, or insecure CI/CD pipelines). Add a note emphasizing that environment variables should be managed securely and not exposed in logs or version control. Provide guidance on how to securely load these variables in different deployment scenarios. | LLM | SKILL.md:137 |
Scan History
Embed Code
[](https://skillshield.io/report/9ee82d5547e73fa7)
Powered by SkillShield