SECURITY.md

May 5, 2026 · View on GitHub

Hack23 AB Logo

🔐 Hack23 AB — European Parliament MCP Server Security Policy

🛡️ Security Through Transparency and Excellence
🎯 Security-first API development with verifiable compliance

Owner Version Effective Date Review Cycle OpenSSF Best Practices

📋 Document Owner: CEO | 📄 Version: 1.0 | 📅 Last Updated: 2026-02-26 (UTC)
🔄 Review Cycle: Quarterly | ⏰ Next Review: 2026-05-26

🏆 Current Security Posture

Current security state as of 2026-02-26:

MetricStatusValue
🧪 Test Suite✅ Passing1396 tests across 54 test files (docs/test-results/results.json)
🔒 npm audit✅ Clean0 vulnerabilities
📜 License compliance✅ PassingAll MIT/ISC/Apache-2.0
🏛️ SLSA Level 3✅ AchievedCryptographic provenance on all releases
🔍 SAST (CodeQL)✅ EnabledAutomated on every PR and push
🔑 Secret scanning✅ EnabledGitHub native secret detection
📦 SBOM✅ PublishedSPDX + CycloneDX on every release
🔐 Sigstore✅ Enablednpm package and GitHub release artifacts

🎯 Security Commitment

At Hack23 AB, we are committed to maintaining the highest standards of security in all our projects. The European Parliament MCP Server implements comprehensive security measures aligned with our Information Security Management System (ISMS), providing verifiable transparency and demonstrating security excellence for sensitive European Parliament data access.

🌍 European Parliament Context

This MCP server provides access to European Parliament datasets, including:

  • Parliamentary proceedings - Legislative activities, debates, votes
  • Member information - MEP profiles, committee memberships
  • Legislative documents - Proposals, amendments, reports
  • Historical data - Archive access to parliamentary records

As such, this server implements enhanced security controls to ensure:

  • 🔒 GDPR Compliance - Personal data protection for MEP information
  • 🇪🇺 EU Data Sovereignty - Appropriate handling of EU institutional data
  • 🔐 Data Integrity - Immutable audit trails for all API access
  • 📊 Transparency - Public accountability for institutional data access

📋 ISMS Policy Framework

All security practices in this repository are governed by our publicly available ISMS policies:

🔐 Core Security Policies

PolicyPurposeLink
🔐 Information Security PolicyOverarching security governance and principlesView Policy
🛠️ Secure Development PolicySDLC, testing, deployment, and CI/CD requirementsView Policy
📦 Open Source PolicyOpen source usage, license compliance, supply chain securityView Policy
🏷️ Data Classification PolicyData sensitivity levels, handling requirementsView Policy
🔒 Privacy PolicyPersonal data protection, GDPR complianceView Policy
🔑 Access Control PolicyAuthentication, authorization, identity managementView Policy
🧪 E2E Test PlanEnd-to-end test strategy and coverage matrixE2ETestPlan.md
🧪 Unit Test PlanUnit test plan and coverage targetsdocs/UnitTestPlan.md

✅ Supported Versions

This project is under active development, and we provide security updates for the latest version only. Please ensure you're using the latest version of the project to receive security updates.

VersionSupportedNode.js Compatibility
latest:white_check_mark:Node.js 26.x

🛡️ Security Features & Evidence

This MCP server implements comprehensive security measures aligned with our Secure Development Policy and Open Source Policy:

🔍 Static & Dynamic Analysis

  • 🛡️ Static Analysis (SAST) - CodeQL scanning for vulnerabilities

  • 🕷️ Dynamic Analysis (DAST) - OWASP ZAP security testing

  • 📋 Code Quality - ESLint with TypeScript rules

📦 Supply Chain Security

🔏 Build Integrity & Attestations

  • 🔐 SLSA Provenance - Build attestations for artifact verification

  • 🛡️ Immutable Releases - Release artifacts cannot be tampered with

  • 🔏 Artifact Signing - Cryptographic proof of build integrity

  • 📦 npm Provenance - Build transparency for npm packages

    • Policy: Open Source Policy
    • Package: european-parliament-mcp-server
    • Verification: npm audit signatures
    • Documentation: NPM_PUBLISHING.md
    • Features:
      • ✅ Cryptographic provenance for every published version
      • ✅ Transparent build process via GitHub Actions
      • ✅ SLSA Level 3 compliance for npm packages
      • ✅ Verifiable with npm audit signatures
    • Algorithm: SHA-256 cryptographic hashing

