open-source-governance
Skill30 starsChanged 9 months agoApache-2.0View on GitHub
Open source governance, security badges, license compliance, SBOM, supply chain security, and vulnerability management per Hack23 Open Source Policy
- Reads credentials
We split this skill into the rules it gives an agent
7 rules. About 0 are common, 6 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈6
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 27
OpenSSF Scorecard Badge: All repos MUST display OpenSSF Scorecard ≥7.0
- Distinctive: line 32
Public Metrics: All security posture metrics publicly visible
- Distinctive: line 36
Approved Licenses Only: Use MIT, Apache-2.0, BSD-3-Clause, ISC, PostgreSQL, Mozilla Public License 2.0
- Distinctive: line 38
Prohibited Licenses: NEVER use GPL-2.0, GPL-3.0, AGPL-3.0, proprietary/closed-source
- Distinctive: line 53
Dependency Pinning: All dependencies pinned to specific versions
- Very specific: line 439
All Badges: https://github.com/Hack23/European-Parliament-MCP-Server#readme
- Distinctive: line 450
Use this checklist for new repositories:
≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
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
# .github/workflows/sbom.yml
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
# Validate all components have licenses
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/jsonEvidence: Black Trigram SBOM Workflow
✅ Good Pattern: License Compliance Check
# .github/workflows/license-check.yml
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
# Check against approved list
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 ABEvidence: European Parliament MCP Server SECURITY.md
✅ Good Pattern: Vulnerability Remediation Tracking
/**
* Vulnerability remediation tracker
*
* ISMS Policy: Open Source Policy Section 3 - Vulnerability Management
* Evidence: https://github.com/Hack23/ISMS-PUBLIC/blob/main/Open_Source_Policy.md#vulnerability-management
*/
interface Vulnerability {
id: string; // CVE-YYYY-NNNNN or GHSA-XXXX-XXXX-XXXX
severity: 'critical' | 'high' | 'medium' | 'low';
component: string; // Affected dependency
version: string; // Vulnerable version
discoveredDate: string; // ISO 8601 date
remediationDeadline: string; // Based on severity SLA
status: 'open' | 'in-progress' | 'resolved' | 'risk-accepted';
assignedTo?: string;
}
// SLA per Open Source Policy Section 3
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;
}
// Track in issue tracker
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
`,
};
// Create GitHub issue via API
await createGitHubIssue(issue);
}Policy Reference: Open Source Policy Section 3.2
✅ Good Pattern: Exception Management Process
/**
* Open Source Policy Exception Request
*
* ISMS Policy: Open Source Policy Section 8 - Exception Management
* Evidence: https://github.com/Hack23/ISMS-PUBLIC/blob/main/Open_Source_Policy.md#exception-management
*/
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';
}
// Temporary exception (max 30 days)
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', // 30 days
compensatingControls: [
'Isolated in separate module',
'Dynamic linking only',
'Alternative being evaluated',
'Legal review in progress',
],
status: 'pending',
};
// Permanent exception (requires CEO approval)
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
// package.json - NEVER do this!
{
"dependencies": {
"gpl-library": "^1.0.0" // GPL-3.0 is PROHIBITED
}
}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 exposedWhy: 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
- Open Source Policy v2.3: https://github.com/Hack23/ISMS-PUBLIC/blob/main/Open_Source_Policy.md
- ISMS-PUBLIC Repository: https://github.com/Hack23/ISMS-PUBLIC
Compliance Checklist
Use this checklist for new repositories:
- OpenSSF Scorecard badge displayed and score ≥7.0
- CII Best Practices badge at "Passing" level
- SLSA Level 3 provenance configured
- Quality gate badge (SonarCloud/equivalent)
- FOSSA license scanning enabled
- SECURITY.md with vulnerability disclosure process
- CONTRIBUTING.md with DCO and contribution guidelines
- CODE_OF_CONDUCT.md with community standards
- LICENSE.md with approved license (MIT/Apache-2.0)
- CODEOWNERS for security-critical paths
- SBOM generation in release workflow
- All dependencies use approved licenses
- Dependabot enabled for security updates
- npm audit passes with zero vulnerabilities
- Exception tracking for any policy deviations
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):
- Information Security Policy — Transparency, stakeholder trust
- Secure Development Policy — SBOM, SLSA, signing as SDLC outputs
- Vulnerability Management — Disclosure SLAs
- Incident Response Plan — Coordinated disclosure, GitHub Security Advisory
- Cryptography Policy — Release signing, Sigstore / cosign
- Change Management — Governance artefact updates tracked as changes
- Third Party Management — Dependency / maintainer trust
- AI Policy — Disclosure of AI-assisted contributions
In this repository41 other files it gives its agents.
- .github/copilot-instructions.mdCopilot instructions
- ai-development-governanceSkill
- ai-governanceSkill
- architecture-documentationSkill
- aws-security-architectureSkill
- behavioral-analysisSkill
- business-model-canvasSkill
- c4-architecture-documentationSkill
- code-quality-excellenceSkill
- compliance-frameworksSkill
- contribution-guidelinesSkill
- data-science-for-intelligenceSkill
- documentation-standardsSkill
- electoral-analysisSkill
- european-parliament-apiSkill
- european-political-systemSkill
- gdpr-complianceSkill
- github-actions-workflowsSkill
- github-agentic-workflowsSkill
- incident-responseSkill
- intelligence-analysis-techniquesSkill
- isms-complianceSkill
- legislative-monitoringSkill
- mcp-gateway-configurationSkill
- mcp-gateway-securitySkill
- mcp-server-developmentSkill
- osint-methodologiesSkill
- performance-optimizationSkill
- political-science-analysisSkill
- risk-assessment-frameworksSkill
- secrets-managementSkill
- secure-code-reviewSkill
- secure-development-lifecycleSkill
- security-by-designSkill
- seo-best-practicesSkill
- strategic-communication-analysisSkill
- testing-mcp-toolsSkill
- testing-strategySkill
- threat-modeling-frameworkSkill
- typescript-strict-patternsSkill
- vulnerability-managementSkill
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

