T09 · Insecure Skill Coding Practices
- Location
scripts/position_sizer.py:29- Finding
Declared Trading Risk Ceiling Is Not Enforced
- Content
View full analysis
100: raise ValueError("Risk percent must be between 0 and 100") ``` The corresponding policy in `SKILL.md` states: ```text - Never exceed 3% risk per trade ``` ### Technical Analysis The skill declares that risk must never exceed 3% per trade, but the executable validation accepts any value up to 100%. The supplied percentage is then used directly to calculate the permitted loss: ```python risk_amount = account_balance * (risk_percent / 100) ``` An accepted value of `100` therefore permits a calculated maximum loss equal to the entire account balance. A narrow difference between the entry and stop-loss prices can also produce a position value substantially greater than the account balance. The program only prints an allocation warning and does not reject or cap the result. This is a safety-control enforcement failure in a financial calculation tool. It does not grant operating-system privileges or enable arbitrary code execution, but it allows callers to bypass the risk policy represented to users. ### Attack Path 1. A caller invokes the position-sizing tool with a risk value greater than the documented 3% ceiling, for example: ```bash python3 scripts/position_sizer.py \ --balance 10000 \ --risk 100 \ --entry 100000 \ --stop-loss 99000 ``` 2. The validation accepts `--risk 100` because it rejects only values above 100. 3. The calculator sets the risk amount to the full `$10,000` account balance. 4. The narrow stop distance produces a position of 10 units with a nominal value of `$1,000,000`. 5. The program presents the result and merely displays a warning rather than refusing the unsafe calculation. ...[truncated 584 chars]- Remediation
View remediation
MAX_RISK_PERCENT: raise ValueError( f"Risk percent must be greater than 0 and no more than " f"{MAX_RISK_PERCENT}" ) ``` 2. Preserve the conservative default of 1% and clearly identify 1–2% as the recommended range. 3. Reject position values greater than the available account balance unless the caller explicitly enables and configures leverage. 4. If leverage is supported, require a separate leverage parameter and calculate liquidation and margin constraints explicitly. 5. Convert allocation warnings into hard validation failures where the result violates the stated safety policy. 6. Add unit tests for boundary values including 0%, 1%, 2%, 3%, values just above 3%, and 100%. 7. Add tests covering narrow stop-loss distances and positions exceeding the account balance. ]]>
