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

[marcelamelara]

I'm totally supportive of the work that this funding is intended for, but I do find the requested amount to be a bit steep for an 8-week FTE timeframe. I realize that the final funding amount is approved by the GB, but can you please elaborate on how the currently requested funding amount was calculated?

[haydentherapper]

@woodruffw, can you answer #445 (comment)?

[woodruffw]

Yep! Thanks for the ping.

but can you please elaborate on how the currently requested funding amount was calculated?

I calculated this amount from the preferential rate my team at Trail of Bits uses for long-standing OSS engineering projects that we contribute to. For full transparency our "corporate" (meaning non-OSS) and non-preferential (meaning not grandfathered) rates tend to be about 30% higher for engineering.

As for why our rates are what they are: we employ a staff of subject matter experts who work on OSS year-round, including ongoing maintenance and support of projects that we're originally paid to create or refine but no longer have active sponsors. I believe pretty strongly that good engineers shouldn't have to take a pay cut to work on OSS, so our rates essentially reflect what it costs us to compensate people to do OSS as though it was any other normal SWE career path.

(Without doing too much promotion, I think we also have a good track record when it comes to delivering high-quality, well-tested, well-documented work that benefits the companies and OSS communities we work most frequently with.)

TL;DR: Trail of Bits' engineering rates reflect our expertise and the fact that we pay SMEs to do OSS engineering full-time at industry rates.

[git-vote]

Vote status

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

Summary

In favor	Against	Abstain	Not voted
2	0	0	7

Binding votes (2)

User	Vote	Timestamp
bobcallaway	In favor	2025-02-25 13:01:18.0 +00:00:00
steiza	In favor	2025-02-24 20:55:32.0 +00:00:00
@justaugustus	Pending
@mlieberman85	Pending
@scovetta	Pending
@lehors	Pending
@gkunz	Pending
@marcelamelara	Pending
@camaleon2016	Pending

[lehors]

No offense to @woodruffw and his team for which I have no reason to doubt the competency and value, as I've always said about this process I find it slightly unsettling that we are being asked to approve a request on the basis of a single proposed provider. I understand for small amounts it may not be worth going through a bidding process with the additional complexity and time this would imply but how high a number are we willing to go without one?

[haydentherapper]

I would also keep in mind the non-material time cost of searching for a team to perform this work and ramping that team up on Sigstore and this library.

[camaleon2016]

I tend to side with Arnaud on this. I do believe this is a good step in the right direction just not sure of the dollar spend for 2 months. Are there cheaper alternatives? How many devs does it take to do something like this? @woodruffw mentioned a team. How many are on the team? why are the only working 8 working days (320 hours) in 2 months?

[woodruffw]

@lehors No offense taken. It's your (meaning the TAC's) responsibility to evaluate the merit of proposals along all dimensions, and I think your concern is a legitimate one.

At the same time, I essentially agree with @haydentherapper: there's a discovery and knowledge cost in any codebase/ecosystem, and Sigstore is no exception. For our (ToB's) part, I think our proposal is competitive given our extensive experience in the Sigstore ecosystem; we don't require any ramp-up time or paid management overhead.

@camaleon2016 My direct team has four people on it: myself, two Senior Engineers, and one Engineer II. All have experience working on components of Sigstore/the Sigstore ecosystem, and we also have a larger company talent pool of ~90 engineers with extensive cryptography and systems experience.

why are the only working 8 working days (320 hours) in 2 months?

Apologies if I'm misunderstanding what you mean, but there are 40 FTE working days in the proposal: 8 engineer-hours per day over 2 months of effort. Our typical working flow is to have a period of performance that's a multiplier of the working period, because we don't bill time when we're blocked or waiting for feedback. For example, in a case like this, our period of performance is typically 4-5 months.

[marcelamelara]

My direct team has four people on it

@woodruffw thanks for your reply above and for clarifying this. It wasn't clear from the submitted proposal that the requested funding amount would cover a team of 4+ engineers over the 8 week span of the work.

If this is the case, @haydentherapper can you please amend the request and specify the anticipated number of engineers this request would cover?

To @lehors and @haydentherapper 's points, I can definitely see the pros/cons of adding a contractor selection process for this work. There's definitely something to be said about reducing ramp-up time by working with an engineering team that is already familiar with the Sigstore ecosystem. At the same time, I worry about the precedent we set for future request for SWE work if we don't go through a bidding process. Were other teams considered for this work?

[marcelamelara]

I'd also like to hear other @ossf/tac perspectives on this discussion.

[woodruffw]

@woodruffw thanks for your reply above and for clarifying this. It wasn't clear from the submitted proposal that the requested funding amount would cover a team of 4+ engineers over the 8 week span of the work.

Sorry, I should clarify further: my team has four people on it, but the scope is for 1 FTE for 2 months. In other words, one of those four for 2 months, or two for 1 month, or similar, but not 2 months for each for all.

(My apologies if I caused more confusion by answering overly literally: the way my team works is that we split our time between multiple OSS projects for multiple clients. That's why we measure everything in engineer-weeks, not calendar-weeks.)