Skip to content

Open_Source_Policy.md

Latest commit

 

History

History
546 lines (428 loc) · 52.7 KB

Open_Source_Policy.md

File metadata and controls

546 lines (428 loc) · 52.7 KB

Hack23 Logo

🔓 Hack23 AB — Open Source Policy

🛡️ Demonstrating Security Excellence Through Transparent Open Source
🎯 Evidence-Based Governance for Community-Aligned Innovation

Owner Version Effective Date Review Cycle

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

🎯 Purpose Statement

Hack23 AB demonstrates that open source transparency creates competitive advantage through systematic security excellence. Our open source policy serves as both operational framework and public demonstration of our cybersecurity consulting expertise.

This policy embodies our 🌟 transparency principle - making security practices publicly verifiable while maintaining 🏆 competitive advantage through innovative implementations and 🤝 customer trust via demonstrable open source governance.

📢 Transparency Commitments

  • 🎖️ Public Security Badges: OpenSSF Scorecard, CII Best Practices, FOSSA license compliance demonstrate continuous validation
  • 🏗️ Architecture Documentation: Every repository maintains SECURITY_ARCHITECTURE.md per Secure Development Policy
  • 📊 Compliance Evidence: Real-time security posture through automated badge generation and public metrics
  • 🔍 Supply Chain Transparency: SBOM generation, dependency tracking, and vulnerability disclosure

— James Pether Sörling, CEO/Founder

🔍 Purpose & Scope

This policy establishes comprehensive governance for creating, maintaining, and contributing to open source projects, ensuring 🔄 operational excellence and 💡 innovation enablement.

Scope:

  • All Hack23-owned repositories and organizations
  • Forks and derivatives under Hack23 control
  • Contributions made by Hack23 personnel to external projects
  • Third-party open source usage and compliance

Out of scope: Internal-only repositories not intended for public distribution

🧭 Core Principles

  1. 🌟 Transparency: Security posture and governance evidence publicly visible through badges and documentation
  2. 🔐 Security-by-default: Preventive controls per Secure Development Policy with evidence-based validation
  3. ✅ Compliance-first: License compliance via FOSSA, REUSE, and automated scanning
  4. 🤝 Community respect: Follow upstream guidelines, maintain attribution, enforce code of conduct
  5. 📊 Evidence-based: All security claims backed by public badges, reports, and metrics

👤 Roles & Responsibilities

CEO/Founder

  • Policy owner and final arbiter on licensing decisions
  • Exception approver for license conflicts or security issues
  • Strategic open source direction and partnership decisions

Repository Maintainer

  • Ensures policy compliance through badge integration
  • Maintains security documentation per Secure Development Policy
  • Manages vulnerability disclosure and remediation

Contributors

  • Adheres to repository CONTRIBUTING.md and CODE_OF_CONDUCT.md
  • Ensures license compatibility before introducing dependencies
  • Reports security issues through proper channels

📜 Policy Requirements

🎖️ 1) Security Posture Evidence

All repositories MUST demonstrate security excellence through public badges and metrics:

🏆 Required Security Badges

  • OpenSSF Scorecard: Supply chain security assessment ≥7.0 score
  • CII Best Practices: Open source maturity at least "Passing" level
  • SLSA Level 3: Build provenance and integrity attestation
  • Quality Gate: SonarCloud or equivalent showing "Passed" status

📊 License Compliance Badges

  • FOSSA Status: License scanning and compliance verification
  • REUSE Compliant: Clear licensing information for all files
  • License Badge: Clear display of repository license

📊 Reference Implementation

🏛️ Citizen Intelligence Agency: OpenSSF Scorecard CII Best Practices SLSA 3 Quality Gate Status FOSSA Status Threat Model STRIDE Analysis Attack Trees

🎮 Black Trigram: OpenSSF Scorecard CII Best Practices SLSA 3 Quality Gate Status FOSSA Status Security Rating License Threat Model Gaming Security Cultural Heritage

📊 CIA Compliance Manager: OpenSSF Scorecard CII Best Practices SLSA 3 Quality Gate Status FOSSA Status Security Rating License Threat Model Risk Assessment Mitigations

🇪🇺 European Parliament MCP Server: OpenSSF Scorecard CII Best Practices SLSA 3 License Security Architecture CRA Self Assessment Complete Documentation

🇪🇺 EU Parliament Monitor: OpenSSF Scorecard CII Best Practices SLSA 3 License Security Architecture CRA Self Assessment Complete Documentation

