Security-Sensitive Project Designation — Trust and Identity Requirements

[Reccetech]

Background

Several Hiero repositories sit in the critical path of real-value transactions on the Hedera network and any network built on Hiero. A malicious or compromised Committer or Maintainer with merge rights on any of these repos could approve code that silently harms end users — for example by:

• Hard-coding an account ID in a fee or transfer calculation
• Injecting a dependency that exfiltrates private keys at signing time
• Introducing a side channel in cryptographic code
• Modifying a build or release workflow to backdoor a published artifact
• Altering transaction routing or fee logic in node or relay software

Real money is at stake. This makes these repositories materially different from many open source projects and justifies a higher level of maintainer vetting than the standard contribution-based process alone provides.

Scope: What Qualifies as Security-Sensitive

A Hiero project should carry the Security-Sensitive designation if a malicious or negligent code change in that repo could directly cause financial loss to end users — specifically, projects that participate in the construction, signing, routing, or processing of value transfers on a Hiero-based network.

In scope — initial designated projects:

Repository	Reason
hiero-sdk-js	Constructs and signs transactions on behalf of end users
hiero-sdk-java	Constructs and signs transactions on behalf of end users
hiero-sdk-go	Constructs and signs transactions on behalf of end users
hiero-sdk-rust	Constructs and signs transactions on behalf of end users
hiero-sdk-python	Constructs and signs transactions on behalf of end users
hiero-sdk-cpp	Constructs and signs transactions on behalf of end users
hiero-sdk-swift	Constructs and signs transactions on behalf of end users
hiero-sdk-tck	Cross-SDK conformance testing; validates transaction behaviour
hiero-consensus-node	Processes and reaches consensus on all network transactions
hiero-mirror-node	Canonical record of all network transactions; downstream trust anchor
hiero-json-rpc-relay	Routes EVM-compatible transactions to the Hedera network

Out of scope — explicitly excluded:

• DID / identity SDKs (hiero-did-sdk-js, hiero-did-sdk-python): These manage decentralized identifiers and verifiable credentials, not value transfers. They are governed through the Identity community.
• dApps and applications built on top of Hedera: Application-layer projects that consume the SDKs but do not themselves sit in the transaction path.
• Developer tooling, documentation, and website repos: hiero-docs, hiero-website, hiero-cli, and similar repos do not participate in transaction processing.
• Standards and governance repos: hiero-improvement-proposals, sdk-collaboration-hub, governance, and similar repos.

The TSC is responsible for maintaining the designation list and may add or remove projects by vote as the ecosystem evolves.

Real-World Precedents

These are not theoretical risks. The broader software supply chain has seen exactly this kind of attack:

• Event-stream (2018): A new maintainer was granted ownership of a widely-used npm package and injected code that stole Bitcoin wallet credentials from a specific downstream application. The attack was live for weeks before detection.
• Rspack (December 2024): A stolen npm token was used to publish a version of @rspack/core (500k weekly downloads) containing an XMRig cryptocurrency miner delivered via a postinstall script.
• npm "Great Heist" (September 2025): Attackers phished the maintainers of debug, chalk, and 17 other packages (collectively 2+ billion weekly downloads) by spoofing the npm support flow to capture live 2FA codes. Malicious versions were live for approximately 2 hours before being reverted.

In all cases, the attack succeeded because the projects had no mechanism to verify who their maintainers really were beyond a GitHub account.

What Other Security-Sensitive Projects Do

Bitcoin Core

All merge commits must be GPG-signed by a maintainer whose public key is stored in the repository. A verify-commits script checks every merge, creating a cryptographic chain of trust. New maintainers are selected by existing maintainers based on demonstrated competence over many months — their keys are added by the existing team, not self-declared.

CNCF Graduated Projects

CNCF graduation criteria require documented governance, a defined security disclosure process, and organizational diversity among maintainers. Well-established graduated projects — Kubernetes being the canonical example — enforce multiple independent reviewers per PR by convention, preventing any single person from unilaterally merging code.

Apache Software Foundation

Any software release requires at least three active PMC (+1) votes. A single compromised or malicious maintainer cannot publish a release alone. The ASF also enforces diversity of organizational affiliation, so no single company can dominate a project's governance.