🧪 Testing & Quality Assurance

  • ✅ Unit Testing - Comprehensive test coverage

    • Policy: Secure Development Policy
    • Minimum Coverage: 80% line coverage, 70% branch coverage
    • Framework: Jest, Vitest, or Node.js test runner

  • 🌐 Integration Testing - API endpoint testing

    • Policy: Secure Development Policy
    • Focus: MCP protocol compliance, European Parliament API integration
    • Tools: Supertest, API testing frameworks

  • 🧪 End-to-End Testing - Full server binary over stdio transport

    • Policy: Secure Development Policy
    • Coverage: 71 E2E test cases across 4 test files; see E2ETestPlan.md
    • Validates: OWASP LLM Top 10 (2025) mitigations and MCP-protocol threat controls (M-1 … M-7)

  • 🔒 Security Testing - Dedicated security test suites

    • Authentication/authorization tests
    • Input validation and sanitization tests
    • Rate limiting and DoS protection tests
    • GDPR compliance tests (data minimization, right to erasure)

🔐 API Security Controls

  • 🔒 Rate Limiting - Protection against abuse and DoS attacks

    • Policy: Information Security Policy
    • Implementation: Express rate-limit or similar middleware
    • Thresholds: Configurable per-endpoint limits

  • 🛡️ Input Validation - Comprehensive request validation

    • Policy: Secure Development Policy
    • Tools: Joi, Yup, or Zod schema validation
    • Protection: SQL injection, XSS, command injection prevention

  • 🔐 Authentication & Authorization - MCP protocol security

    • Policy: Access Control Policy
    • Implementation: OAuth2/OIDC support for client authentication
    • Principle: Least privilege access to European Parliament data

  • 📝 Audit Logging - Comprehensive API access logging

    • Policy: Information Security Policy
    • Coverage: All API requests, authentication events, errors
    • Retention: Compliant with EU data retention requirements

🔐 Security Infrastructure

  • 🔒 Runner Hardening - All CI/CD runners hardened with audit logging

  • 🚨 Security Advisories - Private vulnerability disclosure

👥 Secure Development Environment

🇪🇺 GDPR & European Data Protection

  • 🔐 Data Minimization - Only collect necessary European Parliament data

    • Policy: Privacy Policy
    • Implementation: API endpoints filter unnecessary personal data

  • 🗑️ Right to Erasure - Support for data deletion requests

    • Policy: Privacy Policy
    • Process: AuditLogger.eraseByUser(userId, authToken) removes all in-memory entries for a data subject (GDPR Art. 17). Entries flushed to durable sinks must be erased separately via those sinks.

  • 🔒 Data Protection by Design - Privacy-enhancing technologies

    • Policy: Privacy Policy
    • Implementation: Encryption at rest and in transit, anonymization where applicable

  • 📋 GDPR Compliance Documentation

    • Data Protection Impact Assessment (DPIA) for high-risk processing
    • Records of processing activities (ROPA)
    • Data breach notification procedures

📝 Audit Logging (src/utils/auditLogger.ts + src/utils/auditSink.ts)

ISMS Policy AU-002 (Audit Logging and Monitoring) — all MCP tool invocations and EP API data-access events are recorded in a structured, GDPR-compliant audit trail.

Architecture

ComponentDescription
AuditLoggerCentral logger; writes to an always-on MemoryAuditSink plus zero or more extra sinks
MemoryAuditSinkIn-process buffer; supports query(filter) and eraseByUser(userId)
StderrAuditSinkDefault extra sink; emits [AUDIT] <json> to stderr (MCP-compatible)
FileAuditSinkAppends NDJSON to a file; rotates when the file reaches maxSizeBytes
StructuredJsonSinkPasses serialised JSON to a caller-supplied writer (CloudWatch, Elastic, …)
RetentionPolicyFilters entries older than maxAgeMs on every getLogs() / queryLogs() call

Security Controls

ControlMechanism
PII ProtectionsanitizeParams() redacts top-level keys in DEFAULT_SENSITIVE_KEYS (name, email, fullName, address, firstName, lastName, phone) before any entry is stored
Access ControlrequiredAuthToken constructor option gates getLogs(), queryLogs(), eraseByUser(), and clear() behind an authorization token; unauthorized calls throw immediately
Data RetentionretentionMs constructor option enforces a configurable maximum age; expired entries are excluded from all query results
Right to ErasureeraseByUser(userId, authToken) removes all in-memory entries for a given data subject (GDPR Art. 17)
Append-only sinksFileAuditSink appends using async fs.appendFile (append-only writes); MemoryAuditSink.clear() is publicly exposed but is intended to be used via AuditLogger.clear(), which enforces authorization via checkAuthorization
No stdout pollutionAll sinks write to stderr or external systems; stdout is reserved for the MCP protocol

Configuration Example

import { AuditLogger, FileAuditSink } from 'european-parliament-mcp-server';

const requiredAuthToken = process.env['AUDIT_READ_TOKEN'];

if (!requiredAuthToken) {
  throw new Error('AUDIT_READ_TOKEN environment variable must be set to enable secure audit log access.');
}

const logger = new AuditLogger({
  // Persist to file with automatic log rotation at 50 MiB
  sinks: [new FileAuditSink({ filePath: '/var/log/ep-mcp-audit.ndjson', maxSizeBytes: 50 * 1024 * 1024 })],
  // Enforce 90-day data retention (GDPR Art. 5(1)(e))
  retentionMs: 90 * 24 * 60 * 60 * 1000,
  // Require an auth token to read or erase audit logs
  requiredAuthToken,
  // Extend the default set of redacted keys
  sensitiveKeys: ['name', 'email', 'fullName', 'address', 'mepPrivateEmail'],
});

