Add Trivy container security scanning, fix ShellCheck targeting, update binary container and harden utility scripts

[Jmevorach]

Short description of what this resolves:

• Adds automated container vulnerability scanning for active Docker images, updates the ShellCheck workflow to use .shellcheck-skip marker files instead of hardcoded exclusions, and fixes all ShellCheck warnings in the utilities/ scripts.

Changes proposed in this pull request:

• Add new Trivy Security Scan CI workflow (.github/workflows/trivy.yml) that builds and scans the 8.0.1 and flex Docker images for CRITICAL/HIGH vulnerabilities, using --skip-dirs to scope scanning to OS packages and container-level dependencies rather than application code; includes SARIF upload to the GitHub Security tab
• Replace hardcoded ShellCheck exclusion lists with .shellcheck-skip marker files -- drop a single empty file in any directory to exclude it from scanning, with no workflow YAML changes needed
• Fix all ShellCheck warnings in utilities/openemr-env-installer, utilities/openemr-env-migrator, utilities/openemr-monitor/monitor-installer, and utilities/mariadb-backup-manager/install.sh (quoting variable expansions, direct exit-status consumption, ! a == b to a != b)
• Add Trivy Security Scan badge to README.md

[github-advanced-security]

This pull request sets up GitHub code scanning for this repository. Once the scans have completed and the checks have passed, the analysis results for this pull request branch will appear on this overview. Once you merge this pull request, the 'Security' tab will show more code scanning analysis results (for example, for the default branch). Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results. For more information about GitHub code scanning, check out the documentation.

[jesdynf]

This seems generally positive. Could you glance at the Trivy run https://github.com/openemr/openemr-devops/actions/runs/22650483911/job/65648544747?pr=572 and clear the warning, please? It wants a deprecated action updated, I think.

[Jmevorach]

@jesdynf Done -- bumped github/codeql-action/upload-sarif from v3 to v4.

[jesdynf]

Much obliged! I'm checking on something elsewhere before I pull this in.

[kojiromike]

Thanks for adding Trivy scanning and cleaning up the ShellCheck workflow. A few structural and correctness questions below.

The biggest concern is scope: the ShellCheck targeting fixes, shell script quoting fixes, and Trivy introduction are independent changes. Would it make sense to split this into at least two PRs — one for the ShellCheck/utility-script fixes and one for Trivy? That way the quoting fixes can land immediately without coupling to the Trivy discussion.

[Jmevorach]

@jesdynf
No problem happy to help anytime! Thanks for reviewing this.

@kojiromike
Thanks for reviewing this! Appreciate you and Asher's time on this.

That's a fair point about scope. I'm happy to split this if you feel strongly about it, but my rationale for keeping them together was that ShellCheck + Trivy represent the two remaining pieces needed to complete a baseline CI/CD security posture for the devops repo — ShellCheck for static analysis of our shell scripts, Trivy for container-level vulnerability scanning. They felt like a natural unit of work.

That said, if splitting would help get the ShellCheck fixes merged faster, I can pull those into a separate PR. Let me know your preference.

[Jmevorach]

Thanks for the thorough review, @kojiromike. I've pushed updates addressing your feedback:

• Refactored the skip-pattern loop to a case statement
• Scoped the Trivy if: conditions so the SARIF steps only run when the build succeeds (and the upload only runs when the SARIF file exists)
• Replaced the $? anti-pattern in install.sh with direct exit status consumption via --project-directory

On the broader points:

• PR split: Happy to split ShellCheck and Trivy into separate PRs if you'd prefer. I kept them together because they represent the last two pieces of a baseline CI security posture, but I understand the argument for decoupling them.
• Exclusion list scalability: The list shouldn't grow much — all future images will be based on 8.0.1, which passes ShellCheck cleanly. That said, a discovery-based approach (e.g., a marker file in frozen directories) would be cleaner long-term, and I'd be glad to explore that in a follow-up.
• .trivyignore.yaml scope: Good point about separation of concerns. Trivy and GitHub Code Scanning serve different purposes — Code Scanning analyzes source and dependency manifests, while Trivy scans the built container for OS packages and the full runtime dependency tree. The ignore file is currently dominated by app-level CVEs because the Alpine base is clean, which is the success case. I can look into using --skip-dirs to exclude vendor/ and node_modules/ so the app repo owns its own dependency vulns, which would shrink or eliminate this file.
• binary image omission: Intentional — I removed it because it depends on artifacts from a personal repo and would significantly expand the ignore list. Updated the PR description to reflect this.

[Jmevorach]

@kojiromike

Pushed the .shellcheck-skip marker file approach and removed all the hardcoded exclusions from the workflow YAML. ShellCheck is passing cleanly now -- the only source of truth for which directories to skip is the presence of a .shellcheck-skip file in that directory, so future changes are just a matter of adding or removing a single empty file.

Also, when I was re-reading my earlier comment I realized I was being redundant explaining Trivy -- you obviously know what it does; my bad. Appreciate the review feedback throughout, it's made this PR a lot better.

[Jmevorach]

@kojiromike @jesdynf

Re-added the binary image to the Trivy scan. Since we're now using --skip-dirs to scope scanning to OS packages and container-layer concerns only, the older OpenEMR version bundled in the binary image won't inflate the results.
I've also changed my mind on the binary forge — I'll continue maintaining it in its current location and will periodically commit updated builds to the binary container in openemr-devops. If the community ever wants to move the forge under the OpenEMR org I'm happy to do that, but in the meantime I'll keep it current so the binary image stays a viable deployment option rather than just a proof of concept.

[Jmevorach]

Updated the binary container to use the latest builds from openemr-static-binary-forge (OpenEMR 8.0.0, built 03/10/2026) and re-added it to the Trivy scan. Now that we're using --skip-dirs to scope Trivy to OS packages and container-layer concerns only, the binary image can be scanned cleanly without needing a long ignore list.
Going forward I'll continue maintaining the binary forge in its current location and will periodically commit updated builds here so the binary container stays current.