🗳️ Riksdagsmonitor: OpenSSF Scorecard CII Best Practices SLSA 3 License Security Architecture CRA Self Assessment Complete Documentation

📋 2) Governance Artifacts

Every repository MUST maintain comprehensive governance documentation:

🔐 Security Documentation Requirements

Per Secure Development Policy:

  • SECURITY_ARCHITECTURE.md: Current security implementation with Mermaid diagrams
  • FUTURE_SECURITY_ARCHITECTURE.md: Planned security improvements roadmap
  • SECURITY.md: Coordinated vulnerability disclosure process
  • WORKFLOWS.md: CI/CD pipeline documentation with security gates

📊 Implementation Evidence:

📜 License & Compliance Documentation

  • LICENSE: OSI-approved license clearly stated
  • NOTICE: Attribution for third-party components
  • LICENSES/: Directory containing all dependency licenses (automated via FOSSA)
  • .reuse/dep5: Machine-readable licensing information
  • CRA-ASSESSMENT.md: EU Cyber Resilience Act compliance assessment

📊 Implementation Evidence:

🤝 Community Documentation

  • CODE_OF_CONDUCT.md: Community behavior standards
  • CONTRIBUTING.md: Contribution guidelines and requirements
  • README.md: Must include "Project Classification" section per Classification Framework

📊 Implementation Evidence:

🔒 3) Security Implementation Requirements

🛡️ Supply Chain Security

Aligned with Secure Development Policy:

  • SBOM Generation: CycloneDX or SPDX format for all releases
  • Dependency Scanning: Automated vulnerability detection via Dependabot/Renovate
  • License Scanning: FOSSA integration for continuous compliance monitoring
  • Artifact Signing: Sigstore/cosign for release integrity

📊 Implementation Evidence:

🔍 Vulnerability Management

Per Vulnerability Management SLAs:

  • Critical: Remediation within 24 hours
  • High: Remediation within 7 days
  • Medium: Remediation within 30 days
  • Low: Remediation within 90 days

📊 Live Security Status:

📊 Security Testing Integration

As defined in Secure Development Policy:

  • SAST: SonarCloud or equivalent on every commit
  • SCA: Dependency vulnerability scanning
  • Secret Scanning: GitHub secret scanning or equivalent
  • DAST: OWASP ZAP for web applications

📊 Testing Evidence:

📊 4) License Compliance Framework

✅ Approved Licenses (Pre-approved)

  • Permissive: MIT, Apache 2.0, BSD (2/3-clause), ISC
  • Weak Copyleft: LGPL 2.1/3.0, MPL 2.0, EPL 2.0
  • Documentation: CC-BY-4.0, CC-BY-SA-4.0

⚠️ Review Required Licenses

  • Strong Copyleft: GPL 2.0/3.0, AGPL 3.0 (CEO approval required)
  • Non-standard: Custom or modified licenses
  • Commercial: Dual-licensed components

❌ Prohibited Licenses

  • Licenses with advertising clauses
  • Licenses incompatible with our primary license
  • Licenses with unclear terms or missing attribution

🔍 License Compliance Validation

  • Automated Scanning: FOSSA runs on every pull request
  • Manual Review: Required for license conflicts or exceptions
  • Compliance Reports: Monthly FOSSA reports reviewed by CEO
  • Attribution Management: Automated NOTICE file generation

📊 FOSSA Integration Evidence:

🏷️ 5) Classification & Documentation

Per Classification Framework:

📋 Required Classification Elements

Each project README MUST declare:

  • CIA Triad: Confidentiality, Integrity, Availability levels
  • Business Impact: Financial, Operational, Reputational, Regulatory
  • RTO/RPO: Recovery objectives aligned with classification
  • Strategic Value: ROI and competitive positioning

📊 Classification Implementation:

🔐 6) Data Protection Requirements

Aligned with Data Classification Policy:

🚫 Prohibited Data in Repositories

  • Personal data (PII/GDPR regulated)
  • Confidential business information
  • Production credentials or API keys
  • Customer data or analytics

✅ Acceptable Data Practices

  • Anonymized or synthetic test data only
  • Example configurations with placeholder values
  • Documentation with redacted sensitive information
  • Public datasets with appropriate licensing

🤝 7) Third-Party Contributions

📥 Accepting External Contributions

  • CLA/DCO: Developer Certificate of Origin required
  • License Compatibility: Verify contribution license alignment
  • Security Review: Code review per Change Management
  • Attribution: Maintain CONTRIBUTORS file

📊 Contribution Evidence:

🛡️ Security Evidence Framework

📊 CRA Conformity Assessment Evidence

