Help center

License trust and badges

A practical guide to repository control, build provenance, and Billixi file scanning.

License guide

Choose the license path; verification is needed only when you deliver a file

A key-only license needs no file or GitHub connection. If you also deliver an executable, complete the same executable preflight.

The product does not enter the review queue until its required checks are complete, so an unfinished setup is not returned to you.

Which path applies to me?

Regular Digital File

The file is scanned; GitHub is not required.

Executable Digital File

File Safety and Verified Build are both required before review.

License key only

There is no delivered file; GitHub and file scanning are not required.

License with executable

File Safety and Verified Build are both required before review.

Four simple steps to review

  1. 1

    Choose the file

    Billixi immediately checks its extension and type and warns when it may be executable.

  2. 2

    Save the private draft

    The file enters quarantine and is not available to buyers or the store.

  3. 3

    Complete two checks

    File Safety scans these exact bytes. Verified Build links them to a specific repository, commit, and GitHub Actions run.

  4. 4

    Submit once

    After both checks turn green, Submit is enabled and Ops performs the final review.

What do the two checks mean?

File Safety

This exact uploaded file passed Billixi’s current scan. It is not an absolute guarantee or proof of ownership.

Verified Build / Origin

This exact file hash is linked to a repository, commit, and authenticated GitHub Actions run. It is not proof of legal ownership.

GitHub trust path

Open this simple four-step guide if you need help.

1An anonymized GitHub App example with its Configure button and read-only source trust description.
01

Connect privately

Install the read-only GitHub App only for the repository you select.

2An anonymized private GitHub repository showing the committed .billixi product claim path without exposing the challenge value.
02

Prove publisher control

Commit the one-time product claim and verify its exact branch, tag, or commit.

3An anonymized successful GitHub Actions run with tests, platform builds, immutable release publishing, and Billixi proof.
03

Prove and scan the build

Send the GitHub Actions OIDC build proof, then wait for Billixi security review.

4An anonymized Trust and Verification example showing independent publisher, provenance, scan, and security review signals.
04

Confirm the independent signals

Return to Trust & Verification and check each applicable badge against the exact commit and release.

How release updates work

Import a new GitHub release, wait for approval, then publish it once. Eligible buyers get the latest download and one email.

  1. 1

    Build a new release

    After pushing, manually run the repository release workflow with a new SemVer tag. A push alone never publishes.

  2. 2

    Import and approve

    Accept ownership, import the immutable asset, and wait for Billixi approval on this page.

  3. 3

    Publish and notify

    Add clear buyer notes and publish once. Billixi sends one email to each eligible buyer.

Connect GitHub

Billixi asks for read-only Metadata and Contents access, scoped to repositories you select. Attestations access is optional and used only for GitHub-native provenance. Billixi never commits, opens a PR, clones the repository, or stores an installation token.

Open products and install the GitHub App

Place the one-time challenge file

Copy the path and the product-specific JSON shown in Trust & Verification. Commit it to the selected repository. Billixi resolves one commit first and reads the file only from that exact commit. The displayed challenge normally expires after 24 hours.

Path
.billixi/product-claim.json
Example — use the JSON generated for your product
{
  "schema": "billixi-product-claim/v1",
  "product_id": "<your-product-id>",
  "challenge": "<one-time-value>",
  "expires_at": "<shown-expiry>"
}

GitHub web: Add file → Create new file → enter the exact path → paste JSON → commit. Git local: create the directories and file, commit, push, then enter that branch or commit in Billixi and choose Check again.

Common fixes: exact path and case, correct branch, unexpired challenge, unchanged JSON, and restored app permission.

GitHub web interface

Open the selected repository, choose Add file → Create new file, enter the exact path, paste the generated JSON unchanged, and commit to the branch you will verify.

Git on your computer

Create the file locally, paste the generated JSON unchanged, commit, push, then enter that branch or exact commit in Billixi and choose Check again.

