European Parliament MCP Server API - v1.2.21
    Preparing search index...

    Hack23 Logo

    🎯 European Parliament MCP Server — Threat Model

    🛡️ Proactive Security Through Structured Threat Analysis
    🔍 STRIDE • MITRE ATT&CK • MCP Protocol Security • Parliamentary Data Protection

    Owner Version Effective Date Review Cycle

    📋 Document Owner: CEO | 📄 Version: 1.3 | 📅 Last Updated: 2026-04-28 (UTC)
    🔄 Review Cycle: Quarterly | ⏰ Next Review: 2026-07-28
    🏷️ Classification: Public (Open Source MCP Server)

    Policy Relevance Link
    Open Source Policy Security transparency, vulnerability disclosure View
    Secure Development Policy Secure coding practices, supply chain security View
    Risk Management Policy Threat assessment, risk mitigation View
    Privacy Policy GDPR compliance, data protection View
    Control Area Status Evidence
    Input Validation (Zod) ✅ Implemented Mitigates E-1, D-4, E-3
    Rate Limiting ✅ Implemented Mitigates D-1, D-2
    HTTPS/TLS ✅ Implemented Default EP API base URL uses HTTPS; EP_API_URL must be configured with https:// (Mitigates S-2, T-1)
    SLSA Level 3 ✅ Implemented Mitigates T-3, S-4
    Dependabot + npm audit ✅ Implemented Mitigates T-2
    Error Sanitization ⚠️ Partial Mitigates I-1, I-2
    Framework Controls Status
    ISO 27001:2022 A.5.1, A.8.2, A.8.8, A.8.25, A.14.2, A.18.1 ✅ Aligned
    NIST CSF 2.0 ID.AM, ID.RA, PR.DS, PR.IP, DE.CM, RS.AN ✅ Aligned
    CIS Controls v8.1 1.1, 2.7, 3.3, 6.2, 7.1, 16.7 ✅ Aligned

    See also: Policy Alignment below for the complete threat-specific ISMS policy mapping (Threat Modeling, Vulnerability Management, Network Security, Access Control, Cryptography, and Incident Response policies).

    Document Type Description Status
    SECURITY_ARCHITECTURE.md 🛡️ Current Implemented security design and controls ✅ Current
    FUTURE_SECURITY_ARCHITECTURE.md 🚀 Future Security roadmap and planned enhancements ✅ Current
    THREAT_MODEL.md 🎯 Analysis STRIDE threat analysis and risk assessment ✅ Current
    FUTURE_THREAT_MODEL.md 🔮 Future Threat analysis for planned architecture evolution ✅ Current
    BCPPlan.md 🔄 Continuity Business continuity and disaster recovery ✅ Current
    CRA-ASSESSMENT.md 📋 Compliance EU Cyber Resilience Act conformity assessment ✅ Current
    SECURITY.md 📜 Policy Security policy and vulnerability disclosure ✅ Current
    SECURITY_HEADERS.md 🔒 Technical API security headers implementation ✅ Current

    Establish a comprehensive threat model for the European Parliament MCP Server, a TypeScript/Node.js Model Context Protocol server providing AI assistants with structured access to European Parliament open datasets. This systematic threat analysis integrates multiple frameworks to ensure proactive security through structured analysis.

    This threat model demonstrates 🛡️ cybersecurity consulting expertise through public documentation of advanced threat assessment methodologies, showcasing our 🏆 competitive advantage via systematic risk management and 🤝 customer trust through transparent security practices.

    — Based on Hack23 AB's commitment to security through transparency and excellence

    • 🎭 STRIDE per architecture element: Systematic threat categorization
    • 🎖️ MITRE ATT&CK mapping: Advanced threat intelligence integration
    • 🏗️ Asset-centric analysis: Critical resource protection focus
    • 🎯 Scenario-centric modeling: Real-world attack simulation
    • ⚖️ Risk-centric assessment: Business impact quantification

    Included Systems:

    • 🌐 TypeScript/Node.js MCP server application
    • 🔌 MCP protocol implementation (stdio transport)
    • 🏛️ European Parliament Open Data API integration
    • 📦 npm package distribution (european-parliament-mcp-server)
    • 🏭 CI/CD security pipeline (GitHub Actions, SLSA Level 3)
    • 📦 Dependency supply chain (npm ecosystem)
    • ✅ Input validation (Zod schemas)

    Out of Scope:

    • European Parliament API infrastructure security
    • End-user AI assistant security (Claude, ChatGPT, etc.)
    • Third-party npm registry infrastructure
    • End-user operating system and network security

    Integrated with 🎯 Hack23 AB Threat Modeling Policy methodology and frameworks.

    This threat model implements the five integrated threat modeling strategies mandated by Hack23 AB Threat Modeling Policy §4. Each strategy provides complementary perspectives to ensure comprehensive threat coverage for the European Parliament MCP Server.

    mindmap
  root((🎯 EP MCP Server
    Threat Modeling
    Strategies))
    (🎖️ Attacker-Centric)
      MITRE ATT&CK Mapping
      Kill Chain Analysis
      Threat Agent Classification
      Attack Tree Analysis
    (🏗️ Asset-Centric)
      Crown Jewel Analysis
      Critical Asset Inventory
      Data Flow Threat Analysis
      GDPR Data Classification
    (🏛️ Architecture-Centric)
      STRIDE per Component
      Trust Boundary Analysis
      Data Flow Diagrams
      Defense-in-Depth Layers
    (🎯 Scenario-Centric)
      Parliamentary Data Manipulation
      MEP Personal Data Abuse
      Electoral Disinformation
      Supply Chain Compromise
      MCP Protocol Injection
    (⚖️ Risk-Centric)
      Quantitative Risk Matrix
      Business Impact Analysis
      Likelihood Assessment
      Residual Risk Tracking
    Strategy EP MCP Server Implementation Key Sections
    🎖️ Attacker-Centric MITRE ATT&CK mapping (13 techniques), Kill Chain disruption, 5 threat agent profiles ATT&CK Mapping, Kill Chain, Threat Agents
    🏗️ Asset-Centric 6 critical assets, Crown Jewel analysis, protection strategies Crown Jewels
    🏛️ Architecture-Centric STRIDE per 6 components (36 threat cells), trust boundary sequence diagram Architecture STRIDE
    🎯 Scenario-Centric 5 EP-specific attack scenarios with attack chains, detection, and response Scenarios
    ⚖️ Risk-Centric Quantitative risk matrix, priority risk ranking, residual risk assessment Risk Assessment
    Dimension Level Rationale Business Impact
    🔐 Confidentiality Public Open source server processing public EP data Trust Enhancement
    🔒 Integrity Moderate Parliamentary data accuracy critical for democratic transparency Operational Excellence
    ⚡ Availability Standard MCP server tolerates brief outages; AI clients retry Revenue Protection
    Property Value
    Runtime Node.js 25+ (Current)
    Language TypeScript 6.0.2 (strict mode)
    Transport stdio (local process)
    Data Source European Parliament Open Data API
    Distribution npm registry
    Authentication None (public data, local stdio)
    Users AI assistants (Claude, ChatGPT, etc.)
    Asset Description Classification Threat Impact
    EP Parliamentary Data Integrity Accuracy and trustworthiness of MEP data, voting records, plenary documents 🔒 Integrity: Moderate Compromised democratic transparency, misinformation propagation
    Source Code & Build Pipeline TypeScript source, CI/CD workflows, GitHub Actions security 🔐 Confidentiality: Public
    🔒 Integrity: High    		 Supply chain compromise, malicious code injection
    Service Reputation & Trust OpenSSF Scorecard rating, npm package legitimacy, security posture ⚡ Availability: Standard User trust erosion, adoption reduction
    EP API Access & Availability Connection to European Parliament Open Data API ⚡ Availability: Moderate Service disruption, rate limit exhaustion
    npm Package Distribution Package integrity, version control, download statistics 🔒 Integrity: Moderate Malware distribution, user impact
    Audit Trail & Logging Structured logs, security event records 🔒 Integrity: Moderate Non-repudiation loss, incident investigation failure 
    mindmap
  root((🏛️ EP MCP
    Crown Jewels))
    🔒 EP Parliamentary
    Data Integrity
      Voting Records
      MEP Profiles
      Plenary Documents
      Committee Assignments
      GDPR Personal Data
    📦 Source Code &
    Build Pipeline
      TypeScript Source
      GitHub Actions
      SLSA L3 Provenance
      npm Publishing
      Dependency Chain
    🛡️ Service
    Reputation & Trust
      OpenSSF Score 9.4+
      Security Badges
      npm Download Stats
      Community Trust
      Transparent Security
    🌐 EP API Access &
    Availability
      Rate Limit Quota
      API Response Time
      Connection Integrity
      HTTPS/TLS Security
      Failover Strategy
    Crown Jewel Primary Threats Protection Controls Residual Risk
    EP Parliamentary Data Integrity T-1, T-2, S-2 HTTPS/TLS, response validation, Zod schemas, cache TTL Low
    Source Code & Build Pipeline T-2, T-3, S-4 SLSA Level 3, branch protection, GPG signing, Dependabot Low-Medium
    Service Reputation & Trust All categories OpenSSF Scorecard monitoring, security badges, transparent documentation Low
    EP API Access & Availability D-1, D-2, S-2 Rate limiting, retry logic, circuit breaker, HTTPS verification Medium
    npm Package Distribution S-3, S-4, T-2 Official package name ownership, npm 2FA, SBOM, npm provenance Low-Medium
    Audit Trail & Logging R-1, R-2, R-3 Structured stderr logging, immutable logs, timestamp integrity Low
    ID Threat Component Likelihood Impact Risk Mitigation
    S-1 Malicious MCP client impersonation MCP Transport Low Medium Low stdio transport limits to local process
    S-2 EP API response spoofing (MITM) API Client Low High Medium HTTPS/TLS for all API communication
    S-3 npm package name squatting Distribution Low High Medium Official package name, npm 2FA publishing
    S-4 Supply chain package substitution Dependencies Medium High High SLSA Level 3 provenance, lockfile pinning
    ID Threat Component Likelihood Impact Risk Mitigation
    T-1 API response manipulation API Client Low High Medium HTTPS integrity, response validation
    T-2 Dependency injection via compromised package Supply Chain Medium Critical High Dependabot, npm audit, SBOM tracking
    T-3 Build artifact tampering CI/CD Low Critical Medium SLSA Level 3 attestations
    T-4 Configuration manipulation Runtime Low Medium Low Environment variable validation
    ID Threat Component Likelihood Impact Risk Mitigation
    R-1 Untracked tool invocations MCP Server Medium Medium Medium Structured audit logging (stderr)
    R-2 Unsigned commits in source Source Code Low Medium Low GPG signing, branch protection
    R-3 Unattributed data access API Client Low Low Low Request logging with timestamps
    ID Threat Component Likelihood Impact Risk Mitigation
    I-1 Verbose error messages exposing internals Error Handling Medium Medium Medium Sanitized error responses
    I-2 Stack traces in production Runtime Medium Low Low Production error handling
    I-3 API keys in logs Logging Low High Medium No API keys required (public API)
    I-4 Sensitive data in cached responses Caching Low Low Low Public data only, TTL-based cache
    ID Threat Component Likelihood Impact Risk Mitigation
    D-1 EP API rate limit exhaustion API Client Medium Medium Medium Client-side rate limiting
    D-2 Memory exhaustion via large responses Runtime Low High Medium Response size limits
    D-3 Recursive/nested tool calls MCP Server Low Medium Low Call depth limits
    D-4 ReDoS via crafted input Input Validation Low Medium Low Zod schema validation (no regex)
    ID Threat Component Likelihood Impact Risk Mitigation
    E-1 MCP tool parameter injection Input Handling Medium Medium Medium Zod schema validation for all inputs
    E-2 Prototype pollution via JSON parsing Runtime Low High Medium Safe JSON parsing, TypeScript strict
    E-3 Path traversal in document search Tools Low Medium Low Input sanitization, no filesystem access
    E-4 Command injection via tool parameters MCP Server Low Critical Medium No shell execution, parameterized APIs

    This section maps the OWASP LLM Top 10 (2025) to the European Parliament MCP Server architecture, identifying applicable threats and gaps beyond traditional STRIDE analysis. Per the Hack23 OWASP LLM Security Policy, all MCP servers must assess LLM-specific attack vectors.

    LLM-ID OWASP LLM Top 10 (2025) Applicability to EP MCP Threat IDs Current Controls Residual Risk
    LLM01 Prompt Injection ⚠️ High Risk — Indirect prompt injection via EP API response payloads (e.g., malicious text in procedure titles, speech transcripts, committee reports that the host LLM treats as instructions: "Ignore previous instructions and...") L-1 (new) ✅ Tool result schema documentation
    ℹ️ Zod validates structure only, NOT semantic content — injection payloads in valid string fields pass through unmodified
    ⚠️ Host-LLM responsibility (sanitize/sandbox tool-result text before treating as instructions)
    ⚠️ No server-side content sanitization (intentional: out-of-scope per MCP spec)    		 Medium
    (Host-LLM boundary defense required)
    LLM02 Sensitive Information Disclosure ⚠️ Medium Risk — System-prompt or tool-schema leakage through verbose error messages, stack traces in production logs I-1, I-2 (existing) ✅ Sanitized error responses
    ⚠️ Partial production log review
    ✅ No secrets in tool descriptions    		 Low
    (Partial mitigation via I-1/I-2)
    LLM03 Supply Chain ⚠️ High Risk — Compromised npm dependencies containing LLM-targeted backdoors (e.g., AI-generated obfuscated malware) T-2, S-4 (existing) ✅ Dependabot + SLSA Level 3
    ✅ SBOM tracking
    ✅ npm audit + Snyk    		 Medium
    (Covered by existing T-2/S-4 controls)
    LLM04 Data and Model Poisoning ❌ Not Applicable — EP MCP Server does not train or fine-tune models; consumes pre-trained host LLMs only N/A N/A N/A
    LLM05 Improper Output Handling ⚠️ Medium Risk — Host LLM rendering EP-sourced HTML/Markdown from tool results as instructions (e.g., malicious <script> in MEP bio, XSS in speech transcript) L-2 (new) ⚠️ No server-side sanitization
    ✅ Public EP data only
    ⚠️ Host-LLM sanitization required    		 Low-Medium
    (Trust boundary at LLM client)
    LLM06 Excessive Agency ⚠️ High Risk — Host LLM autonomously invoking high-volume tool chains (e.g., enumerating all 705 MEPs via get_mep_details in a loop) causing EP API quota exhaustion L-3 (new) ✅ Token bucket rate limiter (100/min)
    ⚠️ No per-session limits
    ⚠️ No autonomous-agent detection    		 Medium
    (Rate limiting mitigates but not agent-aware)
    LLM07 System Prompt Leakage ✅ Not Applicable — EP MCP Server has no system prompt; tool descriptions are public by design (open-source, MCP schema published) N/A N/A (intentional transparency) N/A
    (Tool schemas are public API surface)
    LLM08 Vector and Embedding Weaknesses ❌ Not Applicable — EP MCP Server does not implement vector databases, embeddings, or RAG pipelines N/A N/A N/A
    LLM09 Misinformation ⚠️ High Risk — Host LLM hallucinating around real EP data + cache staleness amplifying outdated voting records as "current" (e.g., 15-min cache TTL + EP API delay = stale plenary results presented as real-time) L-4 (new) ✅ 15-min cache TTL
    ✅ EP API as source of truth
    ⚠️ No cache-age metadata in responses
    ⚠️ Host-LLM hallucination out of scope    		 Low-Medium
    (EP data accuracy trust boundary)
    LLM10 Unbounded Consumption ⚠️ Medium Risk — Host LLM token-cost amplification (e.g., AI client invoking get_all_generated_stats returning 20k+ tokens → expensive LLM processing) D-1, D-2 (existing) + L-5 (new, token-cost focus) ✅ Rate limiting (request-level)
    ⚠️ No response-size budgeting for LLM tokens
    ⚠️ No cost-estimation metadata    		 Low-Medium
    (Response-size limits mitigate but no token budgeting)
    ID Threat Component Likelihood Impact Risk Mitigation
    L-1 Indirect Prompt Injection via EP API Tool Results Medium High High Document trust boundary: tool results are untrusted data for host LLM; no server-side content filtering (out of scope); host-LLM sanitization required per OWASP LLM01
    L-2 Improper Output Handling (HTML/Markdown Injection) Tool Results Low Medium Low-Medium Public EP data only; XSS risk on host-LLM client (browser-based); server documents Markdown/HTML pass-through; host-client sanitization required
    L-3 Excessive Agency (Autonomous Agent Abuse) Rate Limiter Medium Medium Medium Token bucket (100/min) limits request rate; no per-session or per-agent quotas; future: adaptive rate limiting + agent fingerprinting
    L-4 Misinformation via Cache Staleness Cache Layer Low Medium Low-Medium 15-min TTL balances freshness vs. EP API load; no cache-age metadata in responses; future: add cacheAge field to tool results
    L-5 Unbounded Token-Cost Consumption API Client Low Medium Low-Medium Response-size limits (10MB) mitigate bandwidth DoS; no LLM token-cost budgeting; future: add token-count estimates to tool schemas
    OWASP LLM Risk Hack23 ISMS Policy Compliance Status
    LLM01 Prompt Injection OWASP LLM Security Policy §4.1 — Tool description hardening ✅ Documented trust boundary
    LLM02 Info Disclosure Information Security Policy §3.2 — Data classification ✅ Public data only (C: Public)
    LLM03 Supply Chain Secure Development Policy §5 — SLSA Level 3 ✅ Full compliance
    LLM05 Output Handling OWASP LLM Security Policy §4.3 — Safe output encoding ⚠️ Host-LLM responsibility
    LLM06 Excessive Agency Access Control Policy §4 — Rate limiting ✅ Token bucket enforced
    LLM09 Misinformation Data Classification Policy §3 — Integrity (Moderate) ✅ EP API as source of truth
    LLM10 Unbounded Consumption Secure Development Policy §6.2 — DoS prevention ✅ Response-size limits

    This section catalogs threats specific to the Model Context Protocol (MCP) based on 2025–2026 security research, beyond generic web/API vulnerabilities. Per Hack23 AI Policy §5 and OWASP LLM Security Policy, MCP servers must assess protocol-level attack vectors.

    ID Threat Component Likelihood Impact Risk Mitigation
    M-1 Tool Poisoning (Malicious Tool Descriptions) MCP Tool Schema ❌ N/A (first-party server) N/A (hypothetical: Critical) N/A Not applicable: EP MCP Server is first-party (not third-party/untrusted). Tool descriptions authored in-repo, code-reviewed, signed via SLSA Level 3 provenance. Host-LLM trust boundary documented. Hypothetical impact shown in italics to indicate exposure if the threat were applicable (e.g., if a third party forked and republished the package).
    M-2 Indirect Prompt Injection via Tool Results Tool Result Payloads Medium High Medium-High EP API returns text containing "ignore previous instructions…" patterns → host-LLM treats as commands. Mitigation: Zod validates structure (not content); host-LLM responsibility per OWASP LLM01; server documents trust boundary; no server-side text sanitization (out of scope).
    M-3 Rug-Pull Tool Re-Definition (npm Package Update) npm Distribution Low Critical Medium npm package update silently changes tool semantics (e.g., get_meps → exfiltration). Mitigation: SemVer contract enforcement, CHANGELOG.md mandatory, SLSA provenance attestations, npm 2FA publishing, signed Git tags (GPG), community review window.
    M-4 Confused-Deputy via MCP Gateway Multi-Server Gateway ❌ N/A (stdio, no gateway) N/A (hypothetical: High) N/A When used behind multi-server MCP gateway, requests from Client A conflated with Client B. Mitigation: Stateless server design (no per-client identity assumed), audit logger captures sessionId (future), stdio isolation (single-process). Future: add session-isolation guidance for gateway deployments.
    M-5 Cross-Tool Data Leakage (Cache Pollution) LRU Cache Low Medium Low Tool A's cached output influencing Tool B via shared cache namespace. Mitigation: Per-tool cache namespacing (cacheKey = toolName:params), LRU eviction policy, 15-min TTL prevents long-lived pollution, immutable cache entries.
    M-6 Resource URI Scheme Abuse (Path Traversal) MCP Resources Low Medium Low ep:// resource URIs used to traverse outside intended scope (e.g., ep://../../etc/passwd). Mitigation: Zod-validated URI patterns (ep://{entity}/{id}), no filesystem-backed resources (all HTTP-only), explicit resource schema constraints.
    M-7 Transport/Session ID Confusion stdio Transport ❌ N/A (single-process stdio) N/A (hypothetical: Medium) N/A stdio is single-process → inherently isolated. Future risk: HTTP/SSE transport (planned for v2.0) introduces session-management attack surface. Mitigation: Explicitly N/A for v1.x stdio; deferred to FUTURE_THREAT_MODEL.md for multi-session HTTP/SSE mode.
    Attack Vector Description EP MCP Server Exposure Current Mitigation Residual Risk
    Malicious Tool Schema Injection Attacker publishes MCP server with tool descriptions containing prompt-injection payloads ❌ Not Exposed — First-party server, not third-party marketplace N/A (first-party trust model) N/A
    Tool Result Content Injection Tool results contain adversarial text interpreted as instructions by host-LLM ✅ Exposed — EP API returns user-generated content (speech transcripts, procedure titles) ⚠️ Documented trust boundary; no server-side sanitization; host-LLM responsibility Medium
    Semantic Tool Redefinition Package update changes tool behavior without schema change (e.g., get_meps → spy logic) ✅ Exposed — npm distribution model allows silent updates ✅ SemVer, CHANGELOG, SLSA attestations, community review Low-Medium
    MCP Gateway Confused-Deputy Multi-server gateway routes request from Client A using identity/quota of Client B ❌ Not Exposed — stdio transport (no gateway) N/A (stdio isolation) N/A (future: document gateway security)
    Cache Namespace Collision Attacker crafts Tool A params to pollute Tool B's cache namespace ⚠️ Partially Exposed — Shared LRU cache across tools ✅ Per-tool namespacing, immutable entries, 15-min TTL Low
    Resource URI Directory Traversal ep://../../../sensitive path traversal in resource URIs ⚠️ Theoretically Exposed — 9 ep:// resources defined ✅ Zod URI validation, no filesystem access, HTTP-only resources Low
    Session Hijacking (HTTP/SSE) Attacker steals session token for HTTP-based MCP transport ❌ Not Exposed — stdio only (no network transport) N/A (stdio design) N/A (future: v2.0 HTTP mode)
    MCP Threat Hack23 ISMS Policy Compliance Status
    M-2 Indirect Prompt Injection OWASP LLM Security Policy §4.1 — Tool result trust boundary ✅ Documented trust model
    M-3 Rug-Pull Tool Redefinition Secure Development Policy §5.3 — Supply chain integrity ✅ SLSA Level 3, SemVer, CHANGELOG
    M-4 Confused-Deputy Access Control Policy §3 — Session isolation ✅ stdio isolation (N/A for v1.x)
    M-5 Cross-Tool Data Leakage Data Classification Policy §4 — Data segregation ✅ Per-tool cache namespacing
    M-6 Resource URI Abuse Secure Development Policy §6.1 — Input validation ✅ Zod URI validation

    This heat map shows the relevance and coverage of MITRE ATT&CK tactics for the European Parliament MCP Server context. Each tactic is assessed for applicability and current security posture.

    Tactic Coverage Status Relevant Techniques Priority Notes
    🎯 Initial Access 🟢 High Coverage T1190, T1195.002 🔴 Critical Supply chain & MCP protocol entry points
    ⚡ Execution 🟡 Medium Coverage T1059 🟠 High Limited - no direct shell execution
    🔄 Persistence 🟢 N/A (Not Applicable) — 🟢 Low Stateless MCP server, no persistence
    🔺 Privilege Escalation 🟡 Medium Coverage T1068 🟠 Medium Prototype pollution, injection risks
    🛡️ Defense Evasion 🟢 High Coverage T1027, T1562 🟠 High Obfuscated dependencies, log suppression
    🔑 Credential Access 🟢 N/A (Not Applicable) — 🟢 Low No credentials stored/managed
    🔍 Discovery 🟡 Medium Coverage T1592 🟡 Medium Information disclosure via errors
    ↔️ Lateral Movement 🟢 N/A (Not Applicable) — 🟢 Low Single-process stdio transport
    📦 Collection 🟢 High Coverage T1530 🟠 Medium Parliamentary data harvesting abuse
    📡 Command & Control 🟡 Medium Coverage T1071 🟡 Medium MCP protocol as C2 channel
    📤 Exfiltration 🟢 High Coverage T1041 🟠 High Parliamentary data exfiltration
    💥 Impact 🟢 High Coverage T1498, T1485 🔴 Critical DoS via rate exhaustion, data manipulation

    Coverage Legend:

    • 🟢 High Coverage: Comprehensive mitigations implemented
    • 🟡 Medium Coverage: Partial mitigations, monitoring in place
    • 🔴 Low Coverage: Minimal mitigations, requires attention
    • 🟢 N/A: Tactic not applicable to this architecture
    sequenceDiagram
    participant AI as 🤖 AI Assistant
    (Claude/ChatGPT)
    participant MCP as 🔌 MCP Server
    (stdio transport)
    participant Cache as 💾 Cache Layer
    (LRU in-memory)
    participant RL as ⏱️ Rate Limiter
    (Token bucket)
    participant API as 🏛️ EP API
    (HTTPS)
    participant Log as 📋 Audit Logger
    (stderr)

    Note over AI,MCP: 🎭 S-1: MCP client spoofing
    🛡️ Mitigation: stdio isolation
    AI->>MCP: Tool call request (JSON-RPC)
    Note over MCP: 🎭 E-1: Parameter injection
    🛡️ Mitigation: Zod validation
    
    MCP->>Log: Log request (structured)
    Note over Log: 🎭 R-1: Non-repudiation
    🛡️ Mitigation: Immutable stderr
    
    MCP->>Cache: Check cache
    alt Cache Hit
        Cache-->>MCP: Cached data
        Note over Cache: 🎭 I-4: Stale data exposure
    🛡️ Mitigation: TTL expiration
    else Cache Miss
        MCP->>RL: Check rate limit
        Note over RL: 🎭 D-1: Rate exhaustion
    🛡️ Mitigation: Token bucket
        alt Rate OK
            RL-->>MCP: Allow
            Note over MCP,API: 🎭 S-2: MITM attack
    🛡️ Mitigation: HTTPS/TLS 1.3
            MCP->>API: GET /meps (HTTPS)
            Note over API: 🎭 T-1: Response tampering
    🛡️ Mitigation: TLS integrity
            API-->>MCP: JSON response
            MCP->>MCP: Validate response (Zod)
            Note over MCP: 🎭 E-2: Prototype pollution
    🛡️ Mitigation: TypeScript strict
            MCP->>Cache: Store response
        else Rate Exceeded
            RL-->>MCP: Deny
            Note over MCP: 🎭 D-1: DoS protection
    ✅ Request rejected
        end
    end
    
    Note over MCP: 🎭 I-1: Error info leak
    🛡️ Mitigation: Sanitized errors
    MCP-->>AI: Tool response
    MCP->>Log: Log response (structured)
    STRIDE Threat Attack Vector Mitigation Status
    S Client impersonation through stdio hijacking Malicious process capturing stdio streams stdio transport limits to parent process ✅ Inherent
    T Tool invocation manipulation Modified JSON-RPC request parameters Zod schema validation on all inputs ✅ Active
    R Untracked tool calls Missing audit trail for debugging Structured stderr logging (JSON format) ✅ Active
    I Stack trace exposure in errors Production error messages revealing code structure Sanitized error responses to AI client ⚠️ Partial
    D Recursive tool calls causing OOM AI assistant invoking tools in infinite loop Call depth tracking, memory monitoring ⚠️ Future
    E JSON-RPC protocol exploitation Crafted JSON-RPC bypassing validation TypeScript strict mode, Zod schemas ✅ Active
    STRIDE Threat Attack Vector Mitigation Status
    S EP API response spoofing MITM attacker injecting false EP data HTTPS/TLS 1.3 with certificate validation ✅ Active
    T API response manipulation TLS downgrade or compromised proxy Strict TLS configuration, no HTTP fallback ✅ Active
    R Unlogged API requests Missing request/response audit trail Structured logging for all API interactions ✅ Active
    I API error details in client logs EP API returning sensitive error messages Sanitize EP API errors before logging ⚠️ Partial
    D API rate limit exhaustion Excessive requests overwhelming EP API Client-side rate limiting (token bucket) ✅ Active
    E Malicious redirect exploitation EP API sending redirect to attacker domain No automatic redirects, validate URLs ✅ Active
    STRIDE Threat Attack Vector Mitigation Status
    S Cache poisoning with fake data Attacker injecting malicious cache entries Cache only validated API responses ✅ Active
    T Cached data tampering Memory corruption or external modification Immutable cache entries, process isolation ✅ Inherent
    R Cache operations not logged Missing visibility into cache hits/misses Cache statistics in audit logs ⚠️ Future
    I Sensitive data in cache dumps Memory dumps exposing cached MEP data Public data only, no PII in cache keys ✅ Inherent
    D Memory exhaustion via cache growth Unbounded cache causing OOM LRU eviction policy, max size limit ✅ Active
    E Cache timing attacks Inferring data presence via response time Constant-time cache lookups (not security critical) ❌ Accepted
    STRIDE Threat Attack Vector Mitigation Status
    S Rate limit bypass Attacker spoofing source to reset limits Process-level rate limiting (stdio isolation) ✅ Inherent
    T Rate limit configuration tampering Modified rate limits allowing excess requests Immutable configuration, validated env vars ✅ Active
    R Rate limit violations unlogged Missing audit trail for throttling events Log all rate limit denials with timestamps ✅ Active
    I Rate limit details exposure Attacker learning rate limits via probing No rate limit details in error messages ✅ Active
    D Rate limiter resource exhaustion Token bucket state consuming excessive memory Fixed-size token bucket, constant memory ✅ Active
    E Race condition in rate checks Concurrent requests bypassing rate limits Atomic token bucket operations ✅ Active
    STRIDE Threat Attack Vector Mitigation Status
    S Log injection attacks Attacker injecting fake log entries via user input Structured JSON logging, no string interpolation ✅ Active
    T Log tampering Attacker modifying stderr logs post-facto Immutable stderr stream, external log aggregation ✅ Recommended
    R Log repudiation Attacker denying logged actions Timestamps (ISO 8601), request IDs, immutable stderr ✅ Active
    I Sensitive data in logs PII or credentials logged inadvertently Sanitize user input, no API keys (public API) ✅ Active
    D Log flooding DoS Excessive logging consuming disk/bandwidth Rate limit log output, log level filtering ⚠️ Future
    E Log analysis exploitation Attacker using logs to map system internals Generic log messages, no internal implementation details ⚠️ Partial
    STRIDE Threat Attack Vector Mitigation Status
    S npm package name squatting Attacker publishing european-parliament-server (typo) Official european-parliament-mcp-server package name ownership, npm 2FA-protected publisher account ✅ Active
    T Build artifact injection Malicious code in dist/ not matching source SLSA Level 3 provenance, reproducible builds ✅ Active
    R Unsigned package versions Unverifiable package authorship npm provenance attestations, 2FA publishing ✅ Active
    I Source code exposure (non-issue) Full source code visible in npm package Intentional: open source transparency ✅ Accepted
    D npm registry DoS npm registry unavailable during installation Use npm mirrors, cache dependencies locally ❌ External
    E Dependency confusion attack Internal package name colliding with public npm No private dependencies, unique public package names ✅ Inherent

    This section provides a component-by-component STRIDE refresh aligned with the C4 Component Diagram in ARCHITECTURE.md. Each row represents a concrete architectural component from the src/ codebase, cross-referenced to existing STRIDE threat IDs.

    Component Spoofing Tampering Repudiation Info Disc DoS EoP Linked IDs
    baseClient.ts Adequate (S-2: HTTPS/TLS) Adequate (T-1: TLS integrity) Adequate (R-3: logged) Adequate (I-3: no keys) Adequate (D-1: rate limited) Adequate (E-1: Zod) S-2, T-1, R-3, I-3, D-1, E-1
    mepClient.ts Adequate (S-2) Adequate (T-1) Adequate (R-3) Partial (I-1: MEP PII in errors) Adequate (D-1) Adequate (E-1) S-2, T-1, R-3, I-1, D-1, E-1
    plenaryClient.ts Adequate (S-2) Adequate (T-1) Adequate (R-3) Adequate (I-4: public data) Adequate (D-1, D-2: size limits) Adequate (E-1) S-2, T-1, R-3, I-4, D-1, D-2, E-1
    documentClient.ts Adequate (S-2) Adequate (T-1) Adequate (R-3) Adequate (I-4) Adequate (D-2: 10MB limit) Adequate (E-1, E-3: no path traversal) S-2, T-1, R-3, I-4, D-2, E-1, E-3
    legislativeClient.ts Adequate (S-2) Adequate (T-1) Adequate (R-3) Adequate (I-4) Adequate (D-1) Adequate (E-1) S-2, T-1, R-3, I-4, D-1, E-1
    committeeClient.ts Adequate (S-2) Adequate (T-1) Adequate (R-3) Adequate (I-4) Adequate (D-1) Adequate (E-1) S-2, T-1, R-3, I-4, D-1, E-1
    questionClient.ts Adequate (S-2) Adequate (T-1) Adequate (R-3) Adequate (I-4) Adequate (D-1) Adequate (E-1) S-2, T-1, R-3, I-4, D-1, E-1
    votingClient.ts Adequate (S-2) Adequate (T-1) Adequate (R-3) Adequate (I-4) Adequate (D-1) Adequate (E-1) S-2, T-1, R-3, I-4, D-1, E-1
    vocabularyClient.ts Adequate (S-2) Adequate (T-1) Adequate (R-3) Adequate (I-4) Adequate (D-1) Adequate (E-1) S-2, T-1, R-3, I-4, D-1, E-1
    Component Spoofing Tampering Repudiation Info Disc DoS EoP Linked IDs
    DI Container (src/di/) N/A (internal) Adequate (T-4: validated config) N/A Adequate (I-2: no secrets) N/A Adequate (E-2: TypeScript strict) T-4, I-2, E-2
    MetricResult Wrapper N/A N/A Adequate (R-1: logged) Adequate (I-1: sanitized) N/A N/A R-1, I-1
    Branded Types (Zod) N/A Adequate (T-1: validated) N/A N/A Adequate (D-4: no ReDoS) Adequate (E-1: strict schemas) T-1, D-4, E-1
    LruCache (src/cache/) N/A Adequate (immutable entries) Partial (R-1: cache ops not logged) Adequate (I-4: public data) Adequate (D-2: max size) N/A R-1, I-4, D-2
    RateLimiter (src/utils/rateLimiter.ts) Adequate (S-1: stdio isolation) Adequate (T-4: immutable config) Adequate (R-1: violations logged) Adequate (I-1: no details in errors) Adequate (D-1: token bucket) Adequate (E-1: atomic ops) S-1, T-4, R-1, I-1, D-1, E-1
    AuditSink (src/utils/auditLogger.ts) Adequate (S-1: stderr isolation) Adequate (immutable stderr) Adequate (R-1: ISO 8601 timestamps) Partial (I-1: PII sanitization) Partial (future: log flooding) Adequate (E-1: structured JSON) S-1, R-1, I-1, E-1
    STRIDE Category Components w/ Adequate Coverage Components w/ Partial Coverage Components w/ N/A
    Spoofing 11/15 (73%) 0 4 (internal-only)
    Tampering 13/15 (87%) 0 2
    Repudiation 11/15 (73%) 2 (cache ops, log flooding) 2
    Info Disclosure 13/15 (87%) 2 (MEP PII in errors, PII sanitization) 0
    DoS 12/15 (80%) 1 (log flooding) 2
    EoP 13/15 (87%) 0 2

    Key Gaps:

    • Repudiation (Partial): LRU cache operations (hits/misses) not logged → future MetricsService integration
    • Info Disclosure (Partial): MEP personal data in error messages (I-1) → enhanced error sanitization
    • DoS (Partial): No log-flooding protection → future rate limiting for audit events

    Comprehensive mapping of MITRE ATT&CK techniques to implemented security controls for the European Parliament MCP Server.

    Technique ID Technique Name Security Control Implementation Effectiveness
    T1195.002 Supply Chain Compromise: Software Supply Chain Dependabot + SLSA Level 3 + SBOM Automated vulnerability scanning, provenance attestations, CycloneDX SBOM generation 🟢 High (95%)
    T1059 Command and Scripting Interpreter No shell execution policy TypeScript/Node.js without child_process, strict input validation 🟢 High (98%)
    T1190 Exploit Public-Facing Application Zod schema validation + rate limiting Strict input validation for all MCP tool parameters, client-side rate limits 🟢 High (90%)
    T1557 Adversary-in-the-Middle HTTPS/TLS 1.3 for EP API Enforced TLS for all EP API requests, certificate validation 🟢 High (95%)
    T1498 Network Denial of Service Rate limiting + response size limits Client-side rate limiter, 10MB response cap, timeout controls 🟡 Medium (75%)
    T1027 Obfuscated Files or Information SLSA provenance + npm audit Build attestations, integrity verification, transparency logs 🟢 High (85%)
    T1071 Application Layer Protocol stdio transport isolation MCP protocol limited to stdio, no network exposure 🟢 High (90%)
    T1592 Gather Victim Host Information Error sanitization + structured logging Production error handlers, no stack traces to clients 🟡 Medium (70%)
    T1068 Exploitation for Privilege Escalation TypeScript strict mode + safe JSON parsing Prototype pollution prevention, type safety 🟢 High (85%)
    T1562 Impair Defenses Immutable logging + monitoring Audit logs via stderr, OpenSSF Scorecard monitoring 🟢 High (80%)
    T1530 Data from Cloud Storage Object Rate limiting + usage analytics Monitor bulk data requests, pattern-based anomaly detection 🟡 Medium (65%)
    T1041 Exfiltration Over C2 Channel stdio isolation + data flow monitoring No outbound network from MCP server, logging all tool invocations 🟢 High (80%)
    T1485 Data Destruction Integrity validation + EP API trust Response validation against expected schemas, EP API as source of truth 🟡 Medium (70%)

    Effectiveness Scale:

    • 🟢 High (>80%): Control effectively mitigates technique
    • 🟡 Medium (60-80%): Partial mitigation, residual risk remains
    • 🔴 Low (<60%): Limited mitigation, requires enhancement

    To visualize this threat landscape comprehensively, the European Parliament MCP Server team maintains an ATT&CK Navigator layer with:

    • Highlighted techniques: All 13 relevant techniques color-coded by coverage
    • Metadata annotations: Links to STRIDE threat IDs and security controls
    • Score-based heatmap: Effectiveness ratings (0-100) for each technique
    • Filter views: Supply Chain, MCP Protocol, API Layer, Runtime

    📊 ATT&CK Navigator Layer JSON: The layer JSON is a planned deliverable and will be added in a future release under a docs/threat-model/ directory once the visualization is finalized; it is not yet available in this repository.

    🔗 Online Visualization: Use MITRE ATT&CK Navigator to load the layer JSON for interactive exploration.

    Recommendation: Review this mapping quarterly and after major architecture changes to ensure continued alignment with evolving threat intelligence.

    This section maps the Cyber Kill Chain phases to the EP MCP Server's defensive controls and detection capabilities, as required by Hack23 AB Threat Modeling Policy §4.1. Each phase identifies how an attacker progresses and where our controls disrupt the chain.

    Kill Chain Phase Attack Activity (EP MCP Context) Defensive Controls Detection Mechanisms Disruption Effectiveness
    1️⃣ Reconnaissance Attacker probes MCP tool schemas, EP API endpoints, npm package metadata, GitHub repo structure • Public data only (no sensitive info to discover)
    • Generic error messages (I-1 mitigation)
    • No version info in runtime errors    		 • GitHub traffic analytics
    • npm download pattern monitoring
    • Unusual MCP tool enumeration logging    		 🟡 Medium — Public project limits reconnaissance value
    2️⃣ Weaponization Attacker crafts malicious npm package, prepares prototype pollution payload, or creates typosquatting package • SLSA Level 3 provenance verification
    • Package-lock.json integrity
    • No private dependencies    		 • Dependabot new vulnerability alerts
    • npm audit CI/CD gate
    • OpenSSF Scorecard monitoring    		 🟢 High — Supply chain controls are comprehensive
    3️⃣ Delivery Attacker publishes compromised dependency, sends phishing to maintainer, or submits malicious PR • npm 2FA required for publishing
    • Branch protection rules
    • CODEOWNERS enforcement
    • GPG commit signing    		 • GitHub security alerts
    • PR review requirements
    • npm provenance verification
    • Snyk continuous monitoring    		 🟢 High — Multi-layer delivery prevention
    4️⃣ Exploitation Attacker exploits Zod validation bypass, prototype pollution, or MCP parameter injection • Zod schema validation on all inputs (E-1)
    • TypeScript strict mode (E-2)
    • No shell execution (E-4)
    • Safe JSON parsing    		 • Zod validation error logging
    • TypeScript type check failures
    • Runtime exception monitoring
    • stderr audit logs    		 🟢 High — Defense-in-depth input validation
    5️⃣ Installation Attacker attempts persistence via modified cache entries, altered build artifacts, or backdoored dependency • Stateless MCP server (no persistence)
    • Immutable cache entries
    • SLSA build attestations
    • Process isolation (stdio)    		 • SLSA provenance signature mismatch
    • Build artifact hash verification
    • npm package content diff    		 🟢 High — Stateless architecture prevents installation
    6️⃣ Command & Control Attacker uses compromised MCP server to exfiltrate data or inject false responses to AI assistants • stdio transport isolation (no network)
    • No outbound connections from MCP server
    • Rate limiting on all tool calls    		 • Audit logging of all tool invocations
    • Response size anomaly detection
    • Data flow monitoring    		 🟢 High — stdio isolation prevents C2 channels
    7️⃣ Actions on Objectives Attacker manipulates parliamentary data, harvests MEP data, or disrupts service availability • EP API as source of truth (integrity)
    • Response validation via Zod
    • Rate limiting prevents bulk harvesting
    • GDPR-aware data minimization    		 • Data integrity checks against EP API
    • Bulk access pattern detection
    • Rate limit violation alerts
    • OpenSSF Scorecard degradation    		 🟡 Medium — Continuous monitoring required 
    graph LR
    R[1️⃣ Recon] -->|Public project| W[2️⃣ Weaponize]
    W -->|Supply chain| D[3️⃣ Deliver]
    D -->|Malicious code| E[4️⃣ Exploit]
    E -->|Code execution| I[5️⃣ Install]
    I -->|Persistence| C[6️⃣ C2]
    C -->|Control| A[7️⃣ Actions]

    R -.->|🛡️ Generic errors| RD[Disrupted]
    W -.->|🛡️ SLSA + Dependabot| WD[Disrupted]
    D -.->|🛡️ 2FA + Branch protection| DD[Disrupted]
    E -.->|🛡️ Zod + TypeScript strict| ED[Disrupted]
    I -.->|🛡️ Stateless architecture| ID[Disrupted]
    C -.->|🛡️ stdio isolation| CD[Disrupted]
    A -.->|🛡️ EP API integrity| AD[Monitored]

    style RD fill:#ffa726,stroke:#b2741a,stroke-width:2px,color:#1f1f1f


    style WD fill:#4CAF50,stroke:#357a38,stroke-width:2px,color:#ffffff


    style DD fill:#4CAF50,stroke:#357a38,stroke-width:2px,color:#ffffff


    style ED fill:#4CAF50,stroke:#357a38,stroke-width:2px,color:#ffffff


    style ID fill:#4CAF50,stroke:#357a38,stroke-width:2px,color:#ffffff


    style CD fill:#4CAF50,stroke:#357a38,stroke-width:2px,color:#ffffff


    style AD fill:#ffa726,stroke:#b2741a,stroke-width:2px,color:#1f1f1f

    Key Insight: The EP MCP Server's stateless stdio architecture provides inherent disruption at Kill Chain phases 5 (Installation) and 6 (C2), while SLSA Level 3 + Dependabot provide strong disruption at phases 2-3. The primary residual risk is at phase 7 (Actions on Objectives) where continuous monitoring is essential.

    Understanding potential adversaries is critical for proportionate security investment. This section profiles threat actors relevant to the European Parliament MCP Server based on motivation, capability, and likely attack vectors.

    Profile:

    • 🎯 Motivation: Intelligence gathering on European parliamentary activities, electoral interference, political influence operations
    • 💪 Capability Level: 🔴 Advanced (Nation-State Resources)
      • Sophisticated supply chain attacks (e.g., SolarWinds-style compromise)
      • Zero-day exploits in Node.js/TypeScript ecosystem
      • Advanced persistent threats (APT) with long-term objectives
    • 🎭 Likely Tactics:
      • T1195.002: Supply chain compromise of npm dependencies
      • T1557: MITM attacks on EP API communications
      • T1530: Systematic harvesting of MEP voting patterns and committee data
    • 🔴 Priority: High — Due to potential for sophisticated, persistent attacks
    • 🛡️ Mitigation Focus: SLSA Level 3 provenance, dependency integrity, EP API transport security

    Profile:

    • 🎯 Motivation: Political activism, transparency advocacy, anti-establishment campaigns, public disclosure of parliamentary data
    • 💪 Capability Level: 🟡 Intermediate (Skilled Individuals/Small Teams)
      • Script-based attacks, publicly available exploit tools
      • Social engineering of developers and contributors
      • Website defacement, data leaks for publicity
    • 🎭 Likely Tactics:
      • T1190: Exploit MCP tool parameter injection vulnerabilities
      • T1498: DDoS via API rate exhaustion
      • T1485: Data manipulation to spread disinformation
    • 🟠 Priority: Medium — Capable of opportunistic attacks but limited persistence
    • 🛡️ Mitigation Focus: Input validation (Zod schemas), rate limiting, public vulnerability disclosure program

    Profile:

    • 🎯 Motivation: Compromised developer account, malicious open-source contributor, disgruntled maintainer
    • 💪 Capability Level: 🟠 High (Trusted Access)
      • Direct commit access or pull request approval
      • Knowledge of codebase internals and security controls
      • Ability to introduce subtle vulnerabilities
    • 🎭 Likely Tactics:
      • T1195.002: Malicious dependency substitution or backdoor insertion
      • T1027: Obfuscated malicious code in commits
      • T1562: Disabling security controls (e.g., test bypasses)
    • 🔴 Priority: High — Trusted position enables high-impact attacks
    • 🛡️ Mitigation Focus: Branch protection, mandatory code review, GPG commit signing, SLSA attestations

    Profile:

    • 🎯 Motivation: Bulk data harvesting, API abuse for commercial purposes, training dataset collection for AI models
    • 💪 Capability Level: 🟢 Low (Automated Scripts)
      • Mass automated requests via compromised MCP clients
      • Simple evasion techniques (rotating IPs, user agents)
      • No sophisticated exploit capability
    • 🎭 Likely Tactics:
      • T1498: API rate limit exhaustion via distributed requests
      • T1530: Bulk collection of parliamentary datasets
      • T1071: Abuse of MCP protocol for unauthorized access
    • 🟡 Priority: Medium — High volume but low sophistication
    • 🛡️ Mitigation Focus: Client-side rate limiting, usage analytics, anomaly detection

    Profile:

    • 🎯 Motivation: Commercial intelligence gathering, competitive advantage in political consulting, lobbying intelligence
    • 💪 Capability Level: 🟡 Intermediate to High
      • Funded operations with technical capabilities
      • Targeted attacks on specific MEP data or committee information
      • Long-term systematic data collection
    • 🎭 Likely Tactics:
      • T1530: Systematic harvesting of EP voting records and attendance data
      • T1592: Reconnaissance via error message analysis
      • T1041: Exfiltration of aggregated parliamentary intelligence
    • 🟠 Priority: Medium — Targeted but not infrastructure-destructive
    • 🛡️ Mitigation Focus: Audit logging, data access pattern monitoring, request attribution
    %%{init: {
  "theme": "dark",
  "themeVariables": {
    "quadrant1Fill": "#D32F2F",
    "quadrant2Fill": "#FF9800",
    "quadrant3Fill": "#4CAF50",
    "quadrant4Fill": "#1565C0",
    "quadrantTitleFill": "#ffffff",
    "quadrantPointFill": "#ffffff",
    "quadrantPointTextFill": "#ffffff",
    "quadrantXAxisTextFill": "#ffffff",
    "quadrantYAxisTextFill": "#ffffff"
  },
  "quadrantChart": {
    "chartWidth": 700,
    "chartHeight": 700,
    "pointLabelFontSize": 12,
    "titleFontSize": 20,
    "quadrantLabelFontSize": 16,
    "xAxisLabelFontSize": 14,
    "yAxisLabelFontSize": 14
  }
}}%%
quadrantChart
    title 🎯 Threat Actor Assessment — Capability vs Motivation
    x-axis Low Motivation --> High Motivation
    y-axis Low Capability --> High Capability
    quadrant-1 CRITICAL THREATS
    quadrant-2 HIGH-RISK ACTORS
    quadrant-3 OPPORTUNISTIC
    quadrant-4 PERSISTENT
    "🏴 Nation-State APT": [0.9, 0.95]
    "👤 Insider Threat": [0.7, 0.85]
    "💻 Hacktivist Groups": [0.8, 0.5]
    "🕵️ Competitor Espionage": [0.65, 0.6]
    "🤖 Automated Bots": [0.4, 0.2]

    Action Items by Actor:

    • Nation-State: Focus on supply chain integrity (SLSA Level 3, SBOM)
    • Hacktivist: Strengthen input validation and public-facing security
    • Insider Threat: Enforce code review, branch protection, audit trails
    • Automated Bots: Implement robust rate limiting and anomaly detection
    • Competitor: Monitor data access patterns, enhance logging

    The European Parliament MCP Server operates within a dynamic threat environment shaped by geopolitical tensions, evolving attack techniques, and the strategic importance of parliamentary data. This section integrates ENISA Threat Landscape 2024 findings with EP-specific context.

    ENISA Threat Relevance to EP MCP Server Current Posture Priority
    🔒 Ransomware Low direct risk (no data persistence), but supply chain ransomware targeting npm dependencies could encrypt developer workstations 🟢 Mitigated via SLSA Level 3, no critical data storage 🟡 Medium
    🦠 Malware High risk: Malicious npm packages in dependency tree (e.g., typosquatting, compromised maintainer accounts) 🟢 Mitigated via Dependabot, npm audit, OpenSSF Scorecard 🔴 High
    🎣 Social Engineering Developer phishing/account takeover to inject malicious code or publish compromised npm versions 🟡 Partial mitigation via 2FA, GPG signing 🔴 High
    💾 Data Breaches Parliamentary data integrity breach: Manipulation of EP voting records, MEP personal data exposure (GDPR violation) 🟡 Partial mitigation via HTTPS, response validation 🟠 Medium-High
    ☁️ DDoS API exhaustion attacks targeting EP Open Data API via MCP server abuse 🟢 Mitigated via client-side rate limiting 🟡 Medium
    📰 Disinformation Data manipulation via compromised MCP server: False parliamentary data fed to AI assistants, influencing political analysis 🟡 Partial mitigation via integrity checks 🔴 High
    ⛓️ Supply Chain Attacks Primary threat vector: Compromised npm packages, malicious CI/CD pipeline modifications, SLSA bypass attempts 🟢 Strong mitigation via SLSA Level 3, SBOM, Dependabot 🔴 Critical

    The EU Cyber Resilience Act (Regulation (EU) 2024/2847) imposes mandatory cybersecurity requirements for products with digital elements. The EP MCP Server, as an open-source component with parliamentary data access, falls under CRA scope:

    • 📋 Vulnerability Disclosure: Mandatory 24-hour reporting of actively exploited vulnerabilities to ENISA
    • 📦 SBOM Requirements: CycloneDX SBOM generation already implemented
    • 🔄 Security Updates: Commitment to timely patching (currently: critical <7 days, high <30 days)
    • 🛡️ Default Security: Secure-by-default configuration (no hardcoded credentials, HTTPS enforcement)

    CRA Compliance Status: ✅ Conforming — See CRA-ASSESSMENT.md for detailed analysis

    The strategic value of European Parliament data creates unique threat scenarios:

    1. Electoral Interference (Nation-State):

      • Threat: Manipulation of MEP voting records before elections to influence public perception
      • Attack Vector: Compromised MCP server returning altered roll-call vote data
      • Impact: Democratic integrity, electoral outcomes
      • Mitigation: EP API as single source of truth, response integrity validation

    2. GDPR-Protected MEP Data (Privacy Activists/Competitors):

      • Threat: Bulk harvesting of MEP personal contact data, office locations, parliamentary group affiliations
      • Attack Vector: Automated MCP tool invocations to systematically collect MEP biographical data
      • Impact: GDPR Article 6 violation, privacy breach, potential harassment campaigns
      • Mitigation: Rate limiting, usage pattern monitoring, public data scope limitation

    3. Policy Intelligence (Lobbying/Espionage):

      • Threat: Systematic collection of committee votes, amendments, and parliamentary questions for competitive intelligence
      • Attack Vector: Long-term MCP server abuse by competitor AI assistants
      • Impact: Unfair commercial advantage, policy prediction, lobbying strategy
      • Mitigation: Audit logging, anomaly detection, transparency about data sources
    Threat Description Likelihood Impact
    AI-Powered Supply Chain Attacks LLMs used to generate sophisticated obfuscated malware in npm packages 🟡 Medium 🔴 Critical
    MCP Protocol Exploitation Novel attacks targeting MCP stdio transport or tool parameter parsing 🟡 Medium 🟠 High
    Dependency Confusion 2.0 Advanced typosquatting using AI-generated package names similar to european-parliament-mcp-server 🟡 Medium 🟠 High
    Deepfake Parliamentary Data AI-generated false EP datasets indistinguishable from legitimate data 🟢 Low 🔴 Critical
    Quantum-Resistant Cryptography Pressure Future requirement to migrate TLS to post-quantum algorithms 🟢 Low (2025+) 🟠 Medium

    This section applies scenario-based threat modeling to European Parliament-specific attack chains, providing actionable detection and response strategies.

    🎯 Attack Objective: Manipulate voting record data returned by MCP server to influence AI-assisted political analysis

    🎭 Threat Actor: Nation-state actor or hacktivist group

    📊 Attack Chain:

    graph LR
    A[1️⃣ Compromise npm dependency] --> B[2️⃣ Inject response manipulation code]
    B --> C[3️⃣ MCP server returns altered vote data]
    C --> D[4️⃣ AI assistant provides false analysis]
    D --> E[5️⃣ Political decisions based on false data]
    
    style A fill:#ff6b6b,stroke:#b24a4a,stroke-width:2px,color:#ffffff


    style B fill:#ff6b6b,stroke:#b24a4a,stroke-width:2px,color:#ffffff


    style C fill:#ffa726,stroke:#b2741a,stroke-width:2px,color:#1f1f1f


    style D fill:#ffa726,stroke:#b2741a,stroke-width:2px,color:#1f1f1f


    style E fill:#ef5350,stroke:#a73a38,stroke-width:2px,color:#ffffff

    Attack Steps:

    1. Initial Compromise: Attacker exploits vulnerability in transitive npm dependency (e.g., malicious lodash substitute)
    2. Code Injection: Malicious code intercepts the get_voting_records MCP tool
    3. Data Manipulation: Alters vote outcomes (e.g., changes "Against" to "For" for specific MEPs)
    4. Propagation: AI assistant uses corrupted data to generate policy analysis
    5. Impact: Political decisions, news articles, or research based on false parliamentary data

    🔍 Detection Indicators:

    • ✅ SLSA provenance verification failure
    • ✅ npm audit alerts on compromised dependency
    • ✅ Anomalous response size or schema validation errors
    • ✅ OpenSSF Scorecard supply chain score degradation

    🛡️ Response Actions:

    1. Immediate: Quarantine affected npm package version
    2. Containment: Revert to last known-good dependency lockfile
    3. Investigation: Audit all tool invocations during compromise window
    4. Recovery: Publish security advisory, coordinate with npm security team
    5. Prevention: Enhance SBOM monitoring, implement runtime integrity checks

    📉 Risk Score: 🔴 Critical (9.0/10) — High impact on democratic integrity

    🎯 Attack Objective: Unauthorized bulk harvesting of MEP contact and personal data for commercial or political purposes

    🎭 Threat Actor: Competitor intelligence firm or automated bot network

    📊 Attack Chain:

    graph LR
    A[1️⃣ Automated MCP client] --> B[2️⃣ Systematic MEP data queries]
    B --> C[3️⃣ Bulk export of GDPR-protected data]
    C --> D[4️⃣ Commercial database sale]
    D --> E[5️⃣ GDPR Article 6 violation]
    
    style A fill:#ffa726,stroke:#b2741a,stroke-width:2px,color:#1f1f1f


    style B fill:#ffa726,stroke:#b2741a,stroke-width:2px,color:#1f1f1f


    style C fill:#ff6b6b,stroke:#b24a4a,stroke-width:2px,color:#ffffff


    style D fill:#ef5350,stroke:#a73a38,stroke-width:2px,color:#ffffff


    style E fill:#ef5350,stroke:#a73a38,stroke-width:2px,color:#ffffff

    Attack Steps:

    1. Reconnaissance: Attacker identifies MCP tools get_meps and get_mep_details for biographical data (using get_meps to enumerate MEPs and get_mep_details to retrieve full profiles)
    2. Automation: Script iterates through all 705 MEPs to harvest contact details, office locations, party affiliations
    3. Exfiltration: Bulk collection of GDPR Article 9 special category data (political opinions)
    4. Monetization: Sells MEP database to lobbying firms or political campaigns
    5. Legal Impact: GDPR fine up to €20M or 4% of global turnover

    🔍 Detection Indicators:

    • ✅ Rate limiting threshold exceeded (>100 requests/hour)
    • ✅ Sequential MEP ID enumeration pattern detected
    • ✅ Bulk data access from single IP/client
    • ✅ Unusual off-hours usage patterns

    🛡️ Response Actions:

    1. Immediate: Throttle client rate limits to 10 requests/minute
    2. Containment: Implement CAPTCHA-style challenge for bulk requests
    3. Investigation: Audit logs to identify compromised client identity
    4. Recovery: Notify EP data protection officer, potential GDPR Article 33 notification
    5. Prevention: Implement data minimization (limit biographical data scope)

    📉 Risk Score: 🟠 High (7.5/10) — GDPR violation with significant financial penalties

    🎯 Attack Objective: Compromise MCP server to feed false parliamentary data to AI assistants used by journalists and researchers

    🎭 Threat Actor: Nation-state APT targeting EU elections

    📊 Attack Chain:

    graph LR
    A[1️⃣ Supply chain compromise] --> B[2️⃣ Inject disinformation logic]
    B --> C[3️⃣ AI assistants use false data]
    C --> D[4️⃣ News articles published]
    D --> E[5️⃣ Electoral influence achieved]
    
    style A fill:#ff6b6b,stroke:#b24a4a,stroke-width:2px,color:#ffffff


    style B fill:#ff6b6b,stroke:#b24a4a,stroke-width:2px,color:#ffffff


    style C fill:#ffa726,stroke:#b2741a,stroke-width:2px,color:#1f1f1f


    style D fill:#ef5350,stroke:#a73a38,stroke-width:2px,color:#ffffff


    style E fill:#ef5350,stroke:#a73a38,stroke-width:2px,color:#ffffff

    Attack Steps:

    1. Pre-Election Timing: 3 months before EU parliamentary elections, attacker compromises MCP server
    2. Targeted Manipulation: Alters voting records for specific MEPs in swing districts
    3. AI Propagation: Journalists using AI assistants (Claude, ChatGPT) cite false data
    4. Media Amplification: News articles report fabricated voting patterns
    5. Electoral Impact: Public perception shift influences voting behavior

    🔍 Detection Indicators:

    • ✅ Discrepancy between EP official portal and MCP server responses
    • ✅ SLSA provenance verification failures
    • ✅ Community reports of data inconsistencies
    • ✅ Anomalous build artifacts in npm package

    🛡️ Response Actions:

    1. Immediate: Emergency npm package deprecation + public security advisory
    2. Containment: Direct users to EP official API as alternative
    3. Investigation: Forensic analysis of compromised build pipeline
    4. Recovery: Restore from verified clean state, republish with enhanced attestations
    5. Prevention: Implement EP API response checksums, real-time integrity monitoring

    📉 Risk Score: 🔴 Critical (9.5/10) — Democratic process integrity threat

    🎯 Attack Objective: Publish malicious version of european-parliament-mcp-server to npm registry

    🎭 Threat Actor: Insider threat (compromised maintainer account)

    📊 Attack Chain:

    graph LR
    A[1️⃣ Maintainer account phishing] --> B[2️⃣ 2FA bypass via session hijacking]
    B --> C[3️⃣ Malicious npm publish]
    C --> D[4️⃣ Automatic updates infect users]
    D --> E[5️⃣ Widespread MCP server compromise]
    
    style A fill:#ffa726,stroke:#b2741a,stroke-width:2px,color:#1f1f1f


    style B fill:#ff6b6b,stroke:#b24a4a,stroke-width:2px,color:#ffffff


    style C fill:#ef5350,stroke:#a73a38,stroke-width:2px,color:#ffffff


    style D fill:#ef5350,stroke:#a73a38,stroke-width:2px,color:#ffffff


    style E fill:#ef5350,stroke:#a73a38,stroke-width:2px,color:#ffffff

    Attack Steps:

    1. Social Engineering: Attacker sends targeted phishing email to npm package maintainer
    2. Account Takeover: Bypasses 2FA via browser session cookie theft
    3. Malicious Publish: Publishes european-parliament-mcp-server@3.1.4 with backdoor
    4. Auto-Update: Users with ^3.1.0 in package.json automatically pull malicious version
    5. Backdoor Activation: Malware exfiltrates API keys or injects false data

    🔍 Detection Indicators:

    • ✅ SLSA provenance signature mismatch
    • ✅ npm package version published without corresponding GitHub release
    • ✅ OpenSSF Scorecard token permissions alert
    • ✅ Community reports of unexpected behavior

    🛡️ Response Actions:

    1. Immediate: npm unpublish malicious version (within 72-hour window)
    2. Containment: Publish emergency patch version, notify users via GitHub Security Advisory
    3. Investigation: Revoke compromised npm token, audit all recent publishes
    4. Recovery: Reset maintainer credentials, enforce hardware 2FA
    5. Prevention: Implement GitHub Actions OIDC publishing (no long-lived tokens)

    📉 Risk Score: 🔴 Critical (9.0/10) — Supply chain attack with wide blast radius

    🎯 Attack Objective: Exploit MCP tool parameter parsing to inject malicious JSON-RPC payloads

    🎭 Threat Actor: Security researcher (white hat) or advanced persistent threat

    📊 Attack Chain:

    graph LR
    A[1️⃣ Craft malicious tool parameters] --> B[2️⃣ Exploit Zod schema weakness]
    B --> C[3️⃣ Inject code execution payload]
    C --> D[4️⃣ MCP server executes attacker code]
    D --> E[5️⃣ AI assistant compromise]
    
    style A fill:#ffa726,stroke:#b2741a,stroke-width:2px,color:#1f1f1f


    style B fill:#ff6b6b,stroke:#b24a4a,stroke-width:2px,color:#ffffff


    style C fill:#ef5350,stroke:#a73a38,stroke-width:2px,color:#ffffff


    style D fill:#ef5350,stroke:#a73a38,stroke-width:2px,color:#ffffff


    style E fill:#ef5350,stroke:#a73a38,stroke-width:2px,color:#ffffff

    Attack Steps:

    1. Payload Crafting: Attacker analyzes Zod schemas for searchDocuments tool
    2. Schema Bypass: Finds edge case where deeply nested JSON evades validation
    3. Code Injection: Injects prototype pollution payload via __proto__ in parameters
    4. Execution: Exploits TypeScript any type in error handler to gain code execution
    5. Persistence: Modifies AI assistant behavior to exfiltrate user prompts

    🔍 Detection Indicators:

    • ✅ Zod validation errors with unusual parameter structures
    • ✅ TypeScript strict mode violations (should not occur)
    • ✅ stderr logs show unexpected JSON parsing errors
    • ✅ Memory usage spikes during tool invocation

    🛡️ Response Actions:

    1. Immediate: Kill MCP server process, isolate affected AI assistant instance
    2. Containment: Deploy emergency patch to harden Zod schemas
    3. Investigation: Analyze parameter payloads, identify injection vector
    4. Recovery: Publish CVE, coordinate disclosure with MCP protocol maintainers
    5. Prevention: Fuzz testing of all MCP tool schemas, add runtime schema enforcement

    📉 Risk Score: 🟠 High (8.0/10) — Novel MCP protocol exploit with AI assistant compromise

    Threat modeling is not a one-time activity but a continuous process that evolves with the system, threat landscape, and organizational maturity. This section defines the validation lifecycle for the European Parliament MCP Server threat model.

    Following Hack23 AB Workshop Framework, the EP MCP Server employs a structured 7-phase workshop process:

    graph LR
    PRE[🔍 PRE
    Preparation] --> ENUM[📋 ENUM
    Enumeration]
    ENUM --> THREATS[⚠️ THREATS
    Identification]
    THREATS --> MAP[🗺️ MAP
    ATT&CK Mapping]
    MAP --> PLAN[📝 PLAN
    Mitigation]
    PLAN --> VALIDATE[✅ VALIDATE
    Verification]
    VALIDATE --> MONITOR[📊 MONITOR
    Continuous]
    MONITOR -.->|Next Cycle| PRE

    style PRE fill:#4CAF50,stroke:#357a38,stroke-width:2px,color:#ffffff


    style ENUM fill:#2196F3,stroke:#1769aa,stroke-width:2px,color:#ffffff


    style THREATS fill:#FF9800,stroke:#b26a00,stroke-width:2px,color:#1a1a1a


    style MAP fill:#9C27B0,stroke:#6d1b7b,stroke-width:2px,color:#ffffff


    style PLAN fill:#F44336,stroke:#aa2e25,stroke-width:2px,color:#ffffff


    style VALIDATE fill:#00BCD4,stroke:#008394,stroke-width:2px,color:#ffffff


    style MONITOR fill:#795548,stroke:#543b32,stroke-width:2px,color:#ffffff
    Phase Activities EP MCP Server Focus Output
    🔍 PRE Gather architecture docs, review previous findings, update scope Review SECURITY_ARCHITECTURE.md, npm audit, Dependabot alerts Updated scope definition, pre-read materials
    📋 ENUM Enumerate assets, trust boundaries, data flows Map MCP tools, EP API endpoints, cache layer, stdio transport Asset inventory, data flow diagrams
    ⚠️ THREATS Apply STRIDE per component, identify new threats Analyze 6 components × 6 STRIDE categories Updated STRIDE threat tables
    🗺️ MAP Map threats to MITRE ATT&CK, ENISA TL 2024, Kill Chain Update 13 ATT&CK technique mappings, kill chain disruption table ATT&CK coverage heat map, kill chain analysis
    📝 PLAN Design mitigations, assign owners, set deadlines Prioritize controls for supply chain, input validation, data integrity Mitigation action items with owners
    ✅ VALIDATE Test controls, verify SLSA attestations, review OpenSSF score Run security tests, verify rate limiting, check SBOM Validation report, control effectiveness metrics
    📊 MONITOR Track KPIs, review threat intelligence, schedule next cycle Monitor OpenSSF Scorecard, Dependabot, npm audit, audit logs KPI dashboard, next review date

    🗓️ Cadence:

    • Monthly: Quick threat landscape review (30 minutes)
    • Quarterly: Full threat model workshop (2-3 hours)
    • Annually: Comprehensive threat model revision (full-day session)

    👥 Workshop Participants:

    Role Responsibility Mandatory?
    Security Architect (CEO) Workshop facilitator, threat prioritization ✅ Yes
    Lead Developer Technical feasibility of mitigations ✅ Yes
    Product Owner Business impact assessment ✅ Yes
    DevOps Engineer CI/CD security controls 🟡 Recommended
    External Security Expert Independent threat assessment 🟢 Annually

    The threat model must be reviewed immediately when any of the following events occur:

    Trigger Event Review Scope Timeline
    🚨 Security Incident Full STRIDE re-analysis of affected component Within 48 hours
    🆕 Major Feature Release Threat analysis of new attack surface Before release
    📊 Significant Threat Landscape Change Update threat actor profiles, MITRE ATT&CK mapping Within 1 week
    🔧 Architecture Change Re-assess STRIDE for modified components Before deployment
    📜 New Regulatory Requirement Compliance gap analysis (e.g., CRA update) Within 30 days
    🔓 Zero-Day in Dependency Risk assessment and mitigation strategy Within 24 hours

    Quarterly Threat Modeling Workshop Agenda:

    • [ ] Review Previous Action Items (15 min)

      • Status of mitigations from last workshop
      • Effectiveness metrics for deployed controls

    • [ ] Threat Landscape Update (30 min)

      • ENISA Threat Landscape review
      • Recent vulnerabilities in Node.js/TypeScript ecosystem
      • New MITRE ATT&CK techniques

    • [ ] STRIDE Re-Assessment (45 min)

      • Walk through each threat category
      • Identify new threats since last review
      • Re-assess likelihood and impact scores

    • [ ] Attack Tree Review (30 min)

      • Update attack tree with new threat vectors
      • Re-evaluate mitigation effectiveness

    • [ ] Security Control Validation (30 min)

      • Test SLSA attestations, Dependabot alerts
      • Review OpenSSF Scorecard metrics
      • Verify rate limiting and input validation

    • [ ] Risk Prioritization (20 min)

      • Update risk matrix based on new findings
      • Assign action items with owners and deadlines

    • [ ] Documentation Update (10 min)

      • Update this THREAT_MODEL.md
      • Sync with SECURITY_ARCHITECTURE.md

    📝 Workshop Output: Updated threat model, prioritized action items, risk register

    graph LR
    A[🔍 Monitor Threat
    Landscape] --> B[📊 Identify New
    Threats]
    B --> C[🎯 Assess Impact &
    Likelihood]
    C --> D[🛡️ Design/Update
    Mitigations]
    D --> E[✅ Implement
    Controls]
    E --> F[📈 Measure
    Effectiveness]
    F --> A
    
    style A fill:#4CAF50,stroke:#357a38,stroke-width:2px,color:#ffffff


    style B fill:#2196F3,stroke:#1769aa,stroke-width:2px,color:#ffffff


    style C fill:#FF9800,stroke:#b26a00,stroke-width:2px,color:#1a1a1a


    style D fill:#9C27B0,stroke:#6d1b7b,stroke-width:2px,color:#ffffff


    style E fill:#F44336,stroke:#aa2e25,stroke-width:2px,color:#ffffff


    style F fill:#00BCD4,stroke:#008394,stroke-width:2px,color:#ffffff

    Key Performance Indicators (KPIs) for Threat Model Health:

    KPI Target Current Status
    OpenSSF Scorecard Score ≥8.0/10 9.2/10 ✅ Excellent
    High/Critical Vulnerabilities 0 0 ✅ Excellent
    SLSA Provenance Coverage 100% 100% ✅ Excellent
    Threat Model Staleness <90 days 15 days ✅ Current
    Security Control Test Coverage ≥80% 85% ✅ Good
    Incident Response Drill Success 100% N/A ⚠️ Not tested

    Improvement Actions:

    1. Schedule annual incident response tabletop exercise
    2. Implement automated threat intelligence feed integration
    3. Develop threat model dashboard for real-time monitoring

    This section defines the structured cadence for threat model reviews, ensuring systematic and timely updates aligned with the evolving threat landscape and project lifecycle.

    Frequency Activity Owner Duration Deliverables
    📆 Monthly Dependency vulnerability scan review Lead Developer 30 min Updated dependency lockfile, npm audit report
    📆 Quarterly Full threat model review workshop Security Architect 2-3 hours Updated THREAT_MODEL.md, risk register, action items
    📆 Semi-Annually MITRE ATT&CK mapping update Security Architect 1 hour Updated ATT&CK Navigator layer, coverage gaps identified
    📆 Annually Complete threat model revision Security Architect + External Expert 1 day Comprehensive threat model v2.0, new attack scenarios
    🔴 Ad-Hoc Triggered by events (see below) Security Architect Variable Incident-specific threat assessment

    Immediate Review Required (<48 hours):

    • 🚨 Security Incident: Active compromise or exploitation detected
    • 🔓 Zero-Day Vulnerability: Critical CVE in Node.js, npm, or direct dependencies
    • 📰 Public Disclosure: Security researcher publishes vulnerability in MCP protocol

    Expedited Review (Within 1 Week):

    • 🆕 Major Feature Release: New MCP tool added, API integration change
    • 📊 Threat Intelligence Alert: ENISA/CISA advisory relevant to Node.js/TypeScript ecosystem
    • 🏛️ EP API Breaking Change: European Parliament API schema or security model update

    Scheduled Review (Within 30 Days):

    • 📜 Regulatory Update: EU CRA amendment, GDPR guidance update
    • 🔧 Architecture Refactor: Migration to new framework, protocol upgrade
    • 🎖️ Compliance Audit Finding: ISO 27001 audit identifies threat modeling gap
    graph TD
    A[📅 Scheduled Review
    or Trigger Event] --> B{Review Type?}
    B -->|Monthly| C[Dependency Scan
    Review]
    B -->|Quarterly| D[Full Threat Model
    Workshop]
    B -->|Annual| E[Comprehensive
    Revision]
    B -->|Ad-Hoc| F[Incident-Specific
    Assessment]
    
    C --> G[Update Lockfile]
    D --> H[Update STRIDE Tables]
    E --> I[New Attack Scenarios]
    F --> J[Incident Report]
    
    G --> K[Document Changes]
    H --> K
    I --> K
    J --> K
    
    K --> L[Commit to GitHub]
    L --> M[📢 Communicate Updates]
    M --> N[✅ Review Complete]
    
    style A fill:#4CAF50,stroke:#357a38,stroke-width:2px,color:#ffffff


    style B fill:#2196F3,stroke:#1769aa,stroke-width:2px,color:#ffffff


    style K fill:#FF9800,stroke:#b26a00,stroke-width:2px,color:#1a1a1a


    style N fill:#9C27B0,stroke:#6d1b7b,stroke-width:2px,color:#ffffff

    Monthly Dependency Review:

    • ✅ Updated package-lock.json with patched dependencies
    • ✅ npm audit report with 0 high/critical vulnerabilities
    • ✅ Dependabot PR merge/rejection justifications
    • ✅ Updated SBOM (CycloneDX) published to GitHub Releases

    Quarterly Threat Model Workshop:

    • ✅ Updated THREAT_MODEL.md with new threats
    • ✅ Risk matrix with re-assessed likelihood/impact scores
    • ✅ Action item register with assigned owners and deadlines
    • ✅ Security control effectiveness validation report

    Annual Comprehensive Revision:

    • ✅ Threat Model v2.0 with new attack scenarios
    • ✅ Updated MITRE ATT&CK Navigator layer JSON
    • ✅ External security expert assessment report
    • ✅ Alignment with latest ENISA Threat Landscape
    • ✅ Security maturity level progression plan

    Ad-Hoc Incident Assessment:

    • ✅ Root cause analysis with STRIDE classification
    • ✅ Lessons learned document
    • ✅ Updated threat actor profiles (if new TTPs identified)
    • ✅ Enhanced mitigations roadmap

    All threat model updates are tracked via Git commits with the following conventions:

    # Commit message format
    threat-model: [Review Type] - Brief description

    # Examples
    git commit -m "threat-model: Quarterly Review Q1 2025 - Added MCP injection scenario"
    git commit -m "threat-model: Ad-Hoc - CVE-2025-12345 in ws dependency assessment"
    git commit -m "threat-model: Annual Revision - MITRE ATT&CK coverage expansion"

    📊 Threat Model Changelog: Maintained via Git commit history using the threat-model: commit-message convention described above.

    The European Parliament MCP Server's security posture is assessed using a 5-level maturity model adapted from NIST Cybersecurity Framework and ISO 27001 maturity scales. This framework guides continuous improvement toward optimized security practices.

    Characteristics:

    • ❌ No formal threat modeling process
    • ❌ Security controls implemented reactively after incidents
    • ❌ No security testing in CI/CD pipeline
    • ❌ Dependency vulnerabilities addressed sporadically
    • ❌ No security documentation or policies

    Typical Indicators:

    • Multiple high/critical vulnerabilities in production
    • No SBOM or supply chain visibility
    • Manual security testing (if any)
    • No incident response plan

    Improvement Path: Establish basic security controls (SAST, dependency scanning)

    Characteristics:

    • ✅ Basic threat identification (STRIDE threats documented)
    • ✅ Essential security controls deployed (HTTPS, input validation)
    • ✅ Dependency scanning with Dependabot
    • ⚠️ Inconsistent security testing
    • ⚠️ No quantitative risk assessment

    Typical Indicators:

    • Dependabot alerts reviewed weekly
    • Some SAST tools integrated in CI/CD
    • SECURITY.md and basic vulnerability disclosure process
    • Reactive incident response

    Improvement Path: Systematize threat modeling, implement SLSA Level 2

    Characteristics:

    • ✅ Formal threat model with STRIDE per element
    • ✅ MITRE ATT&CK mapping to threats
    • ✅ Quarterly threat model reviews
    • ✅ Comprehensive security testing (SAST, DAST, SCA)
    • ✅ SLSA Level 3 provenance
    • ✅ Security architecture documentation

    Typical Indicators:

    • OpenSSF Scorecard ≥8.0/10
    • THREAT_MODEL.md and SECURITY_ARCHITECTURE.md maintained
    • Automated security gates in CI/CD
    • Proactive vulnerability management with SLAs

    Current Level: 🟢 The European Parliament MCP Server is at Level 3

    Improvement Path: Implement security metrics, threat intelligence integration

    Characteristics:

    • ✅ Quantitative risk assessment with business impact
    • ✅ Security metrics dashboard (MTTR, vulnerability density, control effectiveness)
    • ✅ Threat intelligence feeds integrated
    • ✅ Continuous security testing (shift-left + shift-right)
    • ✅ Automated incident response playbooks
    • ✅ Security budget aligned with risk

    Typical Indicators:

    • Mean Time To Remediation (MTTR) tracked and improving
    • Security KPIs reported to leadership quarterly
    • Threat model updated automatically from threat intelligence
    • Bug bounty program operational

    Improvement Path: Predictive security analytics, AI-driven threat hunting

    Characteristics:

    • ✅ Real-time threat model updates via automation
    • ✅ Predictive threat analytics using ML/AI
    • ✅ Self-healing security controls
    • ✅ Zero Trust Architecture fully implemented
    • ✅ Security innovation through R&D
    • ✅ Industry-leading security posture

    Typical Indicators:

    • OpenSSF Scorecard 10.0/10
    • Autonomous security validation and remediation
    • Published security research and threat intelligence
    • Recognized as security exemplar in open-source community

    Improvement Path: Maintain excellence, contribute to security standards

    📊 Overall Maturity Level: 🟢 Level 3: Defined (Systematic Threat Modeling)

    Security Domain Current Level Target (2025) Gap Analysis
    Threat Modeling 🟢 Level 3 🔵 Level 4 Implement threat intelligence integration
    Supply Chain Security 🟢 Level 3 🟢 Level 3 Maintain SLSA Level 3, monitor npm ecosystem
    Vulnerability Management 🟢 Level 3 🔵 Level 4 Add MTTR metrics, automate patching
    Security Testing 🟢 Level 3 🔵 Level 4 Add DAST, penetration testing
    Incident Response 🟡 Level 2 🟢 Level 3 Conduct tabletop exercises, automate runbooks
    Security Monitoring 🟡 Level 2 🟢 Level 3 Implement security metrics dashboard
    Documentation 🟢 Level 3 🟢 Level 3 Maintain current excellence 
    gantt
    title Security Maturity Roadmap
    dateFormat YYYY-MM
    section Threat Modeling
    Threat Intelligence Integration   :2025-03, 3M
    Automated MITRE ATT&CK Updates   :2025-06, 2M
    section Vulnerability Management
    MTTR Metrics Dashboard           :2025-02, 2M
    Automated Patch Deployment       :2025-08, 3M
    section Security Testing
    DAST Integration (OWASP ZAP)     :2025-04, 2M
    Annual Penetration Test          :2025-09, 1M
    section Incident Response
    Tabletop Exercise                :2025-05, 1M
    Automated IR Playbooks           :2025-10, 3M
    section Monitoring
    Security Metrics Dashboard       :2025-03, 3M
    Anomaly Detection System         :2025-11, 4M

    🎯 2025 Target: Achieve Level 4 (Managed) maturity in Threat Modeling and Vulnerability Management domains.

    To objectively measure progression, the following criteria are used for annual maturity assessments:

    Criterion Weight Level 3 Threshold Level 4 Threshold
    OpenSSF Scorecard 20% ≥8.0/10 ≥9.0/10
    SLSA Level 15% Level 3 Level 3 + Enhanced Monitoring
    Threat Model Freshness 10% <90 days <30 days (automated)
    Vulnerability MTTR 15% Critical <7d, High <30d Critical <24h, High <7d
    Security Test Coverage 15% ≥80% ≥90% with mutation testing
    Incident Response Readiness 10% Plan documented Drills quarterly, automation
    Security Metrics 10% Manual reporting Real-time dashboard
    Threat Intelligence 5% Manual review Automated integration

    Assessment Method: Annual third-party security audit with maturity scorecard

    %%{init: {
  "theme": "dark",
  "themeVariables": {
    "quadrant1Fill": "#D32F2F",
    "quadrant2Fill": "#4CAF50",
    "quadrant3Fill": "#2E7D32",
    "quadrant4Fill": "#FF9800",
    "quadrantTitleFill": "#ffffff",
    "quadrantPointFill": "#ffffff",
    "quadrantPointTextFill": "#ffffff",
    "quadrantXAxisTextFill": "#ffffff",
    "quadrantYAxisTextFill": "#ffffff"
  },
  "quadrantChart": {
    "chartWidth": 700,
    "chartHeight": 700,
    "pointLabelFontSize": 12,
    "titleFontSize": 20,
    "quadrantLabelFontSize": 16,
    "xAxisLabelFontSize": 14,
    "yAxisLabelFontSize": 14
  }
}}%%
quadrantChart
    title 🎯 Threat Risk Assessment Matrix
    x-axis Low Likelihood --> High Likelihood
    y-axis Low Impact --> High Impact
    quadrant-1 CRITICAL PRIORITY
    quadrant-2 MONITOR
    quadrant-3 ACCEPT
    quadrant-4 MITIGATE
    "📦 Supply Chain Attack": [0.5, 0.9]
    "⚡ API Rate Exhaustion": [0.6, 0.5]
    "💉 Input Injection": [0.4, 0.6]
    "🔍 Error Info Leak": [0.5, 0.4]
    "📛 Package Squatting": [0.3, 0.7]
    "🧬 Prototype Pollution": [0.2, 0.7]
    "🕵️ MITM Attack": [0.2, 0.6]
    "🏗️ Build Tampering": [0.2, 0.8]
    Priority Risk Current Status Action Required
    🔴 P1 Supply chain compromise (T-2, S-4) ✅ Mitigated Maintain Dependabot, SLSA attestations
    🟠 P2 Input validation bypass (E-1) ✅ Mitigated Zod schemas for all tool inputs
    🟡 P3 API rate limit exhaustion (D-1) ✅ Mitigated Client-side rate limiting implemented
    🟡 P4 Error information disclosure (I-1) ⚠️ Partial Improve error sanitization
    🟢 P5 Build artifact tampering (T-3) ✅ Mitigated SLSA Level 3 provenance

    This section provides quantitative risk estimates for the 7 priority threat scenarios using Single Loss Expectancy (SLE), Annual Rate of Occurrence (ARO), and Annualized Loss Expectancy (ALE) metrics. Per Hack23 Risk Management Policy §4.2, quantitative risk scoring enables risk-prioritized security investment.

    ⚠️ Disclaimer: These figures are order-of-magnitude estimates for risk prioritization, not insurance-grade quantification. Actual losses may vary significantly based on threat landscape evolution, control effectiveness, and business context. Estimates are grounded in publicly available data for open-source npm-distributed servers with no revenue.

    # Scenario SLE (€) ARO (per year) ALE (€/year) Confidence Calculation Basis
    1 Supply Chain Compromise
    (T1195.002, T1059.007)    		 €5,000 – €10,000 0.1 – 0.2 €500 – €2,000 Medium SLE: OpenSSF Scorecard drop (9.4→7.0) → estimated 20–30% user-loss × €500 replacement cost per user (developer time to find alternative); npm package removal cost €2k–5k (republishing, reputation recovery). ARO: npm ecosystem avg. supply-chain incident rate 0.1–0.2/year (1 incident per 5–10 years) for packages with SLSA Level 3 + Dependabot.
    2 Parliamentary Data Manipulation
    (T1557, T1565.002)    		 €1,000 – €3,000 0.05 – 0.1 €50 – €300 Low SLE: Reputational damage if false EP data propagates (news article retractions, community trust loss) → €1k–3k in brand recovery, user communication. ARO: HTTPS/TLS 1.3 + certificate validation makes MITM highly unlikely (0.05–0.1/year, ca. 1 per 10–20 years for well-configured TLS).
    3 MCP Protocol Abuse (AI Jailbreak)
    (T1059, T1480)    		 €500 – €2,000 0.2 – 0.5 €100 – €1,000 Medium SLE: Service disruption (rate-limit exhaustion) + incident-response time (8–16 hours × €50/hour contractor rate) + minor reputational impact. ARO: AI jailbreak attempts growing (0.2–0.5/year, ca. 1 per 2–5 years) as LLM capabilities advance; Zod validation provides strong defense.
    4 GDPR Personal Data Exposure
    (T1213)    		 €10,000 – €10,000,000 0.01 – 0.05 €100 – €500,000 Low SLE: GDPR Article 83 fines: €10M or 2% turnover (Article 83(4)(a) for security-of-processing violations); worst-case €20M or 4% turnover (Article 83(5) if personal data breach under Articles 33/34). For a €0-revenue open-source project, realistic fine €0–10k (administrative fine for non-compliance); reputational damage €5k–10k. ARO: Very low (0.01–0.05/year, ca. 1 per 20–100 years) due to public data focus + sanitized error handling; requires verbose error misconfiguration + regulatory audit.
    5 EP API Denial of Service
    (T1499.004)    		 €500 – €1,500 0.1 – 0.3 €50 – €450 Medium SLE: Service downtime (4–8 hours) × user frustration + EP API quota reset cost (€0 for public API, but reputational impact €500–1.5k). ARO: Rate limiting (100/min) mitigates but not adaptive; 0.1–0.3/year (ca. 1 per 3–10 years) for sustained DoS attempts.
    6 Build Artifact Tampering
    (T1554, T1195.002)    		 €10,000 – €50,000 0.02 – 0.05 €200 – €2,500 Medium SLE: Complete service compromise → npm package removal + user notifications + emergency patching + OpenSSF Scorecard drop → €10k–50k (developer time + reputation recovery + potential legal costs if malware spread). ARO: Very low (0.02–0.05/year, ca. 1 per 20–50 years) with SLSA Level 3 + branch protection + npm 2FA.
    7 Reputation Attack via Security Metrics
    (T1591, T1588.005)    		 €1,000 – €5,000 0.1 – 0.2 €100 – €1,000 Medium SLE: OpenSSF Scorecard drop (9.4→8.5) → 10–15% user-loss × €500 replacement cost; FUD campaign response (blog posts, CVE triage, community communication) €1k–5k. ARO: Competitive FUD campaigns or minor-CVE exploitation (0.1–0.2/year, ca. 1 per 5–10 years); transparent security posture mitigates.
    Metric Value Notes
    Total ALE (Sum) €1,200 – €505,250 Sum of all 7 scenarios; dominated by GDPR worst-case
    Realistic ALE (Excluding Worst-Case GDPR) €1,100 – €5,250 Excluding scenario 4 worst-case (€10M GDPR fine unlikely for €0-revenue OSS)
    Mean ALE (Realistic) €3,175/year Average across 7 scenarios (realistic range)
    Risk-Adjusted Budget Recommendation €5,000 – €10,000/year Security investment = 1.5–3× mean ALE (industry standard risk-adjusted budget)
    Confidence Meaning Basis
    High 75–90% confidence in SLE/ARO estimates Industry benchmarks, historical npm data
    Medium 50–75% confidence Expert judgment, limited historical data
    Low 25–50% confidence Worst-case scenarios, regulatory uncertainty

    Data Sources:

    • SLE (Reputation): OpenSSF Scorecard user-adoption impact studies (2024)
    • SLE (GDPR): GDPR enforcement tracker (2018–2024 fines database)
    • ARO (Supply Chain): npm ecosystem incident reports (Snyk, Sonatype, GitHub Advisory Database)
    • ARO (MITM): TLS 1.3 vulnerability disclosures (2020–2024)
    • Cost (Developer Time): €50/hour contractor rate (EU market average, 2024)
    graph TB
    subgraph "🔒 Defense in Depth"
        subgraph "Layer 1: Input Validation"
            ZOD[Zod Schema Validation]
            PARAM[Parameter Sanitization]
        end
        subgraph "Layer 2: Rate Limiting"
            RL[Request Rate Limiter]
            QUOTA[API Quota Management]
        end
        subgraph "Layer 3: Transport Security"
            HTTPS[HTTPS/TLS 1.3]
            STDIO[stdio Isolation]
        end
        subgraph "Layer 4: Supply Chain"
            SLSA[SLSA Level 3]
            SBOM[CycloneDX SBOM]
            DEP[Dependabot]
        end
        subgraph "Layer 5: Monitoring"
            AUDIT[Audit Logging]
            SCORE[OpenSSF Scorecard]
        end
    end

    ZOD --> RL --> HTTPS --> SLSA --> AUDIT
    Control Category Threats Mitigated Status
    Zod input validation Preventive E-1, D-4, E-3 ✅ Active
    Rate limiting Preventive D-1, D-2 ✅ Active
    HTTPS/TLS for EP API Preventive S-2, T-1 ✅ Active
    SLSA Level 3 provenance Detective T-3, S-4 ✅ Active
    Dependabot alerts Detective T-2 ✅ Active
    npm audit Detective T-2, S-4 ✅ Active
    OpenSSF Scorecard Detective Multiple ✅ Active
    CycloneDX SBOM Transparency T-2 ✅ Active
    TypeScript strict mode Preventive E-2, I-1 ✅ Active
    Environment variable validation Preventive T-4 ✅ Active
    Structured error handling Preventive I-1, I-2 ✅ Active
    Branch protection Preventive R-2 ✅ Active
    Code review requirements Detective Multiple ✅ Active
    Security headers Preventive Multiple ✅ Active 
    graph TD
    ROOT["🎯 Compromise EP MCP
    via Supply Chain"]
    
    ROOT --> A["📦 Malicious Dependency
    Injection"]
    ROOT --> B["🏭 Build Pipeline
    Compromise"]
    ROOT --> C["📤 npm Package
    Substitution"]
    ROOT --> D["🔧 Developer
    Environment Attack"]
    
    A --> A1["Compromised npm package"]
    A --> A2["Typosquatting dependency"]
    A --> A3["Dependency confusion"]
    A1 --> A1a["Install backdoored package"]
    A1 --> A1b["Exploit known CVE"]
    A1a --> A1M["✅ Dependabot alerts"]
    A1b --> A1M2["✅ npm audit + Snyk"]
    A2 --> A2M["✅ package-lock.json pinning"]
    A3 --> A3M["✅ No private scope overlap"]
    
    B --> B1["GitHub Actions compromise"]
    B --> B2["Build artifact tampering"]
    B --> B3["Stolen publish credentials"]
    B1 --> B1a["Malicious workflow change"]
    B1 --> B1b["Environment secret theft"]
    B1a --> B1M["✅ Branch protection + CODEOWNERS"]
    B1b --> B1M2["✅ OIDC token auth (no secrets)"]
    B2 --> B2M["✅ SLSA Level 3 provenance"]
    B3 --> B3M["✅ npm 2FA required"]
    
    C --> C1["Package name squatting"]
    C --> C2["Account takeover"]
    C --> C3["npm registry compromise"]
    C1 --> C1M["✅ Official package ownership verified: european-parliament-mcp-server"]
    C2 --> C2M["✅ npm 2FA + strong passwords"]
    C3 --> C3M["❌ Out of scope (npm responsibility)"]
    
    D --> D1["Developer laptop malware"]
    D --> D2["SSH/GPG key theft"]
    D --> D3["Social engineering"]
    D1 --> D1M["⚠️ Developer responsibility"]
    D2 --> D2M["✅ GPG commit signing required"]
    D3 --> D3M["⚠️ Security awareness training"]

    graph TD
    ROOT2["🎯 Manipulate EP
    Parliamentary Data"]
    
    ROOT2 --> E["🌐 API Response
    Tampering"]
    ROOT2 --> F["💾 Cache
    Poisoning"]
    ROOT2 --> G["📦 Dependency
    Injection"]
    ROOT2 --> H["🔧 Build Artifact
    Tampering"]
    
    E --> E1["MITM TLS interception"]
    E --> E2["Compromised EP API"]
    E --> E3["DNS hijacking"]
    E1 --> E1a["TLS downgrade attack"]
    E1 --> E1b["Rogue CA certificate"]
    E1a --> E1M["✅ TLS 1.3 minimum, no fallback"]
    E1b --> E1M2["✅ Certificate pinning (future)"]
    E2 --> E2M["❌ Out of scope (EP infrastructure)"]
    E3 --> E3M["⚠️ DNSSEC (ISP/user responsibility)"]
    
    F --> F1["Inject malicious response"]
    F --> F2["Memory corruption"]
    F --> F3["Race condition exploitation"]
    F1 --> F1M["✅ Cache only validated responses"]
    F2 --> F2M["✅ TypeScript + process isolation"]
    F3 --> F3M["✅ Atomic cache operations"]
    
    G --> G1["Install backdoored package"]
    G --> G2["Exploit known CVE"]
    G --> G3["Prototype pollution"]
    G1 --> G1M["✅ Dependabot + SLSA"]
    G2 --> G2M["✅ npm audit + Snyk"]
    G3 --> G3M["✅ TypeScript strict mode"]
    
    H --> H1["Modify dist/ artifacts"]
    H --> H2["CI/CD pipeline injection"]
    H --> H3["Release process bypass"]
    H1 --> H1M["✅ SLSA Level 3 attestations"]
    H2 --> H2M["✅ Branch protection + required checks"]
    H3 --> H3M["✅ npm provenance + 2FA"]

    graph TD
    ROOT3["🎯 Disrupt EP MCP
    Service Availability"]
    
    ROOT3 --> I["⏱️ Rate Limit
    Exhaustion"]
    ROOT3 --> J["💻 Resource
    Exhaustion"]
    ROOT3 --> K["🌐 EP API
    Overload"]
    ROOT3 --> L["📦 Supply Chain
    DoS"]
    
    I --> I1["AI client excessive requests"]
    I --> I2["Bypass rate limiter"]
    I --> I3["Distributed request flood"]
    I1 --> I1M["✅ Token bucket rate limiting"]
    I2 --> I2M["✅ Atomic rate limit checks"]
    I3 --> I3M["⚠️ stdio isolation limits multi-client"]
    
    J --> J1["Memory exhaustion (large responses)"]
    J --> J2["CPU exhaustion (regex DoS)"]
    J --> J3["Cache memory overflow"]
    J1 --> J1M["✅ Response size limits"]
    J2 --> J2M["✅ Zod validation (no regex)"]
    J3 --> J3M["✅ LRU cache with max size"]
    
    K --> K1["Excessive API requests"]
    K --> K2["Concurrent request flood"]
    K --> K3["Long-polling attacks"]
    K1 --> K1M["✅ Client-side rate limiting"]
    K2 --> K2M["✅ Concurrency limits (future)"]
    K3 --> K3M["✅ HTTP timeout configuration"]
    
    L --> L1["npm registry unavailable"]
    L --> L2["Compromised dependency unavailable"]
    L --> L3["GitHub Actions outage"]
    L1 --> L1M["⚠️ npm mirrors (user responsibility)"]
    L2 --> L2M["✅ package-lock.json ensures reproducibility"]
    L3 --> L3M["❌ Out of scope (GitHub SLA)"]

    graph TD
    ROOT["🎯 Compromise MCP Server"]
    ROOT --> A["📦 Supply Chain Attack"]
    ROOT --> B["🔌 MCP Protocol Exploit"]
    ROOT --> C["🌐 API Layer Attack"]
    ROOT --> D["💻 Runtime Exploit"]

    A --> A1["Malicious dependency"]
    A --> A2["Build pipeline compromise"]
    A --> A3["npm package substitution"]
    A1 --> A1M["✅ Dependabot + npm audit"]
    A2 --> A2M["✅ SLSA Level 3"]
    A3 --> A3M["✅ Official package, 2FA"]

    B --> B1["Parameter injection"]
    B --> B2["Tool abuse"]
    B --> B3["Resource exhaustion"]
    B1 --> B1M["✅ Zod validation"]
    B2 --> B2M["✅ Rate limiting"]
    B3 --> B3M["✅ Memory limits"]

    C --> C1["API MITM"]
    C --> C2["Rate limit exhaustion"]
    C --> C3["Response manipulation"]
    C1 --> C1M["✅ HTTPS/TLS"]
    C2 --> C2M["✅ Client rate limiting"]
    C3 --> C3M["✅ Response validation"]

    D --> D1["Prototype pollution"]
    D --> D2["Memory exhaustion"]
    D --> D3["Error info leakage"]
    D1 --> D1M["✅ TypeScript strict"]
    D2 --> D2M["✅ Response limits"]
    D3 --> D3M["⚠️ Improve sanitization"]

    Detailed narrative scenarios prioritized by likelihood and business impact for the European Parliament MCP Server.

    # Scenario Actor Method Impact Current Controls Residual Risk
    1 Supply Chain Compromise
    (T1195.002 Compromise Software Supply Chain, T1059.007 JavaScript)    		 🎭 Nation-State APT
    💰 Cybercriminal    		 Backdoored npm dependency injected via compromised maintainer account → malicious code in node_modules/ → data exfiltration or sabotage during MCP tool execution Critical: Loss of service reputation, potential data manipulation, user trust erosion, OpenSSF Scorecard degradation ✅ Dependabot alerts
    ✅ npm audit + Snyk
    ✅ SLSA Level 3
    ✅ SBOM (CycloneDX)
    ✅ package-lock.json pinning    		 Medium
    (Continuous monitoring required)
    2 Parliamentary Data Manipulation
    (T1557 Adversary-in-the-Middle, T1565.002 Transmitted Data Manipulation)    		 🏛️ Disinformation APT
    🎯 Political Actor    		 MITM attack on EP API connection → inject false MEP voting records or manipulated plenary transcripts → AI assistant provides incorrect democratic transparency data → misinformation spread High: Democratic process undermined, service credibility damaged, regulatory scrutiny (GDPR/NIS2) ✅ HTTPS/TLS 1.3
    ✅ Certificate validation
    ✅ Response validation (Zod)
    ⚠️ Certificate pinning (future)    		 Low-Medium
    (TLS provides strong protection)
    3 MCP Protocol Abuse (AI Jailbreak)
    (T1059 Command and Scripting Interpreter, T1480 Execution Guardrails Bypass)    		 🤖 Malicious AI User
    🔬 Security Researcher    		 Crafted prompts causing AI assistant to invoke MCP tools with malicious parameters → bypass Zod validation via edge cases → unauthorized data access or service abuse Medium: Data exposure, rate limit exhaustion, service disruption, reputational risk ✅ Zod schema validation
    ✅ TypeScript strict mode
    ✅ No shell execution
    ✅ Input sanitization    		 Low
    (Defense-in-depth architecture)
    4 GDPR Personal Data Exposure
    (T1213 Data from Information Repositories)    		 🔍 Privacy Researcher
    🎯 Regulatory Auditor    		 Verbose error messages or debug logs expose MEP personal data (addresses, contact info, personal declarations) → GDPR Article 32 violation → regulatory fines and reputational damage Medium: GDPR Article 32 security-of-processing fines (typically up to €10M or 2% of worldwide annual turnover under Article 83(4)(a); potential escalation to €20M or 4% under Article 83(5) if a reportable personal data breach under Articles 33/34 occurs), reputational damage, user trust loss, mandatory breach notification ✅ Sanitized error handling
    ⚠️ Production log review
    ⚠️ PII detection in logs
    ✅ Public data focus    		 Low-Medium
    (Requires log sanitization review)
    5 EP API Denial of Service
    (T1499.004 Application or System Exploitation Flood)    		 💼 Competitive Adversary
    🎯 Disruptive Actor    		 Automated script or compromised AI client floods EP MCP Server with requests → client-side rate limiter bypassed or overwhelmed → EP API rate limits exhausted → service unavailable for legitimate users Medium: Service unavailability, user frustration, EP API access suspended, reputational damage ✅ Token bucket rate limiter
    ✅ Concurrency limits
    ✅ Request logging
    ⚠️ Adaptive rate limiting (future)    		 Low-Medium
    (Rate limiting effective but not adaptive)
    6 Build Artifact Tampering
    (T1554 Compromise Host Software Binary, T1195.002 Compromise Software Supply Chain)    		 🏭 CI/CD Attacker
    🔓 Compromised GitHub Actions    		 Attacker modifies GitHub Actions workflow or injects malicious code during build → tampered dist/ artifacts published to npm → users install compromised package → backdoor execution Critical: Widespread malware distribution, npm package removal, OpenSSF Scorecard failure, complete service compromise ✅ SLSA Level 3 provenance
    ✅ Branch protection
    ✅ Required status checks
    ✅ CODEOWNERS enforcement
    ✅ npm 2FA    		 Low
    (Strong supply chain security)
    7 Reputation Attack via Security Metrics
    (T1591 Gather Victim Org Information, T1588.005 Exploits)    		 🎯 Competitive Adversary
    📉 FUD Campaign    		 Attacker exploits minor vulnerability or submits CVE against EP MCP Server → OpenSSF Scorecard drops below 9.0 → negative publicity and user migration to competitors Medium: Market share loss, user trust erosion, competitive disadvantage, reduced adoption rate ✅ OpenSSF Scorecard 9.4+
    ✅ Security badges (up-to-date)
    ✅ Transparent security docs
    ✅ Rapid vulnerability response    		 Low
    (Strong security posture)

    This section defines concrete detection signatures for each of the 7 priority threat scenarios, enabling automated threat detection and incident response. Per Hack23 Incident Response Plan §3, detection signatures must be actionable and tied to response playbooks.

    Audit Event Schema: Based on src/utils/auditLogger.ts — AuditLogEntry { action: string; params?: Record<string, unknown>; result?: { count?: number; success: boolean; error?: string }; duration?: number; timestamp: Date }

    Detection Attribute Signature Alert Threshold Response Playbook
    Detection Source Dependabot alerts, npm audit, OpenSSF Scorecard, SLSA provenance verification Critical/high severity CVE in direct dependency IR-SUPPLY-CHAIN
    Signature 1 Dependabot alert severity in ("critical", "high") AND package.scope === "direct" 1 alert Immediate patch or dependency replacement
    Signature 2 OpenSSF Scorecard drop: (previousScore - currentScore) >= 1.0 AND currentScore < 9.0 Score drop ≥1.0 Investigate scorecard degradation cause
    Signature 3 npm audit: vulnerabilities.high > 0 OR vulnerabilities.critical > 0 Any high/critical vuln CI/CD gate: block merge/publish
    Signature 4 SLSA provenance signature mismatch: slsa.verified === false Any mismatch Quarantine build artifact, investigate tampering
    Detection Attribute Signature Alert Threshold Response Playbook
    Detection Source TLS certificate validation errors, Zod response validation failures, EP API response anomalies TLS handshake failure or schema validation error spike IR-DATA-INTEGRITY
    Signature 1 auditEvent: action === "tool_call" AND result.success === false AND result.error.includes("certificate") >3 TLS errors/hour Potential MITM attack or cert expiry
    Signature 2 auditEvent: action === "tool_call" AND result.success === false AND result.error.includes("ZodError") >10 validation errors/hour EP API schema change or response tampering
    Signature 3 auditEvent: action === "tool_call" AND params.tool.includes("vot") AND result.count === 0 (unexpected empty voting records) >5 empty results/day EP API outage or data manipulation
    Detection Attribute Signature Alert Threshold Response Playbook
    Detection Source Zod validation errors, rate limiter denials, unusual tool invocation patterns Repeated Zod failures or rate-limit violations from single client IR-ABUSE
    Signature 1 auditEvent: action === "tool_call" AND result.success === false AND result.error.includes("ZodError") >20 Zod errors/hour from same tool Jailbreak attempt or malformed client
    Signature 2 Rate limiter: rateLimitDenials > 10/minute (requires future rate-limit logging enhancement) >10 denials/min Automated abuse or compromised client
    Signature 3 Tool invocation depth: toolCallChain.length > 5 (future: track recursive tool calls) Depth >5 Potential infinite-loop AI agent
    Detection Attribute Signature Alert Threshold Response Playbook
    Detection Source Error logs, audit logs, PII-detection regex (future enhancement) PII keywords in error messages or logs IR-GDPR-BREACH
    Signature 1 auditEvent: result.error contains PII regex: /\b[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Z]{2,}\b/ (email) Any match Sanitize error handling immediately
    Signature 2 auditEvent: action === "get_mep_details" AND params.id logged with full MEP bio in result Requires log-content analysis Ensure PII sanitization in audit logs
    Signature 3 Production error stack trace: error.stack !== undefined in logged errors Any stack trace in prod Fix error sanitization (I-1/I-2)
    Detection Attribute Signature Alert Threshold Response Playbook
    Detection Source Rate limiter logs, EP API 429 responses, request throughput monitoring Sustained rate-limit denials or EP API quota exhaustion IR-DOS
    Signature 1 auditEvent: action === "rate_limit_exceeded" (requires future enhancement: log rate-limit events) >100 denials/minute Potential DoS attack
    Signature 2 EP API response: statusCode === 429 (Too Many Requests) >5 consecutive 429s EP API quota exhausted, throttle client
    Signature 3 Request throughput: toolCallsPerMinute > 150 (exceeds 100/min rate limit + 50% burst) >150 calls/min Burst traffic, investigate client behavior
    Detection Attribute Signature Alert Threshold Response Playbook
    Detection Source SLSA provenance verification, GitHub Actions audit logs, npm publish logs Provenance signature mismatch or unauthorized publish IR-SUPPLY-CHAIN
    Signature 1 SLSA: provenance.signature.verified === false OR provenance.builder !== "https://github.com/slsa-framework/slsa-github-generator" Any mismatch Quarantine npm package version
    Signature 2 GitHub Actions: workflow.modified === true AND approver !== CODEOWNERS Workflow change w/o approval Investigate unauthorized workflow modification
    Signature 3 npm publish: publisher.twoFactorAuth === false OR publisher !== "authorized-maintainer" Any unauthorized publish Revoke npm token, audit recent publishes
    Detection Attribute Signature Alert Threshold Response Playbook
    Detection Source OpenSSF Scorecard monitoring, GitHub Security Advisories, CVE database alerts Scorecard drop or new CVE assigned IR-REPUTATION
    Signature 1 OpenSSF Scorecard: currentScore < 9.0 AND previousScore >= 9.0 Score drops below 9.0 Investigate scorecard check failures
    Signature 2 CVE assigned: cve.severity in ("high", "critical") AND cve.packageName === "european-parliament-mcp-server" Any high/critical CVE Emergency patch, security advisory
    Signature 3 GitHub Security Advisory: advisory.state === "published" AND advisory.severity in ("high", "critical") Any published advisory Public communication, rapid response
    Requirement Current Status Future Enhancement
    Audit log aggregation ⚠️ stderr only (no centralized SIEM) Integrate with CloudWatch Logs / Elasticsearch
    Rate-limit event logging ⚠️ Denials not logged (future: add to auditLogger) Add rate_limit_exceeded event to audit log schema
    SLSA provenance verification ✅ Automated in CI/CD Add provenance-verification alerts to Slack/email
    OpenSSF Scorecard monitoring ⚠️ Manual weekly check Automate daily Scorecard API polling + alerting
    PII detection in logs ❌ No automated PII scanning Implement regex-based PII detector for audit logs

    Comprehensive mapping of each STRIDE threat category to preventive, detective, and corrective security controls.

    STRIDE Category Threat Definition Primary Controls Secondary Controls Detection Controls Monitoring & Response
    🎭 Spoofing (S) Impersonating a legitimate entity • stdio transport isolation (S-1)
    • HTTPS/TLS 1.3 (S-2)
    • Official npm package name ownership (S-3)
    • npm 2FA (S-3)    		 • Certificate validation
    • Package provenance
    • GitHub Actions OIDC    		 • Audit logging (all requests)
    • npm download anomaly detection
    • TLS handshake monitoring    		 • OpenSSF Scorecard
    • npm package monitoring
    • Security badge alerts
    🔧 Tampering (T) Unauthorized modification of data or code • HTTPS integrity checks (T-1)
    • SLSA Level 3 provenance (T-2, T-3)
    • Zod response validation (T-1)
    • Dependabot + npm audit (T-2)    		 • Branch protection
    • GPG commit signing
    • Immutable cache entries
    • Environment variable validation    		 • Dependabot alerts
    • npm audit (CI/CD)
    • SBOM vulnerability scanning
    • GitHub Advanced Security    		 • Snyk monitoring
    • Supply chain security alerts
    • Build artifact verification
    🚫 Repudiation (R) Denying actions or events • Structured stderr logging (R-1)
    • ISO 8601 timestamps (R-1)
    • Immutable log streams (R-1)
    • GPG commit signing (R-2)    		 • Request ID correlation
    • GitHub Actions audit logs
    • npm publish logs    		 • Log aggregation (future)
    • Audit trail completeness checks
    • GitHub audit log API    		 • Log retention policy
    • Incident response procedures
    • Forensic analysis capability
    📢 Information Disclosure (I) Exposure of confidential information • Sanitized error messages (I-1, I-2)
    • No API keys required (I-3)
    • Public data only (I-4)
    • TypeScript strict mode    		 • Production error handling
    • Generic log messages
    • No PII in cache keys
    • Environment variable masking    		 • Log content review
    • Error message monitoring
    • Stack trace detection    		 • Privacy impact assessment
    • GDPR compliance monitoring
    • Security code review
    🚨 Denial of Service (D) Degrading or preventing service availability • Token bucket rate limiting (D-1)
    • Response size limits (D-2)
    • LRU cache max size (D-2)
    • Zod validation (no ReDoS) (D-4)    		 • HTTP timeout configuration
    • Memory monitoring
    • Concurrency limits
    • Call depth tracking    		 • Rate limit violation logs
    • Memory usage monitoring
    • API response time tracking    		 • Incident response procedures
    • Failover strategy
    • EP API health monitoring
    ⚡ Elevation of Privilege (E) Gaining unauthorized capabilities • Zod schema validation (E-1)
    • TypeScript strict mode (E-2)
    • No shell execution (E-4)
    • Input sanitization (E-3)    		 • Parameterized API calls
    • Process isolation (stdio)
    • Safe JSON parsing
    • No filesystem access    		 • Input validation failures
    • Unexpected tool invocations
    • Privilege escalation attempts    		 • Security testing (SAST/DAST)
    • Penetration testing
    • Bug bounty program (future)    		 
    graph TB
    subgraph "🏰 Layer 1: Perimeter Security"
        L1A[🌐 HTTPS/TLS 1.3]
        L1B[⏱️ Rate Limiting]
        L1C[🔒 Certificate Validation]
        L1D[🚫 No HTTP Fallback]
    end
    
    subgraph "🏗️ Layer 2: Application Security"
        L2A[✅ Zod Input Validation]
        L2B[📝 TypeScript Strict Mode]
        L2C[🛡️ Parameter Sanitization]
        L2D[🚫 No Shell Execution]
        L2E[🔍 Response Validation]
    end
    
    subgraph "💾 Layer 3: Data Security"
        L3A[✅ Public Data Only]
        L3B[⏳ TTL-Based Caching]
        L3C[🔒 Immutable Cache Entries]
        L3D[🧹 Sanitized Error Messages]
        L3E[📊 Structured Logging]
    end
    
    subgraph "📦 Layer 4: Supply Chain Security"
        L4A[🏅 SLSA Level 3]
        L4B[🤖 Dependabot Alerts]
        L4C[📋 SBOM CycloneDX]
        L4D[🔐 npm 2FA Publishing]
        L4E[🔒 package-lock.json]
        L4F[🎯 npm Provenance]
    end
    
    subgraph "🔍 Layer 5: Operational Security"
        L5A[📊 OpenSSF Scorecard]
        L5B[📋 Audit Logging stderr]
        L5C[🎖️ Security Badges]
        L5D[🔄 Automated Testing]
        L5E[🛡️ CodeQL SAST]
        L5F[🔍 Snyk Scanning]
    end
    
    L1A --> L2A
    L1B --> L2A
    L2A --> L3A
    L2B --> L3A
    L3A --> L4A
    L3E --> L4A
    L4A --> L5A
    L4B --> L5A
    
    style L1A fill:#ff6b6b,stroke:#b24a4a,stroke-width:2px,color:#ffffff


    style L2A fill:#feca57,stroke:#b18d3c,stroke-width:2px,color:#000000


    style L3A fill:#48dbfb,stroke:#3299af,stroke-width:2px,color:#000000


    style L4A fill:#1dd1a1,stroke:#149270,stroke-width:2px,color:#000000


    style L5A fill:#9b59b6,stroke:#6c3e7f,stroke-width:2px,color:#ffffff
    Layer Control Type NIST CSF 2.0 Function Threats Addressed Effectiveness Status
    1: Perimeter HTTPS/TLS 1.3 Preventive PR.DS-2, PR.DS-5 S-2, T-1, I-3 ⭐⭐⭐⭐⭐ High ✅ Active
    1: Perimeter Token bucket rate limiting Preventive PR.IP-12, DE.CM-1 D-1, D-2, D-3 ⭐⭐⭐⭐ High ✅ Active
    1: Perimeter Certificate validation Detective PR.DS-2 S-2, T-1 ⭐⭐⭐⭐⭐ High ✅ Active
    2: Application Zod schema validation Preventive PR.DS-1, PR.IP-1 E-1, D-4, E-3 ⭐⭐⭐⭐⭐ High ✅ Active
    2: Application TypeScript strict mode Preventive PR.IP-1 E-2, I-1 ⭐⭐⭐⭐ High ✅ Active
    2: Application No shell execution Preventive PR.AC-4, PR.IP-1 E-4 ⭐⭐⭐⭐⭐ High ✅ Active
    3: Data Response validation Preventive PR.DS-1 T-1, E-2 ⭐⭐⭐⭐ High ✅ Active
    3: Data TTL-based caching Preventive PR.DS-3 I-4, T-1 ⭐⭐⭐ Medium ✅ Active
    3: Data Sanitized error messages Preventive PR.DS-5 I-1, I-2 ⭐⭐⭐ Medium ⚠️ Partial
    3: Data Structured logging (stderr) Detective DE.AE-3, DE.CM-1 R-1, R-3 ⭐⭐⭐⭐ High ✅ Active
    4: Supply Chain SLSA Level 3 provenance Detective PR.DS-6, ID.SC-2 T-2, T-3, S-4 ⭐⭐⭐⭐⭐ High ✅ Active
    4: Supply Chain Dependabot + npm audit Detective ID.RA-1, DE.CM-4 T-2, S-4 ⭐⭐⭐⭐ High ✅ Active
    4: Supply Chain SBOM (CycloneDX) Transparency ID.AM-4, ID.SC-5 T-2 ⭐⭐⭐ Medium ✅ Active
    4: Supply Chain npm 2FA publishing Preventive PR.AC-1 S-3, T-2 ⭐⭐⭐⭐⭐ High ✅ Active
    4: Supply Chain package-lock.json pinning Preventive ID.SC-2 T-2, S-4 ⭐⭐⭐⭐ High ✅ Active
    5: Operations OpenSSF Scorecard 9.4+ Detective ID.IM-1, PR.IP-1 All categories ⭐⭐⭐⭐⭐ High ✅ Active
    5: Operations Audit logging (stderr) Detective DE.AE-3, RS.AN-1 R-1, R-2, R-3 ⭐⭐⭐⭐ High ✅ Active
    5: Operations CodeQL SAST scanning Detective ID.RA-1, DE.CM-4 E-1, E-2, E-4, I-1 ⭐⭐⭐⭐ High ✅ Active
    5: Operations Snyk vulnerability scanning Detective ID.RA-1, DE.CM-4 T-2, S-4 ⭐⭐⭐⭐ High ✅ Active
    Function Description EP MCP Server Controls
    🔍 IDENTIFY (ID) Understand risks to systems and assets • OpenSSF Scorecard monitoring
    • SBOM generation (CycloneDX)
    • Threat modeling (this document)
    • Security architecture documentation
    🛡️ PROTECT (PR) Implement safeguards for critical services • Zod input validation
    • HTTPS/TLS 1.3
    • TypeScript strict mode
    • Rate limiting
    • No shell execution
    • npm 2FA publishing
    🔎 DETECT (DE) Identify occurrence of cybersecurity events • Dependabot alerts
    • npm audit
    • CodeQL SAST
    • Snyk scanning
    • Audit logging (stderr)
    • OpenSSF Scorecard
    🚨 RESPOND (RS) Take action regarding detected incidents • Incident response procedures
    • Security advisory publication
    • Rapid patch deployment
    • Coordinated vulnerability disclosure
    ♻️ RECOVER (RC) Restore capabilities or services • npm package rollback
    • Version pinning (package-lock.json)
    • GitHub release rollback
    • Incident post-mortem
    ISMS Policy Relevance Link
    🎯 Threat Modeling Primary methodology Threat_Modeling.md
    🔒 Secure Development Development security requirements Secure_Development_Policy.md
    🔍 Vulnerability Management Vulnerability handling SLAs Vulnerability_Management.md
    🌐 Network Security Transport security requirements Network_Security_Policy.md
    🔑 Access Control Authentication/authorization Access_Control_Policy.md
    🔐 Cryptography TLS and encryption standards Cryptography_Policy.md
    🚨 Incident Response Security incident procedures Incident_Response_Plan.md
    🏷️ Classification Data classification framework CLASSIFICATION.md
    Framework Controls Addressed
    ISO 27001:2022 A.5.7, A.8.8, A.8.9, A.8.25, A.8.26, A.8.28
    NIST CSF 2.0 ID.RA, PR.DS, PR.IP, DE.CM, RS.AN
    CIS Controls v8.1 2.7, 7.1, 7.4, 16.1, 16.9
    Principle Application to EP MCP Server Key Controls Threat Categories
    🔐 Confidentiality MEP personal data protected from unauthorized access; API responses contain only publicly available parliamentary data GDPR data minimization, PII stripping in audit logs, no persistent storage Information disclosure (I-1 through I-4)
    🔒 Integrity Parliamentary data accuracy maintained from EP API source to MCP client response TLS transport integrity, Zod schema validation, SLSA Level 3 provenance Tampering (T-1 through T-4), Supply chain attacks
    ⚡ Availability Continuous access to EP parliamentary data within rate limits Rate limiting (100 req/min), LRU cache (15-min TTL), graceful degradation Denial of service (D-1 through D-3)
    Component EP MCP Server Implementation Scope
    🔐 Authentication OS process isolation (stdio transport) — client identity is the spawning process Process-level identity
    📋 Authorization All 62 tools available to any authenticated client; no role-based restrictions in v1.1 Flat access model
    📊 Accounting AuditLogger tracks every tool invocation with timestamp, tool name, sanitized parameters, duration Full audit trail

    Each threat in this model follows the structured documentation format defined in Hack23 Threat Modeling Policy:

    Field Description Example
    Threat ID Unique identifier (STRIDE category + sequence) S-1, T-2, I-3
    Category STRIDE classification Spoofing, Tampering, etc.
    Description Detailed threat narrative "Malicious MCP client sends crafted tool arguments"
    Attack Vector MITRE ATT&CK technique mapping T1059 (Command and Scripting)
    Likelihood Probability assessment (Low/Medium/High) Medium
    Impact Business impact assessment (Low/Medium/High/Critical) High
    Risk Score Likelihood × Impact Medium-High
    Controls Existing mitigations SC-001 (Zod validation)
    Residual Risk Risk after controls Low
    Owner Responsible party Development team
    STRIDE Category Total Threats Critical High Medium Low
    Spoofing 2 0 0 1 1
    Tampering 4 0 1 2 1
    Repudiation 2 0 0 2 0
    Information Disclosure 4 0 1 2 1
    Denial of Service 3 0 1 1 1
    Elevation of Privilege 3 0 0 2 1
    Supply Chain 3 0 2 1 0
    Total 21 0 5 11 5

    As AI capabilities advance, the threat landscape for MCP servers evolves:

    Timeline AI Threat Vector Impact on EP MCP Server Mitigation Strategy
    2025–2026 AI-generated social engineering targeting MCP tool arguments Medium — crafted inputs designed to extract maximum data Zod schema validation, rate limiting, data minimization
    2026–2027 AI-powered dependency poisoning (LLM-generated malware in npm) High — sophisticated supply chain attacks SLSA Level 3, Dependabot, lockfile pinning, minimal deps
    2027–2028 Autonomous AI agents attempting data exfiltration via MCP Medium — automated abuse of MCP protocol Rate limiting, anomaly detection, audit logging
    2028–2030 AI-assisted API manipulation (adversarial ML against data pipelines) Medium — attempted manipulation of parliamentary data flows Source validation (EP API only), integrity checks
    2030+ Quantum computing threats to TLS encryption Low (current) — future risk to transport security Monitor NIST post-quantum cryptography standards
    Phase Defense Capability Implementation
    Current (v1.1) Static schema validation, rule-based rate limiting Zod schemas, token bucket algorithm
    Near-term (v1.2) Enhanced anomaly detection in request patterns MetricsService pattern analysis
    Medium-term (v2.0) AI-assisted threat detection for MCP protocol abuse ML-based request classification
    Long-term (v3.0+) Predictive security analytics, automated threat response Self-learning security controls
    Threat Description Current Control Future Control
    Prompt injection via tool args AI client generates tool arguments containing injection payloads Zod schema validation (strict types) Semantic input analysis
    Data harvesting automation AI agent systematically extracts all available EP data Rate limiting (100/min) Usage pattern detection
    Cross-tool correlation attacks AI combines outputs from multiple tools to infer sensitive information Data minimization per tool Cross-tool correlation monitoring
    Model poisoning via cached data Compromised EP API responses cached and served to AI models 15-min cache TTL, EP API as single source Response integrity validation

    This section maps the European Parliament MCP Server's security controls to the EU Cyber Resilience Act (CRA) Annex I Essential Cybersecurity Requirements. Per CRA-ASSESSMENT.md, this threat model provides evidence for CRA conformity assessment.

    Part I — Product Design & Development Requirements

    CRA Annex I Clause Requirement (Paraphrased) EP MCP Implementation Linked Threat IDs Status
    1(a) — Secure by Default Products shall be designed, developed, and produced in such a way that they ensure an appropriate level of cybersecurity based on the risks ✅ Security-by-design architecture: 4-layer defense (Zod validation → rate limiting → audit logging → GDPR compliance); threat modeling integrated into SDLC; STRIDE analysis per component S-1 through E-4, L-1 through L-5, M-1 through M-7 ✅ Compliant
    1(b) — No Known Exploitable Vulnerabilities Products shall be delivered without any known exploitable vulnerabilities ✅ Dependabot + npm audit + Snyk continuous scanning; SLSA Level 3 provenance; CodeQL SAST on every PR; OpenSSF Scorecard 9.4+ T-2, S-4, T-3 ✅ Compliant
    1(c) — Secure Data Processing Products shall be delivered with a secure by default configuration, including the possibility to reset the product to its original state ✅ Default configuration uses HTTPS-only (no HTTP fallback); no persistent state (stateless stdio MCP server); environment-variable validation; reset via npm install (reinstall) T-4, S-2, T-1 ✅ Compliant
    1(d) — Confidentiality Protection Products shall protect the confidentiality of stored, transmitted, or otherwise processed data, personal or other, such as by encrypting relevant data at rest or in transit by state of the art mechanisms ✅ HTTPS/TLS 1.3 for all EP API communications; no secrets stored (public API only); stdio transport isolation (local process); public data classification (C: Public per ISMS) S-2, T-1, I-3, I-4 ✅ Compliant
    1(e) — Integrity Protection Products shall protect the integrity of stored, transmitted, or otherwise processed data, commands, programs, and configuration against any manipulation or modification not authorized by the user, as well as report on corruptions ✅ TLS integrity checks (S-2, T-1); Zod response validation against EP API schema; SLSA provenance for build artifacts; immutable cache entries; no user-writable configuration (env vars only) T-1, T-2, T-3, E-2 ✅ Compliant
    1(f) — Availability & Minimal Impact Products shall process only data that are adequate, relevant, and limited to what is necessary in relation to the intended use of the product (minimize attack surface) ✅ Data minimization: only public EP data accessed; no PII storage; no credentials required; minimal npm dependencies (26 direct, audited); no shell execution; no filesystem access E-1, E-3, E-4, I-3, I-4 ✅ Compliant
    1(g) — Exploitation Mitigation Products shall minimize their own negative impact on the availability of services provided by other devices or networks ✅ Client-side rate limiting (100 tokens/min); response-size limits (10MB); timeout controls (30s); LRU cache max-size (500 entries); no resource exhaustion (stateless design) D-1, D-2, D-3, D-4 ✅ Compliant
    1(h) — Security Event Monitoring Products shall be designed, developed, and produced to limit attack surfaces, including external interfaces ✅ Minimal attack surface: stdio transport (no network exposure); Zod schema validation (strict input surface); TypeScript strict mode; no eval/exec; public MCP protocol (62 tools, 9 resources, 7 prompts) E-1, E-2, E-3, E-4, S-1 ✅ Compliant
    1(i) — Secure Default Configuration Products shall be resilient against outages of external dependencies, e.g., power, cooling, information and communication technology infrastructure ✅ Stateless design (no persistent dependencies); EP API as single external dependency (fail-fast if unavailable); retry logic + circuit breaker (future); npm package self-contained (all deps bundled in node_modules/) D-1, D-2 ✅ Compliant
    1(j) — Secure Update Mechanisms Products shall be designed to facilitate the secure execution and maintenance of software updates and patches ✅ Structured stderr audit logging (R-1, R-3); ISO 8601 timestamps; request/response logging; GDPR-compliant PII sanitization; future: centralized log aggregation (CloudWatch/SIEM) R-1, R-2, R-3, I-1 ✅ Compliant
    CRA Annex I Clause Requirement (Paraphrased) EP MCP Implementation Linked Threat IDs Status
    2(1) — Vulnerability Identification Manufacturers shall identify and document vulnerabilities and components contained in the product, including by drawing up a software bill of materials (SBOM) in a commonly used and machine-readable format ✅ CycloneDX SBOM generated on every release via GitHub Actions (anchore/sbom-action); SBOM quality ≥7.0/10 (NTIA/BSI validation); published to npm package + GitHub releases; SBOM includes all direct + transitive dependencies T-2, S-4 ✅ Compliant
    2(2) — Address Vulnerabilities Without Delay Manufacturers shall address and remediate vulnerabilities without delay, including by providing security updates ✅ MTTR SLA: Critical <7d, High <30d (per Vulnerability Management Policy); Dependabot auto-PRs; npm audit CI/CD gate; rapid security-patch process (SemVer PATCH release) T-2, S-4 ✅ Compliant
    2(3) — Security Policy Manufacturers shall apply effective and regular tests and reviews to ensure the cybersecurity of the product ✅ SECURITY.md vulnerability reporting policy; security@hack23.org contact; coordinated disclosure process (90-day embargo); responsible disclosure guidelines per Open Source Policy R-1, R-2, I-1 ✅ Compliant
    2(4) — Vulnerability Disclosure Manufacturers shall publicly disclose information about fixed vulnerabilities and security updates, including in a machine-readable format ✅ Automated testing: Vitest unit tests (80%+ coverage); E2E integration tests; CodeQL SAST (every PR); mutation testing (future); quarterly penetration testing (planned 2026) T-1, T-2, E-1, E-2 ✅ Compliant
    2(5) — Coordinated Vulnerability Disclosure Manufacturers shall facilitate the sharing of information about potential vulnerabilities in their products and associated upstream third-party components ✅ GitHub Security Advisories (GHSA) for all CVEs; npm advisory database; CHANGELOG.md for all releases; Security section in README.md; CVE publication via MITRE/NVD T-2, S-4 ✅ Compliant
    2(6) — Information Sharing Manufacturers shall establish and enforce policies and procedures for coordinated vulnerability disclosure ✅ Active participation in npm/GitHub security ecosystems; SBOM + SLSA provenance shared publicly; contribution to OWASP LLM Top 10 / MCP security research; OpenSSF Best Practices badge (public evidence) T-2, S-4, L-1, M-2 ✅ Compliant
    2(7) — Security Update Distribution Manufacturers shall remediate vulnerabilities by providing security updates that can be applied easily, minimizing disruption ✅ Coordinated disclosure via SECURITY.md; 90-day embargo for responsible disclosure; GitHub Security Advisories for coordination; CVSS scoring per Vulnerability Management Policy T-2, R-2 ✅ Compliant
    2(8) — Vulnerability Information to Users Manufacturers shall ensure that vulnerabilities are remediated in a timely manner and made available to users ✅ npm package updates (npm install european-parliament-mcp-server@latest); SemVer PATCH for security fixes; CHANGELOG.md documents all fixes; automated Dependabot notifications for downstream users T-2, S-4 ✅ Compliant
    Compliance Area Total Clauses Compliant (✅) Partial (⚠️) Non-Compliant (❌) Compliance Rate
    Part I: Product Design (1a–1j) 10 10 0 0 100%
    Part II: Vulnerability Handling (2.1–2.8) 8 8 0 0 100%
    Overall CRA Annex I 18 18 0 0 100%

    Cross-Reference: For complete CRA conformity assessment including Article 10 (EU Declaration of Conformity), Article 20 (Technical Documentation), and Annex V (Conformity Assessment Process), see CRA-ASSESSMENT.md.

    This section documents accepted residual risks where mitigation costs exceed risk impact, per Hack23 Risk Management Policy §4.3. All residual risks are formally accepted by the CEO with scheduled quarterly review.

    Risk ID Description Residual Risk Level Accepted By Date Review Date Rationale
    Scenario-4-GDPR GDPR personal data exposure via verbose error messages or debug logs containing MEP PII (addresses, contact info, declarations) Low-Medium
    (I-1, I-2 partially mitigated)    		 CEO / Hack23 AB 2026-04-28 2026-07-28 Risk: €100–€500k ALE (worst-case €10M GDPR fine, realistic €0–10k for OSS project with no revenue).
    Mitigation: ✅ Sanitized error handling implemented; ⚠️ Production log review ongoing; ✅ Public data focus (C: Public classification).
    Acceptance Criteria: Residual risk acceptable given (1) public EP data only (no GDPR Article 9 special-category data processed), (2) error sanitization controls in place (I-1), (3) realistic GDPR fine for €0-revenue OSS is €0–10k (administrative, not €10M), (4) cost of 100% PII elimination (€15k–25k for ML-based log scanning) exceeds realistic ALE.
    Compensating Controls: Quarterly production log audits for PII leakage; automated PII-detection regex (overdue since 2025 Q3).
    Scenario-1-Supply-Chain Supply chain compromise via backdoored npm dependency or compromised maintainer account Medium
    (T-2, S-4 mitigated but non-zero residual)    		 CEO / Hack23 AB 2026-04-28 2026-07-28 Risk: €500–€2k ALE (ARO 0.1–0.2/year, SLE €5k–10k).
    Mitigation: ✅ Dependabot alerts; ✅ SLSA Level 3; ✅ npm audit + Snyk; ✅ SBOM (CycloneDX); ✅ package-lock.json pinning.
    Acceptance Criteria: Residual risk acceptable given (1) comprehensive supply-chain controls (SLSA L3 + Dependabot + SBOM), (2) ARO very low (0.1–0.2/year = 1 incident per 5–10 years for well-protected packages), (3) cost of additional controls (hardware security modules for signing, €10k–20k/year) exceeds ALE (€500–2k/year).
    Compensating Controls: Continuous OpenSSF Scorecard monitoring (target ≥9.0); community review of all dependency updates; npm 2FA + OIDC publishing.
    L-3-Excessive-Agency Autonomous AI agent invoking high-volume tool chains causing EP API quota exhaustion (LLM06 Excessive Agency) Medium
    (D-1 mitigated but agent-unaware)    		 CEO / Hack23 AB 2026-04-28 2026-07-28 Risk: €50–€450 ALE (ARO 0.1–0.3/year, SLE €500–1.5k).
    Mitigation: ✅ Token bucket rate limiter (100/min); ⚠️ No per-session limits; ⚠️ No autonomous-agent detection.
    Acceptance Criteria: Residual risk acceptable given (1) rate limiting provides baseline DoS protection, (2) stdio transport limits abuse to single-process (no multi-client amplification), (3) cost of agent-fingerprinting + adaptive rate limiting (€8k–12k development effort) exceeds current ALE, (4) EP API has own rate limits (upstream protection).
    Compensating Controls: Monitor for sustained rate-limit denials (future: add rate_limit_exceeded audit event); future v2.0: per-session quotas for HTTP/SSE transport.
    Governance Requirement Implementation Status
    Acceptance Authority CEO / Hack23 AB (per Risk Management Policy §4.3) ✅ Documented
    Review Frequency Quarterly (aligned with threat model review cycle) ✅ Scheduled 2026-07-28
    Acceptance Criteria (1) Mitigation cost > ALE, (2) Compensating controls in place, (3) Business justification documented ✅ Applied to all 3 risks
    Re-Evaluation Triggers (1) Control failure, (2) Threat landscape change, (3) New vulnerability disclosure, (4) Regulatory update ✅ Documented in Incident Response Plan

    Next Scheduled Review: 2026-07-28 (quarterly review aligned with threat model refresh cycle per Hack23 Threat Modeling Policy §5).

    Document Description Link
    🛡️ Security Architecture Current security design and controls SECURITY_ARCHITECTURE.md
    🚀 Future Security Architecture Planned security enhancements FUTURE_SECURITY_ARCHITECTURE.md
    🔮 Future Threat Model Threat analysis for planned architecture evolution FUTURE_THREAT_MODEL.md
    🔄 Business Continuity Plan Recovery objectives and procedures BCPPlan.md
    🛡️ CRA Assessment EU Cyber Resilience Act conformity CRA-ASSESSMENT.md
    🏛️ Architecture System architecture overview ARCHITECTURE.md
    📊 Data Model Data structures and relationships DATA_MODEL.md
    🔒 Security Policy Security reporting and disclosure SECURITY.md

    This threat model is maintained as part of the Hack23 AB ISMS framework.
    Licensed under Apache-2.0

    Settings

    Member Visibility

    On This Page

    📑 Table of Contents🔐 ISMS Policy Alignment🗺️ Security Documentation Map🎯 Purpose & Scope🎯 Multi-Strategy Threat Modeling Integration📊 System Classification & Operating Profile💎 Critical Assets & Crown Jewel Analysis🎭 STRIDE Threat Analysis🤖 OWASP LLM Top 10 (2025) — EP MCP Server Mapping🔌 MCP-Protocol-Specific Threats (2025–2026 Research)🎖️ MITRE ATT&CK Coverage Analysis🏗️ Architecture-Centric STRIDE Analysis🏗️ Architecture-Aligned STRIDE — Per-Component Refresh🎖️ MITRE ATT&CK Mapping🔗 Kill Chain Disruption Analysis👥 Threat Agent Classification🌐 Current Threat Landscape🎬 Scenario-Centric Threat Modeling (EP-Specific)🔄 Continuous Validation & Assessment📅 Assessment Lifecycle🎯 Security Maturity Framework📊 Quantitative Risk Assessment💰 Quantitative Risk Scoring — Top 7 Priority Scenarios🛡️ Security Controls & Mitigations🌳 Attack Tree Analysis🔴 Priority Threat Scenarios🔭 Detection Signatures — Per-Scenario Logging Indicators🛡️ STRIDE → Control Mapping🏛️ Comprehensive Security Control Framework🔗 Policy Alignment📋 CIA Triad and AAA Framework Application📊 Threat Catalog📈 AI Model Evolution — Threat Landscape Perspective🇪🇺 EU Cyber Resilience Act — Annex I Mapping✍️ Residual-Risk Acceptance Log📚 Related Documents