[Nic-dorman]

The advisory fixes this audit depends on have all landed: Rust lockfiles (#366), gRPC (#380), npm (#381), SwiftNIO floors (#383). This PR now changes only the four files below.

Summary

A scheduled dependency-advisory audit covering every SDK in the repo (V2-1582 §3). Until now only Rust (cargo audit) and Go (main-only, continue-on-error govulncheck) were scanned, and only when someone touched those paths.

When it runs: Monday + Wednesday at 05:17 UTC, ahead of the release-decision meetings; on any PR or main push that changes a manifest or lockfile; and on demand (workflow_dispatch).

Job	Covers	Fails on
cargo audit ×4	antd, antd-rust, ffi/rust, ffi/node Cargo.lock (honours .cargo/audit.toml)	RustSec vulnerabilities (warnings don't fail)
govulncheck	antd-go	vulnerabilities in code antd-go actually calls
npm audit ×2	antd-js, ffi/node package-lock.json	any advisory, dev included
NuGet audit	antd-csharp + ffi/csharp, transitive	any advisory; Examples report-only
resolve ×6	generates the lockfiles the SDKs deliberately don't commit: Dart (pub get), PHP (composer update --no-install), Ruby (bundle lock), Python (uv pip compile; antd-py, antd-mcp, ant-dev), Gradle (Java, Kotlin, Android, via an init script) and Swift (package resolve)	resolution errors
osv-scanner	every committed and generated lockfile	any finding outside examples/ not accepted in osv-scanner.toml

osv-scanner also reads GitHub advisories that RustSec doesn't carry. That's how the openpgp/openssl findings fixed in #366 were found while cargo audit reported 0.

Policy

• Blocking: everything except examples/, dev and test dependencies included. Most ecosystems can't separate dev from runtime in a lockfile, and dev tooling runs in CI next to publishing credentials.

• Report-only: examples/ / Examples/ (web3j's jackson/netty/bouncycastle in the Java and Kotlin examples; Newtonsoft.Json in the C# examples). Shown in the summary with a warning, never fails.

• Accepted findings live in osv-scanner.toml, each with a reason, tracking issue and ignoreUntil date. When the date passes the finding fails the run again, which forces a re-review. The initial list (14 entries):

  IDs	Until	Why
  RUSTSEC-2026-0367/0368/0369 (zip)	2026-11-16	extract() never called; mirrors ci(deps): ignore zip extract() advisories until ant-core moves to zip 9 (RUSTSEC-2026-0367, -0368, -0369) #372; V2-1634
  RUSTSEC-2026-0253 (lru)	2027-01-18	fix needs lru 0.18 via alloy-provider upstream
  8 RustSec "unmaintained" notices (incl. basic-toml, build-time only via uniffi)	2027-01-18	informational; cargo audit only warns; osv reports them as findings
  GO-2026-5932 (x/crypto openpgp)	2027-01-18	no fix exists; not imported
  EEF-CVE-2026-43966 (cowlib via gun; covers its alias GHSA-w4f7-4cxr-rv3c)	2026-12-14	unreachable per fix(antd-elixir): move to grpc 1.0.5 past the critical Hex advisory, commit mix.lock (V2-1574) #375 review; V2-1637

• Ecosystems without a committed lockfile are scanned as resolved on the day, so a run can go red with no code change. That's what the schedule is for.

• Not scanned: Lua, Zig, C++ (no usable advisory database).

Files

• .github/workflows/security-audit.yml: the workflow
• osv-scanner.toml: accepted findings (reason, tracking issue, ignoreUntil for each)
• .github/security-audit/lock-all.init.gradle: Gradle dependency locking from outside the build (no build-file changes); -PauditConfigurations limits ffi/android to releaseRuntimeClasspath
• .github/security-audit/collect-lockfiles.sh: copies each resolve job's generated lockfiles into the artifact

Swift

Swift resolves in its own job in the official swift:6.4 image, not setup-swift, which lags behind Swift releases. The toolchain decides what gets resolved: the first run used Swift 6.0, resolved swift-nio 2.97.1 / -http2 1.42.0 / -extras 1.33.0 and correctly reported 5 SwiftNIO advisories whose fixes need Swift 6.1. That finding led to #383 (antd-swift now requires those fixes, Swift 6.1+). On 6.4 it resolves 2.104.0 / 1.46.0 / 1.35.1.

Output

The job summary carries the osv table for the blocking pass, a collapsed list of accepted findings with their reasons, and the examples report. Blocking results are also uploaded as SARIF (category osv-scanner), so they appear in the Security tab and on PRs. Scanner versions are pinned (cargo-audit 0.22.2, govulncheck v1.9.0, osv-scanner 2.7.0 with its SHA-256 checked, uv 0.13.3).

Test plan

• Full resolve + scan pipeline run locally on a scratch worktree of this branch (Dart, PHP, Ruby, Python, Gradle Java + Kotlin; Swift and Android are CI-only):
  • blocking pass: exit 0, all accepted findings filtered with their reasons printed
  • examples pass: 114 advisories across 16 packages, all web3j's dependencies in the Java/Kotlin examples, report-only
  • composer's own audit: no PHP advisories; pip-audit-equivalent: Python clean; Dart, Ruby clean
• --x-exclude form checked: g:**/examples works, g:**/examples/** silently doesn't
• actionlint 1.7.12 (the version lint-workflows.yml uses): clean
• Fixes from this PR's own runs: (1) exit codes are now captured with || code=$?, because Actions' bash -e ended the first scan step before it wrote the summary; (2) Swift resolves under 6.4 (above); (3) safe.directory for git inside the Swift container
• Run at 49b21c2: 40 checks passed, 2 skipped (Go race/security, which run only on pushes to main). Blocking scan passed, SARIF upload accepted, examples report ran; 0 open osv-scanner code-scanning alerts on the PR
• Run after merging main (fix(antd-go, antd-java, antd-kotlin): bump gRPC (and Kotlin protobuf) past open advisories #380, fix(antd-js, ffi/node): clear npm dev-dependency advisories (vitest 4.1.12, tsup 9, js-yaml) #381, fix(antd-swift): require SwiftNIO releases with the security fixes (Swift 6.1+) #383) caught a newly published notice, RUSTSEC-2026-0374 (basic-toml unmaintained, build-time only via uniffi), present on main too. Accepted as above
• Run with the updated osv-scanner.toml (7dcc4b4): 17/17 checks pass, including the blocking scan, SARIF upload and examples report
• After merge: one workflow_dispatch run on main to seed the Security tab

Refs V2-1582.

🤖 Generated with Claude Code

[github-advanced-security]

You are seeing this message because GitHub Code Scanning has recently been set up for this repository, or this pull request contains the workflow file for the Code Scanning tool.

What Enabling Code Scanning Means:

• The 'Security' tab will display more code scanning analysis results (e.g., for the default branch).
• Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results.
• You will be able to see the analysis results for the pull request's branch on this overview once the scans have completed and the checks have passed.

For more information about GitHub Code Scanning, check out the documentation.

[dirvine]

REQUEST_CHANGES — two P2 false-negative defects

Reviewed all four added files (596 lines) in WithAutonomi/ant-sdk at 7dcc4b4cc1a2508723de0344929039c98e1ddcad. The exact-head CI is green, but the following gaps can produce a successful audit without the claimed coverage.

1. NuGet command errors can pass as a clean audit (.github/workflows/security-audit.yml:191–199). Calling check through || disables Bash errexit inside the function. Restore and package-list failures are lost; the final negated grep can return success. The inline finding includes the reproduced exit codes and the minimum fix.
2. The standalone FFI Kotlin SDK is never resolved or scanned (.github/workflows/security-audit.yml:288–291). It has its own Gradle build and dependencies, but no committed/generated lockfile. Neither the other Gradle roots nor recursive OSV scanning resolves it. This is a coverage defect, not a claim of a known vulnerability in its current dependencies.

Verified evidence

• Exact-head security workflow: 15/15 jobs succeeded; the PR rollup contains 17 successful checks. Inspected NuGet, Gradle, Swift and OSV logs, including actual scanned lockfile paths.
• Ran the actual NuGet shell block with controlled dotnet responses, changing only its scratch-output path. Clean output exits 0; vulnerable output exits 1; restore failure (17), package-list failure (23), and both failing all incorrectly exit 0. A scratch-only control with explicit || return $? guards fails all three error cases. These are shell-control tests under macOS Bash 3.2, not a claim that hosted NuGet failed.
• Checked each Gradle root's settings.gradle.kts: none of the three invoked builds includes ffi/kotlin. The pinned OSV 2.7.0 scanner returns 128, No package sources found, when recursively scanning that directory with --offline --no-ignore; exact-head hosted logs also show no FFI Kotlin lockfile.
• actionlint 1.7.12, Bash syntax, and git diff --check passed. Local actionlint ran without shellcheck; hosted workflow lint is separately green.
• Collector fixture passed for ignored/untracked lockfiles, six recognised lockfile types and paths with spaces; excluded build/cache paths stayed excluded and an empty selection failed.
• A separate seeded OSV fixture confirmed that a future ignoreUntil suppresses findings (exit 0) and an expired date restores them (exit 1). The fixture is not a repository dependency finding.

Panel coverage and adjudication

4/6 reviewed — partial panel; 2/3 named models. GLM 5.3 (z-ai/glm-5.3) and Qwen 3.8 (qwen38-27b) each completed correctness and adversarial reviews. All four substantive opinions request changes. Qwen confirms the NuGet defect; GLM confirms both defects. Both findings were checked independently against source and execution evidence. There is no unresolved material disagreement among the responding reviewers.

Missing: DS4 correctness and adversarial. DS4 (deepseek-v4-flash) produced no usable correctness verdict: the original and one narrowed same-model retry both ended at the 8,192-token cap (finish_reason=length). Its subsequently launched focused adversarial role was stopped after that recovery failed; it is not counted as a review. No fallback was counted as DS4. Full-panel consensus is not claimed. This verdict uses the permitted partial-panel quorum, not a claim that all six roles completed.

Tag-pinned Actions, temporary-file hardening and speculative SARIF robustness concerns are not promoted to blockers. A failed/missing SARIF upload would fail that job, not silently prove a clean scan. The FFI Python package has no runtime dependencies, so it is not asserted as a third runtime-coverage gap.

Scope limits / next steps

I did not rerun all ecosystem resolvers or the full SDK build matrix locally; the successful hosted run is the integration evidence. No repository files were changed. Fix the NuGet status propagation, add FFI Kotlin lockfile generation and confirm its runtime/test dependencies appear in the blocking scan. The planned post-merge workflow_dispatch run on main remains unrun. No merge or deployment was performed.

[dirvine]

[P2] Propagate restore and package-list errors from the NuGet check

check is called as the left side of || at line 199, so Bash disables errexit throughout the function. A failed restore or dotnet list ... | tee therefore falls through to the final negated grep. If the error output does not contain the vulnerable-package heading, that grep returns success and all four blocking projects can pass without a successful audit. I executed this exact run block with controlled dotnet responses: restore exit 17, listing exit 23, and both failing each produced workflow exit 0; clean and advisory-output controls produced 0 and 1 respectively. Explicitly propagate both restore and pipeline failures (for example, || return $?) before checking advisory output, and add regression tests for these failure paths. A scratch-only control with those guards failed all three error cases as expected. These are shell-control probes, not a claim that the hosted NuGet run failed.

[dirvine]

[P2] Generate a lockfile for the standalone FFI Kotlin SDK

The Gradle job resolves antd-java, antd-kotlin and ffi/android, but never ffi/kotlin. The separate ffi/kotlin/AntFfi/build.gradle.kts project declares JVM JNA 5.17.0, coroutines 1.8.1 and test dependencies, has no committed Gradle lockfile, and is not included by any of those three Gradle builds. The collector only copies lockfiles; it cannot resolve this manifest. Exact-head OSV job logs contain no ffi/kotlin lockfile, and running the pinned OSV 2.7.0 scanner recursively over that directory with --no-ignore --offline returns 128, “No package sources found”. Thus a dependency advisory confined to that SDK will not affect this supposedly every-SDK blocking audit. Add standalone FFI Kotlin dependency resolution with a suitable Gradle runtime, upload its generated lockfile, and verify its runtime/test packages appear in the blocking scan. This is a coverage defect, not a claim that its current dependencies have a known vulnerability.

[dirvine]

Re-review: APPROVE (provisional: partial review panel, not full consensus)

Reviewed the complete current PR (six added files) at c277b00c2326801036133bfd3b1edfbe59d0b082, including the changes since 7dcc4b4cc1a2508723de0344929039c98e1ddcad. Both findings from review 5584736686 are fixed. No remaining demonstrated blocker was found in this scope.

Previous findings

• P2 NuGet fail-open: fixed. .github/security-audit/nuget-audit.sh:44–56 explicitly handles restore/list failures. The blocking-project loop at lines 64–72 converts both operational errors and vulnerability reports into a nonzero job result. Report-only failures still warn without blocking, as intended. The production script is called directly by the workflow and the regression tests.
• P2 standalone Kotlin FFI omission: fixed. .github/workflows/security-audit.yml:276–284 resolves the separate ffi/kotlin Gradle root and requires all four expected Gradle lockfiles to be non-empty. The scanner coverage check also requires ffi/kotlin/AntFfi/gradle.lockfile. Exact-head CI generated that file and OSV scanned its 36 packages. I downloaded the exact-head resolved-gradle artifact (12262889296) and verified the lockfile contains JNA 5.17.0 and coroutines 1.8.1.

Verification

• Hosted security-audit run 39420175946: all 15 jobs succeeded at the reviewed head. The OSV log accounts for all 19 expected SDK lockfiles.
• Local: all 8 repository regression cases passed; 13 additional NuGet control-flow cases passed; 2 mutation checks proved the regressions reject removal of either failure-propagation branch; 3 coverage-guard cases passed, including missing/empty Kotlin FFI lockfiles. Bash syntax and actionlint passed (actionlint shellcheck integration disabled).
• Evidence limit: local NuGet failure-path tests use a stub executable, not a live vulnerable NuGet package. Hosted CI supplies real .NET/Gradle/OSV execution. These are separate forms of evidence, not interchangeable claims of end-to-end vulnerability injection.

Panel: 5/6 roles complete

• z-ai/glm-5.3 — correctness: APPROVE; adversarial: APPROVE.
• qwen38-27b — correctness: APPROVE; adversarial: APPROVE.
• deepseek-v4-flash — correctness: APPROVE; adversarial: unavailable after bounded attempts (Timed out waiting for the model lock queue; output truncated (finish_reason=length)).

The completed roles agree on approval. Missing roles are not agreement. This is a provisional partial-panel result; no substitute model or historical vote is counted.

Non-blocking watch-out

NuGet vulnerability detection still depends on the current English dotnet list output phrase. A structured-output check or a fixture captured from a vulnerable package would reduce that format risk. No failure was demonstrated with the configured .NET 8 SDK, so this is follow-up hardening, not a new blocker.

Review only. No merge or deployment performed.