chore: applly image scan

[muhammad-tahir-nawaz]

Summary

Why

QA Report

• No QA report required

Integration Tests

• No integration tests required

Added

Edited

Dependencies

[Copilot]

Pull request overview

This PR updates the GitHub Actions CI/CD workflows to incorporate Trivy image scanning into the deployment pipeline and to simplify the existing Trivy+Go test workflow.

Changes:

• Removed PR-commenting steps (and elevated PR permissions) from the Trivy + Go tests workflow.
• Updated the deployment workflow to build the Docker image locally, run a Trivy image scan, then push the image if the scan passes.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
.github/workflows/trivy-go-tests.yaml	Removes PR comment/report steps and reduces permissions; keeps Trivy FS scan + Go unit test execution.
.github/workflows/deployment.yaml	Splits build/push into build → Trivy image scan → push to enforce vulnerability gating before publish.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[greptile-apps]

Greptile Summary

This PR introduces a "scan before push" pattern in the deployment workflow and removes the PR-comment surfacing logic from the filesystem scan workflow. The deployment flow now builds the Docker image locally, runs Trivy against it, and only pushes to the GCP registry if no CRITICAL/HIGH vulnerabilities are found.

• deployment.yaml: Build step switches to push: false + load: true, a Trivy image scan is inserted (CRITICAL/HIGH, exit-code: 1), and a plain docker push step follows — correctly gating registry writes behind the vulnerability check.
• trivy-go-tests.yaml: PR comment steps and the pull-requests: write permission are removed; Go tests are simplified to a single go test -v invocation (fixing the previous double-execution). However, output: 'trivy-results.txt' was left in the Trivy step with no replacement mechanism to surface the file, making scan failures opaque to developers.

Confidence Score: 3/5

The deployment workflow is safe; the filesystem scan workflow leaves scan failures opaque.

The deployment workflow correctly implements scan-before-push. The filesystem scan workflow removes the mechanism that made Trivy results visible without removing the file redirect, so developers cannot see what triggered a scan failure.

.github/workflows/trivy-go-tests.yaml — the output: 'trivy-results.txt' line needs to be removed or paired with an artifact upload step.

Important Files Changed

Filename	Overview
.github/workflows/deployment.yaml	Splits build+push into three steps (build locally, Trivy image scan, then push) so CRITICAL/HIGH vulnerabilities block the push. Logic is sound — load: true makes the image available to Trivy in the local Docker daemon before it reaches the registry.
.github/workflows/trivy-go-tests.yaml	Removes PR comment steps and simplifies Go test execution, but leaves output: 'trivy-results.txt' in place with no artifact upload — scan results become invisible when the job fails.

Sequence Diagram

%%{init: {'theme': 'neutral'}}%%
sequenceDiagram
    participant GH as GitHub Actions
    participant Docker as Docker Daemon
    participant Trivy as Trivy Scanner
    participant Registry as GCP Registry

    Note over GH: deployment.yaml (new flow)
    GH->>Docker: "docker/build-push-action (push=false, load=true)"
    Docker-->>GH: Image loaded locally
    GH->>Trivy: Scan local image (CRITICAL,HIGH)
    alt Vulnerabilities found
        Trivy-->>GH: exit-code 1 → job fails
        Note over Registry: Image never pushed
    else Clean scan
        Trivy-->>GH: exit-code 0
        GH->>Registry: docker push :latest
    end

    Note over GH: trivy-go-tests.yaml (new flow)
    GH->>Trivy: Scan filesystem (output→trivy-results.txt)
    alt Vulnerabilities found
        Trivy-->>GH: exit-code 1 → job fails
        Note over GH: Results in file only — not visible
    else Clean scan
        Trivy-->>GH: exit-code 0
    end
    GH->>GH: go test -v (stdout visible in logs)

Loading

%%{init: {'theme': 'base', 'themeVariables': {"darkMode": true, "background": "#0d1117", "primaryColor": "#21262d", "primaryTextColor": "#e6edf3", "primaryBorderColor": "#8b949e", "lineColor": "#8b949e", "textColor": "#e6edf3", "edgeLabelBackground": "#161b22", "actorBkg": "#21262d", "actorBorder": "#8b949e", "actorTextColor": "#e6edf3", "actorLineColor": "#8b949e", "signalColor": "#8b949e", "signalTextColor": "#e6edf3", "noteBkgColor": "#373320", "noteBorderColor": "#d4a72c", "noteTextColor": "#f0e6c0", "labelBoxBkgColor": "#21262d", "labelBoxBorderColor": "#8b949e", "labelTextColor": "#e6edf3", "loopTextColor": "#e6edf3", "activationBkgColor": "#30363d", "activationBorderColor": "#8b949e"}}}%%
sequenceDiagram
    participant GH as GitHub Actions
    participant Docker as Docker Daemon
    participant Trivy as Trivy Scanner
    participant Registry as GCP Registry

    Note over GH: deployment.yaml (new flow)
    GH->>Docker: "docker/build-push-action (push=false, load=true)"
    Docker-->>GH: Image loaded locally
    GH->>Trivy: Scan local image (CRITICAL,HIGH)
    alt Vulnerabilities found
        Trivy-->>GH: exit-code 1 → job fails
        Note over Registry: Image never pushed
    else Clean scan
        Trivy-->>GH: exit-code 0
        GH->>Registry: docker push :latest
    end

    Note over GH: trivy-go-tests.yaml (new flow)
    GH->>Trivy: Scan filesystem (output→trivy-results.txt)
    alt Vulnerabilities found
        Trivy-->>GH: exit-code 1 → job fails
        Note over GH: Results in file only — not visible
    else Clean scan
        Trivy-->>GH: exit-code 0
    end
    GH->>GH: go test -v (stdout visible in logs)

Loading

_{Reviews (1): Last reviewed commit: "chore: applly image scan" | Re-trigger Greptile}

[greptile-apps]

The output: 'trivy-results.txt' parameter redirects Trivy results to a file instead of stdout. The PR comment step that previously surfaced this file was removed, and no artifact-upload step replaced it. When the scan fails with exit-code: '1', developers will see the job fail but have no way to see which vulnerabilities triggered it — the results file is silently discarded at the end of the runner. Either remove output (letting results print to the workflow log) or add an actions/upload-artifact step so the file is retrievable.

Suggested change

	format: 'table'
	output: 'trivy-results.txt'
	severity: 'CRITICAL,HIGH,MEDIUM,LOW'
	format: 'table'
	severity: 'CRITICAL,HIGH,MEDIUM,LOW'