TavernKeeper Advisory reports for Tavernary

TavernKeeper Scan Report

AventurasTeam/Aventuras

Commit 1aa6832 Reviewed

No material or immediate-danger concern was identified in this review.

This advisory report describes what the named tools and review process found at one exact commit. Unknown or unobserved behavior may still exist.

0 immediate danger 0 material 122 low

What this review found

No material or immediate-danger item was identified.

Minor cautions

zizmor reported secrets-inherit

Minor caution · high confidence

The release pipeline hands every secret the project stores to its Android build job. Since that job's definition lives in the same project and is written by the same maintainers, this is normal practice and not evidence of anything harmful. It is just broader than strictly necessary, so a future problem in that build job could touch more secrets than it needs.

Technical evidence

Scanner reason: zizmor matched workflow-security rule secrets-inherit. The match applies to this repository.

Contextual assessment: The release workflow's android build job passes all repository secrets to a reusable workflow via unconditional secrets inheritance. The called workflow is defined in the same repository under maintainer control, so this is a common CI pattern rather than an external exposure. The hygiene concern is that every repository secret, rather than only the ones the build needs, becomes available to the called workflow, which widens the blast radius if the called workflow or any action it uses is later compromised or changed. No attacker-controlled trigger, exfiltration path, or malicious consumer is demonstrated by the supplied evidence.

Impact: low · Exploitability: unlikely

Developer action: Prefer passing only the specific secrets each reusable build workflow needs, for example the GitHub token and any signing credentials, instead of inheriting all secrets.

Scanner
zizmor 1.28.0
Rule
secrets-inherit
File role
tooling
Source
.github/workflows/release.yml:57

zizmor reported unsound-ternary

Minor caution · high confidence

A conditional expression in the release automation is written in a way that always picks the same outcome, so re-running a pre-release build may stomp on notes a maintainer typed into the draft. It is a small logic bug in the project's own tooling, not something an outsider can exploit or that affects the app users get.

Technical evidence

Scanner reason: zizmor matched workflow-security rule unsound-ternary. The match applies to this repository.

Contextual assessment: The release-body input uses an and/or chain intended as a conditional, but in GitHub's expression language an empty string is falsy, so both branches resolve to the fallback text and the intended empty-on-re-run case never occurs. The observable effect is that the fixed pre-release banner is applied even when re-running against an existing draft, which can overwrite manually typed release notes. This is a correctness flaw in trusted automation logic: the inputs come from an internal guard step, no attacker-controlled data reaches it, and no secrets, exfiltration, or shipped-product behavior are involved.

Impact: none · Exploitability: unlikely

Developer action: Replace the and/or pseudo-ternary with a proper conditional expression so the release body is genuinely left unset when re-running an existing draft.

Scanner
zizmor 1.28.0
Rule
unsound-ternary
File role
tooling
Source
.github/workflows/pre-release.yml:46

Gitleaks reported generic-api-key

Minor caution · high confidence

A scanner flagged an API key hardcoded in the app. Looking at how it is used, it is a publicly available search key from another website—the same key that site gives to every web browser—and it is only used to search that site for characters to download. It is not the project's own secret and not the user's key, so nothing sensitive is exposed. Hardcoding it is still untidy: it can stop working without warning and looks like a real secret to scanners.

Technical evidence

Scanner reason: Gitleaks matched secret-detection rule generic-api-key. The match applies to this repository.

Contextual assessment: A 64-hex-character bearer token is hardcoded as a fallback in a discovery provider for a third-party character-card site. The surrounding code shows the token is normally scraped at runtime from that site's own public client-side JavaScript, meaning it is a token the site already publishes to every browser visitor, not a private project or user credential. The token is sent only to that site's search endpoint to power a character discovery feature that matches the project's stated purpose; no user data, provider API keys, or story content is involved. The hardcoded fallback is a hygiene weakness because it embeds a third party's token and will silently rot or could be confused with a genuine secret, but the evidence does not demonstrate exposure of any sensitive credential.

Impact: low · Exploitability: unlikely

Developer action: Document inline that this is the third-party site's public client token, and consider dropping the hardcoded fallback in favor of failing gracefully and re-fetching the token, so it cannot be mistaken for a genuine secret.

Scanner
gitleaks 8.30.1
Rule
generic-api-key
File role
production
Source
src/lib/services/discovery/providers/janny.ts:28

zizmor reported secrets-inherit

Minor caution · high confidence

The automated release script hands every secret the project has to its build sub-scripts. Those sub-scripts live in the same project and are run only by maintainers when publishing a release, so nothing in the evidence shows secrets leaking to outsiders. It is still a good idea to hand over only the specific secrets each build actually needs, in case the build scripts change later.

Technical evidence

Scanner reason: zizmor matched workflow-security rule secrets-inherit. The match applies to this repository.

Contextual assessment: A release workflow passes all repository secrets to three reusable build workflows. The called workflows are local, same-repository files referenced by relative path, so this is not a cross-repository secret disclosure; it is a maintainers-only release pipeline triggered by protected tags or manual dispatch. The pattern is a real hygiene weakness because every current and future repository secret becomes available to the build jobs, expanding the blast radius if a build workflow step is later modified, but the supplied evidence shows no attacker-controlled trigger, no untrusted input reaching the called jobs, and no demonstrated secret misuse or exfiltration.

Impact: low · Exploitability: unlikely

Developer action: Replace blanket secret inheritance with explicit per-secret passing so each build job receives only the credentials it needs, and keep the called workflows' permissions scoped.

