Misconfiguration scanning not producing a failing exit code on parse error

[green-leader]

Description

I'm using Trivy from within a Github action paired with yamllint on a FluxCD Kubernetes repo. It looks like sometime ago I had some potentially yaml that was causing the kubernetes scanner to choke. On an error such as this I expect it to raise some kind of error code based on the config given.
2025-01-16T19:41:33Z ERROR [kubernetes scanner] Failed to parse file file_path="helmrelease-sample.yml" err="unmarshal yaml: node tag is not supported !! 'timestamp"

config file given:

severity:
  - UNKNOWN
  - LOW
  - MEDIUM
  - HIGH
  - CRITICAL

exit-code: 1

helmrelease-sample.yml

apiVersion: helm.toolkit.fluxcd.io/v2
kind: HelmRelease
metadata:
  name: sample
  namespace: sample
spec:
  chart:
    spec:
      chart: sample
      version: 1.2.3
      sourceRef:
        kind: HelmRepository
        name: sample
        namespace: flux-system
  interval: 15m
  timeout: 5m
  releaseName: sample
  releaseName: sample
  values:
    global: 2024-04-01

The offending line is the date at the end. yamllint has no issues with it and as far as I can tell it's valid YAML. If I put it in quotes the error goes away.

Desired Behavior

I should be alerted when there's an error parsing or scanning a file. Either with a new severity level or caught under severity unknown

Actual Behavior

Exit code is not changed, and documentation doesn't reflect if we can be alerted on a parsing or scanning error.

Reproduction Steps

1. Create `helmrelease-sample.yml` using minimum above
2. Create config file
3. Run `trivy config` passing in the config file and path to sample file
4. Check exit code with `echo $?`

Target

Filesystem

Scanner

Misconfiguration

Output Format

Table

Mode

Standalone

Debug Output

trivy --config .github/workflows/trivy/config.yml config helmrelease-sample.yml -d
2025-01-16T19:53:52Z    DEBUG   No plugins loaded
2025-01-16T19:53:52Z    INFO    Loaded  file_path=".github/workflows/trivy/config.yml"
2025-01-16T19:53:52Z    DEBUG   Cache dir       dir="/home/codespace/.cache/trivy"
2025-01-16T19:53:52Z    DEBUG   Cache dir       dir="/home/codespace/.cache/trivy"
2025-01-16T19:53:52Z    DEBUG   Parsed severities       severities=[UNKNOWN LOW MEDIUM HIGH CRITICAL]
2025-01-16T19:53:52Z    INFO    [misconfig] Misconfiguration scanning is enabled
2025-01-16T19:53:52Z    DEBUG   [misconfig] Checks successfully loaded from disk
2025-01-16T19:53:52Z    DEBUG   Enabling misconfiguration scanners      scanners=[azure-arm cloudformation dockerfile helm kubernetes terraform terraformplan-json terraformplan-snapshot]
2025-01-16T19:53:52Z    DEBUG   Initializing scan cache...      type="memory"
2025-01-16T19:53:52Z    DEBUG   [misconfig] Scanning files for misconfigurations...     scanner="Kubernetes"
2025-01-16T19:53:52Z    ERROR   [kubernetes scanner] Failed to parse file       file_path="helmrelease-sample.yml" err="unmarshal yaml: node tag is not supported !!timestamp"
2025-01-16T19:53:52Z    DEBUG   OS is not detected.
2025-01-16T19:53:52Z    INFO    Detected config files   num=0
2025-01-16T19:53:52Z    DEBUG   Specified ignore file does not exist    file=".trivyignore"
2025-01-16T19:53:52Z    DEBUG   [vex] VEX filtering is disabled

Operating System

Linux codespaces-2fdcbf 6.5.0-1025-azure #26~22.04.1-Ubuntu SMP Thu Jul 11 22:33:04 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

Version

Version: 0.58.2
Check Bundle:
  Digest: sha256:f6901e03f486a48f47aa17a78d89d18e6c31ded82aff83ed19d0d73935a1a059
  DownloadedAt: 2025-01-16 15:24:02.001128502 +0000 UTC

Checklist

• Run trivy clean --all
• Read the troubleshooting

[simar7]

thanks for the report @green-leader!

@nikpivkin currently we don't have an UNKNOWN severity type in IaC Scanning but I'm leaning towards classifying such issues as UNKNOWN type. WDYT?

[nikpivkin]

It seems the issue isn't tied to the severity level.

[nikpivkin]

Hi @green-leader !

Trivy should not return an error code, since the parsing error was only logged and the scan itself continued without fail. I will create an issue to fix the handling of configs with timestamp.

[green-leader]

Perfect, that'll work too!

[nikpivkin]

Track #8252