> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Demo GitHub Security Policy

> Guide to creating a repository SECURITY.md that defines vulnerability reporting, supported versions, triage timelines, encrypted reporting, and coordinated disclosure procedures

In this lesson you'll create a repository security policy that tells contributors and users how to report vulnerabilities and which product versions receive security updates. A clear SECURITY.md improves trust, reduces noisy reports, and helps coordinate responsible disclosure.

## Where to place the security policy

The security policy should be a file named `SECURITY.md`. It can live at the repository root or inside the `.github` directory. Best practice is to place it at `.github/SECURITY.md` so it’s grouped with other repository metadata (issue templates, CODEOWNERS, etc.).

Place `SECURITY.md` in `.github/SECURITY.md` (or at the repo root). If you want stricter workflow control, require pull requests to add or modify it instead of committing directly to the default branch.

## What to include in SECURITY.md

A good security policy typically covers:

* Supported versions and how long security fixes are provided for each release.
* Clear reporting channels (email address, issue template, or third-party platform).
* Expected confidentiality (e.g., “do not post details publicly before a fix”).
* Triage and response timelines (acknowledgement, initial triage, and remediation windows).
* Whether you accept encrypted reports (PGP/GPG) and how to obtain the public key.
* The disclosure process (coordinated disclosure, CVE issuance, public advisory).

Example SECURITY.md content you can adapt:

```markdown theme={null}
## Supported Versions

Use this section to tell people about which versions of your project are
currently being supported with security updates.

| Version | Supported |
| ------- | ---------------- |
| 5.1.x | :white_check_mark: |
| 5.0.x | :x: |
| 4.0.x | :white_check_mark: |
| < 4.0 | :x: |

## Reporting a Vulnerability

Use this section to tell people how to report a vulnerability.

Tell them where to go, how often they can expect to get an update on a
reported vulnerability, what to expect if the vulnerability is accepted or
declined, etc.
```

## Recommended content and examples

You can expand the Reporting section with specifics. For example, provide:

* One primary contact method (email or private issue reporter).
* Whether encrypted emails are accepted (`PGP/GPG` key fingerprint and instructions).
* A short timeline (acknowledge, initial triage timeframe, and estimated fix period).
* How to request or track a CVE.

Use a short, scannable table for supported versions and a clear step-by-step for reporting.

### Example: Reporting options (table)

| Method | When to use | Example / Notes |
| - | - | - |
| Email (private) | Report new vulnerabilities privately | `security@example.com` — support encrypted reports with PGP/GPG |
| GitHub private vulnerability report | When you prefer GitHub's workflow | Use the repository's **Security → Report a vulnerability** flow |
| Issue tracker | Non-sensitive issues or post-disclosure discussion | Public issues are not suitable for initial vulnerability reports |

Do not include sensitive details (exploit code, POCs, or victim data) in public issues. If you accept encrypted reports, publish your PGP/GPG key fingerprint and instructions in `SECURITY.md`.

## Recommended response & disclosure timelines

These are sample timelines you can adapt for your project:

* Acknowledge receipt: within 48 hours.
* Initial triage (assess severity and reproduction): within 7 days.
* Fix or mitigation plan: within 30–90 days depending on severity.
* Public advisory/CVE issuance: coordinated with reporter after fix is available.

State your project's actual timelines in `SECURITY.md` so reporters know what to expect.

## Creating and committing the policy

You can create `SECURITY.md` directly in GitHub's web editor (commit to the default branch or create a pull request), or manage it locally and push:

```bash theme={null}
# from your repository root
git add .github/SECURITY.md
git commit -m "Add security policy"
git push origin main
```

After committing, the `.github` folder with `SECURITY.md` will appear in the repository’s file list alongside README and other metadata.

![A dark-mode GitHub repository page displaying the .github folder and a list of files (ISSUE\_TEMPLATE, CODEOWNERS, PULL\_REQUEST\_TEMPLATE.md, SECURITY.md, dependabot.yml) with recent commit messages. The left sidebar shows other repo files like README.md, app.js, and package.json.](https://mintcdn.com/kodekloud-c4ac6d9a/TlnHw4JjIHBx3Cta/images/GitHub-Administration-Certification/Security-and-Compliance/Demo-GitHub-Security-Policy/dark-github-repo-dotgithub-files.jpg?fit=max\&auto=format\&n=TlnHw4JjIHBx3Cta\&q=85\&s=2bce38ba8c971659918f49a49ab17f21)

The security policy will be visible to contributors and visitors alongside other repository files. GitHub also surfaces this policy in the repository’s Security tab to make it easier for reporters to find guidance.

![A dark-mode screenshot of a GitHub repository's Security tab displaying a "Security Policy" page with a "Supported Versions" table and a "Reporting a Vulnerability" section. The right sidebar shows repo details like contributors, releases, and language statistics.](https://mintcdn.com/kodekloud-c4ac6d9a/TlnHw4JjIHBx3Cta/images/GitHub-Administration-Certification/Security-and-Compliance/Demo-GitHub-Security-Policy/github-security-policy-supported-versions.jpg?fit=max\&auto=format\&n=TlnHw4JjIHBx3Cta\&q=85\&s=c21535af4abc08c64257324558759eae)

## Best practices

* Keep the policy concise and actionable.
* Provide only one or two clear reporting channels.
* Offer encrypted-report options and publish your public key if you accept them.
* Keep the supported-versions table up to date with each release.
* Use PRs to update `SECURITY.md` so changes are reviewed and auditable.

## Links and references

* [GitHub Docs: Creating a security policy for your repository](https://docs.github.com/en/code-security/security-policy)
* [GitHub Docs: Reporting a vulnerability](https://docs.github.com/en/code-security/reporting-vulnerabilities-in-your-project)

Creating a clear SECURITY.md reduces friction for reporters, helps maintainers triage faster, and protects your users by ensuring a coordinated disclosure process.

> [card] [Watch Video](https://learn.kodekloud.com/user/courses/github-administration-certification/module/d477d0b2-5ca0-43b2-aed7-7d82887400f7/lesson/ca9f2036-f6f9-45f7-8d0a-f3e5aed83608)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.