package-lock.json not detected in image scan, while Cargo.lock & composer.lock are

[john-d8r]

Description

While scanning an image from trivy's example https://github.com/aquasecurity/trivy-ci-test, noticed that package-lock.json is not detected, while Cargo.lock & composer.lock are detected.

I can understand that package-lock.json are not supported for image scans (as per trivy support matrix)

But I would like to understand the reason behind this decision and if there are any other work-around for this

Desired Behavior

Trivy to detect package-lock.json while scanning image

Actual Behavior

package-lock.json was not detected

Reproduction Steps

1. clone https://github.com/aquasecurity/trivy-ci-test
2. `docker build . -t trivy-ci-test`
3. trivy image trivy-ci-test

Target

Container Image

Scanner

Vulnerability

Output Format

None

Mode

Standalone

Debug Output

2023-07-04T13:37:47.478+0530    INFO    Detected OS: alpine
2023-07-04T13:37:47.478+0530    INFO    Detecting Alpine vulnerabilities...
2023-07-04T13:37:47.478+0530    DEBUG   alpine: os version: 3.7
2023-07-04T13:37:47.478+0530    DEBUG   alpine: package repository: 3.7
2023-07-04T13:37:47.478+0530    DEBUG   alpine: the number of packages: 58
2023-07-04T13:37:47.480+0530    INFO    Number of language-specific files: 2
2023-07-04T13:37:47.480+0530    INFO    Detecting composer vulnerabilities...
2023-07-04T13:37:47.480+0530    DEBUG   Detecting library vulnerabilities, type: composer, path: php-app/composer.lock
2023-07-04T13:37:47.480+0530    INFO    Detecting cargo vulnerabilities...
2023-07-04T13:37:47.480+0530    DEBUG   Detecting library vulnerabilities, type: cargo, path: rust-app/Cargo.lock
2023-07-04T13:37:47.489+0530    WARN    This OS version is no longer supported by the distribution: alpine 3.7.1
2023-07-04T13:37:47.489+0530    WARN    The vulnerability detection may be insufficient because security updates are not provided

Operating System

WSL

Version

Version: 0.42.1
Vulnerability DB:
  Version: 2
  UpdatedAt: 2023-07-04 06:09:14.346674696 +0000 UTC
  NextUpdate: 2023-07-04 12:09:14.346674396 +0000 UTC
  DownloadedAt: 2023-07-04 06:41:58.571723656 +0000 UTC
Java DB:
  Version: 1
  UpdatedAt: 2023-06-28 00:54:49.597173348 +0000 UTC
  NextUpdate: 2023-07-01 00:54:49.597172848 +0000 UTC
  DownloadedAt: 2023-06-28 03:04:49.960249058 +0000 UTC

Checklist

• Run trivy image --reset
• Read the troubleshooting

[knqyf263]

It is a bit complicated now. Please take a look at the doc to understand the behavior.
https://aquasecurity.github.io/trivy/v0.43/docs/scanner/vulnerability/language/

Trivy needs to scan composer.lock until Trivy supports PHP metadata of installed packages like .gemspec in Ruby.

[john-d8r]

Thanks for you reply @knqyf263

Trivy needs to scan composer.lock until Trivy supports PHP metadata of installed packages like .gemspec in Ruby.

Do you mean that once Trivy supports PHP metadata of installed packages like .gemspec in Ruby. support for composer.lock on image scans will be removed ?

Is there a reason for explicitly disabling lock file analyzers on image scan (for some languages)

trivy/pkg/commands/artifact/run.go

Line 168 in 8e7fb7c

opts.DisabledAnalyzers = analyzer.TypeLockfiles

I don't see trivy docs having explanation on that. (also it's not configurable ATM)

[knqyf263]

Do you mean that once Trivy supports PHP metadata of installed packages like .gemspec in Ruby. support for composer.lock on image scans will be removed ?

Yes

Is there a reason for explicitly disabling lock file analyzers on image scan (for some languages)

There could be unused lock files for testing or any other reasons in container images. Then, it leads to false detection. We've got many complaints about it.

also it's not configurable ATM

What do you mean?

[john-d8r]

There could be unused lock files for testing or any other reasons in container images. Then, it leads to false detection. We've got many complaints about it.

Ok understood

What do you mean?

https://github.com/aquasecurity/trivy/blob/8e7fb7cc84bf010592115c6bfed602aff3410dec/pkg/flag/options.go#L108C1-L109C35
User can't control DisabledAnalyzers from cli at the moment, if they wants their lock files to be analyzed during image scans

[knqyf263]

It is the opposite, but there is a similar issue. We can discuss enabling analyzers as well.
#3987

[john-d8r]

Thanks @knqyf263

[vikasdf]

@knqyf263 But with the current approach, we pick non-lock package manifest files (package.json, requirements.txt etc) even when lock file is available. These non-lock package manifests may not have the exact versions of the dependencies leading to errors in SBOM and associated vulnerability information. Also, we lose out on details like dependency tree etc. If some users left unused lock files in their image, shouldn't the proper fix be to advise them to remove the unused lock files? Also as John mentioned, this behavior should be configurable as there might be users who would prefer to use lockfiles when available.