Merge branch 'main' into repo-sync
This commit is contained in:
Octomerger Bot
@@ -101,7 +101,7 @@ After you enable {% data variables.product.prodname_dependabot_alerts %} for you
|
||||
{% ifversion ghes %}
|
||||
Before you enable {% data variables.product.prodname_dependabot_updates %}, you must configure {% data variables.product.product_location %} to use {% data variables.product.prodname_actions %} with self-hosted runners. For more information, see "[Getting started with {% data variables.product.prodname_actions %} for GitHub Enterprise Server](/admin/github-actions/enabling-github-actions-for-github-enterprise-server/getting-started-with-github-actions-for-github-enterprise-server)."
|
||||
|
||||
{% data variables.product.prodname_dependabot_updates %} are not supported on {% data variables.product.product_name %} if your enterprise uses clustering or a high-availability configuration.
|
||||
{% data variables.product.prodname_dependabot_updates %} are not supported on {% data variables.product.product_name %} if your enterprise uses clustering.
|
||||
{% endif %}
|
||||
|
||||
{% data reusables.enterprise_site_admin_settings.sign-in %}
|
||||
|
||||
@@ -18,6 +18,7 @@ learningTracks:
|
||||
- code_security_actions
|
||||
- code_security_ci
|
||||
- code_security_integration
|
||||
- end_to_end_supply_chain
|
||||
includeGuides:
|
||||
- /code-security/getting-started/adding-a-security-policy-to-your-repository
|
||||
- /code-security/getting-started/github-security-features
|
||||
|
||||
@@ -19,6 +19,7 @@ featuredLinks:
|
||||
- '{% ifversion ghes < 3.3 or ghae %}/code-security/secret-scanning/configuring-secret-scanning-for-your-repositories{% endif %}'
|
||||
- '{% ifversion ghae %}/code-security/code-scanning/integrating-with-code-scanning/uploading-a-sarif-file-to-github{% endif %}'
|
||||
- '{% ifversion ghae %}/code-security/code-scanning/using-codeql-code-scanning-with-your-existing-ci-system{% endif %}'
|
||||
- /code-security/supply-chain-security/end-to-end-supply-chain/end-to-end-supply-chain-overview
|
||||
popular:
|
||||
- '{% ifversion ghes %}/admin/release-notes{% endif %}'
|
||||
- /code-security/supply-chain-security/managing-vulnerabilities-in-your-projects-dependencies/about-alerts-for-vulnerable-dependencies
|
||||
|
||||
@@ -48,11 +48,12 @@ You cannot change the configuration of {% data variables.product.prodname_secret
|
||||
{% ifversion fpt %}
|
||||
{% note %}
|
||||
|
||||
**Note:** Organizations using {% data variables.product.prodname_ghe_cloud %} with {% data variables.product.prodname_GH_advanced_security %} can also enable {% data variables.product.prodname_secret_scanning_GHAS %} on any repository they own, including private repositories. For more information, see the [{% data variables.product.prodname_ghe_cloud %} documentation](/enterprise-cloud@latest/code-security/secret-security/about-secret-scanning#about-secret-scanning-for-advanced-security).
|
||||
{% data reusables.secret-scanning.fpt-GHAS-scans %}
|
||||
|
||||
{% endnote %}
|
||||
{% endif %}
|
||||
|
||||
|
||||
{% endif %}
|
||||
|
||||
{% ifversion not fpt %}
|
||||
|
||||
@@ -0,0 +1,38 @@
|
||||
---
|
||||
title: Securing your end-to-end supply chain
|
||||
shortTitle: Overview
|
||||
allowTitleToDifferFromFilename: true
|
||||
intro: Introducing best practice guides on complete end-to-end supply chain security including personal accounts, code, and build processes.
|
||||
versions:
|
||||
fpt: '*'
|
||||
ghec: '*'
|
||||
ghes: '*'
|
||||
type: overview
|
||||
topics:
|
||||
- Organizations
|
||||
- Teams
|
||||
- Dependencies
|
||||
- Advanced Security
|
||||
---
|
||||
|
||||
## What is the end-to-end supply chain?
|
||||
|
||||
At its core, end-to-end software supply chain security is about making sure the code you distribute hasn't been tampered with. Previously, attackers focused on targeting dependencies you use, for example libraries and frameworks. Attackers have now expanded their focus to include targeting user accounts and build processes, and so those systems must be defended as well.
|
||||
|
||||
## About these guides
|
||||
|
||||
This series of guides explains how to think about securing your end-to-end supply chain: personal account, code, and build processes. Each guide explains the risk to that area, and introduces the {% data variables.product.product_name %} features that can help you address that risk.
|
||||
|
||||
Everyone's needs are different, so each guide starts with the highest impact change, and continues from there with additional improvements you should consider. You should feel free to skip around and focus on improvements you think will have the biggest benefit. The goal isn't to do everything at once but to continuously improve security in your systems over time.
|
||||
|
||||
- "[Best practices for securing accounts](/code-security/supply-chain-security/end-to-end-supply-chain/securing-accounts)"
|
||||
|
||||
- "[Best practices for securing code in your supply chain](/code-security/supply-chain-security/end-to-end-supply-chain/securing-code)"
|
||||
|
||||
- "[Best practices for securing your build system](/code-security/supply-chain-security/end-to-end-supply-chain/securing-builds)"
|
||||
|
||||
## Further reading
|
||||
|
||||
- [Safeguarding artifact integrity across any software supply chain](https://slsa.dev/)
|
||||
- [Microsoft Supply Chain Integrity Model](https://github.com/microsoft/scim)
|
||||
- [Software Supply Chain Security Paper - CNCF Security Technical Advisory Group](https://github.com/cncf/tag-security/blob/main/supply-chain-security/supply-chain-security-paper/CNCF_SSCP_v1.pdf)
|
||||
@@ -0,0 +1,19 @@
|
||||
---
|
||||
title: End-to-end supply chain
|
||||
intro: How to think about securing your user accounts, your code, and your build process
|
||||
versions:
|
||||
fpt: '*'
|
||||
ghec: '*'
|
||||
ghes: '*'
|
||||
topics:
|
||||
- Security overview
|
||||
- Organizations
|
||||
- Teams
|
||||
- Dependencies
|
||||
- Advanced Security
|
||||
children:
|
||||
- /end-to-end-supply-chain-overview
|
||||
- /securing-accounts
|
||||
- /securing-code
|
||||
- /securing-builds
|
||||
---
|
||||
@@ -0,0 +1,136 @@
|
||||
---
|
||||
title: Best practices for securing accounts
|
||||
shortTitle: Securing accounts
|
||||
allowTitleToDifferFromFilename: true
|
||||
intro: Guidance on how to protect accounts with access to your software supply chain.
|
||||
versions:
|
||||
fpt: '*'
|
||||
ghec: '*'
|
||||
ghes: '*'
|
||||
type: overview
|
||||
topics:
|
||||
- Organizations
|
||||
- Teams
|
||||
- SSH
|
||||
- Security
|
||||
- Accounts
|
||||
---
|
||||
## About this guide
|
||||
|
||||
This guide describes the highest impact changes you can make to increase account security. Each section outlines a change you can make to your processes to improve the security. The highest impact changes are listed first.
|
||||
|
||||
## What's the risk?
|
||||
|
||||
Account security is fundamental to the security of your supply chain. If an attacker can take over your account on {% data variables.product.product_name %}, they can then make malicious changes to your code or build process. So your first goal should be to make it difficult for someone to take over your account and the accounts of other {% ifversion ghes %}users{% else %}members{% endif %} of {% ifversion fpt %}your organization{% elsif ghec or ghae %}your organization or enterprise{% elsif ghes %}{% data variables.product.product_location %}{% endif %}.
|
||||
|
||||
{% ifversion ghec or ghes %}
|
||||
## Centralize authentication
|
||||
{% endif %}
|
||||
|
||||
{% ifversion ghec %}
|
||||
If you're an enterprise or organization owner, you can configure centralized authentication with SAML. While you can add or remove members manually, it's simpler and more secure to set up single sign-on (SSO) and SCIM between {% data variables.product.product_name %} and your SAML identity provider (IdP). This also simplifies the authentication process for all members of your enterprise.
|
||||
|
||||
You can configure SAML authentication for an enterprise or organization account. With SAML, you can grant access to the personal accounts of members of your enterprise or organization on {% data variables.product.product_location %} through your IdP, or you can create and control the accounts that belong to your enterprise by using {% data variables.product.prodname_emus %}. For more information, see "[About identity and access management with SAML single sign-on](/organizations/managing-saml-single-sign-on-for-your-organization/about-identity-and-access-management-with-saml-single-sign-on)".
|
||||
|
||||
After you configure SAML authentication, when members request access to your resources, they'll be directed to your SSO flow to ensure they are still recognized by your IdP. If they are unrecognized, their request is declined.
|
||||
|
||||
Some IdPs support a protocol called SCIM, which can automatically provision or deprovision access on {% data variables.product.product_name %} when you make changes on your IdP. With SCIM, you can simplify administration as your team grows, and you can quickly revoke access to accounts. SCIM is available for individual organizations on {% data variables.product.product_name %}, or for enterprises that use {% data variables.product.prodname_emus %}. For more information, see "[About SCIM](/organizations/managing-saml-single-sign-on-for-your-organization/about-scim)."
|
||||
{% endif %}
|
||||
|
||||
{% ifversion ghes %}
|
||||
If you're the site administrator for {% data variables.product.product_location %}, you can simplify the login experience for users by choosing an authentication method that connects with your existing identity provider (IdP), like CAS, SAML, or LDAP. This means that they no longer need to remember an extra password for {% data variables.product.prodname_dotcom %}.
|
||||
|
||||
Some authentication methods also support communicating additional information to {% data variables.product.product_name %}, for example, what groups the user is a member of, or synchronizing cryptographic keys for the user. This is a great way to simplify your administration as your organization grows.
|
||||
|
||||
For more information on these authentication methods, see "[Using CAS](/admin/identity-and-access-management/authenticating-users-for-your-github-enterprise-server-instance/using-cas)," "[Using SAML](/admin/identity-and-access-management/authenticating-users-for-your-github-enterprise-server-instance/using-saml)," and "[Using LDAP](/admin/identity-and-access-management/authenticating-users-for-your-github-enterprise-server-instance/using-ldap)."
|
||||
{% endif %}
|
||||
|
||||
## Configure two-factor authentication
|
||||
|
||||
The best way to improve the security of {% ifversion fpt %}your personal account{% elsif ghes %}your personal account or {% data variables.product.product_location %}{% elsif ghec %}your accounts{% elsif ghae %}your enterprise on {% data variables.product.product_name %}{% endif %} is to configure two-factor authentication (2FA){% ifversion ghae %} on your SAML identity provider (IdP){% endif %}. Passwords by themselves can be compromised by being guessable, by being reused on another site that's been compromised, or by social engineering, like phishing. 2FA makes it much more difficult for your accounts to be compromised, even if an attacker has your password.
|
||||
|
||||
{% ifversion not ghae %}
|
||||
|
||||
{% ifversion ghec %}
|
||||
If you're an enterprise owner, you may be able to configure a policy to require 2FA for all organizations owned by your enterprise.
|
||||
{% endif %}
|
||||
|
||||
{% ifversion ghes %}
|
||||
If you're the site administrator for {% data variables.product.product_location %}, you may be able to configure 2FA for all users of your instance. The availability of 2FA on {% data variables.product.product_name %} depends on the authentication method that you use. For more information, see "[Centralize user authentication](#centralize-user-authentication)."
|
||||
{% endif %}
|
||||
|
||||
If you're an organization owner, then you {% ifversion fpt %}can{% else %}may be able to{% endif %} require that all members of the organization enable 2FA.
|
||||
|
||||
{% ifversion ghec or ghes %}
|
||||
|
||||
### Configure your enterprise account
|
||||
|
||||
Enterprise owners may be able to require 2FA for all {% ifversion ghes %}users on{% elsif ghec %}members of{% endif %} the {% ifversion ghes %}instance{% elsif ghec %}enterprise{% endif %}. The availability of 2FA policies on {% data variables.product.product_name %} depends on how {% ifversion ghes %}users{% else %}members{% endif %} authenticate to access your {% ifversion ghes %}instance{% elsif ghec %}enterprise's resources{% endif %}.
|
||||
|
||||
{% ifversion ghes %}
|
||||
- If you sign into {% data variables.product.product_location %} through an external IdP using CAS or SAML SSO, you
|
||||
{% elsif ghec %}
|
||||
If your enterprise uses {% data variables.product.prodname_emus %} or SAML authentication is enforced for your enterprise, you
|
||||
{%- endif %} cannot configure 2FA on {% data variables.product.product_name %}. Someone with administrative access to your IdP must configure 2FA for the IdP.
|
||||
|
||||
{% ifversion ghes %}
|
||||
|
||||
- If you sign into {% data variables.product.product_location %} through an external LDAP directory, you can require 2FA for your enterprise on {% data variables.product.product_name %}. If you allow built-in authentication for users outside of your directory, individual users can enable 2FA, but you cannot require 2FA for your enterprise.
|
||||
|
||||
{% endif %}
|
||||
|
||||
For more information, see {% ifversion ghec %}"[About identity and access management for your enterprise](/admin/identity-and-access-management/managing-iam-for-your-enterprise/about-identity-and-access-management-for-your-enterprise)" and {% endif %}"[Enforcing policies for security settings in your enterprise](/admin/policies/enforcing-policies-for-your-enterprise/enforcing-policies-for-security-settings-in-your-enterprise#requiring-two-factor-authentication-for-organizations-in-your-enterprise)."
|
||||
|
||||
{% endif %}
|
||||
|
||||
### Configure your personal account
|
||||
|
||||
{% ifversion ghec or ghes %}
|
||||
{% note %}
|
||||
|
||||
**Note**: Depending on the authentication method that {% ifversion ghec %}an enterprise owner{% elsif ghes %}a site administrator{% endif %} has configured for {% ifversion ghec %}your enterprise on {% endif %}{% data variables.product.product_location %}, you may not be able to enable 2FA for your personal account.
|
||||
|
||||
{% endnote %}
|
||||
{% endif %}
|
||||
|
||||
{% data variables.product.product_name %} supports several options for 2FA, and while any of them is better than nothing, the most secure option is WebAuthn. WebAuthn requires either a hardware security key or a device that supports it through things like Windows Hello or Mac TouchID. It's possible, although difficult, to phish other forms of 2FA (for example, someone asking you to read them your 6 digit one-time password). However WebAuthn isn't phishable, because domain scoping is built into the protocol, which prevents credentials from a website impersonating a login page from being used on {% data variables.product.product_name %}.
|
||||
|
||||
When you set up 2FA, you should always download the recovery codes and set up more than one factor. This ensures that access to your account doesn't depend on a single device. For more information, see "[Configuring two-factor authentication](/authentication/securing-your-account-with-two-factor-authentication-2fa/configuring-two-factor-authentication)," "[Configuring two-factor authentication recovery methods](/authentication/securing-your-account-with-two-factor-authentication-2fa/configuring-two-factor-authentication-recovery-methods)," and [GitHub Branded hardware security keys](https://thegithubshop.com/products/github-branded-yubikey) in the GitHub shop.
|
||||
|
||||
### Configure your organization account
|
||||
|
||||
{% ifversion ghec or ghes %}
|
||||
{% note %}
|
||||
|
||||
**Note**: Depending on the authentication method that {% ifversion ghec %}an enterprise owner{% elsif ghes %}a site administrator{% endif %} has configured for {% ifversion ghec %}your enterprise on {% endif %}{% data variables.product.product_location %}, you may not be able to require 2FA for your organization.
|
||||
|
||||
{% endnote %}
|
||||
{% endif %}
|
||||
|
||||
If you're an organization owner, you can see which users don't have 2FA enabled, help them get set up, and then require 2FA for your organization. To guide you through that process, see:
|
||||
|
||||
1. "[Viewing whether users in your organization have 2FA enabled](/organizations/keeping-your-organization-secure/managing-two-factor-authentication-for-your-organization/viewing-whether-users-in-your-organization-have-2fa-enabled)"
|
||||
2. "[Preparing to require two-factor authentication in your organization](/organizations/keeping-your-organization-secure/managing-two-factor-authentication-for-your-organization/preparing-to-require-two-factor-authentication-in-your-organization)"
|
||||
3. "[Requiring two-factor authentication in your organization](/organizations/keeping-your-organization-secure/managing-two-factor-authentication-for-your-organization/requiring-two-factor-authentication-in-your-organization)"
|
||||
|
||||
{% endif %}
|
||||
|
||||
## Connect to {% data variables.product.product_name %} using SSH keys
|
||||
|
||||
There are other ways to interact with {% data variables.product.product_name %} beyond signing into the website. Many people authorize the code they push to {% data variables.product.prodname_dotcom %} with an SSH private key. For more information, see "[About SSH](/authentication/connecting-to-github-with-ssh/about-ssh)."
|
||||
|
||||
Just like your account password, if an attacker were able to get your SSH private key, they could impersonate you and push malicious code to any repository you have write access for. If you store your SSH private key on a disk drive, it's a good idea to protect it with a passphrase. For more information, see "[Working with SSH key passphrases](/authentication/connecting-to-github-with-ssh/working-with-ssh-key-passphrases)."
|
||||
|
||||
Another option is to generate SSH keys on a hardware security key. You could use the same key you're using for 2FA. Hardware security keys are very difficult to compromise remotely, because the private SSH key remains on the hardware, and is not directly accessible from software. For more information, see "[Generating a new SSH key for a hardware security key](/authentication/connecting-to-github-with-ssh/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent#generating-a-new-ssh-key-for-a-hardware-security-key)."
|
||||
|
||||
{% ifversion ghec or ghes or ghae %}
|
||||
Hardware-backed SSH keys are quite secure, but the hardware requirement might not work for some organizations. An alternative approach is to use SSH keys that are only valid for a short period of time, so even if the private key is compromised it can't be exploited for very long. This is the concept behind running your own SSH certificate authority. While this approach gives you a lot of control over how users authenticate, it also comes with the responsibility of maintaining an SSH certificate authority yourself. For more information, see "[About SSH certificate authorities](/organizations/managing-git-access-to-your-organizations-repositories/about-ssh-certificate-authorities)."
|
||||
{% endif %}
|
||||
|
||||
## Next steps
|
||||
|
||||
- "[Securing your end-to-end supply chain](/code-security/supply-chain-security/end-to-end-supply-chain/end-to-end-supply-chain-overview)"
|
||||
|
||||
- "[Best practices for securing code in your supply chain](/code-security/supply-chain-security/end-to-end-supply-chain/securing-code)"
|
||||
|
||||
- "[Best practices for securing your build system](/code-security/supply-chain-security/end-to-end-supply-chain/securing-builds)"
|
||||
@@ -0,0 +1,62 @@
|
||||
---
|
||||
title: Best practices for securing your build system
|
||||
shortTitle: Securing builds
|
||||
allowTitleToDifferFromFilename: true
|
||||
intro: Guidance on how to protect the end of your supply chain—the systems you use to build and distribute artifacts.
|
||||
versions:
|
||||
fpt: '*'
|
||||
ghec: '*'
|
||||
ghes: '*'
|
||||
type: overview
|
||||
topics:
|
||||
- Fundamentals
|
||||
- Security
|
||||
- CI
|
||||
- CD
|
||||
---
|
||||
|
||||
## About this guide
|
||||
|
||||
This guide describes the highest impact changes you can make to improve the security of your build systems. Each section outlines a change you can make to your processes to improve security. The highest impact changes are listed first.
|
||||
|
||||
## What's the risk?
|
||||
|
||||
Some attacks on software supply chains target the build system directly. If an attacker can modify the build process, they can exploit your system without the effort of compromising personal accounts or code. It's important to make sure that you don't forget to protect the build system as well as personal accounts and code.
|
||||
|
||||
## Secure your build system
|
||||
|
||||
There are several security capabilities a build system should have:
|
||||
|
||||
1. The build steps should be clear and repeatable.
|
||||
|
||||
2. You should know exactly what was running during the build process.
|
||||
|
||||
3. Each build should start in a fresh environment, so a compromised build doesn't persist to affect future builds.
|
||||
|
||||
{% data variables.product.prodname_actions %} can help you meet these capabilities. Build instructions are stored in your repository, alongside your code. You choose what environment your build runs on, including Windows, Mac, Linux, or runners you host yourself. Each build starts with a fresh virtual environment, making it difficult for an attack to persist in your build environment.
|
||||
|
||||
In addition to the security benefits, {% data variables.product.prodname_actions %} lets you trigger builds manually, periodically, or on git events in your repository for frequent and fast builds.
|
||||
|
||||
{% data variables.product.prodname_actions %} is a big topic, but a good place to get started is "[Understanding GitHub Actions](/actions/learn-github-actions/understanding-github-actions)," as well as "[Choosing GitHub-hosted runners](/actions/using-workflows/workflow-syntax-for-github-actions#choosing-github-hosted-runners)," and "[Triggering a workflow](/actions/using-workflows/triggering-a-workflow)."
|
||||
|
||||
## Sign your builds
|
||||
|
||||
After your build process is secure, you want to prevent someone from tampering with the end result of your build process. A great way to do this is to sign your builds. When distributing software publicly, this is often done with a public/private cryptographic key pair. You use the private key to sign the build, and you publish your public key so users of your software can verify the signature on the build before they use it. If the bytes of the build are modified, the signature will not verify.
|
||||
|
||||
How exactly you sign your build will depend on what sort of code you're writing, and who your users are. Often it's difficult to know how to securely store the private key. One basic option here is to use {% data variables.product.prodname_actions %} encrypted secrets, although you'll need to be careful to limit who has access to those {% data variables.product.prodname_actions %} workflows. {% ifversion fpt or ghec %}If your private key is stored in another system accessible over the public internet (like Microsoft Azure, or HashiCorp Vault), a more advanced option is to authenticate with OpenID Connect, so you don't have to share secrets across systems.{% endif %} If your private key is only accessible from a private network, another option is to use self-hosted runners for {% data variables.product.prodname_actions %}.
|
||||
|
||||
For more information, see "[Encrypted secrets](/actions/security-guides/encrypted-secrets)"{% ifversion fpt or ghec %}, "[About security hardening with OpenID Connect](/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect)",{% endif %} and "[About self-hosted runners](/actions/hosting-your-own-runners/about-self-hosted-runners)."
|
||||
|
||||
## Harden security for {% data variables.product.prodname_actions %}
|
||||
|
||||
There are many further steps you can take to additionally secure {% data variables.product.prodname_actions %}. In particular, be careful when evaluating third-party workflows, and consider using `CODEOWNERS` to limit who can make changes to your workflows.
|
||||
|
||||
For more information, see "[Security hardening for GitHub Actions](/actions/security-guides/security-hardening-for-github-actions);" particularly "[Using third-party actions](/actions/security-guides/security-hardening-for-github-actions#using-third-party-actions)" and "[Using `CODEOWNERS` to monitor changes](/actions/security-guides/security-hardening-for-github-actions#using-codeowners-to-monitor-changes)."
|
||||
|
||||
## Next steps
|
||||
|
||||
- "[Securing your end-to-end supply chain](/code-security/supply-chain-security/end-to-end-supply-chain/end-to-end-supply-chain-overview)"
|
||||
|
||||
- "[Best practices for securing accounts](/code-security/supply-chain-security/end-to-end-supply-chain/securing-accounts)"
|
||||
|
||||
- "[Best practices for securing code in your supply chain](/code-security/supply-chain-security/end-to-end-supply-chain/securing-code)"
|
||||
@@ -0,0 +1,119 @@
|
||||
---
|
||||
title: Best practices for securing code in your supply chain
|
||||
shortTitle: Securing code
|
||||
allowTitleToDifferFromFilename: true
|
||||
intro: Guidance on how to protect the center of your supply chain—the code you write and the code you depend on.
|
||||
versions:
|
||||
fpt: '*'
|
||||
ghec: '*'
|
||||
ghes: '*'
|
||||
type: overview
|
||||
topics:
|
||||
- Dependabot
|
||||
- Security updates
|
||||
- Vulnerabilities
|
||||
- Advanced Security
|
||||
- Secret scanning
|
||||
---
|
||||
|
||||
## About this guide
|
||||
|
||||
This guide describes the highest impact changes you can make to improve the security of your code. Each section outlines a change you can make to your processes to improve security. The highest impact changes are listed first.
|
||||
|
||||
## What's the risk?
|
||||
|
||||
Key risks in the development process include:
|
||||
|
||||
- Using dependencies with security vulnerabilities that an attacker could exploit.
|
||||
- Leaking authentication credentials or a token that an attacker could use to access your resources.
|
||||
- Introducing a vulnerability to your own code that an attacker could exploit.
|
||||
|
||||
These risks open your resources and projects to attack and those risks are passed directly on to anyone who uses a package that you create. The following sections explain how you can protect yourself and your users from these risks.
|
||||
|
||||
## Create a vulnerability management program for dependencies
|
||||
|
||||
You can secure the code you depend on by creating a vulnerability management program for dependencies. At a high level this should include processes to ensure that you:
|
||||
|
||||
1. Create an inventory of your dependencies.
|
||||
|
||||
2. Know when there is a security vulnerability in a dependency.
|
||||
|
||||
3. Assess the impact of that vulnerability on your code and decide what action to take.
|
||||
|
||||
### Automatic inventory generation
|
||||
|
||||
As a first step, you want to make a complete inventory of your dependencies. The dependency graph for a repository shows you dependencies for supported ecosystems. If you check in your dependencies, or use other ecosystems, you will need to supplement this with data from 3rd party tools or by listing dependencies manually. For more information, see "[About the dependency graph](/code-security/supply-chain-security/understanding-your-software-supply-chain/about-the-dependency-graph)."
|
||||
|
||||
### Automatic detection of vulnerabilities in dependencies
|
||||
|
||||
{% data variables.product.prodname_dependabot %} can help you by monitoring your dependencies and notifying you when they contain a known vulnerability. {% ifversion fpt or ghec or ghes > 3.2 %}You can even enable {% data variables.product.prodname_dependabot %} to automatically raise pull requests that update the dependency to a secure version.{% endif %} For more information, see "[About alerts for vulnerable dependencies](/code-security/supply-chain-security/managing-vulnerabilities-in-your-projects-dependencies/about-alerts-for-vulnerable-dependencies)"{% ifversion fpt or ghec or ghes > 3.2 %} and "[About Dependabot security updates](/code-security/supply-chain-security/managing-vulnerabilities-in-your-projects-dependencies/about-dependabot-security-updates)"{% endif %}.
|
||||
|
||||
### Assessment of exposure to risk from a vulnerable dependency
|
||||
|
||||
When you discover you are using a vulnerable dependency, for example, a library or a framework, you must assess your project's level of exposure and determine what action to take. Vulnerabilities are usually reported with a severity score to show how severe their impact could be. The severity score is a useful guide but cannot tell you the full impact of the vulnerability on your code.
|
||||
|
||||
To assess the impact of a vulnerability on your code, you also need to consider how you use the library and determine how much risk that actually poses to your system. Maybe the vulnerability is part of a feature that you don't use, and you can update the affected library and continue with your normal release cycle. Or maybe your code is badly exposed to risk, and you need to update the affected library and ship an updated build right away. This decision depends on how you're using the library in your system, and is a decision that only you have the knowledge to make.
|
||||
|
||||
## Secure your communication tokens
|
||||
|
||||
Code often needs to communicate with other systems over a network, and requires secrets (like a password, or an API key) to authenticate. Your system needs access to those secrets to run, but it's best practice to not include them in your source code. This is especially important for public repositories, but also for private repositories to which many people might have access.
|
||||
|
||||
### Automatic detection of secrets committed to a repository
|
||||
|
||||
{% note %}
|
||||
|
||||
**Note:** {% data reusables.gated-features.secret-scanning-partner %}
|
||||
|
||||
{% endnote %}
|
||||
|
||||
{% data reusables.secret-scanning.enterprise-enable-secret-scanning %}
|
||||
|
||||
{% ifversion fpt or ghec %}
|
||||
{% data variables.product.prodname_dotcom %} partners with many providers to automatically detect when secrets are committed to or stored in your public repositories, and will notify the provider so they can take appropriate actions to ensure your account remains secure. For more information, see "[About {% data variables.product.prodname_secret_scanning %} for partner patterns](/code-security/secret-scanning/about-secret-scanning#about-secret-scanning-for-partner-patterns)."
|
||||
{% endif %}
|
||||
|
||||
{% ifversion fpt %}
|
||||
{% data reusables.secret-scanning.fpt-GHAS-scans %}
|
||||
{% elsif ghec %}
|
||||
If your organization uses {% data variables.product.prodname_GH_advanced_security %}, you can enable {% data variables.product.prodname_secret_scanning_GHAS %} on any repository owned by the organization. You can also define custom patterns to detect additional secrets at the repository, organization, or enterprise level. For more information, see "[About {% data variables.product.prodname_secret_scanning_GHAS %}](/code-security/secret-scanning/about-secret-scanning#about-secret-scanning-for-advacned-security)."
|
||||
{% else %}
|
||||
You can configure {% data variables.product.prodname_secret_scanning %} to check for secrets issued by many service providers and to notify you when any are detected. You can also define custom patterns to detect additional secrets at the repository, organization, or enterprise level. For more information, see "[About secret scanning](/code-security/secret-scanning/about-secret-scanning)" and "[Secret scanning patterns](/code-security/secret-scanning/secret-scanning-patterns)."
|
||||
{% endif %}
|
||||
|
||||
{% ifversion fpt or ghec or ghes > 3.2 %}
|
||||
### Secure storage of secrets you use in {% data variables.product.product_name %}
|
||||
{% endif %}
|
||||
|
||||
{% ifversion fpt or ghec %}
|
||||
Besides your code, you probably need to use secrets in other places. For example, to allow {% data variables.product.prodname_actions %} workflows, {% data variables.product.prodname_dependabot %}, or your {% data variables.product.prodname_codespaces %} development environment to communicate with other systems. For more information on how to securely store and use secrets, see "[Encrypted secrets in Actions](/actions/security-guides/encrypted-secrets)," "[Managing encrypted secrets for Dependabot](/code-security/supply-chain-security/keeping-your-dependencies-updated-automatically/managing-encrypted-secrets-for-dependabot)," and "[Managing encrypted secrets for your codespaces](/codespaces/managing-your-codespaces/managing-encrypted-secrets-for-your-codespaces)."
|
||||
{% endif %}
|
||||
|
||||
{% ifversion ghes > 3.2 %}
|
||||
Besides your code, you probably need to use secrets in other places. For example, to allow {% data variables.product.prodname_actions %} workflows or {% data variables.product.prodname_dependabot %} to communicate with other systems. For more information on how to securely store and use secrets, see "[Encrypted secrets in Actions](/actions/security-guides/encrypted-secrets)", and "[Managing encrypted secrets for Dependabot](/code-security/supply-chain-security/keeping-your-dependencies-updated-automatically/managing-encrypted-secrets-for-dependabot)."
|
||||
{% endif %}
|
||||
|
||||
## Keep vulnerable coding patterns out of your repository
|
||||
|
||||
{% note %}
|
||||
|
||||
**Note:** {% data reusables.gated-features.code-scanning %}
|
||||
|
||||
{% endnote %}
|
||||
|
||||
{% data reusables.code-scanning.enterprise-enable-code-scanning %}
|
||||
|
||||
### Create a pull request review process
|
||||
|
||||
You can improve the quality and security of your code by ensuring that all pull requests are reviewed and tested before they are merged. {% data variables.product.prodname_dotcom %} has many features you can use to control the review and merge process. To get started, see "[About protected branches](/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches)."
|
||||
|
||||
### Scan your code for vulnerable patterns
|
||||
|
||||
Insecure code patterns are often difficult for reviewers to spot unaided. In addition to scanning your code for secrets, you can check it for patterns that are associated with security vulnerabilities. For example, a function that isn't memory-safe, or failing to escaping user input that could lead to an injection vulnerability. {% data variables.product.prodname_dotcom %} offers several different ways to approach both how and when you scan your code. To get started, see "[About code scanning](/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/about-code-scanning)."
|
||||
|
||||
## Next steps
|
||||
|
||||
- "[Securing your end-to-end supply chain](/code-security/supply-chain-security/end-to-end-supply-chain/end-to-end-supply-chain-overview)"
|
||||
|
||||
- "[Best practices for securing accounts](/code-security/supply-chain-security/end-to-end-supply-chain/securing-accounts)"
|
||||
|
||||
- "[Best practices for securing your build system](/code-security/supply-chain-security/end-to-end-supply-chain/securing-builds)"
|
||||
@@ -18,5 +18,6 @@ children:
|
||||
- /understanding-your-software-supply-chain
|
||||
- /keeping-your-dependencies-updated-automatically
|
||||
- /managing-vulnerabilities-in-your-projects-dependencies
|
||||
- /end-to-end-supply-chain
|
||||
---
|
||||
|
||||
|
||||
@@ -110,3 +110,13 @@ code_security_ci:
|
||||
- /code-security/code-scanning/using-codeql-code-scanning-with-your-existing-ci-system/configuring-codeql-cli-in-your-ci-system
|
||||
- /code-security/code-scanning/using-codeql-code-scanning-with-your-existing-ci-system/migrating-from-the-codeql-runner-to-codeql-cli
|
||||
- /code-security/code-scanning/using-codeql-code-scanning-with-your-existing-ci-system/troubleshooting-codeql-runner-in-your-ci-system
|
||||
|
||||
# Feature available in all versions
|
||||
end_to_end_supply_chain:
|
||||
title: 'End-to-end supply chain'
|
||||
description: 'How to think about securing your user accounts, your code, and your build process.'
|
||||
guides:
|
||||
- /code-security/supply-chain-security/end-to-end-supply-chain/end-to-end-supply-chain-overview
|
||||
- /code-security/supply-chain-security/end-to-end-supply-chain/securing-accounts
|
||||
- /code-security/supply-chain-security/end-to-end-supply-chain/securing-code
|
||||
- /code-security/supply-chain-security/end-to-end-supply-chain/securing-builds
|
||||
|
||||
1
data/reusables/secret-scanning/fpt-GHAS-scans.md
Normal file
1
data/reusables/secret-scanning/fpt-GHAS-scans.md
Normal file
@@ -0,0 +1 @@
|
||||
**Note:** Organizations using {% data variables.product.prodname_ghe_cloud %} with {% data variables.product.prodname_GH_advanced_security %} can also enable {% data variables.product.prodname_secret_scanning_GHAS %} on any repository they own, including private repositories. For more information, see the [{% data variables.product.prodname_ghe_cloud %} documentation](/enterprise-cloud@latest/code-security/secret-security/about-secret-scanning#about-secret-scanning-for-advanced-security).
|
||||
@@ -1,8 +1,8 @@
|
||||
{% note %}
|
||||
|
||||
**Note:** {% data variables.product.company_short %} is improving security by dropping older, insecure key types.
|
||||
**Note:** {% data variables.product.company_short %} improved security by dropping older, insecure key types on March 15, 2022.
|
||||
|
||||
DSA keys (`ssh-dss`) are no longer supported. Existing keys will continue to function through March 15, 2022. You cannot add new DSA keys to your user account on {% data variables.product.product_location %}.
|
||||
As of that date, DSA keys (`ssh-dss`) are no longer supported. You cannot add new DSA keys to your user account on {% data variables.product.product_location %}.
|
||||
|
||||
RSA keys (`ssh-rsa`) with a `valid_after` before November 2, 2021 may continue to use any signature algorithm. RSA keys generated after that date must use a SHA-2 signature algorithm. Some older clients may need to be upgraded in order to use SHA-2 signatures.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user