Expected Behavior
In a YAML file that references other files (e.g. a docker-compose include:), # kics-scan ignore-line should suppress the finding on the line beneath it, and lines without an ignore comment should apply warnings as usual.
For the reproduction below: foo's port finding is suppressed, while bar's port finding is reported.
Actual Behavior
The ignore positions seem to be shifted by the resolved (inlined) content, so:
- foo is reported at line 8 — despite the
ignore-line comment right above its ports:
- bar is silently suppressed, although it has no ignore comment (the shifted ignore lands on it)
Container Traffic Not Bound To Host Interface, Severity: MEDIUM, Results: 1
[1]: docker-compose.yaml:8
Steps to Reproduce the Problem
- Create
docker-compose.yaml:
include:
- included.yaml
services:
foo:
image: alpine
# kics-scan ignore-line
ports:
- "1111:1111"
bar:
image: alpine
ports:
- "2222:2222"
- Create
included.yaml next to it:
services:
rabbit:
image: rabbitmq:3
environment:
K0: "0"
K1: "1"
K2: "2"
- Run
kics scan -p docker-compose.yaml (narrowing to the ports query shows it clearly: --include-queries 451d79dc-0588-476a-ad03-3c7f0320abb3)
Specifications
- Version: reproduced on current master and v2.1.20
- Platform: any YAML platform with resolved file references
Root cause
Parser.Parse first resolves the referenced files (the resolver inlines included.yaml, shifting all lines below the include: block), then collects the ignore comment positions from the resolved content. Then we store the shifted positions in FileMetadata.LinesIgnore (pkg/kics/sink.go). Findings, however, are reported on original file coordinates, so checkComment(vulnerability.Line, file.LinesIgnore) (pkg/engine/inspector.go) compares two different coordinate systems. In the repro, the comment at original lines 6-7 is stored as [12, 13].
Two other places already handle this by recomputing ignore lines from the original data: the secrets engine (model.GetIgnoreLines in pkg/engine/secrets/inspector.go, added in #5735) and the Helm sink (getOriginalIgnoreLines in pkg/kics/resolver_sink.go). The regular sink doesn't have such fix.
Issues I think are related:
I have a fix ready, PR coming.
Expected Behavior
In a YAML file that references other files (e.g. a docker-compose
include:),# kics-scan ignore-lineshould suppress the finding on the line beneath it, and lines without an ignore comment should apply warnings as usual.For the reproduction below: foo's port finding is suppressed, while bar's port finding is reported.
Actual Behavior
The ignore positions seem to be shifted by the resolved (inlined) content, so:
ignore-linecomment right above itsports:Steps to Reproduce the Problem
docker-compose.yaml:included.yamlnext to it:kics scan -p docker-compose.yaml(narrowing to the ports query shows it clearly:--include-queries 451d79dc-0588-476a-ad03-3c7f0320abb3)Specifications
Root cause
Parser.Parsefirst resolves the referenced files (the resolver inlinesincluded.yaml, shifting all lines below theinclude:block), then collects the ignore comment positions from the resolved content. Then we store the shifted positions inFileMetadata.LinesIgnore(pkg/kics/sink.go). Findings, however, are reported on original file coordinates, socheckComment(vulnerability.Line, file.LinesIgnore)(pkg/engine/inspector.go) compares two different coordinate systems. In the repro, the comment at original lines 6-7 is stored as[12, 13].Two other places already handle this by recomputing ignore lines from the original data: the secrets engine (
model.GetIgnoreLinesinpkg/engine/secrets/inspector.go, added in #5735) and the Helm sink (getOriginalIgnoreLinesinpkg/kics/resolver_sink.go). The regular sink doesn't have such fix.Issues I think are related:
model.GetIgnoreLinesrecompute inpkg/engine/secrets/inspector.go). I think it's most likely an oversight to not have done the more "catch all" fix initially.kics-scan ignore-blocknot working in a templated Kubernetes YAML; likely the same family of problem ?I have a fix ready, PR coming.