[Technical Initiative Funding Request]: Sigstore Transparency Log Monitoring

[haydentherapper]

Technical Initiative

Sigstore

Lifecycle Phase

Graduated

Funding amount

$112,000 USD, for 320 hours (2 months FTE)

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?

https://github.com/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 1) a thorough review of the codebase to identity areas for improvement, 2) completion of all open issues on rekor-monitor, 3) 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. In the future, we would like to see a website like https://www.gopherwatch.org/ stood up as well to provide monitoring as a 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, including:

1. A thorough review through the existing codebase, with any necessary refactoring for maintainability and testing, and identifying areas for improvement
2. Completion of all open and newly identified issues in rekor-monitor
3. A 1.0 major release with a stable API

Who is responsible for doing the work of this funding initiative?

William Woodruff, 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, https://github.com/sigstore/tsc?tab=readme-ov-file#members

What license is this funding initiative being used under?

https://github.com/sigstore/rekor-monitor/blob/main/LICENSE

Code of Conduct

• 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 Q2'25, rekor-monitor has been reviewed and work has begun on open issues.

By the end of Q2'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 Q2'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.

[steiza]

Similar to #424, this is among the larger of funding requests we've seen, but (also similar to #424) the Sigstore transparency log, Rekor, underpins attestations on npm, PyPI, Maven Central, and Homebrew.

I can't speak for the other ecosystems, but deps.dev monitors npm attestations, and at least 3 times they have uncovered small operational issues where Rekor was part of our investigation. The value of monitoring the transparency log is not just hypothetical!

[lehors]

This is the kind of funding requests I wish we didn't have. Not because there is no value in the proposed work. Not at all. I think the value is pretty clear. But because this should be something done by the open source community. Having to hire contractors to develop open source software just feels wrong to me. I've been saying this since the very first days the idea of funding development came up, several years ago.

I understand this may be the only way to get the work done but I think it should be understood that the actual cost will be much higher in the end because we'll have no community behind that code and no expertise in it. Any maintenance or further development will require contracting again. This isn't just theoretical, I am dealing with a living example of that in another LF org right now.

[bobcallaway]

@haydentherapper assuming this gets funded, who will own long-term operations of the platform?

[haydentherapper]

@bobcallaway, the current maintainers of rekor-monitor will continue to maintain the codebase. With this funding request, there will be no infrastructure created.
For future work outside of the scope of this funding request, we'll need infrastructure operations for a website, but the current plan is to explore a partnership with existing log monitors from the Certificate Transparency ecosystem.

[haydentherapper]

@lehors, for more context, this is an existing project within an active community with a set of maintainers who are happy to continue to maintain it, but who don't have the bandwidth to implement new features. I agree with you that we should scrutinize funding requests for new projects that don't include a clear story around how that project would be maintained long-term. For this funding request, we're looking for feature implementation on an existing project which will be maintained by its current set of maintainers.

[riaankleinhans]

/vote

[git-vote]

Vote created

@riaankleinhans has called for a vote on [Technical Initiative Funding Request]: Sigstore Transparency Log Monitoring (#445).

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 1month 11days 13h 26m 24s. It will pass if at least 70% of the users with binding votes vote In favor 👍. Once it's closed, results will be published here as a new comment.