mirror of
https://github.com/semantica-agi/semantica.git
synced 2026-09-04 04:01:07 +00:00
Mohd Kaif
2eab7ab876
* fix(ci): drop --ignore from Safety check, filter accepted CVEs in jq instead The follow-up to #1370: adding `--ignore SFTY-20260120-40557` to the `safety check` invocation reintroduced the exact crash #1131/#1157 had just fixed - "Unhandled exception happened: 'cuda-toolkit'" - but only once Safety actually has a live vulnerability match to apply the ignore against (the plain, un-ignored scan against the same requirements-ci.txt had already succeeded and correctly reported that same match on main, per the run right before this one). I couldn't reproduce this locally: my local Safety installation doesn't surface the live cuda-toolkit CVE match at all (its open-source vulnerability DB appears to lag CI's), so --ignore never had a real match to crash on in my testing. That's on me - I should have caught that my "0 vulnerabilities" local result meant the DB hadn't even seen the finding yet, not that the fix worked. Since I can't safely iterate against Safety's own --ignore path without live-DB access, this moves the "should we still fail on ID X" decision out of Safety entirely: run the plain scan (the one path an actual CI run has now proven doesn't crash), then filter the accepted vulnerability ID out of the report ourselves in jq before counting/printing. Verified the jq expression directly against a synthetic report shaped like a real one (id present + one other unrelated id): filters exactly the intended entry, and - as a bonus - iterating over a null/missing "vulnerabilities" key with jq now raises inside jq the way the existing guard comment always assumed it did, rather than silently coming back as 0. * fix(ci): apply the accepted-CVE exclusion list to the PR comment too Qodo caught a real gap on this PR: the jq-based exclusion I added only covers the CI gate (the VULNS count and the failure-path detail print). The "Comment PR with Security Results" step reads safety-report.json independently in its own JS, with no filtering at all, so a PR touching only the accepted cuda-toolkit CVE would still get a comment saying "Found 1" even though the gate itself correctly treats it as non-actionable and passes. Export IGNORED_VULN_IDS via $GITHUB_ENV from the shell step so the JS step can read the same list, and filter data.vulnerabilities there before rendering - with a footnote naming what was excluded and why, so the comment stays transparent about the accepted finding rather than just silently hiding it. Verified the JS logic standalone against two synthetic reports: one with the accepted CVE plus an unrelated real one (shows only the real one, plus the footnote), and one with only the accepted CVE (shows "No findings" plus the footnote, rather than misleadingly looking identical to a clean scan with no explanation).