Ethereum / Solidity

New contributors to the Solidity compiler team must be introduced by an existing team member who knows them professionally. All commits are GPG-signed and the release pipeline requires multiple maintainer sign-offs.

Additional Requirements for Security-Sensitive Projects

These requirements apply to all Committer and Maintainer nominations on designated projects, whether submitted through the normal process or the continuity process.

1. Identity Verification (beyond a GitHub account)

The nominee must be verifiably known to their sponsor. A GitHub account and contribution history alone are not sufficient — the sponsor must be able to confirm the nominee's real-world identity. Acceptable forms of verification:

• Co-employment: The nominee currently works or has previously worked at the same LFDT member organization as the sponsor
• Direct interaction: A video call or in-person meeting where the nominee's name, face, and professional affiliation were confirmed by at least one existing Maintainer or TSC member
• Documented professional relationship: A prior professional context with a verified identity (e.g., conference co-presenter, prior open source collaboration under a known identity)

The sponsor attestation included in the nomination PR must explicitly state which form of verification applies, with enough detail for the TSC to evaluate it.

2. CODEOWNERS Enforcement

Every Security-Sensitive project must maintain a .github/CODEOWNERS file with "Require review from Code Owners" enabled in branch protection. The CODEOWNERS file must ensure that PR approval requires someone with genuine knowledge of that specific repo — a person who maintains the consensus node should not be able to satisfy the codeowner requirement for an SDK repo, and vice versa.

For the Hiero SDKs specifically, the per-SDK codeowner team structure defined in Issue 1 implements this requirement. For other Security-Sensitive projects (consensus node, mirror node, JSON-RPC relay), the existing per-project maintainer team already provides this separation, and a CODEOWNERS file referencing that team is sufficient.

This requirement must be in place before any new nomination takes effect.

3. GPG Key Registration

While GPG commit signing is already required for all Hiero contributors under the existing DCO policy, Committers and Maintainers on Security-Sensitive projects must additionally register their public key as part of their nomination PR by adding it to governance/trusted-keys/<github-handle>.asc. This creates a governance-controlled mapping of identity to key: a commit signed with an unregistered key from a known Committer or Maintainer should be treated as a signal of potential account compromise.

4. Structured Offboarding Within 7 Days

When a Committer or Maintainer departs a Security-Sensitive project, the following must be completed within 7 days:

1. GitHub access revoked via a PR to config.yaml
2. GPG key removed from governance/trusted-keys/
3. Any Trusted Publisher registrations they hold on package registries (npm, Maven Central, PyPI, crates.io, etc.) explicitly reviewed and updated

This addresses a known gap: npm and PyPI Trusted Publisher systems do not automatically revoke registry access when a person is removed from a GitHub team. Without explicit offboarding, a departed maintainer may retain the ability to publish packages long after their access should have been removed.

Note: PR #648 is currently open and proposes publishing guidelines covering npm, Maven Central, PyPI, crates.io, and other registries under the @hiero-ledger org. That PR should be reviewed alongside this proposal, and the offboarding requirements here should be reflected in whatever publishing policy it establishes.

Offboarding for inactivity. The standard 6-month inactivity threshold defined in roles-and-groups.md applies. A Committer or Maintainer who has made no meaningful contribution in 6 months and does not respond to a contact attempt within 2 weeks must be offboarded via the same 7-day process above. Project maintainers are responsible for monitoring inactivity and initiating the offboarding PR. The TSC may also initiate offboarding if maintainers fail to act.

References

• Hiero Roles and Groups
• PR #648: Publishing guidelines
• CNCF Graduation Criteria
• Rspack supply chain attack (Dec 2024)
• npm "Great Heist" (Sep 2025)
• Event-stream Bitcoin credential theft (2018)
• Bitcoin Core contributor guide
• Apache Foundation Governance

[exploreriii]

Hello, I have had a go at reading these documents but would appreciate a little help.

"The sponsor attestation included in the nomination PR must explicitly state which form of verification applies, with enough detail for the TSC to evaluate it."

Could you confirm the exact nature of the sponsor attestation?

In the emergency procedure, #660, it details an attestation process. In that document, I would not qualify to sponsor anyone. Is that the case with the usual process?

I notice the document is not all about identity requirements.
If I may suggest if a project is truly security sensitive, perhaps we can consider adding two approvals. We are already doing this in the python SDK. We also require rebasing at the point of merge. This would avoid merging PRs that may conflict with recently new PRs, and avoid one person having too much voting power. Additionally, we sign releases which attests to their provenance. These requirements were all part of increasing the open SSF scorecard which is designed to promote good practices. https://hiero-hackers.github.io/analytics/ (see scorecards tab). In this case, perhaps the 'minimum' open SSF score for truly security sensitive projects should be at least 8.

[hendrikebbers]

This is an excellent discussion base and I like to have some of our repos in a more secure definition. My thoughts on it:

The CNCF and Apache example are what we should look at since both are coming from other OSS foundations / stewards. Here a main "security aspect" is that multiple people need to approve changes or releases. So far that was exactly what our community (including maintainers and committers) do not wanted since is has been seen as a bottleneck.

Co-employment: The nominee currently works or has previously worked at the same LFDT member organization as the sponsor
A work relation should not bring any benefit here and would be against our clear goal of a vendor neutral product. We should remove that point.

GPG Key Registration

I believe we need to make it more clear what MUST be signed by those keys:

• any commit pushed directly to a protected branch
• the merge (or squash) commit that integrates a pull request
• any release tag

Changes performed through the GitHub web UI ("Merge" / "Squash and merge" / "Rebase and merge") are signed with GitHub's internal web-flow key, not with the Committer's registered key. Next to that we have some bots that have keys, too.

Next to it we need to provide a good step-by-step documentation for that process.

But with those changes I'm fine with the concept.

Any Trusted Publisher registrations they hold on package registries (npm, Maven Central, PyPI, crates.io, etc.) explicitly reviewed and updated

We do not use personal keys here that are bound to an account. For all that we have global keys or repo specific keys. We should not allow in future to do releases with keys that are only owned by a single account.

Offboarding for inactivity. The standard 6-month inactivity threshold defined in roles-and-groups.md applies. A Committer or Maintainer who has made no meaningful contribution in 6 months and does not respond to a contact attempt within 2 weeks must be offboarded via the same 7-day process above. Project maintainers are responsible for monitoring inactivity and initiating the offboarding PR. The TSC may also initiate offboarding if maintainers fail to act.

@exploreriii is already working on those metrics and we have a lot of good content here.
Question: What if a person with inactivity after 6 months just replies all time that he/she wants to stay in the group but does not do any other interaction. Should be defined for high priority projects.

[hendrikebbers]

What is still open:

• https://github.com/hiero-hackers/hiero-sdk-csharp <- if that project wants to become part of Hiero, is the given rule a must for that project (or any future SDK project)?
• https://github.com/hiero-ledger/hiero-enterprise-java is today the only SDK like project that in Java is published under the Hiero namespace to maven central. What about projects like that?

[exploreriii]

Question: What if a person with inactivity after 6 months just replies all time that he/she wants to stay in the group but does not do any other interaction. Should be defined for high priority projects.

Yes I think for 'security sensitive projects' maintainers and committers should be at least able to keep the same level their skills over time, so replies on a group forum will not be enough as is not really repository relevant.

Meaningful maintainer/committer tasks in my eyes include:

• PRs
• reviews
• Merges
• Issues created
• Issues labelled

Generally, a maintainer or committer will do a mixture of the above as their 'meaningful contribution'.
I could suggest a minimum of 10 of such 'meaningful contributions' in a 6 month period to preserve permissions in a security sensitive repo.

We can also expect a reasonably long period of time where there is no activity e.g. planned time off for holidays, training, etc, without any notice need to be given. If a 6 month vacation is planned in a security sensitive repo, it should be documented in advance, and perhaps an exception can be made in that case.

There is a table here https://hiero-hackers.github.io/analytics/ that already tracks these activities, but this can be adapted to track on a rolling 6 month basis. Such data is public and activity analytics can definitely be made easier for the community to access, so keeping permissions up to date is made easier.