Repository navigation
security: eliminate warning-class output from central Security Scan #689
Description
Evidence
Current-head Naruon PR #1206 run 30637062852 completed with zero Medium-or-higher findings, but the central Security Scan log still contains strict-contract warning/fatal-class output:
- Trivy:
[pip] Unable to find python site-packages directory. License detection is skipped. - OSV Scanner v2.3.8:
--outputis deprecated in favor of--output-filefor base/head scans. - OSV Reporter v2.3.8:
--outputis deprecated in favor of--output-files. - SARIF upload: local git attribution first emits
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
- Replace deprecated OSV flags with their v2 forms.
- Run Trivy with its supported quiet/log-suppression input while retaining required SARIF output and the explicit parser that prints every Medium+ finding.
- Materialize and verify the PR synthetic merge object before SARIF upload so attribution does not emit handled
fataloutput. - Add regression assertions and validate the reusable workflow with actionlint plus focused/full tests.
- Prove the change on a downstream current-head canary log.
Activity
seonghobae commentedon Aug 1, 2026
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.
seonghobae commentedon Aug 1, 2026
Implemented in #690 at current head
69ac38fe53ab7ba831c5bf7460373bab8e54ec79.Live required-workflow canary: Security Scan run 30679412515.
Verified synthetic merge attribution commit before OSV SARIF upload.INPUT_HIDE_PROGRESS=true, scanners remainvuln,secret,misconfig, job successfatal: bad object; the only matched historical phrases were quoted in the PR descriptionLocal verification remains 796/796 tests, 100% statement coverage, 100% docstrings, plus 0 OSV/Trivy/Gitleaks findings.
seonghobae commentedon Sep 11, 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.seonghobae commentedon Sep 11, 2026
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.seonghobae commentedon Sep 13, 2026
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.seonghobae commentedon Sep 13, 2026
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.