[Technical Initiative Funding Request]: Sigstore Log Monitoring Website

[haydentherapper]

Technical Initiative

Sigstore

Lifecycle Phase

Graduated

Funding amount

$96,000

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.

The average user will not want to run a monitor themselves as this requires maintaining a service. The lack of a simple solution for monitoring a transparency log puts users at risk by not knowing that their identity has been compromised.

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. This project focuses on the users that generate public Sigstore signatures, though this can also benefit private deployments as well.

Have there been previous attempts to resolve the problem?

The OpenSSF funded a technical initiative to improve and productionize sigstore/rekor-monitor, a tool for monitoring identities and keys. This tool can be run as both a service, which requires users to become service operators, and a GitHub Action, which is costly for the Sigstore project at scale due to the amount of entries downloaded from the log.

Why should it be tackled now and by this TI?

Building on the momentum of the previous OpenSSF TI-funded work to build a productionized monitor, we now want to make monitoring as simple as possible for our users.

Give an idea of what is required to make the funding initiative happen

We will implement a frontend for sigstore/rekor-monitor that offers monitoring for user-provided identities, along with any changes needed in sigstore/rekor-monitor to support this service, e.g. a storage backend. We will take inspiration from gopherwatch.org, an open source project for monitoring the Go checksum database.

Note that this request is not for long-term funding of the operation of the website and infrastructure. This is a one-time funding request for implementation. The community will take on the long-term operation of the monitor. This funding request will be the last request for Sigstore monitoring.

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 additional work besides running the monitor is needed.

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 implement a user-friendly web frontend for rekor-monitor, including:

• A web frontend where users can subscribe to get alerts if one of their identities, repositories and/or packages is used in the transparency log.
• Any changes required in the backend (rekor-monitor) for the correct functioning of the web service.
• A release of the service in an easy-to-deploy configuration (e.g: using docker-compose) to make it easy for members of the community to run their own monitor services.

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

Facundo Tuesca, Trail of Bits

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

Hayden Blauzvern, Google and Sigstore community chair, and Facundo Tuesca, 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 Q1'26, the changes necessary to implement a website and any changes to rekor-monitor have been identified and scoped.

By the end of Q2'26, the website and backend have been implemented, along with a blog post on the work.

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.

SoW will be provided upon funding approval, which will include the above deliverables and milestones.

[steiza]

/vote

[git-vote]

Vote created

@steiza has called for a vote on [Technical Initiative Funding Request]: Sigstore Log Monitoring Website (#536).

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]

Vote status

So far 0.00% of the users with binding vote are in favor and 0.00% are against (passing threshold: 55%).

Summary

In favor	Against	Abstain	Not voted
0	0	0	9

Binding votes (0)

User	Vote	Timestamp
@steiza	Pending
@justaugustus	Pending
@mlieberman85	Pending
@scovetta	Pending
@bobcallaway	Pending
@lehors	Pending
@gkunz	Pending
@marcelamelara	Pending
@camaleon2016	Pending

[mlieberman85]

It's mentioned that there is no request for funding of the operations and service of the website, but I assume that infra cost is covered through some other mechanism as well?

[haydentherapper]

It's mentioned that there is no request for funding of the operations and service of the website, but I assume that infra cost is covered through some other mechanism as well?

Infra costs will be the responsibility of whoever operates the monitor, though this should be far less than the cost of operating Sigstore.

Roughly trying to estimate storage costs - For every registered user, you'll need to store a) the identity string or key fingerprint, b) index values, c) artifact hashes. You'll also need to the identity, index and hash for every entry in Rekor. Let's roughly say that's 100 bytes for each entry, and with the currently 650 million entries in Rekor, you're looking at 65 gigabytes. For GCP, that's ~$2 a month. I can't estimate egress and infrastructure (e.g. K8s) costs since that varies significantly between hosting providers, but we could give guidance on how to run this as low cost as possible, maybe with serverless infra.