Test Coverage

The audit logging subsystem is security-critical and maintains 100% statement, branch, function, and line coverage (src/utils/auditLogger.ts and src/utils/auditSink.ts).

🚨 Reporting a Vulnerability

We take the security of the European Parliament MCP Server project seriously. If you have found a potential security vulnerability, we kindly ask you to report it privately, so that we can assess and address the issue before it becomes publicly known.

Our vulnerability management process is governed by our Information Security Policy and follows industry best practices for responsible disclosure.

🔍 What Constitutes a Vulnerability

A vulnerability is a weakness or flaw in the project that can be exploited to compromise the security, integrity, or availability of the system or its data. Examples of vulnerabilities include, but are not limited to:

  • 🔓 Unauthenticated access to sensitive European Parliament data
  • 💉 Injection attacks (SQL injection, NoSQL injection, command injection)
  • 🔐 Authentication/authorization bypass in MCP protocol implementation
  • 🌐 API security issues (rate limit bypass, parameter manipulation)
  • 🔒 Cryptographic weaknesses (weak algorithms, improper key management)
  • 📊 GDPR violations (unauthorized data exposure, insufficient data protection)
  • ⚡ Denial of service vulnerabilities in API endpoints
  • 🔗 Supply chain attacks through compromised dependencies

🛡️ How to Privately Report a Vulnerability using GitHub

Please follow these steps to privately report a security vulnerability:

  1. On GitHub.com, navigate to the main page of the European-Parliament-MCP-Server repository.
  2. Under the repository name, click Security. If you cannot see the "Security" tab, select the dropdown menu, and then click Security.
  3. In the left sidebar, under "Reporting", click Advisories.
  4. Click Report a vulnerability to open the advisory form.
  5. Fill in the advisory details form. Provide as much information as possible to help us understand and reproduce the issue:
    • Title: Brief description of the vulnerability
    • Description: Detailed explanation including:
      • Affected components (API endpoints, authentication, etc.)
      • Steps to reproduce
      • Potential impact (especially GDPR/data protection concerns)
      • Suggested mitigation (if any)
    • Severity: Your assessment of the vulnerability severity
    • CVE ID: If already assigned
  6. At the bottom of the form, click Submit report.

After you submit the report, the maintainers of the European-Parliament-MCP-Server repository will be notified. They will review the report, validate the vulnerability, and take necessary actions to address the issue. You will be added as a collaborator and credited for the security advisory.

⏱️ Disclosure Timeline

Upon receipt of a vulnerability report, our team will:

  1. Acknowledge the report within 48 hours
  2. Validate the vulnerability within 7 days
  3. Assess GDPR/data protection implications within 7 days
  4. Develop and release a patch or mitigation within 30 days, depending on the complexity and severity of the issue
  5. Publish a security advisory with a detailed description of the vulnerability and the fix
  6. Notify affected users if there is a potential data breach (as required by GDPR)

🏆 Recognition and Anonymity

We appreciate your effort in helping us maintain a secure and reliable project. If your report results in a confirmed security fix, we will recognize your contribution in the release notes and/or a public acknowledgment, unless you request to remain anonymous.

Internal Documentation

ISMS-PUBLIC Policies

All security practices are governed by our publicly available ISMS:

European Parliament Data Protection

📋 Document Control:
✅ Approved by: James Pether Sörling, CEO
📤 Distribution: Public
🏷️ Classification: Confidentiality: Public
📅 Effective Date: 2026-02-26
⏰ Next Review: 2026-05-26
🎯 Framework Compliance: ISO 27001 NIST CSF 2.0 CIS Controls AWS Well-Architected GDPR Compliant

Thank you for helping us keep the European Parliament MCP Server and its users safe.

Part of Hack23 AB's commitment to transparency and security excellence

🔌 MCP-Specific Security

Tool Invocation Security

Input Validation: All tool parameters validated with Zod schemas

  • Country codes: ISO 3166-1 alpha-2 format
  • Dates: YYYY-MM-DD format
  • Keywords: Alphanumeric + spaces/hyphens only

Rate Limiting: 100 requests per 15 minutes per IP address

Output Sanitization: Error messages sanitized to prevent information disclosure

Threat Model

Threats Addressed:

  • ✅ Injection attacks → Zod validation
  • ✅ DoS attacks → Rate limiting
  • ✅ Data exfiltration → Audit logging
  • ✅ Information disclosure → Error sanitization

🔒 Complete security architecture →

MCP Security Checklist

  • Input validation (Zod schemas)
  • Rate limiting (Token bucket)
  • Audit logging (All requests)
  • Error sanitization
  • HTTPS only
  • No secrets in code
  • GDPR compliance

📋 Complete security guide →