[Technical Initiative Funding Request]: Sigstore Transparency Log Monitoring

[haydentherapper]

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:

1. A thorough review of the codebase to identify 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.

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

• 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.

[mlieberman85]

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?

[woodruffw]

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.

[haydentherapper]

@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.