chore: add notification step to trigger UDS Security Hub scan

[benjaminwilcox]

Currently, there is typically a delay between core releases and when they appear in the UDS Security Hub database with relevent cve information. This addition will notify and kick off a scan once core publishes a release.

[mjnagel]

One other thing to note - if we wanted to run this on the snapshot releases as well (and we make the changes mentioned in my other comments) we'd need to copy/paste similar logic into this workflow which makes our snapshots.

[UnicornChance]

One other thing to note - if we wanted to run this on the snapshot releases as well (and we make the changes mentioned in my other comments) we'd need to copy/paste similar logic into this workflow which makes our snapshots.

Maybe we should make these changes it's own action for ease of portability between different workflows?

[benjaminwilcox]

One other thing to note - if we wanted to run this on the snapshot releases as well (and we make the changes mentioned in my other comments) we'd need to copy/paste similar logic into this workflow which makes our snapshots.

@mjnagel @UnicornChance Do we want a full scan to be ran each time the snapshot is released? We already run a nightly scan.

There were two issues at hand: 1) delay between core official releases and latest official release data in security hub db and 2) cve notifications for crit/highs.

I figured the latter would address your use-case of monitoring snapshots against the latest release. The example I showed you in dm's of the latest official release vs snapshot results was a single workflow that uses the callable workflow to scan only the latest official core release and only the latest snapshot each night like so:

name: Results for Core Official Release and for Snapshot

on:
  schedule:
    - cron: "0 2 * * *" # Run daily at 2 AM

jobs:
  trigger-scan:
    runs-on: ubuntu-latest

    steps:
      - name: Trigger Scan Workflow for Latest Core Release
        run: |
          curl -X POST \
            -H "Authorization: Bearer ${{ secrets.GITHUB_TOKEN }}" \
            -H "Accept: application/vnd.github+json" \
            https://api.github.com/repos/defenseunicorns/uds-core/actions/workflows/run-vulnerability-scan.yaml/dispatches \
            -d '{
              "ref": "main",
              "inputs": {
                "application_name": "core",
                "package_tag": "0.33.1-unicorn", # this would need to be updated to whatever the latest version is
                "package_repository": "ghcr.io/defenseunicorns/packages/private/uds/core"
              }
            }'

      - name: Trigger Scan Workflow for Core Snapshots
        run: |
            curl -X POST \
              -H "Authorization: Bearer ${{ secrets.GITHUB_TOKEN }}" \
              -H "Accept: application/vnd.github+json" \
              https://api.github.com/repos/defenseunicorns/uds-core/actions/workflows/run-vulnerability-scan.yaml/dispatches \
              -d '{
                "ref": "main",
                "inputs": {
                  "application_name": "core",
                  "package_tag": "latest-unicorn",
                  "package_repository": "ghcr.io/defenseunicorns/packages/private/uds/snapshots/core"
                }
              }'

Because I thought monitoring snapshots was more of an internal core need to track if/when CVEs are resolved on main even if they aren't in an official release yet.

Also for clarity - the api url assumes the consuming vuln scanning workflow exists in uds-core, this one above just triggers that one to use the callable workflow. trigger -> consuming workflow -> callable workflow

[mjnagel]

Yeah @benjaminwilcox good point I think we can skip the "trigger" on snapshots for now!

[mjnagel]

Leaving a placeholder comment here to make sure we don't forget to acquire and add a token secret. Depending on intent it might make sense to set it at the org level (assuming we could safely scope the token down), to enable usage of that token from other repos for this same purpose?

[benjaminwilcox]

Yeah, that makes sense - something like the DEFENSEUNICORNS_GITHUB_PACKAGE_READ_TOKEN token but with the workflow/repo permissions