diff --git a/doc/security/INCIDENT_RESPONSE_PLAN.md b/doc/security/INCIDENT_RESPONSE_PLAN.md
index 96b927d3..24e73217 100644
--- a/doc/security/INCIDENT_RESPONSE_PLAN.md
+++ b/doc/security/INCIDENT_RESPONSE_PLAN.md
@@ -1,16 +1,18 @@
-# Incident Response Plan (IRP) for API Dash
+# Incident Response Plan (IRP)
 
-**Document Version:** 1.0  
-**Effective Date:** December 2025  
-**Project:** API Dash - Open Source Cross-Platform API Client  
-**Classification:** Public  
-**Review Cycle:** Annually or post-incident
+This Incident Response Plan (IRP) establishes a structured approach for identifying, managing, and resolving security incidents affecting the API Dash open source project. API Dash is a cross-platform API testing client used by developers worldwide, making security incident response critical to maintaining user trust and protecting the community.
 
----
+Key objectives are:
+
+1. **Rapid Detection**: Identify security incidents quickly through community reporting and automated monitoring
+2. **Effective Response**: Contain and resolve incidents with minimal impact to users
+3. **Transparent Communication**: Keep the community informed while protecting sensitive details
+4. **Continuous Improvement**: Learn from incidents to strengthen security posture
+5. **Compliance**: Adhere to responsible disclosure practices and regulatory requirements
 
 ## Table of Contents
 
