fix(security): Remove Hard Fail from Trivy

[justin-tahara]

Description

[Provide a brief description of the changes in this PR]
In my retry PR I added an --exit-code 1 which is doing the correct thing of hard failing the check if there are High and Critical Vulnerabilities found in our code.

In order to unblock the queue and get things built and uploaded, going to remove this flag for now and add it back in when we are able to properly address this and dedicate time to fixing each CVE that is identified.

This is a combination of either adding to our trivy ignore file or properly addressing each CVE which is a non-trivial amount of work.

How Has This Been Tested?

[Describe the tests you ran to verify your changes]

Backporting (check the box to trigger backport action)

Note: You have to check that the action passes, otherwise resolve the conflicts manually and tag the patches.

• This PR should be backported (make sure to check that the backport attempt succeeds)
• [Optional] Override Linear Check

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Preview	Comments	Updated (UTC)
internal-search	Ready	Preview	Comment	Sep 11, 2025 5:29pm

[cubic-dev-ai]

No issues found across 4 files

[greptile-apps]

Greptile Summary

This PR removes the --exit-code 1 flag from Trivy vulnerability scanner configurations across four GitHub Actions workflows that build and publish Docker images for different components of the Onyx application (backend, model server, web, and cloud-web containers). The Trivy scanner is a security tool that scans Docker images for known vulnerabilities and assigns severity levels.

Previously, the --exit-code 1 flag caused the CI/CD pipeline to fail hard when HIGH or CRITICAL severity vulnerabilities were detected in the Docker images, preventing the build and deployment process from completing. By removing this flag, the vulnerability scanning still occurs and reports findings, but no longer blocks the pipeline when vulnerabilities are found.

These workflow files are part of Onyx's automated Docker image building process that triggers when tags are pushed to the repository. The workflows handle multi-platform builds (linux/amd64 and linux/arm64), authentication to Docker Hub, image building with proper metadata, and security scanning. The change affects the final step of each workflow where Trivy performs vulnerability assessment on the newly built images.

This modification maintains the security scanning functionality while removing the enforcement mechanism, allowing the development team to continue deploying while they work on addressing the underlying security issues through either proper CVE remediation or updating the Trivy ignore file.

Confidence score: 2/5

• This PR significantly weakens security enforcement by allowing images with HIGH/CRITICAL vulnerabilities to be deployed to production
• Score reflects the high risk of deploying vulnerable containers to production environments, even though the change itself is technically straightforward
• Pay close attention to all four workflow files as they collectively handle the entire Docker image publication pipeline for the application

Context used:

Rule - Remove temporary debugging code before merging to production, especially tenant-specific debugging logs. (link)

_{4 files reviewed, no comments}

_{Edit Code Review Bot Settings | Greptile}