GitHub security advisories now support the new CVSS 4.0 schema. CVSS, or the Common Vulnerability Scoring System, is an industry standard maintained by FIRST. The CVSS 4.0 standard adds new metrics for a more thorough assessment of the risk of a particular vulnerability.
When creating a repository security advisory, you can now calculate either a CVSS 4.0 or 3.1 base score and view this data on the published global advisory, related Dependabot alerts, and through the API.
To make it easier to submit security advisories, GitHub now validates package names.
When submitting a new GHSA (GitHub Security Advisory) in a repository, the user is prompted to enter the ecosystem (e.g. npm, maven) and package name (e.g. webpack, lodash). Now, when they enter the name, there will be a validation message at the bottom of the form to confirm whether or not the package name they entered has been found in the ecosystem they specified.
It will continue to work for an additional year in the current version of the REST API before being removed in July of 2025. However, users should note this will conflict with the settings assigned in code security configurations if the configuration is unenforced. This may result in a code security configuration being unintentionally removed from a repository.
The endpoint will be removed entirely in the next version of the REST API.
Code security configurations simplify the rollout of GitHub security products at scale by defining collections of security settings and helping you apply those settings to groups of repositories. Configurations help you change the settings for important features like code scanning, secret scanning, and Dependabot.
With the addition of configurations data in the audit log, organization and enterprise owners have easy visibility into why the settings on certain repositories may have changed.
Audit log events now include:
– Name of the configuration applied to a repository
– When the configuration application fails
– When a configuration is removed from a repository
– When configurations are created, updated, or deleted
– When configurations become enforced
– When the default configuration for new repositories changes
Code security configurations are now available in public beta on GitHub.com and will be available in GitHub Enterprise Server 3.15. You can learn more about code security configurations or send us your feedback.
✕
Wait! Don't Go Yet 🚀
Get our FREE eBook "10 Programming Tips That Changed Everything" when you subscribe!
Code security configurations simplify the rollout of GitHub security products at scale. They help you define collections of security settings and apply them across groups of repositories.
Since the beta release on April 2, 2024, we’ve launched several improvements, including configuration enforcement and an API.
All new changes to security settings must happen through the new code security configurations expereince. Organizations that were previously opted out of the experience have been opted back in. All default settings for new repositories have been migrated to a configuration called “Legacy” and automatically applied to new repos.
Code security configurations will be made generally available (GA) on July 10th, 2024. At that point, we will sunset the organization-level code security settings UI experience along with the API parameters that complemented it.
If you are currently using the Update an organization REST API endpoint to set default security settings for new repositories, or the Get an organization REST API endpoint to retrieve current defaults for security settings on new repositories, those parameters will now be ignored. The parameters will be removed entirely in the next version of the REST API.
Your previous default settings in your organization have been saved to a code security configuration called “Legacy” and will continue to apply. To change the default security settings for new repositories, use the code security configurations UI, the configurations API, or the unaffected enterprise-level security settings.
You can now use the REST API to create and manage code security configurations, as well as attach them to repositories at scale.
The API supports the following code security configuration actions for organizations:
– Create, get, update, and delete configurations
– Set and retrieve default configurations
– List all configurations
– Attach configurations to repositories
Configurations are collections of security settings that organization administrators and security managers can define to help roll out GitHub security products at scale.
Starting today, you can enforce configurations. This new feature allows you to prevent users at the repository level from changing the security features that have been enabled and disabled in the configuration attached to their repository.
You can mark a configuration as enforced or unenforced at the bottom of the configurations edit page under the policy section:
As of today, May 15th, 2024, you will no longer be able to create security advisories in private repositories. Formerly published advisories will no longer be available.
Code security configurations simplify the rollout of GitHub security products at scale by defining collections of security settings that can be applied to groups of repositories. Your organization can apply the ‘GitHub recommended’ security configuration, which applies GitHub’s suggested settings for Dependabot, secret scanning, and code scanning. Alternatively, you can instead create your own custom security configurations. For example, an organization could create a ‘High risk’ security configuration for production repositories, and a ‘Minimum protection’ security configuration for internal repositories. This lets you manage security settings based on different risk profiles and security needs. Your organization can also set a default security configuration which is automatically applied to new repositories, avoiding any gaps in your coverage.
With security configurations, you can also see the additional number of GitHub Advanced Security (GHAS) licenses that are required to apply a configuration, or made available by disabling GHAS features on selected repositories. This lets you understand license usage when you roll out GitHub’s code security features in your organization.
As of February 15th, 2024, you will no longer be able to create security advisories in private repositories. Formerly published advisories will no longer be available.
If you are a security manager or a user with admin permissions to a repository, you can now delete the workspace directly from the repository advisory, regardless of the state of the advisory. Before this, there was no option to delete such private forks.
✕
Wait! Don't Go Yet 🚀
Get our FREE eBook "10 Programming Tips That Changed Everything" when you subscribe!