Security: Repository & Code Security

GitHub's security tooling covers four distinct threat categories. Understanding which feature addresses which threat is the starting point for building a coherent security posture.

A well-configured dependabot.yml keeps your dependencies fresh without drowning the team in PR noise. The key levers are scheduling, grouping, and ignore rules.

Supported ecosystems

Secret scanning watches for credentials in your code. It operates in two modes: retroactive scanning (after a secret is committed) and push protection (blocking the commit before it lands).

Default patterns

GitHub maintains a list of 200+ patterns for credentials from major providers — AWS access keys, GitHub tokens, Stripe keys, Slack webhooks, GCP service accounts, Twilio keys, and dozens more. These are detected automatically without any configuration.

When a match is found on a private repo, GitHub notifies the repo admins and the commit author. For public repos, GitHub also notifies the affected service provider (e.g., AWS, Stripe) who may revoke the credential automatically.

Push protection

Push protection intercepts a push before it reaches the remote. When a secret pattern is detected, the push is rejected with a message identifying the file and pattern type:

Removing a committed secret

Bypass policies

Sometimes push protection generates false positives (a test fixture that looks like a real token). The bypass options are:

• It's used in tests — the value is a test or placeholder, not a real credential
• It's a false positive — the pattern matched but it's not actually a secret
• I'll fix it later — acknowledge and push (creates an audit event; admin can see this)

All bypasses are logged in the audit log. Org admins can configure which bypass reasons are allowed and which require explicit org-level approval.

Custom secret scanning patterns

For internal credentials (internal API keys, custom token formats), add custom patterns:

SECURITY.md

A SECURITY.md file tells security researchers how to report vulnerabilities. GitHub surfaces it in the Security tab and adds a "Report a vulnerability" button when private vulnerability reporting is enabled.

Enabling private vulnerability reporting

Settings → Security → Private vulnerability reporting → Enable. Once enabled:

• A "Report a vulnerability" button appears on the Security tab
• Reports land in a private draft security advisory, visible only to repo admins and collaborators you invite
• GitHub automatically suggests CVSS scores and CWE categories
• The reporter can collaborate on the draft advisory before it's published

A hardened private repo should have all of these enabled. Walk through Settings → Security for each repo or automate via the REST API.

Auditing security settings across all repos in an org

The dependency review action compares the dependency manifest changes in a PR against the GitHub Advisory Database. It blocks the PR if any newly added dependency has a known CVE above your severity threshold.

When the action finds a problem it posts a comment on the PR showing:

• The vulnerable package name and version being added
• The CVE ID, CVSS score, and severity
• The vulnerable version range and the minimum safe version
• A direct link to the GitHub Advisory

License compliance gate

The allow-licenses / deny-licenses inputs add a licence compatibility check at the PR level — catching GPL contamination or AGPL obligations before they reach your codebase. This is particularly valuable for commercial software that can't adopt copyleft dependencies.

When a vulnerability is found in your code (by your team or a researcher), GitHub Security Advisories give you a private workspace to draft the advisory, coordinate with the reporter, develop a patch in a private fork, and publish when ready.

Advisory lifecycle

1. Create a draft — Security tab → Advisories → New draft security advisory
2. Fill in details — affected package, vulnerable version range, severity (CVSS), CWE category, description
3. Invite collaborators — add the reporter and your security team; all communication is private
4. Request a CVE — GitHub is a CVE Numbering Authority (CNA); request a CVE ID directly from the advisory
5. Create a private fork — GitHub creates a temporary private fork where you can develop and review the fix without exposing it
6. Publish — when the fix is released, publish the advisory. It enters the GitHub Advisory Database and Dependabot begins alerting anyone who uses your package.

CVSS scoring basics

CVSS (Common Vulnerability Scoring System) v3.1 produces a score from 0–10 based on base metrics:

GitHub's advisory UI has a CVSS calculator — fill in the attack vector (network/local), privileges required, user interaction, and impact (confidentiality/integrity/availability) and it produces the score. Don't agonise over precision; a score accurate to ±1 point is sufficient for triage.

CWE categories (common ones)

The goal of blast radius minimisation is ensuring that if any single credential is compromised — through a leaked secret, a compromised runner, or a malicious dependency — the attacker can only reach a bounded subset of your systems.

The problem with repo-level secrets

Credential scoping strategy

OIDC as the ultimate blast radius minimiser

The best approach is to eliminate long-lived credentials from GitHub entirely using OIDC (Phase 6.9). When there are no stored secrets, there are no stored secrets to steal. The OIDC token is short-lived, scoped to the run, and can only be exchanged for credentials by a job that matches your IAM trust policy claims (specific repo + specific branch).