Enterprise Readiness Assessment

When to Use

• Evaluating projects for production/enterprise readiness
• Implementing supply chain security (SLSA, signing, SBOMs)
• Hardening CI/CD pipelines
• Establishing quality gates
• Pursuing OpenSSF Best Practices Badge (Passing/Silver/Gold)
• Reviewing code or PRs for quality
• Writing ADRs, changelogs, or migration guides
• Configuring Git hooks or CI pipelines

MANDATORY Requirements

CRITICAL: The following are NOT optional. Every project MUST have ALL of these. Do not skip any.

README Badges (MANDATORY)

Every project README.md MUST display these badges at the top, in this order:

<!-- Row 1: CI/Quality -->
[![CI](https://github.com/ORG/REPO/actions/workflows/ci.yml/badge.svg)](https://github.com/ORG/REPO/actions/workflows/ci.yml)
[![codecov](https://codecov.io/gh/ORG/REPO/graph/badge.svg)](https://codecov.io/gh/ORG/REPO)

<!-- Row 2: Security (MANDATORY) -->
[![OpenSSF Scorecard](https://api.securityscorecards.dev/projects/github.com/ORG/REPO/badge)](https://securityscorecards.dev/viewer/?uri=github.com/ORG/REPO)
[![OpenSSF Best Practices](https://www.bestpractices.dev/projects/PROJECT_ID/badge)](https://www.bestpractices.dev/projects/PROJECT_ID)

CI/CD Workflows (MANDATORY)

Every GitHub project MUST have these workflows in .github/workflows/:

CI Must Include (MANDATORY)

Supply Chain Security (MANDATORY for Releases)

Supply chain security controls MUST block releases when violated.

Release Workflow Order (MANDATORY)

Supply chain artifacts MUST be generated in this order:

1. CI passes (tests, lint, security audit)
     ↓
2. Create SIGNED tag locally: git tag -s vX.Y.Z
     ↓
3. Push signed tag: git push origin vX.Y.Z
     ↓
4. Create release on existing tag: gh release create vX.Y.Z
     ↓
5. SLSA provenance workflow triggers (workflow_run)
     ↓
6. Provenance attestation uploaded to release
     ↓
7. SBOM generated and uploaded

NEVER use gh release create without a pre-existing signed tag - this creates unsigned tags.

CI Integration for Supply Chain

Add to .github/workflows/release.yml:

# Pre-release checks (block release if failed)
- name: Security Audit
  run: |
    composer audit --format=plain || exit 1
    npm audit --audit-level=high || exit 1

# SBOM generation
- name: Generate SBOM
  uses: anchore/sbom-action@v0
  with:
    artifact-name: sbom.spdx.json
    output-file: sbom.spdx.json

- name: Upload SBOM to release
  run: gh release upload ${{ github.ref_name }} sbom.spdx.json
  env:
    GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Verification of Supply Chain Artifacts

Before announcing a release, verify:

• Release tag is GPG/SSH signed: git tag -v vX.Y.Z
• SLSA provenance exists: multiple.intoto.jsonl in release assets
• SBOM exists: sbom.spdx.json or sbom.cyclonedx.json in release assets
• No HIGH/CRITICAL CVEs: composer audit / npm audit clean

See references/slsa-provenance.md for detailed SLSA implementation guide.

OpenSSF Registration (MANDATORY)

1. Register at bestpractices.dev: https://www.bestpractices.dev/en/projects/new
2. Note the Project ID assigned after registration
3. Add badge to README with correct PROJECT_ID
4. Run Scorecard workflow to generate initial score

Codecov Setup (MANDATORY)

1. Enable Codecov for the repository at codecov.io
2. Collect coverage from ALL test suites (not just unit tests):

3. Upload ALL coverage files to Codecov:
   yamlCopy

   - uses: codecov/codecov-action@SHA # vX.Y.Z
     with:
       token: ${{ secrets.CODECOV_TOKEN }}  # MANDATORY - see below
       files: .Build/coverage/unit.xml,.Build/coverage/integration.xml,.Build/coverage/e2e.xml,coverage/lcov.info
       fail_ci_if_error: false
   

CODECOV_TOKEN (MANDATORY)

Never rely on tokenless uploads. They fail for protected branches and are unreliable.

Failure without token:

Upload failed: {"message":"Token required because branch is protected"}

Get token from: https://app.codecov.io/gh/ORG/REPO/settings

Add as org secret (recommended):

# Organization-level (covers all repos)
gh secret set CODECOV_TOKEN --org netresearch --visibility all

# Or repository-level
gh secret set CODECOV_TOKEN --repo OWNER/REPO

JavaScript Coverage (MANDATORY for projects with JS/TS)

When a project contains JavaScript or TypeScript files:

1. vitest.config.js MUST include lcov reporter for Codecov:

   javascriptCopy

   coverage: {
       provider: 'v8',
       reporter: ['text', 'json', 'html', 'lcov'],  // lcov REQUIRED for Codecov
       reportsDirectory: 'coverage',
   }
   

2. CI workflow MUST include JavaScript test job:

   yamlCopy

   - uses: actions/setup-node@SHA # vX.Y.Z
     with:
       node-version: '22'
   - run: npm install
   - run: npm run test:coverage
   

3. Codecov upload MUST include coverage/lcov.info

Verification Checklist

Before marking enterprise-readiness complete, verify ALL:

• README has CI badge linking to workflow
• README has Codecov badge (not "unknown")
• README has OpenSSF Scorecard badge (correct URL with api.securityscorecards.dev)
• README has OpenSSF Best Practices badge (correct PROJECT_ID, not placeholder)
• .github/workflows/ci.yml exists and uploads coverage
• .github/workflows/codeql.yml exists
• .github/workflows/scorecard.yml exists
• Codecov shows actual coverage percentage
• Scorecard shows actual score

If any badge shows "unknown", "invalid", or placeholder ID - FIX IT. Do not proceed.

Assessment Workflow

1. Discovery: Identify platform (GitHub/GitLab), languages, existing CI/CD
2. Scoring: Apply checklists from references based on stack
3. Badge Assessment: Check OpenSSF criteria status
4. Gap Analysis: List missing controls by severity
5. Implementation: Apply fixes using scripts and templates
6. Verification: Re-score and compare (see Post-Implementation Verification)

Post-Implementation Verification

MANDATORY: After implementing improvements, re-assess the project to verify gains.

Re-Scoring Workflow

1. Record baseline score before making changes (save output)
2. Implement improvements following gap analysis priorities
3. Re-run full assessment using same criteria
4. Compare scores and document delta

Verification Checklist

Expected Outcomes

Verification Commands

# OpenSSF Scorecard (re-run after changes merged to default branch)
scorecard --repo=github.com/ORG/REPO --format=json

# Coverage (after CI runs)
# Check Codecov dashboard or badge

# Best Practices (update at bestpractices.dev after implementing)
# Re-answer questions that are now satisfied

If score did not improve as expected, investigate:

• Did CI workflows run successfully?
• Are badges pointing to correct repository?
• Did changes merge to default branch (required for Scorecard)?

Continuous Improvement

Enterprise readiness is not a one-time achievement. Maintain scores over time.

Scheduled Re-Assessment

Automated Monitoring

Add badge health check to CI:

# .github/workflows/badge-health.yml
name: Badge Health Check
on:
  schedule:
    - cron: '0 6 * * 1'  # Weekly Monday 6am
  workflow_dispatch:

jobs:
  check-badges:
    runs-on: ubuntu-latest
    steps:
      - name: Check Codecov
        run: |
          BADGE_URL="https://codecov.io/gh/${{ github.repository }}/graph/badge.svg"
          curl -sL "$BADGE_URL" | grep -q "unknown" && echo "::warning::Codecov badge shows unknown" || true

      - name: Check Scorecard
        run: |
          SCORE=$(curl -s "https://api.securityscorecards.dev/projects/github.com/${{ github.repository }}" | jq -r '.score // "N/A"')
          echo "Current Scorecard: $SCORE/10"
          if [ "$SCORE" != "N/A" ] && [ "$(echo "$SCORE < 7" | bc -l)" = "1" ]; then
            echo "::warning::Scorecard dropped below 7.0"
          fi

Regression Detection

Watch for these warning signs:

Dependency Update Cadence

Dependency CVE Workflow

When assessing enterprise readiness, always run dependency audit as part of discovery:

# PHP/Composer
composer audit

# Node.js
npm audit

# Python
pip-audit

# Go
govulncheck ./...

CVE Handling Best Practice

Separate dependency updates from code changes:

Real-world example from t3x-cowriter review:

• Found 4 CVEs during enterprise assessment
• CVE fixes required composer update typo3/cms-core typo3/cms-backend
• Kept separate from code fixes (JS bug, AGENTS.md updates) for clean PR history

CVE Severity Response

CI Integration

Add dependency audit to CI pipeline:

# .github/workflows/ci.yml
- name: Security audit
  run: composer audit --format=plain

Reference Files (Load Based on Stack)

Quality & Process References (Language-Agnostic)

Explicit Content Triggers

When reviewing PRs or code, load references/code-review.md for the comprehensive checklist covering test resource management, state mutation, defensive enum handling, documentation accuracy, and defensive code coverage.

When writing ADRs (Architecture Decision Records), load references/documentation.md for templates, file organization, and required sections (Context, Decision, Consequences, Alternatives).

When writing changelogs or release notes, load references/documentation.md for Keep a Changelog format and conventional commit mapping.

When writing API documentation or migration guides, load references/documentation.md for structure patterns and completeness checklists.

When configuring CI/CD pipelines, load references/ci-patterns.md for comprehensive pipeline structure, job ordering, and quality gates.

When setting up Git hooks (pre-commit/pre-push), load references/ci-patterns.md for the hook division strategy and Lefthook configuration.

When enforcing coverage thresholds, load references/ci-patterns.md for threshold tables and enforcement patterns.

When handling signed commits with rebase-only merge, load references/ci-patterns.md for the local fast-forward merge workflow.

Implementation Guides

Automation Scripts

Document Templates

Templates in assets/templates/:

• GOVERNANCE.md - Project governance (Silver)
• ARCHITECTURE.md - Technical docs (Silver)
• CODE_OF_CONDUCT.md - Contributor Covenant v3.0
• SECURITY_AUDIT.md - Security audit (Gold)
• BADGE_EXCEPTIONS.md - N/A justifications

CI Workflow Templates

GitHub Actions workflows in assets/workflows/:

Copy workflows to .github/workflows/ and pin action versions with SHA hashes.

Scoring Interpretation

Code Review Quick Checklist

Before approving PRs, verify (see references/code-review.md for details):

• One resource per test - No duplicate instances
• State mutation complete - Tracking fields updated after operations
• Defensive enum handling - Valid() method, default case, tested
• Documentation accurate - Claims match benchmarks, trade-offs noted
• Platform code marked - Limitations documented, alternatives provided
• Defensive code tested - Error paths and edge cases covered

Critical Rules

• NEVER interpolate ${{ github.event.* }} in run: blocks (script injection)
• NEVER guess action versions - always fetch from GitHub API
• ALWAYS use SHA pins for actions with version comments
• ALWAYS verify commit hashes against official tags

Related Skills

Resources

• OpenSSF Scorecard
• Best Practices Badge
• SLSA Framework
• S2C2F

Contributing: Improvements to this skill should be submitted to the source repository: https://github.com/netresearch/enterprise-readiness-skill