Scanner
zizmor 1.28.0
Rule
secrets-inherit
File role
tooling
Source
.github/workflows/release.yml:64

zizmor reported secrets-inherit

Minor caution · high confidence

The desktop build job also receives every project secret rather than just the ones it needs. Nothing in the supplied evidence shows misuse; this is a least-privilege hygiene note for the release pipeline.

Technical evidence

Scanner reason: zizmor matched workflow-security rule secrets-inherit. The match applies to this repository.

Contextual assessment: Identical pattern to the other called workflow: the desktop build job inherits all repository secrets unconditionally. The reusable workflow is local to the same repository and maintainers control its content, so there is no demonstrated external or attacker-controlled destination. The weakness is over-broad secret scope relative to what the job needs, which increases potential blast radius if the called workflow or its actions are ever compromised, but no such compromise or exfiltration is evidenced.

Impact: low · Exploitability: unlikely

Developer action: Pass only the required secrets explicitly to the reusable desktop build workflow instead of inheriting all of them.

Scanner
zizmor 1.28.0
Rule
secrets-inherit
File role
tooling
Source
.github/workflows/release.yml:49

JavaScript analysis reported javascript.xray.unsafe-regex

Minor caution · medium confidence

A crafted input might briefly slow or freeze the local client, without showing broader security harm.

Technical evidence

Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.unsafe-regex. The match applies to this repository.

Contextual assessment: The expression may permit a local CPU slowdown, but this evidence shows no credential, persistence, code-execution, or cross-user impact.

Impact: low · Exploitability: plausible

Developer action: Bound the input length or replace the expression when practical.

Scanner
javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1_families-1
Rule
javascript.xray.unsafe-regex
File role
tooling
Source
scripts/version.js:14

zizmor reported unsound-ternary

Minor caution · high confidence

The expression chosen to leave the release notes blank on a re-run never actually produces a blank value, so the placeholder text is always used and could overwrite notes someone typed into a draft release. This is a release-pipeline bug, not a security issue, and it only affects maintainers publishing releases.

Technical evidence

Scanner reason: zizmor matched workflow-security rule unsound-ternary. The match applies to this repository.

Contextual assessment: The release-body parameter uses a chained and/or pseudo-ternary. In GitHub expression semantics, the intended-empty branch evaluates to an empty string, which is falsy, so the or-branch is taken in every case. The result is that the body always receives the fallback text, including on re-runs of an existing draft, where the surrounding comment says the notes should be left untouched. This is a demonstrated logic defect in the workflow, but it affects only release-note content in a maintainer-operated pipeline; there is no attacker-controlled input, secret exposure, or code-execution consequence, and the fallback text itself is a harmless static string.

Impact: low · Exploitability: unlikely

Developer action: Replace the chained and/or expression with a proper conditional, such as an if-based step or a format/if expression that yields an empty body when the release state is draft, so typed draft notes are preserved on re-runs.

