T09 · Insecure Skill Coding Practices
Warning
- Location
- templates/obsidian-tracking.md:43
- Finding
- Confidential Personnel and Behavioral Records Stored in Plaintext Markdown Files<![CDATA[ ## Vulnerability Details **File Location**: `templates/obsidian-tracking.md:43-79`; related configuration at `config.yaml:38-41` **Vulnerability Type**: Plaintext storage of sensitive personnel information **Risk Level**: Medium ### Vulnerable Code `templates/obsidian-tracking.md:43-79`: ```markdown ## Individual Status Notes ### 1. [Team Member Name] ([Project/Role]) - **Response Time:** Xh Xm (PROMPT/DELAYED/NONE) - **Response Quality:** Detailed/Good/Vague/Minimal - **Status:** [What they reported] - **Blockers:** [Any blockers mentioned] - **Team Coordination:** [How team work is going] - **Support Needed:** [What they need] - **Follow-up Action:** [What you asked for] - **Behavioral Note:** [Pattern observation] ### 2. [Next Team Member] ... --- ## Key Observations ### Response Rate - **Total:** X/Y (Z%) - **Quick Responders:** Name, Name - **Non-Responders:** Name, Name ### Behavioral Patterns - ✅ **Positive:** [Good patterns] - ⚠️ **Concern:** [Issues noticed] - 🚨 **Critical:** [Urgent issues] ### Action Items 1. ✅ [Completed action] 2. ⏳ [Pending action] 3. 🔴 [Urgent action needed] ``` `config.yaml:38-41`: ```yaml # Tracking tracking: obsidian_path: "/root/life/pkm/daily-status" # Where to store tracking files keep_history_days: 90 # How long to keep daily logs ``` ### Technical Analysis The Skill instructs the Agent to collect identifiable personnel data—including response times, response quality, behavioral observations, blockers, and non-responder lists—and persist it as ordinary Markdown files in an Obsidian directory. Although the templates label this information as confidential, a confidentiality label does not enforce filesystem authorization, encryption at rest, secure deletion, or protection of backups and synchronized copies. The configured `keep_history_days: 90` value expresses a retention preference, but the reviewed project contains no implementation that enforces deletion after that ...[truncated 2084 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. **Minimize collected information** - Avoid free-form behavioral profiling unless it is strictly required. - Store objective project facts rather than subjective labels such as “poor” or “non-responsive.” - Do not retain named response metrics longer than operationally necessary. 2. **Protect the storage location** - Replace the fixed root-level path with a user-configurable protected directory. - Create directories with owner-only permissions, such as mode `0700`. - Create sensitive files with owner-only permissions, such as mode `0600`. - Validate permissions before writing and refuse to proceed when the vault is broadly readable. 3. **Encrypt sensitive records** - Use encrypted storage for personnel records rather than unprotected Markdown. - Keep encryption keys outside the vault and outside synchronized or backed-up content. - Use an operating-system credential store or managed secret service for key material. 4. **Enforce access control** - Define authorized readers by role. - Prevent untrusted Obsidian plugins and unrelated automation from accessing the tracking directory. - Review permissions for backup and synchronization services before enabling tracking. 5. **Implement retention securely** - Enforce `keep_history_days` in the implementation rather than treating it as documentation. - Delete expired primary records and account for synchronized copies, snapshots, and backups. - Record deletion outcomes and alert when retention cleanup fails. 6. **Add privacy safeguards** - Document the purpose and lawful basis for collecting personnel metrics. - Notify authorized administrators about the sensitivity of the data. - Establish procedures for access review, correction, export, and deletion where applicable. ]]>