Design and operationalise an intake process for ProdSecEng
## Project Description
[VulnMapper](https://gitlab.com/gitlab-com/gl-security/product-security/vulnerability-management/vulnerability-management-internal/vulnmapper-product-roadmap) is a project created by the VulnMgmt team. ProdSecEng needs to start taking over partial ownership of this tool so they can lead the work to get the different tooling and automation incorporated into the GitLab product (if there is product fit and Product/Engineering alignment). We specifically call out "partial" ownership as VulnMapper is a significant tool for VulnMgmt, and we expect to slowly start handing over responsibilities over time.
In order to start getting ProdSecEng involved with VulnMapper, we we need to:
1. Have a clear way for the VulnMgmt team to engage with ProdSecEng on any future tooling or automation needs (intake process)
2. Make sure those needs go through a clear process of use case identification, product fit mapping, etc.
While we want to develop this process for VulnMapper as a first iteration, ideally we want this process to be used for future tooling or automation needs that the rest of ProdSec may need and give them a clear way to engage with us or find an existing solution.
### **Context**
ProdSecEng are the stewards of automation and tooling within Product Security, with the mission of shepherding internal tools into the GitLab product. The [Security Interlock](https://handbook.gitlab.com/handbook/security/product-security/security-platforms-architecture/security-interlock/) initiative drives this: if our Security teams have had to build their own tooling and automation to do their work, and there is a clear fit for other customers like us, then we want to turn those internal tools into product features. This enables the Security division to dogfood our own product and allows GitLab to better serve the security teams of our customers.
This intake process is the **first of three interconnected workflows** that ProdSecEng will operationalise:
| \# | Workflow | Purpose | Status |
|----|----------|---------|--------|
| 1 | **Intake** (this epic) | How ProdSecEng receives, evaluates, accepts tooling/automation work; how maintenance expectations are set | In progress |
| 2 | **Co-create** (future epic) | Product validation → Product integration → ProdSec transition/sunsetting | Partially in progress (via [Initial Contribution of VulnMapper](https://gitlab.com/groups/gitlab-com/gl-security/product-security/-/work_items/57)) |
| 3 | **Maintenance & Inventory Prioritisation** (parallel) | Ongoing maintenance of existing tooling until product integration or sunsetting | Partially in progress (via [ProdSecEng Tooling Inventory Review](https://gitlab.com/groups/gitlab-com/gl-security/product-security/product-security-engineering/-/work_items/52)) |
## Project Goals
The intake process must enable ProdSecEng to answer the following when a new tool/automation request, or existing tool/automation ownership transfer is presented:
1. **Understand the problem and need**
- What are the user requirements from the ProdSec team?
- What alternative solutions (within GitLab, or otherwise) were explored? Or did the team go straight to building internal tooling?
- What design decisions were made (language, tech stack, architecture)?
- If the tool/automation already exists: How does it work (data flow, process flow)? Who uses it? What business processes depend on it?
2. **Understand short-term maintainability**
- Can we provide an SLO (how quickly we respond to issues)?
- Can we provide an RTO (how quickly we restore service if it goes down)?
- How critical is this tool to the team? What is the worst case if it's unavailable?
- Does this tool tie into the team's or business' priorities or mission?
- How quickly do we need to get this tool to a maintainable state?
- How quickly do we need to integrate this into the product to reduce risk and reliance on ProdSecEng?
3. **Understand the path to product**
- Do we already have an understanding of the product fit?
- Does this align with existing Product or Engineering roadmaps or priorities?
- What architectural decisions and use cases should be centrally stored as inputs into sizing, scoring, and milestone planning?
4. **Shift ownership so ProdSecEng can effectively maintain it**
- Minimum level of understanding to commit to inventory
- Meets the minimum acceptance bar defined by ProdSecEng's [best practices for automation](https://gitlab.com/gitlab-com/gl-security/product-security/product-security-engineering/product-security-engineering-team/-/issues/366) (Good/Better/Best model)
**Reference examples:**
- [Proposal: Query advisory information via GraphQL](https://gitlab.com/gitlab-org/gitlab/-/issues/503307) — example of a well-documented proposal with clear use cases and product fit
- [ADR-0006: Multi-source Advisory Correlation](https://gitlab.com/gitlab-com/gl-security/product-security/vulnerability-management/vulnerability-management-internal/vulnmapper-product-roadmap/-/blob/main/adr/0006-multi-source-advisory-correlation.md?ref_type=heads) — example of how an internal tool was documented with clear use cases and product fit analysis
## Stakeholders
| **Stakeholder** | **Team** | **Reason** | **RACI** |
|-----------------|----------|------------|----------|
| @erica-anderson | ProdSecEng (Manager) | DRI for epic definition, stakeholder engagement, status reporting | Responsible & Accountable |
| @ashmckenzie | ProdSecEng | IC — process design, drafting intake artifacts, VulnMapper subject matter | Responsible |
| @nmalcolm | ProdSecEng | IC — owns intake review work in tooling inventory ([#376](https://gitlab.com/gitlab-com/gl-security/product-security/product-security-engineering/product-security-engineering-team/-/issues/376), [#377](https://gitlab.com/gitlab-com/gl-security/product-security/product-security-engineering/product-security-engineering-team/-/issues/377)); alignment needed to avoid duplication | Consulted |
| @jhebden | Vulnerability Management | VulnMapper originator; first "customer" of the intake process; input on what a good handover looks like | Consulted |
| @estrike | Security Capabilities Engineering (Manager) | Goal alignment, unblocking, strategic direction for Security Interlock | Informed |
| TBD | TBD - Product (Sec Section / Security Risk Mgmt)? | Product fit validation; alignment with Product roadmap for co-create phase | Consulted |
| Product Security Leadership | Product Security | Informed on process changes that affect how ProdSec teams engage with ProdSecEng | Informed |
## Known Dependencies (and DRI for those)
<table>
<tr>
<th>
**Dependency**
</th>
<th>
**DRI**
</th>
</tr>
<tr>
<td>
[ProdSecEng Tooling Inventory Review](https://gitlab.com/groups/gitlab-com/gl-security/product-security/product-security-engineering/-/work_items/52):
* [#366](https://gitlab.com/gitlab-com/gl-security/product-security/product-security-engineering/product-security-engineering-team/-/issues/366) which defines the minimum acceptance bar for incoming tools
* [#376](https://gitlab.com/gitlab-com/gl-security/product-security/product-security-engineering/product-security-engineering-team/-/issues/376) (Review & update intake process - before/during build) and [#377](https://gitlab.com/gitlab-com/gl-security/product-security/product-security-engineering/product-security-engineering-team/-/issues/377) (Propose intake process for ownership transfers - after build) Complementary work reviewing existing intake content; outputs should be aligned with this epic
</td>
<td>
@nmalcolm
</td>
</tr>
<tr>
<td>
Existing intake templates ([product_security_requirement](https://gitlab.com/gitlab-com/gl-security/product-security/product-security-engineering/product-security-engineering-team/-/blob/main/.gitlab/issue_templates/product_security_requirement.md), [automation_request](https://gitlab.com/gitlab-com/gl-security/product-security/product-security-engineering/product-security-engineering-team/-/blob/main/.gitlab/issue_templates/automation_request.md)) - must be reviewed and updated as part of this work
</td>
<td>
@ashmckenzie
</td>
</tr>
<tr>
<td>
[Internal Co-Create handbook page](https://handbook.gitlab.com/handbook/security/product-security/security-platforms-architecture/security-interlock/prodsec-to-product-workflow/internal-co-create/) - intake process must clearly hand off to co-create
</td>
<td>
@erica-anderson
</td>
</tr>
</table>
## Known Risks and mitigation
| **Risk** | **Mitigation** |
|----------|----------------|
| Process designed in isolation without input from the teams who will use it (VulnMgmt, AppSec, PSIRT) | VulnMapper handover is the first "customer" of this process; validate with VulnMgmt team before finalising. Async feedback from AppSec/PSIRT as secondary validation. |
| Overlap or conflict with @nmalcolm's intake review work in [&52](https://gitlab.com/groups/gitlab-com/gl-security/product-security/product-security-engineering/-/work_items/52) ([#376](https://gitlab.com/gitlab-com/gl-security/product-security/product-security-engineering/product-security-engineering-team/-/issues/376), [#377](https://gitlab.com/gitlab-com/gl-security/product-security/product-security-engineering/product-security-engineering-team/-/issues/377)) | Explicit alignment checkpoint: this epic defines the forward-looking process; [#376](https://gitlab.com/gitlab-com/gl-security/product-security/product-security-engineering/product-security-engineering-team/-/issues/376)/[#377](https://gitlab.com/gitlab-com/gl-security/product-security/product-security-engineering/product-security-engineering-team/-/issues/377) review existing content for fitness. Outputs must converge. |
| Intake process becomes too heavyweight or bureaucratic, discouraging teams from engaging ProdSecEng early | Design a tiered approach: lightweight for small automations (automation_request template), full intake for significant tooling/ownership transfers. Validate with stakeholders that the process is proportionate. |
| Co-create process is undefined, so intake has no clear "next step" to hand off to | Intake epic explicitly documents the handoff point and what artefacts are passed to co-create. Co-create epic will be scoped as a follow-on. |
| Best practices model ([#366](https://gitlab.com/gitlab-com/gl-security/product-security/product-security-engineering/product-security-engineering-team/-/issues/366)) not yet finalised - intake acceptance criteria may lack a defined quality bar | Track [#366](https://gitlab.com/gitlab-com/gl-security/product-security/product-security-engineering/product-security-engineering-team/-/issues/366) progress; draft intake with placeholder for minimum acceptance bar and update once Good/Better/Best is published. |
## Success Criteria and Metrics
| **Goal** | **Metric** |
|----------|------------|
| A documented, published intake process that ProdSec teams can follow to engage ProdSecEng | Intake process published in handbook; discoverable from ProdSecEng charter page and Security Interlock pages |
| Intake process covers both net-new requests AND ownership transfers of existing tools | Process explicitly addresses both scenarios with appropriate templates/checklists for each |
| VulnMapper handover successfully uses the intake process as first validation | VulnMapper intake completed using the new process at least 1 time; retrospective captured within 2 weeks after the process is completed. |
| Intake produces structured artefacts that feed into co-create and maintenance workflows | Each completed intake produces: (1) use case documentation, (2) product fit assessment, (3) maintainability assessment (SLO/RTO/criticality), (4) architectural decisions record |
| Stakeholders can self-serve and understand how to engage ProdSecEng | At least 2 ProdSec teams (beyond VulnMgmt) are aware of and can locate the intake process; validated via async survey or Slack confirmation |
| Existing intake templates are reviewed and updated | product_security_requirement and automation_request templates updated to reflect new process; MRs merged |
## Return on Investment (ROI)
**Why this work needs to be done:**
ProdSecEng was established to shepherd internal security tooling into the GitLab product. When the team was formed, multiple tools were urgently transferred without a structured process - leading to unclear ownership, inconsistent documentation, and difficulty prioritising maintenance vs. product integration. The [Tooling Inventory Review](https://gitlab.com/groups/gitlab-com/gl-security/product-security/product-security-engineering/-/work_items/52) is addressing the backlog; this epic ensures the _forward-looking process_ prevents the same problems from recurring.
**How GitLab benefits:**
- **Reduces risk:** A clear intake process ensures tools are evaluated for criticality, maintainability, and product fit _before_ ProdSecEng commits to ownership — preventing unplanned maintenance burden and reducing the risk of critical tools being under-supported.
- **Accelerates product integration:** By capturing use cases, architectural decisions, and product fit analysis at intake, we create the inputs that Product and Engineering need for sizing, scoring, and milestone planning — making the co-create process faster and more intentional.
- **Furthers Security Org goals:** Directly supports the FY27 Security priority to "automate tasks with agents" and shift from fundamentals to more automated, performant security. A structured intake ensures automation efforts are aligned to critical business priorities.
- **Enables dogfooding:** By formalising how ProdSec's real-world needs become product features, we strengthen GitLab's position as "customer zero" for security capabilities — ensuring our product serves the needs of security teams like ours and our customers'.
- **Scales ProdSecEng:** Without a process, every new tool request is ad-hoc. A repeatable intake process allows the team to evaluate and prioritise work consistently, even as demand grows.
**References:**
* Previous epics: [FY26Q4 - Initial VulnMapper Product Transition Roadmap](https://gitlab.com/groups/gitlab-com/gl-security/product-security/vulnerability-management/vulnerability-management-internal/-/work_items/55)
* Primary project: [VulnMapper ADRs & Proposals Roadmap Project](https://gitlab.com/gitlab-com/gl-security/product-security/vulnerability-management/vulnerability-management-internal/vulnmapper-product-roadmap)
* Related current epics:
* [Initial Contribution of VulnMapper Capabilities to Product](https://gitlab.com/groups/gitlab-com/gl-security/product-security/-/work_items/57) - first co-create output; will need the process defined after intake
* [ProdSecEng Tooling and Automation Inventory Review](https://gitlab.com/groups/gitlab-com/gl-security/product-security/product-security-engineering/-/work_items/52) - complementary work reviewing existing tooling and intake content
* Handbook references:
* [ProdSecEng Mission](https://handbook.gitlab.com/handbook/security/product-security/security-platforms-architecture/product-security-engineering/)
* [Security Interlock](https://handbook.gitlab.com/handbook/security/product-security/security-platforms-architecture/security-interlock/)
* [Internal Co-Create Process (current draft)](https://handbook.gitlab.com/handbook/security/product-security/security-platforms-architecture/security-interlock/prodsec-to-product-workflow/internal-co-create/)
* [Product Security Requirements](https://handbook.gitlab.com/handbook/security/product-security/security-platforms-architecture/product-security-engineering/product-security-requirements/)
epic