Scanner
zizmor 1.28.0
Rule
unsound-ternary
File role
tooling
Source
.github/workflows/release.yml:45
Deterministic technical evidence (103)

  • Dependency advisory RUSTSEC-2025-0080:pkg:d9db6230dfa23e8ba0fa93cf applies · osv-scanner 2.4.0

    A dependency has a published security issue, though this scan does not show that the project exposes it to an attacker.

    Policy reason: osv-structured-advisory · Execution scope: unknown

    Source: src-tauri/Cargo.lock

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/pre-release.yml:24

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/build-desktop.yml:105

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/build-android.yml:149

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/release.yml:23

  • zizmor reported template-injection · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/actions/build-version/action.yml:37

  • Dependency advisory GHSA-72xf-g2v4-qvf3:pkg:2f098d09dffd8939e104e6f0 applies · osv-scanner 2.4.0

    A dependency has a published security issue, though this scan does not show that the project exposes it to an attacker.

    Policy reason: osv-structured-advisory · Execution scope: unknown

    Source: package-lock.json

  • Dependency advisory GHSA-2mjp-6q6p-2qxm:pkg:6d96a46fadb25a056091e448 applies · osv-scanner 2.4.0

    A dependency has a published security issue, though this scan does not show that the project exposes it to an attacker.

    Policy reason: osv-structured-advisory · Execution scope: unknown

    Source: package-lock.json

  • Dependency advisory GHSA-m8rv-5g2x-5cg5:pkg:4960f6321d5eb83e948ad4ac applies · osv-scanner 2.4.0

    A dependency has a published security issue, though this scan does not show that the project exposes it to an attacker.

    Policy reason: osv-structured-advisory · Execution scope: unknown

    Source: package-lock.json

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/build-desktop.yml:83

  • Dependency advisory GHSA-g8m3-5g58-fq7m:pkg:e4124745cfdd4bc7b9a15ac1 applies · osv-scanner 2.4.0

    A dependency has a published security issue, though this scan does not show that the project exposes it to an attacker.

    Policy reason: osv-structured-advisory · Execution scope: unknown

    Source: package-lock.json

  • Dependency advisory RUSTSEC-2026-0258:pkg:222a355a74aca3bba6fbb9da applies · osv-scanner 2.4.0

    A dependency has a published security issue, though this scan does not show that the project exposes it to an attacker.

    Policy reason: osv-structured-advisory · Execution scope: unknown

    Source: src-tauri/Cargo.lock

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/build-android.yml:39

  • zizmor reported artipacked · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/release.yml:22-23

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/actions/npm-install/action.yml:34

  • Dependency advisory GHSA-v3r7-h72x-cjcm:pkg:3442b6d04e2f119213e16797 applies · osv-scanner 2.4.0

    A dependency has a published security issue, though this scan does not show that the project exposes it to an attacker.

    Policy reason: osv-structured-advisory · Execution scope: unknown

    Source: package-lock.json

  • Dependency advisory GHSA-5v7r-6r5c-r473:pkg:db1c36cdfd066cb137608ca0 applies · osv-scanner 2.4.0

    A dependency has a published security issue, though this scan does not show that the project exposes it to an attacker.

    Policy reason: osv-structured-advisory · Execution scope: unknown

    Source: package-lock.json

  • Dependency advisory GHSA-vrm6-8vpv-qv8q:pkg:0b992fe91b0b56ff0c3a69a0 applies · osv-scanner 2.4.0

    A dependency has a published security issue, though this scan does not show that the project exposes it to an attacker.

    Policy reason: osv-structured-advisory · Execution scope: unknown

    Source: package-lock.json

  • zizmor reported cache-poisoning · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/build-android.yml:48

  • Dependency advisory GHSA-vxpw-j846-p89q:pkg:2b5722d889310f1a977423f1 applies · osv-scanner 2.4.0

    A dependency has a published security issue, though this scan does not show that the project exposes it to an attacker.

    Policy reason: osv-structured-advisory · Execution scope: unknown

    Source: package-lock.json

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/build-android.yml:109

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/build-android.yml:71

  • zizmor reported excessive-permissions · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/release.yml:10

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/lint-and-typecheck.yml:24

  • zizmor reported artipacked · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/pre-release.yml:23-24

  • Dependency advisory RUSTSEC-2023-0071:pkg:ee975215c8fb081d4be2c2de applies · osv-scanner 2.4.0

    A dependency has a published security issue, though this scan does not show that the project exposes it to an attacker.

    Policy reason: osv-structured-advisory · Execution scope: unknown

    Source: src-tauri/Cargo.lock

  • Dependency advisory GHSA-pxg6-pf52-xh8x:pkg:6da1e3539f31ff57c2a349c3 applies · osv-scanner 2.4.0

    A dependency has a published security issue, though this scan does not show that the project exposes it to an attacker.

    Policy reason: osv-structured-advisory · Execution scope: unknown

    Source: package-lock.json

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/build-android.yml:66

  • zizmor reported artipacked · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/build-android.yml:24-25

  • Dependency advisory GHSA-9rgm-9g3h-6x36:pkg:8a05d6d431ec29dc9927e432 applies · osv-scanner 2.4.0

    A dependency has a published security issue, though this scan does not show that the project exposes it to an attacker.

    Policy reason: osv-structured-advisory · Execution scope: unknown

    Source: package-lock.json

  • Dependency advisory RUSTSEC-2024-0370:pkg:9b268f40461da81c7a1c55ed applies · osv-scanner 2.4.0

    A dependency has a published security issue, though this scan does not show that the project exposes it to an attacker.

    Policy reason: osv-structured-advisory · Execution scope: unknown

    Source: src-tauri/Cargo.lock

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/pre-release.yml:39

  • Dependency advisory GHSA-w5hq-g745-h8pq:pkg:557a6d9a353e8755eba18deb applies · osv-scanner 2.4.0

    A dependency has a published security issue, though this scan does not show that the project exposes it to an attacker.

    Policy reason: osv-structured-advisory · Execution scope: unknown

    Source: package-lock.json

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/bootstrap-ios.yml:63

  • Dependency advisory GHSA-pmjh-fq2x-6v4x:pkg:814e6386268dbf3533461ca1 applies · osv-scanner 2.4.0

    A dependency has a published security issue, though this scan does not show that the project exposes it to an attacker.

    Policy reason: osv-structured-advisory · Execution scope: unknown

    Source: package-lock.json

  • JavaScript analysis reported javascript.xray.shady-link · javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1_families-1

    This technical signal is not part of the shipped runtime behavior.

    Policy reason: javascript-xray-inert-content · Execution scope: test-documentation-data

    Source: scripts/remote.test.js:10

  • Dependency advisory GHSA-wrw7-89jp-8q8g:pkg:4b30aae73f1836d87a5b008c applies · osv-scanner 2.4.0

    A dependency has a published security issue, though this scan does not show that the project exposes it to an attacker.

    Policy reason: osv-structured-advisory · Execution scope: unknown

    Source: src-tauri/Cargo.lock

  • Dependency advisory RUSTSEC-2026-0258:pkg:95f9173f3d1ac6374e456fa8 applies · osv-scanner 2.4.0

    A dependency has a published security issue, though this scan does not show that the project exposes it to an attacker.

    Policy reason: osv-structured-advisory · Execution scope: unknown

    Source: src-tauri/Cargo.lock

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/build-android.yml:55

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/build-android.yml:48

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/build-ios.yml:33

  • Dependency advisory GHSA-q2hr-2g5m-vwhr:pkg:795fdc464a3888c7b68760ab applies · osv-scanner 2.4.0

    A dependency has a published security issue, though this scan does not show that the project exposes it to an attacker.

    Policy reason: osv-structured-advisory · Execution scope: unknown

    Source: package-lock.json

  • Dependency advisory GHSA-rx4f-c7p8-82vq:pkg:84b2df35347fd80a7d52507c applies · osv-scanner 2.4.0

    A dependency has a published security issue, though this scan does not show that the project exposes it to an attacker.

    Policy reason: osv-structured-advisory · Execution scope: unknown

    Source: package-lock.json

  • Dependency advisory RUSTSEC-2025-0081:pkg:5c764120c78ffcfe5027b39c applies · osv-scanner 2.4.0

    A dependency has a published security issue, though this scan does not show that the project exposes it to an attacker.

    Policy reason: osv-structured-advisory · Execution scope: unknown

    Source: src-tauri/Cargo.lock

  • zizmor reported artipacked · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/build-desktop.yml:76-80

  • zizmor reported artipacked · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/bootstrap-ios.yml:22-23

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/bootstrap-ios.yml:23

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/actions/npm-install/action.yml:47

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/bootstrap-ios.yml:51

  • Dependency advisory GHSA-2gqq-gqf2-x968:pkg:46832ca569076237770558e9 applies · osv-scanner 2.4.0

    A dependency has a published security issue, though this scan does not show that the project exposes it to an attacker.

    Policy reason: osv-structured-advisory · Execution scope: unknown

    Source: package-lock.json

  • Dependency advisory GHSA-2v37-7h3g-55p8:pkg:06ad0185911f4bb6106d61dc applies · osv-scanner 2.4.0

    A dependency has a published security issue, though this scan does not show that the project exposes it to an attacker.

    Policy reason: osv-structured-advisory · Execution scope: unknown

    Source: package-lock.json

  • Dependency advisory GHSA-fjxv-7rqg-78g4:pkg:6c89c9914b40635e432f1415 applies · osv-scanner 2.4.0

    A dependency has a published security issue, though this scan does not show that the project exposes it to an attacker.

    Policy reason: osv-structured-advisory · Execution scope: unknown

    Source: package-lock.json

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/build-desktop.yml:77

  • Dependency advisory GHSA-hmw2-7cc7-3qxx:pkg:b55f5aef11b0369cc46f988a applies · osv-scanner 2.4.0

    A dependency has a published security issue, though this scan does not show that the project exposes it to an attacker.

    Policy reason: osv-structured-advisory · Execution scope: unknown

    Source: package-lock.json

  • Dependency advisory GHSA-6rw7-vpxm-498p:pkg:43bb4aeefd1a794ecdaf18ba applies · osv-scanner 2.4.0

    A dependency has a published security issue, though this scan does not show that the project exposes it to an attacker.

    Policy reason: osv-structured-advisory · Execution scope: unknown

    Source: package-lock.json

  • Dependency advisory GHSA-8436-99hf-9mmv:pkg:8ca5f098d431dc526b1c0927 applies · osv-scanner 2.4.0

    A dependency has a published security issue, though this scan does not show that the project exposes it to an attacker.

    Policy reason: osv-structured-advisory · Execution scope: unknown

    Source: package-lock.json

  • JavaScript analysis reported javascript.xray.shady-link · javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1_families-1

    This technical signal is not part of the shipped runtime behavior.

    Policy reason: javascript-xray-inert-content · Execution scope: test-documentation-data

    Source: src/lib/services/syncActions.test.ts:15

  • Dependency advisory RUSTSEC-2024-0429:pkg:d2e88fc02f6be9987f66e6e8 applies · osv-scanner 2.4.0

    A dependency has a published security issue, though this scan does not show that the project exposes it to an attacker.

    Policy reason: osv-structured-advisory · Execution scope: unknown

    Source: src-tauri/Cargo.lock

  • zizmor reported artipacked · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/build-ios.yml:32-33

  • Dependency advisory GHSA-rfgv-xxqx-mfg5:pkg:fa194ca81f9401706246a35f applies · osv-scanner 2.4.0

    A dependency has a published security issue, though this scan does not show that the project exposes it to an attacker.

    Policy reason: osv-structured-advisory · Execution scope: unknown

    Source: package-lock.json

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/build-android.yml:138

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/build-ios.yml:54

  • Dependency advisory GHSA-r53p-7pc4-xj5r:pkg:bd7641efc84f0d9546a70936 applies · osv-scanner 2.4.0

    A dependency has a published security issue, though this scan does not show that the project exposes it to an attacker.

    Policy reason: osv-structured-advisory · Execution scope: unknown

    Source: package-lock.json

  • Dependency advisory GHSA-35p6-xmwp-9g52:pkg:d8c1871761b9627fdd34c81b applies · osv-scanner 2.4.0

    A dependency has a published security issue, though this scan does not show that the project exposes it to an attacker.

    Policy reason: osv-structured-advisory · Execution scope: unknown

    Source: package-lock.json

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/build-desktop.yml:114

  • JavaScript analysis reported javascript.xray.serialize-environment · javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1_families-1

    This technical signal is not part of the shipped runtime behavior.

    Policy reason: javascript-xray-inert-tooling · Execution scope: tooling-only

    Source: vite.config.js:5

  • Dependency advisory GHSA-6j4f-fj2g-mc7p:pkg:1b256821002216bb3b207a3c applies · osv-scanner 2.4.0

    A dependency has a published security issue, though this scan does not show that the project exposes it to an attacker.

    Policy reason: osv-structured-advisory · Execution scope: unknown

    Source: package-lock.json

  • Dependency advisory GHSA-8xcm-r25x-g524:pkg:cc5804616c4fb4e83e60068a applies · osv-scanner 2.4.0

    A dependency has a published security issue, though this scan does not show that the project exposes it to an attacker.

    Policy reason: osv-structured-advisory · Execution scope: unknown

    Source: package-lock.json

  • Dependency advisory RUSTSEC-2026-0235:pkg:d039eb756756d5d8fe092ddd applies · osv-scanner 2.4.0

    A dependency has a published security issue, though this scan does not show that the project exposes it to an attacker.

    Policy reason: osv-structured-advisory · Execution scope: unknown

    Source: src-tauri/Cargo.lock

  • Dependency advisory GHSA-2jfj-6hjv-fm6j:pkg:175831eb9d2400b3cdc340b4 applies · osv-scanner 2.4.0

    A dependency has a published security issue, though this scan does not show that the project exposes it to an attacker.

    Policy reason: osv-structured-advisory · Execution scope: unknown

    Source: package-lock.json

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/build-android.yml:25

  • Dependency advisory GHSA-w293-vg96-wgc3:pkg:d43b5e923dc7ff1e776c4a60 applies · osv-scanner 2.4.0

    A dependency has a published security issue, though this scan does not show that the project exposes it to an attacker.

    Policy reason: osv-structured-advisory · Execution scope: unknown

    Source: package-lock.json

  • Dependency advisory RUSTSEC-2025-0100:pkg:bd8adf60c37242745cb633a0 applies · osv-scanner 2.4.0

    A dependency has a published security issue, though this scan does not show that the project exposes it to an attacker.

    Policy reason: osv-structured-advisory · Execution scope: unknown

    Source: src-tauri/Cargo.lock

  • Dependency advisory GHSA-r53p-7pc4-xj5r:pkg:1059646a53ed0e896cbf29be applies · osv-scanner 2.4.0

    A dependency has a published security issue, though this scan does not show that the project exposes it to an attacker.

    Policy reason: osv-structured-advisory · Execution scope: unknown

    Source: package-lock.json

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/actions/npm-install/action.yml:20

  • zizmor reported excessive-permissions · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/pre-release.yml:10

  • Dependency advisory RUSTSEC-2026-0285:pkg:08db2c0c1ca8ee1872b3d40f applies · osv-scanner 2.4.0

    A dependency has a published security issue, though this scan does not show that the project exposes it to an attacker.

    Policy reason: osv-structured-advisory · Execution scope: unknown

    Source: src-tauri/Cargo.lock

  • Dependency advisory RUSTSEC-2025-0075:pkg:3e15a087e2f1d00bbc8d944a applies · osv-scanner 2.4.0

    A dependency has a published security issue, though this scan does not show that the project exposes it to an attacker.

    Policy reason: osv-structured-advisory · Execution scope: unknown

    Source: src-tauri/Cargo.lock

  • Dependency advisory RUSTSEC-2025-0098:pkg:bc6e2fc910a7ca702c31e56a applies · osv-scanner 2.4.0

    A dependency has a published security issue, though this scan does not show that the project exposes it to an attacker.

    Policy reason: osv-structured-advisory · Execution scope: unknown

    Source: src-tauri/Cargo.lock

  • Dependency advisory GHSA-3wwx-pv8p-q78v:pkg:a08e866514b3f530ce58da45 applies · osv-scanner 2.4.0

    A dependency has a published security issue, though this scan does not show that the project exposes it to an attacker.

    Policy reason: osv-structured-advisory · Execution scope: unknown

    Source: package-lock.json

  • Dependency advisory GHSA-82fw-gwwq-j7x9:pkg:e73b265e463302d69e55909b applies · osv-scanner 2.4.0

    A dependency has a published security issue, though this scan does not show that the project exposes it to an attacker.

    Policy reason: osv-structured-advisory · Execution scope: unknown

    Source: package-lock.json

  • Dependency advisory RUSTSEC-2026-0293:pkg:8490244dc01980c032c6e3d6 applies · osv-scanner 2.4.0

    A dependency has a published security issue, though this scan does not show that the project exposes it to an attacker.

    Policy reason: osv-structured-advisory · Execution scope: unknown

    Source: src-tauri/Cargo.lock

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/build-ios.yml:112

  • zizmor reported artipacked · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/lint-and-typecheck.yml:23-24

  • Dependency advisory GHSA-qhr7-859c-m2p7:pkg:30aebd0885cdb30a5bdc22ef applies · osv-scanner 2.4.0

    A dependency has a published security issue, though this scan does not show that the project exposes it to an attacker.

    Policy reason: osv-structured-advisory · Execution scope: unknown

    Source: package-lock.json

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/build-ios.yml:47

  • Dependency advisory GHSA-p8p7-x288-28g6:pkg:e8e7ad0090121b0f387eaa27 applies · osv-scanner 2.4.0

    A dependency has a published security issue, though this scan does not show that the project exposes it to an attacker.

    Policy reason: osv-structured-advisory · Execution scope: unknown

    Source: package-lock.json

  • Dependency advisory GHSA-p88m-4jfj-68fv:pkg:0aa6e836b145749eb5c5bae2 applies · osv-scanner 2.4.0

    A dependency has a published security issue, though this scan does not show that the project exposes it to an attacker.

    Policy reason: osv-structured-advisory · Execution scope: unknown

    Source: package-lock.json

  • Dependency advisory GHSA-4992-7rv2-5pvq:pkg:787189633d8ba93446193680 applies · osv-scanner 2.4.0

    A dependency has a published security issue, though this scan does not show that the project exposes it to an attacker.

    Policy reason: osv-structured-advisory · Execution scope: unknown

    Source: package-lock.json

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/build-desktop.yml:132

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/release.yml:38

  • Dependency advisory GHSA-3xpg-4rpp-hhhm:pkg:a6f8bf7a6965562dac1ca61a applies · osv-scanner 2.4.0

    A dependency has a published security issue, though this scan does not show that the project exposes it to an attacker.

    Policy reason: osv-structured-advisory · Execution scope: unknown

    Source: package-lock.json

  • zizmor reported cache-poisoning · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/build-android.yml:66

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/bootstrap-ios.yml:29

  • zizmor reported unpinned-uses · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/build-ios.yml:100

  • Dependency advisory GHSA-v9p9-hfj2-hcw8:pkg:272b59ddefffdd1746f88817 applies · osv-scanner 2.4.0

    A dependency has a published security issue, though this scan does not show that the project exposes it to an attacker.

    Policy reason: osv-structured-advisory · Execution scope: unknown

    Source: package-lock.json

  • Dependency advisory GHSA-4mjr-xmp4-gh2g:pkg:71d1998e85e0b475b0071821 applies · osv-scanner 2.4.0

    A dependency has a published security issue, though this scan does not show that the project exposes it to an attacker.

    Policy reason: osv-structured-advisory · Execution scope: unknown

    Source: package-lock.json

  • Dependency advisory GHSA-82fw-gwwq-j7x9:pkg:00f885f51d12cc13a66b964f applies · osv-scanner 2.4.0

    A dependency has a published security issue, though this scan does not show that the project exposes it to an attacker.

    Policy reason: osv-structured-advisory · Execution scope: unknown

    Source: package-lock.json

  • zizmor reported template-injection · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/build-ios.yml:92

  • JavaScript analysis reported javascript.xray.data-exfiltration · javascript-analysis webcrack-2.16.0_js-x-ray-16.0.0_signatures-1_literals-1_families-1

    This technical signal is not part of the shipped runtime behavior.

    Policy reason: javascript-xray-inert-content · Execution scope: test-documentation-data

    Source: scripts/package-manager.test.js:3

  • Dependency advisory GHSA-g9mf-h72j-4rw9:pkg:2ae61459d96677abe6b160ba applies · osv-scanner 2.4.0

    A dependency has a published security issue, though this scan does not show that the project exposes it to an attacker.

    Policy reason: osv-structured-advisory · Execution scope: unknown

    Source: package-lock.json

  • zizmor reported template-injection · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/build-android.yml:96

  • zizmor reported cache-poisoning · zizmor 1.28.0

    The code has a known weakness, though this scan does not show that anyone can exploit it here.

    Policy reason: zizmor-known-workflow-rule · Execution scope: automation

    Source: .github/workflows/build-ios.yml:54

