Using GitHub Actions to Check CISA KEV Daily (SI.L2-3.14.3)

A GitHub Actions CISA KEV daily check can automatically download CISA’s Known Exploited Vulnerabilities catalog, compare entries against a maintained asset inventory, and create tracked remediation tickets for matching systems. This provides repeatable evidence that external advisories are monitored under NIST SP 800-171 Rev. 2 and CMMC 2.0 Level 2 practice SI.L2-3.14.3, while leaving applicability decisions, remediation approval, and closure validation with accountable staff. The workflow should preserve the advisory details, affected asset, assigned owner, review decision, and response date.

What can a GitHub Actions CISA KEV daily check automate, and what still requires review?

Automation is useful for the repetitive parts of advisory monitoring: obtaining the current CISA feed, identifying potential matches, notifying the right people, and retaining a time-stamped review record. It does not replace the analyst or system owner who must decide whether a listed vulnerability applies to the organization’s actual version, configuration, exposure, compensating controls, and business impact.

For an MSSP, this distinction is important. A daily CISA KEV check in GitHub Actions proves the monitoring mechanism is operating, but it should create a review queue rather than silently declaring a customer compliant. The ticket is the handoff point between alert monitoring and response action.

How do you build the automated KEV matching workflow?

Store the workflow and a small customer-specific asset inventory in a private GitHub repository. The inventory should contain only systems relevant to vulnerability response, not sensitive configuration exports. Normalize product names to align with CISA’s vendorProject and product fields.

For example, an MSSP supporting a 180-person aircraft-parts manufacturer may maintain an inventory for its engineering file portal, production ERP server, VPN appliance, and Microsoft Exchange environment. The customer’s engineering drawings are CUI, so the workflow records that the Exchange system supports CUI communications without copying CUI into the issue.

[
  {
    "id": "MFG-EXCH-01",
    "vendor": "Microsoft",
    "product": "Exchange Server",
    "owner": "infrastructure@customer.example",
    "criticality": "high",
    "business_service": "CUI email and supplier communications"
  },
  {
    "id": "MFG-VPN-01",
    "vendor": "Ivanti",
    "product": "Connect Secure",
    "owner": "network@customer.example",
    "criticality": "high",
    "business_service": "Remote access for engineering and production support"
  }
]

Save that file as inventory/assets.json. Next, add the following Bash script as scripts/check-kev.sh. It downloads CISA’s official KEV catalog, compares normalized vendor and product fields, and writes matching records to kev-matches.json.

#!/usr/bin/env bash
set -euo pipefail

KEV_URL="https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json"
ASSETS="inventory/assets.json"
CATALOG="kev-catalog.json"
MATCHES="kev-matches.json"

curl --fail --silent --show-error --location \
  --retry 3 --retry-delay 5 \
  --output "$CATALOG" "$KEV_URL"

jq -e '.vulnerabilities | type == "array"' "$CATALOG" >/dev/null

jq -n \
  --slurpfile assets "$ASSETS" \
  --slurpfile catalog "$CATALOG" '
  [
    $assets[0][] as $asset
    | $catalog[0].vulnerabilities[] as $kev
    | select(
        ($kev.vendorProject | ascii_downcase) ==
        ($asset.vendor | ascii_downcase)
      )
    | select(
        ($kev.product | ascii_downcase) ==
        ($asset.product | ascii_downcase)
      )
    | {
        asset: $asset,
        kev: {
          cveID: $kev.cveID,
          vendorProject: $kev.vendorProject,
          product: $kev.product,
          vulnerabilityName: $kev.vulnerabilityName,
          dateAdded: $kev.dateAdded,
          dueDate: $kev.dueDate,
          requiredAction: $kev.requiredAction,
          notes: $kev.notes
        }
      }
  ]' > "$MATCHES"

echo "Potential KEV matches: $(jq 'length' "$MATCHES")"

This is intentionally conservative and exact-match based. Do not use broad text matching such as “contains Microsoft” because it produces noisy tickets. Where customer tooling reports different product names, maintain a reviewed alias list or enrich the inventory from a trusted CMDB or vulnerability scanner export.

How should the scheduled workflow create actionable response records?

