The following page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features or functionality remain at the sole discretion of GitLab Inc.
| Section | Sec |
| Content Last Reviewed | 2023-11-14 |
| Content Last Updated | 2023-11-14 |
This prioritized list contains initiatives where help from a Principal Engineer would be the most beneficial for the Sec section. The criteria for inclusion in this list is in balancing high priority to the business and level of technical effort that is not likely to succeed without involvement by a Principal Engineer. Principal engineers are also encouraged to identify and propose projects they believe would have a significant impact on their section and the company.
| Priority / Name / Size / Group | Comments |
|---|---|
Priority: 1Pre-receive secret detection Estimated Size: LSecure:Secret Detection |
This paves the way for us to do other types of real-time scanning in the IDE. There are still a number of architectural decisions that we need to make that will impact implementation of other Static Analysis scanning types. |
Priority: 2Write guidance on meeting SLSA (Supply-chain Levels for Software Artifacts) L3 requirements with GitLab Estimated Size: SGovern - SSCS Working Group |
This item can be timeboxed to 3 days or less. This item also has some time urgency as we have a wave of customers asking about SLSA compliance and we really need a good response. Essentially we just need a Principal Engineer to review the document, review the SLSA requirements, and help us work on some CI examples showing how we can achieve SLSA L3 compliance within GitLab. |
Priority: 3Real-time scanning in the IDE Estimated Size: LSecure:Static analysis and there might be a part for Threat Insights in the display of findings |
We've done some research into this idea however the solution that we land on for pre-receive secret detection will greatly inform it. To get get ramped up on the project, it is advised to: 1. Review the feedback summary in the technical discovery issue. 2. Review the decisions made, open questions, and next steps in the technical discovery issue. 3. Read through/watch the technical discovery review sync (agenda, recording) 4. Watch LSP integration brown bag (recording - shows secret detection POC working in the IDE) |
Priority: 4Threat Insights Database Optimization Estimated Size: LGovern - Threat Insights but will indirectly benefit all of Secure |
Database performance is a blocker for our ability to do advanced filtering on the Vulnerability Report. This includes several filters that the Secure stage needs (location and identifier). Also, we have a very large and growing number of customers requesting the ability to track vulnerabilities for all branches (which will also require adding an ability to filter by branch). To support both of these initiatives, we likely will need to add partitioning to the table and possibly also combine the Vulnerabilities and Vulnerabilities::Finding tables. These are large and very complex projects that are being worked on by the Threat Insights team but that might benefit from the help of a Principal Engineer. A spike to Evaluate decomposing Secure related tables to a separate Postgres DB would be a good starting point. |
Priority: 5Risk-based vulnerability prioritization Estimated Size: XLSpans across Secure and Govern |
Some initial research has been done in this area, but overall we don't yet have a good overarching vision for how this will work. Ideally we would have the full list of items in the "Future product roadmap needs" section of the description in this research spike. If we have all that data available, we would be able to much more To implement this, we will likely need to take the following steps: 1. Add more data into our External Database (Composition Analysis) 2. Ingest that data as additional fields into the GitLab PostGres database (Composition Analysis) 3. Display those fields in the Vulnerability Report (Threat Insights) 4. Add filters to the Vulnerability Report (Threat Insights) 5. Add filters to Security Policies (Security Policies) 6. Create a new area in the UI where a risk-based priority score can be calculated (Ownership unclear) 7. Surface the new priority score in the Vulnerability Report and in the Policy Editor (TI + SP teams respectively) The complexity of those steps and the span across multiple groups has limited our ability to make progress up to this point. Ideally a Principal Engineer would help unblock that work and facilitate progress toward this feature. |
Priority: 6Vulnerability alerting and notifications Estimated Size: LGovern but will indirectly benefit all of Secure |
Ownership for this item is unclear between Threat Insights and Security Policies. Now that we have Continuous Vulnerability Scanning in place, we really need a good vulnerability alerting solution. Potentially this could be configured as a new type of security policy with customizable actions on where and when to send notifications about new vulnerabilities. A Principal Engineer could help by proposing a path forward and helping to identify some small/iterative quick wins to unblock customers. |
Priority: 7Organization-level security management Estimated Size: MAll of Govern |
Nearly all self managed customers need the ability to manage security across all of their top-level groups. We have been waiting on the Organization Object to become available; however, delivery has been repeatedly delayed as the new Organization object is intertwined with the GitLab Cells work to isolate database tables for scalability purposes. In a internal call on November 15 (See the private notes doc and recording) we explored the option of contributing just enough to the Organization Object so it could show up in the UI and so we could add our security features there. The summary takeaway from that call is that the Organization object is so intertwined with the isolation work that this is not an option. Since the top priority here is to make the Vulnerability Report and Dependency List available for self managed customers across all their top-level groups, we may want to add those pages to the Explore section of the product as an intermediate solution. Especially considering that the timelines for the Organization object are long as we are already very strong customer demand for this feature. In theory this will be a relatively smaller task with a very big impact as we should be able to reuse the frontend that we already have at the Group level. |
*This page may contain information related to upcoming products, features and functionality.
It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes.
Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.*