Contextual expected matches (11)

zizmor reported secrets-inherit

Expected behavior · high confidence

The pre-release pipeline passes the project's secrets to its own iOS build recipe, even though the iOS build is intentionally unsigned and does not use them. Only maintainers can start this pipeline, so no outsider can reach the secrets through it. Trimming the handoff would be tidier, not safer in any demonstrated way.

Technical evidence

Scanner reason: zizmor matched workflow-security rule secrets-inherit. The match applies to this repository.

Contextual assessment: Blanket secret inheritance into the local iOS build workflow, invoked from the pre-release pipeline that triggers only on maintainer-controlled version-tag pushes and manual dispatch. The iOS build is deliberately unsigned and uses no signing secrets, so the inheritance is broader than strictly necessary, but the called workflow is a local same-ref file, the caller's permissions are limited to repository contents, and no pull-request or fork path can reach these jobs. As a least-privilege hygiene matter the iOS leg could receive no secrets at all, but no untrusted trigger or exposure is demonstrated.

Impact: low · Exploitability: unlikely

Developer action: Optionally pass no secrets (or only the specific required ones) to the iOS build call, as a least-privilege tidy-up.

Scanner
zizmor 1.28.0
Rule
secrets-inherit
File role
tooling
Source
.github/workflows/pre-release.yml:65

