🛡️ Riksdagsmonitor — Security Architecture

🔐 Defense-in-Depth Protection for Swedish Parliament Transparency
🎯 Comprehensive Security Framework for Political Intelligence Platform

📋 Document Owner: CEO | 📄 Version: 2.5 | 📅 Last Updated: 2026-06-02 (UTC)
🔄 Review Cycle: Annual | ⏰ Next Review: 2027-06-02
🏢 Owner: Hack23 AB (Org.nr 5595347807) | 🏷️ Classification: Public

📚 Related Architecture Documentation

Hack23 ISMS Policy References

📋 Table of Contents

• 🎯 Executive Summary
• 🔐 ISMS Policy Alignment
• 1. 🏗️ System Overview
  • 1.1 🎯 Purpose and Scope
  • 1.2 🔐 AWS Security Controls
  • 1.3 Architecture Diagram
• 2. 🔐 Security Architecture Components
  • 2.1 Authentication & Access Control
  • 2.2 Authorization Model
  • 2.3 Data Security
  • 2.4 Network Security
  • 2.5 Application Security
  • 2.6 Monitoring & Logging
  • 2.7 Incident Response
  • 2.8 Release Security & Supply Chain Protection
• 3. 📋 Compliance Mapping
  • 3.1 ISO 27001:2022 Controls
  • 3.2 NIST CSF 2.0 Categories
  • 3.3 CIS Controls v8.1
• 4. 🛡️ Security Controls Summary
  • 4.1 Preventive Controls
  • 4.2 Detective Controls
  • 4.3 Corrective Controls
• 5. 📝 Security Assumptions and Constraints
  • 5.1 Assumptions
  • 5.2 Constraints
• 6. ⚠️ Risk Assessment
  • 6.1 Residual Risks
  • 6.2 Accepted Risks
• 7. 🏛️ Security Governance
  • 7.1 Roles and Responsibilities
  • 7.2 Review and Update Schedule
  • 7.3 Related Documentation
• 8. ✅ Approval
• 🛡️ Defense-in-Depth Strategy
• 📜 Data Integrity & Auditing
• 🔍 Security Event Monitoring
• 🏗️ High Availability Design
• 🕵️ Threat Detection & Investigation
• 🔎 Vulnerability Management
• 🤖 Automated Security Operations
• ⚡ Resilience & Operational Readiness
• 📋 Configuration & Compliance Management
• 📊 Monitoring & Analytics
• 🔄 Security Operations
• 💰 Security Investment
• 🕵️ Political Intelligence Security Surface
• 🏗️ gh-aw Platform Security Architecture (Three-Layer Model)
• 🔐 Five-Layer Safe-Output Security Model (Detailed)
• 🌐 External Data Provider Trust Model
• 📝 Conclusion
• 📋 Document Control

🎯 Executive Summary

Riksdagsmonitor is a web platform providing Swedish Parliament intelligence and election monitoring capabilities. This document outlines the security architecture aligned with Hack23 AB's Information Security Management System (ISMS), Classification Framework, and compliance frameworks (ISO 27001, NIST CSF 2.0, CIS Controls v8.1).

Security Posture: Defense-in-depth architecture with dual-deployment (AWS CloudFront/S3 multi-region primary, GitHub Pages disaster recovery), HTTPS-only access, comprehensive CI/CD security controls, and SLSA Build Provenance attestations.

For complete CI/CD workflow documentation, see WORKFLOWS.md.

🔐 ISMS Policy Alignment

Riksdagsmonitor security architecture is governed by and aligned with Hack23 AB's comprehensive Information Security Management System (ISMS). This ensures consistent security practices across all organizational assets.

📜 Governing Policies

🎯 Policy Compliance Summary

• ✅ Security Documentation: Complete (SECURITY_ARCHITECTURE.md, THREAT_MODEL.md, FUTURE_SECURITY_ARCHITECTURE.md)
• ✅ Code Scanning: CodeQL, Dependabot, Secret Scanning enabled
• ✅ Access Controls: MFA enforced, SSH keys, GPG signing mandatory
• ✅ Vulnerability Management: SLAs defined (Critical: 24h, High: 7d, Medium: 30d, Low: 90d)
• ✅ Incident Response: Documented procedures with escalation to CISO
• ✅ Data Classification: Information classification scheme applied (§2.3)
• ✅ Compliance Frameworks: ISO 27001:2022, NIST CSF 2.0, CIS Controls v8.1 mapped (§3)

Policy Review Cycle: All referenced policies reviewed annually by CISO. Next ISMS policy review: 2027-01-31.

1. 🏗️ System Overview

1.1 🎯 Purpose and Scope

Purpose:

• Monitor Swedish Riksdag political activity
• Provide real-time intelligence on 349 MPs
• Track coalition stability and election predictions
• Deliver functional CIA-platform dashboards: committee, coalition, election-cycle, risk, anomaly detection, party, seasonal, pre-election, ministry, and politician analyses
• OSINT-powered political transparency

Scope:

• Web application with HTML/CSS/JavaScript (Chart.js, D3.js)
• Functional dashboards bundled by Vite into hashed ES modules, lazy-loaded via IntersectionObserver (Chart.js, D3.js)
• Multi-language support (14 languages)
• CIA data integration with local CSV caching
• AWS CloudFront + S3 hosting infrastructure (Primary)
• GitHub Pages hosting infrastructure (Disaster Recovery)
• AWS Route 53 DNS with health checks and automatic failover

1.2 🔐 AWS Security Controls

AWS Infrastructure Security (Primary Deployment):

• 🔑 Authentication & Access Control:

  • GitHub Actions OIDC integration for AWS authentication (ephemeral credentials)
  • No long-lived AWS access keys or IAM user credentials stored
  • Least-privilege IAM roles with time-limited session tokens
  • S3 bucket policies restrict access to CloudFront Origin Access Identity only

• 📊 Audit Logging & Monitoring:

  • AWS CloudTrail enabled for all API activity logging
  • 90-day log retention in dedicated S3 audit bucket
  • CloudWatch metrics for S3, CloudFront, and Route 53
  • Real-time alerting on security events and anomalies

• 🔒 Data Protection:

  • S3 server-side encryption at rest (AES-256)
  • S3 bucket versioning enabled for rollback capability
  • Cross-region replication (typically within minutes) (us-east-1 → eu-west-1)
  • TLS 1.3 encryption in transit via CloudFront

• 🛡️ DDoS & Threat Protection:

  • AWS Shield Standard (automatic DDoS protection)
  • CloudFront geographic restrictions capability
  • Planned request rate limiting via AWS WAF rate-based rules associated with CloudFront
  • AWS Web Application Firewall (WAF) planned for advanced application-layer threat protection and rate limiting

1.3 Architecture Diagram

graph TB
    User[User Browser]
    Route53[AWS Route 53<br/>DNS + Health Checks]
    
    subgraph "Primary: AWS Infrastructure"
        CF[CloudFront CDN<br/>600+ Edge Locations]
        S3US[S3 Bucket us-east-1<br/>Primary Storage + Versioning]
        S3EU[S3 Bucket eu-west-1<br/>Cross-region Replica<br/>Active Failover Origin]
    end
    
    subgraph "Disaster Recovery: GitHub"
        GHCDN[GitHub Pages CDN<br/>Standby Deployment]
    end
    
    subgraph "GitHub Infrastructure"
        GitHubRepo[GitHub Repository<br/>main branch]
        Actions[GitHub Actions<br/>CI/CD Dual Deploy]
        Security[Security Scanning<br/>Dependabot, CodeQL, Secrets]
    end
    
    CIA[CIA Platform<br/>www.hack23.com/cia]
    
    User -->|DNS Query| Route53
    Route53 -->|DNS Response: CloudFront Primary| User
    Route53 -.->|DNS Response: GitHub Pages on Failover| User
    User -->|HTTPS Only TLS 1.3| CF
    User -.->|HTTPS Only TLS 1.3 (DR)| GHCDN
    
    CF -->|Cache Miss| S3US
    CF -.->|Origin Failover on 5xx errors| S3EU
    S3US -->|Async Cross-Region Replication (&lt;15 min RPO)| S3EU
    
    User -->|External Links| CIA
    
    GHCDN --> GitHubRepo
    Actions -->|Deploy| S3US
    Actions -->|Deploy| GitHubRepo
    Security -->|Monitor| GitHubRepo
    
    style User fill:#e1f5ff,color:#000000
    style Route53 fill:#ff9800,color:#000000
    style CF fill:#4caf50,color:#000000
    style S3US fill:#2196f3,color:#ffffff
    style GHCDN fill:#90caf9,color:#000000
    style Actions fill:#ff9800,color:#000000
    style Security fill:#f44336,color:#ffffff
    style CIA fill:#9c27b0,color:#ffffff
Copy

2. 🔐 Security Architecture Components

2.1 Authentication & Access Control

Public Access Model:

• No Authentication Required: Static public website accessible to all
• Content Management: GitHub repository access controlled via GitHub authentication
  • MFA required for all contributors
  • SSH keys with passphrase protection
  • GPG signing required for commits
  • Branch protection rules enforced

Control Mapping:

• ISO 27001: A.9.2 User Access Management
• NIST CSF 2.0: PR.AC-1 (Identities and credentials managed)
• CIS Controls v8.1: 5.1 (Establish and Maintain an Inventory of Accounts)

2.2 Authorization Model

GitHub Repository Permissions:

• Admin: Repository owners (Hack23 organization owners)
• Write: Approved contributors with MFA
• Read: Public access (website viewing)

CI/CD Pipeline Permissions:

• Least privilege GitHub Actions permissions
• Scoped GITHUB_TOKEN for workflow operations
• Secrets management via GitHub Secrets

Control Mapping:

• ISO 27001: A.9.4 System and Application Access Control
• NIST CSF 2.0: PR.AC-4 (Access permissions managed)
• CIS Controls v8.1: 6.8 (Define and Maintain Role-Based Access Control)

2.3 Data Security

Information Classification:

Following Hack23 AB ISMS information classification policy:

Data Inventory:

• Public Data:
  • 14-language website (HTML/CSS)
  • Swedish Parliament data (349 MPs, 50+ years)
  • Election statistics, voting records
  • Government budget data
  • All source code and documentation
• Internal Data:
  • GitHub repository and Actions access tokens (if used, e.g., optional PATs for local tooling)
  • AWS IAM credentials (ephemeral via OIDC)
  • GitHub Actions workflow secrets
• No Sensitive End-User Data:
  • ❌ No end-user accounts or authentication features
  • ❌ No collection of non-public personal data from site users
  • ⚠️ Public personal data about Swedish public officials (e.g., names, person identifiers, roles) from Riksdag open data and cia-data datasets
    • Information classification: 🟢 Public (openly available data)
    • Privacy classification: Personal data – public-official (GDPR/PII handling still applies despite public availability)

Data Protection Controls:

In Transit:

• TLS 1.3 encryption (AWS CloudFront + GitHub Pages)
• HTTPS-only access enforced
• HSTS headers configured (max-age=31536000)
• Certificate transparency monitoring

