Apply for sandbox stage with OpenBao

[cipherboy]

This was in conversation with @ware and others on the Security Tooling WG, see 2025-03-07 meeting notes.

OpenBao is a secrets manager, forked from Vault under the LF Edge sub-foundation. We're looking to better align with our contributor base, which largely is not Edge-aligned and instead more broadly security focused, though we definitely wish to continue our partnerships with other LF Edge projects and across the LF as a whole.

This would thus be a lateral transfer within the LF to a different foundation, hopefully simplifying IP and license review process. We currently receive no budget from LF Edge.

Starting this move was approved by the OpenBao TSC.

fyi @gkunz

[ware]

Just to verify, the Security Tooling WG is happy to accept OpenBao as a project. I think this will be a great addition to the OpenSSF and our working group.

[lehors]

Could you please elaborate on why you want to move this project to OpenSSF and what the expected benefits for the project and the community at large are?

[cipherboy]

@lehors Happy to!

1. Choice of existing foundation was decided by the initial startup TSC as it was the local community (3 founding members were LF Edge).
2. LF Edge has foundation membership requirements this project cannot meet there, that OpenSSF does not have and would be easier to meet.
3. LF Edge isn't really aligned with the project or its mission and community members have commented on that. From an community awareness PoV, it is clear OpenSSF much better aligns with our target audience and mission for our project and has community member mindshare that LF Edge does not.
4. OpenBao already integrates with Sigstore in OpenSSF (and thus transitively to SLSA when Sigstore is used for signing provenance), could likely integrate with policy documents like OSPS Baseline and OpenSSF Scorecard, and benefits other supply chain security discussions.
5. From a community PoV, besides the project continuing as a LF project, it aligns with community/project expectations and gives us room to grow in beneficial ways that will grow project awareness.

Context on above

1. The initial startup TSC consisted of IBM (from its involvement in LF Edge's OpenHorizon which used HashiCorp Vault pre-BUSL and thus needed a replacement), IOTech (from its involvement in LF Edge's EdgeX Foundry which was in a similar position), Zededa (also LF Edge member, not using Vault), Viaccess-Orca (not an LF or LF Edge member) or Wallix (also not a LF Edge member).
   • Most of these groups were already LF Edge aligned, but much of the development work has happened by non-LF Edge companies. IBM bought HashiCorp and had to step away for a year while that process sorted out. Zededa has taken on other engagements and got too busy to continue on the TSC. Both Zededa and IOTech have offered wonderful advice and leadership to the early community and IOTech is a great consumer of the project, but don't substantially contribute to development. Viaccess-Orca briefly acquired an entry-level LF Edge membership but opted not to renew this year.
   • In short, the current TSC is comprised of 3 non-LF Edge members (my employer, GitLab; Wallix; Viaccess-Orca, which is not renewing its LF Edge membership is my understanding), one entry LF Edge member (IOTech), and IBM (which had abstained from all project participation due to said acquisition).
   • Of these, GitLab and IBM are both existing OpenSSF members. From a community PoV, we've gotten contributions from G-Research (not LF Edge, but also OpenSSF member) and Wallix/V-O are more likely OpenSSF interested than LF Edge interested and have contributed technically to the project.
2. Move now driven by LF Edge policy changes. Stage 1 projects need to meet two criteria, which IBM was formerly helping us with. In late January, they instituted a new policy giving projects 60 days to meet compliance or be graduated; we were at risk of this.
   • 1. LF Edge requires all projects to have two TAC sponsors. IBM had previously pulled out of sponsorship because of their acquisition. The other sponsorship was from IOTech's stage 3 project (EdgeX Foundry), which was also at risk as it was short sponsors.
     • OpenBao, thanks to introductions from the TAC chair and EdgeX Foundry finding two replacement TAC sponsors, recently met this requirement again.
   • 2. LF Edge requires all projects have a sponsoring premier seat member.
     • Outside of IBM, none of our TSC or community members have an interest in this.
     • While not formally given notice of the 60-day meet-or-graduate requirements, it is understood between myself and the current LF Edge TAC chair (Joe Pearson, IBM) as being a gap this project is short.
     • This is a rather difficult conversation to have; of the $50k-$70k (depending on if a company is a LF Member), ~$0 goes directly to our project. Especially for companies in Europe who aren't existing LF members (including many of our contributors) and who aren't more broadly aligned with LF Edge (including GitLab, Wallix, Viaccess Orca on the TSC and others in the community), this is nearly a full time developer they could employ to work on the project direct.
     • If OpenSSF were to add such a project requirement in the future, given better alignment with contributing companies, it seems much more likely we could meet it here than under LF Edge.
3. LF Edge isn't well known. I've been FOSDEM and SOOCon '25 recently; most people weren't aware of LF Edge and many asked why not OpenSSF / CNCF. Anecdotal, but of I think 4 people I talked with who knew of LF Edge, two were current/former LF employees and a third worked in the edge space. Most people interested in a Vault fork are not looking under LF Edge.
   • We've also had a few people ask this question on our community call as well.
   • We are a general purpose secrets manager and not just focused on the Edge space.
4. Our integrations really span the entire LF.
   • We also consume OpenSSF projects like Scorecard, are starting baseline requirements, and generate SBOMs.
   • Under the CNCF, we integrate with Notary, SOPS, bank-vaults, cert-manager, external secrets operator, and likely others I'm not aware of.
   • Under the LF Edge, we integrate with OpenHorizon and EdgeX Foundry.
