Open Source Policy

Open Source Policy Skill

Purpose

This skill provides comprehensive open source governance aligned with Hack23 AB's transparency principle, demonstrating that radical openness creates competitive advantage through evidence-based security excellence. It enables repository maintainers to implement required security badges, manage license compliance, generate SBOMs, and maintain security documentation that serves as both operational necessity and client demonstration.

When to Use This Skill

Apply this skill when:

• ✅ Creating new public repositories
• ✅ Preparing for OpenSSF Scorecard assessment (target: ≥7.0)
• ✅ Configuring CII Best Practices badge (minimum: Passing)
• ✅ Setting up SLSA Level 3 build attestations
• ✅ Implementing license compliance scanning (FOSSA)
• ✅ Generating SBOMs (CycloneDX/SPDX)
• ✅ Creating security architecture documentation
• ✅ Planning coordinated vulnerability disclosure
• ✅ Responding to client due diligence requests

Do NOT use for:

• ❌ Private/internal repositories (different policy applies)
• ❌ Security incident response (use incident-response skill)
• ❌ Tactical vulnerability remediation (use vulnerability-management skill)

Required Security Badge Architecture

graph TB
    REPO["📦 Repository"] --> BADGES["🎖️ Security Badges"]
    
    BADGES --> OSS[OpenSSF Scorecard<br/>Target: ≥7.0]
    BADGES --> CII[CII Best Practices<br/>Minimum: Passing]
    BADGES --> SLSA[SLSA Level 3<br/>Build Attestation]
    BADGES --> QUALITY[Quality Gate<br/>SonarCloud: Passed]
    BADGES --> LICENSE[License Compliance<br/>FOSSA: Passing]
    
    OSS --> OSS_CHECKS{15 Automated Checks}
    OSS_CHECKS --> BRANCH[Branch Protection]
    OSS_CHECKS --> SIGNED[Signed Commits]
    OSS_CHECKS --> PINNED[Pinned Dependencies]
    OSS_CHECKS --> VULN[Vulnerability Scanning]
    OSS_CHECKS --> CODE_REVIEW[Code Review]
    
    CII --> CII_CRITERIA{70+ Criteria}
    CII_CRITERIA --> BASICS[Project Basics]
    CII_CRITERIA --> CHANGE[Change Control]
    CII_CRITERIA --> QUALITY_CII[Quality Assurance]
    CII_CRITERIA --> SECURITY[Security]
    CII_CRITERIA --> ANALYSIS[Analysis]
    
    SLSA --> BUILD_INTEGRITY[Build Provenance<br/>Signed Artifacts<br/>Reproducible Builds]
    
    QUALITY --> SONAR_METRICS[Code Coverage ≥80%<br/>Complexity Control<br/>Security Hotspots = 0]
    
    LICENSE --> FOSSA_SCAN[Automated License Scan<br/>Attribution Management<br/>Compliance Reports]
    
    BRANCH --> EVIDENCE["📊 Public Evidence"]
    SIGNED --> EVIDENCE
    QUALITY_CII --> EVIDENCE
    BUILD_INTEGRITY --> EVIDENCE
    SONAR_METRICS --> EVIDENCE
    FOSSA_SCAN --> EVIDENCE
    
    EVIDENCE --> CLIENTS["🤝 Client Trust<br/>Competitive Advantage"]
    
    style REPO fill:#1565C0,stroke:#0D47A1,stroke-width:3px,color:#fff
    style BADGES fill:#4CAF50,stroke:#2E7D32,stroke-width:2px,color:#fff
    style EVIDENCE fill:#FF9800,stroke:#F57C00,stroke-width:2px
    style CLIENTS fill:#9C27B0,stroke:#6A1B9A,stroke-width:2px,color:#fff

Repository Setup Checklist

Phase 1: Initial Security Configuration

• Enable branch protection on main/master:
  • Require pull request reviews (1+ approvers)
  • Require status checks to pass
  • Require signed commits
  • Restrict push access
• Enable Dependabot security updates
• Enable GitHub secret scanning
• Configure CodeQL analysis
• Set up automated security scanning (SonarCloud)

Phase 2: Documentation Requirements

• Create SECURITY_ARCHITECTURE.md with Mermaid diagrams
• Create FUTURE_SECURITY_ARCHITECTURE.md for roadmap
• Create SECURITY.md with vulnerability disclosure process
• Create WORKFLOWS.md documenting CI/CD security gates
• Create LICENSE (Apache 2.0 or compatible)
• Create NOTICE for third-party attributions
• Create CODE_OF_CONDUCT.md
• Create CONTRIBUTING.md
• Create CRA-ASSESSMENT.md (EU Cyber Resilience Act)

Phase 3: License Compliance

• Integrate FOSSA scanning
• Generate LICENSES/ directory with all dependency licenses
• Add .reuse/dep5 for machine-readable licensing
• Configure automated NOTICE file generation
• Review all dependencies for license compatibility

Phase 4: Security Badges