Git on your computer
mkdir -p .billixi
# Save the exact JSON generated in Billixi as:
# .billixi/product-claim.json
git add .billixi/product-claim.json
git commit -m "chore: add Billixi product claim"
git push

Generate private build provenance

GitHub Actions signs a short-lived OIDC proof that binds the private repository, workflow, commit, GitHub-hosted runner, Billixi product, and final file SHA-256. Billixi stores only immutable claims and token digests—not the token or source. No Enterprise plan, public repository, secret, or personal token is required.

.github/workflows/release.yml
name: Private release provenance
on:
  push:
    tags: ['v*']

permissions:
  contents: read
  id-token: write

jobs:
  release:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
      - name: Build artifact
        run: ./scripts/build-release.sh
      - name: Prove the exact private build to Billixi
        shell: bash
        env:
          BILLIXI_PRODUCT_ID: '<your-product-id>'
          BILLIXI_ARTIFACT_PATH: dist/my-product.zip
          BILLIXI_PROOF_ENDPOINT: https://api.billixi.com/api/v1/payment/source-providers/github/actions/build-proofs
        run: |
          set -euo pipefail
          sha256="$(sha256sum "$BILLIXI_ARTIFACT_PATH" | cut -d ' ' -f1)"
          compact_product_id="$(tr -d '-' <<<"$BILLIXI_PRODUCT_ID")"
          audience="billixi-source-trust:${compact_product_id}:${sha256}"
          encoded="$(jq -rn --arg value "$audience" '$value | @uri')"
          response="$(curl --silent --show-error --fail-with-body \
            -H "Authorization: Bearer ${ACTIONS_ID_TOKEN_REQUEST_TOKEN}" \
            "${ACTIONS_ID_TOKEN_REQUEST_URL}&audience=${encoded}")"
          token="$(jq -er '.value' <<<"$response")"
          echo "::add-mask::$token"
          body="$(jq -cn --arg productId "$BILLIXI_PRODUCT_ID" --arg artifactSha256 "$sha256" \
            --arg artifactName "$(basename "$BILLIXI_ARTIFACT_PATH")" \
            '{productId:$productId,artifactSha256:$artifactSha256,artifactName:$artifactName}')"
          curl --silent --show-error --fail-with-body \
            -H "Authorization: Bearer ${token}" -H 'Content-Type: application/json' \
            --data "$body" "$BILLIXI_PROOF_ENDPOINT" >/dev/null
          unset token response
Linux / macOS
sha256sum dist/my-product.zip
# macOS
shasum -a 256 dist/my-product.zip
Windows PowerShell
Get-FileHash .\dist\my-product.zip -Algorithm SHA256

Statuses and fixes

Waiting for GitHub
Install the app or retry after a temporary provider outage.
Repository verified
The exact claim commit passed and remains within its freshness window.
Attestation missing
Run the release workflow for the final asset, then retry verification.
Digest mismatch
The attested or provider digest is not the Billixi SHA-256. Create a new release with unchanged final bytes.
Wrong workflow identity
Use the workflow allowed by the product policy; Ops cannot bypass it.
Waiting for Billixi scan
The imported bytes are quarantined and waiting for the independent scan.
Scan rejected
Fix the artifact and create a new release; provenance cannot bypass the scan.
Manual review
Billixi found evidence that needs security or ownership review.
Approved
The exact release passed the applicable gate.
Connection revoked
Reinstall or re-authorize the GitHub App and verify the repository again.
Attestation stale or revoked
Create valid new evidence or retry after trusted-root recovery.

Real limitations

  • Repository verification is evidence of control at one point in time, not legal ownership.
  • Build provenance validates stated build identity and source reference, not source-code quality or absence of backdoors.
  • Billixi Scan Passed reduces risk but does not guarantee absolute safety.
  • The three badges are independent risk signals; together they are not an absolute anti-theft or “fully trusted” promise.