5. Besides integrating with several policy actions as an example of a secrets manager if a platform-native one isn't available, many other projects within OpenSSF need signing keys or other types of secrets and so OpenBao would be a native, foundation-local integration.

Let me know if you need more details about anything.

[steiza]

Thanks for filling out this application! I believe OpenBao aligns with the mission of the OpenSSF and meets the requirements for a sandbox project.

[gkunz]

Thank you, @cipherboy, for the detailed additional context and information. I think that OpenBao fits into the scope of the OpenSSF; and looking at the documented processes and procedures, it meets the graduation requirements.

[lehors]

Thanks for the additional background. SGTM!

[marcelamelara]

Thank you @cipherboy for sending this application! I appreciate the detailed context for this transition, and I agree that OpenBao is a good fit for OpenSSF. As discussed during the 4/1 TAC call, I left a note about the software license review.

[marcelamelara]

I noticed that OpenBao is currently licensed under an MPL 2 license. Since OpenSSF typically prefers Apache 2.0 or MIT licenses for software projects, I'm think there may be an additional review of the license step by the Governing Board.

[cipherboy]

Thanks @marcelamelara and @lehors for the discussion on the call! I've pushed an update to the IP licensing requirements linking to our charter and the OpenSSF TAC charter.

I'm told the more unusual thing was that our core documentation was under MPLv2, but this was an artifact of upstream's documentation license.

[bobcallaway]

@cipherboy what is the LF Edge TAC's opinion of this proposal?

[cipherboy]

Hello @bobcallaway,

@cipherboy what is the LF Edge TAC's opinion of this proposal?

I have brought up the move on a past meeting but not officially sought a statement from them. They are aware of our inability to meet the stage 1 foundation membership requirements and Kendall Perez (LF Liaison) has been updated on votes and status of the proposal from the community side.

If you'd like, I'm happy to attend the next LF Edge TAC meeting and see if someone would be willing to give an official statement?

[joewxboy]

@cipherboy what is the LF Edge TAC's opinion of this proposal?

@bobcallaway This is Joe Pearson, Chair of the LF Edge TAC. While we don't encourage projects to leave LF Edge, and we do all that we can to support our projects, Alex and the project TSC have made a compelling case for the desired transition to OpenSSF. We have no objections and hope that OpenSSF proves to be a better fit. We briefly mentioned and discussed the desired move in a previous TAC meeting, and no red flags were raised. Several LF Edge projects plan to continue collaborating with OpenBao going forward, and the TAC is working to keep OpenBao in good standing as a project until such time as a transfer would be completed.

[bobcallaway]

@cipherboy what is the LF Edge TAC's opinion of this proposal?

@bobcallaway This is Joe Pearson, Chair of the LF Edge TAC. While we don't encourage projects to leave LF Edge, and we do all that we can to support our projects, Alex and the project TSC have made a compelling case for the desired transition to OpenSSF. We have no objections and hope that OpenSSF proves to be a better fit. We briefly mentioned and discussed the desired move in a previous TAC meeting, and no red flags were raised. Several LF Edge projects plan to continue collaborating with OpenBao going forward, and the TAC is working to keep OpenBao in good standing as a project until such time as a transfer would be completed.

Thanks for the confirmation!

[ware]

Are there any next steps needed by OpenBao?

[marcelamelara]

I approve admitting OpenBao as a sandbox project, pending the IP/license review.

[marcelamelara]

Are there any next steps needed by OpenBao?

@Naomi-Wash I believe we need an IP/license review for this project since it's a transfer to OpenSSF?

[gkunz]

Adding to Marcela's comment, an approval by the Governing Board of the MPL-2.0 should be scheduled. The next GB meeting is scheduled for May 15 (@Naomi-Wash).

[steiza]

There's always a bit of a chicken-and-egg problem with process like this - what order should the steps be completed in?

I think it makes sense for the TAC to finish the technical review, and if enough TAC members approve then it goes on to staff (and possibly the Governing Board) for things like IP / license review.

By our decision process doc adopting a new TI requires 7 approvals and we're at 6 (if you count @marcelamelara's comment approving pending IP/license review).

But we haven't yet heard from @camaleon2016 @mlieberman85 or @justaugustus - I think we need one of them to review and approve for this to move forward.

[Naomi-Wash]

I agree with @steiza's suggestion. Let the TAC fully approve, then we'll bring it to the board to approve it since they have a license not noted in the Charter.

[cipherboy]

For the benefit of anyone not yet voting and who may not have attended the TAC call the other day, I'll just reiterate I'm happy to chat on GitHub, on OpenSSF Slack, or via video call if anyone has questions about the project or the move.

[justaugustus]

LGTM for Sandbox inclusion, pending the license review/exception!

[camaleon2016]

If all good with license, etc. LGTM

[camaleon2016]

If all good with license, etc. LGTM

[marcelamelara]

Let the TAC fully approve, then we'll bring it to the board to approve it since they have a license not noted in the Charter.

I'm comfortable approving, given this.

[steiza]

@Naomi-Wash we now have the votes! I think we're ready to proceed with staff review.

In the meantime, we'll leave this pull request open and land it once OpenBao's acceptance is official?