ci(security): Trivy correctness fixes and a complete-coverage report - #230
Conversation
…once Ports three review findings from constructorfabric/insight#2002 to this repo, so the two scanning setups do not drift. The repo-root `.trivyignore` documented on the gate job was never read. Trivy resolves the default ignore file relative to the working directory, and the containers had no `-w`, so waivers were looked for in the image's own cwd. Verified: with a waiver present the gate now honors it where it previously did not, and with no `.trivyignore` at all — the current state of this repo — the gate is unaffected. `--ignorefile` is deliberately not used: Trivy exits FATAL when the named file is absent, which would break every run until someone adds a waiver. SARIF upload steps ran under `always()` against files a failed scan never wrote, producing a second error pointing at Code Scanning instead of the scan that actually broke. A `hashFiles` guard drops that. Both report passes scanned the same target twice to produce two formats. The scan now runs once to JSON and `trivy convert` derives the rest — SARIF for the repository pass, and both the log table and SARIF for the image scan. Output is identical: 31 results for the repository pass and 37 for the image, matching what main currently reports. Signed-off-by: Grigoriy Gogin <Grigoriy.Gogin@constructor.tech>
📝 WalkthroughWalkthroughTrivy image and filesystem scans now generate JSON reports for table and SARIF conversion, with report-only critical findings and guarded SARIF uploads. TruffleHog reports findings without failing jobs and adds GitHub API scanning. Semgrep now runs on pushes to ChangesSecurity workflow changes
Estimated code review effort: 3 (Moderate) | ~25 minutes Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
…objects
Widens what the scans report. Nothing here changes what blocks a merge, and no
finding is fixed — this is about the report being complete.
Four gaps, each measured on this repository:
- The repository report pass filtered to HIGH/MEDIUM/LOW while the gate, which
covers CRITICAL, only prints a table. A CRITICAL therefore failed the check
and never became an alert. CRITICAL is now in the report severities too;
reporting and blocking are separate concerns.
- Dev dependencies were excluded by Trivy's pnpm default. They do not ship, but
a compromised one executes on the runner and can alter the bundle. Including
them takes the repository pass from 29 to 37 vulnerabilities.
- The image scan filtered to CRITICAL/HIGH, hiding 70 of 107 findings in the
image that actually ships.
- Secrets were only scanned through git refs. A new report-only job uses the
GitHub API source, which additionally sees pull request and issue comments,
wikis, and objects orphaned by a force push or a deleted branch — all
unreachable from any ref and therefore invisible to the git scan. Measured:
~8600 chunks against the git scan's ~6900, ten seconds. Off pull requests and
non-blocking, since it depends on API availability.
semgrep.yml gains a push trigger for main. Without it Code Scanning holds no SAST
data for the default branch between a merge and the 03:27 nightly run, so a merge
that introduces a finding stays invisible until the next morning.
Deliberately not added: extra Semgrep rule packs (p/javascript, p/typescript,
p/react, p/owasp-top-ten). Measured on this repository they raise the rule count
from 525 to 564 and the finding count from 19 to 20 — `--config auto` already
selects what matters here.
Signed-off-by: Grigoriy Gogin <Grigoriy.Gogin@constructor.tech>
Gregory91G
changed the title
Every scan here becomes observational. Two checks blocked until now: the Trivy
CRITICAL pass and the TruffleHog history scan. Both keep running, keep reporting,
and stop deciding whether a branch can merge.
- Trivy: `--exit-code 1` becomes `--exit-code 0`. The pass is renamed from
`gate (CRITICAL)` to `critical (report-only)` — a check named "gate" that
gates nothing is worse than no check at all.
- TruffleHog: the summary step no longer exits non-zero on a finding. It still
renders the redacted table and still says to rotate.
Comments follow the behaviour: nothing in either file claims to block any more,
and where a waiver mechanism only matters under enforcement, the comment says so.
Baselines are unchanged by this: 0 CRITICAL and 0 secrets. Nothing was passing
because of these gates, so nothing regresses by removing them — what changes is
that a future finding will be reported rather than enforced.
Turning enforcement back on is prepared separately and deliberately not merged.
Refs #231
Signed-off-by: Grigoriy Gogin <Grigoriy.Gogin@constructor.tech>
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
.github/workflows/trivy.yml (1)
120-124: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick winGenerate the
trivy converttable report in the report job.The report step still only converts the JSON to SARIF. Add the same
convert --format tablestep used by.github/workflows/docker.ymlso the job log includes Trivy’s table report rather than only the Python summary.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/trivy.yml around lines 120 - 124, Update the Trivy conversion commands in the report job of trivy.yml to also run convert with --format table, matching the established step in docker.yml. Keep the existing SARIF conversion and Python summary, and ensure the table output is emitted to the job log.Source: MCP tools
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/trivy.yml:
- Around line 114-115: Update the Trivy workflow command to include UNKNOWN in
the --severity list, and update the later summary’s severity counts and ranking
to include UNKNOWN as well. Keep the scan and summary severity sets consistent
so undetermined-severity findings are reported end to end.
In @.github/workflows/trufflehog.yml:
- Around line 143-160: Update the TruffleHog workflow’s GitHub API scan at
.github/workflows/trufflehog.yml lines 143-160 to either invoke
github-experimental with --object-discovery and an appropriately longer timeout
for unreachable-object coverage, or remove unreachable-object claims and scope
the scan summary accordingly; also update the related summary at
.github/workflows/trufflehog.yml lines 199-201 to match the chosen coverage.
Preserve the existing reachable API scans and findings output.
---
Outside diff comments:
In @.github/workflows/trivy.yml:
- Around line 120-124: Update the Trivy conversion commands in the report job of
trivy.yml to also run convert with --format table, matching the established step
in docker.yml. Keep the existing SARIF conversion and Python summary, and ensure
the table output is emitted to the job log.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: b475561e-2560-41e1-9ad2-562c190dd984
📒 Files selected for processing (4)
.github/workflows/docker.yml.github/workflows/semgrep.yml.github/workflows/trivy.yml.github/workflows/trufflehog.yml
🚧 Files skipped from review as they are similar to previous changes (1)
- .github/workflows/docker.yml
| --severity CRITICAL,HIGH,MEDIUM,LOW \ | ||
| --include-dev-deps \ |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "Locate workflow files"
fd -a 'trivy\.yml$|trivy\.yaml$' .github/workflows 2>/dev/null || true
echo
echo "Relevant workflow excerpt"
if [ -f .github/workflows/trivy.yml ]; then
nl -ba .github/workflows/trivy.yml | sed -n '90,180p'
else
echo ".github/workflows/trivy.yml not found"
fi
echo
echo "Search for UNKNOWN and trivy severity/reporting"
rg -n "unknown|UNKNOWN|trivy" .github/workflows/trivy.yml .github/workflows -S || trueRepository: constructorfabric/insight-front
Length of output: 306
🏁 Script executed:
#!/bin/bash
set -u
echo "Workflow excerpt"
awk 'NR>=90 && NR<=180 { printf "%6d\t%s\n", NR, $0 }' .github/workflows/trivy.yml
echo
echo "Search for UNKNOWN and relevant reporting lines"
grep -n "unknown\|UNKNOWN\|--severity\|for s in\|rank\|every severity" .github/workflows/trivy.yml .github/workflows -S || trueRepository: constructorfabric/insight-front
Length of output: 5971
🌐 Web query:
Trivy --severity UNKNOWN documentation
💡 Result:
In Trivy, the UNKNOWN severity signifies that a vulnerability's severity rating could not be determined from the available data sources [1][2]. Key aspects regarding the UNKNOWN severity include: Severity Assignment Logic: Trivy automatically aggregates severity data from multiple sources (such as NVD, GHSA, and OS-specific vendors) to provide the most accurate assessment [1][3]. If no configured vendor or data source provides a severity rating for a vulnerability, Trivy defaults to UNKNOWN [1][2]. Customizing Severity Sources: Users can control how severities are determined using the --vuln-severity-source flag [1][4]. This allows you to specify a priority list of data sources [4]. Trivy will check these sources in the order provided; if none of the specified sources contain a severity, it will fall back to UNKNOWN [1][4]. For example: --vuln-severity-source nvd,ghsa: Trivy checks NVD first, then GHSA, and returns UNKNOWN if neither provides a severity [4]. Reasons for UNKNOWN Severity: - Data Delay: Some vendors (like NVD) may delay severity analysis for new vulnerabilities, while others may provide it more quickly [1][5]. - Missing Detail: Vulnerabilities detected via OS advisories (e.g., Alpine secdb) may lack severity information in the underlying vulnerability database if the detail entry has not yet been populated [6]. - Light Database Mode: Using the --light option may result in UNKNOWN severities because the lightweight database lacks detailed vulnerability information (such as CVSS scores) often used to calculate severity [7]. Trivy Severity Mapping: In Trivy's internal classification, UNKNOWN is mapped to the value 0, while others are assigned as follows [1][2]: 0: Unknown 1: Low 2: Medium 3: High 4: Critical
Citations:
- 1: https://trivy.dev/docs/latest/scanner/vulnerability/
- 2: https://github.com/aquasecurity/trivy/blob/main/docs/guide/scanner/vulnerability.md
- 3: https://trivy.dev/docs/v0.56/guide/scanner/vulnerability/
- 4: feat: add
--vuln-severity-sourceflag to customize vulnerability severity selection aquasecurity/trivy#8180 - 5: unexpected severity if
nvdandsourcedon't have severity for vulnerability aquasecurity/trivy#6714 - 6: fix(vuln): fall back to UNKNOWN severity when vulnerability details are missing aquasecurity/trivy#10795
- 7: --light option sometimes causes vulnerability severity to be unknown aquasecurity/trivy#922
🌐 Web query:
Trivy UNKNOWN severity documentation
💡 Result:
In Trivy, the "UNKNOWN" severity indicates that a vulnerability's severity level could not be determined from any of the available data sources (such as NVD, GHSA, or vendor-specific databases) [1][2][3]. Key points regarding the UNKNOWN severity: Determination Logic: Trivy automatically attempts to assign a severity based on a prioritized list of sources [1][2][4]. If no vendor or data source provides a specific severity rating, and it cannot be calculated via a CVSS score, Trivy assigns it the UNKNOWN severity [1][3]. Avoiding UNKNOWNs: To minimize the occurrence of UNKNOWN severities, Trivy is designed to use severity ratings from various vendors as fallbacks. For example, even if an NVD severity is not yet available, Trivy may use severity data from other vendors (like Red Hat) to provide a more actionable assessment [1][3][5]. Customization: Users can influence how severity is determined using the --vuln-severity-source flag [1][2][6]. This allows you to define a custom order of priority for severity sources. If you specify a sequence of sources, Trivy will check them in that order; if none of the specified sources contain a severity, Trivy will result in an UNKNOWN severity [1][2][6]. Reporting: In the context of reporting, UNKNOWN is considered a severity level (mapped to numerical value 0), distinct from other levels like Low, Medium, High, and Critical [1][2][3]. It is also important to distinguish this from vulnerability "status" (e.g., "unknown" status), which refers to whether a package is affected by a vulnerability on a specific platform [7]. For technical verification, you can check the SeveritySource field in Trivy's JSON output to identify exactly which source provided the severity (or if it was unable to be determined) for a specific vulnerability [2][3].
Citations:
- 1: https://trivy.dev/docs/latest/scanner/vulnerability/
- 2: https://github.com/aquasecurity/trivy/blob/main/docs/guide/scanner/vulnerability.md
- 3: https://trivy.dev/docs/v0.58/guide/scanner/vulnerability/
- 4: https://github.com/aquasecurity/trivy/blob/57c9cd36/pkg/vulnerability/vulnerability.go
- 5: unexpected severity if
nvdandsourcedon't have severity for vulnerability aquasecurity/trivy#6714 - 6: feat: add
--vuln-severity-sourceflag to customize vulnerability severity selection aquasecurity/trivy#8180 - 7: https://github.com/aquasecurity/trivy/blob/main/docs/guide/configuration/filtering.md
Include Trivy’s UNKNOWN severity end to end.
--severity CRITICAL,HIGH,MEDIUM,LOW filters out UNKNOWN findings, while the summary later says it reports every severity. Add UNKNOWN to the scan and include it in the summary counts/ranking so vulnerabilities without a determined severity are not silently omitted.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/trivy.yml around lines 114 - 115, Update the Trivy
workflow command to include UNKNOWN in the --severity list, and update the later
summary’s severity counts and ranking to include UNKNOWN as well. Keep the scan
and summary severity sets consistent so undetermined-severity findings are
reported end to end.
Source: MCP tools
| - name: TruffleHog scan (GitHub API — comments, wikis, unreachable objects) | ||
| env: | ||
| # The auto-injected token is enough for a public repository's commits and comments. | ||
| GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} | ||
| run: | | ||
| set -euo pipefail | ||
| docker run --rm \ | ||
| -e GITHUB_TOKEN \ | ||
| trufflesecurity/trufflehog:3.96.0@sha256:aa821cf4ace8861c7d096d83818cdf7bb9719028a52d37a52eaad44086a52577 \ | ||
| github \ | ||
| --repo "${GITHUB_SERVER_URL}/${GITHUB_REPOSITORY}" \ | ||
| --issue-comments \ | ||
| --pr-comments \ | ||
| --include-wikis \ | ||
| --json \ | ||
| --no-update \ | ||
| --results=verified,unknown,unverified,filtered_unverified \ | ||
| > trufflehog-api-findings.jsonl |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major | 🏗️ Heavy lift
🧩 Analysis chain
🏁 Script executed:
#!/usr/bin/env bash
set -euo pipefail
IMAGE='trufflesecurity/trufflehog:3.96.0@sha256:aa821cf4ace8861c7d096d83818cdf7bb9719028a52d37a52eaad44086a52577'
docker run --rm "$IMAGE" github --help
docker run --rm "$IMAGE" github-experimental --helpRepository: constructorfabric/insight-front
Length of output: 213
🌐 Web query:
TruffleHog 3.96.0 github github-experimental object-discovery documentation
💡 Result:
The github-experimental object-discovery module in TruffleHog is an alpha feature designed to identify Cross Fork Object References, allowing users to discover and scan hidden or deleted commits in GitHub repositories [1][2][3]. As of TruffleHog version 3.96.0, which was released on July 24, 2026 [4][5], this feature remains available via the following command structure: trufflehog github-experimental --repo https://github.com//.git --object-discovery Key details for using this feature include: Authentication: You must provide a valid GitHub Access Token, either by setting the GITHUB_TOKEN environment variable or by passing it via the --token flag [3]. Operational Behavior: When executed, TruffleHog creates two files in a $HOME/.trufflehog directory: valid_hidden.txt and invalid.txt [1][6]. The former contains a list of all discovered hidden and deleted commits [1][3]. Users can include the --delete-cached-data flag if they wish to have these files automatically removed after the scan is complete [1][2]. Performance: The enumeration process can be time-intensive, potentially taking from 20 minutes to several hours depending on the repository size, as it involves querying GitHub's services for commit hashes [1][3]. Configuration: The command supports a --collision-threshold flag (defaulting to 1), which allows users to manage the trade-off between scan speed and potential hash collisions [7][3][8]. For more context on the security implications of Cross Fork Object References, refer to the official Truffle Security blog [3][9].
Citations:
- 1: https://github.com/trufflesecurity/trufflehog/blob/main/README.md
- 2: https://github.com/trufflesecurity/trufflehog/tree/refs/heads/main
- 3: https://trufflesecurity.com/blog/trufflehog-now-finds-all-deleted-and-private-commits-on-github
- 4: https://github.com/trufflesecurity/trufflehog/releases/tag/v3.96.0
- 5: https://newreleases.io/project/github/trufflesecurity/trufflehog/release/v3.96.0
- 6: https://github.com/trufflesecurity/trufflehog
- 7: https://github.com/trufflesecurity/trufflehog/blob/9f0b97f1/docs/man/trufflehog.1
- 8: https://github.com/trufflesecurity/trufflehog/blob/c1a1d6a2/docs/man/trufflehog.1
- 9: https://raw.githubusercontent.com/trufflesecurity/trufflehog/main/README.md
🌐 Web query:
site:github.com/marketplace/actions/trufflehog-oss TruffleHog GitHub experimental object discovery
💡 Result:
In TruffleHog, object discovery is an experimental sub-module within the github-experimental command designed to identify and scan hidden, deleted, or cross-fork commits in a GitHub repository [1]. To run this feature, use the command: trufflehog github-experimental --repo https://github.com//.git --object-discovery Key details about this experimental feature include: Data Outputs: When the --object-discovery flag is used, TruffleHog creates a $HOME/.trufflehog directory containing two files: valid_hidden.txt and invalid.txt [1]. These files track the state of commit enumeration and provide a list of all identified hidden and deleted commits [1]. Cleanup: To automatically remove these cached files after the scan completes, you can add the --delete-cached-data flag [1]. Performance: Enumerating all commits on a repository using this method can take between 20 minutes to several hours, depending on the repository size [1]. While enumeration takes time, the subsequent secret scanning phase is designed to run very quickly [1]. This functionality is categorized as an alpha release feature [1].
Citations:
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf 'Workflow file info:\n'
wc -l .github/workflows/trufflehog.yml 2>/dev/null || true
sed -n '1,230p' .github/workflows/trufflehog.yml 2>/dev/null | nl -ba
printf '\nSearch for object discovery/github-experimental references:\n'
rg -n "github-experimental|object-discovery|object discovery|orphaned|unreachable|orphan|hidden" .github/workflows/trufflehog.yml . 2>/dev/null | head -120Repository: constructorfabric/insight-front
Length of output: 266
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf 'Workflow lines 1-230:\n'
python3 - <<'PY'
from pathlib import Path
p = Path('.github/workflows/trufflehog.yml')
lines = p.read_text().splitlines()
for i, line in enumerate(lines, 1):
print(f"{i:4}: {line}")
PY
printf '\nSearch results:\n'
python3 - <<'PY'
import re
from pathlib import Path
terms = ('github-experimental', 'object-discovery', 'object discovery', 'orphaned', 'unreachable', 'orphan', 'hidden')
for path in sorted(Path('.').rglob('*')):
if path.is_file() and '.git' not in path.parts:
try:
txt = path.read_text(errors='ignore').splitlines()
except Exception:
continue
for idx, line in enumerate(txt, 1):
if any(term in line for term in terms):
print(f"{path}:{idx}:{line}")
PYRepository: constructorfabric/insight-front
Length of output: 50388
🏁 Script executed:
#!/bin/bash
set -euo pipefail
python3 - <<'PY'
from pathlib import Path
p = Path('.github/workflows/trufflehog.yml')
text = p.read_text()
lines = text.splitlines()
for i, line in enumerate(lines, 1):
if 1 <= i <= 80 or 130 <= i <= 210:
print(f"{i:4}: {line}")
PYRepository: constructorfabric/insight-front
Length of output: 8675
Align the GitHub API scan with TruffleHog execution realities.
The workflow notes unreachable objects live on the remote and need trufflehog github --repo, but this job uses trufflehog github for its claimed orphaned-object coverage. That also ignores TruffleHog’s github-experimental --object-discovery command for unreachable deleted/hidden commit enumeration; add that scan with a longer timeout if that coverage is required, or remove the unreachable-object language and scope the summary to reachable API content.
📍 Affects 1 file
.github/workflows/trufflehog.yml#L143-L160(this comment).github/workflows/trufflehog.yml#L199-L201
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/trufflehog.yml around lines 143 - 160, Update the
TruffleHog workflow’s GitHub API scan at .github/workflows/trufflehog.yml lines
143-160 to either invoke github-experimental with --object-discovery and an
appropriately longer timeout for unreachable-object coverage, or remove
unreachable-object claims and scope the scan summary accordingly; also update
the related summary at .github/workflows/trufflehog.yml lines 199-201 to match
the chosen coverage. Preserve the existing reachable API scans and findings
output.
Review remark from @cyberantonz on constructorfabric/insight#2016, applied here too since the same widening had landed in this workflow. Measured before reverting: on a backend connector image the filter change takes one image from 99 findings to 315, and across that estate from ~660 to ~2100. On this repository's image it was 37 to 107. The volume buys nothing. Every finding in an image comes from a base layer, and the remedy is identical at every severity — refresh the base image. What the wider filter does change is that the CRITICALs, which are the ones driving that refresh, end up buried under three times as many MEDIUM and LOW entries. Kept where it does pay: the repository pass stays at every severity. There the volume is small (37 findings) and each one points at a dependency this repository declares and can bump on its own. Refs #231 Signed-off-by: Grigoriy Gogin <Grigoriy.Gogin@constructor.tech>
2 participants
Ports three review findings from constructorfabric/insight#2002 to this repo, so the two scanning setups do not drift apart. No behaviour change to what is reported — only to what is honored, what is logged on failure, and how many times Trivy runs.
1. The repo-root
.trivyignorewas never readtrivy.ymldocuments that waivers go in a date-scoped.trivyignoreat the repo root. They did not work. Trivy resolves the default ignore file relative to the working directory, and the containers set no-w, so the file was looked for in the Trivy image's own cwd rather than in the mounted tree.Measured on a minimal tree (a
Dockerfilewith noUSER, soDS-0002HIGH):.trivyignore.trivyignorewithDS-0002at the root, command as it was-w /src--ignorefile /src/.trivyignoreFixed with
-w, not--ignorefile: Trivy exitsFATAL ignore file not foundwhen the named file is absent, and neither repo has a.trivyignoreyet, so that variant would break every run until someone added a waiver. Verified both ways — with a waiver present the gate now honors it, and with no.trivyignoreat all the gate is unaffected.Impact today is latent: there are no waivers to honor. But the first person whom the gate blocks on an unfixable CRITICAL would follow the documented instruction and find it does nothing.
2. SARIF upload ran even when no SARIF existed
The upload steps used
if: always()against files that a failed scan never writes. When a scan step dies (registry auth, network, DB download), the job is already red — and thenupload-sarifadds a second error about a missing path, which points at Code Scanning instead of the scan that actually broke. AhashFiles(...) != ''guard drops that, keeping the fork-PR condition intact.3. Trivy scanned twice to produce two formats
Both passes ran the full scan twice over an identical target: the repository pass for SARIF and JSON, the image scan for a log table and SARIF.
trivy convertderives every other format from a saved JSON report without rescanning.Now: one scan → JSON, then
convertfor the rest. Output is byte-for-byte equivalent in count — verified against whatmaincurrently reports:convert)trivy-fs)trivy-image)The image scan gains the most: it drops a second registry pull and a second layer analysis per run.
Test plan
Run locally against this branch.
actionlinton both changed files — no new findings (the two pre-existing SC2046/SC2016 warnings onCreate multi-arch manifestandReport pushed imageare untouched)-w /srcagainst this repository — exit 0, still green.trivyignorewithDS-0002now suppresses the finding, where the previous command reported it.trivyignoreexists — the current state of the repoconvert→ SARIF with 31 results, matchingmainghcr.io/constructorfabric/insight-front:latest— one scan → JSON,convert --format tablerendersTotal: 37 (HIGH: 35, CRITICAL: 2),convert --format sarifyields 37 results, matchingmaintrivy-imagejob itself — runs on push tomain, so first exercised after mergeSummary by CodeRabbit
Part 2 — completeness of the report
The three fixes above are correctness. This second commit is about coverage: what the scans
report, not what they block. No behaviour of any gate changes and nothing is fixed — fixing
the findings is separate work.
Four gaps, each measured on this repository before being closed:
semgrep.ymlalso gains apush: maintrigger. Without it Code Scanning holds no SAST data forthe default branch between a merge and the 03:27 nightly, so a merge that introduces a finding is
invisible until the next morning — and the front's
branch:mainfilter currently shows Trivy only.Deliberately not added
p/javascript,p/typescript,p/react,p/owasp-top-ten).Measured: rules 525 → 564, findings 19 → 20, and the one extra is not in
src/.--config autoalready selects what matters for this codebase.same review. None apply here: this repo already has
pnpm-lock.yaml, already scans its image atpublish time, and holds no Helm chart (the frontend chart lives in
constructorfabric/insightunder
src/frontend/helm).What the report will contain after this merges
Roughly 146 Trivy alerts on
main— 39 from the repository (37 vulnerabilities + 2misconfigurations) and 107 from the image — plus the Semgrep baseline that the new push trigger
produces immediately instead of overnight. Before this PR: 68.
Test plan — part 2
actionlinton all four changed files — no new findings--include-dev-deps— 37 vulnerabilities + 2 misconfigurations, up from 29 + 2--ignore-unfixedverified to make no difference on the current image: all 107 have a published fixCloses constructorfabric/insight#2079