Replace 'security release' with 'patch release' on the handbook
The release terminology has been updated on #19912 (closed), gitlab-com/content-sites/handbook!5428 (merged). Still, there are several places in the new handbook that still mention the 'security release'. This issue is to align the handbook to use the new terminology:
Click to expand
content/handbook/security/working-in-security.md:9:- Security releases. At GitLab, the Security Department is DRI for critical and non-critical security releases.
content/handbook/security/product-security/application-security/metrics/capacity.md:37:| AppSecWorkType::VulnFixVerification | Indicates the work was associated to security fix validations during security releases (not the same as security release manager rotation AppSecWorkType::SecurityReleaseRotation label) |
content/handbook/security/product-security/application-security/vulnerability-management.md:74:Vulnerabilities in the GitLab web application and all other products bundled with our Omnibus packages are fixed following the [patch release process](https://gitlab.com/gitlab-org/release/docs/blob/master/general/security/engineer.md). GitLab has two types of security releases: a regular monthly release, and a critical security release whenever a `~severity::1` issue is reported. See the [Security Releases](https://about.gitlab.com/handbook/engineering/releases/security-releases/) section of the main Product Security handbook page for more information.
content/handbook/security/product-security/application-security/vulnerability-management.md:76:If you're working on a vulnerability that you feel could be treated as a security enhancement and skip the security release process, feel free to ping `@gitlab-com/gl-security/product-security/appsec`.
content/handbook/security/product-security/application-security/vulnerability-management.md:78:GitLab products that follow an independent release cycle and are not aligned with the monthly GitLab security release are also required to have a process for developing security fixes and disclosing them to the customers. Either the [GitLab patch release process](https://gitlab.com/gitlab-org/release/docs/blob/master/general/security/engineer.md) or a recommended bare minimum process as below can be followed:
content/handbook/security/product-security/application-security/vulnerability-management.md:98:Fixed vulnerabilities are mentioned in the [security release blog posts](https://about.gitlab.com/releases/categories/releases/) and it's possible to [receive notifications](/handbook/security#receive-security-release-notifications) either through email or RSS.
content/handbook/security/product-security/application-security/vulnerability-management.md:100:Issues that were handled outside of the security release process can be mentioned in the regular release posts if the product manager deems it appropriate.
content/handbook/security/product-security/application-security/vulnerability-management.md:102:Security issues fixed in GitLab products may be mentioned in the security release blog post only if they are released along with the monthly GitLab security release. All security issues that need to be mentioned in the security release blog posts are expected to be linked to the `~"upcoming security release"` issue. If linking is not possible, please contact the [Security release managers](https://about.gitlab.com/community/release-managers/) to include security issue in the security release blog post.
content/handbook/security/product-security/application-security/vulnerability-management.md:104:GitLab products that follow an independent release cycle and are not aligned with the monthly GitLab security release could make use of `CHANGELOG.md` file or a separate security advisory file in the project repository to publish details about security fixes in their new releases.
content/handbook/security/product-security/application-security/vulnerability-management.md:202:- Make an MR to update the security release blog post
content/handbook/security/product-security/application-security/runbooks/triage-rotation.md:47:scheduled security release.
content/handbook/security/product-security/application-security/runbooks/unintended-vuln-disclosure.md:55:1. Consider scheduling a security release, regular or critical - depending on the severity of the vulnerability.
content/handbook/security/product-security/application-security/runbooks/unintended-vuln-disclosure.md:78:1. Consider starting a conversation with Delivery, Dedicated, and the relevant development teams about potentially scheduling an ad-hoc critical security release, depending on the severity of the vulnerability.
content/handbook/security/product-security/application-security/runbooks/unintended-vuln-disclosure.md:88:- Accidentally added to the security release blog post even though the fix didn't make it into the release
content/handbook/security/product-security/application-security/runbooks/unintended-vuln-disclosure.md:99:1. Consider starting a conversation with Delivery, Dedicated, and the relevant development teams about potentially scheduling an ad-hoc critical security release, depending on the severity of the vulnerability.
content/handbook/security/product-security/application-security/runbooks/security-engineer.md:2:title: General process for the application security team in security releases
content/handbook/security/product-security/application-security/runbooks/verifying-security-fixes.md:47:1. For each vulnerability (CVSSv3 score > 0) affecting the self-managed version of GitLab, request a CVE identifier by creating a new issue and selecting the `Internal GitLab Submission` template. Please note that some merge requests included in the security release do not require a CVE identifier (e.g., only third-party dependency upgrades, gitlab.com-only issues, etc.).
content/handbook/security/product-security/application-security/runbooks/hackerone-process.md:105: - If the CVSS score is higher on GitLab.com than self-managed, calculate both scores and share them in the Bug Bounty Council issue. If the council agrees that security impact is higher on GitLab.com than self-managed, bounty award will be based on the CVSS for GitLab.com. The CVE and security release blog post will always use the self-managed CVSS.
content/handbook/security/product-security/application-security/runbooks/hackerone-process.md:215:Vulnerabilities behind disabled-by-default feature flags do not need a CVE (use `~no-cve` when importing) as they are [patched in regular releases](https://docs.gitlab.com/ee/administration/feature_flags.html#risks-when-enabling-features-still-in-development), not security releases.
content/handbook/security/product-security/application-security/runbooks/handling-s1p1.md:52:Sometimes the fix is very simple, sometimes it's not. If the impact to users is greater than the time it takes to apply the long-term fix, you will need to consider a [short term solution](#short-term) as well as the [long term](#long-term) one. Otherwise, if you and the development team are confident the fix is straightforward and simple, then you only need to do the long term fix and roll it out in a critical security release.
content/handbook/security/product-security/application-security/runbooks/deciding-gitlab-com-deployment.md:5:The following chart is intended for `~"severity::1"` issues. Other issues should follow the regular security release process.
content/handbook/security/product-security/application-security/runbooks/deciding-gitlab-com-deployment.md:16: RegularRelease --> |Yes| ShipRegularRelease(Include the fix in the regular security release)
content/handbook/security/product-security/application-security/reproducible-vulnerabilities.md:221:First, find an interesting publicly disclosed vulnerability by looking at our [public and closed vulnerability issue list](https://gitlab.com/gitlab-org/gitlab/-/issues/?sort=updated_desc&state=closed&label_name%5B%5D=bug%3A%3Avulnerability&first_page_size=20) or our [security release blog posts](https://about.gitlab.com/releases/categories/releases/). Choose a vulnerability that was fixed in any release *prior* to the latest security release.
content/handbook/security/product-security/application-security/reproducible-vulnerabilities.md:264:<!-- Paste the text from the security release post. Adapt if needed. //-->
content/handbook/security/product-security/application-security/stable-counterparts.md:115: - I try to give priority to SC work unless there is an incident or I'm handling a security release.
content/handbook/security/engaging-with-security.md:43:We currently request CVEs [through our CVE project](https://about.gitlab.com/security/cve/). Keep in mind that some of our security releases contain *security related* enhancements which may not have an associated [CWE](https://cwe.mitre.org/) or vulnerability. These particular issues are not required to obtain a CVE since there's no associated vulnerability.
content/handbook/security/engaging-with-security.md:47:On the day of the security release several things happen in order:
content/handbook/security/engaging-with-security.md:172:If a better understanding of an issue leads us to discover the severity has changed, recalculate the time to remediate from the date the issue was opened. If that date is in the past, the issue must be remediated on or before the next security release.
content/handbook/security/engaging-with-security.md:179:monthly security releases on the 28th of each month. For example, suppose today is October 1st, and
content/handbook/security/engaging-with-security.md:180:a new `severity::2` `~security` issue is opened. It must be addressed in a security release [within 30 days]({{< ref "./product-security/vulnerability-management#remediation-slas" >}}),
content/handbook/security/engaging-with-security.md:181:which is October 31st. So therefore, it must catch the October 28th security release.
content/handbook/security/engaging-with-security.md:183:say that all merge requests associated with the fix must be ready 48 hours before the due date of the security release, which would be October 26th. So the due date in this example must be October 26th.
content/handbook/security/engaging-with-security.md:187:monthly security release dates.
content/handbook/security/engaging-with-security.md:190:needs to move up or delay a monthly security release date to accommodate for urgent
content/handbook/security/engaging-with-security.md:265:considered for a critical security release.
content/handbook/security/engaging-with-security.md:268:security release, which may be days or weeks ahead depending on severity and
content/handbook/security/engaging-with-security.md:270:that a patch will be ready prior to the next security release, but that
content/handbook/security/external-security-communications-procedure.md:45:- Vulnerability. A security issue, such as one reported internally or via our HackerOne program, involving GitLab code or configurations. Public communication is handled by the [Security Release Process](https://about.gitlab.com/handbook/engineering/releases/security-releases/). During that process, the responsible AppSec engineer will need to open a [Security Communications issue](https://gitlab.com/gitlab-com/gl-security/security-communications/communications/-/issues/new) to send communications about the security release. This is the main area where most security-related communications are generated.
content/handbook/security/external-security-communications-procedure.md:47:Remember that it is not unusual for security-related patches to be in the regular GitLab release [every month](/handbook/engineering/releases/) as the GitLab codebase is updated continuously, but vulnerabilities are addressed in the monthly security release happens roughly one week after the regular GitLab release.
content/handbook/security/best-practices/google-cloud-security-best-practices.md:114:Establish a plan to update GitLab after every security release, and update system packages at least once a week.
content/handbook/security/_index.md:227:#### Receive notification of security releases
content/handbook/security/_index.md:229:- To receive security release blog notifications delivered to your inbox, visit our [contact us](/handbook/company/contact/) page.
content/handbook/security/_index.md:230:- To receive release notifications via RSS, subscribe to our [security release RSS feed](https://about.gitlab.com/security-releases.xml) or our [RSS feed for all releases](https://about.gitlab.com/all-releases.xml).
content/handbook/security/_index.md:231:- For additional information regarding security releases, please visit the Delivery Team's [security releases](https://about.gitlab.com/handbook/engineering/releases/security-releases/) page.
content/handbook/security/_index.md:275:- GitLab Security Tanuki for use on security release blogs, social media and security related swag as appropriate:
content/handbook/ceo/office-of-the-ceo/jihu-support/_index.md:95:JiHu is responsible for building and releasing the JiHu Edition each month including all patch and security releases. For security releases, GitLab Inc will continue to follow our existing [security release process](https://gitlab.com/gitlab-org/release/docs/blob/master/general/security/process.md) to publish our [security releases](https://about.gitlab.com/releases/categories/releases/). To enable JiHu to build their security releases in a timely manner, GitLab Inc will notify JiHu when a security release is in progress along so that their teams can be on stand by. GitLab Inc will not notify JiHu of the contents of the security release or of the vulnerability.
content/handbook/ceo/office-of-the-ceo/jihu-support/_index.md:97:To notify JiHu of an upcoming security release, please simply post a comment in: https://gitlab.com/gitlab-jh/gitlab-jh-enablement/-/issues/112
content/handbook/ceo/office-of-the-ceo/jihu-support/_index.md:101:GitLab Inc will follow the [documented vulnerability disclosure process](https://about.gitlab.com/security/disclosure/#vulnerability-disclosure) and will not provide detailed information about vulnerabilities directly to JiHu. No information will be shared prior to or during an in-progress security release.
content/handbook/ceo/office-of-the-ceo/jihu-support/_index.md:103:Only after a GitLab [security release](https://about.gitlab.com/handbook/engineering/releases/security-releases/), GitLab Inc may provide JiHu with:
content/handbook/ceo/office-of-the-ceo/jihu-support/_index.md:105:- A link to the public security release blog post
content/handbook/marketing/blog/release-posts/_index.md:9:Release posts are [blog posts](https://about.gitlab.com/releases/categories/releases/) that announce changes to the GitLab application. This includes our regular cadence of monthly releases which happen [every month](/handbook/engineering/releases/), and patch/security releases whenever necessary.
content/handbook/marketing/blog/release-posts/_index.md:1625:The Delivery team is responsible for creating release posts for [patch](https://gitlab.com/gitlab-org/release/docs/-/blob/master/general/patch/blog-post.md) and [security releases](https://gitlab.com/gitlab-org/release/docs/blob/master/general/security/process.md#critical-security-releases).
content/handbook/marketing/blog/release-posts/_index.md:1627:Release posts should live in `sites/uncategorized/source/releases/posts`. For patch and security releases,
content/handbook/marketing/blog/_index.md:177:- security releases
content/handbook/marketing/inbound-marketing/search-marketing/analytics.md:38:- [Security releases dashboard](https://datastudio.google.com/u/0/reporting/2eabf79d-2173-488a-bb64-dcbddd900487/page/l7vj) — Website analytics data for security release blog posts.
content/handbook/marketing/brand-and-product-marketing/product-and-solution-marketing/demo/cicd-deep.md:51:- The file is versioned which means pipeline changes can be tested in branches supporting any changes in your app code. Similarly if you need to go back to an old version, perhaps to ship a security release, the associated pipeline will be exactly how you left it for that particular release.
content/handbook/engineering/deployments-and-releases/_index.md:9:1 **Monthly self-managed release**: GitLab version (XX.YY.0) [published every month][process-monthly-release]. From this monthly release, [patch][process-patch-release], [non-critical][process-security-release-non-critical], and [critical][process-security-release-critical] security releases are created as needed
content/handbook/engineering/releases/patch-releases/index.md:92:![Unplanned critical security release overview](unplanned-critical-patch-release-overview.jpg)
content/handbook/engineering/releases/patch-releases/index.md:103: - **Step 3: First steps** - Release preparation begins when release managers run the `prepare` chatops command to create the new release task issue to guide the security release. From here they follow the checklist to complete the initial set up and communication issues needed to prepare the release.
content/handbook/engineering/releases/backports.md:88:No it’s not. Backporting is a catch-all term for any activity that applies updates or patches from a newer version of software to an older version. At GitLab we have a specific [Patch Release process](/handbook/engineering/releases/#patch-releases-overview) that is applied according to the [Maintenance Policy](https://docs.gitlab.com/ee/policy/maintenance.html). This is one of the release methods we use to ship self-managed, along with the security release and regular monthly release. There is a separate [exception process](https://docs.gitlab.com/ee/policy/maintenance.html#backporting-to-older-releases) for backports that are outside the scope of our maintenance policy and these are delivered on a best effort basis and not guaranteed.
content/handbook/engineering/releases/_index.md:192:- Any (critical) [security releases](https://about.gitlab.com/handbook/engineering/releases/security-releases/) that require the attention of release
content/handbook/engineering/development/data-science/ai-powered/custom-models/_index.md:112:| Build Board | Milestone, `~group::custom models`, `~Deliverable` | `~workflow::ready for development`, `~workflow::in dev`, `~workflow::in review`, `~workflow::awaiting security release`, `~workflow::blocked` |
content/handbook/engineering/development/sec/secure/composition-analysis.md:86:1. Check for new security releases of our dependencies and ensure we use them:
content/handbook/engineering/development/sec/govern/authentication.md:186:1. `workflow::awaiting security release` - (security MRs only) the work is complete, just pending [backports](https://gitlab.com/gitlab-org/release/docs/-/blob/master/general/security/engineers.md#backports).
content/handbook/engineering/development/sec/govern/authentication.md:190:Issues with the `workflow::verification` or `workflow::awaiting security release` labels are, for the purposes of release planning, the same as closed issues, because the dev work is complete.
content/handbook/engineering/development/processes/infra-dev-escalation/process/index.md:43: 1. [GitLab.com deployment](https://gitlab.com/gitlab-org/gitlab/issues/198440) or a security release is blocked due to pipeline failure.
content/handbook/engineering/development/ops/verify/pipeline-execution/_index.md:467:1. `workflow::awaiting security release` (if applicable)
content/handbook/engineering/development/ops/verify/pipeline-execution/_index.md:479:`workflow::awaiting security release` is applied by an engineer after the security issue has passed verification and this label signals that it is ready for production but awaiting the next [monthly security release](https://about.gitlab.com/handbook/engineering/releases/security-releases/). When this label is applied, the issue's milestone should also be updated to the next milestone to align with when the next security release will happen.
content/handbook/engineering/development/ops/verify/pipeline-authoring/_index.md:223:**Note:** `workflow::awaiting security release` is applied by an engineer after the security issue has been approved by an AppSec engineer and a maintainer, and the backports have been created. This label signals that the MR is ready for merging into production, but it is awaiting the next [monthly security release](https://about.gitlab.com/handbook/engineering/releases/security-releases/). When this label is applied, the issue's milestone should also be updated to the next milestone to align with the next security release's milestone.
content/handbook/engineering/workflow/_index.md:53:The cost to fix test failures increases exponentially as time passes due to [merged results pipelines](https://docs.gitlab.com/ee/ci/pipelines/merged_results_pipelines.html) used. Auto-deploys, as well as monthly releases and security releases, depend on `gitlab-org/gitlab` master being green for tagging and [merging of backports](https://gitlab.com/gitlab-org/release/docs/-/blob/master/general/security/release-manager.md#regular-security-releases).
content/handbook/engineering/workflow/_index.md:75:If a broken `master` is blocking your team before auto-escalation (such as creating a security release) then you should:
content/handbook/engineering/workflow/_index.md:213: delays in releases / security releases.
content/handbook/engineering/workflow/_index.md:335:For more information on how the entire process works for security releases, see the
content/handbook/engineering/workflow/_index.md:336:[documentation on security releases](https://gitlab.com/gitlab-org/release/docs/blob/master/general/security/process.md).
content/handbook/engineering/infrastructure/core-platform/systems/distribution/maintenance/_index.md:21: is used for building official packages as well as hosting security release
content/handbook/engineering/infrastructure/environments/_index.md:155:| release | release.gitlab.net | Deploying self-managed releases | Final monthly, patch and security releases | Separate and local | SREs |
content/handbook/engineering/infrastructure/environments/_index.md:157:The release environment is an environment used for validating security releases, self-managed final monthly and patch versions. It does not have a full production HA topology or a
content/handbook/engineering/infrastructure/test-platform/debugging-qa-test-failures/index.md:251:[Omnibus nightly builds](https://dev.gitlab.org/gitlab/omnibus-gitlab/-/pipeline_schedules) are paused at the start of a security release and enabled again once the release is complete.
content/handbook/engineering/infrastructure/test-platform/debugging-qa-test-failures/index.md:256:1. An announcement from the release team when the security release has started.
content/handbook/engineering/infrastructure/test-platform/debugging-qa-test-failures/index.md:257:2. A notification from GitLab ChatOps when the security release has been published.
content/handbook/engineering/infrastructure/test-platform/debugging-qa-test-failures/index.md:259:For other ways to check if there is an ongoing security release, you can visit the `#releases` Slack channel's `Next Security Release` bookmark, or [search the GitLab project's issues
content/handbook/engineering/infrastructure/test-platform/debugging-qa-test-failures/index.md:260:by the `~"upcoming security release"` label](https://gitlab.com/gitlab-org/gitlab/-/issues/?sort=created_date&state=opened&label_name%5B%5D=upcoming%20security%20release&first_page_size=20).
content/handbook/engineering/infrastructure/test-platform/debugging-qa-test-failures/index.md:262:Please note that a security release issue can sometimes be created before a release is in progress.
content/handbook/engineering/infrastructure/test-platform/debugging-qa-test-failures/index.md:454: - If page above returns 404 error, check if the version exists in [GitLab Security repo](https://gitlab.com/gitlab-org/security/gitlab) in case there is a security release.
content/handbook/engineering/infrastructure/career.md:112:**Justification**: The Delivery team is tasked with making it increasingly safe and efficient for work product from all of GitLab to make its way to the production environment as well as into the monthly release, patch releases, and security releases. This is an area with continuing needs for additional automation as well as a wide scope of skills and experience.
content/handbook/engineering/infrastructure/emergency-change-processes.md:43:In cases where the emergency change is required as a means to rectify a security vulnerability, the [security release process] is followed.
content/handbook/engineering/infrastructure/emergency-change-processes.md:51:[security release process]: https://gitlab.com/gitlab-org/release/docs/-/blob/master/general/security/process.md
content/handbook/engineering/infrastructure/team/delivery/_index.md:56:- Scale security releases to meet organization needs whilst maintaining or reducing release manager workload
content/handbook/engineering/infrastructure/team/delivery/_index.md:94:1. Coordination and preparation of GitLab releases for self-managed users for the monthly patch and security releases.
content/handbook/product-development-flow/_index.md:273:|<i class="fab fa-gitlab fa-fw" style="color:rgb(252,109,38); font-size:1.25em" aria-hidden="true"></i> `workflow::awaiting security release` | Applied by an engineer after the security issue has passed verification, this label signals that it is ready but awaiting the next [monthly security release](https://about.gitlab.com/handbook/engineering/releases/security-releases/).|
content/handbook/company/okrs/2018-q3.md:503: - Both critical and regular security release processes could use more automation.
content/handbook/company/okrs/2018-q2.md:81: - Security: Design, document, and implement security release process and craft epic with S1 & S2 issues and present to product for prioritization => 100%, [security release process](https://gitlab.com/gitlab-org/release/docs/blob/master/general/security/process.md)
content/handbook/company/okrs/2018-q2.md:380: - Continue to refine and improve upon critical and non-critical security release processes. This will involve continuing to train new RMs to become familiar with the process.
content/handbook/company/okrs/fy20-q1.md:95: 1. AppSec: Security release: complete at least 4 cycles of security release process/checklist X%
content/handbook/company/okrs/fy20-q1.md:135: 1. Gitter: Improve security practices: Enable use of dev.gitlab.org for security issues, document security release process for gitter.im in partnership with Security => 100%
content/handbook/company/okrs/fy20-q1.md:136: - Now using `https://dev.gitlab.org/gitlab/gitter/webapp` for security releases/fixes
content/handbook/company/okrs/2017-q4.md:300: - Improve overall security release process by defining roles and expectations of release managers, developers, and security team
content/handbook/company/okrs/2018-q1.md:191: - Security: Manage [Advance Notification Program](https://gitlab.com/gitlab-com/marketing/general/issues/1996) for security releases (SecOps-KW/JT/JR) => 100%
content/handbook/company/okrs/2018-q1.md:454: - We were not able to get as far along in application security reviews, due to other efforts taking higher priority (e.g., remediating new open issues, security release process efforts).
content/handbook/company/okrs/2018-q4.md:142: - Complete at least 2 cycles of security release process: 2/2, 100% [Releases](https://about.gitlab.com/releases/categories/releases/)
content/handbook/company/okrs/2018-q4.md:601: - Work with release delivery and management team to address security release issues.
content/handbook/company/working-groups/object-storage.md:223: - Another security release, still in **12.10**, was needed to completely fix [Nuget packages](https://gitlab.com/gitlab-org/gitlab/-/issues/214636).
content/job-families/security/application-security.md:32:- Support the preparation of security releases.
content/job-families/security/application-security.md:78:- Lead both critical and regular security releases.
content/job-families/security/security-engineer.md:261:- Facilitate preparation of both critical and regular security releases