• Register with OpenSSF Scorecard: https://scorecard.dev/
• Apply for CII Best Practices: https://bestpractices.coreinfrastructure.org/
• Configure SLSA attestations in GitHub Actions
• Add SonarCloud quality gate badge
• Add FOSSA license status badge
• Add custom security badges (Threat Model, STRIDE, etc.)

Phase 5: Supply Chain Security

• Implement SBOM generation (CycloneDX or SPDX)
• Configure artifact signing (Sigstore/cosign)
• Pin all GitHub Actions dependencies
• Enable Dependabot version updates
• Set up automated vulnerability scanning

OpenSSF Scorecard Optimization Guide

Target score: ≥7.0 across 15 automated checks

Critical Checks (Must Pass)

1. Branch-Protection (Weight: High)

# .github/branch-protection.yml
required_status_checks:
  strict: true
  contexts:
    - "CodeQL"
    - "SonarCloud Code Analysis"
    - "Security Scan"
required_pull_request_reviews:
  required_approving_review_count: 1
  dismiss_stale_reviews: true
enforce_admins: true
restrictions: null

2. Signed-Releases (Weight: High)

# .github/workflows/release.yml
- name: Sign artifacts
  uses: sigstore/gh-action-sigstore-python@cd84bbf8fc2bdfd61e0b9bb63e1a18050dd9ff99 # v2.1.1
  with:
    inputs: ./dist/*
- name: Generate SBOM
  uses: anchore/sbom-action@d94f46e13c6c62f59525ac9a1e147a99dc0b9bf5 # v0.15.1
  with:
    format: cyclonedx-json

3. Pinned-Dependencies (Weight: High)

# Pin ALL dependencies to specific SHA
# Bad:
uses: actions/checkout@v4
# Good:
uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1

4. Token-Permissions (Weight: High)

# .github/workflows/*.yml
permissions:
  contents: read  # Least privilege
  security-events: write  # Only if needed

5. Vulnerabilities (Weight: High)

• Enable Dependabot alerts
• Configure CodeQL scanning
• Integrate SonarCloud security analysis
• Set SLAs for vulnerability remediation (see below)

6. Code-Review (Weight: High)

• Require at least 1 approving review
• No commits directly to default branch
• Use CODEOWNERS file

Important Checks (Should Pass)

7. Dangerous-Workflow

• Don't use pull_request_target without security review
• Avoid script injection from user-controlled data

8. License

• Include LICENSE file (Apache 2.0)
• Add SPDX identifier to source files

9. SAST

• Enable CodeQL with security queries
• Add SonarCloud with Security Hotspot detection

10. Dependency-Update-Tool

• Enable Dependabot for both security and version updates

# .github/dependabot.yml
version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    open-pull-requests-limit: 10

Additional Checks

11. Fuzzing (Java/Spring projects)

• Configure JQF for fuzz testing where applicable

12. Maintained

• Commit at least every 90 days
• Respond to issues within 14 days

13. Packaging

• Publish to npm/Maven Central with provenance

14. Security-Policy

• Maintain SECURITY.md with disclosure process

15. Binary-Artifacts

• Avoid committing binary files (use package managers)

CII Best Practices Badge Requirements

Apply for badge at: https://bestpractices.coreinfrastructure.org/

Passing Level (Minimum Required)

Basics (13 criteria):

• Project website URL
• Basic project documentation
• FLOSS license (Apache 2.0)
• Public version-controlled source repository
• Public discussion forum (GitHub Issues)
• English language communication
• Bug reporting process (SECURITY.md)
• Security vulnerability disclosure (SECURITY.md)
• Working build system
• Automated test suite
• New functionality testing
• Warning flags enabled
• Release notes for each version

Change Control (6 criteria):

• Public version control (GitHub)
• Unique version numbering (SemVer)
• Changelog maintained
• Previous versions available
• Identification of committers
• Commit review before integration

Quality (13 criteria):

• Automated test suite runs on CI
• Build warnings free
• Static analysis (SonarCloud)
• Dynamic analysis (OWASP ZAP for web apps)
• Memory safety (Java/managed languages)
• Automated test suite covers ≥80% statements
• Test suite covers ≥70% branches
• New tests added with new features
• Continuous integration tests
• Test policy documented

Security (11 criteria):

• Secure coding standards documented
• HTTPS for website/downloads
• TLS 1.2+ for encrypted connections
• Secure delivery mechanism (signed releases)
• Automated security vulnerability detection
• No known unpatched critical vulnerabilities
• Public vulnerability disclosure process
• Private vulnerability reporting channel
• Hardening mechanism documented
• Crypto published/peer-reviewed
• Input validation

Analysis (10 criteria):

• Static code analysis
• Address all medium+ severity issues
• Memory-safe language or analysis
• Dynamic analysis on releases
• Code coverage measurement
• Continuous automated testing

Reference Implementation:

• CIA Platform (Passing)
• Black Trigram (Passing)
• CIA Compliance Manager (Passing)