T09 · Insecure Skill Coding Practices
Error
- Location
- scripts/scan.py:55
- Finding
- Unsupported “SAFE” Classification Based Only on Market Metrics<![CDATA[ ## Vulnerability Details **File Location**: `scripts/scan.py`, lines 55–97 **Vulnerability Type**: Insecure financial risk-scoring logic **Risk Level**: High ### Complete Code Snippet ```python def calculate_risk_score(token_data): """ Calculate risk score based on multiple factors Returns 0-100 score """ score = 50 # Base score # Liquidity factor liquidity = token_data.get('liquidity', 0) if liquidity > 100000: score += 20 elif liquidity > 50000: score += 10 # Volume factor volume = token_data.get('volume24h', 0) if volume > 100000: score += 15 elif volume > 50000: score += 10 # Risk adjustments if liquidity < 10000: score -= 30 if volume < 1000: score -= 20 return max(0, min(100, score)) if __name__ == "__main__": print("[SENTRY-AI] Starting scan...") results = scan_all() print(f"Found {len(results)} pools") for token in results: risk = calculate_risk_score(token) status = "SAFE" if risk >= 70 else "RISKY" print(f"[{status}] {token['symbol']} - Risk Score: {risk}/100") print(f" Liquidity: ${token['liquidity']:,.0f}") print(f" URL: {token['url']}") print() ``` ### Technical Analysis The scanner assigns an initial score of 50 and adjusts it using only reported liquidity and 24-hour trading volume. A score of 70 or higher is then presented as `SAFE`. These metrics do not establish smart-contract safety. The implementation does not examine: - Mint or freeze authorities - Owner or administrator privileges - Transfer restrictions or honeypot behavior - Upgradeability and proxy administration - Holder concentration - Liquidity ownership or lock status - Sellability and fee manipulation - Contract source code or bytecode - Token supply manipulation - Wash trading or artificially generated volume Liquidity and volume can be su ...[truncated 1471 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Replace `SAFE` with a narrowly scoped description such as `HIGH LIQUIDITY/ACTIVITY` until contract-level checks are implemented. 2. Do not produce a positive security verdict when required evidence is unavailable. Use an `UNKNOWN` or `INSUFFICIENT DATA` state. 3. Separate market-quality scoring from contract-security scoring. 4. Add chain-specific checks, including: - Solana mint and freeze authority status - EVM ownership, access-control, proxy, and upgradeability analysis - Transfer simulation and honeypot detection - Buy and sell fee analysis - Holder concentration - Liquidity lock and ownership verification - Source-code or bytecode inspection 5. Treat third-party API data as untrusted and potentially manipulable. 6. Require multiple independent indicators before issuing any favorable assessment. 7. Include the evidence used for each conclusion and clearly document scoring limitations. 8. Add test cases for tokens with high liquidity and volume but dangerous contract permissions. ]]>