The Growth Process (Feedback Loops) & Source Code Leak Response

Plan
  → Set goals and plan the execution method
Do
  → Execute the plan on a small scale
Check
  → Measure results and compare against expectations
Act
  → Analyze gaps and develop improvement measures
  → Feeds back into the next Plan

Observe
  → Perceive the current situation as it is
Orient
  → Interpret observed information by combining it with
    existing knowledge, experience, and cultural context
Decide
  → Determine the optimal course of action based on interpretation
Act
  → Execute the decision
  → Results feed back into the Observe phase

Goal Setting
  → Set specific and measurable goals
  → Example: "Deep-dive into TypeScript type system this quarter"

Execute
  → Study 30 minutes daily, apply to real work
  → Experiment with small projects

Measure
  → Record study time, completed tasks, applied patterns
  → Quantitative metrics matter

Reflect
  → "What worked well?"
  → "Where did I get stuck?"
  → "Why did I get stuck?"

Adjust
  → Change learning methods
  → Modify goals
  → Start a new cycle

Keep (What to maintain)
  → Things going well that should continue
  → Example: "Culture of quickly sharing blockers in daily standups"

Problem (What needs improvement)
  → Areas requiring change
  → Example: "Code reviews often take more than 3 days"

Try (What to attempt)
  → Action items for the next sprint
  → Example: "Introduce a first-review-within-24-hours rule"

Liked (What was enjoyable)
  → Positive experiences like team atmosphere, sense of achievement
  → Example: "Pair programming enabled great knowledge sharing"

Learned (What was learned)
  → New technologies, processes, or lessons
  → Example: "Realized the importance of E2E testing"

Lacked (What was missing)
  → Shortages in resources, time, or tools
  → Example: "Unstable QA environment delayed testing"

Longed for (What is desired)
  → Things to have going forward
  → Example: "Automated staging environment deployment pipeline"

Start (What to begin)
  → New practices to introduce
  → Example: "Weekly tech sharing sessions"

Stop (What to cease)
  → Inefficient or harmful practices
  → Example: "Friday afternoon deployments"

Continue (What to maintain)
  → Proven practices
  → Example: "Automated release notes"

// Poor review comment
"Rename this variable"

// Good review comment
"This function seems to have two responsibilities.
Separating validation from transformation would make
it easier to test -- what do you think?"

Postmortem structure:
1. Timeline (What happened)
2. Impact scope (Who was affected, how much)
3. Root cause analysis (Why it happened)
4. What went well (What reduced damage)
5. Areas for improvement (What was lacking)
6. Action items (Specific + assignee + deadline)

Objective: Improve frontend performance by 50%
  KR1: Achieve LCP under 2.5s -> Currently 3.1s (60% progress)
  KR2: Reduce bundle size by 30% -> Currently 20% reduced (67% progress)
  KR3: All Core Web Vitals "Good" -> 2/3 achieved (67% progress)

Review result:
  -> KR1 can improve further with image optimization
  -> KR2 needs expanded dynamic imports
  -> Overall on track but needs focus given remaining time

Step 1: Separate emotions
  → Do not react immediately when receiving feedback
  → "This feedback is about my behavior, not about me as a person"

Step 2: Extract the core message
  → Strip away emotional expressions and look at the essence
  → "The code is a mess" -> "This code's readability can be improved"

Step 3: Ask specific questions
  → "Which parts would benefit most from improvement?"
  → "Could you give me an example?"

Step 4: Create an execution plan
  → Convert feedback into concrete action items
  → Set deadlines and measurement criteria

Step 5: Share follow-up
  → Share improvement results with the feedback provider
  → Complete the feedback loop

# Weekly Growth Journal
## Date: YYYY-MM-DD ~ YYYY-MM-DD

### Goals for This Week
- [ ] Goal 1
- [ ] Goal 2
- [ ] Goal 3

### Achievements
- Achievement 1: Brief description
- Achievement 2: Brief description

### What I Learned
- Technical: What new things did I learn
- Soft skills: Lessons in collaboration and communication

### What Was Lacking
- Shortcomings and root cause analysis
- Time management, focus, etc.

### Goals for Next Week
- [ ] Goal 1 (High priority)
- [ ] Goal 2
- [ ] Goal 3

### Gratitude
- Appreciation for colleagues, environment, opportunities, etc.

### One-Line Retrospective
- "If I summarize this week in one sentence?"

Common mistake patterns:
- Failing to add .env files to .gitignore
- Changing a private repo to public
- Committing internal code to a forked repo
- Hardcoding API keys and database passwords

Supply chain attack scenario:
- Malicious code injected into dependency packages
- CI/CD pipeline infiltration
- Code theft through development tool plugins

Immediate isolation checklist:
- Block the leaked repository or access path
- Change all related account passwords immediately
- Revoke access methods such as VPN and SSH keys
- Initial assessment of leak scope (which code, branches, timeframe)

