trivy image scan suddenly timing out

[stealthrabbi]

Trivy image scan was taking less than 1 minute as of yesterday. Now suddenly it is timing out.

Settting `--security-checks vuln has no effect, as was suggested from output.

Tried this with v0.24.2 and current latest

2023-01-12T12:46:56.932Z    INFO    Need to update DB
2023-01-12T12:46:56.932Z    INFO    DB Repository: ghcr.io/aquasecurity/trivy-db
2023-01-12T12:46:56.932Z    INFO    Downloading DB...
10.64 MiB / 36.04 MiB [------------------>__________________________________________] 29.53% ? p/s ?23.69 MiB / 36.04 MiB [---------------------------------------->____________________] 65.75% ? p/s ?36.04 MiB / 36.04 MiB [----------------------------------------------------------->] 100.00% ? p/s ?36.04 MiB / 36.04 MiB [---------------------------------------------->] 100.00% 42.35 MiB p/s ETA 0s36.04 MiB / 36.04 MiB [---------------------------------------------->] 100.00% 42.35 MiB p/s ETA 0s36.04 MiB / 36.04 MiB [---------------------------------------------->] 100.00% 42.35 MiB p/s ETA 0s36.04 MiB / 36.04 MiB [---------------------------------------------->] 100.00% 39.62 MiB p/s ETA 0s36.04 MiB / 36.04 MiB [---------------------------------------------->] 100.00% 39.62 MiB p/s ETA 0s36.04 MiB / 36.04 MiB [---------------------------------------------->] 100.00% 39.62 MiB p/s ETA 0s36.04 MiB / 36.04 MiB [---------------------------------------------->] 100.00% 37.07 MiB p/s ETA 0s36.04 MiB / 36.04 MiB [---------------------------------------------->] 100.00% 37.07 MiB p/s ETA 0s36.04 MiB / 36.04 MiB [---------------------------------------------->] 100.00% 37.07 MiB p/s ETA 0s36.04 MiB / 36.04 MiB [---------------------------------------------->] 100.00% 34.67 MiB p/s ETA 0s36.04 MiB / 36.04 MiB [-------------------------------------------------] 100.00% 14.56 MiB p/s 2.7s2023-01-12T12:47:00.337Z    INFO    Vulnerability scanning is enabled
2023-01-12T12:56:56.932Z    WARN    Increase --timeout value
2023-01-12T12:56:56.932Z    FATAL   image scan error: scan error: scan failed: failed analysis: analyze error: timeout: context deadline exceeded

[sadovnikov]

Thank you, @pioneer2k! Setting offline mode through ENV is working indeed 👍
I'll spend some time figuring out why this fails with the config file.

Running Trivy with trivy.yaml config from:  ./.github/trivy.yaml

[navzen2000]

@DmitriyLewen What is search.maven.org used for?

If your jar file doesn't have information about GroupID, ArtifactID and Version in pom.properties or MANIFEST.MF then: We use maven repository to try to get GroupID, ArtifactID and Version by SHA-1 digest or get GroupID by artifactID(artifactID got from file name)

I checked for a given jar file, all the above details are present in manifest.mf and pom.properties Then why Trivy tried to connect to search.maven.org to retrieve these details and hitting 504 I think such errors need to be gracefully handled (with warnings perhaps) without erroring out completely and impacting the execution.

[durcon]

@knqyf263, @DmitriyLewen

@knqyf263

@WhyJee --debug helps. Many JAR files don't correctly define the identity. The warning will overwhelm the output. That is why they are debugging messages.

As I wrote in my comment almost all JARs in my project provide such information. However, if --debug shows that JARs that's helpful. I will try it and check my project again.

Instead of deactivating the search would it possible to cache the search results like the database? The SHA-1 digest should never change. Trivy should only call search.maven.org if there is a new JAR without a cached SHA-1 digest. That would also ease the rate limit problem.

I checked my build with --debug enabled.

2023-01-17T17:49:52.972Z    DEBUG   retrying request    {"request": "GET https://search.maven.org/solrsearch/select?q=1%3A%22f22f518dcb0d7361ae9055a87a730770decf19fb%22&rows=1&wt=json (status: 504)", "timeout": "20s", "remaining": 5}

It is the JAR for org.springframework.boot:spring-boot:2.3.10.RELEASE. And this JAR contains a MANIFEST.MF:

Manifest-Version: 1.0
Implementation-Title: Spring Boot
Automatic-Module-Name: spring.boot
Implementation-Version: 2.3.10.RELEASE
Built-By: Spring
Build-Jdk-Spec: 1.8

Why is Trivy calling search.maven.org, if the information is already in the JAR file?

There are several other Spring JARs, which are search by API, although the information is available.

[bpfoster]

In a lot of cases there is also the pom.xml in den JAR.

I'm not sure there is resource with a list of jars that we can use to save to the database.

That's why we use maven repository to analyze similar jars.

Central does provide their index, but it's pretty big.

[DmitriyLewen]

Hello @navzen2000

I checked for a given jar file, all the above details are present in manifest.mf and pom.properties

perhaps there is no one field.

e.g. org.springframework.boot:spring-boot:2.3.10.RELEASE from @durcon post doesn't have GroupID.

➜  ~ curl https://search.maven.org/solrsearch/select\?q\=1%3A%22f22f518dcb0d7361ae9055a87a730770decf19fb%22\&rows\=1\&wt\=json | jq
{
...
  },
  "response": {
    "numFound": 1,
    "start": 0,
    "docs": [
      {
        "id": "org.springframework.boot:spring-boot:2.3.10.RELEASE",
        "g": "org.springframework.boot",
        "a": "spring-boot",
        "v": "2.3.10.RELEASE",
        "p": "jar",
...

[navzen2000]

@DmitriyLewen Here is the extract from pom.properties in my case (values masked). Please let me know what is missing that causes below error FYI: @komamitsu

Created by Apache Maven 3.6.3

groupId=connectors artifactId=guava version=2307

2023-01-18T05:19:10.527Z        DEBUG   Parsing Java artifacts...       {"file": "libs/guava.jar"}
2023-01-18T05:19:10.538Z        FATAL   image scan error:
    github.com/aquasecurity/trivy/pkg/commands/artifact.Run
        /home/runner/work/trivy/trivy/pkg/commands/artifact/run.go:397
  - scan error:
    github.com/aquasecurity/trivy/pkg/commands/artifact.(*runner).scanArtifact
        /home/runner/work/trivy/trivy/pkg/commands/artifact/run.go:257
  - scan failed:
    github.com/aquasecurity/trivy/pkg/commands/artifact.scan
        /home/runner/work/trivy/trivy/pkg/commands/artifact/run.go:588
  - failed analysis:
    github.com/aquasecurity/trivy/pkg/scanner.Scanner.ScanArtifact
        /home/runner/work/trivy/trivy/pkg/scanner/scan.go:146
  - analyze error:
    github.com/aquasecurity/trivy/pkg/fanal/artifact/image.Artifact.Inspect
        /home/runner/work/trivy/trivy/pkg/fanal/artifact/image/image.go:127
  - failed to analyze layer:  :
    github.com/aquasecurity/trivy/pkg/fanal/artifact/image.Artifact.inspect.func1
        /home/runner/work/trivy/trivy/pkg/fanal/artifact/image/image.go:229
  - walk error:
    github.com/aquasecurity/trivy/pkg/fanal/artifact/image.Artifact.inspectLayer
        /home/runner/work/trivy/trivy/pkg/fanal/artifact/image/image.go:284
  - failed to process the file:
    github.com/aquasecurity/trivy/pkg/fanal/walker.LayerTar.Walk
        /home/runner/work/trivy/trivy/pkg/fanal/walker/tar.go:90
  - failed to analyze file:
    github.com/aquasecurity/trivy/pkg/fanal/walker.LayerTar.processFile
        /home/runner/work/trivy/trivy/pkg/fanal/walker/tar.go:104
  - failed to analyze config/libs/caffeine-3.1.1.jar:
    github.com/aquasecurity/trivy/pkg/fanal/artifact/image.Artifact.inspectLayer.func1
        /home/runner/work/trivy/trivy/pkg/fanal/artifact/image/image.go:279
  - unable to open config/libs/caffeine-3.1.1.jar:
    github.com/aquasecurity/trivy/pkg/fanal/analyzer.AnalyzerGroup.AnalyzeFile
        /home/runner/work/trivy/trivy/pkg/fanal/analyzer/analyzer.go:407
  - failed to open:
    github.com/aquasecurity/trivy/pkg/fanal/walker.(*cachedFile).Open
        /home/runner/work/trivy/trivy/pkg/fanal/walker/cached_file.go:65
  - unable to read the file:
    github.com/aquasecurity/trivy/pkg/fanal/walker.(*cachedFile).Open.func1
        /home/runner/work/trivy/trivy/pkg/fanal/walker/cached_file.go:58
  - read tcp 172.17.0.2:47252->130.35.129.83:443: read: connection reset by peer

The issue goes away when "--offline-scan" is being passed.

Is it alright to use "--offline-scan" parameter without compromising result quality?

[DmitriyLewen]

Hello @navzen2000

The problem seems to be in the caffeine-3.1.1.jar file inside libs/guava.jar: failed to open: This is not a problem with the maven repository. Also you need to update Trivy - so that Trivy doesn't stop scanning if there are any problems with banks(use debug flag to see these problems)

Is it alright to use "--offline-scan" parameter without compromising result quality?

If all your jars (and internal jars) have correct pom.properties or MANIFEST.MF -> --offline-scan flag will not affect you.

[navzen2000]

@DmitriyLewen Am already using v 0.36.1 Is there a newer version available?

[DmitriyLewen]

hmm...so weird... Can you create a new issue and submit this guava.jar for investigation?

[durcon]

@DmitriyLewen

Hello @navzen2000

I checked for a given jar file, all the above details are present in manifest.mf and pom.properties

perhaps there is no one field.

e.g. org.springframework.boot:spring-boot:2.3.10.RELEASE from @durcon post doesn't have GroupID.

I never saw a group ID in a MANIFEST.MF. Oracle didn't define such an entry, see Setting Package Version Information. Maven does not generate such an entry by default, see manifest.

What entry does Trivy use? Where is this entry defined?

[DmitriyLewen]

hello @kumarsandeep590 This is problem with maven repository. You can use the offline-scan flag, but there are some risks to doing so- https://github.com/aquasecurity/trivy/issues/3421#issuecomment-1381514618

@durcon take a look on #3427 we are talking about it here.

[Punkoivan]

There is no problem with trivy itself, it's a problem with maven central. I guess that the mirror could help with that, but it's a huge effort, since you have to keep it synced and you will want to sync only your deps, not the entire repo.

[dvdgsng]

guess that the mirror could help with that, but it's a huge effort, since you have to keep it synced and you will want to sync only your deps, not the entire repo.

It's quite common to have a local mirror of maven central on your network (e.g. Nexus). It's not required for trivy to mirror Maven central itself - it really should not. What's needed is a way to decouple trivy from search.maven.org and point trivy to other mirrors.

[Punkoivan]

It's quite common to have a local mirror of maven central on your network (e.g. Nexus). It's not required for trivy to mirror Maven central itself - it really should not. What's needed is a way to decouple trivy from search.maven.org and point trivy to other mirrors.

Exactly, for now we can try to use dirty hack and update local dns or hosts file, to point to the mirror, not central.

[durcon]

guess that the mirror could help with that, but it's a huge effort, since you have to keep it synced and you will want to sync only your deps, not the entire repo.

It's quite common to have a local mirror of maven central on your network (e.g. Nexus). It's not required for trivy to mirror Maven central itself - it really should not. What's needed is a way to decouple trivy from search.maven.org and point trivy to other mirrors.

I agree, but just turning it off is no solution. Changing the identification method will work for some more artifacts, but it isn't enough.

Maybe it is possible that the Trivy database contains a list of SHA-1 digest for each vulnerability, then Trivy doesn't need to use search.maven.org. The database creation script would call search.maven.org (or the downloaded index) for each artifact. It should do this only for new vulnerability or new artefact. Is that possible?

If this is not possible, it would be helpful to cache the responses (like database), see may comment: https://github.com/aquasecurity/trivy/issues/3421#issuecomment-1383836520

[knqyf263]

@bpfoster Thanks for the info. Do you know a way to convert the Lucene index to a format that can be easily parsed such as XML, JSON, etc.?

[bpfoster]

@bpfoster Thanks for the info. Do you know a way to convert the Lucene index to a format that can be easily parsed such as XML, JSON, etc.?

@knqyf263 The maven indexer project contains a (relatively) straightforward example of how to programmatically read the index (in Java). The example prints out fields to stdout but the same approach could be used to created a formatted file.

https://github.com/apache/maven-indexer/blob/a7aeb9f2fe34e6c9f5222bcc2e31f43442cdf99c/indexer-examples/indexer-examples-basic/src/main/java/org/apache/maven/indexer/examples/BasicUsageExample.java#L198-L217

[candrews]

How do other tools, such as Grype, derive the Maven coordinates from discovered jars?

[knqyf263]

@bpfoster Thanks. We started working on that. https://github.com/aquasecurity/trivy-java-db

@candrews We're not maintainers of Grype. Seems like they parse pom.properties like Trivy also does at first, but we're not sure.

[durcon]

How do other tools, such as Grype, derive the Maven coordinates from discovered jars?

@candrews They are parsing MANIFEST.MF. They use more headers than the current Trivy version. If they don't find version information they call search.maven.org. The difference (excepts more headers) is, that you can configure the catalog (something else than search.maven.org) and by default they are not calling any external service. You have to enable it.

[knqyf263]

They use more headers than the current Trivy version

Which header specifically? Most headers are already covered. As we discussed here, other headers will not help in many cases. Also, another issue is we need to verify the field values extracted from MANIFEST.MF are artifactID and groupID.

You have to enable it.

Package detection will be much less accurate without API calling. MANIFEST.MF and pom.properties are not standardized enough.

Anyway, we will build the index database.

[durcon]

@knqyf263

I was just answering the question, I don't know if it is neccessary to use more headers. And I agree that not calling the API is less accurate. If I had no problem with it, I would always use --offline-scan, but I do not use it.

[knqyf263]

I was just answering the question, I don't know if it is neccessary to use more headers.

Yes, thanks. If we're missing any important header, we want to add support for it. Please feel free to suggest anything.

[labsolam]

We've been investigating workarounds for this issue and I'm wondering if generating then using the sbom would give us comparable results? Will this suffer the same timeouts?

trivy image --format cyclonedx --list-all-pkgs <IMAGE_NAME> > sbom

trivy sbom --security-checks vuln --format table --exit-code 1 --ignore-unfixed --vuln-type os,library --severity CRITICAL,HIGH sbom

[dvdgsng]

Will this suffer the same timeouts?

Yes. You can verify it by adding --debug and --cache-dir /tmp/new-empty-cache to the trivy image command. The log shows DEBUG Parsing Java artifacts..., which means it contacts the maven central search API.

[wenqiglantz]

FYI, the intermittent timeout errors from search.maven.org has just been resolved, see their update https://status.maven.org/incidents/mblzqd69jjpz.

[DmitriyLewen]

@wenqiglantz unfortunately maven still has problems - https://status.maven.org/incidents/lfdx0m1kq3qt

[joshdilip]

We are also facing trivy image scan error due to timeout, below is the trace. Please let us know if we have any resolution for the same. We are blocked with this issue.

2023-01-23T05:27:14.060Z INFO Downloading DB... 36.18 MiB / 36.18 MiB [---------->] 100.00% ? p/s ?36.18 MiB / 36.18 MiB [-------------------------->] 100.00% ? p/s ?36.18 MiB / 2023-01-23T05:27:15.831Z INFO Vulnerability scanning is enabled 2023-01-23T05:27:15.831Z INFO Secret scanning is enabled 2023-01-23T05:27:15.831Z INFO If your scanning is slow, please try '--security-checks vuln' to disable secret scanning 2023-01-23T05:27:15.831Z INFO Please see also https://aquasecurity.github.io/trivy/v0.36/docs/secret/scanning/#recommendation for faster secret detection 2023-01-23T05:32:14.099Z WARN Increase --timeout value 2023-01-23T05:32:14.099Z FATAL image scan error: scan error: scan failed: failed analysis: analyze error: timeout: context deadline exceeded

[cpach]

We are also facing trivy image scan error due to timeout, below is the trace. Please let us know if we have any resolution for the same. We are blocked with this issue.

All info is in the thread above.

[ewqiew]

Suddenly from yesterday, only the Maven application has timed out. Has this been resolved already? Or is there still no solution? Trivy is the latest version.

[toming90]

Later last week, this issue seems fixed and our pipeline worked. However, from this morning, we again face this trivy scan timeout issue. search.maven.org was fixed according to a incident report yeesterday: https://status.maven.org/incidents/h6y6dpr1qp2c Anybody has similar experience?

[kyberorg]

@toming90 same here. Never had any problems with Trivy (both standalone and harbor). But starting from today almost half or scans failed with timeout.

[tanadeau]

@13CSherman I think that would be a great feature.

[candrews]

Would it be possible to add a flag to just switch to offline mode after 3 attempts and throw a warning in the end?

I think any flag that results in inconsistent behavior isn't a good idea. A given invocation of trivy should always produce the same result or it should fail.

[cpach]

With these search.maven.org persistent issues going on as of recent. Would it be possible to add a flag to just switch to offline mode after 3 attempts and throw a warning in the end? Defaulting to offline mode all the time doesn't seem ideal.

FWIW: If you really desire this behaviour and you invoke Trivy from a shell script, then you can implement a similar behaviour in the calling script.

[13CSherman]

Would it be possible to add a flag to just switch to offline mode after 3 attempts and throw a warning in the end?

I think any flag that results in inconsistent behavior isn't a good idea. A given invocation of trivy should always produce the same result or it should fail.

Agreed on this. The true solution would be for search maven to be stable or dependency on it removed(not recommended).

[exiett]

Can someone explain how Trivy checks if a given image is a Java image and takes the decision to invoke the Maven endpoint which seems to be going down this last week? Also...

Agreed on this. The true solution would be for search maven to be stable or dependency on it removed(not recommended).

Why is it not recommended to remove the Maven dependency? (Truly out of curiosity, does it plays a great part into Java vulnerabilities?)

[13CSherman]

Can someone explain how Trivy checks if a given image is a Java image and takes the decision to invoke the Maven endpoint which seems to be going down this last week? Also...

Agreed on this. The true solution would be for search maven to be stable or dependency on it removed(not recommended).

Why is it not recommended to remove the Maven dependency? (Truly out of curiosity, does it plays a great part into Java vulnerabilities?)

Correct me if I am wrong. I think we want to keep the maven search functionality as needed as mentioned above for jar identification method sake. Removing the maven search dependency doesn't really help unless there is a better way for jar identification as durcon mentioned above.

[StevDa86]

We have similar problems scanning with Trivy. It feels like only every 3-4 runs through. We were able to reproduce the problem with our own images as well as with public images. It is also always different files that Trivy seems to find sometimes and sometimes not.

Trivy Version 0.36.1

2023-01-31T11:42:52.372Z INFO Need to update DB 2023-01-31T11:42:52.372Z INFO DB Repository: ghcr.io/aquasecurity/trivy-db 2023-01-31T11:42:52.372Z INFO Downloading DB... 14.80 MiB / 36.40 MiB [------------------------>____] 40.66% ? p/s ?36.27 MiB / 36.40 MiB [------------------------------------------------------------>] 99.64% ? p/s ?36.40 MiB / 36.40 MiB [----------------------------------------------------------->] 100.00% ? p/s ?36.40 MiB / 36.40 MiB [---------------------------------------------->] 100.00% 35.94 MiB p/s ETA 0s36.40 MiB / 36.40 MiB [---------------------------------------------->] 100.00% 35.94 MiB p/s ETA 0s36.40 MiB / 36.40 MiB [---------------------------------------------->] 100.00% 35.94 MiB p/s ETA 0s36.40 MiB / 36.40 MiB [---------------------------------------------->] 100.00% 33.62 MiB p/s ETA 0s36.40 MiB / 36.40 MiB [---------------------------------------------->] 100.00% 33.62 MiB p/s ETA 0s36.40 MiB / 36.40 MiB [---------------------------------------------->] 100.00% 33.62 MiB p/s ETA 0s36.40 MiB / 36.40 MiB [-------------------------------------------------] 100.00% 20.49 MiB p/s 2.0s2023-01-31T11:42:55.344Z INFO Vulnerability scanning is enabled 2023-01-31T11:42:55.344Z INFO Secret scanning is enabled 2023-01-31T11:42:55.344Z INFO If your scanning is slow, please try '--security-checks vuln' to disable secret scanning 2023-01-31T11:42:55.344Z INFO Please see also https://aquasecurity.github.io/trivy/v0.36/docs/secret/scanning/#recommendation for faster secret detection 2023-01-31T11:44:16.099Z FATAL image scan error: scan error: scan failed: failed analysis: analyze error: failed to analyze layer: : walk error: failed to process the file: failed to analyze file: failed to analyze app/lib/jaxb-impl-2.3.5.jar: unable to open app/lib/jaxb-impl-2.3.5.jar: failed to open: unable to read the file: unexpected EOF

[cpach]

I see that a few people get the error message failed to open: unable to read the file: unexpected EOF. I wonder if that really has to do with the Maven API issue. It could be something entirely different.

Perhaps @knqyf263 or @DmitriyLewen could chime in?

I’m not 100% certain but it seems like that error message (i.e. failed to open: unable to read the file: unexpected EOF) should only occur for cachedFile objects – and therefore it should only apply to VMs or tar files – not jar files!? It could be that I’m missing something, but to me it seems suspicious to encounter this error messages in the context of a jar file.

[exiett]

Hey guys, just letting you know I'm still observing the timeout error in my pipeline flow. When running Trivy with --debug option enabled, I can observe that Trivy struggles while trying to call search.maven.org still:

2023-02-01T00:04:35.742Z    DEBUG   retrying request    {"request": "GET https://search.maven.org/solrsearch/select?q=1%3A%22053aae0415da5e4be7a7dfbae6d63880d0765b97%22&rows=1&wt=json (status: 504)", "timeout": "20s", "remaining": 5}
2023-02-01T00:04:36.282Z    DEBUG   retrying request    {"request": "GET https://search.maven.org/solrsearch/select?q=1%3A%228eed85a5337c7b4e84156cc0f3921930fb0d780b%22&rows=1&wt=json (status: 504)", "timeout": "20s", "remaining": 5}
.
.
.
2023-02-01T00:07:12.147Z    FATAL   image scan error:
    github.com/aquasecurity/trivy/pkg/commands/artifact.Run
        /home/runner/work/trivy/trivy/pkg/commands/artifact/run.go:397
  - scan error:
    github.com/aquasecurity/trivy/pkg/commands/artifact.(*runner).scanArtifact
        /home/runner/work/trivy/trivy/pkg/commands/artifact/run.go:257
  - scan failed:
    github.com/aquasecurity/trivy/pkg/commands/artifact.scan
        /home/runner/work/trivy/trivy/pkg/commands/artifact/run.go:588
  - failed analysis:
    github.com/aquasecurity/trivy/pkg/scanner.Scanner.ScanArtifact
        /home/runner/work/trivy/trivy/pkg/scanner/scan.go:[146](https://code.ifoodcorp.com.br/ifood/local-commerce/oms/connection/gateway-core/-/jobs/22925032#L146)
  - analyze error:
    github.com/aquasecurity/trivy/pkg/fanal/artifact/image.Artifact.Inspect
        /home/runner/work/trivy/trivy/pkg/fanal/artifact/image/image.go:127
  - timeout:
    github.com/aquasecurity/trivy/pkg/fanal/artifact/image.Artifact.inspect
        /home/runner/work/trivy/trivy/pkg/fanal/artifact/image/image.go:248
  - context deadline exceeded
[INFO] - Generating JSON report...
2023-02-01T00:12:12.456Z    FATAL   image scan error: scan error: scan failed: failed analysis: analyze error: timeout: context deadline exceeded

Maven status page reported a downtime of 23 minutes earlier today. Although the timeout, I can still make the request locally from my machine using an HTTP client just fine, with the request being answered in 1.5s:

[StevDa86]

We have similar problems scanning with Trivy. It feels like only every 3-4 runs through. We were able to reproduce the problem with our own images as well as with public images. It is also always different files that Trivy seems to find sometimes and sometimes not.

Trivy Version 0.36.1

2023-01-31T11:42:52.372Z �[34mINFO�[0m Need to update DB 2023-01-31T11:42:52.372Z �[34mINFO�[0m DB Repository: ghcr.io/aquasecurity/trivy-db 2023-01-31T11:42:52.372Z �[34mINFO�[0m Downloading DB... 14.80 MiB / 36.40 MiB [------------------------>____] 40.66% ? p/s ?36.27 MiB / 36.40 MiB [------------------------------------------------------------>] 99.64% ? p/s ?36.40 MiB / 36.40 MiB [----------------------------------------------------------->] 100.00% ? p/s ?36.40 MiB / 36.40 MiB [---------------------------------------------->] 100.00% 35.94 MiB p/s ETA 0s36.40 MiB / 36.40 MiB [---------------------------------------------->] 100.00% 35.94 MiB p/s ETA 0s36.40 MiB / 36.40 MiB [---------------------------------------------->] 100.00% 35.94 MiB p/s ETA 0s36.40 MiB / 36.40 MiB [---------------------------------------------->] 100.00% 33.62 MiB p/s ETA 0s36.40 MiB / 36.40 MiB [---------------------------------------------->] 100.00% 33.62 MiB p/s ETA 0s36.40 MiB / 36.40 MiB [---------------------------------------------->] 100.00% 33.62 MiB p/s ETA 0s36.40 MiB / 36.40 MiB [-------------------------------------------------] 100.00% 20.49 MiB p/s 2.0s2023-01-31T11:42:55.344Z �[34mINFO�[0m Vulnerability scanning is enabled 2023-01-31T11:42:55.344Z �[34mINFO�[0m Secret scanning is enabled 2023-01-31T11:42:55.344Z �[34mINFO�[0m If your scanning is slow, please try '--security-checks vuln' to disable secret scanning 2023-01-31T11:42:55.344Z �[34mINFO�[0m Please see also https://aquasecurity.github.io/trivy/v0.36/docs/secret/scanning/#recommendation for faster secret detection 2023-01-31T11:44:16.099Z �[31mFATAL�[0m image scan error: scan error: scan failed: failed analysis: analyze error: failed to analyze layer: : walk error: failed to process the file: failed to analyze file: failed to analyze app/lib/jaxb-impl-2.3.5.jar: unable to open app/lib/jaxb-impl-2.3.5.jar: failed to open: unable to read the file: unexpected EOF

Its very strange, i tested this image again this morning and the check was done successfully in about 20 seconds. So its not a trivy timeout issue. I also tested it on different Systems. The Problem is always the same and occurs twice a day.

[cpach]

Its very strange, i tested this image again this morning and the check was done successfully in about 20 seconds. So its not a trivy timeout issue. I also tested it on different Systems. The Problem is always the same and occurs twice a day.

See my comment above regarding EOF. My hunch is that for some reason Trivy attempts to treat jaxb-impl-2.3.5.jar as something other than a JAR file – however, I’m not able to verify if this hypothesis holds up. It would probably be a good idea to open a new issue for the EOF error, with a reference to the discussion here.

[knqyf263]

@cpach Thanks for the heads-up. @StevDa86 I created another issue. We're looking into it. https://github.com/aquasecurity/trivy/issues/3514

I've hidden your comments so that people who came to this issue can see relevant discussion. We can keep discussing this issue in #3514.

[knqyf263]

Thanks all for your patience. We managed to include the improvement in v0.37.0 🎉🎉 We're grateful for everyone who helped make it happen.

Trivy no longer relies on the third-party API and instead uses the pre-built database for Java scanning. The Java index database will be downloaded when JAR files are found. The scan results should be almost the same as before. You don't have to use --offline-scan anymore. You can see more detail below. https://github.com/aquasecurity/trivy/discussions/3518

It can be used even in air-gapped environments💯 https://aquasecurity.github.io/trivy/v0.37/docs/advanced/air-gap/#download-the-java-index-database1

[knqyf263]

It may have a critical issue. We're on it. https://github.com/aquasecurity/trivy/issues/3520

[canthony]

It may have a critical issue. We're on it. #3520

Oh no - I was just about to test it in our pipeline!

Thankyou for the quick notification though.

[markbaird]

It may have a critical issue. We're on it. #3520

It's working fine for me this morning. Both locally, and in AWS CodePipeline.

[knqyf263]

v0.37.0 has a critical issue. Please try v0.37.1 instead. https://github.com/aquasecurity/trivy/releases/tag/v0.37.1

[canthony]

v0.37.1 works for us

Thankyou.