Credential access and network transmission in one file

Expected behavior · high confidence

The scanner saw 'reads settings' and 'makes network requests' in the same test file and raised a flag. In reality the only setting read is a yes/no switch for turning on optional live tests, and the network requests just fetch public character cards from the same websites the app's search feature uses. No passwords or keys are touched, and these tests only run when a developer deliberately enables them.

Technical evidence

Scanner reason: A credential source and an outbound network operation were detected in the same file.

Contextual assessment: A heuristic flagged a test file that both reads an environment variable and performs network fetches. The environment variable is a single opt-in flag controlling whether live smoke tests run; no credential, token, or user secret is read anywhere in the file. The network calls go through a mock that substitutes plain platform fetch for the production Tauri HTTP wrapper, and the tests exercise public character-card search and download endpoints for providers the app legitimately integrates with. This is a standard live integration test behind an explicit opt-in, matching the project's stated character-discovery purpose; there is no credential source and no exfiltration path.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner
tavernkeeper 5
Rule
credential-exfiltration
File role
test
Source
src/lib/services/discovery/providers/providers.live.test.ts:12

zizmor reported secrets-inherit

Expected behavior · high confidence

The pre-release pipeline passes the project's signing secrets to its own Android build recipe so the app can be signed before publishing. Only maintainers can start this pipeline (by pushing a version tag or clicking run), so outside contributors cannot reach the secrets through it.

