agentleFS
Hack23Hack23/European-Parliament-MCP-Server/.github/skills/open-source-governance/SKILL.md

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
  1. Distinctive:

    OpenSSF Scorecard Badge: All repos MUST display OpenSSF Scorecard ≥7.0

    line 27
  2. Distinctive:

    Public Metrics: All security posture metrics publicly visible

    line 32
  3. Distinctive:

    Approved Licenses Only: Use MIT, Apache-2.0, BSD-3-Clause, ISC, PostgreSQL, Mozilla Public License 2.0

    line 36
  4. Distinctive:

    Prohibited Licenses: NEVER use GPL-2.0, GPL-3.0, AGPL-3.0, proprietary/closed-source

    line 38
  5. Distinctive:

    Dependency Pinning: All dependencies pinned to specific versions

    line 53
  6. Very specific:

    All Badges: https://github.com/Hack23/European-Parliament-MCP-Server#readme

    line 439
  7. Distinctive:

    Use this checklist for new repositories:

    line 450

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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)

  1. OpenSSF Scorecard Badge: All repos MUST display OpenSSF Scorecard ≥7.0
  2. CII Best Practices: Minimum "Passing" level badge required
  3. SLSA Level 3: Build provenance and integrity attestation mandatory
  4. Quality Gate: SonarCloud or equivalent showing "Passed" status
  5. FOSSA License Compliance: License scanning badge required
  6. Public Metrics: All security posture metrics publicly visible

2. License Compliance Framework (Policy Section 4)

  1. Approved Licenses Only: Use MIT, Apache-2.0, BSD-3-Clause, ISC, PostgreSQL, Mozilla Public License 2.0
  2. Review Required: CC0-1.0, LGPL-2.1, LGPL-3.0 need explicit approval
  3. Prohibited Licenses: NEVER use GPL-2.0, GPL-3.0, AGPL-3.0, proprietary/closed-source
  4. Dependency Scanning: Automated license checking on every PR
  5. REUSE Compliance: Clear licensing for all files

3. Governance Artifacts (Policy Section 2)

  1. SECURITY.md: Vulnerability disclosure process, supported versions, security features
  2. CONTRIBUTING.md: Contribution guidelines, DCO sign-off requirements
  3. CODE_OF_CONDUCT.md: Community standards and enforcement
  4. LICENSE.md: Repository license (MIT or Apache-2.0)
  5. CODEOWNERS: Maintainer assignments for security-critical paths

4. Supply Chain Security (Policy Section 3)

  1. SBOM Generation: CycloneDX format, quality score ≥7.0/10
  2. Dependency Pinning: All dependencies pinned to specific versions
  3. Dependabot: Enabled for automated security updates
  4. npm audit: Zero known vulnerabilities before release
  5. Transitive Dependencies: Review and approve all transitive deps

5. Vulnerability Management (Policy Section 3)

  1. Private Disclosure: Security issues MUST be reported to security@hack23.com
  2. Response SLA: Initial response within 48 hours
  3. Remediation SLA: Critical (1 day), High (7 days), Medium (30 days), Low (90 days)
  4. Coordinated Disclosure: 90-day disclosure window after fix
  5. 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/json

Evidence: 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 AB

Evidence: 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 exposed

Why: Violates vulnerability disclosure process - MUST report privately to security@hack23.com

Evidence Portfolio

Reference Implementations

  1. Citizen Intelligence Agency (CIA)
  2. Black Trigram Game
  3. CIA Compliance Manager
  4. European Parliament MCP Server

Policy Documents

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):

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.