At Rest:

• AWS S3 server-side encryption (AES-256)
• GitHub repository encryption at rest
• GitHub Secrets encryption (Libsodium sealed boxes)
• Immutable Git history for audit trail
• S3 versioning enabled for rollback capability

Access Controls:

• Public data: No authentication (intentionally public)
• Internal data: GitHub MFA, SSH keys, GPG signing
• AWS credentials: Ephemeral OIDC tokens only (no long-lived keys)
• Least privilege IAM roles

Data Lifecycle:

• Creation: Git commits with GPG signing
• Storage: GitHub + AWS S3 with versioning
• Access: TLS 1.3 encrypted channels only
• Retention: Indefinite (public data), 90 days (AWS CloudTrail logs)
• Deletion: Git history retained, S3 versioning for recovery

Control Mapping:

• ISO 27001: A.5.10 (Acceptable use - data classification), A.10.1 (Cryptographic controls)
• NIST CSF 2.0: PR.DS-1 (Data-at-rest protected), PR.DS-2 (Data-in-transit protected)
• CIS Controls v8.1: 3.1 (Establish data management), 3.10 (Encrypt data in transit)

2.4 Network Security

AWS CloudFront Infrastructure (Primary):

• DDoS Protection: AWS Shield Standard (automatic protection)
• CDN: 600+ global edge locations
• WAF: Available for application-layer protection (roadmap: 2027 Q2)
• TLS: CloudFront managed certificates with TLS 1.3
• Firewall: AWS infrastructure-level protection

GitHub Pages Infrastructure (Disaster Recovery):

• DDoS Protection: GitHub infrastructure-level protection
• CDN: GitHub Pages CDN for global distribution
• Firewall: GitHub-managed infrastructure firewall

Security Headers (Target Configuration - AWS CloudFront Response Headers Policy):

Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline' fonts.googleapis.com; font-src 'self' fonts.gstatic.com; img-src 'self' data: https:; connect-src 'self' https://raw.githubusercontent.com
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
X-XSS-Protection: 1; mode=block
Strict-Transport-Security: max-age=31536000; includeSubDomains
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: geolocation=(), microphone=(), camera=()
Copy

Note: CSP style-src includes 'unsafe-inline' for Chart.js/D3.js inline styles; script-src uses 'self' plus per-script sha256 hashes for the small bootstrap snippets (no 'unsafe-inline' for scripts). The connect-src directive includes https://raw.githubusercontent.com to allow fetching CIA CSV data from the cia repository. Security headers are configured via AWS CloudFront Response Headers Policy for the primary deployment. GitHub Pages disaster recovery inherits default GitHub Pages security headers. Chart.js, D3.js, chartjs-plugin-annotation and Mermaid are hosted locally on CloudFront (js/lib/) rather than via external CDN, eliminating external script dependencies (CI-enforced by tests/no-external-cdn.test.ts).

Control Mapping:

• ISO 27001: A.13.1 Network Security Management
• NIST CSF 2.0: PR.AC-5 (Network integrity protected)
• CIS Controls v8.1: 13.1 (Centralize Security Event Alerting)

2.5 Application Security

Web Application Security:

• Client-Side JavaScript: Chart.js and D3.js for interactive dashboards
  • All dashboards are functional TypeScript modules under src/browser/dashboards/, bundled by Vite into hashed ES modules and lazy-loaded on demand via an IntersectionObserver — each module's import() fires only when its container scrolls into view
  • The homepage (src/browser/main.ts) registers 11 specialised dashboards; the CIA Intelligence Dashboard page (dashboard/index*.html) is orchestrated by src/browser/cia/dashboard-init.ts
  • No inline application scripts and no HTML-only placeholder sections remain — every dashboard section initialises real JavaScript
• XSS Mitigation: Content Security Policy (CSP) headers with script-src restrictions
• Input Sanitization: CIA CSV data is subjected to best-effort, non-blocking schema validation during CI/data-integration workflows (e.g., .github/workflows/validate-cia-data.yml); validation failures currently surface as warnings rather than blocking publication, and client-side code then parses this CSV (D3 CSV utilities/custom parsers) and applies basic sanity checks prior to rendering via Chart.js/D3.js
• External Dependencies:
  • Chart.js v4.4.1 (hosted locally on CloudFront/S3 at js/lib/chart.umd.4.4.1.js)
  • chartjs-plugin-annotation v3.0.1 (hosted locally on CloudFront/S3 at js/lib/chartjs-plugin-annotation.3.0.1.min.js)
  • chartjs-adapter-date-fns v3.0.0 bundle (hosted locally on CloudFront/S3 at js/lib/chartjs-adapter-date-fns.3.0.0.bundle.min.js) - for time-series charts
  • D3.js v7.9.0 (hosted locally on CloudFront/S3 at js/lib/d3.7.9.0.min.js)
  • Papa Parse v5.5.3 (hosted locally on CloudFront/S3 at js/lib/papaparse.5.5.3.min.js) - for CSV parsing
  • Google Fonts (Inter, Orbitron, Share Tech Mono - via fonts.googleapis.com and fonts.gstatic.com CDN)
• CIA Data Integration: Fetches CSV data from https://raw.githubusercontent.com/Hack23/cia/ that is subject to non-blocking CI schema validation checks in pre-processing (e.g., .github/workflows/validate-cia-data.yml), with local caching for performance; the browser consumes this dataset which may contain validation warnings
• No User Input Processing: Dashboards do not accept or process arbitrary user input; they display pre-processed CIA data generated upstream in CI/data pipelines that has passed non-blocking schema validation checks where configured
• No Server-Side Code: Static hosting eliminates injection vulnerabilities

Dashboard Security:

• Functional Dashboard Modules (all initialise Chart.js / D3.js):

1. Committee Dashboard (src/browser/dashboards/committees-dashboard.ts) ✅
2. Coalition Dashboard (src/browser/dashboards/coalition-dashboard.ts + coalition-loader.ts) ✅
3. Election Cycle Dashboard (src/browser/dashboards/election-cycle.ts) ✅
4. Risk Dashboard (src/browser/dashboards/risk-dashboard.ts) ✅
5. Anomaly Detection Dashboard (src/browser/dashboards/anomaly-detection.ts — standalone timeline, Z-score distribution, type, and quarterly-frequency charts) ✅
6. Party Performance Dashboard (src/browser/dashboards/party-dashboard.ts) ✅
7. Seasonal Patterns Dashboard (src/browser/dashboards/seasonal-patterns.ts) ✅
8. Pre-Election Monitoring Dashboard (src/browser/dashboards/pre-election.ts) ✅
9. Ministry Dashboard (src/browser/dashboards/ministry-dashboard.ts) ✅
10. Politician Dashboard (src/browser/dashboards/politician-dashboard.ts) ✅

Dependency Management:

• Chart.js, D3.js, chartjs-plugin-annotation, chartjs-adapter-date-fns, and Papa Parse hosted locally on CloudFront/S3 (js/lib/); versions reviewed manually at least quarterly and after critical CVE disclosures
• Library file integrity can be verified via SHA-256 hashes if needed for deployment validation (not required for runtime as served from same origin)
• Dependabot configured for GitHub Actions workflows (.github/dependabot.yml) and automated dependency risk assessment for repository-managed components via GitHub dependency-review and Dependabot alerts
• Supply chain security scanning via CodeQL and OpenSSF Scorecards

Control Mapping:

• ISO 27001: A.14.2 Security in Development and Support
• NIST CSF 2.0: PR.IP-12 (A vulnerability management plan developed)
• CIS Controls v8.1: 16.1 (Establish and Maintain a Secure Application Development Process)

2.5.1 News Pipeline Sanitisation Chain

The news-generation pipeline (scripts/aggregate-analysis.ts → scripts/render-articles.ts → scripts/render-lib/) produces HTML articles from AI-authored markdown artifacts under analysis/daily/$DATE/$SUB/. The AI-authored markdown is an untrusted input from the perspective of the renderer; the sanitisation chain is therefore a primary output-encoding control for the platform.

Sanitisation chain (input → output trust boundary)

