ENH: Add vulnerability scan workflow with grype

.github/workflows/grype.yml

@@ -0,0 +1,38 @@
+name: Vulnerability scans
+
+on:
+  push:
+    branches:
+      - main
+    paths:
+      - 'pixi.lock'
+      - '.github/workflows/grype.yml'
+  pull_request:
+    paths:
+      - 'pixi.lock'
+      - '.github/workflows/grype.yml'
+  schedule:
+  # Sunday at 01:59 UTC
+  - cron: '59 01 * * 0'
+  workflow_dispatch:
+
+concurrency:
+  group: ${{ github.workflow }}-${{ github.ref }}
+  cancel-in-progress: true
+
+jobs:
+  grype-scan:
+    name: "Scan action pixi environment"
+    runs-on: ubuntu-latest
+
+    steps:
+      - uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd  # v6.0.2
+
+      - name: Set up pixi
+        uses: prefix-dev/setup-pixi@1b2de7f3351f171c8b4dfeb558c639cb58ed4ec0  # v0.9.5
+
+      - name: Scan with grype (for all vulnerabilities)
+        run: pixi exec grype .pixi/envs/default --fail-on critical
+
+      - name: Scan with grype (for fixed vulnerabilities)
+        run: pixi exec grype .pixi/envs/default --only-fixed --fail-on high

MAINTAINERS.md

@@ -0,0 +1,46 @@
+# upload-nightly-action Maintainer Notes
+
+## Grype security scans in CI
+
+[`grype`](https://github.com/anchore/grype) is used to perform scheduled security scans of the `upload-nightly-action` Pixi environment in CI.
+In the event that the scan fails, a maintainer should:
+
+1. Check to see if the detected vulnerability can be avoided by upgrading dependencies with
+
+```
+pixi upgrade
+```
+
+2. If the `pixi.lock` has been updated by this action, then the offending packages should be checked for updates with `pixi list` and the `grype` scan should be repeated with
+
+```
+pixi run grype
+```
+
+3. If the `pixi.lock` lock file is not updated try resolving the lock file fresh with
+
+```
+pixi reinstall
+```
+
+or by
+
+```
+rm pixi.lock && pixi lock
+```
+
+and then running the scan again
+
+
+```
+pixi run grype
+```
+
+4. If the `pixi.lock` lock file is still not updated with fixes to the offending packages, then the changes to the `pixi.toml` Pixi manifest and `pixi.lock` lock file can be ignored/reverted and a maintainer should open up a tracking GitHub issue that reports the vulnerability and summarizes their understanding of the root cause of the vulnerability being introduced to the environment.
+`pixi tree --invert` may help with this.
+
+Example:
+
+```
+pixi tree --invert openssl
+```