| Property | Value |
|---|---|
| Date Created | 2023-03-23 |
| End Date | TBD |
| Slack | #wg_software_supply_chain_security (only accessible from within the company) |
| Google Doc | Software Supply Chain Security Working Group Agenda (only accessible from within the company) |
| Issue Label | WorkingGroup::SSCS |
Software Supply Chain Security (SSCS) is a key area where GitLab needs to excel, not only for the benefit of the company but for the benefit and security of our users. SSCS features and capabilities span across nearly all of the stages and groups in GitLab. The primary focus of this working group will be to work on building signing and verification into GitLab and will involve contributions in areas the following groups maintain: Create::Source Code, Verify::Pipeline Execution, Verify::Runner, Package::Package Registry, and Package::Container Registry. There may be some minor code contributions into other team areas as well. The other SSCS feature work at GitLab that is unrelated to signing and verification is outside the scope of this Working Group (but is still being considered or worked on in other areas in GitLab). This direction page describes the broad, long-term future vision for SSCS across the entire SDLC.
Signing and verification are traditionally difficult tasks. To securely sign a build artifact, container image, or package, users need to first securely store a private signing key. This key needs to be regularly rotated, and the signing tool needs a way to securely access the signing key. The combination of all of these requirements result in a high barrier to entry for users to sign their builds. As a result, many private projects and small open source projects do not publish signed build artifacts.
At a high level, this working group plans on making it possible for signing to happen automatically and by default anytime GitLab is used to build an artifact, container image, or package. By taking this complexity away from the end user and enabling it by default, GitLab intends to help lower this barrier to entry and make signing an industry-wide on-by-default standard.
Some of these links may provide useful background for the working group:
This working group is anticipated to require a total of 12-15 months to complete. This timeline is only an estimate and the working group will formally conclude once the exit criteria is met. This may result in either a longer or shorter timeline than the estimate of 12-15 months. The group will hold a review at the end of each quarter.
Unlike other working groups, this effort is expected to take priority over other work. Core members from the Govern stage in the working group should expect to contribute approximately 80% of their time towards this project. Core members from other stages are volunteers and the percentage of their time may be much smaller. This commitment should be discussed and agreed upon with the individual's manager, and product counterpart where applicable, prior to joining the working group. Team members can also join as regular working group contributors.
We intend to re-evaluate the staffing needs of this working group on a quarterly basis. The product and engineering DRIs for the working group may increase, decrease, or swap out team members each quarter based on the overall interests of the team and the needs of the working group. The following dates are planned for re-evaluating the team structure:
Because software supply chain security impacts areas across GitLab, this working group will operate similar to a community contributor by adding functionality into other stages and groups in GitLab. As that functionality is incrementally completed, it will be handed off to the appropriate stage/group for ongoing maintenance.
The exit criteria for this working group is the completion of the following four criteria:
Epics to track the above work are still being created, along with the necessary requirements and designs. Please consider the items that do have links as a work-in-progress. Epics to track items that do not have links will be created and added in the future.
A prioritized list of work will be tracked here after an engineering DRI has been identified.
| Priority | Epic | Status |
|---|---|---|
| 1 | Research spike into the next steps to support Native Signing of Build Artifacts | Research in progress |
| 2 | User Experience for Signed Container Registry Images | Backend development in progress; frontend development not currently resourced |
| 3 | Upstream Cosign changes to use a GitLab provider | Development in progress |
| 4 | User Experience for Signed Build Artifacts | Designs nearly complete; almost ready for refinement |
| 5 | Support for GitSign | Ready for refinement |
| 6+ | This is a WIP and we are still working to add a list of prioritized Epics to deliver on the rest of the exit criteria for the group. | In progress |
To be added once the project is complete
| Working Group Role | Person | Title |
|---|---|---|
| Executive Sponsor | Hillary Benson | Senior Director, Product Management |
| Engineering DRI | Brian Williams | Sr. Backend Engineer, Govern |
| Product DRI | Sam White | Group Manager, Product - Govern |
| Member | Nathan Rosandich | Engineering Manager, Govern |
| Member | Ali Ladhani | Backend Engineer, Govern |
| Member | Aaron Huntsman | Sr. Backend Engineer, Govern |
| Member | Daniel Tian | Sr. Frontend Engineer, Govern |
| Member | Julian Thome | Staff, Vulnerability Research |
| Member | Kris K | Software Engineer, Google |
| Advisor | David Fernandez | Staff Backend Engineer, Package Registry |
| Advisor | Joao Pereira | Staff Backend Engineer, Container Registry |
| Advisor | Vasilii Iakliushin | Senior Backend Engineer, Source Code |
| Advisor | Dominic Couture | Staff Security Engineer, Application Security |