π‘οΈ Security Through Transparency and Excellence
π― Security-first API development with verifiable compliance
π Document Owner: CEO | π Version: 1.0 | π
Last Updated: 2026-02-26 (UTC)
π Review Cycle: Quarterly | β° Next Review: 2026-05-26
Current security state as of 2026-02-26:
| Metric | Status | Value |
|---|---|---|
| π§ͺ Test Suite | β Passing | 1396 tests across 54 test files (docs/test-results/results.json) |
| π npm audit | β Clean | 0 vulnerabilities |
| π License compliance | β Passing | All MIT/ISC/Apache-2.0 |
| ποΈ SLSA Level 3 | β Achieved | Cryptographic provenance on all releases |
| π SAST (CodeQL) | β Enabled | Automated on every PR and push |
| π Secret scanning | β Enabled | GitHub native secret detection |
| π¦ SBOM | β Published | SPDX + CycloneDX on every release |
| π Sigstore | β Enabled | npm package and GitHub release artifacts |
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.
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
All security practices in this repository are governed by our publicly available ISMS policies:
| Policy | Purpose | Link |
|---|---|---|
| π Information Security Policy | Overarching security governance and principles | View Policy |
| π οΈ Secure Development Policy | SDLC, testing, deployment, and CI/CD requirements | View Policy |
| π¦ Open Source Policy | Open source usage, license compliance, supply chain security | View Policy |
| π·οΈ Data Classification Policy | Data sensitivity levels, handling requirements | View Policy |
| π Privacy Policy | Personal data protection, GDPR compliance | View Policy |
| π Access Control Policy | Authentication, authorization, identity management | View Policy |
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.
| Version | Supported | Node.js Compatibility |
|---|---|---|
| latest | β | Node.js 25.x |
This MCP server implements comprehensive security measures aligned with our Secure Development Policy and Open Source Policy:
-
π‘οΈ Static Analysis (SAST) - CodeQL scanning for vulnerabilities
- Policy: Secure Development Policy
- Implementation: CodeQL Workflow (if present)
- Focus: Node.js/TypeScript security patterns, API vulnerabilities
-
π·οΈ Dynamic Analysis (DAST) - OWASP ZAP security testing
- Policy: Secure Development Policy
- Implementation: ZAP Workflow (if present)
- Focus: API endpoint security, injection attacks
-
π Code Quality - ESLint with TypeScript rules
- Policy: Secure Development Policy
- Standards: TypeScript strict mode, security-focused linting rules
-
π OSSF Scorecard - Supply chain security assessment
- Policy: Open Source Policy
- Badge:
-
π Dependency Review - Automated dependency vulnerability checks
- Policy: Open Source Policy
- Implementation: Dependency Review Workflow
- Tools: GitHub Dependabot, npm audit
-
π License Compliance - Automated license checking
- Policy: Open Source Policy
- Approved Licenses: MIT, Apache-2.0, BSD variants, ISC, CC0-1.0, Unlicense
-
π SBOM Generation - Software Bill of Materials in SPDX format
- Policy: Open Source Policy
- Implementation: SBOM Generation Workflow
- Documentation: SBOM.md
- Location: Included in every release
- Format: SPDX 2.3+ JSON
-
π SBOM Quality Validation - Automated quality scoring with SBOMQS
- Policy: Secure Development Policy
- Implementation: SBOM Generation Workflow
- Minimum Score: 7.0/10
- Standards: NTIA-minimum-elements, BSI v1.1/v2.0
-
π·οΈ Pinned Dependencies - All GitHub Actions pinned to SHA hashes
- Policy: Secure Development Policy
- Implementation: All
.github/workflows/*.ymlfiles
-
π SLSA Provenance - Build attestations for artifact verification
- Policy: Secure Development Policy
- Verification:
gh attestation verify <artifact> --owner Hack23 --repo European-Parliament-MCP-Server - Level: SLSA Level 3+ compliant
- Documentation: ATTESTATIONS.md
-
π‘οΈ Immutable Releases - Release artifacts cannot be tampered with
- Policy: Data Classification Policy
- Implementation: GitHub release immutability enabled
-
π Artifact Signing - Cryptographic proof of build integrity
- Policy: Secure Development Policy
- Format: In-toto attestations in JSONL format
-
π¦ 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
-
β 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
-
π 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)
-
π 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
-
π Runner Hardening - All CI/CD runners hardened with audit logging
- Policy: Secure Development Policy
- Implementation: Step Security hardening in all workflows
-
π¨ Security Advisories - Private vulnerability disclosure
- Policy: Information Security Policy
- Process: GitHub Security Advisories (see below)
-
π GitHub Codespaces - Secure, hardened development environment
- Policy: Secure Development Policy + Access Control Policy
- Configuration: .devcontainer (if present)
-
π€ GitHub Copilot - AI-assisted development with security guidelines
- Policy: Secure Development Policy
- Agents: .github/agents/
- Skills: .github/skills/
-
π 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
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.
| Component | Description |
|---|---|
AuditLogger |
Central logger; writes to an always-on MemoryAuditSink plus zero or more extra sinks |
MemoryAuditSink |
In-process buffer; supports query(filter) and eraseByUser(userId) |
StderrAuditSink |
Default extra sink; emits [AUDIT] <json> to stderr (MCP-compatible) |
FileAuditSink |
Appends NDJSON to a file; rotates when the file reaches maxSizeBytes |
StructuredJsonSink |
Passes serialised JSON to a caller-supplied writer (CloudWatch, Elastic, β¦) |
RetentionPolicy |
Filters entries older than maxAgeMs on every getLogs() / queryLogs() call |
| Control | Mechanism |
|---|---|
| PII Protection | sanitizeParams() redacts top-level keys in DEFAULT_SENSITIVE_KEYS (name, email, fullName, address, firstName, lastName, phone) before any entry is stored |
| Access Control | requiredAuthToken constructor option gates getLogs(), queryLogs(), eraseByUser(), and clear() behind an authorization token; unauthorized calls throw immediately |
| Data Retention | retentionMs constructor option enforces a configurable maximum age; expired entries are excluded from all query results |
| Right to Erasure | eraseByUser(userId, authToken) removes all in-memory entries for a given data subject (GDPR Art. 17) |
| Append-only sinks | FileAuditSink 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 pollution | All sinks write to stderr or external systems; stdout is reserved for the MCP protocol |
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'],
});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).
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.
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
Please follow these steps to privately report a security vulnerability:
- On GitHub.com, navigate to the main page of the European-Parliament-MCP-Server repository.
- Under the repository name, click Security. If you cannot see the "Security" tab, select the dropdown menu, and then click Security.
- In the left sidebar, under "Reporting", click Advisories.
- Click Report a vulnerability to open the advisory form.
- 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
- 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.
Upon receipt of a vulnerability report, our team will:
- Acknowledge the report within 48 hours
- Validate the vulnerability within 7 days
- Assess GDPR/data protection implications within 7 days
- Develop and release a patch or mitigation within 30 days, depending on the complexity and severity of the issue
- Publish a security advisory with a detailed description of the vulnerability and the fix
- Notify affected users if there is a potential data breach (as required by GDPR)
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.
- π‘οΈ Security Headers - Security headers implementation for API responses
- π README.md - Project overview with security features
- π€ Copilot Agents - AI-assisted secure development
- π― Copilot Skills - Specialized security and compliance skills
All security practices are governed by our publicly available ISMS:
- π Information Security Policy - Overall security governance
- π οΈ Secure Development Policy - SDLC and CI/CD requirements
- π¦ Open Source Policy - Supply chain security
- π·οΈ Data Classification Policy - Data handling requirements
- π Privacy Policy - Privacy and GDPR compliance
- π Access Control Policy - Authentication and authorization
- π Vulnerability Management - Security vulnerability handling
- π·οΈ Classification Framework - CIA triad and impact levels
- πͺπΊ GDPR - Regulation (EU) 2016/679
- ποΈ EP Data Protection - European Parliament data protection rules
- π ePrivacy Directive - Directive 2002/58/EC
- π Information Security Policy - Overall security governance
- π οΈ Secure Development Policy - SDLC and CI/CD requirements
- π¦ Open Source Policy - Supply chain security
- π·οΈ Data Classification Policy - Data handling requirements
- π Privacy Policy - Privacy and GDPR compliance
- π Access Control Policy - Authentication and authorization
- π Vulnerability Management - Security vulnerability handling
- π·οΈ Classification Framework - CIA triad and impact levels
- π‘οΈ CRA Conformity Assessment - EU Cyber Resilience Act compliance
- π‘οΈ CRA Conformity Assessment Process - CRA assessment template
π Document Control:
β
Approved by: James Pether SΓΆrling, CEO
π€ Distribution: Public
π·οΈ Classification:
π
Effective Date: 2026-02-26
β° Next Review: 2026-05-26
π― Framework Compliance:
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
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
Threats Addressed:
- β Injection attacks β Zod validation
- β DoS attacks β Rate limiting
- β Data exfiltration β Audit logging
- β Information disclosure β Error sanitization
π Complete security architecture β
- Input validation (Zod schemas)
- Rate limiting (Token bucket)
- Audit logging (All requests)
- Error sanitization
- HTTPS only
- No secrets in code
- GDPR compliance