analysis/daily/$DATE/$SUB/*.md          (untrusted AI authored markdown)
           │
           ▼
gray-matter frontmatter extraction       (structural only — no HTML)
           │
           ▼
unified + remark-parse + remark-gfm      (markdown → MDAST)
           │
           ▼
remark-rehype + rehype-raw               (MDAST → HAST; raw HTML islands preserved)
           │
           ▼
rehype-sanitize  ◄─── TRUST BOUNDARY     (allow-list enforcement)
           │
           ▼
rehype-slug + rehype-autolink-headings   (stable anchors for TOC)
           │
           ▼
rehype-stringify                         (HAST → serialised HTML)
           │
           ▼
scripts/render-lib/chrome.ts             (JSON-LD NewsArticle, SEO, lang switcher)
           │
           ▼
news/$DATE-$SUB-{en,sv}.html             (trusted output)
Copy

rehype-sanitize allow-list

The sanitiser is configured with an explicit allow-list (schema) rather than a blocklist. Only these elements and attributes survive the boundary:

URL-bearing attributes (href, src) are filtered to the following schemes: http:, https:, mailto:, plus data:image/{png,jpeg,gif,webp,svg+xml} for embedded images only. Rejected: javascript:, vbscript:, non-image data:, file:, chrome:, and all other URI schemes.

Explicitly rejected elements (removed without error so AI-authored content cannot escape the sandbox): script, iframe, object, embed, form, input, button, style, link, meta, base, applet, frame, frameset, and every on* event handler attribute.

Mermaid client-side rendering trust boundary

Mermaid diagrams are the only HTML extension permitted past the sanitiser. They are handled as follows:

1. Source — a ```mermaid fenced block in the .md artifact is passed through by remark-parse as a code node with lang: mermaid.
2. Transform — the renderer emits the node as <pre class="mermaid">…source…</pre> so the sanitiser's pre[class|lang] rule lets it through.
3. Accessibility wrapping — each Mermaid block is wrapped in <figure> with a <figcaption> and a <details>-wrapped plain-text fallback containing the source (WCAG 2.1 AA text equivalent).
4. Render-time — scripts/render-lib/chrome.ts conditionally injects <script type="module" src="/js/lib/mermaid-init.mjs"></script> only when at least one <pre class="mermaid"> survived sanitisation.
5. Runtime sandboxing — mermaid-init.mjs imports Mermaid via native ESM dynamic import() and calls mermaid.initialize({ startOnLoad: false, securityLevel: 'strict' }). securityLevel: 'strict' disables Mermaid's own click-handler and interaction features, so a malicious Mermaid diagram cannot execute JavaScript even if the DSL is exploited.
6. CSP — the global Content-Security-Policy forbids 'unsafe-eval'. Mermaid's strict-mode parser does not require eval; this has been validated and is documented in the deployment runbook.

The trust boundary is therefore: AI → markdown → Mermaid DSL → SVG — never AI → JavaScript.

GitHub-blob link rewriting (output-encoding control)

Relative markdown links inside aggregated artifacts (e.g. [methodology](../methodologies/devils-advocate.md)) would resolve against news/ in the published output and 404. The aggregator rewrites every relative .md, .json, and .html link to an absolute https://github.com/Hack23/riksdagsmonitor/blob/main/… URL before the sanitiser sees them. This is an output-encoding control: it removes a broken-link class and pins every citation to a content-addressable GitHub blob URL that serves as the provenance chain.

Provenance manifest (tamper detection)

The aggregator emits a .manifest.json sibling to each article.md listing every source artifact consumed, with a SHA-256 digest:

{
  "article": "analysis/daily/2026-04-24/propositions/article.md",
  "generated_at": "2026-04-24T04:12:31Z",
  "sources": [
    { "path": "analysis/daily/2026-04-24/propositions/executive-brief.md", "sha256": "…" },
    { "path": "analysis/daily/2026-04-24/propositions/synthesis.md",        "sha256": "…" },
    { "path": "analysis/methodologies/devils-advocate.md",                   "sha256": "…" }
  ]
}
Copy

The renderer emits the manifest contents into the NewsArticle.citation[] JSON-LD block, giving downstream consumers a cryptographic evidence chain: every claim in the HTML can be traced back to a specific SHA-256 of a specific markdown artifact at a specific timestamp.

Control Mapping:

• ISO 27001:2022 A.8.28 (Secure coding) — allow-list sanitisation, explicit trust boundary, output encoding
• ISO 27001:2022 A.8.25 (Secure development life cycle) — sanitiser schema is version-controlled and covered by dedicated unit tests
• NIST CSF 2.0 PR.DS-6 (Integrity checking mechanisms) — SHA-256 manifest; drift detection at render time
• NIST CSF 2.0 PR.PS-06 (Secure software development practices) — CI gate on sanitisation drops
• CIS Controls v8.1 16.10 (Apply Secure Design Principles in Application Architectures) — input validation and output encoding at every trust boundary
• CIS Controls v8.1 16.11 (Leverage Vetted Modules or Services) — unified/remark/rehype/gray-matter are vetted, pinned, and Dependabot-grouped

2.6 Monitoring & Logging

Security Monitoring:

• GitHub Security Features:
  • Dependabot alerts for dependency vulnerabilities
  • Secret scanning for exposed credentials
  • Code scanning (CodeQL) for security issues
  • Security advisories tracking

Audit Logging:

• Git Commit History: Immutable audit trail of all changes
• GitHub Actions Logs: CI/CD pipeline execution logs
• GitHub Audit Log: Organization-level access and change logs

Alert Mechanisms:

• GitHub Security Advisories
• Email notifications for security events
• Pull request checks for quality gates

Control Mapping:

• ISO 27001: A.12.4 Logging and Monitoring
• NIST CSF 2.0: DE.CM-1 (The network is monitored)
• CIS Controls v8.1: 8.2 (Collect Audit Logs)

2.7 Incident Response

Security Incident Procedures:

1. Detection: GitHub security alerts, Dependabot, manual reporting
2. Containment: Disable GitHub Pages, revert commits if needed
3. Investigation: Review Git history, GitHub Actions logs
4. Remediation: Apply security patches, update dependencies
5. Recovery: Re-deploy verified secure version
6. Lessons Learned: Update SECURITY_ARCHITECTURE.md and THREAT_MODEL.md

Incident Response Team:

• Security Lead: James Pether Sörling (CISSP, CISM)
• Repository Owners: Hack23 organization admins
• Escalation: Follow Hack23 ISMS Incident Response Plan

Control Mapping:

• ISO 27001: A.16.1 Management of Information Security Incidents
• NIST CSF 2.0: RS.CO-1 (Personnel know their roles and order of operations)
• CIS Controls v8.1: 17.1 (Designate Personnel to Manage Incident Handling)

2.8 Release Security & Supply Chain Protection

SLSA Build Provenance Attestations:

• Framework: SLSA (Supply Chain Levels for Software Artifacts) Level 2+
• Implementation: GitHub Actions Attestations (actions/attest-build-provenance@v3.2.0)
• Purpose: Cryptographically prove artifacts were built by trusted CI/CD pipeline
• Verification: gh attestation verify riksdagsmonitor-vX.Y.Z.zip -R Hack23/riksdagsmonitor
• Format: in-toto attestations (*.intoto.jsonl)

Software Bill of Materials (SBOM):

• Format: SPDX (Software Package Data Exchange)
• Generator: Anchore SBOM Action (anchore/sbom-action@v0.22.2)
• Contents: Complete dependency inventory with versions and licenses
• Attestation: SBOM also cryptographically signed (actions/attest-sbom@v3.0.0)
• Purpose: Vulnerability tracking, license compliance, supply chain transparency
• External MCP supplement: package.json x-external-mcp field records MCP servers outside the npm graph (Python, Docker, HTTP). It is currently empty — all economic-data clients (World Bank, SCB, IMF) ship as npm TypeScript (scripts/world-bank-client.ts, scripts/scb-client.ts, scripts/imf-client.ts) and are fully covered by the standard SPDX SBOM; see THREAT_MODEL.md TB-6a for the IMF client's threat model.

External Data Providers (parity across the three primary economic sources):

All three providers share: GitHub-runner root CA trust anchors, public-data classification, no API key, and optional-enrichment semantics (failure never blocks article generation or site availability).

Release Pipeline Security (3-job workflow):

1. Prepare Job (15-20min):

   • Run comprehensive test suite (unit + E2E)
   • Generate all documentation (API, coverage, E2E reports, dependencies)
   • Deploy docs to GitHub Pages
   • Security: Read-only permissions, harden-runner enabled

2. Build Job (5min):

   • Build production artifacts
   • Generate SBOM in SPDX format
   • Create SLSA Build Provenance attestation
   • Create SBOM attestation
   • Generate SHA-256 checksums
   • Security: Minimal write permissions (contents: write, attestations: write, id-token: write)

3. Release Job (5-10min):

   • Create GitHub Release with all artifacts
   • Deploy to AWS S3/CloudFront (OIDC authentication)
   • Deploy to GitHub Pages (disaster recovery)
   • Invalidate CloudFront cache
   • Security: OIDC for AWS (no long-lived credentials), least-privilege IAM roles

Release Artifacts (per version):

• riksdagsmonitor-vX.Y.Z.zip - Production build
• riksdagsmonitor-vX.Y.Z.zip.sha256 - Integrity checksum
• riksdagsmonitor-vX.Y.Z.spdx.json - SBOM
• riksdagsmonitor-vX.Y.Z.zip.intoto.jsonl - Build provenance attestation
• riksdagsmonitor-vX.Y.Z.spdx.json.intoto.jsonl - SBOM attestation

Documentation as Code: All technical reports automatically generated and committed to docs/ on each release:

• docs/api/ - JSDoc API documentation
• docs/coverage/ - Vitest test coverage (HTML + lcov)
• docs/test-results/ - Vitest test results (JSON + HTML)
• docs/cypress/ - Cypress E2E test reports
• docs/dependencies/ - npm dependency tree (JSON + TXT)
• docs/index.html - Documentation hub (cyberpunk-themed)

Verification Procedures:

# Verify build provenance attestation
gh attestation verify riksdagsmonitor-vX.Y.Z.zip -R Hack23/riksdagsmonitor

# Verify SBOM attestation
gh attestation verify riksdagsmonitor-vX.Y.Z.spdx.json -R Hack23/riksdagsmonitor

# Verify artifact integrity
sha256sum -c riksdagsmonitor-vX.Y.Z.zip.sha256
Copy

Control Mapping:

• ISO 27001: A.8.30 (Secure coding), A.8.32 (Change management), A.14.2 (Security in development)
• NIST CSF 2.0: PR.DS-6 (Integrity verification mechanisms), ID.SC-3 (Supply chain risk assessment)
• CIS Controls v8.1: 16.6 (Application software security), 16.10 (Vulnerability remediation)

For complete release process documentation, see RELEASE_PROCESS.md and WORKFLOWS.md.

3. 📋 Compliance Mapping

3.1 ISO 27001:2022 Controls

3.2 NIST CSF 2.0 Categories

3.3 CIS Controls v8.1

4. 🛡️ Security Controls Summary

4.1 Preventive Controls

1. Access Control:

   • GitHub MFA requirement
   • SSH key authentication with passphrase
   • GPG commit signing
   • Branch protection rules
   • AWS OIDC authentication (no long-lived credentials)

2. Network Security:

   • HTTPS-only access (TLS 1.3)
   • Security headers (CSP, HSTS, X-Frame-Options, Permissions-Policy)
   • AWS CloudFront DDoS protection (AWS Shield Standard)
   • Route 53 health checks and automatic failover
   • GitHub infrastructure DDoS protection (DR)

3. Development Security:

   • HTML/CSS/JavaScript with Chart.js and D3.js
   • CSP headers with SRI for CDN resources
   • No user input processing (display CIA data only)
   • Dependency scanning via GitHub Dependabot alerts
   • Code quality checks in CI/CD (HTMLHint, linkinator)
   • CIA data validation against JSON schemas

4.2 Detective Controls

1. Security Monitoring:

   • Dependabot vulnerability alerts
   • Secret scanning
   • CodeQL static analysis
   • GitHub audit logs

2. Quality Checks:

   • HTML validation (HTMLHint)
   • Link checking (linkinator)
   • Automated CI/CD pipeline checks

4.3 Corrective Controls

1. Incident Response:

   • Documented procedures
   • Git rollback capability
   • Rapid re-deployment via GitHub Actions

2. Patch Management:

   • Dependabot automatic updates
   • Rapid deployment via GitHub Actions
   • Version control for rollback

5. 📝 Security Assumptions and Constraints

5.1 Assumptions

1. AWS Infrastructure: Trusted cloud provider with robust security
2. GitHub Infrastructure: Trusted cloud provider with robust security (DR)
3. Client-Side Security: Chart.js/D3.js libraries are secure, maintained, and hosted locally on CloudFront
4. CloudFront Security: AWS CloudFront is trusted for static asset delivery with 99.9% SLA
5. Public Data: All content is public information (Swedish Riksdag open data)
6. External Dependencies: CIA platform (www.hack23.com/cia) maintains its own security
7. Browser Security: Users have modern browsers with JavaScript enabled

5.2 Constraints

1. AWS Infrastructure Limitations:

   • S3 static website limitations (no server-side code execution)
   • CloudFront caching behavior (potential stale content)
   • Cost constraints for high traffic scenarios

2. GitHub Pages Limitations (DR):

   • No server-side code execution
   • No database access
   • Limited customization of HTTP headers
   • Fixed infrastructure (cannot modify underlying OS)

3. Client-Side JavaScript Limitations:

   • Requires JavaScript enabled in browser
   • CSP 'unsafe-inline' needed for Chart.js/D3.js
   • Browser compatibility requirements (ES6+)
   • Limited control over client execution environment

6. ⚠️ Risk Assessment

6.1 Residual Risks

6.2 Accepted Risks

1. Client-Side JavaScript: Acceptable for interactive dashboards with CSP and SRI
2. AWS Platform Dependency: Acceptable given AWS's security posture and GitHub Pages DR
3. GitHub Platform Dependency (DR): Acceptable with AWS as primary
4. External CIA Platform Dependency: Acceptable with documented availability in THREAT_MODEL.md
5. CSP 'unsafe-inline': Acceptable for Chart.js/D3.js dashboard rendering (future: nonce-based CSP)

7. 🏛️ Security Governance

7.1 Roles and Responsibilities

7.2 Review and Update Schedule

• Security Architecture Review: Annual or after major changes
• Threat Model Update: Quarterly or after incidents
• Dependency Updates: Automated via Dependabot (weekly)
• Access Control Review: Quarterly

7.3 Related Documentation

• Hack23 ISMS
• Secure Development Policy
• THREAT_MODEL.md - Riksdags Monitor threat analysis
• Information Security Policy

8. ✅ Approval

🛡️ Defense-in-Depth Strategy

Riksdagsmonitor implements a comprehensive defense-in-depth security strategy with six overlapping layers of protection. Each layer provides independent security controls, ensuring that compromise of a single layer does not result in complete system failure.

Security Layers

graph TB
    subgraph "Layer 6: Monitoring & Response"
        L6A[GitHub Security Alerts]
        L6B[AWS CloudWatch]
        L6C[Dependabot Monitoring]
        L6D[Incident Response Team]
    end
    
    subgraph "Layer 5: CI/CD Security"
        L5A[CodeQL SAST]
        L5B[Dependabot Updates]
        L5C[Secret Scanning]
        L5D[SLSA Attestations]
        L5E[step-security/harden-runner]
    end
    
    subgraph "Layer 4: Data Protection"
        L4A[TLS 1.3 Transit]
        L4B[AES-256 At Rest]
        L4C[S3 Versioning]
        L4D[Cross-Region Replication]
    end
    
    subgraph "Layer 3: Access Control"
        L3A[GitHub MFA]
        L3B[SSH Keys + Passphrase]
        L3C[GPG Commit Signing]
        L3D[AWS OIDC ephemeral credentials]
    end
    
    subgraph "Layer 2: Application Security"
        L2A[Content Security Policy]
        L2B[HSTS Headers]
        L2C[Subresource Integrity]
        L2D[XSS Protection]
    end
    
    subgraph "Layer 1: Network Security"
        L1A[AWS CloudFront CDN]
        L1B[AWS Shield Standard]
        L1C[AWS WAF on CloudFront (planned)]
        L1D[GitHub Infrastructure DR]
    end
    
    User[👤 User/Attacker] --> L1A
    User -.->|DR Failover| L1D
    L1A --> L2A
    L2A --> L3A
    L3A --> L4A
    L4A --> L5A
    L5A --> L6A
    
    style User fill:#ff6b6b,color:#000000
    style L1A fill:#51cf66,color:#000000
    style L2A fill:#4dabf7,color:#000000
    style L3A fill:#ffd43b,color:#000000
    style L4A fill:#ff8787,color:#000000
    style L5A fill:#da77f2,color:#000000
    style L6A fill:#20c997,color:#000000
Copy

Layer 1: Network Security (Perimeter Defense)

Purpose: Protect against network-level attacks (DDoS, volumetric attacks, malicious traffic).

ISO 27001: A.13.1 (Network Security Management)
NIST CSF 2.0: PR.AC-5 (Network integrity protected)
CIS Controls v8.1: 13.1 (Centralize security event alerting)

Layer 2: Application Security (HTTP Defense)

Purpose: Protect against web application attacks (XSS, clickjacking, MIME sniffing).

Note: CSP style-src includes 'unsafe-inline' for Chart.js/D3.js inline styles; script-src uses 'self' plus per-script sha256 hashes (no 'unsafe-inline' for scripts).

ISO 27001: A.14.2 (Security in development and support)
NIST CSF 2.0: PR.IP-12 (Vulnerability management plan)
CIS Controls v8.1: 16.1 (Secure application development process)

Layer 3: Access Control (Identity & Authorization)

Purpose: Ensure only authorized entities can modify code or infrastructure.

ISO 27001: A.9.2 (User access management), A.9.4 (System access control)
NIST CSF 2.0: PR.AC-1 (Identities and credentials managed), PR.AC-4 (Access permissions managed)
CIS Controls v8.1: 5.1 (Account inventory), 6.8 (Role-based access control)

Layer 4: Data Protection (Confidentiality & Integrity)

Purpose: Protect data in transit and at rest; enable recovery from data loss.

RPO (Recovery Point Objective): <15 minutes (S3 cross-region replication)
RTO (Recovery Time Objective): <15 minutes (AWS primary), <30 minutes (GitHub Pages DR)

ISO 27001: A.10.1 (Cryptographic controls)
NIST CSF 2.0: PR.DS-1 (Data-at-rest protected), PR.DS-2 (Data-in-transit protected)
CIS Controls v8.1: 3.10 (Encrypt data in transit)

Layer 5: CI/CD Security (Supply Chain Protection)

Purpose: Prevent introduction of vulnerabilities during development and deployment.

Supply Chain Security Level: SLSA Level 2+ (cryptographically signed build provenance)

ISO 27001: A.8.30 (Secure coding), A.8.32 (Change management), A.14.2 (Security in development)
NIST CSF 2.0: PR.DS-6 (Integrity verification), ID.SC-3 (Supply chain risk assessment)
CIS Controls v8.1: 16.6 (Application software security), 16.10 (Vulnerability remediation)

Layer 6: Monitoring & Response (Detection & Recovery)

Purpose: Detect security events, respond to incidents, and continuously improve security posture.

Mean Time to Detect (MTTD): <24 hours (automated scanning)
Mean Time to Respond (MTTR): Critical: 24h, High: 7d, Medium: 30d, Low: 90d (see §Vulnerability Management)

ISO 27001: A.12.4 (Logging and monitoring), A.16.1 (Incident management)
NIST CSF 2.0: DE.CM-1 (Network monitored), RS.CO-1 (Personnel know roles)
CIS Controls v8.1: 8.2 (Collect audit logs), 17.1 (Designate incident handling personnel)

📜 Data Integrity & Auditing

Riksdagsmonitor maintains comprehensive data integrity controls and immutable audit trails to ensure trustworthiness of all content and changes.

Git Commit Integrity

Verification Command:

git log --show-signature main
# or verify specific commit:
git verify-commit <commit-sha>
Copy

SLSA Build Provenance Attestations

Framework: SLSA (Supply Chain Levels for Software Artifacts) Level 2+
Purpose: Cryptographically prove artifacts were built by trusted CI/CD pipeline without tampering

Attestation Format: in-toto (*.intoto.jsonl) - industry-standard supply chain metadata format

What SLSA Attestations Prove:

1. ✅ Artifact was built by specific GitHub Actions workflow
2. ✅ Build occurred in isolated GitHub runner environment
3. ✅ No unauthorized modifications during build process
4. ✅ Build inputs (source code commit SHA) are traceable
5. ✅ Build outputs (artifacts) match declared provenance

Immutable Audit Trail

Integrity Verification

SHA-256 Checksums: Every release includes .sha256 file for artifact integrity verification

# Verify artifact integrity
sha256sum -c riksdagsmonitor-vX.Y.Z.zip.sha256
Copy

SBOM Integrity: Software Bill of Materials (SPDX format) cryptographically signed with SLSA attestation

• Tracks all dependencies (name, version, license)
• Enables vulnerability tracking across supply chain
• Supports license compliance audits

ISO 27001: A.12.4 (Logging and monitoring), A.8.32 (Change management)
NIST CSF 2.0: PR.DS-6 (Integrity checking mechanisms)
CIS Controls v8.1: 8.2 (Collect audit logs), 8.5 (Collect detailed audit logs)

🔍 Security Event Monitoring

Riksdagsmonitor implements continuous security monitoring with automated alerting and response workflows.

GitHub Security Features

Alert Severity Classification

AWS CloudWatch Monitoring

Metrics Monitored:

• CloudFront: Request count, error rates (4xx, 5xx), cache hit ratio, origin latency
• S3: Bucket size, request metrics, replication lag
• Route 53: Health check status, DNS query count, failover events

Alerting Thresholds:

• CloudFront 5xx error rate >5% for 5 minutes → PagerDuty alert
• S3 replication lag >30 minutes → Email alert
• Route 53 health check failure (3 consecutive) → Automatic DNS failover to GitHub Pages

Security Event Correlation

Event Types Tracked:

1. Access Events: GitHub login, SSH key usage, AWS console access
2. Change Events: Git commits, AWS resource modifications, DNS changes
3. Security Events: Failed authentication, unauthorized access attempts, security scan findings
4. Availability Events: Service outages, health check failures, high error rates

Correlation Analysis:

• Multiple failed login attempts + successful login → Potential account compromise
• Unusual git commit pattern (time/frequency) → Investigate for compromise
• Spike in 5xx errors + CloudFront origin health check failure → Trigger failover

ISO 27001: A.12.4 (Logging and monitoring), A.16.1 (Incident management)
NIST CSF 2.0: DE.CM-1 (Network monitored), DE.AE-3 (Event data aggregated and analyzed)
CIS Controls v8.1: 8.2 (Collect audit logs), 13.1 (Centralize security event alerting)

🏗️ High Availability Design

Riksdagsmonitor implements dual-deployment architecture with automatic failover to achieve 99.9%+ availability SLA.

Architecture Overview

graph TB
    User[👤 User Request]
    
    subgraph "DNS Layer"
        Route53[AWS Route 53<br/>Health Checks + Failover]
    end
    
    subgraph "Primary Deployment - AWS"
        CF[CloudFront CDN<br/>600+ Edge Locations<br/>SLA: 99.9%]
        S3US[S3 us-east-1<br/>Primary Origin<br/>SLA: 99.99%]
        S3EU[S3 eu-west-1<br/>Failover Origin<br/>SLA: 99.99%]
        
        CF -->|Cache Miss| S3US
        CF -.->|Origin Failover<br/>on 5xx errors| S3EU
        S3US -.->|Async Replication<br/>RPO: <15 min| S3EU
    end
    
    subgraph "Disaster Recovery - GitHub"
        GHCDN[GitHub Pages CDN<br/>SLA: 99.9%]
        GHRepo[GitHub Repository<br/>main branch]
        
        GHCDN --> GHRepo
    end
    
    User --> Route53
    Route53 -->|Primary DNS| CF
    Route53 -.->|Failover DNS<br/>on health check failure| GHCDN
    
    style User fill:#e1f5ff,color:#000000
    style Route53 fill:#ff9800,color:#000000
    style CF fill:#4caf50,color:#000000
    style S3US fill:#2196f3,color:#ffffff
    style S3EU fill:#90caf9,color:#000000
    style GHCDN fill:#9c27b0,color:#ffffff
    style GHRepo fill:#673ab7,color:#ffffff
Copy

Availability Tiers

Composite Availability: 99.95%+ (accounting for dual-deployment failover)

Failover Scenarios

Recovery Objectives

Cross-Region Replication

Configuration:

• Source: s3://riksdagsmonitor-us-east-1
• Destination: s3://riksdagsmonitor-eu-west-1
• Replication Mode: Asynchronous (near real-time)
• Replication SLA: <15 minutes for 99.99% of objects
• Replication Scope: All objects (HTML, CSS, JS, images, data files)

Replication Monitoring:

• S3 Replication metrics in CloudWatch
• Alert if replication lag >30 minutes
• Daily verification of object count consistency

Disaster Recovery Testing

Test Schedule:

• Monthly: Automated DNS failover test (non-production DNS record)
• Quarterly: Full DR exercise with manual DNS failover to GitHub Pages
• Annually: AWS region failure simulation (coordinated maintenance window)

Last DR Test: 2026-02-15 (GitHub Pages failover - Success, RTO: 4m 32s)
Next DR Test: 2026-05-15 (Full AWS→GitHub failover exercise)

ISO 27001: A.17.1 (Information security continuity), A.17.2 (Redundancies)
NIST CSF 2.0: RC.RP-1 (Recovery plan executed), RC.CO-3 (Recovery activities communicated)
CIS Controls v8.1: 11.1 (Establish and maintain data recovery), 11.5 (Establish and maintain an isolated recovery environment)

🕵️ Threat Detection & Investigation

Riksdagsmonitor implements comprehensive threat detection capabilities with defined investigation workflows.

Detection Capabilities

Investigation Workflow

graph TB
    Alert[🚨 Security Alert Triggered]
    
    Alert --> Triage{Triage<br/>Is it valid?}
    
    Triage -->|False Positive| Dismiss[📝 Document & Dismiss<br/>Update detection rules]
    Triage -->|Valid Threat| Assess{Assess<br/>Severity?}
    
    Assess -->|Critical| Immediate[🔴 Immediate Response<br/>24h SLA]
    Assess -->|High| Urgent[🟠 Urgent Response<br/>7d SLA]
    Assess -->|Medium| Scheduled[🟡 Scheduled Response<br/>30d SLA]
    Assess -->|Low| Backlog[🟢 Backlog<br/>90d SLA]
    
    Immediate --> Investigate
    Urgent --> Investigate
    Scheduled --> Investigate
    Backlog --> Investigate
    
    Investigate[🔍 Investigate<br/>Scope & Impact] --> Contain[🛡️ Contain<br/>Limit damage]
    
    Contain --> Remediate[🔧 Remediate<br/>Fix vulnerability]
    
    Remediate --> Verify[✅ Verify<br/>Test fix]
    
    Verify --> Document[📄 Document<br/>Lessons learned]
    
    Document --> Close[✔️ Close Alert<br/>Update docs]
    
    Close --> Review{Requires<br/>Architecture Update?}
    
    Review -->|Yes| UpdateDocs[📝 Update SECURITY_ARCHITECTURE.md<br/>and THREAT_MODEL.md]
    Review -->|No| End[🏁 End]
    
    UpdateDocs --> End
    Dismiss --> End
    
    style Alert fill:#ff6b6b,color:#000000
    style Immediate fill:#ff0000,color:#fff
    style Urgent fill:#ff6b6b,color:#000000
    style Scheduled fill:#ffd43b,color:#000000
    style Backlog fill:#51cf66,color:#000000
    style Contain fill:#4dabf7,color:#000000
    style Remediate fill:#da77f2,color:#000000
    style Verify fill:#20c997,color:#000000
    style End fill:#e9ecef,color:#000000
Copy

Investigation Procedures

1. Dependabot Vulnerability Alert

• Trigger: New CVE affecting dependency
• Investigation Steps:
  1. Review Dependabot alert details (CVSS score, affected versions, patch availability)
  2. Check if vulnerability is exploitable in Riksdagsmonitor context (e.g., unused code path)
  3. Assess impact to application functionality
  4. Verify patch availability and compatibility
• Remediation: Accept Dependabot PR or manually update package.json / package-lock.json
• Verification: Run npm audit, re-scan with Dependabot, test functionality
• Documentation: Record the security fix in GitHub release notes and commit message

2. CodeQL Code Scanning Alert

• Trigger: SAST finding in pull request or scheduled scan
• Investigation Steps:
  1. Review CodeQL alert (CWE category, location, data flow)
  2. Analyze false positive likelihood (CodeQL has ~5-10% FP rate)
  3. Trace vulnerable code path from source to sink
  4. Assess exploitability (input vector, attacker control)
• Remediation: Refactor code, add input validation, or dismiss if false positive with justification
• Verification: Re-run CodeQL, confirm alert resolved
• Documentation: If architecture change, update SECURITY_ARCHITECTURE.md

3. Secret Scanning Alert

• Trigger: Pattern match for API key, token, or credential
• Investigation Steps:
  1. Identify secret type and scope (GitHub token, AWS key, API key)
  2. Determine if secret is active or test/example data
  3. Check if secret has been used (GitHub audit log, AWS CloudTrail)
  4. Assess blast radius (what resources does secret access?)
• Remediation: Rotate secret immediately, revoke old credential, update GitHub Secrets
• Verification: Confirm old secret is revoked and new secret works
• Documentation: Record incident in THREAT_MODEL.md, update access controls if needed

4. Infrastructure Anomaly (AWS)

• Trigger: CloudWatch alarm (high error rate, latency spike, health check failure)
• Investigation Steps:
  1. Check CloudFront metrics (error rates, cache hit ratio, origin latency)
  2. Review S3 access logs for suspicious patterns
  3. Analyze Route 53 query logs for DNS anomalies
  4. Check AWS CloudTrail for unauthorized API calls
• Remediation: Varies by root cause (scale resources, fix configuration, block malicious IP)
• Verification: Confirm metrics return to normal, health checks pass
• Documentation: Update runbooks if new failure mode discovered

Threat Intelligence Sources

ISO 27001: A.16.1 (Management of information security incidents), A.12.4 (Logging and monitoring)
NIST CSF 2.0: DE.AE-2 (Detected events analyzed), DE.AE-5 (Incident alert thresholds established)
CIS Controls v8.1: 17.2 (Establish and maintain contact information), 17.4 (Establish and maintain incident response process)

🔎 Vulnerability Management

Riksdagsmonitor implements a risk-based vulnerability management program with defined Service Level Agreements (SLAs) for remediation.

Vulnerability Lifecycle

graph LR
    Detect[🔍 Detect<br/>Scanner finds vulnerability] --> Triage{🎯 Triage<br/>Assess severity<br/>& exploitability}
    
    Triage -->|Critical| C[🔴 Critical<br/>24h SLA]
    Triage -->|High| H[🟠 High<br/>7d SLA]
    Triage -->|Medium| M[🟡 Medium<br/>30d SLA]
    Triage -->|Low| L[🟢 Low<br/>90d SLA]
    
    C --> Remediate[🔧 Remediate<br/>Apply patch/fix]
    H --> Remediate
    M --> Remediate
    L --> Remediate
    
    Remediate --> Verify[✅ Verify<br/>Re-scan & test]
    
    Verify --> Pass{Verification<br/>Passed?}
    
    Pass -->|Yes| Close[✔️ Close<br/>Document fix]
    Pass -->|No| Remediate
    
    Close --> Monitor[👁️ Monitor<br/>Continuous scanning]
    
    Monitor --> Detect
    
    style Detect fill:#4dabf7,color:#000000
    style C fill:#ff0000,color:#fff
    style H fill:#ff6b6b,color:#000000
    style M fill:#ffd43b,color:#000000
    style L fill:#51cf66,color:#000000
    style Remediate fill:#da77f2,color:#000000
    style Verify fill:#20c997,color:#000000
    style Close fill:#e9ecef,color:#000000
Copy

Remediation SLAs

SLA Start: Clock starts when vulnerability is first detected by automated scanner or manually reported

SLA Pause Conditions:

• Waiting for upstream patch (e.g., library maintainer)
• Requires breaking change with deprecation period
• Validated as false positive (requires CISO approval)

Severity Classification

Factors Considered:

1. CVSS Base Score: Industry-standard severity metric
2. Exploitability: Is there a known exploit? (EPSS score)
3. Context: Is vulnerable code path reachable in Riksdagsmonitor?
4. Impact: Confidentiality/Integrity/Availability impact
5. Exposure: Public internet-facing vs. internal-only

Severity Adjustment Examples:

• CVE-2024-12345 in lodash (CVSS 8.2 High): Downgraded to Medium if vulnerable function not used
• CVE-2024-67890 in Chart.js (CVSS 5.5 Medium): Upgraded to High if actively exploited in the wild

Vulnerability Sources

Remediation Strategies

Patch Management Process

Automated Patching (Dependabot):

1. Dependabot detects new patch version
2. Dependabot opens PR with changelogs and test results
3. CI/CD runs automated tests
4. If tests pass, PR auto-merged (for minor/patch versions)
5. If tests fail, manual review required

Manual Patching:

1. Security team reviews vulnerability details
2. Create fix branch: security/CVE-YYYY-NNNNN
3. Apply fix (update dependency, refactor code, apply workaround)
4. Run full test suite (unit + E2E)
5. Record the security fix in GitHub release notes and commit message
6. Create PR with "Security Fix" label
7. Fast-track review (bypass normal review queue for Critical/High)
8. Merge to main and deploy immediately

Zero-Day Response:

1. CISO notified immediately (email + phone)
2. Assess blast radius and exploitability
3. If critical: Disable GitHub Pages temporarily (rollback to safe version)
4. Apply emergency fix within 24h
5. Deploy hotfix release (vX.Y.Z+1)
6. Conduct post-incident review within 7 days

Metrics & Reporting

Key Performance Indicators (KPIs):

• Mean Time to Detect (MTTD): <24 hours (target: real-time)
• Mean Time to Remediate (MTTR): Varies by severity (see SLAs)
• Vulnerability Backlog: <10 open vulnerabilities (target: <5)
• SLA Compliance: >95% of vulnerabilities remediated within SLA
• False Positive Rate: <10% (CodeQL findings dismissed as FP)

Monthly Security Report:

• New vulnerabilities detected (by severity)
• Vulnerabilities remediated (by SLA compliance)
• Overdue vulnerabilities (exceeding SLA)
• Dependency update velocity (patches/month)
• False positive rate

ISO 27001: A.12.6 (Technical vulnerability management), A.14.2 (Security in development)
NIST CSF 2.0: PR.IP-12 (Vulnerability management plan), DE.CM-8 (Vulnerability scans performed)
CIS Controls v8.1: 7.1 (Establish a vulnerability management process), 7.2 (Establish a remediation process)

🤖 Automated Security Operations

Riksdagsmonitor leverages extensive automation to reduce manual security overhead and accelerate response times.

CI/CD Security Automation

Dependabot Configuration

Dependabot is configured to automatically monitor and update both npm dependencies and GitHub Actions workflows, with daily checks for new versions and security patches. Minor and patch npm updates are grouped for reduced noise.

The authoritative configuration is maintained in .github/dependabot.yml. Refer to that file for the exact ecosystems, schedules, labels, groups, and other settings currently in effect.

Auto-Merge Policy:

• Patch versions (X.Y.Z → X.Y.Z+1): Auto-merge if CI passes
• Minor versions (X.Y.Z → X.Y+1.0): Manual review required
• Major versions (X.Y.Z → X+1.0.0): Manual review + architecture assessment

CodeQL Configuration

File: .github/workflows/codeql.yml

Query Suites:

• GitHub default CodeQL query suite for JavaScript (security coverage aligned with OWASP/CWE/SANS)
• Additional review for riksdagsmonitor-specific patterns as needed

Scan Frequency:

• Pull Requests: Every PR (blocking check)
• Scheduled: Every Monday 00:00 UTC (full repository scan, cron: 0 0 * * 1)
• Manual: On-demand via workflow_dispatch

False Positive Management:

• Dismissed alerts documented in the central security documentation (CodeQL dismissal log)
• Requires CISO approval for dismissal
• Automated re-opening if code changes in dismissed location

SLSA Build Provenance Workflow

File: .github/workflows/release.yml (Build job)

- name: Generate SLSA Build Provenance
  uses: actions/attest-build-provenance@96278af6caaf10aea03fd8d33a09a777ca52d62f # v3.2.0
  with:
    subject-path: 'riksdagsmonitor-*.zip'
Copy

Attestation Contents:

• Build environment (GitHub Actions runner: ubuntu-latest)
• Workflow identity (riksdagsmonitor/.github/workflows/release.yml)
• Source commit SHA (git ref)
• Builder identity (GitHub Actions OIDC token)
• Build timestamp (RFC 3339)

step-security/harden-runner

Purpose: Monitor GitHub Actions workflow execution for supply chain attacks

Capabilities:

• Syscall Monitoring: Detect unauthorized file access, process creation
• Network Egress: Audit all outbound connections, block unexpected domains
• Threat Intelligence: Compare actions against known malicious patterns

Configuration (every workflow):

- name: Harden Runner
  uses: step-security/harden-runner@58077d3c7e43986b6b15fba718e8ea69e387dfcc # v2.15.1
  with:
    egress-policy: audit  # Log all network egress (block mode planned 2027 Q2)
    allowed-endpoints: >
      github.com:443
      api.github.com:443
      raw.githubusercontent.com:443
      registry.npmjs.org:443
      data.imf.org:443
      api.imf.org:443
      www.imf.org:443
Copy

Security Automation Metrics

ROI of Automation:

• Manual effort saved: ~15 hours/week (previously: 17 hours/week manual security tasks)
• Faster response: 90% reduction in time to deploy security patches (24h → 2.5h)
• Improved coverage: 100% code scanning (previously: ad-hoc manual reviews)

ISO 27001: A.14.2 (Security in development and support), A.12.1 (Operational procedures)
NIST CSF 2.0: PR.IP-1 (Configuration baseline established), PR.IP-12 (Vulnerability management)
CIS Controls v8.1: 16.1 (Secure application development), 16.9 (Separate production and non-production environments)

⚡ Resilience & Operational Readiness

Riksdagsmonitor maintains operational resilience through comprehensive business continuity planning, disaster recovery testing, and operational runbooks.

Recovery Objectives Summary

Business Continuity Plan (BCP)

Scope: Ensure continuity of Riksdagsmonitor service during disruptions (technical failures, security incidents, natural disasters)

Critical Business Functions:

1. Website Availability: Serve content to users (RTO: <15 minutes)
2. Content Updates: Deploy new content/fixes (RTO: <2 hours)
3. Security Monitoring: Detect and respond to threats (RTO: <1 hour)

BCP Scenarios:

BCP Testing Schedule:

• Tabletop Exercise: Quarterly (next: 2026-03-15)
• DR Failover Test: Quarterly (next: 2026-05-15)
• Full BCP Exercise: Annually (next: 2026-08-15)

For complete BCP documentation, see BCPPlan.md.

Disaster Recovery Testing

Last DR Test Results (2026-02-15):

• Test Type: AWS → GitHub Pages failover
• Trigger: Manual DNS record change (simulated Route 53 health check failure)
• RTO Achieved: 4 minutes 32 seconds
• Issues Found: None
• Lessons Learned: None (test successful)

Next DR Test (2026-05-15):

• Test Type: Full AWS region failure simulation
• Scope: Simulate us-east-1 S3 bucket deletion
• Expected RTO: <5 minutes (CloudFront → S3 eu-west-1 → GitHub Pages)
• Rollback Plan: Restore from S3 versioning or GitHub repository

Operational Runbooks

On-Call & Escalation

On-Call Rotation: Not applicable (solo maintainer, automated monitoring)

Escalation Path:

1. Automated Alerts → Email/PagerDuty → James Pether Sörling (CISO)
2. Critical Incidents (CVSS ≥9.0, service outage) → Immediate phone call
3. Business Hours (09:00-17:00 CET) → Email response within 2 hours
4. After Hours → PagerDuty alert → Response within 1 hour

Contact Information:

• CISO: James Pether Sörling (james@hack23.com)
• Backup: Hack23 AB organizational admins
• Emergency: PagerDuty integration (Critical alerts only)

Operational Metrics

Service Level Indicators (SLIs):

• Availability: 99.95% (measured via Route 53 health checks + CloudWatch)
• Latency (p95): <200ms (CloudFront edge response time)
• Error Rate: <0.1% (CloudFront 5xx error rate)
• Data Loss: 0 incidents (S3 cross-region replication + versioning)

Operational Performance (Last 90 Days):

• Availability: 99.98% (6 minutes unplanned downtime)
• Incidents: 2 (1 planned maintenance, 1 CloudFront edge degradation)
• Security Alerts: 47 (45 Dependabot, 2 CodeQL)
• Deployments: 12 releases (average: 1 per week)

ISO 27001: A.17.1 (Information security continuity), A.17.2 (Redundancies)
NIST CSF 2.0: RC.RP-1 (Recovery plan executed), RC.CO-3 (Recovery activities communicated)
CIS Controls v8.1: 11.1 (Data recovery capability), 11.3 (Protect recovery data)

📋 Configuration & Compliance Management

Riksdagsmonitor implements Infrastructure as Code (IaC) principles using GitHub Actions workflows and enforces configuration compliance through automated policies.

Infrastructure as Code (IaC)

Philosophy: All infrastructure configuration managed through version-controlled code (GitHub Actions workflows, CloudFormation templates).

Roadmap (2027 Q2): Migrate AWS CloudFront + Route 53 to Terraform for full IaC management.

GitHub Branch Protection Rules

Applied to: main branch

Audit Frequency: Quarterly review of branch protection rules (next: 2026-05-01)

Configuration Drift Detection

Manual Audit Process (Quarterly):

1. Export current AWS configurations (S3 bucket policies, CloudFront distributions, Route 53 records)
2. Compare against documented baseline (§1.2, §1.3)
3. Document deviations in ARCHITECTURE.md
4. Remediate unauthorized changes within 7 days

Last Configuration Audit: 2026-02-10 (No drift detected)
Next Configuration Audit: 2026-05-10

Automated Drift Detection (Planned 2027 Q2):

• AWS Config service to monitor S3/CloudFront/Route 53 changes
• CloudWatch Events to alert on configuration changes
• Terraform state file to detect drift

Compliance Monitoring

Continuous Compliance Checks:

Compliance Dashboard: GitHub Security tab provides real-time compliance status for Dependabot, CodeQL, and Secret Scanning.

Change Management

Change Types:

Emergency Change Process:

1. CISO authorizes emergency change (verbal approval acceptable)
2. Deploy fix immediately (bypass normal review process)
3. Document change in post-incident review (within 24 hours)
4. Formal approval added retroactively to PR

Change Advisory Board (CAB): Not applicable (solo maintainer). For multi-maintainer projects, CAB would meet monthly to review significant changes.

ISO 27001: A.8.32 (Change management), A.12.1 (Operational procedures)
NIST CSF 2.0: PR.IP-1 (Configuration baseline), PR.IP-3 (Change control processes)
CIS Controls v8.1: 4.1 (Configuration baseline), 4.2 (Secure configuration implementation)

📊 Monitoring & Analytics

Riksdagsmonitor implements comprehensive monitoring across infrastructure, application, and security dimensions.

AWS CloudWatch Monitoring

Metrics Dashboard:

Log Retention:

• CloudFront Access Logs: 90 days (S3 bucket: riksdagsmonitor-logs-cloudfront)
• S3 Access Logs: 90 days (S3 bucket: riksdagsmonitor-logs-s3)
• CloudTrail Logs: 90 days (S3 bucket: riksdagsmonitor-logs-cloudtrail)

Log Analysis:

• Automated: CloudWatch Insights queries for anomaly detection (high 5xx rates, unusual geographic traffic)
• Manual: Quarterly log review for security incidents, access patterns, optimization opportunities

GitHub Audit Logging

Audit Scope:

• Organization-level access (user additions, permission changes)
• Repository-level access (clone, push, pull requests)
• Actions workflow execution (workflow runs, secrets access)
• Security events (failed authentication, secret scanning alerts)

Audit Retention: 90 days (GitHub Free), 180 days (GitHub Enterprise - if upgraded)

Audit Review Process:

• Automated: GitHub Security dashboard for real-time alerts
• Manual: Quarterly audit log review for anomalous access patterns

Security Metrics Dashboard

Key Security Metrics (Updated Monthly):

Security Score (OpenSSF Scorecard): ~8.2/10 (estimated; run gh api repos/Hack23/riksdagsmonitor/properties/values or OpenSSF Scorecard CLI for current value)

• Maintained: ✅ (active commits in last 90 days)
• Vulnerabilities: ✅ (no known vulnerabilities)
• Signed Releases: ✅ (SLSA attestations)
• Branch Protection: ✅ (enforced on main)
• Dangerous Workflows: ✅ (no dangerous patterns)

Performance Monitoring

User Experience Metrics (Real User Monitoring via CloudFront):

Synthetic Monitoring (Planned 2027 Q2):

• Uptime Robot or Pingdom for external availability checks
• Lighthouse CI for performance regression detection

Cost Monitoring

AWS Monthly Costs (Projected):

• CloudFront: $8-12 (1 GB data transfer out)
• S3 Storage: $1-2 (50 GB storage)
• S3 Requests: $0.50 (100k GET requests)
• Route 53: $0.50 (1 hosted zone)
• CloudTrail: $0 (free tier: 1 trail)
• Total: ~$10-15/month (well within free tier limits)

Cost Optimization:

• CloudFront cache hit ratio >90% reduces origin requests
• S3 Intelligent-Tiering (planned 2027 Q2) for infrequently accessed objects
• Lifecycle policies to delete old logs after 90 days

Analytics & Insights

Website Analytics: Not implemented (privacy-first approach, no user tracking)

Traffic Insights (CloudFront Access Logs):

• Daily Visitors: ~500-1000 unique IPs
• Geographic Distribution: 80% Sweden, 10% EU, 10% Other
• Peak Traffic: Weekdays 09:00-17:00 CET (Riksdag working hours)

ISO 27001: A.12.4 (Logging and monitoring)
NIST CSF 2.0: DE.CM-1 (Network monitored), DE.CM-7 (Monitoring for unauthorized activity)
CIS Controls v8.1: 8.2 (Collect audit logs), 8.5 (Collect detailed audit logs)

🔄 Security Operations

Riksdagsmonitor implements structured security operations with defined procedures, responsibilities, and continuous improvement processes.

Security Operations Center (SOC) Model

Operational Model: Single-person SOC (CISO), augmented with automated monitoring and alerting

Operating Hours:

• Business Hours (09:00-17:00 CET): Active monitoring, <2 hour response time
• After Hours: Automated monitoring, PagerDuty alerts for Critical events, <1 hour response time
• Weekends: Automated monitoring, email alerts, <4 hour response time (Critical only)

On-Call Coverage: Not applicable (solo maintainer, automated incident detection)

Security Operations Workflows

graph TB
    Monitor[📊 Continuous Monitoring<br/>Dependabot, CodeQL, CloudWatch]
    
    Monitor --> Detect{🔍 Security Event<br/>Detected?}
    
    Detect -->|No| Monitor
    Detect -->|Yes| Alert[🚨 Generate Alert<br/>Email/PagerDuty]
    
    Alert --> Classify{🎯 Classify Severity<br/>Critical/High/Medium/Low}
    
    Classify -->|Critical| Immediate[🔴 Immediate Response<br/>CISO notified<br/>24h SLA]
    Classify -->|High| Urgent[🟠 Urgent Response<br/>Email alert<br/>7d SLA]
    Classify -->|Medium| Standard[🟡 Standard Response<br/>Email digest<br/>30d SLA]
    Classify -->|Low| Routine[🟢 Routine Response<br/>Monthly review<br/>90d SLA]
    
    Immediate --> Investigate[🔬 Investigate<br/>Root cause analysis]
    Urgent --> Investigate
    Standard --> Investigate
    Routine --> Investigate
    
    Investigate --> Respond[🛡️ Respond<br/>Contain, remediate, verify]
    
    Respond --> Document[📝 Document<br/>Update THREAT_MODEL.md]
    
    Document --> Review[🔄 Post-Incident Review<br/>Lessons learned]
    
    Review --> Improve[⚡ Improve<br/>Update procedures/controls]
    
    Improve --> Monitor
    
    style Monitor fill:#4dabf7,color:#000000
    style Alert fill:#ff6b6b,color:#000000
    style Immediate fill:#ff0000,color:#fff
    style Urgent fill:#ff6b6b,color:#000000
    style Standard fill:#ffd43b,color:#000000
    style Routine fill:#51cf66,color:#000000
    style Investigate fill:#da77f2,color:#000000
    style Respond fill:#20c997,color:#000000
    style Document fill:#868e96,color:#000000
    style Review fill:#e9ecef,color:#000000
    style Improve fill:#51cf66,color:#000000
Copy

Operational Procedures

Security Review Cadence

Daily:

• Review Dependabot alerts (5 minutes)
• Check GitHub Security dashboard (2 minutes)

Weekly:

• Review CodeQL findings from scheduled scan (15 minutes)
• Triage and assign vulnerability remediation (30 minutes)

Monthly:

• Review security metrics dashboard (30 minutes)
• Analyze AWS CloudWatch alarms (15 minutes)
• Update security documentation if needed (1 hour)

Quarterly:

• Access control review (GitHub permissions, AWS IAM) (2 hours)
• Configuration audit (AWS, GitHub settings) (2 hours)
• DR failover test (1 hour)
• THREAT_MODEL.md update (2 hours)

Annually:

• Full security architecture review (8 hours)
• SECURITY_ARCHITECTURE.md update (4 hours)
• FUTURE_SECURITY_ARCHITECTURE.md update (2 hours)
• Incident response drill (3 hours)

Continuous Improvement Process

Lessons Learned (After Every Incident):

1. Conduct post-incident review within 7 days of resolution
2. Document root cause, timeline, and impact in incident report
3. Identify preventive measures (controls, monitoring, procedures)
4. Update relevant documentation (SECURITY_ARCHITECTURE.md, THREAT_MODEL.md, runbooks)
5. Track improvement actions to completion

Security Metrics Review (Monthly):

1. Analyze trends in vulnerability backlog, MTTR, SLA compliance
2. Identify areas for improvement (e.g., reduce CodeQL false positives)
3. Adjust security automation (e.g., tune Dependabot PR frequency)
4. Report to CEO/CISO on security posture

Threat Landscape Monitoring (Quarterly):

1. Review industry threat intelligence (OWASP, NIST, CISA)
2. Assess applicability to Riksdagsmonitor (e.g., new attack vectors for static sites)
3. Update THREAT_MODEL.md with new threats
4. Implement additional controls if needed

ISO 27001: A.16.1 (Incident management), A.12.1 (Operational procedures)
NIST CSF 2.0: DE.AE-5 (Incident alert thresholds), RS.AN-5 (Processes established for receiving, analyzing, and responding)
CIS Controls v8.1: 17.1 (Designate incident handling personnel), 17.9 (Establish incident scoring and prioritization schema)

💰 Security Investment

Riksdagsmonitor achieves robust security posture with minimal financial investment by leveraging zero-cost security controls and cloud platform free tiers.

Cost Breakdown

Zero-Cost Security Controls

GitHub Native Security Features (All Free):

1. ✅ Dependabot: Automated dependency vulnerability scanning and patching
2. ✅ CodeQL: SAST code scanning (JavaScript, HTML)
3. ✅ Secret Scanning: Detect exposed credentials in code
4. ✅ Security Advisories: CVE notifications and tracking
5. ✅ Branch Protection: Enforce code review and status checks
6. ✅ GPG Commit Signing: Cryptographic commit verification
7. ✅ Audit Log: Track access and changes (90-day retention)
8. ✅ Attestations: SLSA build provenance and SBOM signing
9. ✅ OWASP ZAP DAST: Weekly + on-demand active scans against production via .github/workflows/zap-scan.yml (rules baseline .zap/rules.tsv); artifacts retained 90 days. Maps to ISO 27001 A.8.29 / NIST CSF DE.CM-08 / CIS Control 18.

AWS Free Tier Security Features:

1. ✅ Shield Standard: DDoS protection for CloudFront
2. ✅ S3 Encryption: AES-256 at rest (no additional cost)
3. ✅ CloudTrail: API audit logging (1 trail free)
4. ✅ CloudWatch: Basic monitoring (10 metrics free)
5. ✅ IAM: Identity and access management (always free)
6. ✅ S3 Versioning: Rollback capability (storage cost only)

ROI of Security Automation

Manual Effort Avoided (Per Year):

• Dependency Updates: 52 weeks × 2 hours = 104 hours (automated by Dependabot)
• Vulnerability Scanning: 52 weeks × 1 hour = 52 hours (automated by CodeQL + Dependabot)
• Security Monitoring: 365 days × 0.5 hours = 182.5 hours (automated by GitHub Security dashboard)
• Total Manual Effort Saved: 338.5 hours/year ≈ $16,925/year (at $50/hour developer rate)

Risk Reduction:

• Data Breach Avoidance: Estimated $100,000+ cost (notification, investigation, reputation damage) - prevented by defense-in-depth
• Downtime Avoidance: 99.95% uptime = 4.4 hours/year downtime (vs. 99% = 87.6 hours) - saved by dual-deployment
• Compliance Cost: $0 (vs. $10,000-50,000 for manual compliance audits) - automated compliance mapping

Total Annual ROI: >$16,925 labor savings + risk avoidance for only $126-186/year investment = >9000% ROI

Future Security Investments (Planned)

Total Planned Investment: $60-120/year additional (2027+)

Cost Optimization Strategies

1. CloudFront Cache Optimization: 92% cache hit ratio reduces S3 requests by 92% (saves ~$5/month)
2. S3 Lifecycle Policies: Delete CloudFront logs after 90 days (saves ~$2/month)
3. S3 Intelligent-Tiering: Automatically move infrequently accessed objects to cheaper storage (planned 2027 Q2, saves ~$5/month)
4. GitHub Actions Caching: Reduce build times by 50% (saves runner minutes, keeps within free tier)

ISO 27001: A.5.23 (Information security for use of cloud services)
NIST CSF 2.0: ID.BE-3 (Priorities for organizational mission, objectives, and activities are established)
CIS Controls v8.1: N/A (Cost optimization is not directly mapped to security controls)

📝 Conclusion

Riksdagsmonitor demonstrates that robust security is achievable for static websites through defense-in-depth architecture, comprehensive automation, and zero-cost security controls.

Security Posture Summary

✅ Strong Security Controls:

• Multi-layered defense (6 layers: Network → Application → Access → Data → CI/CD → Monitoring)
• 100% code scanning coverage (CodeQL + Dependabot)
• SLSA Level 2+ supply chain security
• Dual-deployment with automatic failover (99.95% availability)
• <24 hour vulnerability detection and remediation (Critical/High)

✅ Compliance Excellence:

• ISO 27001:2022 Annex A controls fully mapped and implemented
• NIST CSF 2.0 six-function framework aligned
• CIS Controls v8.1 Implementation Group 1-2 coverage
• OpenSSF Scorecard: 8.2/10 (above industry average)

✅ Operational Efficiency:

• 90% reduction in manual security tasks (338.5 hours/year saved)
• <5 minute RTO for disaster recovery
• $10-15/month operational cost (<$200/year)

• 9000% ROI on security investment

✅ Continuous Improvement:

• Quarterly threat model updates
• Annual security architecture reviews
• Automated dependency updates (daily)
• Incident-driven control enhancements

Security Maturity Level

Current Maturity: Level 4 - Managed and Measurable (out of 5)

Maturity Assessment:

• ✅ Level 1 (Initial): Security controls exist
• ✅ Level 2 (Repeatable): Documented procedures and policies
• ✅ Level 3 (Defined): Standardized and integrated security processes
• ✅ Level 4 (Managed): Quantitatively managed with metrics and KPIs
• 🎯 Level 5 (Optimizing): Continuous improvement with threat intelligence integration (roadmap: 2027)

Future Security Roadmap

2027 Q2:

• Implement AWS WAF for rate limiting and advanced application protection
• Migrate to full IaC (Terraform) for AWS infrastructure
• Implement nonce-based CSP for stricter inline script control
• Add synthetic monitoring for external availability checks

2027 Q4:

• Integrate MITRE ATT&CK framework for threat modeling
• Implement Security Information and Event Management (SIEM) correlation
• Achieve Level 5 security maturity (Optimizing)

2028:

• Explore GitHub Enterprise for extended audit logging
• Expand OWASP ZAP DAST coverage to per-PR scans against npm run preview (current scope: weekly + on-demand against production — see .github/workflows/zap-scan.yml)
• Achieve SLSA Level 3 (hermetic builds with ephemeral environments)

Commitment to Security

Hack23 AB is committed to maintaining the highest security standards for Riksdagsmonitor as a public service for Swedish democratic transparency. Security is not a checkbox but a continuous journey of improvement, adaptation, and vigilance.

Security Contact: security@hack23.com
Responsible Disclosure: See SECURITY.md for vulnerability reporting procedures.

Section A: NIS2 Directive Compliance Mapping

NIS2 Directive (EU) 2022/2555 — Applicability Assessment

Riksdagsmonitor operates as a civic technology platform providing parliamentary transparency services. As a non-commercial platform operated by a micro-enterprise (Hack23 AB, single employee), Riksdagsmonitor falls under the general applicability provisions of NIS2 but is likely below the threshold for mandatory compliance as a "medium enterprise" (50+ employees or €10M+ turnover required for essential/important entity designation).

However, Hack23 AB voluntarily maps to NIS2 requirements as a best practice and client readiness demonstration.

Section B: OWASP LLM Top 10 Mitigations for MCP Pipeline

This section maps all 10 OWASP Top 10 for Large Language Model Applications risks to the Riksdagsmonitor MCP content generation pipeline.

Overall LLM Risk Assessment for Riksdagsmonitor MCP Pipeline: LOW-MEDIUM

The primary residual risks are LLM02 (output handling) mitigated by human review, and LLM05 (supply chain) mitigated by dependency pinning. The architecture's read-only data access, public data sources only, and mandatory human review gate collectively create a strong defense-in-depth posture.

Section C: ISO 27001:2022 Statement of Applicability Excerpt

Statement of Applicability (SoA) for Riksdagsmonitor - ISO 27001:2022 Annex A Controls

Scope: Riksdagsmonitor platform, all associated GitHub repositories, AWS infrastructure, and CI/CD pipelines.

Note: Riksdagsmonitor is not yet formally ISO 27001 certified. This SoA documents alignment as preparation for future certification.

SoA Summary:

• Total Annex A Controls: 93
• Applicable: 68 (73%)
• Not Applicable: 25 (27%) - primarily physical security, HR (single-person company)
• Fully Implemented: 66 (97% of applicable)
• Partially Implemented: 2 (3% of applicable)
• Not Implemented: 0

Section D: NIST CSF 2.0 Govern Function Mapping

NIST CSF 2.0 introduced the new GOVERN (GV) function as the sixth function, providing organizational context for all other functions.

GV.OC — Organizational Context

GV.RM — Risk Management Strategy

GV.RR — Roles, Responsibilities, and Authorities

GV.PO — Policy

GV.OV — Oversight

GV.SC — Supply Chain Risk Management

Section E: CIS Controls v8.1 Implementation Group Classification

Riksdagsmonitor is classified as an IG1/IG2 organization: micro-enterprise (1 employee), civic tech with moderate risk profile.

CIS Controls IG1 Summary: 35/35 applicable controls implemented (100%)
CIS Controls IG2 Summary: 28/35 applicable controls implemented (80%)
CIS Controls IG3 Summary: 3/10 applicable controls implemented (30%) — IG3 not a current target

Section F: Supply Chain Security (NIST CSF PR.SC)

PR.SC-1: Cyber Supply Chain Risk Management Documented

Riksdagsmonitor's cyber supply chain is documented in the Third Party Management Policy (ISMS-PUBLIC) and mapped here:

Critical Suppliers Tier 1 (Platform-Level Dependency):

1. GitHub — Source control, CI/CD, GitHub Pages hosting, GitHub Actions

   • Dependency type: CRITICAL — service unavailable = platform unavailable
   • Risk treatment: GitHub Enterprise ToS, MFA enforced, branch protection
   • Continuity: AWS CloudFront primary hosting reduces GitHub Pages dependency

2. AWS — CloudFront CDN, S3 multi-region, Route 53 DNS

   • Dependency type: HIGH — primary production hosting
   • Risk treatment: Multi-region S3, CloudFront origin failover, GitHub Pages DR
   • SLA: 99.99% CloudFront availability SLA

Supplier Tier 2 (Service-Level Dependency): 3. Anthropic (via GitHub Copilot) — Claude Sonnet 4.6 AI model

• Dependency type: MEDIUM — content generation only; cached content available
• Risk treatment: Caching, fallback to template articles, graceful degradation

4. riksdag-regering-mcp — Data pipeline MCP server
   • Dependency type: MEDIUM — data fetching; cached data available
   • Risk treatment: Local caching, stale data banner, version pinning

Supplier Tier 3 (Component-Level Dependencies): 5. npm ecosystem — JavaScript dependencies

• Dependency type: LOW-MEDIUM — build-time only; runtime is static HTML
• Risk treatment: package-lock.json SHA pinning, Dependabot daily scanning

6. GitHub Actions Marketplace — CI/CD workflow actions
   • Dependency type: LOW-MEDIUM — build-time pipeline
   • Risk treatment: SHA-pinned to specific commits, step-security/harden-runner

PR.SC-2: Third-Party Vetting Process

Vetting Criteria for New Dependencies:

SHA Pinning Strategy

# Example: SHA-pinned GitHub Actions (from workflows)
- uses: actions/checkout@v4  # SHA: abc123...
- uses: step-security/harden-runner@v2  # SHA: def456...
- uses: github/codeql-action/init@v3  # SHA: ghi789...
Copy

SHA Pinning Policy:

• All GitHub Actions MUST be pinned to full commit SHA, not tags
• SHA updates allowed only via Dependabot PRs (reviewed before merge)
• No @latest or floating version references permitted
• Reviewed quarterly or when Dependabot raises update

Dependabot Automation

Dependabot is configured in .github/dependabot.yml with:

• npm packages: Daily scan, auto-PR for patch updates
• GitHub Actions: Weekly scan, auto-PR for SHA updates
• Auto-merge: Patch-level security updates (no API changes)
• Manual review: Major and minor version updates

npm Package Audit Process

# Integrated into CI/CD pipeline (GitHub Actions):
npm audit --audit-level=high  # Blocks pipeline on high+ CVEs
npm audit --json > audit-report.json  # Archive audit results
Copy

Audit gates:

• critical: Blocks deployment immediately
• high: Blocks deployment + creates Dependabot PR
• moderate: Creates advisory, does not block
• low: Logged only

GitHub Actions Supply Chain Controls

Section G: Content Integrity Controls

SHA-256 Checksums for Generated Content

Status: Planned (Target: Q3 2026) — Article-level SHA-256 hashing is not yet implemented in the content generation pipeline. The design below documents the planned approach. Currently, content integrity is assured via Git commit history, SLSA provenance attestation, and Sigstore artifact signing.

Planned Hash Generation Process (not yet implemented):

1. Article HTML content normalized (whitespace, encoding)
2. SHA-256 computed over normalized content
3. Hash stored in article metadata HTML comment
4. Hash committed to Git alongside content
5. Hash verifiable by anyone with the file

<!-- Planned article metadata format (not yet in production) -->
<!-- content-hash: sha256:a3f5c8d2e1b4... -->
<!-- generated-at: 2026-02-25T02:15:00Z -->
<!-- pipeline-run: github.com/Hack23/riksdagsmonitor/actions/runs/12345 -->
<!-- sources: riksdag-api:2024/25, cia-export:2026-02-24 -->
Copy

Current Content Integrity Controls (Active)

Git Commit Signatures as Content Provenance

• All commits to main branch require authenticated push (GitHub authentication)
• SLSA provenance attestation includes full build inputs and outputs
• Sigstore transparency log provides tamper-evident record of all signed artifacts
• Git commit SHA provides immutable reference to exact content state

Tamper Detection Approach

Section H: Credential Lifecycle Management

MCP API Credentials Lifecycle

stateDiagram-v2
    [*] --> Created
    Created --> Active : Stored in GitHub Secrets
    Active --> Expiring : Age 60+ days warning
    Expiring --> Rotating : 90-day policy triggered
    Rotating --> DualActive : New key created
    DualActive --> Updated : GitHub Secret updated
    Updated --> Active : Old key revoked
    Active --> Compromised : Security event
    Compromised --> Revoked : Immediate revocation
    Revoked --> [*]
Copy

Credential Inventory

Secret Rotation Schedule

90-Day Rotation Policy (all credentials):

• Day 0: Credential created and stored in GitHub Secrets
• Day 60: Rotation reminder generated (GitHub Issue)
• Day 80: Rotation must begin (new credential generated, dual-active period starts)
• Day 90: Old credential revoked, new credential sole active
• Day 90+: Rotation documented in credential audit log

Exception handling:

• Security events: Immediate rotation regardless of age
• Provider-mandated rotation: Follow provider timeline
• Compromised credential: Revoke within 15 minutes (P1 incident)

GitHub Secrets Management

Secrets storage:

• All API keys stored as GitHub Actions secrets (AES-256 encrypted at rest)
• Secrets never exposed in logs (GitHub automatic masking)
• Secrets not passed to fork pull requests
• Secrets accessible only to specific workflows (not all workflows)

Secret naming convention:

GITHUB_TOKEN                 # GitHub-managed workflow token
AWS_ACCESS_KEY_ID             # AWS IAM (if applicable)
AWS_SECRET_ACCESS_KEY         # AWS IAM secret
MCP_RIKSDAG_API_KEY           # riksdag-regering-mcp (if auth required)
Copy

Emergency Credential Revocation Procedure

P1 Trigger: Credential suspected compromised

1. T+0: Detect compromise (Secret Scanning alert, anomalous API usage, security report)
2. T+5min: Access provider console, revoke credential immediately
   • AWS: IAM Console > Users > Security credentials > Deactivate
   • GitHub: Settings > Developer Settings > PATs > Revoke
   • GitHub Copilot: disable affected workflow / revoke related GitHub token or PAT
3. T+10min: Update GitHub Secret with new credential (or blank to disable workflow)
4. T+15min: Verify no unauthorized usage since detection (provider access logs)
5. T+30min: Generate new credential, update GitHub Secret, re-enable workflow
6. T+60min: Document incident in GitHub Issue, review for data exposure
7. T+72h: Post-incident review, implement additional controls

Section I: Security KPIs and Metrics Dashboard

Key Performance Indicators

Security Metrics Dashboard Summary

Security KPI Reporting

Reporting Cadence:

• Real-time: Automated GitHub Security alerts, Dependabot notifications
• Daily: Dependabot scan results reviewed via GitHub Security tab
• Weekly: Manual review of open security advisories, CodeQL alerts
• Monthly: OpenSSF Scorecard review, uptime calculation, MTTP calculation
• Quarterly: Full security metrics review, threat model update, BCP test
• Annual: Security architecture review, ISMS policy review, risk register update

Section J: Architecture Decision Log (ADL)

This section documents key security architecture decisions, the options considered, and the rationale for each choice. This record provides audit evidence and supports future architecture reviews.

ADL-001: Static HTML Architecture as Security Control

ADL-002: GitHub Pages as Primary Hosting