Technical evidence

Scanner reason: zizmor matched workflow-security rule secrets-inherit. The match applies to this repository.

Contextual assessment: Detailed technical wording was omitted by the public report safety filter.

Impact: low · Exploitability: unlikely

Developer action: none

Scanner
zizmor 1.28.0
Rule
secrets-inherit
File role
tooling
Source
.github/workflows/pre-release.yml:58

zizmor reported superfluous-actions

Expected behavior · high confidence

A linter noted that this step leans on an outside helper for something the build machine might do by itself. The step just attaches the finished iOS app file to a draft release page, matching the project's documented release process. There is no evidence of anything risky happening here.

Technical evidence

Scanner reason: zizmor matched workflow-security rule superfluous-actions. The match applies to this repository.

Contextual assessment: The candidate is an informational workflow-audit note that a third-party release-upload action duplicates capability the hosted runner already ships. The step only uploads an unsigned, locally built iOS package to a draft GitHub release behind an explicit publish input; the version and tag come from an internal resolution step, and the workflow runs only via workflow_call from trusted pipelines. No untrusted input path, secret flow, persistence, or obfuscation is present, so this is a lint-style style observation rather than a security exposure.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner
zizmor 1.28.0
Rule
superfluous-actions
File role
tooling
Source
.github/workflows/build-ios.yml:112

