ci/docs: add vulnerability scanning workflow & security policy (#3106)

.github/workflows/generic_vulnerability-scan.yml

@@ -0,0 +1,70 @@
+# This workflow checks out code, re-builds an image from cache, performs a container image
+# vulnerability scan with Anchore's Grype tool, and integrates the results with GitHub
+# Advanced Security code scanning feature.
+#
+# For more information on the Anchore scan action usage and parameters, see
+# https://github.com/anchore/scan-action. For more information on Anchore's container
+# image scanning tool Grype, see https://github.com/anchore/grype.
+name: "Anchore Grype Vulnerability Scan"
+
+on:
+  workflow_call:
+    inputs:
+      cache-key:
+        required: true
+        type: string
+
+permissions:
+  contents: read
+
+jobs:
+  scan-image:
+    permissions:
+      contents: read         # for actions/checkout to fetch code
+      security-events: write # for github/codeql-action/upload-sarif to upload SARIF results
+    runs-on: ubuntu-22.04
+    steps:
+      - name: 'Checkout'
+        uses: actions/checkout@v3
+
+      # Get the cached build layers from the build job:
+      # This should always be a cache-hit, thus `restore-keys` fallback is not used.
+      # No new cache uploads should ever happen for this job.
+      - name: 'Retrieve image built from build cache'
+        uses: actions/cache@v3
+        with:
+          path: /tmp/.buildx-cache
+          key: cache-buildx-${{ inputs.cache-key }}
+
+      # Configures buildx to use `docker-container` driver,
+      # Ensures consistent BuildKit version (not coupled to Docker Engine),
+      # and increased compatibility of the build cache vs mixing buildx drivers.
+      - name: 'Set up Docker Buildx'
+        uses: docker/setup-buildx-action@v2.4.1
+
+      # Importing from the cache should create the image within approx 30 seconds:
+      # NOTE: `qemu` step is not needed as we only test for AMD64.
+      - name: 'Build AMD64 image from cache'
+        uses: docker/build-push-action@v4.0.0
+        with:
+          context: .
+          tags: mailserver-testing:ci
+          # Export the built image to the Docker host for later use:
+          load: true
+          # Rebuilds the AMD64 image from the cache:
+          platforms: linux/amd64
+          cache-from: type=local,src=/tmp/.buildx-cache
+          # Disable provenance attestation: https://docs.docker.com/build/attestations/slsa-provenance/
+          provenance: false
+
+      - name: 'Run the Anchore Grype scan action'
+        uses: anchore/scan-action@v3.3.4
+        id: scan
+        with:
+          image: mailserver-testing:ci
+          fail-build: false
+
+      - name: 'Upload vulnerability report'
+        uses: github/codeql-action/upload-sarif@v2
+        with:
+          sarif_file: ${{ steps.scan.outputs.sarif }}

.github/workflows/scheduled_builds.yml

@@ -15,6 +15,13 @@ jobs:
     with:
       platforms: linux/amd64,linux/arm64
 
+  scan-image:
+    name: 'Scan Image for Vulnerabilities'
+    needs: build-images
+    uses: docker-mailserver/docker-mailserver/.github/workflows/generic_vulnerability-scan.yml@master
+    with:
+      cache-key: ${{ needs.build-images.outputs.build-cache-key }}
+
   publish-images:
     name: 'Publish Images'
     needs: build-images

SECURITY.md

@@ -0,0 +1,14 @@
+# Security Policy
+
+## Supported Versions
+
+Due to the way DMS is released, the most recent patches and the most current software is published on the `:edge` tag of the container image. Hence, security updates will land on this "rolling release tag". Older tags need manual updating, as we do not usually release an updated image for an existing tag; this will only be done in case of _severe_ vulnerabilities.
+
+| Image Tags  | Latest Packages & Patches |
+|-------------|:-------------------------:|
+| `:edge`     | :white_check_mark:        |
+| not `:edge` | :x:                       |
+
+## Reporting a Vulnerability
+
+When reporting a vulnerability, you can use GitHub's "Private Vulnerability Reporting". Just navigate to the [Open an Issue](https://github.com/docker-mailserver/docker-mailserver/issues/new/choose) page and choose "Report a security vulnerability". This way, maintainers will privately notified first. Afterwards, in a best-case scenario, if the vulnerability is fixed, the report will be made public.