Fix OSSF Scorecard Dangerous-Workflow finding in .github/workflows/on-review.yml

[danielmarv]

🧑‍🔬 Advanced Issue

Welcome! This is an Advanced Issue touching core SDK architecture.

It is designed for expert contributors who have demonstrated deep architectural understanding and a proven track record of high-quality contributions.

🐞 Problem Description

Summary

The Python SDK repository is currently failing the OSSF Scorecard Dangerous-Workflow check with a critical warning.

Scorecard output:

Dangerous-Workflow
Risk level: critical

Determines if the project's GitHub Action workflows avoid dangerous patterns.

Reason: dangerous workflow patterns detected
Details:
Warn: untrusted code checkout '${{ github.event.pull_request.base.sha || github.ref }}': .github/workflows/on-review.yml:34

The warning points to this workflow file:

• File: .github/workflows/on-review.yml
• Affected line: 34

This workflow may be checking out code in a way that GitHub security tools consider unsafe. That can be dangerous because pull requests from forks are not fully trusted. A malicious contributor could try to modify workflow behavior, access tokens, or abuse permissions if the workflow mixes untrusted pull request code with privileged GitHub Actions permissions.

This does not necessarily mean the repository is currently compromised. It means the workflow has a pattern that security scanners recognize as risky and should be hardened.

Explanation

The Scorecard warning is caused by a checkout step in .github/workflows/on-review.yml using this dynamic ref expression:

ref: ${{ github.event.pull_request.base.sha || github.ref }}

This pattern is being flagged as an untrusted checkout.

The risk becomes more serious if the workflow is triggered by events such as:

• pull_request_target
• workflow_run
• or any other event that may run with elevated permissions while handling pull request-controlled input

The core security concern is this combination:

privileged workflow context + pull request-controlled input + checkout or execution of code

Depending on the rest of the workflow, this can create risks such as:

• executing untrusted code with a privileged GITHUB_TOKEN
• exposing repository secrets to attacker-controlled code
• allowing workflow command or script injection
• allowing unintended write access to repository resources
• reducing the repository's OSSF Scorecard security posture

Current Behavior

The workflow currently contains a checkout ref that Scorecard identifies as unsafe:

ref: ${{ github.event.pull_request.base.sha || github.ref }}

As a result, the repository receives a critical Dangerous-Workflow finding.

Expected Behavior

The workflow should avoid unsafe checkout behavior and clearly separate trusted and untrusted execution contexts.

Expected secure behavior:

• Workflows processing untrusted pull requests should run with minimal permissions.
• Pull request code should not execute in a privileged workflow context.
• Repository secrets should not be exposed to pull request-controlled code.
• Checkout refs should be explicit and safe for the workflow trigger being used.
• The OSSF Scorecard Dangerous-Workflow warning should be resolved.

🛠️ Implementation Notes

🧠 Advanced Contributors — Prerequisites & Expectations

Caution

Advanced issues are the highest-risk work in this project. We will reject PRs that do not meet these standards.

🏁 Concrete Prerequisites

• Advanced Language: Proficient with Python.
• Expertise: Deep architectural understanding of _Executable, Transaction, and Query base classes.
• Proven History: Successfully completed ≥ 10 intermediate issues in this repo.
• Consistency: ≥ 3–4 months of active, human-led contributions to this SDK.

Note

CI/CD Exception: For issues focused on GitHub Actions / Workflows, the repo-specific thresholds above may be waived if the contributor demonstrates advanced-level proficiency in CI/CD.

⚠️ AI Usage Policy

• Using AI to generate code for Advanced issues is strictly discouraged
• AI may be used to help explain file relationships, but cannot be the main source of research.
• Submitting AI-generated or unvalidated code is grounds for immediate closure

⏱️ Timeline & Workflow

• Typical time: ~1 month / ~50 hours.
• 🔴 Completing an advanced issue in 1–3 days is a red flag and will likely be rejected.
• Suggested: Post your proposed architectural approach as a comment and wait for explicit maintainer approval before writing any code.

🔬 Technical Domains

• API Client Architecture (request → serialization → execution → response mapping)
• Backward Compatibility (preserving method signatures, defaults, and return types)
• Protobuf Alignment (reading .proto files, _to_proto() / _from_proto() correctness)
• State & Immutability (correct usage of guards like _require_not_frozen)
• Execution Boundaries (retry logic, backoff, node selection, gRPC deadlines)
• Testing (unit, integration, mocking, test coverage for edge cases and failure modes)

🛡️ Quality & Review Standards

Advanced PRs must be "safe, maintainable, architecturally sound, and production-ready."

1. Architectural Fit: The solution must fit naturally into the existing SDK abstractions.
2. Security & Correctness: Evaluate all logic for injection risks, state corruption, or thread-safety issues.
3. Maintainability: Code must be short and clear enough for any other maintainer to debug without your assistance.
4. Backward Compatibility: Public API signatures must be preserved. If a breaking change is required, it must be explicitly managed through a deprecation cycle.
5. Comprehensive Testing: Must include unit and integration tests covering all new logic paths, edge cases, and failure modes. AI generated tests based on AI generated code is grounds for immediate rejection.

✅ PR Quality Checklist

Before opening your PR, the contributor must confirm:

• I have spent the majority of my time researching the problem and solution space extensively, including reviewing relevant code, documentation, and external resources.
• I understand the system-wide impact of these changes on affected modules and performance.
• The system design fits with current Hiero SDK architectural approaches.
• I have tested my changes extensively against both local and network environments.
• I have verified naming, types, and field ordering against pinned Protobufs.
• Every line of code is personally understood and explainable.

📚 Resources & Support

References:

• Hedera Protobufs

Python SDK References:

• SDK Project Structure
• Transaction Lifecycle
• Executable Architecture
• Hedera Protobufs (services)
• Browse closed advanced PRs — see how others did it

🆘 Stuck?

• Community Calls
• Discord

[github-actions]

Thanks for your submission.

This issue is awaiting approval from @hiero-ledger/hiero-sdk-python-triage and @hiero-ledger/hiero-sdk-python-committers and @hiero-ledger/hiero-sdk-python-maintainers.

[github-actions]

Approved by @hiero-ledger/hiero-sdk-python-triage and @hiero-ledger/hiero-sdk-python-committers and @hiero-ledger/hiero-sdk-python-maintainers.