T09 · Insecure Skill Coding Practices
- Location
references/workflows.md:50- Finding
Unguarded Git Push May Expose Sensitive Personal Information
- Content
View full analysis
Vulnerability Details
File Location:
references/workflows.md:50-53
Vulnerability Type: Unprotected synchronization of sensitive data to a Git remote
Risk Level: MediumVulnerable Code
markdown After processing: 1. Create/update `Journal/YYYY-MM-DD.md` 2. Commit: `git add -A && git commit -m "daily: $(date +%Y-%m-%d)"` 3. Push: `git push`The same unsafe synchronization pattern is repeated in weekly and general Git workflows:
bash git add -A git commit -m "weekly review: $(date +%Y-%m-%d)" git pushbash # After finishing work git add -A && git commit -m "sync" && git pushThe repository is explicitly intended to contain sensitive categories of information, as demonstrated in
references/structure.md:text ├── personal-growth/ │ ├── health.md # Fitness, nutrition, medical │ ├── habits.md # Habit tracking │ ├── learning.md # Courses, books, skills │ └── career.md # Career goals, development ├── family/ │ ├── important-dates.md # Birthdays, anniversaries │ └── traditions.md # Family ritualsThe person template in
assets/templates/person.md:17-21also solicits direct contact information:markdown ## Contact - **Email:** - **Phone:** - **LinkedIn:** - **Twitter:**Technical Analysis
The workflow uses
git add -A, which stages every changed, deleted, or newly created file in the knowledge repository. It then instructs the agent to rungit pushwithout first validating:- Which remote repository will receive the data.
- Whether the remote is private or publicly accessible.
- Whether the remote is controlled by the intended user.
- Whether the user has explicitly consented to uploading sensitive records.
- Whether files containing medical, family, relationship, journal, career, or contact information should be excluded.
- Whether repository contents are encrypted before transmission and storage.
This violates data-minimiz ...[truncated 2662 chars]
- Remediation
View remediation
Remediation Suggestions
-
Make remote synchronization opt-in
- Do not run
git pushas an automatic part of daily or weekly processing. - Separate local commits from remote synchronization.
- Require explicit user authorization before the first push and whenever the remote changes.
- Do not run
-
Validate the remote before uploading
- Run and display
git remote -v. - Confirm that the destination belongs to the intended user.
- Warn if the remote uses an unexpected host, account, or repository.
- Where provider APIs are available, verify that repository visibility is private.
- Run and display
-
Require informed confirmation
- Before pushing, summarize the files that will be uploaded using commands such as:
bash git status --short git diff --cached --name-only - Obtain confirmation after warning that the repository may contain medical, family, journal, relationship, and contact data.
- Before pushing, summarize the files that will be uploaded using commands such as:
-
Avoid indiscriminate staging
- Replace
git add -Awith explicit staging of reviewed files. - Exclude sensitive directories by default unless users deliberately enable their synchronization.
- Provide a conservative
.gitignoretemplate for local-only categories.
- Replace
-
Protect sensitive content
- Recommend client-side encryption for repositories containing private personal records.
- Clearly explain that private Git hosting does not provide end-to-end content encryption.
- Avoid storing credentials, authentication tokens, government identifiers, or similarly high-risk secrets in the repository.
-
Add remote-change safeguards
- Record the approved remote URL locally and require renewed consent if it changes.
- Refuse automatic pushes when multiple remotes exist or the destination cannot be validated.
-
Document incident response
- If sensitive data is pushed accidentally, instruct users to disable public access, rotate exposed credentials where relevant, rewrite Git history with an appropriat ...[truncated 195 chars]
-