Skip to content
Snippets Groups Projects
Commit 9c36c658 authored by James Ritchey's avatar James Ritchey :speech_balloon: Committed by Josh Lemos
Browse files

Fix security-engineering to product-security redirect

parent b1d39ba4
No related branches found
No related tags found
1 merge request!3355Fix security-engineering to product-security redirect
Showing
with 25 additions and 25 deletions
......@@ -117,7 +117,7 @@ The [IT Engineering - Access Management](/handbook/business-technology/engineeri
## Cloud Infrastructure Management
The [IT Engineering - Infrastructure](/handbook/business-technology/engineering/infrastructure) team collaborates with the [Engineering Infrastructure Reliability (SRE)](/handbook/engineering/infrastructure/) and [Infrastructure Security](/handbook/security/security-engineering/infrastructure-security/) teams to provide Infrastructure Shared Services for all AWS, Azure, and GCP related requests and support across the organization. See the [Infrastructure Standards](/handbook/infrastructure-standards) handbook page to learn more.
The [IT Engineering - Infrastructure](/handbook/business-technology/engineering/infrastructure) team collaborates with the [Engineering Infrastructure Reliability (SRE)](/handbook/engineering/infrastructure/) and [Infrastructure Security](/handbook/security/product-security/infrastructure-security/) teams to provide Infrastructure Shared Services for all AWS, Azure, and GCP related requests and support across the organization. See the [Infrastructure Standards](/handbook/infrastructure-standards) handbook page to learn more.
Our focus is on organizational policy management, access request provisioning, and services that are outside of the [Reliability Engineering](/handbook/engineering/infrastructure/) scope of hosting the Gitlab.com SaaS service, such as the provisioning of demo/sandbox/test infrastructure for team members.
......
......@@ -111,7 +111,7 @@ We are in the process of creating <a href="/handbook/it/access-manager">GitLab A
<br />
The IT Infrastructure team manages AWS and GCP infrastructure that is not related to GitLab.com SaaS production infrastructure and provide managed infrastructure services for other departments, including most ephemeral sandbox infrastructure needs across the company. We also handle access requests for cloud infrastructure and DNS/domain name requests.<br />
<br />
We collaborate with the <a href="/handbook/engineering/infrastructure">Reliability Engineering (SRE)</a> and <a href="/handbook/security/security-engineering/infrastructure-security/">Infrastructure Security</a> teams to provide Infrastructure Shared Services for all AWS, Azure, and GCP related requests and support across the organization.<br />
We collaborate with the <a href="/handbook/engineering/infrastructure">Reliability Engineering (SRE)</a> and <a href="/handbook/security/product-security/infrastructure-security/">Infrastructure Security</a> teams to provide Infrastructure Shared Services for all AWS, Azure, and GCP related requests and support across the organization.<br />
<br />
We also provide escalation engineering and triage support for the <a href="/handbook/security/security-operations/sirt">Security Incident Response Team ("SIRT")</a> and <a href="/handbook/security/threat-management/red-team">Security Red Team</a> when security anomalies, events, or incidents require AWS/GCP subject matter expertise.<br />
<br />
......
......@@ -26,7 +26,7 @@ In the interim, please visit the following handbook pages:
- [Security Compliance](/handbook/security/security-assurance/security-compliance/)
- [Security Governance](/handbook/security/security-assurance/governance/)
- [Security Risk](/handbook/security/security-assurance/security-risk/)
- [Product Security Sub-department](/handbook/security/security-engineering/)
- [Product Security Sub-department](/handbook/security/product-security/)
- [Application Security](/handbook/security/product-security/application-security/)
- [Infrastructure Security](/handbook/security/product-security/infrastructure-security/)
- [Security Operations Sub-department](/handbook/security/security-operations)
......
......@@ -31,7 +31,7 @@ An automated comment pings the AppSec team after the MR receives its first appro
### Determining who will perform a security review of a JiHu contribution
When the AppSec team is pinged on a JiHu contribution, it will typically be first seen by
the AppSec engineer on [Triage (mentions and issues) Rotation](/handbook/security/security-engineering/application-security/runbooks/triage-rotation.html). This person should:
the AppSec engineer on [Triage (mentions and issues) Rotation](/handbook/security/product-security/application-security/runbooks/triage-rotation.html). This person should:
1. Ping the stable counterpart for the [relevant part of the codebase](/handbook/product/categories/#devops-stages) and ask them to perform the review
- If the change is small or easy to review, the AppSec engineer on triage can do the review themselves and `@-mention` the stable counterpart for visibility
......
......@@ -5,7 +5,7 @@ title: Release Certification
## Process for Release Certification
Every release with JiHu contributions needs to be certified by a member of the
[Federal Application Security team](/handbook/security/security-engineering/application-security/index.html).
[Federal Application Security team](/handbook/security/product-security/application-security/index.html).
This is required to satisfy PubSec/FedRamp requirements and
to handle JiHu's merge request contributions to GitLab Inc repositories.
......
......@@ -45,7 +45,7 @@ great results by using it.
- Establish criteria for when a blueprint should be used.
- Identify cross-functional touchpoints and consolidate upstream processes like
[production readiness](/handbook/engineering/infrastructure/production/readiness/),
[AppSec reviews](/handbook/security/security-engineering/application-security/runbooks/review-process),
[AppSec reviews](/handbook/security/product-security/application-security/runbooks/review-process),
and [creation of release posts](/handbook/marketing/blog/release-posts/).
- Develop strategy for incorporating this process and the Engineering roadmap into Product planning
and prioritization via the [Cross-functional Prioritization][next-prioritization] framework.
......
......@@ -4,7 +4,7 @@ We plan in monthly cycles in accordance with our [Product Development Timeline](
* This issue should include a tentative plan for the release, along with links to boards that represent the proposed work for the milestone. Please see examples from [Fulfilment](https://gitlab.com/gitlab-org/fulfillment-meta/issues/37), [Manage](https://gitlab.com/gitlab-org/manage/issues/65), and [Create](https://gitlab.com/gitlab-org/create-stage/issues/33)!
* Issues without estimates should have the `workflow::planning breakdown` label applied to make estimation easier and be marked for the coming release as `Deliverable`. Issues of particular significance to our stage's strategy should be marked with `direction`.
* At this stage, the Product Manager applies the `quad-planning::ready` label to all `feature` issues and assigns them to the SET counterpart for the group.
* Identify any issues which may have security implications, and ping the [Application Security Stable Counterpart](/handbook/security/security-engineering/application-security/stable-counterparts.html) and/or [request an Application Security Review](/handbook/security/security-engineering/application-security/appsec-reviews.html). The Product Manager will list these in the planning issue.
* Identify any issues which may have security implications, and ping the [Application Security Stable Counterpart](/handbook/security/product-security/application-security/stable-counterparts.html) and/or [request an Application Security Review](/handbook/security/product-security/application-security/appsec-reviews.html). The Product Manager will list these in the planning issue.
* To review the proposed scope and kick off estimation, synchronous meetings with Engineering and Design are recommended.
* By the 12th, all planned issues proposed for the next release should be estimated by engineering (`workflow:ready for development`).
* To assist with capacity planning, we track the cumulative weight of closed issues over the past 3 releases on a rolling basis. The proposed scope of work for the next release should not exceed 80% of this to account for slippage from the previous release.
......
......@@ -241,7 +241,7 @@ from PM or UX.
The group has an existing [threat model](https://gitlab.com/gitlab-com/gl-security/appsec/threat-models/-/blob/master/gitlab-org/gitlab/GitLab%20Migration.md) to assist in identifying issues that may have security implications, but there are other considerations.
An [Application Security Review](/handbook/security/security-engineering/application-security/appsec-reviews.html) should be requested when the issue or MR might have security implications. These include, but aren't limited to, issues or MRs which:
An [Application Security Review](/handbook/security/product-security/application-security/appsec-reviews.html) should be requested when the issue or MR might have security implications. These include, but aren't limited to, issues or MRs which:
- falls under the threat model
- handles binary files (downloading, decompressing, extracting, moving, deleting)
- modifies or uses file manipulation services
......
......@@ -287,7 +287,7 @@ The MRs must meet the following criteria:
In addition to the approval rules, MRs may require additional reviews as suggested by the [Danger bot](https://docs.gitlab.com/ee/development/dangerbot.html):
1. Modifications to the DB require database reviewer and maintainer approval
1. Security-related issues (such as changes to authentication) require a [Security review](/handbook/security/security-engineering/application-security/appsec-reviews.html#adding-features-to-the-queue)
1. Security-related issues (such as changes to authentication) require a [Security review](/handbook/security/product-security/application-security/appsec-reviews.html#adding-features-to-the-queue)
1. Changes to the SFDC APIs require review by the [Sales team](/handbook/sales/field-operations/sales-systems/)
1. Changes to the Zuora APIs require review by the [EntApps team](/handbook/business-technology/enterprise-applications/)
1. Changes to the user experience require a [UX Review](/handbook/product/ux/product-designer/mr-reviews/).
......
......@@ -156,7 +156,7 @@ Those comfortable with external interactions may offer their services to the Fie
### Security Guidelines for Incubation Projects
Incubation Engineers should familiarize themselves with the [GitLab AppSec Review](/handbook/security/security-engineering/application-security/appsec-reviews.html) process and preferably have the AppSec review triggered early for each merge request when appropriate.
Incubation Engineers should familiarize themselves with the [GitLab AppSec Review](/handbook/security/product-security/application-security/appsec-reviews.html) process and preferably have the AppSec review triggered early for each merge request when appropriate.
Incubation Engineers are often required to create prototypes or demo applications as they are iterating on ideas and gathering feedback. Below are some security guidelines to keep in mind while building these applications:
......@@ -170,7 +170,7 @@ For UX support, see how Product Designers [engage with Single Engineer Groups (S
### Releasing Features
When releasing features, ensure you engage the [Application Security team](/handbook/security/security-engineering/application-security/stable-counterparts.html) if your feature matches the [guidelines of what should be reviewed](/handbook/security/security-engineering/application-security/appsec-reviews.html#what-should-be-reviewed), and follow the [guidelines for documentation](/handbook/product/ux/technical-writing/workflow/#documentation-for-a-product-change).
When releasing features, ensure you engage the [Application Security team](/handbook/security/product-security/application-security/stable-counterparts.html) if your feature matches the [guidelines of what should be reviewed](/handbook/security/product-security/application-security/appsec-reviews.html#what-should-be-reviewed), and follow the [guidelines for documentation](/handbook/product/ux/technical-writing/workflow/#documentation-for-a-product-change).
### Write a Release Post
......
......@@ -109,7 +109,7 @@ we will need to put more work into building a simple solution.
**Availability/Reliability**, **Quality**, **Security**, and **Performance** are the pillars for building reliable software. Reliability is our contract with our customers that say you can count on us to deliver an available and dependable product. Everyone in the organization has a role to play.
Engineers, Product Managers, and Designers have the most direct influence over the reliability of the code through either planning, implementation, monitoring (e.g. [Kibana](/handbook/support/workflows/kibana.html), [Sentry](/handbook/support/workflows/sentry.html), Grafana and other [GitLab.com monitoring tools](/handbook/engineering/monitoring/#monitoring)), or prioritization of the work. Product and Engineering management monitors (e.g. [Error Budgets](/handbook/engineering/error-budgets/)) and measures the reliability of features and makes recommendations if necessary. Our focus on [learning and development](/handbook/people-group/learning-and-development/) will also ensure that teams have the tools and training required to build reliable software. The [Infrastructure](/handbook/engineering/infrastructure/#mission), [Application Security](/handbook/security/security-engineering/application-security/#application-security-mission), [Database](/handbook/engineering/infrastructure/core-platform/data_stores/database/) and [Quality](/handbook/engineering/quality/#mission) teams are the Subject Matter Experts supporting product development teams.
Engineers, Product Managers, and Designers have the most direct influence over the reliability of the code through either planning, implementation, monitoring (e.g. [Kibana](/handbook/support/workflows/kibana.html), [Sentry](/handbook/support/workflows/sentry.html), Grafana and other [GitLab.com monitoring tools](/handbook/engineering/monitoring/#monitoring)), or prioritization of the work. Product and Engineering management monitors (e.g. [Error Budgets](/handbook/engineering/error-budgets/)) and measures the reliability of features and makes recommendations if necessary. Our focus on [learning and development](/handbook/people-group/learning-and-development/) will also ensure that teams have the tools and training required to build reliable software. The [Infrastructure](/handbook/engineering/infrastructure/#mission), [Application Security](/handbook/security/product-security/application-security/#application-security-mission), [Database](/handbook/engineering/infrastructure/core-platform/data_stores/database/) and [Quality](/handbook/engineering/quality/#mission) teams are the Subject Matter Experts supporting product development teams.
## Velocity
......
......@@ -134,7 +134,7 @@ We plan in monthly cycles in accordance with our [Product Development Timeline](
- We try to plan 1-2 Milestones ahead, we include a max of 2 planning issues (`workflow::planning breakdown` and `workflow::solution validation`) per person at the start of a Milestone, this is a rule of thumb.
- When a planning issue is included in a Milestone it is also assigned to team members. This is to provide clarity on what and who is doing what planning in the Milestone.
- By the 20th, Product should review the release that just concluded development (currently, we transition development work from one release to the next on the 18th) for issues that slipped from the milestone. Please evaluate issues that weren't merged in time and reschedule them appropriately.
- Identify any issues which may have security implications, and ping the [Application Security Stable Counterpart](/handbook/security/security-engineering/application-security/stable-counterparts/) and/or [request an Application Security Review](/handbook/security/security-engineering/application-security/appsec-reviews/#adding-features-to-the-queue--requesting-a-security-review). The Product Manager will list these in the planning issue.
- Identify any issues which may have security implications, and ping the [Application Security Stable Counterpart](/handbook/security/product-security/application-security/stable-counterparts/) and/or [request an Application Security Review](/handbook/security/product-security/application-security/appsec-reviews/#adding-features-to-the-queue--requesting-a-security-review). The Product Manager will list these in the planning issue.
### Issue Prioritization
......
......@@ -178,7 +178,7 @@ We use the Vulnerability Report with filters to focus on items matching [our pol
1. [License-db Vulnerability Report[License-db Vulnerability Report]
- To configure the report manually, select all [license-db](#license-db) projects and apply the `Still detected` activity filter and apply the `Needs Triage` status.
For each item, investigate and either [dismiss](#dismissing-a-vulnerability) or [confirm](#confirming-a-vulnerability) it. If it's not clear whether there's indeed a threat, escalate to our [Application Security team](/handbook/security/security-engineering/application-security/).
For each item, investigate and either [dismiss](#dismissing-a-vulnerability) or [confirm](#confirming-a-vulnerability) it. If it's not clear whether there's indeed a threat, escalate to our [Application Security team](/handbook/security/product-security/application-security/).
> Refer to [Vulnerability status definitions](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/#vulnerability-status-values) in case you are unsure of what each of them mean.
......@@ -257,11 +257,11 @@ You can leverage quick actions to add the necessary labels.
/label ~"Category:Software Composition Analysis"
/label ~"Category:Container Scanning"
It's important to add the `~security` and `~"bug::vulnerability"` labels as described above, because the [`AppSec Escalation Engine`](https://gitlab.com/gitlab-com/gl-security/engineering-and-research/automation-team/appsec-escalator/-/blob/3a7e8a4baed7b7e54039558f4f76328046543a0c/README.md#L3) will automatically pick up any issues with these labels and add additional labels `~security-sp-label-missing` and `~security-triage-appsec` as well as mention the issue in the `#sec-appsec` Slack channel. At this point, the [Stable Counterpart](/handbook/engineering/development/sec/secure/#stable-counterparts) or [Application Security team](/handbook/security/security-engineering/application-security/) triage person will pick up the issue and assign a severity as part of the appsec triage rotation.
It's important to add the `~security` and `~"bug::vulnerability"` labels as described above, because the [`AppSec Escalation Engine`](https://gitlab.com/gitlab-com/gl-security/engineering-and-research/automation-team/appsec-escalator/-/blob/3a7e8a4baed7b7e54039558f4f76328046543a0c/README.md#L3) will automatically pick up any issues with these labels and add additional labels `~security-sp-label-missing` and `~security-triage-appsec` as well as mention the issue in the `#sec-appsec` Slack channel. At this point, the [Stable Counterpart](/handbook/engineering/development/sec/secure/#stable-counterparts) or [Application Security team](/handbook/security/product-security/application-security/) triage person will pick up the issue and assign a severity as part of the appsec triage rotation.
Once the issue is created, please add it to [the vulnerability's linked items](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/#link-a-vulnerability-to-existing-issues) for ease of tracking.
Developers reporting the security issue should help the [Application Security team](/handbook/security/security-engineering/application-security/) assess the impact of the vulnerability, and update the issue description with an `Impact` section.
Developers reporting the security issue should help the [Application Security team](/handbook/security/product-security/application-security/) assess the impact of the vulnerability, and update the issue description with an `Impact` section.
If immediate feedback is required, then add a comment to the vulnerability issue with an `@`-mention directed at one of the Security Engineers listed in the [Stable Counterpart](/handbook/engineering/development/sec/secure/#stable-counterparts) section, or ping them on slack.
......
......@@ -24,7 +24,7 @@ When creating a new project, please follow these steps:
If you don't have the permissions to create a project there, you can create an [Access Request issue](/handbook/business-technology/team-member-enablement/onboarding-access-requests/access-requests/#individual-or-bulk-access-request) and ping one of the Maintainers ([gitlab-org](https://gitlab.com/groups/gitlab-org/-/group_members?sort=access_level_desc), and [gitlab-com](https://gitlab.com/groups/gitlab-com/-/group_members?sort=access_level_desc)) for approval.
1. Configure the project repository to use `main` as the name of the default branch.
1. [Add the project to the list of GitLab projects in `projects.yml`](https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/doc/projects.md).
1. Help [AppSec](/handbook/security/security-engineering/application-security/) [categorizing your new project]({{ ref "/handbook/security/security-engineering/application-security/inventory/#how-to-categorize-projects" }}).
1. Help [AppSec](/handbook/security/product-security/application-security/) [categorizing your new project]({{ ref "/handbook/security/product-security/application-security/inventory/#how-to-categorize-projects" }}).
1. Add a license to the repository. Contact #legal as to which license to add. A sample license is here: [`gitlab-org/gitlab` MIT License](https://gitlab.com/gitlab-org/gitlab/blob/master/LICENSE), but contact legal before using it.
1. Add a section titled "Developer Certificate of Origin and License" to `CONTRIBUTING.md` in the repository. It is easiest to simply copy-paste the [`gitlab-org/gitaly` DCO + License section](https://gitlab.com/gitlab-org/gitaly/-/blob/master/CONTRIBUTING.md#developer-certificate-of-origin-license) verbatim.1. Add any further relevant details to the Contribution Guide. See [Contribution Example](https://gitlab.com/gitlab-org/gitlab/blob/master/CONTRIBUTING.md).
1. Add a link to `CONTRIBUTING.md` from the project's `README.md`.
......
......@@ -809,9 +809,9 @@ Open merge requests may also have other properties that indicate that the engine
## Security is everyone's responsibility
[Security](/security/) is our top priority. Our Security Team is raising the bar on security every day to protect users' data and make GitLab a safe place for everyone to contribute. There are many lines of code, and Security Teams need to scale. That means shifting security left in the [Software Development LifeCycle (SDLC)](/stages-devops-lifecycle/). Each team has an [Application Security Stable Counterpart](/handbook/security/security-engineering/application-security/stable-counterparts.html) who can help you, and you can find more secure development help in the `#sec-appsec` Slack channel.
[Security](/security/) is our top priority. Our Security Team is raising the bar on security every day to protect users' data and make GitLab a safe place for everyone to contribute. There are many lines of code, and Security Teams need to scale. That means shifting security left in the [Software Development LifeCycle (SDLC)](/stages-devops-lifecycle/). Each team has an [Application Security Stable Counterpart](/handbook/security/product-security/application-security/stable-counterparts.html) who can help you, and you can find more secure development help in the `#sec-appsec` Slack channel.
Being able to start the security review process earlier in the software development lifecycle means we will catch vulnerabilities earlier, and mitigate identified vulnerabilities before the code is merged. You should know when and how to proactively [seek an Application Security Review](/handbook/security/security-engineering/application-security/appsec-reviews.html). You should also be familiar with our [Secure Coding Guidelines](https://docs.gitlab.com/ee/development/secure_coding_guidelines.html).
Being able to start the security review process earlier in the software development lifecycle means we will catch vulnerabilities earlier, and mitigate identified vulnerabilities before the code is merged. You should know when and how to proactively [seek an Application Security Review](/handbook/security/product-security/application-security/appsec-reviews.html). You should also be familiar with our [Secure Coding Guidelines](https://docs.gitlab.com/ee/development/secure_coding_guidelines.html).
We are fixing the obvious security issues before every merge, and therefore, scaling the security review process. Our workflow includes a check and validation by the reviewers of every merge request, thereby enabling developers to act on identified vulnerabilities before merging. As part of that process, developers are also encouraged to reach out to the Security Team to discuss the issue at that stage, rather than later on, when mitigating vulnerabilities becomes more expensive. After all, security is everyone's job. See also our [Security Paradigm](https://about.gitlab.com/direction/secure/#security-paradigm)
......
......@@ -55,7 +55,7 @@ For cloud infrastructure, we have created top-level AWS organizational units and
| `it` | Orange/Yellow/Green | [IT Engineering](/handbook/business-technology/engineering/#infrastructure-engineering) | [Realm Docs](/handbook/infrastructure-standards/realms/it) | `#it_help` (tag `@it-eng`) |
| `saas` | Red/Orange/Yellow/Green | [Reliability Engineering](/handbook/engineering/infrastructure/team/reliability/) | [Realm Docs](/handbook/infrastructure-standards/realms/saas) | `#infrastructure-lounge` |
| `sandbox` | Green | Self Service (Team Member) | [Sandbox Cloud](/handbook/infrastructure-standards/realms/sandbox) | `#sandbox-cloud-questions` |
| `security` | Orange/Yellow/Green | [Infrastructure Security](/handbook/security/security-engineering/infrastructure-security/) | [Realm Docs](/handbook/infrastructure-standards/realms/security) | `#security-infrasec` |
| `security` | Orange/Yellow/Green | [Infrastructure Security](/handbook/security/product-security/infrastructure-security/) | [Realm Docs](/handbook/infrastructure-standards/realms/security) | `#security-infrasec` |
### Managed by Infrastructure Teams
......
......@@ -109,7 +109,7 @@ For any infrastructure services related to business operations and our tech stac
New SaaS applications should go through the [Procurement Process](/handbook/finance/procurement/) and are managed by the respective department's [system owners](/handbook/business-technology/#cross-department-system-owners).
Self-hosted application infrastructure is determined on a case-by-case basis and is architected in collaboration with [IT Infrastructure](/handbook/business-technology/it/engineering/infrastructure/), [Security Architecture](/handbook/security/architecture/), [Infrastructure Security](/handbook/security/security-engineering/infrastructure-security/), [Application Security](/handbook/security/security-engineering/application-security/), and [3rd Party Risk](/handbook/security/security-assurance/security-risk/third-party-risk-management.html). Please tag `@jeffersonmartin` in an issue for preliminary guidance on new services. If you do not have an issue yet, please create one in the [IT Infrastructure issue tracker](https://gitlab.com/gitlab-com/business-technology/engineering/infrastructure/issue-tracker/-/issues).
Self-hosted application infrastructure is determined on a case-by-case basis and is architected in collaboration with [IT Infrastructure](/handbook/business-technology/it/engineering/infrastructure/), [Security Architecture](/handbook/security/architecture/), [Infrastructure Security](/handbook/security/product-security/infrastructure-security/), [Application Security](/handbook/security/product-security/application-security/), and [3rd Party Risk](/handbook/security/security-assurance/security-risk/third-party-risk-management.html). Please tag `@jeffersonmartin` in an issue for preliminary guidance on new services. If you do not have an issue yet, please create one in the [IT Infrastructure issue tracker](https://gitlab.com/gitlab-com/business-technology/engineering/infrastructure/issue-tracker/-/issues).
#### Accessing your AWS Account
......
......@@ -289,7 +289,7 @@ This phase begins after work has been broken down, and [prioritized](/handbook/p
When an issue is in development the Software Engineer in Test ([SET](/handbook/engineering/quality/quality-engineering/#stable-counterparts)) will ensure the [quad planning](/handbook/engineering/infrastructure/test-platform/quad-planning/#process) process is being followed regarding test plans, regression jobs, end to end tests, etc. Coordination is key between the assigned development engineer and the SET during this phase.
When an issue is in `workflow::in review`, the Application Security Engineer would help validate the risk mitigations through the non-blocking [application security review process](/handbook/security/security-engineering/application-security/appsec-reviews.html).
When an issue is in `workflow::in review`, the Application Security Engineer would help validate the risk mitigations through the non-blocking [application security review process](/handbook/security/product-security/application-security/appsec-reviews.html).
Documentation for the work will be developed by the engineer and the Technical Writer (see [Documentation with code as workflow](/handbook/product/ux/technical-writing/workflow/#documentation-with-code-as-a-workflow)). The Technical Writer should review the documentation as part of the development process. Items discovered during a documentation review should not block issues moving into the next phase. This may drive the creation of follow-on improvement MRs for the documentation, after release.
......@@ -303,7 +303,7 @@ When an issue is in `workflow::verification`, the responsible engineer will [man
| Outcomes | Activities | DRI |
|----------|------------|-----|
|<i class="fab fa-gitlab fa-fw" style="color:rgb(252,109,38); font-size:1.25em" aria-hidden="true"></i> **Feature is built** | - Engineering Manager check that [definition of done](https://gitlab.com/gitlab-org/gitlab-foss/-/blob/master/doc/development/contributing/merge_request_workflow.md#definition-of-done) is met<br/>- Provide regular status updates to stakeholders<br/>- Provide asynchronous updates to avoid status check-ins and synchronous stand-ups<br/> - Engineers follow the [engineering process](/handbook/engineering/workflow/#basics) to implement assigned issues. | Engineer |
|<i class="fab fa-gitlab fa-fw" style="color:rgb(252,109,38); font-size:1.25em" aria-hidden="true"></i> **Feature is tested** | - Engineers test features they implement (see [Definition of done](https://gitlab.com/gitlab-org/gitlab-foss/-/blob/master/doc/development/contributing/merge_request_workflow.md#definition-of-done)).<br/>- SET sets testing requirements on the issue.<br/>- SET follows up on any specific test coverage changes necessary as an outcome of Quad Planning. <br/>- Technical Writers complete a [review](/handbook/product/ux/technical-writing/#reviews) of any developed documentation. <br/>- Application Security Engineer validates the risk mitigations through the non-blocking [application security review process](/handbook/security/security-engineering/application-security/appsec-reviews.html). | Engineer |
|<i class="fab fa-gitlab fa-fw" style="color:rgb(252,109,38); font-size:1.25em" aria-hidden="true"></i> **Feature is tested** | - Engineers test features they implement (see [Definition of done](https://gitlab.com/gitlab-org/gitlab-foss/-/blob/master/doc/development/contributing/merge_request_workflow.md#definition-of-done)).<br/>- SET sets testing requirements on the issue.<br/>- SET follows up on any specific test coverage changes necessary as an outcome of Quad Planning. <br/>- Technical Writers complete a [review](/handbook/product/ux/technical-writing/#reviews) of any developed documentation. <br/>- Application Security Engineer validates the risk mitigations through the non-blocking [application security review process](/handbook/security/product-security/application-security/appsec-reviews.html). | Engineer |
### Build phase 3: Launch
......
......@@ -83,7 +83,7 @@ Reviewers of controlled documents are required to
| Access Level Wristband Colors | Establishes access level categories for managing access to systems at GitLab | [https://about.gitlab.com/handbook/it/policies/access-level-wristbands/](/handbook/it/policies/access-level-wristbands/) | IT Management |
| Access Management Policy | Specifies Centralized access management ensuring that the authorized GitLab team-members have access to the correct data and systems at the correct level. | [https://about.gitlab.com/handbook/security/access-management-policy/](/handbook/security/access-management-policy/)| Security Assurance Management |
| Access Review Procedure | Defines the importance of the User access review process as an important control activity required for internal and external IT audits, helping to minimize threats, and provide assurance of who has access to what. | [https://about.gitlab.com/handbook/security/security-assurance/security-compliance/access-reviews/](/handbook/security/security-assurance/security-compliance/access-reviews/)| Security Compliance Team |
| Application Vulnerability Management Procedure | Designed to provide insight into our environments, promote healthy patch management among other preventative best-practices, and remediate risk; all with the end goal to better secure our environments and our product. | [https://about.gitlab.com/handbook/security/security-engineering/application-security/vulnerability-management](/handbook/security/security-engineering/application-security/vulnerability-management/) | Security Management |
| Application Vulnerability Management Procedure | Designed to provide insight into our environments, promote healthy patch management among other preventative best-practices, and remediate risk; all with the end goal to better secure our environments and our product. | [https://about.gitlab.com/handbook/security/product-security/application-security/vulnerability-management](/handbook/security/product-security/application-security/vulnerability-management/) | Security Management |
| Audit Logging Policy | Ensures the proper operation and security of critical information system activity. | [https://about.gitlab.com/handbook/security/audit-logging-policy/](/handbook/security/audit-logging-policy/) | Security Assurance Management |
| Backup Procedure | Documents that our production databases are taken every 24 hours with continuous incremental data (at 60 sec intervals). | [https://about.gitlab.com/handbook/engineering/infrastructure/production/#backups](/handbook/engineering/infrastructure/production/#backups) | Infrastructure Management Team |
| Backup Recovery Testing Procedure | Documentation implementing a backup testing pipeline to detect whether or not the backup is actually restorable and in good shape. | [https://gitlab.com/gitlab-com/gl-infra/gitlab-restore/postgres-gprd/blob/master/README.md](https://gitlab.com/gitlab-com/gl-infra/gitlab-restore/postgres-gprd/blob/master/README.md) | Infrastructure Management Team |
......
......@@ -334,7 +334,7 @@ The Identity Team has three functional specialties and collaborates cross-functi
### Identity Infrastructure Engineering
The Identity Infrastructure team is focused on our top-level cloud provider infrastructure organization-level management for AWS and GCP in collaboration with the [Infrastructure Security](/handbook/security/security-engineering/infrastructure-security) team.
The Identity Infrastructure team is focused on our top-level cloud provider infrastructure organization-level management for AWS and GCP in collaboration with the [Infrastructure Security](/handbook/security/product-security/infrastructure-security) team.
We build self-service tools for users to create their own AWS accounts and GCP projects and provide castle wall hardening.
......
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment