| name | open-source-governance |
| description | Open source governance, security badges, license compliance, SBOM, supply chain security, and vulnerability management per Hack23 Open Source Policy |
| license | MIT |
Open Source Governance Skill
Context
This skill applies when:
- Setting up new open source repositories
- Implementing security badges (OpenSSF Scorecard, SLSA, CII Best Practices)
- Managing license compliance and dependencies
- Generating and validating SBOMs (Software Bill of Materials)
- Handling vulnerability disclosure and remediation
- Creating governance artifacts (SECURITY.md, CONTRIBUTING.md, CODE_OF_CONDUCT.md)
- Monitoring supply chain security
- Managing exceptions to open source policies
This skill enforces Hack23 Open Source Policy v2.3 requirements for transparent, secure open source development.
Rules
1. Security Posture Evidence (Policy Section 1)
- OpenSSF Scorecard Badge: All repos MUST display OpenSSF Scorecard ≥7.0
- CII Best Practices: Minimum "Passing" level badge required
- SLSA Level 3: Build provenance and integrity attestation mandatory
- Quality Gate: SonarCloud or equivalent showing "Passed" status
- FOSSA License Compliance: License scanning badge required
- Public Metrics: All security posture metrics publicly visible
2. License Compliance Framework (Policy Section 4)
- Approved Licenses Only: Use MIT, Apache-2.0, BSD-3-Clause, ISC, PostgreSQL, Mozilla Public License 2.0
- Review Required: CC0-1.0, LGPL-2.1, LGPL-3.0 need explicit approval
- Prohibited Licenses: NEVER use GPL-2.0, GPL-3.0, AGPL-3.0, proprietary/closed-source
- Dependency Scanning: Automated license checking on every PR
- REUSE Compliance: Clear licensing for all files
3. Governance Artifacts (Policy Section 2)
- SECURITY.md: Vulnerability disclosure process, supported versions, security features
- CONTRIBUTING.md: Contribution guidelines, DCO sign-off requirements
- CODE_OF_CONDUCT.md: Community standards and enforcement
- LICENSE.md: Repository license (MIT or Apache-2.0)
- CODEOWNERS: Maintainer assignments for security-critical paths
4. Supply Chain Security (Policy Section 3)
- SBOM Generation: CycloneDX format, quality score ≥7.0/10
- Dependency Pinning: All dependencies pinned to specific versions
- Dependabot: Enabled for automated security updates
- npm audit: Zero known vulnerabilities before release
- Transitive Dependencies: Review and approve all transitive deps
5. Vulnerability Management (Policy Section 3)
- Private Disclosure: Security issues MUST be reported to security@hack23.com
- Response SLA: Initial response within 48 hours
- Remediation SLA: Critical (1 day), High (7 days), Medium (30 days), Low (90 days)
- Coordinated Disclosure: 90-day disclosure window after fix
- CVE Assignment: Request CVEs for significant vulnerabilities
Examples
✅ Good Pattern: Complete Security Badge Integration
# Repository Name
<p align="center">
<a href="https://securityscorecards.dev/viewer/?uri=github.com/Hack23/European-Parliament-MCP-Server">
<img src="https://api.securityscorecards.dev/projects/github.com/Hack23/European-Parliament-MCP-Server/badge" alt="OpenSSF Scorecard"/>
</a>
<a href="https://bestpractices.coreinfrastructure.org/projects/XXXXX">
<img src="https://bestpractices.coreinfrastructure.org/projects/XXXXX/badge" alt="CII Best Practices"/>
</a>
<a href="https://github.com/Hack23/European-Parliament-MCP-Server/attestations/">
<img src="https://slsa.dev/images/gh-badge-level3.svg" alt="SLSA 3"/>
</a>
<a href="https://sonarcloud.io/dashboard?id=Hack23_European-Parliament-MCP-Server">
<img src="https://sonarcloud.io/api/project_badges/measure?project=Hack23_European-Parliament-MCP-Server&metric=alert_status" alt="Quality Gate"/>
</a>
<a href="https://app.fossa.com/projects/git%2Bgithub.com%2FHack23%2FEuropean-Parliament-MCP-Server">
<img src="https://app.fossa.com/api/projects/git%2Bgithub.com%2FHack23%2FEuropean-Parliament-MCP-Server.svg?type=shield" alt="FOSSA Status"/>
</a>
</p>
**Security & Compliance:** All security practices align with [Hack23 ISMS-PUBLIC](https://github.com/Hack23/ISMS-PUBLIC) policies.
Evidence: CIA Repository Badges
✅ Good Pattern: SBOM Generation and Validation
name: Generate SBOM
on:
release:
types: [published]
jobs:
sbom:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Generate CycloneDX SBOM
run: |
npx @cyclonedx/cyclonedx-npm \
--output-format JSON \
--output-file sbom.json
- name: Validate SBOM Quality
run: |
# Check SBOM has required components
COMPONENT_COUNT=$(jq '.components | length' sbom.json)
if [ "$COMPONENT_COUNT" -lt 1 ]; then
echo "Error: SBOM has no components"
exit 1
fi
UNLICENSED=$(jq '.components | map(select(.licenses == null or .licenses == [])) | length' sbom.json)
if [ "$UNLICENSED" -gt 0 ]; then
echo "Error: $UNLICENSED components missing licenses"
exit 1
fi
echo "✅ SBOM quality validated"
- name: Upload SBOM to Release
uses: actions/upload-release-asset@v1
with:
upload_url: ${{ github.event.release.upload_url }}
asset_path: ./sbom.json
asset_name: sbom.json
asset_content_type: application/json
Evidence: Black Trigram SBOM Workflow
✅ Good Pattern: License Compliance Check
name: License Compliance
on: [push, pull_request]
jobs:
license-check:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Check Licenses with FOSSA
uses: fossas/fossa-action@v1
with:
api-key: ${{ secrets.FOSSA_API_KEY }}
- name: Validate Approved Licenses
run: |
# Extract all licenses from package-lock.json
npm ls --json --all | jq -r '
.. | .license? | select(. != null)
' | sort -u > licenses.txt
APPROVED="MIT|Apache-2.0|BSD-3-Clause|ISC|PostgreSQL|MPL-2.0"
while read license; do
if ! echo "$license" | grep -E "^($APPROVED)$" > /dev/null; then
echo "❌ Unapproved license: $license"
echo "See: https://github.com/Hack23/ISMS-PUBLIC/blob/main/Open_Source_Policy.md#approved-licenses"
exit 1
fi
done < licenses.txt
echo "✅ All licenses approved"
Policy Reference: Open Source Policy Section 4
✅ Good Pattern: SECURITY.md Template
# Security Policy
## Supported Versions
| Version | Supported |
| ------- | ------------------ |
| 1.x.x | :white_check_mark: |
| < 1.0 | :x: |
## Reporting a Vulnerability
**IMPORTANT:** Per [Hack23 Open Source Policy](https://github.com/Hack23/ISMS-PUBLIC/blob/main/Open_Source_Policy.md#vulnerability-management), do NOT open public issues for security vulnerabilities.
### Reporting Process
1. **Email**: security@hack23.com with detailed vulnerability report
2. **Response**: Expect initial response within 48 hours
3. **Disclosure**: Coordinated disclosure after fix (typically 90 days)
### What to Include
- Vulnerability description
- Steps to reproduce
- Potential impact
- Suggested fix (if available)
## Security Features
This project implements security controls per [Hack23 Secure Development Policy](https://github.com/Hack23/ISMS-PUBLIC/blob/main/Secure_Development_Policy.md):
### Supply Chain Security
- **OSSF Scorecard**: Target ≥8.0/10
- **SLSA Level 3**: Build provenance
- **SBOM**: CycloneDX format, quality ≥7.0/10
- **Dependencies**: All pinned to specific versions
- **Licenses**: Only approved open source licenses
### Static Analysis
- **CodeQL**: Scans on every PR
- **Dependabot**: Automated security updates
- **License Compliance**: FOSSA scanning
### Testing
- **Coverage**: 80% minimum (95% for security code)
- **Security Tests**: Input validation, auth, authorization
## Security Contacts
- **Security Team**: security@hack23.com
- **Policy Owner**: CEO, Hack23 AB
Evidence: European Parliament MCP Server SECURITY.md
✅ Good Pattern: Vulnerability Remediation Tracking
interface Vulnerability {
id: string;
severity: 'critical' | 'high' | 'medium' | 'low';
component: string;
version: string;
discoveredDate: string;
remediationDeadline: string;
status: 'open' | 'in-progress' | 'resolved' | 'risk-accepted';
assignedTo?: string;
}
const REMEDIATION_SLA_DAYS = {
critical: 1,
high: 7,
medium: 30,
low: 90,
};
function calculateDeadline(severity: Vulnerability['severity'], discovered: Date): Date {
const days = REMEDIATION_SLA_DAYS[severity];
const deadline = new Date(discovered);
deadline.setDate(deadline.getDate() + days);
return deadline;
}
async function createVulnerabilityIssue(vuln: Vulnerability): Promise<void> {
const issue = {
title: `[SECURITY] ${vuln.severity.toUpperCase()}: ${vuln.id} in ${vuln.component}`,
labels: ['security', `severity:${vuln.severity}`],
body: `
## Vulnerability Details
- **CVE/ID**: ${vuln.id}
- **Severity**: ${vuln.severity}
- **Component**: ${vuln.component}@${vuln.version}
- **Discovered**: ${vuln.discoveredDate}
- **Remediation Deadline**: ${vuln.remediationDeadline}
## SLA Reference
Per [Hack23 Open Source Policy Section 3](https://github.com/Hack23/ISMS-PUBLIC/blob/main/Open_Source_Policy.md#vulnerability-management):
- Critical: 1 day
- High: 7 days
- Medium: 30 days
- Low: 90 days
## Action Required
1. Review vulnerability details
2. Assess impact on this project
3. Implement remediation or mitigation
4. Update dependencies
5. Verify fix and close issue
`,
};
await createGitHubIssue(issue);
}
Policy Reference: Open Source Policy Section 3.2
✅ Good Pattern: Exception Management Process
interface PolicyException {
type: 'license' | 'security' | 'compliance';
reason: string;
component: string;
requestedBy: string;
requestDate: string;
approvedBy?: string;
approvalDate?: string;
expiryDate?: string;
compensatingControls: string[];
status: 'pending' | 'approved' | 'denied' | 'expired';
}
const temporaryException: PolicyException = {
type: 'license',
reason: 'Dependency X required for critical feature, GPL-3.0 license under review for replacement',
component: 'example-package@1.0.0',
requestedBy: 'developer@hack23.com',
requestDate: '2026-02-16',
expiryDate: '2026-03-18',
compensatingControls: [
'Isolated in separate module',
'Dynamic linking only',
'Alternative being evaluated',
'Legal review in progress',
],
status: 'pending',
};
const permanentException: PolicyException = {
type: 'security',
reason: 'Legacy system integration requires specific outdated dependency version',
component: 'legacy-lib@2.0.0',
requestedBy: 'architect@hack23.com',
requestDate: '2026-02-16',
compensatingControls: [
'Network isolation via VPC',
'WAF rules blocking known exploits',
'Regular security scanning',
'Monitoring and alerting',
'Incident response plan',
],
status: 'approved',
approvedBy: 'CEO',
approvalDate: '2026-02-20',
};
Policy Reference: Open Source Policy Section 8
Anti-Patterns
❌ Bad: Using Prohibited License
{
"dependencies": {
"gpl-library": "^1.0.0"
}
}
Why: Violates Open Source Policy Section 4.3 - GPL licenses create legal risks
❌ Bad: No Security Badges
# My Project
Just a cool project. // No security posture evidence!
Why: Violates Open Source Policy Section 1 - Security posture must be publicly visible
❌ Bad: Public Security Disclosure
# ISSUE #123: SQL Injection Vulnerability Found!
Steps to reproduce:
1. Go to /api/users?id=1' OR '1'='1
2. See all user data exposed
Why: Violates vulnerability disclosure process - MUST report privately to security@hack23.com
Evidence Portfolio
Reference Implementations
-
Citizen Intelligence Agency (CIA)
-
Black Trigram Game
-
CIA Compliance Manager
-
European Parliament MCP Server
Policy Documents
Compliance Checklist
Use this checklist for new repositories:
ISMS Compliance
This skill enforces the following Open Source Policy controls:
- OS-001: Public transparency through badges (Scorecard, CII, SLSA)
- OS-002: License compliance framework (approved-licence allowlist)
- OS-003: Supply-chain security (SBOM, pinned deps, OSSF Scorecard ≥ 8.0)
- OS-004: Vulnerability management (Dependabot, npm audit, CodeQL)
- OS-005: Governance artefacts (LICENSE, SECURITY.md, CONTRIBUTING.md, CODE_OF_CONDUCT.md, DCO, CODEOWNERS)
Policy References
Primary policy:
Related policies (cite in governance PRs):
