Repository navigation
security: eliminate warning-class output from central Security Scan #689
Description
Activity
Codex started the central warning-free Security Scan remediation on 2026-08-01 10:45 KST from exact downstream evidence in ContextualWisdomLab/naruon#1206. Project status: In Progress; Phase: Ops; Component: dot-github.
Implemented in #690 at current head
69ac38fe53ab7ba831c5bf7460373bab8e54ec79.Live required-workflow canary: Security Scan run 30679412515.
- OSV base/head: 0 findings / 0 findings
- exact receipt:
Verified synthetic merge attribution commit before OSV SARIF upload. - OSV SARIF upload: success; no upload runtime failures
- Trivy:
INPUT_HIDE_PROGRESS=true, scanners remainvuln,secret,misconfig, job success - runtime search: no deprecated-output warning, pip license warning, or
fatal: bad object; the only matched historical phrases were quoted in the PR description - current-head pip-audit, dependency-review, OSV, Trivy, Bandit, Semgrep, CodeQL, and Gitleaks are green
Local verification remains 796/796 tests, 100% statement coverage, 100% docstrings, plus 0 OSV/Trivy/Gitleaks findings.
- added
on Aug 22, 2026 Fresh downstream reproduction confirms the SARIF attribution warning in this issue is still live on the current central Security Scan. LifeOS #247 exact
48087da1d1d5031374eacc12228d1a96f55359c0, Security run34643498057, Trivy job103408671264verified the exact contributor head, thengithub/codeql-action/upload-sarifemittedfatal: bad object b01389498606377f3d6d6d453a5cd6e383988a03, fell back to server-side base resolution, and uploaded successfully.This matches #689's existing acceptance to materialize/verify the PR synthetic merge object before SARIF upload rather than suppressing handled fatal output. LifeOS issue #278 should therefore remain a downstream canary/consumer-tracking issue, not a competing implementation owner. Please preserve exact contributor-head analysis, bounded provenance materialization,
persist-credentials: false, and existing scanner gates; no broad history fetch or stderr filtering.LifeOS-local AppGuardrail now has a concrete bounded implementation of the same provenance principle, without copying the central Security workflow. Draft LifeOS #279 first produced reality RED at
ebedd2fc53a29070ce2067d42b53d5a297d9e605/ run34648222331/ job103424010024, then added a same-repository PR-only depth-1 fetch ofrefs/pull/<n>/merge, verifiesFETCH_HEAD == github.shaand the commit object, never checks out the merge commit, and preserves contributor-head SARIFref/sha.Exact local candidate
e4a7ddcdf55a02ccbebd70f7654a529578b27db2, run34649865068/ job103429245032, is GREEN: 26 suites / 78 tests, typecheck, build andgit diff --check; temporary verifier is retired at76e352ed063bcbf48be6061e2f0bf9edaa47ece7. The local runtime-warning canary remains pending until its parent #276 integrates and #279 can retarget tomainnormally. Central #689 remains the implementation owner for the organization Security Scan; please retain its own current-head/synthetic-merge identity verification rather than consuming mutable LifeOS source.Fresh Naruon downstream evidence: #1674 exact
24e6e80bc7341cfd4fc3a1b0af09a21f7b6eafe1, central Security Scan run34733739231, trivy-fs job103661531163still emits handledfatal: bad object 7c440247fda58394c93616d7c5ab4a9482d0656fduring SARIF attribution before server-side fallback, while SARIF upload later succeeds. This is the same warning/fatal-class log-contract defect tracked here; no consumer workaround was added.Fresh Naruon canary evidence from PR #1486 exact head
b85be537feab5bcba532465da7f8ff5618b2ff25: repo-local Bandit run34748443125, job103700517733, failed only atgithub/codeql-action/upload-sarif@f205ea1c...; the precedingbandit -r backend/ ... -f sarifstep succeeded and wrotebandit-results.sarif. The upload log reachesUploading resultsat 08:46:25Z and then exits into post-job cleanup around 08:46:48Z without a surfaced API diagnostic. Token permissions showSecurityEvents: write. This is therefore not a Bandit finding receipt and should not be repaired by weakening/ignoring the upload gate. The same job also emitted two avoidable Bandit warning-class lines because# nosec B608remained on 0011 SQL constants although Bandit reported no corresponding failed test; Naruon removed only those stale suppressions in ordinary descendant090a8d700911bbe3f99dd2dd9780060056cfdcb6and will use the fresh run as a canary. Please retain #689 ownership of SARIF upload/log-contract remediation and correlate this silent upload failure with the synthetic-merge attribution work already tracked here.
Evidence
Current-head Naruon PR #1206 run
30637062852completed with zero Medium-or-higher findings, but the centralSecurity Scanlog still contains strict-contract warning/fatal-class output:[pip] Unable to find python site-packages directory. License detection is skipped.--outputis deprecated in favor of--output-filefor base/head scans.--outputis deprecated in favor of--output-files.fatal: bad object <synthetic merge sha>before falling back to server-side calculation.The actual scan evidence was clean: Trivy 0 CRITICAL/HIGH/MEDIUM, dependency-review 0 moderate+, OSV reporter SARIF 0, open code-scanning alerts 0. This issue tracks log-contract remediation rather than a package/CVE finding.
Acceptance
fataloutput.