Create .github/workflows/cisa-kev-daily.yml with a daily schedule and a manual-dispatch option. The workflow needs issues: write permission because it creates the internal advisory record. It searches for an existing open issue before creating another one, preventing daily duplicates for the same CVE and asset.

name: CISA KEV Daily Review

on:
  schedule:
    - cron: "17 11 * * *"
  workflow_dispatch:

permissions:
  contents: read
  issues: write

jobs:
  check-kev:
    runs-on: ubuntu-latest
    steps:
      - name: Check out advisory repository
        uses: actions/checkout@v4

      - name: Run KEV comparison
        run: |
          chmod +x scripts/check-kev.sh
          scripts/check-kev.sh

      - name: Create review issues for new matches
        env:
          GH_TOKEN: $
        run: |
          jq -c '.[]' kev-matches.json | while read -r record; do
            asset=$(jq -r '.asset.id' <<< "$record")
            owner=$(jq -r '.asset.owner' <<< "$record")
            cve=$(jq -r '.kev.cveID' <<< "$record")
            title="[KEV] $cve on $asset"

            existing=$(gh issue list --state open --search "$title in:title" \
              --json number --jq 'length')

            if [ "$existing" -eq 0 ]; then
              body=$(jq -r '
                "CISA KEV review required.\n\n" +
                "**Asset:** " + .asset.id + "\n" +
                "**Service:** " + .asset.business_service + "\n" +
                "**Criticality:** " + .asset.criticality + "\n" +
                "**CVE:** " + .kev.cveID + "\n" +
                "**CISA due date:** " + (.kev.dueDate // "Not listed") + "\n" +
                "**Required action:** " + .kev.requiredAction + "\n\n" +
                "Document applicability, remediation or mitigation, validation evidence, and closure approval."
              ' <<< "$record")

              gh issue create --title "$title" --body "$body" \
                --assignee "$owner"
            fi
          done

      - name: Retain matching output
        uses: actions/upload-artifact@v4
        with:
          name: kev-matches-$
          path: |
            kev-catalog.json
            kev-matches.json
          retention-days: 90

The daily schedule establishes a defined review frequency that aligns with the publication cadence of the CISA feed. Manual dispatch is useful when CISA publishes an urgent advisory or when an analyst needs to demonstrate the process during a customer assessment.

How does this fit into CI/CD and scheduled operational work?

Keep the KEV job separate from application build pipelines. Advisory monitoring is an operational security process, and a failure in the feed download should not automatically stop a production release unless the customer has formally approved that policy. The scheduled workflow should run in a private compliance repository with restricted access for the MSSP and designated customer personnel.

For mature customers, connect the issue queue to existing change management. A high-criticality KEV issue can require a change ticket before patching a production system, while a lower-risk match may be routed to the normal maintenance window. At the aerospace component manufacturer, an Ivanti Connect Secure match would be escalated to the network lead and customer security contact because remote access supports both engineering and plant operations; an analyst would still verify the installed appliance version before directing a change.

Preserve three evidence types: successful workflow runs showing the feed was reviewed, GitHub issues showing potential applicability and ownership, and closure comments containing validation evidence. This supports all three SI.L2-3.14.3 objectives: monitoring advisories, identifying response actions, and taking those actions.

Which monitoring and alerting hooks should an MSSP add?

• GitHub Issues: Use the issue as the internal security advisory, assign the customer owner, and require a documented disposition.
• GitHub notifications: Add the MSSP analyst mailbox as a repository watcher so failed runs and assigned issues are visible.
• Ticketing integration: Use a GitHub App, Power Automate, or the PSA platform’s GitHub connector to mirror newly created KEV issues into the customer’s service queue.
• Workflow failure alert: Configure GitHub Actions failure notifications and create an MSSP escalation procedure when no successful run occurs within 24 hours.
• Monthly review: Report open KEV issues, overdue CISA due dates, exceptions, and workflow failures in the customer’s vulnerability-management review.

How should the workflow handle failures and false matches?

For MSSP analysts, the next step is to deploy this workflow in one customer’s private compliance repository, validate its inventory matches against current scanner data, and review the first week of tickets with the customer’s system owners.