tac
tac copied to clipboard
ossf
[Technical Initiative Funding Request]: Sigstore Transparency Log Monitoring
Technical Initiative
Sigstore
Lifecycle Phase
Graduated
Funding amount
$96,000 USD
Problem Statement
Sigstore allows signers to audit how they sign artifacts such as binaries, containers and attestations, through inclusion of signatures in a public transparency log, an append-only and tamper-evident data structure, called Rekor. Rekor contains signatures and certificates for all publicly signed artifacts using Sigstore clients. These certificates include identities, such as emails or CI workload identities. A signer can monitor the log, periodically querying the log for new entries, to find entries that contain their identity and take steps to secure their identity if it has been unexpectedly found.
The ability to monitor the log is the log's primary benefit over traditional signing schemes. An ecosystem that uses transparency logs must provide tooling to simplify and encourage monitoring. A signature present in an unaudited log adds little value, rather the value comes from the discoverability of the signature by its creator.
Sigstore also operates a certificate transparency log for publishing code signing certificates from its certificate authority, Fulcio. We are unaware of any monitors that are monitoring this log and correlating entries between Fulcio and Rekor.
Who does this affect?
This problem impacts all Sigstore signers, and more broadly the entire Sigstore ecosystem and OSS registries that integrate with Sigstore as the integrity of its signers leads to secure artifact verification. The solution is primarily for those who generate public Sigstore signatures.
Have there been previous attempts to resolve the problem?
sigstore/rekor-monitor is the current solution, a tool for monitoring identities and keys that can also be run as a GitHub Action, albeit it is not productionized and its maintainers have not been able to dedicate time to further develop it.
Why should it be tackled now and by this TI?
Sigstore is being widely adopted without a fully fleshed out log monitoring system, leaving a gap in the ecosystem.
Give an idea of what is required to make the funding initiative happen
We will complete rekor-monitor with all features necessary to run the monitor in a production environment. This work will include:
- A thorough review of the codebase to identify areas for improvement;
- Completion of all open issues on rekor-monitor;
- A major 1.0 release for rekor-monitor.
What is going to be needed to deliver this funding initiative?
Nothing additional is needed besides funding.
Are there tools or tech that still need to be produced to facilitate the funding initiative?
No, engineering work will be novel.
This work will unblock future improvements to the Sigstore ecosystem, and to Sigstore’s monitoring story in particular. For example, this work will enable a website akin to gopherwatch.org, which will be able to provide Sigstore monitoring as a public service.
Give a summary of the requirements that contextualize the costs of the funding initiative
For 320 hours (2 months FTE) of work, this work will productionize rekor-monitor. In particular, the following high-level goals will be achieved through the funding initiative:
- A thorough review through the existing codebase, with any necessary refactoring for maintainability and testing, and identifying areas for improvement
- Completion of all open and newly identified issues in rekor-monitor
- A 1.0 major release with a stable API
Further detail on each high-level goal, with effort estimates:
- Review and modernization: 4 weeks FTE:
- Evaluating the current monitor for resilience, e.g. ensuring that less-common Sigstore log entry types or malformed log entries do not pose an availability or monitoring fidelity risk, and fixing any cases that do occur;
- Improvements to the monitor’s log state and entry tracking, e.g. reducing the monitor’s checkpoint state to only the latest observed checkpoint, and replacing the current output file with a database suitable for independent/asynchronous consumption of monitoring results (such as by a future gopherwatch-style website);
- Completion of open issues: 3 weeks FTE:
- Support for certificate chaining per #378, to reduce the likelihood of false-positive log entry alerts;
- Verifying the log’s checkpoint using a bundled or retrieved TUF root instead of the log’s own public key, per #51;
- Adding alerts for unexpected shard or STH states, per #8 and #58.
- As time allows or if the above issues are completed by other community members or maintainers, addressing other open issues.
- Preparation of a 1.0 release: 1 week FTE:
- Full and repeatable end-to-end testing of the monitor’s lifecycle, per #521;
- Preparation of public- and developer-facing announcements, including on the OpenSSF, Sigstore, and Trail of Bits blogs.
Who is responsible for doing the work of this funding initiative?
William Woodruff (@woodruffw), Trail of Bits
Who is accountable for doing the work of this funding initiative?
Hayden Blauzvern, Google and Sigstore community chair, and William Woodruff, Trail of Bits
If the responsible or accountable parties are no longer available, what is the backup contact or plan?
The Sigstore TSC, sigstore/tsc#members
What license is this funding initiative being used under?
sigstore/rekor-monitor@main/LICENSE
Code of Conduct
- [x] I agree to follow the OpenSSF's Code of Conduct
List the major milestones by date and identify the overall timeline within which the technical initiative plans to accomplish their goals. Any payments for services, sponsorships, etc., will require LF Legal and Financial review.
By the middle of Q3'25, rekor-monitor has been reviewed and work has begun on open issues.
By the end of Q3'25, rekor-monitor has been completed and a major 1.0 release has been cut.
This assumes the work will begin at the beginning of Q3'25. If the work starts later, assume that the work will still take one total quarter.
If this is a request for funding to issue a contract, then OpenSSF will issue that contract. Please provide a Statement of Work (SOW) that we may review. Any contracting action will take 4-6 weeks to issue.
No SoW needed as work will be executed by Trail of Bits.
Do we have a list of folks who have talked about running a monitor. Have any sites like gopherwatch.org committed or at least shown interest to run a monitor?
Do we have a list of folks who have talked about running a monitor.
I think it'd be great to have a formal list! For my part: Trail of Bits would happily run a production-ready monitor.
@mlieberman85, in addition to reaching out to some of the companies that work on Sigstore, I was planning to see if anyone from the CT community that has experience operating a monitor, like CertSpotter, would be interested.
Vote created
@steiza has called for a vote on [Technical Initiative Funding Request]: Sigstore Transparency Log Monitoring (#470).
The members of the following teams have binding votes:
| Team |
|---|
| @ossf/tac |
Non-binding votes are also appreciated as a sign of support!
How to vote
You can cast your vote by reacting to this comment. The following reactions are supported:
| In favor | Against | Abstain |
|---|---|---|
| 👍 | 👎 | 👀 |
Please note that voting for multiple options is not allowed and those votes won't be counted.
The vote will be open for 14days. It will pass if at least 55% of the users with binding votes vote In favor 👍. Once it's closed, results will be published here as a new comment.
![git-vote[bot] avatar](https://avatars.githubusercontent.com/in/206179?v=4 "Published by a pub.dev verified publisher"){kind=small}
I'm voting in favor of this proposal. This is an iteration on the request we saw last cycle, where I wrote about my reasoning on https://github.com/ossf/tac/issues/445#issuecomment-2663950192.
At the time we were still working through the sequencing of technical review, identifying the exact amount, and determining contractor selection. To reiterate, at this stage we are evaluating the proposal for technical merit, and if it passes the TAC vote, then staff will work with @haydentherapper to do vendor selection and determine the exact amount of funding required.
Vote status
So far 33.33% of the users with binding vote are in favor and 0.00% are against (passing threshold: 55%).
Summary
| In favor | Against | Abstain | Not voted |
|---|---|---|---|
| 3 | 0 | 0 | 6 |
Binding votes (3)
| User | Vote | Timestamp |
|---|---|---|
| gkunz | In favor | 2025-04-24 12:28:58.0 +00:00:00 |
| steiza | In favor | 2025-04-24 14:44:11.0 +00:00:00 |
| bobcallaway | In favor | 2025-04-23 14:52:25.0 +00:00:00 |
| @justaugustus | Pending | |
| @mlieberman85 | Pending | |
| @scovetta | Pending | |
| @lehors | Pending | |
| @marcelamelara | Pending | |
| @camaleon2016 | Pending |
I'm voting in favor of this funding request, given that we've clarified some of the questions around the funding review process for contractor work since the last funding cycle.
Vote closed
The vote passed! 🎉
77.78% of the users with binding vote were in favor and 0.00% were against (passing threshold: 55%).
Summary
| In favor | Against | Abstain | Not voted |
|---|---|---|---|
| 7 | 0 | 0 | 2 |
Binding votes (7)
| User | Vote | Timestamp |
|---|---|---|
| @marcelamelara | In favor | 2025-04-28 16:18:21.0 +00:00:00 |
| @bobcallaway | In favor | 2025-04-23 14:52:25.0 +00:00:00 |
| @camaleon2016 | In favor | 2025-04-29 11:41:15.0 +00:00:00 |
| @steiza | In favor | 2025-04-24 14:44:11.0 +00:00:00 |
| @lehors | In favor | 2025-04-28 13:28:08.0 +00:00:00 |
| @gkunz | In favor | 2025-04-24 12:28:58.0 +00:00:00 |
| @scovetta | In favor | 2025-04-28 18:03:18.0 +00:00:00 |
@haydentherapper Can you please provide a brief status update on this TI?
@kj-powell Hi, I can provide one: we're currently finishing up the last remaining hours and have a single task before doing a 1.0 release for the monitor, which should close all the tasks in this project. We also have a blog post lined up once everything is done.
In addition to what Facundo said, I'll mention that all other milestones have been completed. We've completed a review of the codebase and completed a number of issues to improve functionality. As my team concurrently began work to rewrite Rekor with a focus on reducing cost and maintenance, we pivoted some of this work to focus on adding support for Rekor v2 to the monitor.