GitHub Security Triage

Overview

Security triage covers the process of identifying, assessing, and responding to security vulnerabilities and alerts in GitHub repositories. This skill includes vulnerability management, security alerts, dependency scanning, and incident response workflows.

When to use this skill: When handling security alerts, vulnerabilities, or security-related issues in GitHub repositories.

Table of Contents

1. Security Alert Workflow
2. Vulnerability Management
3. Dependency Security
4. Security Incident Response
5. Security Triage Checklist
6. Quick Reference

Security Alert Workflow

Alert Processing Flow

graph TD
    A[Security Alert] --> B[Assess Severity]
    B --> C{Critical?}
    C -->|Yes| D[Immediate Response]
    C -->|No| E[Schedule Review]
    D --> F[Create Issue]
    E --> F
    F --> G[Assign Team]
    G --> H[Develop Fix]
    H --> I[Review Fix]
    I --> J[Release Patch]
    J --> K[Update Advisory]
    K --> L[Close Alert]

Alert Types

Severity Levels

Vulnerability Management

Code Scanning Alerts

# .github/workflows/code-scanning.yml
name: Code Scanning

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  analyze:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3

      - name: Initialize CodeQL
        uses: github/codeql-action/init@v2
        with:
          languages: javascript, python

      - name: Autobuild
        uses: github/codeql-action/autobuild@v2

      - name: Perform CodeQL Analysis
        uses: github/codeql-action/analyze@v2
        with:
          category: "/language:javascript"

Vulnerability Response

## Vulnerability Response Template

### Assessment
- [ ] Vulnerability confirmed
- [ ] Impact assessed
- [ ] Exploitability determined
- [ ] Severity assigned

### Fix Development
- [ ] Fix developed
- [ ] Fix tested
- [ ] Regression testing done
- [ ] Security review completed

### Release
- [ ] Patch released
- [ ] Advisory published
- [ ] Users notified
- [ ] Documentation updated

Advisory Documentation

## Security Advisory

### Summary
Brief description of the vulnerability.

### Affected Versions
- 1.0.0 - 1.2.0

### Vulnerability Details
- CVSS Score: 7.5 (High)
- CWE: CWE-79
- Attack Vector: Network

### Patches
Upgrade to version 1.2.1 or later.

### Workarounds
Disable affected feature until patched.

### References
- CVE-2024-12345
- GHSA-abc123

Dependency Security

Dependabot Configuration

# .github/dependabot.yml
version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    open-pull-requests-limit: 10
    reviewers:
      - "@security-team"
    labels:
      - "dependencies"
      - "security"
    commit-message:
      prefix: "chore"
      prefix-development: "chore"
      include: "scope"

Security Update Workflow

graph LR
    A[Dependabot Alert] --> B[Assess Risk]
    B --> C{High Risk?}
    C -->|Yes| D[Immediate Update]
    C -->|No| E[Schedule Update]
    D --> F[Create PR]
    E --> F
    F --> G[Review]
    G --> H[Merge]
    H --> I[Monitor]

Dependency Audit

# Check for vulnerabilities
npm audit
npm audit fix

# Python dependencies
pip-audit

# Ruby dependencies
bundle audit

# GitHub Dependabot
gh api repos/:owner/:repo/dependabot/alerts

# View security advisories
gh api advisories --query package-name

Security Incident Response

Incident Classification

Response Steps

## Security Incident Response

### 1. Containment (0-4 hours)
- [ ] Identify affected systems
- [ ] Implement temporary fixes
- [ ] Block exploit vectors
- [ ] Notify stakeholders

### 2. Investigation (4-24 hours)
- [ ] Root cause analysis
- [ ] Impact assessment
- [ ] Determine scope
- [ ] Document findings

### 3. Remediation (24-72 hours)
- [ ] Develop permanent fix
- [ ] Test fix thoroughly
- [ ] Security review
- [ ] Prepare release

### 4. Recovery (72-168 hours)
- [ ] Deploy fix
- [ ] Monitor for issues
- [ ] Update documentation
- [ ] Close incident

Communication Plan

## Security Communication

### Internal Communication
- [ ] Security team notified
- [ ] Engineering team notified
- [ ] Management notified
- [ ] Legal team notified (if needed)

### External Communication
- [ ] Advisory published
- [ ] Users notified
- [ ] Customers informed
- [ ] Public statement (if needed)

### Channels
- Email: security@example.com
- GitHub Security Advisory
- Security Blog
- Social Media (if needed)

Security Triage Checklist

Alert Assessment

## Security Alert Assessment

### Initial Review
- [ ] Alert reviewed
- [ ] Severity determined
- [ ] Impact assessed
- [ ] Exploitability evaluated
- [ ] Workarounds identified

### Validation
- [ ] Vulnerability confirmed
- [ ] Affected code identified
- [ ] Reproduction steps documented
- [ ] Proof of concept created

### Classification
- [ ] Alert type classified
- [ ] CVE assigned (if applicable)
- [ ] GHSA assigned
- [ ] Response SLA determined
- [ ] Team assigned

Fix Development

## Security Fix Development

### Development
- [ ] Fix implemented
- [ ] Code reviewed
- [ ] Security tested
- [ ] Regression tested
- [ ] Documentation updated

### Testing
- [ ] Unit tests added
- [ ] Security tests added
- [ ] Integration tested
- [ ] Penetration tested
- [ ] Performance validated

### Release
- [ ] Version bumped
- [ ] Changelog updated
- [ ] Advisory published
- [ ] Release created
- [ ] Users notified

Quick Reference

GitHub CLI Commands

# View security alerts
gh api repos/:owner/:repo/code-scanning/alerts

# View dependency alerts
gh api repos/:owner/:repo/dependabot/alerts

# View secret scanning alerts
gh api repos/:owner/:repo/secret-scanning/alerts

# Create security advisory
gh api repos/:owner/:repo/security-advisories \
  --method POST \
  -f summary="Vulnerability description" \
  -f severity="high"

# Update security advisory
gh api repos/:owner/:repo/security-advisories/:ghsa_id \
  --method PATCH \
  -f state="published"

# View advisories
gh api advisories --query package-name

Security Labels

Response Time SLAs

Common Pitfalls

1. Ignoring alerts - Always respond to security alerts promptly
2. Underestimating severity - Assess impact carefully
3. No testing - Thoroughly test security fixes
4. Poor communication - Keep stakeholders informed
5. Not documenting - Document all security incidents
6. Skipping review - Security fixes need extra review
7. No monitoring - Monitor after security releases
8. Delayed disclosure - Follow responsible disclosure

Additional Resources

• GitHub Security Documentation
• Code Scanning
• Dependabot
• Secret Scanning