# Secret rotation checklist
# 1. Reissue all API keys
# 2. Change database passwords
# 3. Regenerate OAuth client secrets
# 4. Replace JWT signing keys
# 5. Rotate encryption keys
# 6. Reissue service account credentials
# 7. Refresh all environment variables

# Using BFG Repo-Cleaner to remove sensitive information
# Note: History rewriting affects the entire team

# Remove specific files example
bfg --delete-files credentials.json

# Remove text patterns example
bfg --replace-text passwords.txt

# Force push after cleanup
git reflog expire --expire=now --all
git gc --prune=now --aggressive

Impact assessment items:
- Scope and sensitivity of leaked code
- Value of exposed business logic
- Whether customer data was exposed
- Whether security vulnerabilities were exposed
- Impact on competitors
- Legal obligations (data protection laws, etc.)

Three requirements for trade secret status:
1. Secrecy: Not publicly known
2. Economic value: Has independent economic value
3. Reasonable efforts: Maintained as secret through reasonable efforts

"Reasonable efforts" is the most frequently contested requirement in court.
-> Access controls, confidentiality markings, and NDAs serve as evidence of management efforts.

Injunction filing preparation:
1. Evidence of the leak (screenshots, logs, commit records)
2. Materials proving trade secret status
3. Evidence of secrecy management efforts (access logs, NDAs)
4. Proof of urgency (irreparable harm if use continues)
5. Security deposit (amount determined by the court)

Evidence preservation methods:
- Web page captures (including notarization)
- Backup of Git logs and commit records
- Preservation of access logs (server, VPN, repository)
- Preservation of communication records (email, messages)
- Securing digital forensics experts

# GitHub Actions secret scanning setup example
name: Secret Scanning
on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - name: Run GitGuardian scan
        uses: GitGuardian/ggshield-action@v1
        env:
          GITGUARDIAN_API_KEY: GITGUARDIAN_API_KEY_PLACEHOLDER

# .pre-commit-config.yaml
repos:
  - repo: https://github.com/pre-commit/pre-commit-hooks
    rev: v4.5.0
    hooks:
      - id: detect-private-key
      - id: check-added-large-files
        args: ['--maxkb=500']

  - repo: https://github.com/Yelp/detect-secrets
    rev: v1.4.0
    hooks:
      - id: detect-secrets
        args: ['--baseline', '.secrets.baseline']

# Git commit signing setup
git config --global commit.gpgsign true
git config --global user.signingkey YOUR_GPG_KEY_ID

# Verify signed commit
git log --show-signature -1

DLP coverage areas:
- Email attachment inspection
- Cloud storage upload monitoring
- External storage device (USB) usage restrictions
- Clipboard copy restrictions (source code related)
- Screen capture monitoring

Access management checklist:
- Apply Role-Based Access Control (RBAC)
- Separate access rights per repository
- Distinguish read-only vs write permissions
- Limit production code access to necessary personnel
- Regular access rights audits (quarterly)
- Automatic expiration for temporary access

Offboarding checklist (security related):
1. Immediately revoke all repository access
2. Delete SSH keys and personal access tokens
3. Deactivate VPN accounts
4. Deactivate email and messaging accounts
5. Return and wipe company devices
6. Remove cloud service access
7. Block CI/CD pipeline access
8. Reconfirm confidentiality obligations in exit interview

Essential NDA clauses:
- Specific definition of protected information
- Duration of confidentiality obligation (typically 2-5 years)
- Damages clause for violations
- Non-compete clause (if applicable)
- Explicit statement of post-departure obligations

Source code leak postmortem template:

1. Incident summary
   - Discovery date/time, leak channel, impact scope

2. Timeline
   - Estimated leak time
   - Discovery time
   - Time per response phase

3. Technical analysis
   - Which code was leaked
   - List of exposed secrets
   - Whether vulnerabilities were exposed

4. Response evaluation
   - What went well
   - What to improve
   - Response time analysis

5. Root cause
   - Technical cause
   - Process cause
   - Cultural cause

6. Action items
   - Short-term (within 1 week): Secret rotation, access blocking
   - Mid-term (1 month): Security tool adoption, process improvement
   - Long-term (quarter): Security culture reinforcement, training

Phase 1 - Immediate (1 week):
  - Complete all secret rotations
  - Block vulnerable access paths
  - Enhance temporary monitoring

Phase 2 - Short-term (1 month):
  - Adopt secret scanning tools
  - Deploy pre-commit hooks company-wide
  - Audit all access permissions

Phase 3 - Mid-term (quarter):
  - Introduce DLP system
  - Start security training program
  - Establish regular security audit process

Phase 4 - Long-term (annual):
  - Establish security culture
  - Automated security testing pipeline
  - Red team/Blue team exercises

Messages by stakeholder:
Executives: Business impact, legal risk, response status
Dev team: Technical details, immediate actions, changes
Legal team: Evidence status, legal response options, timeline
Customers: Impact status, protective measures, follow-up plan (if needed)