* 3.1 megabranch * these should be in a topic branch to avoid unnecessary ci failures * add copies of 3.0 schema files * update link veresion from 3.0 -> 3.1 * update correct version 🤦♀️ * update with 3.1 version links * first stab of this work * fix product variable and links to section that has been moved * simplify Liquid conditions * elsif * Update content/github/managing-subscriptions-and-notifications-on-github/viewing-your-subscriptions.md Co-authored-by: Shati Patel <42641846+shati-patel@users.noreply.github.com> * [GHES 3.1] Code scanning: SARIF limit increased to 5000 (#18539) * revert api previews * delete 3.1 preview * Revert "delete 3.1 preview" This reverts commit 0a7df3e17a1e182e5b01b0fdafacb6bb19100f70. * regenerate decorated file * make security policy docs available in GHES 3.1 and GHAE docs * adapt for GHES/GHAE and remove the word * revert a whole bunch of stuff * more reverting and further updating * update links to Adding a security policy to your repo article * fix broken links and remove responsibly * simplify Liquid versioning * Update content/code-security/getting-started/adding-a-security-policy-to-your-repository.md Co-authored-by: Felicity Chapman <felicitymay@github.com> * address comment * Remove overcomplicated versioning (#18934) * Update information on licensing and billing for GHES 3.1 (#18835) * regenerate graphql files with new prerendered input object * add release notes placeholder file * add scaffolding * use real date * ✂️ 3.1 schema added accidentally * update enterprise release dates * add base files * Correct versioning for branch renaming and master to main transition in GHES docs (#19050) * update versioning * apply Alistair's suggestion * add new cached index names * Update docs for code scanning in external CI to cover CodeQL CLI usage (#19030) * 3893 add missing flag for GHES and GHAE (next) users (#19129) * [GHES 3.1] Release candidate 1 release notes (#18419) * fleshing out the 33.1 RC1 release notes * update with moreee * really flesh it all out * format a bit * fix linter errors * fix errors again * add quotes around heading with Liquid * placeholder to get error fixed * add quotes * just remove thoose things * typo * Update 0-rc1.yml * update with feedback * add workflow beta * upload increase * some last changes * change the date * fix links Co-authored-by: Sarah Schneider <sarahs@github.com> Co-authored-by: Rachael Sewell <rachmari@github.com> * Conflict resolution between 19082 and 3.1 Megabranch (#19158) * Fix typo in new reusable * delete 3.1 rest schema files * Update OpenAPI Descriptions (#19166) * last minute additions yikes * redeploy staging Co-authored-by: Melanie Yarbrough <11952755+myarb@users.noreply.github.com> Co-authored-by: Shati Patel <42641846+shati-patel@users.noreply.github.com> Co-authored-by: mchammer01 <42146119+mchammer01@users.noreply.github.com> Co-authored-by: skedwards88 <skedwards88@github.com> Co-authored-by: Matt Pollard <mattpollard@users.noreply.github.com> Co-authored-by: Felicity Chapman <felicitymay@github.com> Co-authored-by: Meg Bird <megbird@github.com> Co-authored-by: Sarah Schneider <sarahs@github.com> Co-authored-by: github-openapi-bot <69533958+github-openapi-bot@users.noreply.github.com>
60 lines
4.1 KiB
Markdown
60 lines
4.1 KiB
Markdown
---
|
|
title: Adding a security policy to your repository
|
|
intro: You can give instructions for how to report a security vulnerability in your project by adding a security policy to your repository.
|
|
redirect_from:
|
|
- /articles/adding-a-security-policy-to-your-repository
|
|
- /github/managing-security-vulnerabilities/adding-a-security-policy-to-your-repository
|
|
- /github/code-security/security-advisories/adding-a-security-policy-to-your-repository
|
|
versions:
|
|
free-pro-team: '*'
|
|
enterprise-server: '>=3.1'
|
|
github-ae: 'next'
|
|
topics:
|
|
- Security
|
|
---
|
|
|
|
### About security policies
|
|
|
|
To give people instructions for reporting security vulnerabilities in your project,{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.0" %} you can add a _SECURITY.md_ file to your repository's root, `docs`, or `.github` folder.{% else %} you can add a _SECURITY.md_ file to your repository's root, or `docs` folder.{% endif %} When someone creates an issue in your repository, they will see a link to your project's security policy.
|
|
|
|
{% if currentVersion != 'github-ae@next' %}
|
|
<!-- no public repos in GHAE -->
|
|
You can create a default security policy for your organization or user account. For more information, see "[Creating a default community health file](/communities/setting-up-your-project-for-healthy-contributions/creating-a-default-community-health-file)."
|
|
{% endif %}
|
|
|
|
{% tip %}
|
|
|
|
**Tip:** To help people find your security policy, you can link to your _SECURITY.md_ file from other places in your repository, such as your README file. For more information, see "[About READMEs](/articles/about-readmes)."
|
|
|
|
{% endtip %}
|
|
|
|
{% if currentVersion == "free-pro-team@latest" %}
|
|
After someone reports a security vulnerability in your project, you can use {% data variables.product.prodname_security_advisories %} to disclose, fix, and publish information about the vulnerability. For more information about the process of reporting and disclosing vulnerabilities in {% data variables.product.prodname_dotcom %}, see "[About coordinated disclosure of security vulnerabilities](/code-security/security-advisories/about-coordinated-disclosure-of-security-vulnerabilities#about-reporting-and-disclosing-vulnerabilities-in-projects-on-github)." For more information about {% data variables.product.prodname_security_advisories %}, see "[About {% data variables.product.prodname_security_advisories %}](/github/managing-security-vulnerabilities/about-github-security-advisories)."
|
|
|
|
{% data reusables.repositories.github-security-lab %}
|
|
{% endif %}
|
|
{% if currentVersion ver_gt "enterprise-server@3.0" or currentVersion == 'github-ae@next' %}
|
|
<!-- alternative to the content about GitHub Security Advisories in the dotcom article -->
|
|
By making security reporting instructions clearly available, you make it easy for your users to report any security vulnerabilities they find in your repository using your preferred communication channel.
|
|
{% endif %}
|
|
|
|
### Adding a security policy to your repository
|
|
|
|
{% data reusables.repositories.navigate-to-repo %}
|
|
{% data reusables.repositories.sidebar-security %}
|
|
3. In the left sidebar, click **Security policy**.
|
|

|
|
4. Click **Start setup**.
|
|

|
|
5. In the new _SECURITY.md_ file, add information about supported versions of your project and how to report a vulnerability.
|
|
{% data reusables.files.write_commit_message %}
|
|
{% data reusables.files.choose-commit-email %}
|
|
{% data reusables.files.choose_commit_branch %}
|
|
{% data reusables.files.propose_file_change %}
|
|
|
|
### Further reading
|
|
|
|
- "[About securing your repository](/github/administering-a-repository/about-securing-your-repository)"{% if currentVersion != 'github-ae@next' %}
|
|
- "[Setting up your project for healthy contributions](/communities/setting-up-your-project-for-healthy-contributions)"{% endif %}{% if currentVersion == "free-pro-team@latest" %}
|
|
- [{% data variables.product.prodname_security %}]({% data variables.product.prodname_security_link %}){% endif %}
|