T09 · Insecure Skill Coding Practices
- Location
src/index.mjs:23- Finding
Missing persona sets silently fall back to synthetic approving personas
- Content
View full analysis
({persona_id:`default-${n}`,name:`Default Persona ${n}`,reputation:0.5})) }; } ``` ### Technical Analysis In persona mode, the implementation attempts to load either the requested persona set or the latest persona-set artifact. If no such artifact exists, it does not reject the request. Instead, it silently creates five synthetic personas with equal reputations. These generated personas are subsequently passed to `makeVotes()`. Unless optional, caller-controlled constraints detect failing tests or one of a small set of security-related phrases, each synthetic persona votes `YES`. This is a fail-open condition in a security and release-governance control. This behavior conflicts with the documented invocation contract in `SKILL.md`, which states that persona mode requires an existing `persona_set_id` and that the guard does not generate persona sets internally. The fallback can therefore produce an apparently governed `MERGE` decision despite the absence of the required governance state. ### Attack Path 1. An attacker or improperly configured caller invokes the guard in persona mode. 2. The caller omits `persona_set_id` when no latest persona set exists, or supplies an identifier that does not resolve to an existing persona set. 3. The caller omits `require_tests_pass` and `block_on_security_flags`, or supplies a change summary that does not match the narrow security-expression check. 4. The guard creates five synthetic personas rather than returning an error. 5. Each synthetic persona votes `YES`. 6. The votes are aggregated and can result in `MERGE`. 7. The decision is written to board state as an auditable decision artifact, making the bypass appear to be a legitimate governed outcome. ### Impact ...[truncated 529 chars]- Remediation
View remediation