Demonstrating EU Cyber Resilience Act compliance readiness through systematic self-assessment:

📊 CRA Assessment Portfolio:

🔍 CRA Essential Requirements Coverage:

  • Annex I § 1.1: Secure by Design architecture documentation
  • Annex I § 2.2: Coordinated vulnerability disclosure via SECURITY.md
  • Annex I § 2.3: SBOM generation for all releases
  • Annex I § 2.4: Signed updates with SLSA attestations
  • Annex I § 2.5: Comprehensive security monitoring and logging

🏗️ Security Architecture Excellence

📊 Architecture Documentation:

🎯 Threat Modeling Maturity Matrix:

Project STRIDE Coverage Attack Trees Risk Quantification Control Mapping Public Documentation
🏛️ CIA Complete Documented Quantified Mapped Public
🎮 Black Trigram Complete Documented Quantified Mapped Public
📊 CIA Compliance Complete Documented Quantified Mapped Public
🇪🇺 EP MCP Server Architecture Architecture SLSA Mapped Public
🇪🇺 EU Parliament Monitor Architecture Architecture SLSA Mapped Public
🗳️ Riksdagsmonitor Architecture Architecture Scorecard Mapped Public

📊 Evidence Dashboard

🏆 Security Excellence Metrics:

Evidence Category CIA Black Trigram CIA Compliance Manager EP MCP Server EU Parliament Monitor Riksdagsmonitor
🛡️ Threat Models THREAT_MODEL.md THREAT_MODEL.md THREAT_MODEL.md — — —
🏗️ Security Architecture SECURITY_ARCHITECTURE.md SECURITY_ARCHITECTURE.md SECURITY_ARCHITECTURE.md SECURITY_ARCHITECTURE.md SECURITY_ARCHITECTURE.md SECURITY_ARCHITECTURE.md
⚖️ CRA Assessment CRA-ASSESSMENT.md CRA-ASSESSMENT.md CRA-ASSESSMENT.md — — —
🔐 Security Policy SECURITY.md SECURITY.md SECURITY.md SECURITY.md — —
🏷️ License LICENSE LICENSE LICENSE LICENSE LICENSE LICENSE

🔍 Live Security Monitoring:

  • 📊 GitHub Security: Organization-wide security posture via Security Overview
  • 🎯 OpenSSF Tracking: Continuous scorecard monitoring across all repositories
  • ⚖️ FOSSA Compliance: Real-time license compliance status for all projects
  • 🛡️ Vulnerability Management: Active security advisory and dependabot integration

📊 Compliance Monitoring & Metrics

🎯 Key Performance Indicators

Tracked via Security Metrics:

  • OpenSSF Score: Target ≥7.0 for all repositories
  • License Compliance: 100% FOSSA approval rate
  • Vulnerability Response: SLA compliance rate ≥95%
  • Documentation Coverage: 100% of repos with required artifacts
  • CRA Readiness: Complete self-assessments for EU market products
  • Threat Model Coverage: 100% of products with public threat analysis

📊 Live Compliance Dashboard:

📈 Continuous Monitoring

  • Weekly: Automated security scanning results review
  • Monthly: License compliance report from FOSSA
  • Quarterly: Policy compliance assessment
  • Annually: Strategic open source review

📊 Monitoring Evidence:

📊 Public Transparency Dashboard

Live metrics available at:

🔄 Integration with SDLC

This policy integrates with our development lifecycle as defined in Secure Development Policy:

📋 Planning Phase

  • License strategy selection based on business goals
  • Security architecture documentation requirements
  • Community engagement planning

📊 Planning Evidence:

💻 Development Phase

  • Continuous license scanning via FOSSA
  • Security testing per SDLC requirements
  • Documentation maintained alongside code

📊 Development Evidence:

🚀 Release Phase

  • SBOM generation and publication
  • Artifact signing and attestation
  • Security badge verification

📊 Release Evidence:

🔧 Maintenance Phase

  • Vulnerability monitoring and patching
  • License compliance updates
  • Community support and engagement

📊 Maintenance Evidence:

🚨 Exception Management

📋 Exception Request Process

  1. Document business justification
  2. Identify compensating controls
  3. Define exception duration
  4. Submit to CEO for approval

⏱️ Exception Types

  • Temporary: Maximum 90 days for specific issues
  • Project-specific: Limited to single repository
  • Strategic: Long-term exceptions with quarterly review

📊 Exception Tracking

📚 Related Documents

🔐 Core Security Integration

📊 Compliance & Classification

🤝 Third-Party Management

📈 Monitoring & Reporting

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