-1. [Executive Summary](#1-executive-summary)
+1. [Incident Response Timeline](#1-incident-response-timeline)
 2. [Purpose and Scope](#2-purpose-and-scope)
 3. [Incident Response Team](#3-incident-response-team)
 4. [Incident Classification and Severity](#4-incident-classification-and-severity)
@@ -20,39 +22,22 @@
 8. [Post-Incident Activities](#8-post-incident-activities)
 9. [Tools and Resources](#9-tools-and-resources)
 10. [Training and Awareness](#10-training-and-awareness)
-11. [Legal and Compliance](#11-legal-and-compliance)
-12. [Plan Maintenance](#12-plan-maintenance)
-13. [Appendices](#13-appendices)
+11. [Appendix](#11-appendix)
 
----
+## 1. Incident Response Timeline
 
-## 1. Executive Summary
-
-This Incident Response Plan (IRP) establishes a structured approach for identifying, managing, and resolving security incidents affecting the API Dash open source project. API Dash is a cross-platform API testing client used by developers worldwide, making security incident response critical to maintaining user trust and protecting the community.
-
-### Key Objectives
-
-1. **Rapid Detection**: Identify security incidents quickly through community reporting and automated monitoring
-2. **Effective Response**: Contain and resolve incidents with minimal impact to users
-3. **Transparent Communication**: Keep the community informed while protecting sensitive details
-4. **Continuous Improvement**: Learn from incidents to strengthen security posture
-5. **Compliance**: Adhere to responsible disclosure practices and regulatory requirements
-
-### Incident Response Goals (2025 Standards)
-
-- **Detection Time**: < 1 hour for critical vulnerabilities
-- **Initial Response**: < 4 hours for critical, < 24 hours for high severity
-- **Patch Release**: < 72 hours for critical vulnerabilities
+- **Detection Time**: < 6 hour for critical vulnerabilities
+- **Initial Response**: < 24 hours
+- **Patch Release**: Depends on the vulnerability
 - **Public Disclosure**: Within 90 days of fix, coordinated with reporters
 - **Post-Incident Review**: Within 7 days of incident resolution
 
----
-
 ## 2. Purpose and Scope
 
 ### 2.1 Purpose
 
 This IRP provides:
+
 - Clear procedures for handling security incidents
 - Defined roles and responsibilities
 - Communication protocols
@@ -62,6 +47,7 @@ This IRP provides:
 ### 2.2 Scope
 
 **In Scope:**
+
 - Security vulnerabilities in API Dash application code
 - Vulnerabilities in API Dash dependencies and packages
 - Security issues in build/release infrastructure
@@ -73,6 +59,7 @@ This IRP provides:
 - Compromised releases or distribution channels
 
 **Out of Scope:**
+
 - General bugs or functionality issues (use GitHub Issues)
 - User configuration errors or misuse
 - Security of third-party APIs being tested
@@ -83,23 +70,25 @@ This IRP provides:
 ### 2.3 Applicability
 
 This IRP applies to:
+
 - All API Dash maintainers and contributors
 - Security researchers reporting vulnerabilities
 - Users affected by security incidents
 - Third-party security teams coordinating disclosures
 
----
-
 ## 3. Incident Response Team
 
 ### 3.1 Core Team Structure
 
+**Primary**: Ankit Mahato
+**Backup**: Ashita Prasad
+
 #### 3.1.1 Incident Commander (IC)
-**Role**: Overall incident coordination and decision-making  
-**Primary**: Lead Maintainer (@foss42 GitHub organization)  
-**Backup**: Senior Maintainer
+
+**Role**: Overall incident coordination and decision-making
 
 **Responsibilities**:
+
 - Activate incident response procedures
 - Coordinate team activities
 - Make critical decisions
@@ -107,11 +96,11 @@ This IRP applies to:
 - Declare incident closure
 
 #### 3.1.2 Security Lead
-**Role**: Technical security assessment and remediation  
-**Primary**: Security-focused maintainer  
-**Backup**: Senior developer with security experience
+
+**Role**: Technical security assessment and remediation
 
 **Responsibilities**:
+
 - Vulnerability analysis and validation
 - Risk assessment and severity classification
 - Technical remediation guidance
@@ -119,11 +108,11 @@ This IRP applies to:
 - Coordinate with security researchers
 
 #### 3.1.3 Communications Lead
-**Role**: Internal and external communications  
-**Primary**: Project lead or designated spokesperson  
-**Backup**: Senior maintainer
+
+**Role**: Internal and external communications
 
 **Responsibilities**:
+
 - Draft incident communications
 - Manage GitHub Security Advisories
 - Coordinate vulnerability disclosure
@@ -131,11 +120,11 @@ This IRP applies to:
 - Handle media inquiries (if applicable)
 
 #### 3.1.4 Technical Lead
-**Role**: Code fixes and release management  
-**Primary**: Core maintainer with release permissions  
-**Backup**: Senior developer
+
+**Role**: Code fixes and release management
 
 **Responsibilities**:
+
 - Develop and test security patches
 - Emergency release coordination
 - Code review of security fixes
@@ -143,63 +132,44 @@ This IRP applies to:
 - Update dependencies
 
 #### 3.1.5 Documentation Lead
-**Role**: Incident documentation and reporting  
-**Primary**: Designated maintainer  
-**Backup**: Any core team member
+
+**Role**: Incident documentation and reporting
 
 **Responsibilities**:
+
 - Document incident timeline
 - Maintain incident logs
 - Create post-incident reports
 - Update security documentation
 - Track action items
 
-### 3.2 Extended Team
-
-- **Community Moderators**: Manage community communications
-- **Legal Advisor**: Provide legal guidance (if available)
-- **External Security Experts**: Consultants for complex incidents
-- **Platform Representatives**: GitHub, distribution platform contacts
-
-### 3.3 Contact Information
+### 3.2 Contact Information
 
 **Primary Communication Channel**: Private GitHub Security Advisory  
-**Emergency Contact**: security@apidash.dev (or maintainer emails)  
-**Escalation Path**: GitHub organization owners → CNCF security team (if applicable)
-
-**Response Time Commitments**:
-- Critical: Response within 4 hours
-- High: Response within 24 hours
-- Medium: Response within 72 hours
-- Low: Response within 1 week
-
----
+**Emergency Contact**: ankit[at] apidash.dev (or maintainer emails)
 
 ## 4. Incident Classification and Severity
 
 ### 4.1 Severity Levels (Aligned with CVSS 3.1)
 
 #### CRITICAL (CVSS 9.0-10.0)
+
 **Definition**: Vulnerabilities with severe impact requiring immediate action
 
 **Examples**:
+
 - Remote code execution (RCE) vulnerabilities
 - Arbitrary code execution in template engine
 - Critical data exposure of all users' credentials
 - Supply chain compromise (malicious dependency)
 - Backdoor or malicious code in releases
 
-**Response SLA**:
-- Initial Response: 4 hours
-- Assessment: 8 hours
-- Patch Development: 48 hours
-- Patch Release: 72 hours
-- Public Disclosure: Immediate advisory, full disclosure after 7-14 days
-
 #### HIGH (CVSS 7.0-8.9)
+
 **Definition**: Significant vulnerabilities that could lead to major impact
 
 **Examples**:
+
 - Authentication bypass
 - Privilege escalation vulnerabilities
 - SQL injection or command injection in generated code
@@ -207,17 +177,12 @@ This IRP applies to:
 - Deserialization vulnerabilities
 - XSS or code injection in UI components
 
-**Response SLA**:
-- Initial Response: 24 hours
-- Assessment: 48 hours
-- Patch Development: 1 week
-- Patch Release: 2 weeks
-- Public Disclosure: Full disclosure after 30 days
-
 #### MEDIUM (CVSS 4.0-6.9)
+
 **Definition**: Vulnerabilities with moderate impact
 
 **Examples**:
+
 - Information disclosure of non-critical data
 - CSRF vulnerabilities
 - Insecure defaults
@@ -225,39 +190,27 @@ This IRP applies to:
 - Denial of service (local only)
 - Weak cryptography
 
-**Response SLA**:
-- Initial Response: 72 hours
-- Assessment: 1 week
-- Patch Development: 2-4 weeks
-- Patch Release: Next regular release
-- Public Disclosure: Full disclosure after 60 days
-
 #### LOW (CVSS 0.1-3.9)
+
 **Definition**: Minor vulnerabilities with limited impact
 
 **Examples**:
+
 - Information leakage with minimal impact
 - Security misconfigurations
 - Minor input validation issues
 - Non-sensitive data exposure
 
-**Response SLA**:
-- Initial Response: 1 week
-- Assessment: 2 weeks
-- Patch Development: As resources allow
-- Patch Release: Next regular release
-- Public Disclosure: Full disclosure after 90 days
-
 ### 4.2 Incident Categories
 
-| Category | Description | Examples |
-|----------|-------------|----------|
-| **Vulnerability** | Security flaws in code or dependencies | CVE-reported vulnerabilities |
-| **Data Breach** | Unauthorized access to sensitive data | Credential exposure, data leak |
-| **Malicious Code** | Intentional backdoors or malware | Supply chain attack, compromised dependency |
-| **Infrastructure** | Compromise of project infrastructure | GitHub account takeover, website defacement |
-| **Social Engineering** | Attacks targeting team or users | Phishing, impersonation |
-| **Availability** | DoS or service disruption | Resource exhaustion attacks |
+| Category               | Description                            | Examples                                    |
+| ---------------------- | -------------------------------------- | ------------------------------------------- |
+| **Vulnerability**      | Security flaws in code or dependencies | CVE-reported vulnerabilities                |
+| **Data Breach**        | Unauthorized access to sensitive data  | Credential exposure, data leak              |
+| **Malicious Code**     | Intentional backdoors or malware       | Supply chain attack, compromised dependency |
+| **Infrastructure**     | Compromise of project infrastructure   | GitHub account takeover, website defacement |
+| **Social Engineering** | Attacks targeting team or users        | Phishing, impersonation                     |
+| **Availability**       | DoS or service disruption              | Resource exhaustion attacks                 |
 
 ### 4.3 Impact Assessment Factors
 
@@ -271,8 +224,6 @@ Severity is determined by evaluating:
 6. **User Interaction**: Required user interaction (none vs. significant)
 7. **Privileges Required**: Attacker privileges needed (none vs. admin)
 
----
-
 ## 5. Incident Response Lifecycle
 
 ### 5.1 Phase 1: Preparation
@@ -280,6 +231,7 @@ Severity is determined by evaluating:
 #### Ongoing Activities
 
 **1. Proactive Security Measures**
+
 - Enable GitHub Dependabot alerts
 - Implement automated security scanning in CI/CD
 - Regular dependency updates and security patches
@@ -287,6 +239,7 @@ Severity is determined by evaluating:
 - Maintain updated contact information
 
 **2. Monitoring and Detection**
+
 - Monitor GitHub Security Advisories
 - Subscribe to security mailing lists for dependencies
 - Track Dependabot alerts
@@ -294,6 +247,7 @@ Severity is determined by evaluating:
 - Review CodeQL scan results
 
 **3. Tools and Access**
+
 - Maintain incident response toolkit
 - Ensure access to critical systems
 - Keep security advisory templates ready
@@ -301,6 +255,7 @@ Severity is determined by evaluating:
 - Prepare patch release procedures
 
 **4. Documentation**
+
 - Keep IRP updated
 - Maintain security runbooks
 - Document emergency procedures
@@ -311,15 +266,17 @@ Severity is determined by evaluating:
 #### Step 1: Incident Detection
 
 **Detection Sources**:
+
 1. **GitHub Security Advisories** (private vulnerability reports)
 2. **Dependabot alerts** (dependency vulnerabilities)
-3. **Community reports** (security@apidash.dev or GitHub Issues)
+3. **Community reports** (ankit[at] apidash.dev or GitHub Issues)
 4. **Security researchers** (coordinated disclosure)
 5. **Automated scanning** (CodeQL, SAST tools)
 6. **Social media** (public vulnerability discussions)
 7. **Third-party notification** (GitHub Security Lab, etc.)
 
-**Initial Actions** (within 1 hour):
+**Initial Actions**:
+
 ```
 [ ] Acknowledge receipt of report
 [ ] Assign incident commander
@@ -331,6 +288,7 @@ Severity is determined by evaluating:
 #### Step 2: Initial Triage
 
 **Triage Checklist**:
+
 ```
 [ ] Validate the vulnerability (is it real?)
 [ ] Determine affected versions
@@ -342,6 +300,7 @@ Severity is determined by evaluating:
 ```
 
 **Triage Decision Matrix**:
+
 - **Valid Security Issue** → Proceed to analysis
 - **Non-Security Bug** → Route to regular issue tracking
 - **Duplicate/Known** → Reference existing advisory/issue
@@ -350,13 +309,16 @@ Severity is determined by evaluating:
 #### Step 3: Detailed Analysis
 
 **Analysis Activities**:
+
 1. **Reproduce the Vulnerability**
+
    - Set up test environment
    - Follow reproduction steps
    - Document exact conditions
    - Capture evidence (screenshots, logs)
 
 2. **Impact Assessment**
+
    - Determine CVSS score
    - Identify affected components
    - Assess data at risk
@@ -364,6 +326,7 @@ Severity is determined by evaluating:
    - Identify downstream effects
 
 3. **Root Cause Analysis**
+
    - Identify vulnerable code
    - Determine when introduced (git blame)
    - Check if present in other locations
@@ -376,6 +339,7 @@ Severity is determined by evaluating:
    - Assess network exposure
 
 **Analysis Output**:
+
 - Severity classification (Critical/High/Medium/Low)
 - Affected versions and components
 - Root cause summary
@@ -389,6 +353,7 @@ Severity is determined by evaluating:
 **Immediate Actions** (Critical/High severity):
 
 1. **For Critical Vulnerabilities in Released Versions**:
+
    ```
    [ ] Confirm severity with team consensus
    [ ] Activate emergency response team
@@ -399,6 +364,7 @@ Severity is determined by evaluating:
    ```
 
 2. **For Infrastructure Compromise**:
+
    ```
    [ ] Revoke compromised credentials immediately
    [ ] Enable 2FA on all accounts (if not enabled)
@@ -409,6 +375,7 @@ Severity is determined by evaluating:
    ```
 
 3. **For Supply Chain Attacks**:
+
    ```
    [ ] Identify malicious dependency/code
    [ ] Pin previous known-good versions
@@ -429,6 +396,7 @@ Severity is determined by evaluating:
 #### Long-term Containment
 
 **Sustained Response Actions**:
+
 - Implement temporary security controls
 - Monitor for exploitation attempts
 - Prepare comprehensive fix
@@ -440,6 +408,7 @@ Severity is determined by evaluating:
 #### Root Cause Elimination
 
 **1. Develop Security Fix**:
+
 ```
 [ ] Design secure solution
 [ ] Implement fix in development branch
@@ -451,6 +420,7 @@ Severity is determined by evaluating:
 ```
 
 **2. Code Review Requirements**:
+
 - Minimum 2 security-aware reviewers
 - Focus on security implications
 - Check for similar issues elsewhere
@@ -459,6 +429,7 @@ Severity is determined by evaluating:
 - Verify no information leakage
 
 **3. Testing Validation**:
+
 - Unit tests for security fix
 - Integration tests
 - Regression testing
@@ -467,6 +438,7 @@ Severity is determined by evaluating:
 - Cross-platform validation
 
 **4. Dependency Updates**:
+
 ```
 [ ] Identify updated secure versions
 [ ] Test compatibility
@@ -497,50 +469,50 @@ Severity is determined by evaluating:
 [ ] Verify release availability
 ```
 
-**2. Release Prioritization**:
+**2. Release Announcement Template**:
 
-| Severity | Release Timeline | Release Type |
-|----------|-----------------|--------------|
-| Critical | 48-72 hours | Emergency patch |
-| High | 1-2 weeks | Security patch |
-| Medium | 2-4 weeks | Regular release |
-| Low | Next planned release | Regular release |
-
-**3. Release Announcement Template**:
-
-```markdown
+```
 # Security Release: API Dash v{VERSION}
 
 ## Overview
+
 This is a security release addressing [severity] vulnerability in API Dash.
 
 ## Affected Versions
+
 - {version range}
 
 ## Fixed Vulnerabilities
+
 - **{CVE-ID}** (Severity: {CRITICAL/HIGH/MEDIUM/LOW})
   - {Brief description}
   - CVSS Score: {score}
 
 ## Recommended Action
+
 All users should upgrade immediately to version {VERSION}.
 
 ## Upgrade Instructions
+
 {Platform-specific upgrade steps}
 
 ## Workarounds (if applicable)
+
 {Temporary workarounds for users who cannot upgrade immediately}
 
 ## Credits
+
 We would like to thank {researcher name} for responsibly disclosing this vulnerability.
 
 ## References
+
 - GitHub Security Advisory: {GHSA link}
 - CVE: {CVE link}
 - Detailed Security Advisory: {link}
 ```
 
-**4. Distribution Channels**:
+**3. Distribution Channels**:
+
 - GitHub Releases (primary)
 - App Store (iOS/iPad)
 - Platform-specific package managers (apt, rpm, etc.)
@@ -548,15 +520,16 @@ We would like to thank {researcher name} for responsibly disclosing this vulnera
 - Documentation updates
 
 **5. User Notification**:
+
 - GitHub Security Advisory (automatic notification to watchers)
 - Release notes
-- Social media (Twitter/X, Discord)
-- Security mailing list (if established)
+- Social media (LinkedIn, X, Discord)
 - In-app notification (for future versions)
 
 #### Verification
 
 **Post-Release Validation**:
+
 ```
 [ ] Verify fix effectiveness
 [ ] Confirm vulnerability no longer exploitable
@@ -570,8 +543,6 @@ We would like to thank {researcher name} for responsibly disclosing this vulnera
 
 See [Section 8: Post-Incident Activities](#8-post-incident-activities) for detailed procedures.
 
----
-
 ## 6. Communication Plan
 
 ### 6.1 Communication Principles
@@ -588,18 +559,15 @@ See [Section 8: Post-Incident Activities](#8-post-incident-activities) for detai
 #### During Active Incident
 
 **Communication Channels**:
+
 - **Primary**: Private GitHub Security Advisory discussion
-- **Real-time**: Dedicated Discord/Slack channel (private)
+- **Real-time**: Dedicated Discord channel (private)
 - **Documentation**: Shared incident log (Google Docs or equivalent)
 - **Escalation**: Direct email to incident commander
 
-**Communication Cadence**:
-- Critical: Updates every 4 hours minimum
-- High: Updates every 12 hours minimum
-- Medium/Low: Updates every 48 hours minimum
-
 **Status Update Template**:
-```markdown
+
+```
 ## Incident Status Update - {Date/Time}
 
 **Incident ID**: {IR-YYYY-MM-DD-###}
@@ -607,24 +575,30 @@ See [Section 8: Post-Incident Activities](#8-post-incident-activities) for detai
 **Phase**: {Detection/Analysis/Containment/Eradication/Recovery}
 
 ### Current Status
+
 {Brief status description}
 
 ### Activities Completed
+
 - {Item 1}
 - {Item 2}
 
 ### In Progress
+
 - {Item 1}
 - {Item 2}
 
 ### Next Steps
+
 - {Item 1}
 - {Item 2}
 
 ### Blockers/Issues
+
 - {Any blockers}
 
 ### Expected Next Update
+
 {Time}
 ```
 
@@ -632,99 +606,26 @@ See [Section 8: Post-Incident Activities](#8-post-incident-activities) for detai
 
 #### Communication to Security Researchers
 
-**Initial Response (within 4-24 hours)**:
-```markdown
+```
 Dear {Researcher Name},
 
-Thank you for reporting this security issue to the API Dash project. 
+Thank you for reporting this security issue to the API Dash project.
 We have received your report and assigned it ID {IR-YYYY-MM-DD-###}.
 
-Our security team is currently analyzing the issue and will provide 
+Our security team is currently analyzing the issue and will provide
 an initial assessment within {timeframe} hours.
 
-We appreciate your responsible disclosure and will keep you updated 
+We appreciate your responsible disclosure and will keep you updated
 on our progress.
 
 Best regards,
-API Dash Security Team
-```
-
-**Progress Updates**:
-- Provide updates every 7 days minimum
-- Share assessment results
-- Discuss remediation timeline
-- Coordinate disclosure date
-
-**Disclosure Coordination**:
-```markdown
-Dear {Researcher Name},
-
-We have completed development of a fix for {vulnerability ID}. 
-We plan to release version {VERSION} on {DATE}.
-
-Proposed disclosure timeline:
-- {DATE}: Patch release
-- {DATE + 7 days}: Limited disclosure (GHSA)
-- {DATE + 30 days}: Full public disclosure
-
-Please let us know if you have any concerns with this timeline 
-or if you need additional information.
-
-Credit: We would like to credit you as "{Preferred Name/Handle}" 
-in the advisory. Please confirm or provide alternative credit info.
+API Dash Team
 ```
 
 #### Communication to Users
 
-**Security Advisory Template**:
-```markdown
-# Security Advisory: {Title}
-
-**Advisory ID**: GHSA-{id}  
-**CVE**: CVE-{year}-{number}  
-**Severity**: {CRITICAL/HIGH/MEDIUM/LOW}  
-**Affected Versions**: {versions}  
-**Fixed in Version**: {version}  
-**Publication Date**: {date}
-
-## Summary
-{Brief, clear description of the vulnerability suitable for all audiences}
-
-## Impact
-{What could an attacker do? What data/systems are at risk?}
-
-## Affected Configurations
-{Are all users affected or only specific configurations?}
-
-## Remediation
-
-### Immediate Actions
-1. Upgrade to version {VERSION} immediately
-2. {Additional steps if needed}
-
-### Workarounds (if patch not immediately possible)
-{Temporary mitigations}
-
-## Timeline
-- {Date}: Vulnerability reported
-- {Date}: Fix developed
-- {Date}: Patch released
-- {Date}: Public disclosure
-
-## References
-- Fix commit: {link}
-- GitHub Security Advisory: {link}
-- CVE Details: {link}
-
-## Credits
-Discovered by: {Researcher name/handle}  
-Coordinated disclosure: {if applicable}
-
-## Contact
-For questions about this advisory: security@apidash.dev
-```
-
 **Social Media/Community Update**:
+
 ```markdown
 🔒 Security Update: API Dash v{VERSION} released
 
@@ -736,39 +637,8 @@ Details: {link to GHSA}
 Download: {link to release}
 
 Thank you to @{researcher} for responsible disclosure.
-
-#security #apidash #infosec
 ```
 
-### 6.4 Media and Public Relations
-
-**For High-Profile Incidents**:
-- Designate single spokesperson
-- Prepare statement in advance
-- Coordinate with legal (if available)
-- Monitor public discussion
-- Correct misinformation promptly
-
-**Statement Template**:
-```markdown
-API Dash Security Statement
-
-The API Dash team was notified of a security vulnerability affecting 
-versions {versions} on {date}. We immediately began investigating and 
-developing a fix.
-
-We have released version {VERSION} which addresses this issue. All users 
-should upgrade as soon as possible.
-
-We take security seriously and appreciate the responsible disclosure from 
-the security community. Users can report security issues confidentially 
-through our GitHub Security Advisories.
-
-For more information: {link}
-```
-
----
-
 ## 7. Incident Types and Response Procedures
 
 ### 7.1 Code Vulnerability
@@ -778,44 +648,50 @@ For more information: {link}
 **Detection**: Security researcher report, automated scan, or code review
 
 **Response Procedure**:
-1. **Receive and Validate** (0-4 hours)
+
+1. **Receive and Validate**
+
    - Acknowledge report
    - Validate vulnerability
    - Create private GHSA
    - Assign severity
 
-2. **Analyze** (4-24 hours)
+2. **Analyze**
+
    - Reproduce issue
    - Determine affected versions
    - Assess impact
    - Identify root cause
 
-3. **Develop Fix** (24-72 hours for critical)
+3. **Develop Fix**
+
    - Implement secure solution
    - Add security tests
    - Code review
    - Test thoroughly
 
-4. **Release Patch** (48-96 hours for critical)
+4. **Release Patch**
+
    - Create patch release
    - Update documentation
    - Publish GHSA
    - Notify users
 
-5. **Monitor** (1-2 weeks post-release)
+5. **Monitor**
    - Track adoption
    - Monitor for exploitation
    - Address user questions
 
 **Example Decision Tree**:
+
 ```
 Vulnerability Report
     │
     ├─ Valid & Security-related?
     │   ├─ Yes → Assess Severity
-    │   │        ├─ Critical → Emergency Response (4hr SLA)
-    │   │        ├─ High → Priority Response (24hr SLA)
-    │   │        └─ Med/Low → Standard Response (72hr SLA)
+    │   │        ├─ Critical → Emergency Response
+    │   │        ├─ High → Priority Response
+    │   │        └─ Med/Low → Standard Response
     │   └─ No → Route to standard bug tracking
     │
     └─ Continue with standard process
@@ -828,7 +704,9 @@ Vulnerability Report
 **Detection**: Dependabot alert, security advisory, or manual audit
 
 **Response Procedure**:
-1. **Assess Impact** (0-24 hours)
+
+1. **Assess Impact**
+
    ```
    [ ] Identify vulnerable dependency
    [ ] Check if vulnerability affects API Dash usage
@@ -838,60 +716,26 @@ Vulnerability Report
    ```
 
 2. **Evaluate Remediation Options**:
+
    - **Option A**: Update to patched version
      - Test compatibility
      - Update pubspec.yaml
      - Verify fix
-     
    - **Option B**: Replace with alternative library
      - Research alternatives
      - Plan migration
      - Implement replacement
-     
    - **Option C**: Apply workaround
      - Disable vulnerable feature
      - Implement compensating controls
      - Document limitation
 
-3. **Release Update**:
-   - For critical: Emergency patch within 72 hours
-   - For high: Security update within 1 week
-   - For medium/low: Next regular release
-
-4. **Documentation**:
-   ```markdown
-   ## Dependency Security Update
-   
-   **Affected Dependency**: {package}@{version}
-   **Vulnerability**: {CVE or description}
-   **Severity**: {level}
-   **Resolution**: Updated to {package}@{new-version}
-   **API Dash Versions Affected**: {versions}
-   **Fixed in**: API Dash v{version}
-   ```
-
-**Dependabot Integration**:
-```yaml
-# .github/dependabot.yml
-version: 2
-updates:
-  - package-ecosystem: "pub"
-    directory: "/"
-    schedule:
-      interval: "weekly"
-    open-pull-requests-limit: 10
-    labels:
-      - "dependencies"
-      - "security"
-    assignees:
-      - "security-team-member"
-```
-
 ### 7.3 Supply Chain Attack
 
 **Scenario**: Malicious code injected through compromised dependency or build pipeline
 
-**Detection**: 
+**Detection**:
+
 - Unexpected package behavior
 - Community reports of malicious activity
 - Checksum mismatches
@@ -899,7 +743,8 @@ updates:
 
 **Response Procedure** (CRITICAL - IMMEDIATE ACTION):
 
-**Phase 1: Emergency Response (0-1 hour)**
+**Phase 1: Emergency Response**
+
 ```
 [ ] STOP all builds and releases immediately
 [ ] Revoke access to compromised accounts/systems
@@ -908,7 +753,8 @@ updates:
 [ ] Identify affected versions
 ```
 
-**Phase 2: Containment (1-4 hours)**
+**Phase 2: Containment**
+
 ```
 [ ] Remove malicious packages from distribution
 [ ] Contact platform providers (GitHub, App Stores)
@@ -918,7 +764,8 @@ updates:
 [ ] Identify attack vector
 ```
 
-**Phase 3: Analysis (4-24 hours)**
+**Phase 3: Analysis**
+
 ```
 [ ] Forensic analysis of compromise
 [ ] Identify malicious code
@@ -929,7 +776,8 @@ updates:
 [ ] Analyze access logs
 ```
 
-**Phase 4: Eradication (24-48 hours)**
+**Phase 4: Eradication**
+
 ```
 [ ] Remove all malicious code
 [ ] Verify source code integrity
@@ -939,7 +787,8 @@ updates:
 [ ] Audit all dependencies
 ```
 
-**Phase 5: Recovery (48-96 hours)**
+**Phase 5: Recovery**
+
 ```
 [ ] Release clean version with new version number
 [ ] Sign releases with new keys (if keys compromised)
@@ -948,13 +797,15 @@ updates:
 [ ] Monitor for continued threats
 ```
 
-**User Communication (URGENT)**:
-```markdown
+**User Communication (LinkedIn or public channels)**:
+
+```
 🚨 CRITICAL SECURITY ALERT 🚨
 
 Versions {versions} of API Dash have been compromised with malicious code.
 
 IMMEDIATE ACTION REQUIRED:
+
 1. UNINSTALL affected versions immediately
 2. DO NOT use until further notice
 3. Change any credentials entered in these versions
@@ -971,7 +822,8 @@ More details: {link to emergency advisory}
 
 **Response Procedure**:
 
-**Phase 1: Initial Response (0-1 hour)**
+**Phase 1: Initial Response**
+
 ```
 [ ] Confirm breach occurred
 [ ] Identify data accessed/exfiltrated
@@ -981,7 +833,8 @@ More details: {link to emergency advisory}
 [ ] Assess legal obligations (GDPR, CCPA, etc.)
 ```
 
-**Phase 2: Assessment (1-6 hours)**
+**Phase 2: Assessment**
+
 ```
 [ ] Identify affected users
 [ ] Determine data sensitivity
@@ -991,7 +844,8 @@ More details: {link to emergency advisory}
 [ ] Identify attack method
 ```
 
-**Phase 3: User Notification (6-72 hours)**
+**Phase 3: User Notification**
+
 ```
 [ ] Prepare notification message
 [ ] Identify notification method
@@ -1001,35 +855,43 @@ More details: {link to emergency advisory}
 ```
 
 **Breach Notification Template**:
-```markdown
+
+```
 # Data Breach Notification
 
-**Date of Breach**: {date}  
-**Date of Discovery**: {date}  
+**Date of Breach**: {date}
+**Date of Discovery**: {date}
 **Notification Date**: {date}
 
 ## What Happened
+
 {Clear description of the breach}
 
 ## What Information Was Involved
+
 {List of data types: credentials, API keys, response data, etc.}
 
 ## What We're Doing
+
 {Steps taken to contain and investigate}
 
 ## What You Should Do
+
 1. {Action item 1}
 2. {Action item 2}
 3. {Action item 3}
 
 ## Additional Information
+
 {Resources, support contact, FAQ}
 
 ## Contact Us
+
 {Contact information for questions}
 ```
 
 **Regulatory Compliance**:
+
 - **GDPR**: Notify supervisory authority within 72 hours if EU data affected
 - **CCPA**: Notify affected California residents without unreasonable delay
 - **Other jurisdictions**: Follow applicable data breach notification laws
@@ -1040,7 +902,8 @@ More details: {link to emergency advisory}
 
 **Response Procedure**:
 
-**Phase 1: Immediate Lockdown (0-15 minutes)**
+**Phase 1: Immediate Lockdown**
+
 ```
 [ ] Revoke compromised credentials
 [ ] Enable/verify 2FA on all accounts
@@ -1050,7 +913,8 @@ More details: {link to emergency advisory}
 [ ] Contact platform support
 ```
 
-**Phase 2: Investigation (15 minutes - 2 hours)**
+**Phase 2: Investigation**
+
 ```
 [ ] Review access logs
 [ ] Identify unauthorized actions
@@ -1060,7 +924,8 @@ More details: {link to emergency advisory}
 [ ] Review recent commits/changes
 ```
 
-**Phase 3: Remediation (2-24 hours)**
+**Phase 3: Remediation**
+
 ```
 [ ] Revert unauthorized changes
 [ ] Strengthen access controls
@@ -1070,7 +935,8 @@ More details: {link to emergency advisory}
 [ ] Consider new authentication methods (hardware keys)
 ```
 
-**Phase 4: Recovery (24-72 hours)**
+**Phase 4: Recovery**
+
 ```
 [ ] Restore systems to secure state
 [ ] Verify integrity of code and releases
@@ -1080,6 +946,7 @@ More details: {link to emergency advisory}
 ```
 
 **GitHub Specific Actions**:
+
 ```
 [ ] Review "Settings > Audit log"
 [ ] Check "Security > Deploy keys"
@@ -1096,7 +963,8 @@ More details: {link to emergency advisory}
 
 **Response Procedure**:
 
-**Phase 1: Detection (0-1 hour)**
+**Phase 1: Detection**
+
 ```
 [ ] Identify suspicious code
 [ ] Determine if merged to main branch
@@ -1105,7 +973,8 @@ More details: {link to emergency advisory}
 [ ] Preserve evidence
 ```
 
-**Phase 2: Containment (1-4 hours)**
+**Phase 2: Containment**
+
 ```
 [ ] Revert malicious commits immediately
 [ ] Block contributor if intentional
@@ -1114,7 +983,8 @@ More details: {link to emergency advisory}
 [ ] Determine if emergency release needed
 ```
 
-**Phase 3: Analysis (4-24 hours)**
+**Phase 3: Analysis**
+
 ```
 [ ] Analyze malicious code intent
 [ ] Determine what it could do
@@ -1123,7 +993,8 @@ More details: {link to emergency advisory}
 [ ] Assess trust in other contributions
 ```
 
-**Phase 4: Communication (24-48 hours)**
+**Phase 4: Communication**
+
 ```
 [ ] If released: Issue security advisory
 [ ] Report to GitHub abuse team
@@ -1133,6 +1004,7 @@ More details: {link to emergency advisory}
 ```
 
 **Prevention Measures**:
+
 - Require code review from trusted maintainers
 - Use automated security scanning on PRs
 - Implement CODEOWNERS file
@@ -1147,19 +1019,22 @@ More details: {link to emergency advisory}
 
 **Timing**: Within 7 days of incident resolution
 
-**Attendees**: 
+**Attendees**:
+
 - Incident Commander
 - All IR team members involved
 - Relevant stakeholders
 
 **Agenda**:
+
 1. Incident timeline review
 2. What went well
 3. What could be improved
 4. Action items
 
 **PIR Template**:
-```markdown
+
+```
 # Post-Incident Review: {Incident ID}
 
 **Date**: {date}
@@ -1167,6 +1042,7 @@ More details: {link to emergency advisory}
 **Attendees**: {list}
 
 ## Incident Summary
+
 - **ID**: {IR-YYYY-MM-DD-###}
 - **Type**: {vulnerability/breach/infrastructure/etc.}
 - **Severity**: {level}
@@ -1174,25 +1050,30 @@ More details: {link to emergency advisory}
 - **Impact**: {users affected, scope}
 
 ## Timeline
-| Time | Event | Owner |
-|------|-------|-------|
+
+| Time        | Event               | Owner    |
+| ----------- | ------------------- | -------- |
 | {timestamp} | {event description} | {person} |
-| ... | ... | ... |
+| ...         | ...                 | ...      |
 
 ## Metrics
+
 - Time to detect: {duration}
 - Time to respond: {duration}
 - Time to patch: {duration}
 - Time to resolve: {duration}
 - Users affected: {number/percentage}
 
-## What Went Well ✅
+## What Went Well
+
 1. {Item 1}
 2. {Item 2}
 3. {Item 3}
 
-## What Could Be Improved 🔄
+## What Could Be Improved
+
 1. {Item 1}
+
    - Root cause: {why}
    - Impact: {what was the effect}
    - Recommendation: {how to fix}
@@ -1203,17 +1084,20 @@ More details: {link to emergency advisory}
    - Recommendation: {how to fix}
 
 ## Action Items
-| Action | Owner | Priority | Due Date | Status |
-|--------|-------|----------|----------|--------|
-| {Action 1} | {name} | {P0/P1/P2} | {date} | {Open/In Progress/Done} |
-| ... | ... | ... | ... | ... |
+
+| Action     | Owner  | Priority   | Due Date | Status                  |
+| ---------- | ------ | ---------- | -------- | ----------------------- |
+| {Action 1} | {name} | {P0/P1/P2} | {date}   | {Open/In Progress/Done} |
+| ...        | ...    | ...        | ...      | ...                     |
 
 ## Lessons Learned
+
 1. {Lesson 1}
 2. {Lesson 2}
 3. {Lesson 3}
 
 ## Documentation Updates Needed
+
 - [ ] Update IRP
 - [ ] Update threat model
 - [ ] Update security documentation
@@ -1221,6 +1105,7 @@ More details: {link to emergency advisory}
 - [ ] Update monitoring/detection
 
 ## Follow-up Meeting
+
 Scheduled for: {date} to review action item progress
 ```
 
@@ -1229,18 +1114,19 @@ Scheduled for: {date} to review action item progress
 **Incident Log**:
 Maintain a comprehensive log of all security incidents:
 
-```markdown
+```
 # Security Incident Log
 
-| ID | Date | Type | Severity | Status | Resolution |
-|----|------|------|----------|--------|------------|
-| IR-2025-12-001 | 2025-12-01 | Vulnerability | HIGH | Resolved | Patched in v1.2.3 |
-| IR-2025-11-045 | 2025-11-15 | Dependency | MEDIUM | Resolved | Updated dep |
-| ... | ... | ... | ... | ... | ... |
+| ID             | Date       | Type          | Severity | Status   | Resolution        |
+| -------------- | ---------- | ------------- | -------- | -------- | ----------------- |
+| IR-2025-12-001 | 2025-12-01 | Vulnerability | HIGH     | Resolved | Patched in v1.2.3 |
+| IR-2025-11-045 | 2025-11-15 | Dependency    | MEDIUM   | Resolved | Updated dep       |
+| ...            | ...        | ...           | ...      | ...      | ...               |
 ```
 
 **Knowledge Base**:
 Create runbooks for common scenarios:
+
 - Dependency update procedure
 - Emergency release process
 - Infrastructure compromise response
@@ -1250,6 +1136,7 @@ Create runbooks for common scenarios:
 
 **Security Enhancements**:
 Based on incident learnings:
+
 1. Implement additional security controls
 2. Update threat model
 3. Enhance monitoring/detection
@@ -1258,6 +1145,7 @@ Based on incident learnings:
 6. Update documentation
 
 **Process Improvements**:
+
 1. Refine IRP procedures
 2. Update response checklists
 3. Improve communication templates
@@ -1265,6 +1153,7 @@ Based on incident learnings:
 5. Streamline escalation paths
 
 **Training**:
+
 1. Conduct incident retrospective training
 2. Share lessons learned with team
 3. Update security awareness materials
@@ -1273,6 +1162,7 @@ Based on incident learnings:
 ### 8.4 Continuous Monitoring
 
 **Post-Incident Monitoring**:
+
 - Monitor for reoccurrence
 - Track patch adoption rates
 - Watch for exploitation attempts
@@ -1280,6 +1170,7 @@ Based on incident learnings:
 - Check for similar vulnerabilities
 
 **Metrics Tracking**:
+
 ```
 Key Performance Indicators (KPIs):
 - Mean Time to Detect (MTTD)
@@ -1291,13 +1182,12 @@ Key Performance Indicators (KPIs):
 - Effectiveness of mitigations
 ```
 
----
-
 ## 9. Tools and Resources
 
 ### 9.1 Security Tools
 
 #### Detection and Monitoring
+
 - **GitHub Dependabot**: Automated dependency vulnerability scanning
 - **CodeQL**: Static application security testing (SAST)
 - **Dart/Flutter Security Linters**: Code quality and security checks
@@ -1305,18 +1195,21 @@ Key Performance Indicators (KPIs):
 - **OWASP Dependency-Check**: Dependency vulnerability analysis
 
 #### Analysis Tools
+
 - **GitHub Security Advisories**: Vulnerability database and disclosure platform
 - **CVE/NVD**: Common Vulnerabilities and Exposures database
 - **CVSS Calculator**: Severity scoring tool
 - **Git History Tools**: For forensic analysis (git log, git blame)
 
 #### Communication
+
 - **GitHub Security Advisories**: Primary disclosure platform
 - **GitHub Discussions**: Community communication
 - **Discord/Slack**: Real-time team communication
 - **Email**: Direct communication with researchers
 
 #### Incident Management
+
 - **GitHub Issues**: Private security issues
 - **GitHub Projects**: Incident tracking board
 - **Shared Documents**: Incident logs (Google Docs/Notion)
@@ -1325,114 +1218,35 @@ Key Performance Indicators (KPIs):
 ### 9.2 Reference Materials
 
 #### Vulnerability Databases
+
 - **GitHub Advisory Database**: https://github.com/advisories
 - **National Vulnerability Database**: https://nvd.nist.gov/
-- **CVE**: https://cve.mitre.org/
-- **Pub.dev Security Advisories**: https://pub.dev/
+- **CVE**: https://www.cve.org
 
 #### Security Frameworks
+
 - **NIST Cybersecurity Framework**: https://www.nist.gov/cyberframework
-- **CIS Controls**: https://www.cisecurity.org/controls
 - **OWASP Top 10**: https://owasp.org/www-project-top-ten/
 - **OWASP Mobile Top 10**: https://owasp.org/www-project-mobile-top-10/
 
 #### Disclosure Guidelines
+
 - **ISO/IEC 29147**: Vulnerability disclosure
-- **CERT Guide to Coordinated Vulnerability Disclosure**: https://vuls.cert.org/
+- **CERT Guide to Coordinated Vulnerability Disclosure**: https://certcc.github.io/CERT-Guide-to-CVD/
 - **Google Project Zero Policy**: 90-day disclosure deadline
 
 #### Legal Resources
+
 - **GDPR**: https://gdpr-info.eu/
 - **CCPA**: https://oag.ca.gov/privacy/ccpa
 - **Data Breach Notification Laws**: State-by-state requirements
 
-### 9.3 Contact Lists
-
-#### Internal Contacts
-```
-Incident Commander:
-- Name: {Lead Maintainer}
-- GitHub: @{username}
-- Email: {email}
-- Phone: {emergency only}
-
-Security Lead:
-- Name: {Security-focused maintainer}
-- GitHub: @{username}
-- Email: {email}
-
-Communications Lead:
-- Name: {Communications person}
-- GitHub: @{username}
-- Email: {email}
-```
-
-#### External Contacts
-```
-GitHub Security Team:
-- Email: security@github.com
-- Emergency: https://github.com/security
-
-Platform Providers:
-- Apple App Store: https://developer.apple.com/contact/
-- Pub.dev: security@pub.dev
-
-Legal (if applicable):
-- TBD based on organization
-
-Security Community:
-- CERT/CC: cert@cert.org
-- OpenSSF: security@openssf.org
-```
-
-### 9.4 Templates and Checklists
-
-**Available in Appendices**:
-- Incident response checklist
-- Security advisory template
-- Post-incident review template
-- Communication templates
-- Severity assessment guide
-
----
-
 ## 10. Training and Awareness
 
-### 10.1 Team Training
-
-**Required Training for IR Team**:
-1. **Incident Response Basics** (Annual)
-   - IRP overview
-   - Roles and responsibilities
-   - Communication protocols
-   - Tools and access
-
-2. **Security Fundamentals** (Annual)
-   - Common vulnerability types
-   - Secure coding practices
-   - Threat modeling basics
-   - Security testing
-
-3. **Tabletop Exercises** (Bi-annual)
-   - Simulated incident scenarios
-   - Practice response procedures
-   - Test communication channels
-   - Identify gaps in plan
-
-4. **Platform-Specific Training** (As needed)
-   - GitHub Security features
-   - Flutter security best practices
-   - Dependency management
-
-**Training Schedule**:
-- Onboarding: New IR team members
-- Annual: All IR team members
-- Quarterly: Security updates and lessons learned
-- Post-incident: Specific learnings from incidents
-
-### 10.2 Tabletop Exercise Scenarios
+### 10.1 Tabletop Exercise Scenarios
 
 **Scenario 1: Critical RCE Vulnerability**
+
 ```
 SCENARIO: Security researcher reports remote code execution vulnerability
           in template engine. Exploit code is public.
@@ -1446,6 +1260,7 @@ EXERCISE:
 ```
 
 **Scenario 2: Compromised Dependency**
+
 ```
 SCENARIO: A popular dependency has been compromised with malicious code.
           API Dash uses this dependency.
@@ -1459,6 +1274,7 @@ EXERCISE:
 ```
 
 **Scenario 3: Data Breach**
+
 ```
 SCENARIO: User reports their API credentials were leaked after using API Dash.
           Potentially multiple users affected.
@@ -1472,6 +1288,7 @@ EXERCISE:
 ```
 
 **Scenario 4: GitHub Account Compromise**
+
 ```
 SCENARIO: A maintainer's GitHub account is compromised.
           Unauthorized commits are pushed to main branch.
@@ -1484,31 +1301,36 @@ EXERCISE:
 - How do we verify code integrity?
 ```
 
-### 10.3 User Education
+### 10.2 User Education
 
 **Security Best Practices Guide** (for users):
-```markdown
+
+```
 # API Dash Security Best Practices
 
 ## Protecting Your Credentials
+
 - Use environment variables for sensitive values
 - Don't commit credentials to version control
 - Regularly rotate API keys and tokens
 - Use read-only tokens when possible
 
 ## Safe Collection Sharing
+
 - Redact credentials before exporting
 - Use encrypted exports for sensitive data
 - Review collections before importing
 - Trust collection sources
 
 ## Keeping Secure
+
 - Always use latest version
 - Enable automatic updates
 - Watch for security advisories
 - Report security issues responsibly
 
 ## Local Data Security
+
 - Use full-disk encryption
 - Secure your workspace folder
 - Clear history containing sensitive data
@@ -1516,17 +1338,20 @@ EXERCISE:
 ```
 
 **Responsible Disclosure Guide** (for researchers):
-```markdown
+
+```
 # Reporting Security Vulnerabilities
 
 Thank you for helping keep API Dash secure!
 
 ## How to Report
+
 1. **Do NOT** create public GitHub issues
 2. Use GitHub Security Advisories (preferred)
-3. Or email: security@apidash.dev
+3. Or email: ankit[at] apidash.dev
 
 ## What to Include
+
 - Description of vulnerability
 - Steps to reproduce
 - Affected versions
@@ -1534,229 +1359,35 @@ Thank you for helping keep API Dash secure!
 - Suggested fix (optional)
 
 ## What to Expect
-- Acknowledgment within 24 hours
-- Initial assessment within 72 hours
+
+- Acknowledgment
+- Initial assessment
 - Regular updates on progress
 - Coordinated disclosure timeline
 - Credit in advisory (if desired)
 
 ## Disclosure Policy
+
 - We follow 90-day disclosure deadline
 - Earlier disclosure if fix is ready
 - We'll coordinate with you
 
 ## Safe Harbor
+
 We will not pursue legal action against researchers who:
+
 - Act in good faith
 - Don't access user data
 - Don't disrupt service
 - Report responsibly
 ```
 
----
+## 11. Appendix
 
-## 11. Legal and Compliance
-
-### 11.1 Regulatory Requirements
-
-#### Data Protection Laws
-
-**GDPR (EU)**:
-- **Breach Notification**: 72 hours to supervisory authority
-- **User Notification**: Without undue delay if high risk
-- **Documentation**: Detailed records of breach
-- **Applicability**: If processing EU residents' data
-
-**CCPA (California)**:
-- **Breach Notification**: Without unreasonable delay
-- **Content**: Specific information requirements
-- **Method**: Written notice to affected individuals
-- **Applicability**: If processing California residents' data
-
-**Other Jurisdictions**:
-- Check applicable data breach notification laws
-- Consult legal counsel for specific requirements
-- Maintain list of applicable regulations
-
-#### Open Source Considerations
-
-**Transparency**:
-- Open source projects have unique transparency expectations
-- Balance between security and openness
-- Public incident disclosure aligns with open source values
-
-**Liability**:
-- Review project license (API Dash likely uses MIT)
-- Understand warranty disclaimers
-- Consider liability limitations
-- Document security efforts
-
-### 11.2 Legal Contacts
-
-**When to Involve Legal Counsel**:
-- Data breaches affecting personal information
-- Potential regulatory violations
-- Threats of legal action
-- Complex liability questions
-- Law enforcement involvement
-
-**Legal Resources**:
-- Open source legal organizations (Software Freedom Conservancy, etc.)
-- Pro bono legal services for open source
-- GitHub's legal resources
-- Local bar associations
-
-### 11.3 Law Enforcement
-
-**When to Contact Law Enforcement**:
-- Criminal activity (hacking, extortion, etc.)
-- Significant data breach
-- Identity theft concerns
-- Ongoing attacks
-
-**What to Provide**:
-- Incident summary
-- Timeline of events
-- Evidence preservation
-- Technical details
-- Impact assessment
-
-**Coordination**:
-- Designate single point of contact
-- Preserve evidence chain of custody
-- Get case number for reference
-- Balance investigation with incident response
-
-### 11.4 Insurance
-
-**Cyber Insurance Considerations**:
-- Most applicable for commercial entities
-- Open source projects typically lack coverage
-- Document security practices for potential future coverage
-- Understand requirements if organization obtains coverage
-
----
-
-## 12. Plan Maintenance
-
-### 12.1 Review Schedule
-
-**Regular Reviews**:
-- **Annual**: Comprehensive plan review and update
-- **Quarterly**: Metrics review and process improvements
-- **Post-Incident**: Review and update based on learnings
-- **After Major Changes**: Review when project structure changes
-
-**Review Checklist**:
-```
-[ ] Update contact information
-[ ] Review and update procedures
-[ ] Validate tool access
-[ ] Check compliance requirements
-[ ] Update templates
-[ ] Review metrics and KPIs
-[ ] Incorporate lessons learned
-[ ] Test communication channels
-[ ] Verify escalation paths
-[ ] Update training materials
-```
-
-### 12.2 Change Management
-
-**Plan Updates**:
-- Version control this document
-- Track changes in git history
-- Communicate significant changes to team
-- Train team on major procedural updates
-
-**Approval Process**:
-- Minor updates: Security Lead approval
-- Major updates: Incident Commander + team consensus
-- Emergency updates: Incident Commander approval, team notification
-
-**Change Log**:
-```markdown
-| Version | Date | Changes | Approved By |
-|---------|------|---------|-------------|
-| 1.0 | 2025-12-04 | Initial IRP | IC |
-| ... | ... | ... | ... |
-```
-
-### 12.3 Testing and Validation
-
-**Plan Testing**:
-- **Annual Tabletop Exercise**: Full scenario walkthrough
-- **Quarterly Mini-Exercise**: Specific procedure testing
-- **Post-Update Testing**: Validate changes work as intended
-
-**Validation Criteria**:
-- All contacts are current
-- All tools are accessible
-- Procedures are clear and actionable
-- Templates are complete
-- Team understands roles
-
-### 12.4 Continuous Improvement
-
-**Improvement Sources**:
-1. Post-incident reviews
-2. Tabletop exercises
-3. Industry best practices
-4. Regulatory changes
-5. Tool updates
-6. Team feedback
-
-**Metrics for Success**:
-- Reduced time to detect
-- Reduced time to respond
-- Reduced time to resolve
-- Increased patch adoption
-- Improved team confidence
-- Positive community feedback
-
----
-
-## 13. Appendices
-
-### Appendix A: Quick Reference Card
-
-```
-╔══════════════════════════════════════════════════════════╗
-║        API DASH INCIDENT RESPONSE QUICK GUIDE           ║
-╠══════════════════════════════════════════════════════════╣
-║ CRITICAL INCIDENT?                                       ║
-║   → Contact Incident Commander IMMEDIATELY               ║
-║   → Create private GitHub Security Advisory              ║
-║   → Do NOT discuss publicly                              ║
-║                                                          ║
-║ RESPONSE TIMES:                                          ║
-║   Critical:  4 hours                                     ║
-║   High:      24 hours                                    ║
-║   Medium:    72 hours                                    ║
-║   Low:       1 week                                      ║
-║                                                          ║
-║ SEVERITY GUIDE:                                          ║
-║   🔴 Critical: RCE, Supply chain, Mass credential leak   ║
-║   🟠 High:     Auth bypass, Privilege escalation         ║
-║   🟡 Medium:   Info disclosure, CSRF, DoS                ║
-║   🟢 Low:      Minor info leak, Security misconfig       ║
-║                                                          ║
-║ CONTACTS:                                                ║
-║   Security: security@apidash.dev                         ║
-║   GitHub:   Security Advisories (preferred)              ║
-║   Discord:  #security channel                            ║
-║                                                          ║
-║ REMEMBER:                                                ║
-║   ✓ Preserve evidence                                    ║
-║   ✓ Document everything                                  ║
-║   ✓ Communicate regularly                                ║
-║   ✓ Learn and improve                                    ║
-╚══════════════════════════════════════════════════════════╝
-```
-
-### Appendix B: Incident Response Checklist
+### Incident Response Checklist
 
 **Phase 1: Detection**
+
 ```
 [ ] Incident detected/reported
 [ ] Initial assessment completed
@@ -1767,6 +1398,7 @@ We will not pursue legal action against researchers who:
 ```
 
 **Phase 2: Analysis**
+
 ```
 [ ] Vulnerability validated
 [ ] Affected versions identified
@@ -1778,6 +1410,7 @@ We will not pursue legal action against researchers who:
 ```
 
 **Phase 3: Containment**
+
 ```
 [ ] Immediate threats neutralized
 [ ] Access revoked (if compromise)
@@ -1788,6 +1421,7 @@ We will not pursue legal action against researchers who:
 ```
 
 **Phase 4: Eradication**
+
 ```
 [ ] Security fix developed
 [ ] Fix tested thoroughly
@@ -1798,6 +1432,7 @@ We will not pursue legal action against researchers who:
 ```
 
 **Phase 5: Recovery**
+
 ```
 [ ] Patch released
 [ ] Security advisory published
@@ -1808,6 +1443,7 @@ We will not pursue legal action against researchers who:
 ```
 
 **Phase 6: Post-Incident**
+
 ```
 [ ] PIR scheduled
 [ ] Incident documented
@@ -1818,15 +1454,12 @@ We will not pursue legal action against researchers who:
 [ ] Metrics recorded
 ```
 
-### Appendix C: Communication Templates
-
-**See Section 6 for detailed templates**
-
-### Appendix D: CVSS Scoring Guide
+### CVSS Scoring Guide
 
 **CVSS v3.1 Quick Reference**:
 
 **Base Metrics**:
+
 - Attack Vector (AV): Network/Adjacent/Local/Physical
 - Attack Complexity (AC): Low/High
 - Privileges Required (PR): None/Low/High
@@ -1839,6 +1472,7 @@ We will not pursue legal action against researchers who:
 **Calculator**: https://www.first.org/cvss/calculator/3.1
 
 **Example Scoring**:
+
 ```
 Remote Code Execution:
 AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
@@ -1849,139 +1483,15 @@ AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N
 Score: 5.4 (MEDIUM)
 ```
 
-### Appendix E: Useful Commands
+### Useful Commands
 
-**Git Forensics**:
 ```bash
-# View commit history for file
-git log --follow --all -- path/to/file
-
-# See who changed specific lines
-git blame path/to/file
-
-# Find when vulnerability was introduced
-git bisect start
-git bisect bad  # Current broken state
-git bisect good v1.0.0  # Known good version
-
-# Check if specific code exists in all branches
-git grep "suspicious_function" $(git rev-list --all)
-
-# Revert specific commits
-git revert <commit-hash>
-```
-
-**Security Scanning**:
-```bash
-# Check for dependency vulnerabilities
-dart pub outdated --mode security
+# Check for outdated dependency vulnerabilities
+dart pub outdated
 
 # Run static analysis
 flutter analyze
 
-# Check for secrets in code (using gitleaks)
-gitleaks detect --source .
-
-# Audit npm packages (if using web)
-npm audit
-
-# Check license compliance
+# Check dependencies
 flutter pub deps --style=compact
 ```
-
-**Incident Response**:
-```bash
-# Create branch for security fix
-git checkout -b security/fix-cve-2025-xxxx
-
-# Create signed commit
-git commit -S -m "security: fix vulnerability"
-
-# Create signed tag for release
-git tag -s v1.2.3 -m "Security release v1.2.3"
-
-# Verify signature
-git verify-tag v1.2.3
-```
-
-### Appendix F: Acronyms and Definitions
-
-**Acronyms**:
-- **IRP**: Incident Response Plan
-- **IR**: Incident Response
-- **IC**: Incident Commander
-- **PIR**: Post-Incident Review
-- **GHSA**: GitHub Security Advisory
-- **CVE**: Common Vulnerabilities and Exposures
-- **CVSS**: Common Vulnerability Scoring System
-- **RCE**: Remote Code Execution
-- **XSS**: Cross-Site Scripting
-- **CSRF**: Cross-Site Request Forgery
-- **DoS**: Denial of Service
-- **SAST**: Static Application Security Testing
-- **DAST**: Dynamic Application Security Testing
-- **SBOM**: Software Bill of Materials
-
-**Definitions**:
-- **Security Incident**: Any event that poses a threat to confidentiality, integrity, or availability
-- **Vulnerability**: A weakness that can be exploited
-- **Exploit**: Code or technique that takes advantage of a vulnerability
-- **Patch**: Update that fixes a security issue
-- **Advisory**: Public notification of security issue and fix
-- **Disclosure**: Process of revealing vulnerability details
-- **Coordinated Disclosure**: Vulnerability disclosure coordinated with vendor
-
-### Appendix G: External Resources
-
-**Security Organizations**:
-- **OWASP**: https://owasp.org/
-- **CERT/CC**: https://www.kb.cert.org/vuls/
-- **Open Source Security Foundation**: https://openssf.org/
-- **GitHub Security Lab**: https://securitylab.github.com/
-
-**Reporting Platforms**:
-- **HackerOne**: https://hackerone.com/
-- **Bugcrowd**: https://bugcrowd.com/
-- **GitHub Security Advisories**: Built into GitHub
-
-**Learning Resources**:
-- **NIST Cybersecurity Framework**: https://www.nist.gov/cyberframework
-- **SANS Incident Response**: https://www.sans.org/incident-response/
-- **Google Project Zero**: https://googleprojectzero.blogspot.com/
-
----
-
-## Document Control
-
-| Version | Date | Author | Changes | Approved By |
-|---------|------|--------|---------|-------------|
-| 1.0 | December 2025 | Security Team | Initial IRP based on 2025 guidelines | Incident Commander |
-
-**Next Review Date**: December 2026  
-**Document Owner**: API Dash Security Team  
-**Classification**: Public  
-**Distribution**: All maintainers, published in repository
-
----
-
-## Acknowledgments
-
-This Incident Response Plan is based on industry best practices and frameworks including:
-- NIST Computer Security Incident Handling Guide (SP 800-61 Rev. 2)
-- SANS Incident Handler's Handbook
-- ISO/IEC 27035 Incident Management
-- CERT Coordination Center practices
-- OWASP Incident Response guidelines
-- GitHub Security best practices
-- Open Source Security Foundation recommendations
-
-Special thanks to the security community for their guidance and the API Dash contributors for their commitment to security.
-
----
-
-**For security incidents or questions about this plan:**  
-📧 security@apidash.dev  
-🔒 GitHub Security Advisories: https://github.com/foss42/apidash/security/advisories  
-💬 Discord: #security channel
-
-**END OF INCIDENT RESPONSE PLAN**