zizmor reported superfluous-actions

Expected behavior · high confidence

A linter noted the release step uses a helper that roughly overlaps with what the build machine can already do. This is a style note about the release recipe, not a security problem.

Technical evidence

Scanner reason: zizmor matched workflow-security rule superfluous-actions. The match applies to this repository.

Contextual assessment: The scanner flags the release-creation step as duplicating functionality already available on the runner. This is an informational workflow-hygiene finding about using a third-party action where a built-in could serve. The action is pinned to a major version and used for its documented purpose of creating a draft GitHub release with assets, which matches the release pipeline's stated function. No secret flow, code execution, or attacker-controlled input beyond normal release metadata is shown.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner
zizmor 1.28.0
Rule
superfluous-actions
File role
tooling
Source
.github/workflows/release.yml:38

zizmor reported secrets-inherit

Expected behavior · high confidence

The iOS build gets the project's secrets handed to it even though it does not need them, since iOS builds are intentionally unsigned. That is slightly generous, but the builds only run from maintainers' own actions, so no outsider can reach the secrets this way. Tightening it would be nice-to-have, not urgent.

Technical evidence

Scanner reason: zizmor matched workflow-security rule secrets-inherit. The match applies to this repository.

Contextual assessment: Identical blanket-secret-inheritance pattern into the local iOS build workflow. The iOS leg uses no signing secrets at all (it deliberately produces an unsigned package), so the inheritance is broader than strictly needed, but the caller's triggers exclude pull requests and fork input, and the called workflow is a local file at the same commit. The audit rule's concern — secrets reaching a workflow an untrusted actor can influence — has no demonstrated path here. This is at most a least-privilege hygiene note, not a demonstrated exposure.

Impact: low · Exploitability: unlikely

Developer action: Optionally pass only the specific secrets each build workflow needs instead of inheriting all of them, as a least-privilege hardening measure.

Scanner
zizmor 1.28.0
Rule
secrets-inherit
File role
tooling
Source
.github/workflows/ci.yml:59

zizmor reported secrets-inherit

Expected behavior · high confidence

The build file passes the project's signing secrets to its own Android build recipe, which needs them to sign the app it produces. These builds only start from maintainers' commits, a weekly timer, or a manual button, so an outside contributor cannot use this route to reach the secrets.

Technical evidence

Scanner reason: zizmor matched workflow-security rule secrets-inherit. The match applies to this repository.

Contextual assessment: Same pattern as the sibling call sites: blanket secret inheritance into a local, same-commit reusable Android build workflow. The Android build genuinely requires the keystore and key secrets to sign the artifacts it uploads, so the inheritance is proportionate to the stated purpose. The caller is restricted to default-branch pushes on dependency/CI paths, scheduled runs, and manual dispatch, with no pull-request trigger, so no untrusted or fork-controlled input can reach the inherited secrets through this workflow. Exposure is not demonstrated.

Impact: low · Exploitability: unlikely

Developer action: none

Scanner
zizmor 1.28.0
Rule
secrets-inherit
File role
tooling
Source
.github/workflows/ci.yml:66

zizmor reported superfluous-actions

Expected behavior · high confidence

An automated linter left a note saying this step uses an outside helper that the build machine could perhaps do without. The step simply attaches the finished Android app file to a draft release page, which is exactly what this project's release process is supposed to do. Nothing here sends data anywhere unexpected or handles secrets improperly.

Technical evidence

Scanner reason: zizmor matched workflow-security rule superfluous-actions. The match applies to this repository.

Contextual assessment: The flagged step is an informational audit note that a third-party release-upload action may duplicate functionality the hosted runner already provides (the gh command-line tool). The step only attaches a locally built, already-signed Android package to a draft GitHub release, gated behind an explicit publish input, with the tag and version values sourced from an internal version-resolution step. The workflow is invoked only through workflow_call from trusted CI and release pipelines, so no untrusted input reaches this step, no secrets are passed to it, and there is no exfiltration, persistence, or obfuscation in the data flow. Using an external action instead of the runner's built-in CLI is a style choice, not a demonstrated security exposure.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner
zizmor 1.28.0
Rule
superfluous-actions
File role
tooling
Source
.github/workflows/build-android.yml:149

zizmor reported secrets-inherit

Expected behavior · high confidence

This file hands the project's stored secrets to its own build recipes so they can sign app packages. A scanner flags that handoff as broad, but these builds only run from maintainers' own commits, a weekly timer, or a manual button — never from a stranger's pull request — and the recipes live in the same repository. There is no shown way for an outsider to reach those secrets through this file.

