ossf · cipherboy · Jul 28, 2026
@@ -102,10 +102,32 @@ Chair: Jonathan Metzman
 
 The OSS Fuzzing SIG (Fuzzing Collaboration) continues its work of supporting open source developers with their fuzzing needs.  Participation in the group has been spotty.  Jeff Diecks has been working with them to determine if it might be best for the project to find a better umbrella to be under where they might get more participation.
 
+## OpenBao
+
+**Lead**: Alexander Scheel
+
+[OpenBao](https://openbao.org/) securely manages static and dynamic secrets, certificates, and keys allowing greater auditing for compliance with best practices. This is important because many other solutions don't allow for centralized risk accounting and inventory.
+
+The OpenBao community continues to work towards greater tenant separation and solution scalabillity.
+
+ - Promotions
+   - Adfinis was recently promoted to voting member of the OpenBao TSC after Viaccess-Orca stepped down in May.
+   - Andrii F. (Adfinis) and Jonas K. (Reply) were recently promoted to voting members of the OpenBao Development WG.
+   - Geoffrey W. was recently promoted as a core committer.
+ - OpenBao v2.3.1 was released last month with support for namespaces (multi-tenancy), KMIP auto-unseal, safe rotation in the SSH engine, and Common Expression Language (CEL) for PKI issuance policies and JWT authorization policies (and more).
+ - Working Group Updates:
+   - The _Supply Chain Security WG_ started strong but has had a little weaker attendance in past weeks with summer holidays. The initial focus of this WG are the OSPS baseline requirements, collecting evidence for completion at https://openbao.org/docs/policies/osps-baseline/, which had broad contributions from many community members including Adfinis, Reply, and our OpenBao mentee, Fatima. This working group will be important in the project's OpenSSF maturity as it will focus on the OpenSSF best practices badge program next.
+   - The _UI WG_ just started last week (July 15th) with its first kick-off meeting. Initial membership consists of Adfinis and Alex (community participation). The WG opted to start a greenfield implementation using React in the https://github.com/openbao/dough repository which was created for this purpose.
+   - The _Namespaces WG_ has seen good progress and meets every other week (last on July 23rd). Recently finished work is the successful landing of Namespaces in v2.3.1 GA release last month (with a few last-minute fixes and a recent race condition fix in the deletion logic after the last release). This WG is currently focusing on per-namespace seals with a RFC in https://github.com/openbao/openbao/pull/1357 and initial changes on the [`namespaces-seal` branch](https://github.com/openbao/openbao/compare/main...namespaces-seal), courtesy of Reply. This was impacted by the recent CVE as rekeying of the root seal information provides a design basis for rekeying of namespace seal mechanisms. In addition, designs discussions have started for allowing federated namespaces and supporting transferring namespaces across different OpenBao instances, with initial designs in https://github.com/openbao/openbao/issues/1568 and https://github.com/openbao/openbao/issues/1569, which is a requirement from GitLab.
+   - The _Horizontal Scalability WG_ has seen good progress and meets every other week (last on July 16th). We've proposed two main RFCs (https://github.com/openbao/openbao/pull/1553 + https://github.com/openbao/openbao/issues/1550) towards our first goal of read-enabled horizontal scalability. Initial development work is happening in the [`read-replication` branch](https://github.com/openbao/openbao/compare/main...read-replication), with contributions and proof of concepts from Adfinis and our OpenBao mentee, Fatima. GitLab is also participating with an interest in PostgreSQL-backed replication, though the invalidation mechanism may be more difficult to achieve here.
+   - After the successful introduction of PKCS#11-based unsealing in OpenBao 2.2.0 GA, the _PKCS#11/KMS WG_ was re-formed in June. With the introduction of External Key support ([openbao/openbao#1320](https://github.com/openbao/openbao/pull/1320)), the WG proposed an RFC that allows secret engines to interact with various KMS and HSM backends for key operations. As part of this effort, a reference implementation of the external keys RFC for PKCS#11 was developed, which also included a major refactor of the existing PKCS#11 code ([openbao/go-kms-wrapping#33](https://github.com/openbao/go-kms-wrapping/pull/33)). This foundational work enables a range of upcoming features, such as PKCS#11-backed signing in the PKI engine. The working group, supported by contributors from Reply (on behalf of SAP), Securosys, and Wallix, includes organizations not only requesting enhanced KMS/HSM support but also actively contributing to its design and implementation.
+   - The _FIPS WG_ has not yet met. There was initial interest from three parties (Reply, Adfinis, and GitLab) but additional requirements needed to be collected before having an initial upstream meeting.
+ - Community continues to see a bit of growth with new contributors, meeting attendees, and large feature development by multiple parties.
+
 ## Questions/Issues for the TAC
 
 No general requests at this time
 
 ## Additional Information
 
-We have been approached by the lead maintainer of the [cve-bin-tool](https://github.com/intel/cve-bin-tool) project.  They are looking to have Intel donate cve-bin-tool to OpenSSF.  Being a Software Composition Analysis (SCA) solution for both binaries and SBOMs, it is a natural fit for OpenSSF which does not currently have an SCA solution.
+We have been approached by the lead maintainer of the [cve-bin-tool](https://github.com/intel/cve-bin-tool) project.  They are looking to have Intel donate cve-bin-tool to OpenSSF.  Being a Software Composition Analysis (SCA) solution for both binaries and SBOMs, it is a natural fit for OpenSSF which does not currently have an SCA solution.