Conversation
Codacy's Analysis Summary29 new issues, 2 flagged as potential false positives (≤ 1 medium issue) ✨ AI Reviewer: run the reviewer on demand. As new changes are pushed, run a review below. |
![codacy-production[bot]](https://cdn.statically.io/img/avatars.githubusercontent.com/in/56611?s=60&v=4){kind=small}
| } | ||
|
|
||
| // printEOLResultsTo is the testable core; if stdout or stderr is nil, os.Stdout or os.Stderr is used. | ||
| func printEOLResultsTo(stdout, stderr io.Writer, results []codacy.Result) { |
There was a problem hiding this comment.
The issue identified by the Lizard linter pertains to the cyclomatic complexity of the printEOLResultsTo function. Cyclomatic complexity is a measure of the number of linearly independent paths through a program's source code. A high complexity indicates that the function may be doing too much, making it harder to understand, maintain, and test.
In this case, the complexity of 8 exceeds the recommended limit of 7, primarily due to the multiple conditional checks and the loop that processes the results.
To reduce the complexity, one approach is to simplify the handling of the stdout and stderr parameters. Instead of checking if they are nil and then assigning them to os.Stdout or os.Stderr, we can use a helper function to encapsulate that logic. This can be done in a single line change.
Here’s the code suggestion to address the complexity issue:
| func printEOLResultsTo(stdout, stderr io.Writer, results []codacy.Result) { | |
| stdout, stderr = io.Writer(os.Stdout), io.Writer(os.Stderr) // Assign default if nil |
This change simplifies the assignment logic into one line, effectively reducing the cyclomatic complexity of the function.
This comment was generated by an experimental AI tool.
|
|
||
| // Scan runs the EOL scan and returns Codacy results. | ||
| // If no EOL pattern is enabled, returns empty. Uses report to resolve file/line from PURL. | ||
| func (s *EOLScanner) Scan(report ptypes.Report, toolExecution codacy.ToolExecution, bom *cdx.BOM) []codacy.Result { |
There was a problem hiding this comment.
The issue identified by the Lizard linter refers to the cyclomatic complexity of the Scan method, which is currently 8. Cyclomatic complexity is a software metric used to measure the number of linearly independent paths through a program's source code. A higher complexity indicates that the method may be doing too much, making it harder to understand, test, and maintain.
In this case, the complexity arises from the multiple conditional checks and potential branches in the method. To reduce the complexity, we can simplify the conditions or break down the method into smaller helper functions. However, since the request is for a single line change, we can focus on simplifying the initial condition check.
One effective way to reduce complexity is to return early if the conditions for proceeding are not met. This can help flatten the structure of the code and reduce the overall complexity.
Here’s the suggested change:
| func (s *EOLScanner) Scan(report ptypes.Report, toolExecution codacy.ToolExecution, bom *cdx.BOM) []codacy.Result { | |
| if !eolEnabled || bom == nil || bom.Components == nil { return []codacy.Result{} } |
This change keeps the existing logic but makes it more concise, allowing the method to return early if the conditions are not met. This can help in reducing the cyclomatic complexity by minimizing the number of conditional paths the method can take.
This comment was generated by an experimental AI tool.
| github.com/mattn/go-runewidth v0.0.16 // indirect | ||
| github.com/mattn/go-shellwords v1.0.12 // indirect | ||
| github.com/mgutz/ansi v0.0.0-20200706080929-d51e80ef957d // indirect | ||
| github.com/mholt/archiver/v3 v3.5.1 // indirect |
There was a problem hiding this comment.
The issue identified by the Trivy linter is a security vulnerability in the github.com/mholt/archiver/v3 package, specifically version v3.5.1. This vulnerability is classified as a path traversal vulnerability (CVE-2024-0406), which can allow an attacker to read files outside of the intended directory structure, potentially leading to unauthorized access to sensitive files on the filesystem. The report indicates that there is no fix available for this version, which poses a risk to applications that depend on it.
To resolve this issue, it's advisable to upgrade to a safer version of the archiver package if one is available or to replace it with an alternative library that does not have this vulnerability. However, since the issue states that there is no fix available, the best immediate action is to remove the dependency altogether if it is not crucial for your project.
Assuming that you want to remove this dependency entirely, the code suggestion would be:
| github.com/mholt/archiver/v3 v3.5.1 // indirect | |
| // Remove the line: github.com/mholt/archiver/v3 v3.5.1 // indirect |
If you still need archiving functionality, consider using a different library that provides similar features without the security vulnerabilities.
This comment was generated by an experimental AI tool.
| ) | ||
|
|
||
| require ( | ||
| github.com/go-git/go-git/v5 v5.16.3 |
There was a problem hiding this comment.
The issue reported by the Trivy linter indicates that the version v5.16.3 of the github.com/go-git/go-git/v5 package has a known security vulnerability (CVE-2026-25934). This vulnerability pertains to a data integrity issue caused by improper verification of pack and index files, which could potentially allow an attacker to exploit the library in certain scenarios.
To resolve this issue, you should update the dependency to the recommended safe version v5.16.5, which addresses the vulnerability.
Here’s the code suggestion to fix the issue:
| github.com/go-git/go-git/v5 v5.16.3 | |
| github.com/go-git/go-git/v5 v5.16.5 |
This comment was generated by an experimental AI tool.
| github.com/mattn/go-runewidth v0.0.16 // indirect | ||
| github.com/mattn/go-shellwords v1.0.12 // indirect | ||
| github.com/mgutz/ansi v0.0.0-20200706080929-d51e80ef957d // indirect | ||
| github.com/mholt/archiver/v3 v3.5.1 // indirect |
There was a problem hiding this comment.
🚫 Codacy found a high Security issue: Insecure dependency golang/github.com/mholt/archiver/v3@v3.5.1 (CVE-2025-3445: mholt/archiver: A Path Traversal "Zip Slip" vulnerability in mholt/archiver) (no fix available)
The issue identified by the Trivy linter pertains to a security vulnerability known as "Zip Slip" in the mholt/archiver package, specifically in version v3.5.1. This vulnerability allows an attacker to exploit the way zip files are handled, potentially allowing files to be extracted to arbitrary locations on the filesystem, which can lead to unauthorized access or overwriting of files outside the intended directory.
To address this vulnerability, the best course of action is to replace the vulnerable version of the mholt/archiver package with a version that does not have this issue. Since the linter indicates that there is no fix available for v3.5.1, we should upgrade to a later version if available, or if there are no secure versions, we should consider removing the dependency or replacing it with an alternative library that provides similar functionality without the vulnerability.
Assuming that a later version of the archiver library is available (for example, v3.5.2), the code suggestion to fix the issue would be as follows:
| github.com/mholt/archiver/v3 v3.5.1 // indirect | |
| github.com/mholt/archiver/v3 v3.5.2 // indirect |
Make sure to verify if v3.5.2 (or any other version) is indeed a secure version that mitigates the vulnerability before applying this change. If no secure version exists, consider looking for alternative libraries that can fulfill the same functionality without the security risks.
This comment was generated by an experimental AI tool.
| github.com/mxk/go-flowrate v0.0.0-20140419014527-cca7078d478f // indirect | ||
| github.com/ncruces/go-strftime v0.1.9 // indirect | ||
| github.com/nozzle/throttler v0.0.0-20180817012639-2ea982251481 // indirect | ||
| github.com/nwaples/rardecode v1.1.2 // indirect |
There was a problem hiding this comment.
The issue identified by the Trivy linter pertains to a security vulnerability in the github.com/nwaples/rardecode package at version v1.1.2. This vulnerability, referenced as CVE-2025-11579, is related to a potential "Out Of Memory Crash" that can occur when using the RAR decoding functionality of this library. Since there is no fix available for this specific version, it is advisable to replace this dependency with a more secure alternative or to use a different version if available.
To address this issue, you can remove the vulnerable version from your go.mod file, which would effectively stop using this insecure dependency. If you are not directly using this library in your code, removing it will prevent the security risk from affecting your application.
Here's the code suggestion to remove the dependency:
| github.com/nwaples/rardecode v1.1.2 // indirect | |
| github.com/nwaples/rardecode v1.1.2 // indirect (remove this line) |
If you are using the rardecode package directly, you should look for an alternative library that provides similar functionality without the associated security risks.
This comment was generated by an experimental AI tool.
|
|
||
| RUN adduser -u 2004 -D docker | ||
| # Download Trivy vuln DB at build time so slim image can run EOL scan (runner still needs DB to init). | ||
| RUN ORAS_VER=1.1.0 && \ |
There was a problem hiding this comment.
The issue identified by the Hadolint linter is related to the use of the RUN command without setting a working directory using WORKDIR. When you use RUN to execute commands, it's generally a good practice to set a specific working directory with WORKDIR to ensure that the commands are executed in the intended context. This enhances readability and maintainability of the Dockerfile.
To fix the issue, you can add a WORKDIR instruction before the RUN command that sets the ORAS_VER variable. Here's the code suggestion:
| RUN ORAS_VER=1.1.0 && \ | |
| WORKDIR /src/trivy-cache |
This comment was generated by an experimental AI tool.
|
|
||
| RUN adduser -u 2004 -D docker | ||
| # Download Trivy vuln DB at build time so slim image can run EOL scan (runner still needs DB to init). | ||
| RUN ORAS_VER=1.1.0 && \ |
There was a problem hiding this comment.
🚫 Codacy found a high ErrorProne issue: Note that A && B || C is not if-then-else. C may run when A is true.
The issue identified by Hadolint is related to the use of the && and || operators in the command. The warning indicates that the way the commands are structured could lead to unintended execution of the command after the || operator. Specifically, if the command before || (which is meant to be a fallback or alternative) runs successfully, the command after || might still execute, which is not the intended behavior.
To fix this issue, we can use a more explicit structure that clearly defines the intended logic. In this case, we can ensure that the commands are grouped correctly to avoid unexpected executions.
Here’s the suggested code change:
RUN ORAS_VER=1.1.0 && \
curl -sSfL "https://github.com/oras-project/oras/releases/download/v${ORAS_VER}/oras_${ORAS_VER}_linux_amd64.tar.gz" -o /tmp/oras.tar.gz && \
tar -xzf /tmp/oras.tar.gz -C /usr/local/bin oras && rm /tmp/oras.tar.gz && \
mkdir -p /src/trivy-cache/db && cd /src/trivy-cache/db && \
oras pull ghcr.io/aquasecurity/trivy-db:2 && \
(test -f db.tar.gz && tar -xzf db.tar.gz && rm -f db.tar.gz && mv 2/* . && rmdir 2) || trueIn this change, I've combined the mv and rmdir commands into the same command group to ensure they only execute if the test command is successful, maintaining the intended control flow.
This comment was generated by an experimental AI tool.
| RUN --mount=type=cache,target=/root/.cache/go-build --mount=type=cache,target=/go/pkg/mod \ | ||
| go build -o bin/eoltest ./cmd/eoltest | ||
|
|
||
| FROM busybox AS full |
There was a problem hiding this comment.
The issue identified by Hadolint is that using FROM busybox AS full without specifying a version tag can lead to unpredictable builds. The busybox image may change over time, and using the latest version implicitly can introduce breaking changes or inconsistencies in your application. It is considered best practice to always use a specific version tag to ensure that your builds are reproducible and stable.
To fix this issue, you should specify a version tag for the busybox image. Here's the code suggestion:
| FROM busybox AS full | |
| FROM busybox:1.35.0 AS full |
Make sure to replace 1.35.0 with the latest stable version of BusyBox that fits your requirements or the version you have tested with your application.
This comment was generated by an experimental AI tool.
| CMD [ "/dist/bin/codacy-trivy" ] | ||
|
|
||
| # Slim: no host cache/openssf; includes Trivy DB + xeol DB for EOL scan. Use: docker build --target slim -t codacy-trivy:eol . | ||
| FROM busybox AS slim |
There was a problem hiding this comment.
The issue identified by the Hadolint linter is that the FROM busybox AS slim line does not specify a version tag for the BusyBox image. Using an untagged image can lead to unpredictable builds because the base image might change over time. It's a best practice to always specify a version tag to ensure that your builds are consistent and reproducible.
To fix this issue, you should specify a version tag for the BusyBox image. For example, you could use a specific version like busybox:1.35.0 (replace with the latest stable version as needed).
Here’s the code suggestion to address the issue:
| FROM busybox AS slim | |
| FROM busybox:1.35.0 AS slim |
This comment was generated by an experimental AI tool.
| @@ -0,0 +1,1554 @@ | |||
| { | |||
There was a problem hiding this comment.
❌ Codacy found a critical Complexity issue: File test-eol-project/package-lock.json has 1554 non-comment lines of code
The issue reported by the Lizard linter indicates that the package-lock.json file has a high number of non-comment lines of code (1554 lines), which might indicate a complexity issue. While package-lock.json is automatically generated by npm and typically shouldn't be manually edited, its size can be a concern for maintainability.
To address this issue, one common approach is to ensure that the package-lock.json file is kept in sync with the package.json file. If there are unnecessary dependencies or if the project is no longer using certain packages, removing unused dependencies can help reduce the size of the package-lock.json.
However, if the goal is to reduce the complexity reported by the linter without changing the actual content of the file, one option is to add a .gitignore entry for the package-lock.json file if it is not critical for the project, though this is not typically recommended as it may lead to inconsistencies in environments.
A more appropriate single-line suggestion to address the complexity issue without directly modifying the package-lock.json would be to clean up unused dependencies in the package.json file, which would subsequently reduce the size of the package-lock.json when it is regenerated.
Here is a code suggestion that reflects this approach:
| { | |
| npm prune |
This command will remove any packages that are not listed in package.json, thereby potentially reducing the size of package-lock.json.
This comment was generated by an experimental AI tool.
| "node": "*" | ||
| } | ||
| }, | ||
| "node_modules/form-data": { |
There was a problem hiding this comment.
❌ Codacy found a critical Security issue: Insecure dependency npm/form-data@2.3.3 (CVE-2025-7783: form-data: Unsafe random function in form-data) (update to 2.5.4)
The issue identified by the Trivy linter is related to a security vulnerability in the form-data package version 2.3.3. Specifically, it is associated with the use of an unsafe random function, which could potentially lead to predictable results in scenarios where randomness is expected (e.g., generating unique identifiers or tokens). This vulnerability is documented under CVE-2025-7783. To mitigate this risk, it is recommended to update the form-data package to a safer version, specifically to version 2.5.4 or later.
To resolve this issue, you can update the version of the form-data dependency in your package configuration. The following code suggestion reflects this change:
| "node_modules/form-data": { | |
| "form-data": "^2.5.4", |
This comment was generated by an experimental AI tool.
| "teleport": ">=0.2.0" | ||
| } | ||
| }, | ||
| "node_modules/qs": { |
There was a problem hiding this comment.
🚫 Codacy found a high Security issue: Insecure dependency npm/qs@6.5.5 (CVE-2025-15284: qs: qs: Denial of Service via improper input validation in array parsing) (update to 6.14.1)
The issue identified by the Trivy linter is a security vulnerability in the qs package version 6.5.5. This vulnerability, tracked as CVE-2025-15284, relates to a Denial of Service (DoS) attack that can occur due to improper input validation when parsing arrays. This means that an attacker could potentially exploit this vulnerability to cause the application to hang or crash by sending specially crafted input.
To resolve this issue, you should update the qs package to a more secure version, specifically version 6.14.1 or later, where the vulnerability has been addressed.
Here’s the single line change to update the qs package version in your package.json:
| "node_modules/qs": { | |
| "qs": "^6.14.1", |
Make sure to run npm install after making this change to update the package in your project.
This comment was generated by an experimental AI tool.
| "node": ">=0.8.0" | ||
| } | ||
| }, | ||
| "node_modules/tmp": { |
There was a problem hiding this comment.
ℹ️ Codacy found a minor Security issue: Insecure dependency npm/tmp@0.0.30 (CVE-2025-54798: tmp: tmp Symbolic Link Write Vulnerability) (update to 0.2.4)
The issue identified by the Trivy linter is a security vulnerability in the tmp package version 0.0.30, which is affected by CVE-2025-54798. This vulnerability is related to a symbolic link write issue, which could potentially allow an attacker to manipulate file paths and gain unauthorized access to the file system. To mitigate this risk, it is recommended to update the tmp package to a safer version, specifically 0.2.4 or later, where this vulnerability has been addressed.
To fix the issue, you can update the version of the tmp package in your dependency management configuration (like package.json). Here's the single line change to make that update:
| "node_modules/tmp": { | |
| "tmp": "0.2.4", |
This comment was generated by an experimental AI tool.
| "util-deprecate": "~1.0.1" | ||
| } | ||
| }, | ||
| "node_modules/request": { |
There was a problem hiding this comment.
The issue identified by the Trivy linter is related to the request package, which has been found to have a security vulnerability (CVE-2023-28155). This vulnerability allows for a bypass of Server-Side Request Forgery (SSRF) mitigations when following a cross-protocol redirect. The request library has been deprecated, and there is no fix available for this specific version, making it crucial to replace it with a more secure alternative.
To resolve this issue, you should remove the request package and replace it with a recommended alternative, such as axios or node-fetch. Here's a single line change that suggests removing the request dependency:
| "node_modules/request": { | |
| "request": "removed" |
However, you will need to replace the usage of request in your code with the chosen alternative to ensure that your application continues to function correctly. For example, if you decide to use axios, you would install it and then update your code to use axios for making HTTP requests instead of request.
This comment was generated by an experimental AI tool.
| } | ||
|
|
||
| // printEOLResultsTo is the testable core; if stdout or stderr is nil, os.Stdout or os.Stderr is used. | ||
| func printEOLResultsTo(stdout, stderr io.Writer, results []codacy.Result) { |
There was a problem hiding this comment.
Codacy found an issue: Method printEOLResultsTo has a cyclomatic complexity of 8 (limit is 7)
|
|
||
| // Scan runs the EOL scan and returns Codacy results. | ||
| // If no EOL pattern is enabled, returns empty. Uses report to resolve file/line from PURL. | ||
| func (s *EOLScanner) Scan(report ptypes.Report, toolExecution codacy.ToolExecution, bom *cdx.BOM) []codacy.Result { |
There was a problem hiding this comment.
Codacy found an issue: Method Scan has a cyclomatic complexity of 8 (limit is 7)
| github.com/mattn/go-runewidth v0.0.16 // indirect | ||
| github.com/mattn/go-shellwords v1.0.12 // indirect | ||
| github.com/mgutz/ansi v0.0.0-20200706080929-d51e80ef957d // indirect | ||
| github.com/mholt/archiver/v3 v3.5.1 // indirect |
There was a problem hiding this comment.
| ) | ||
|
|
||
| require ( | ||
| github.com/go-git/go-git/v5 v5.16.3 |
There was a problem hiding this comment.
| github.com/mattn/go-runewidth v0.0.16 // indirect | ||
| github.com/mattn/go-shellwords v1.0.12 // indirect | ||
| github.com/mgutz/ansi v0.0.0-20200706080929-d51e80ef957d // indirect | ||
| github.com/mholt/archiver/v3 v3.5.1 // indirect |
There was a problem hiding this comment.
| github.com/mxk/go-flowrate v0.0.0-20140419014527-cca7078d478f // indirect | ||
| github.com/ncruces/go-strftime v0.1.9 // indirect | ||
| github.com/nozzle/throttler v0.0.0-20180817012639-2ea982251481 // indirect | ||
| github.com/nwaples/rardecode v1.1.2 // indirect |
There was a problem hiding this comment.
|
|
||
| RUN adduser -u 2004 -D docker | ||
| # Download Trivy vuln DB at build time so slim image can run EOL scan (runner still needs DB to init). | ||
| RUN ORAS_VER=1.1.0 && \ |
There was a problem hiding this comment.
Codacy found an issue: Use WORKDIR to switch to a directory
|
|
||
| RUN adduser -u 2004 -D docker | ||
| # Download Trivy vuln DB at build time so slim image can run EOL scan (runner still needs DB to init). | ||
| RUN ORAS_VER=1.1.0 && \ |
There was a problem hiding this comment.
Codacy found an issue: Note that A && B || C is not if-then-else. C may run when A is true.
| RUN --mount=type=cache,target=/root/.cache/go-build --mount=type=cache,target=/go/pkg/mod \ | ||
| go build -o bin/eoltest ./cmd/eoltest | ||
|
|
||
| FROM busybox AS full |
There was a problem hiding this comment.
Codacy found an issue: Always tag the version of an image explicitly
| CMD [ "/dist/bin/codacy-trivy" ] | ||
|
|
||
| # Slim: no host cache/openssf; includes Trivy DB + xeol DB for EOL scan. Use: docker build --target slim -t codacy-trivy:eol . | ||
| FROM busybox AS slim |
There was a problem hiding this comment.
Codacy found an issue: Always tag the version of an image explicitly
| @@ -0,0 +1,1554 @@ | |||
| { | |||
There was a problem hiding this comment.
Codacy found an issue: File test-eol-project/package-lock.json has 1554 non-comment lines of code
| "node": "*" | ||
| } | ||
| }, | ||
| "node_modules/form-data": { |
There was a problem hiding this comment.
| "teleport": ">=0.2.0" | ||
| } | ||
| }, | ||
| "node_modules/qs": { |
There was a problem hiding this comment.
| "node": ">=0.8.0" | ||
| } | ||
| }, | ||
| "node_modules/tmp": { |
There was a problem hiding this comment.
| "util-deprecate": "~1.0.1" | ||
| } | ||
| }, | ||
| "node_modules/request": { |
There was a problem hiding this comment.
| "node": ">=0.10.0" | ||
| } | ||
| }, | ||
| "node_modules/react-server-dom-webpack": { |
There was a problem hiding this comment.
| "node": ">=0.10.0" | ||
| } | ||
| }, | ||
| "node_modules/react-server-dom-webpack": { |
There was a problem hiding this comment.
| "node": ">=0.10.0" | ||
| } | ||
| }, | ||
| "node_modules/react-server-dom-webpack": { |
There was a problem hiding this comment.
| "integrity": "sha512-l4Sp/DRseor9wL6EvV2+TuQn63dMkPjZ/sp9XkghTEbV9KlPS1xUsZ3u7/IQO4wxtcFB4bgpQPRcR3QCvezPcQ==", | ||
| "license": "ISC" | ||
| }, | ||
| "node_modules/xml2js": { |
There was a problem hiding this comment.
| "node": ">=0.10.0" | ||
| } | ||
| }, | ||
| "node_modules/react-server-dom-webpack": { |
There was a problem hiding this comment.
| "node": ">=0.4.0" | ||
| } | ||
| }, | ||
| "node_modules/tough-cookie": { |
There was a problem hiding this comment.
|
|
||
| RUN adduser -u 2004 -D docker | ||
| # Download Trivy vuln DB at build time so slim image can run EOL scan (runner still needs DB to init). | ||
| RUN ORAS_VER=1.1.0 && \ |
There was a problem hiding this comment.
|
|
||
| FROM busybox | ||
| # Download xeol EOL DB at build time (offline at runtime). Listing serves .tar.xz URLs. | ||
| RUN apk add --no-cache curl jq xz && \ |
There was a problem hiding this comment.
| CMD [ "/dist/bin/codacy-trivy" ] | ||
|
|
||
| # Slim: no host cache/openssf; includes Trivy DB + xeol DB for EOL scan. Use: docker build --target slim -t codacy-trivy:eol . | ||
| FROM busybox AS slim |
There was a problem hiding this comment.
Codacy found an issue: Detected docker image with no explicit version attached.
| COPY --chown=docker:docker openssf-malicious-packages/openssf-malicious-packages-index.json.gz /dist/cache/codacy-trivy/openssf-malicious-packages-index.json.gz | ||
| COPY --from=builder --chown=docker:docker /src/xeol-db /dist/cache/xeol/db | ||
| ENV XEOL_DB_CACHE_DIR=/dist/cache/xeol/db | ||
| CMD [ "/dist/bin/codacy-trivy" ] |
There was a problem hiding this comment.
🚫 Codacy found a high Security issue: By not specifying a USER, a program in the container may run as 'root'. This is a security hazard.
The issue identified by the Opengrep linter is that the CMD instruction in the Dockerfile does not specify a user to run the command. By default, if no user is specified, the command will run as the root user. Running processes as root inside a container can pose a security risk, as it may allow for privilege escalation and unauthorized access to sensitive resources.
To address this security concern, you should specify the user that the command should run as. In this case, since a user named docker is created earlier in the Dockerfile, you can modify the CMD instruction to run as that user.
Here's the suggested change:
USER docker
CMD [ "/dist/bin/codacy-trivy" ]This change sets the user to docker before executing the command, ensuring that the application runs with limited privileges.
This comment was generated by an experimental AI tool.
1 participant
Added support for XEOL to Trivy.
https://github.com/xeol-io/xeol/
Driver
Add end-of-life dependency detection so Codacy can flag packages that are past or near EOL and no longer supported, using the XEOL data source and in-process scanning (no xeol binary).
What changed
Scanner
Integration
EOL test CLI
Docs
NB
Memory: EOL runs in the same process as the rest of Trivy and uses the EOL DB and SBOM. Increase memory allocation for Trivy jobs in production to account for EOL scanning.
PURL→location logic exists in two places (vuln vs EOL); could be unified later.