Technical evidence

Scanner reason: zizmor matched workflow-security rule secrets-inherit. The match applies to this repository.

Contextual assessment: The workflow forwards all repository secrets to a reusable build workflow defined in the same repository at the same commit. The audit rule flags blanket secret inheritance because it widens exposure if a called workflow were ever reachable from untrusted input. Here the caller runs only on a weekly schedule, pushes to the default branch restricted to dependency and CI-related paths, and manual dispatch; it never runs on pull requests, and fork contributions cannot modify or trigger these jobs. The called desktop build workflow is local, and the Android leg of the same pipeline legitimately consumes the signing secrets to produce signed artifacts, which matches the project's stated release purpose. No untrusted trigger or attacker-controlled path to the inherited secrets is demonstrated.

Impact: low · Exploitability: unlikely

Developer action: none

Scanner
zizmor 1.28.0
Rule
secrets-inherit
File role
tooling
Source
.github/workflows/ci.yml:52

zizmor reported superfluous-actions

Expected behavior · high confidence

A linter note says this step uses an outside helper for something the build machine can already do. The step just creates a draft pre-release entry on the project's release page using the version number worked out by an earlier step. Nothing risky is happening.

Technical evidence

Scanner reason: zizmor matched workflow-security rule superfluous-actions. The match applies to this repository.

Contextual assessment: An informational audit note that a third-party release-creation action duplicates capability the hosted runner provides. The step creates or reuses a draft pre-release using only values from the internal guard step (version, release state) and the triggering commit, and runs in a maintainer-only workflow. No untrusted input reaches it, no secrets are exposed by it, and the draft-then-publish sequencing is consistent with the project's documented release process. Using an external action versus the runner's built-in tooling is a style consideration, not a security exposure.

Impact: none · Exploitability: unlikely

Developer action: none

Scanner
zizmor 1.28.0
Rule
superfluous-actions
File role
tooling
Source
.github/workflows/pre-release.yml:39

zizmor reported secrets-inherit

Expected behavior · high confidence

The pre-release pipeline hands the project's secrets to its own desktop build recipe. Only maintainers can start it, and the recipe lives in the same repository, so there is no shown way for an outsider to use this route to the secrets.

Technical evidence

Scanner reason: zizmor matched workflow-security rule secrets-inherit. The match applies to this repository.

Contextual assessment: Blanket secret inheritance into the local desktop build workflow from a workflow that triggers only on maintainer-controlled tag pushes and manual dispatch. The called workflow is a same-repository file, the caller's permission scope is limited to repository contents, and the release-guard step runs before any release interaction. As with the sibling call sites, the audit rule's generic concern about secrets reaching an attacker-influenced workflow has no demonstrated trigger path here.

Impact: low · Exploitability: unlikely

Developer action: none

Scanner
zizmor 1.28.0
Rule
secrets-inherit
File role
tooling
Source
.github/workflows/pre-release.yml:50

Related contextual observations

Release-body fallback text is applied on every run, including draft re-runs

low risk · high confidence

A logic slip means the workflow always writes its placeholder release notes, even when it is supposed to leave existing draft notes alone. Only release notes are affected, and only for maintainers.

Technical assessment

Because the intermediate empty-string branch is falsy, the pseudo-ternary always resolves to the fallback body text. On a re-run over an existing draft release, the release step will set that static text rather than leaving the notes as the workflow comment intends, potentially replacing maintainer-entered draft notes. This is confined to release-note content in CI and has no attacker-controlled path or user-facing security effect.

Impact: low · Exploitability: unlikely

Developer action: Use an explicit conditional to produce an empty body value when the release is in draft state.

Sources:

Coverage and limitations

Inventory
983 files · 10988769 bytes
Contextual coverage
121 of 121 candidates assessed

JavaScript coverage

Status
Incomplete
Candidates
523 files · 3672435 bytes
X-Ray review families
5 warning occurrences compacted to 5 evidence-preserving review families
Representations
523 raw · 23 decoded · 0 normalized · 0 bundle modules
Stage scans
523 raw signatures · 77 raw AST · 523 raw OpenGrep · 23 derived signatures · 0 derived AST · 23 derived OpenGrep

Unresolved JavaScript stages

Tools

Limitations

Technical scan identity
Full commit
1aa68321c528c89c46187e29398998ba8bcb433f
Completed
History depth
11 commits
Method
Deterministic evidence with contextual review
Reviewer
nano-gpt.com · zai-org/glm-latest
Scanner
0.1.0
Scanner policy
5
Rule catalog
2
Contextual policy
5
Ecosystem context
sillytavern-community-v1
Prompt
contextual-review-v7
Assessment schema
contextual-assessment-v2
Review provenance
9 fresh / 0 reused groups · 17 fresh / 0 reused candidates
Review source reports
none
Evidence triage
104 deterministic / 17 contextual candidates · 9 contextual / 28 total behavior cases
Model budget
3 model calls · 9 / 12 fresh cases · 95434 / 200000 estimated input · 72371 / 250000 actual input · 10944 / 40000 output tokens
Review batching
3 model calls · up to 5 groups and 10 candidates per call · 0 retry calls · 0 over-budget singleton calls
Review usage
72371 input · 10944 output · 1359 cache read · 4042 reasoning tokens
Report
45f64b6a8b4bfa442209ba110f04d709d16dd650d6221e7fb78a384521232e00