Switch to make "This OS version is no longer supported" an error exit code

[tisc0]

Hi guyz, And first of all, again, thanks a lot for the job done here !

Everything is in the title : would be great to simply flag an outdated scanned image, so that we could take care of its replacement ! (adding a switch like --exit-error-nolonger-supported-os ?)

david@e-falcon 01:08:38:~/ (add-trivy) $ trivy image --exit-code 1 --severity MEDIUM,HIGH,CRITICAL golang:1.9.7-alpine3.8
2021-03-18T01:08:49.252+0100    INFO    Detecting Alpine vulnerabilities...
2021-03-18T01:08:49.252+0100    INFO    Trivy skips scanning programming language libraries because no supported file was detected
2021-03-18T01:08:49.252+0100    WARN    This OS version is no longer supported by the distribution: alpine 3.8.0
2021-03-18T01:08:49.252+0100    WARN    The vulnerability detection may be insufficient because security updates are not provided

golang:1.9.7-alpine3.8 (alpine 3.8.0)
=====================================
Total: 0 (MEDIUM: 0, HIGH: 0, CRITICAL: 0)

david@e-falcon 01:08:49:~/ (add-trivy) $ echo $?
0

Thanks,

[thiago-gitlab]

My suggestion for this would be to output the warning to a vulnerability. This works well with integrations because the item will be reviewed by the responsible team without the need for an exception to existing processes.

It also makes sense that an "unsupported OS" is a kind of vulnerability because you could be exposed. Since we can't tell for sure, I'm open to what the severity should be (in GitLab we support unknown).

[lfama]

Hi all,

I also think it would be great to have such a option. it looks like the PR #1092 from @philnichol implements the switch to control the behaviour for unsupported OSes. Do you plan to merge it?

Thanks! Luca

[agileknight]

Returning an exit code 1 for unknown (seems to be the case already) and unsupported OS versions seems to be the desired behavior since both could mean that CVEs are missed by the scan.

[eli-darkly]

I agree that it would be highly desirable for Trivy to fail in a case where it cannot actually scan the OS. However, I'd like to propose a slightly different behavior for the case where the OS version is not EOL, but rather, is newer than the last known version and has not yet been added to the EOL list (see: https://github.com/aquasecurity/trivy/pull/2319). I think in that case it would be highly desirable for it to assume that the version is not EOL, and to scan for vulnerabilities if possible; if I understand correctly, the current behavior in this case is that it just logs "This OS version is not on the EOL list" and then does not really do a scan.

[MaineK00n]

I agree that it would be highly desirable for Trivy to fail in a case where it cannot actually scan the OS. However, I'd like to propose a slightly different behavior for the case where the OS version is not EOL, but rather, is newer than the last known version and has not yet been added to the EOL list (see: #2319). I think in that case it would be highly desirable for it to assume that the version is not EOL, and to scan for vulnerabilities if possible; if I understand correctly, the current behavior in this case is that it just logs "This OS version is not on the EOL list" and then does not really do a scan.

Even if it is not present in the EOL list, detection is still performed, only the following log is displayed.

2022-06-15T12:17:29.469+0900    INFO    This OS version is not on the EOL list: alpine 3.16

https://github.com/aquasecurity/trivy/pull/2319#issuecomment-1155943469

[eli-darkly]

@MaineK00n Thanks. I'm not sure what is going on then in my case - I'll keep looking into it.

[simonst]

Any news on this? I am still not getting any errors on non supported OS versions. When scanning a Pod directly with 'trivy k8s' there is not even a warning shown.

[aleliaert]

I just encountered this behavior when evaluatingtrivy. My test cases included an obsolete OS, and was surprised to see json output show no vulnerabilities, and invocation return 0/success.

IMO, this sort of tool really needs to err on the side of overcommunicating in warning situations. Just some text to stderr isn't good enough when CICD integrations are relying on return code (and json output) to make choices. False negatives can be a big deal for compliance, and threat actors can abuse this sort of behavior.

Bonus points for having features to ease integration when handling warnings. Command line args to influence return codes and/or enumerated info in json output are helpful.

Any ideas on workarounds this behavior? Some things I can think of:

• Parse stderr from the tool and catch WARN in general
• Parse stderr from the tool and catch the specific warnings above (brittle)
• Provide some Rego policy file that specifies specific OSes/versions as pass, or EOL list versions as fail? (Would such work?)
• Output SBoM and let another tool notice the OS problem (but more tools)

FWIW am liking a lot of trivy features in general. IMO this issue points out the need for one more.

[simonst]

It would be great to have this. liking trivy a lot as well, so it would be a big plus to have this.

[knqyf263]

We've added --exit-on-eol. Please reference the release note. https://github.com/aquasecurity/trivy/discussions/3719

[aleliaert]

@knqyf263 - Thanks, am seeing desired behavior on my test cases.