SupplyGuard

Inspiration

Supply-chain attacks — XZ Utils, SolarWinds, Log4Shell — all enter the same way: a dependency that wasn't there before, or one that silently changed. Security teams pour effort into monitoring network traffic, yet almost nobody watches where these attacks actually enter: the CI/CD build pipeline. A manual typosquat/CVE audit across repos takes weeks; pipelines ship hourly. I wanted Splunk — already the system of record for machine data — to watch the supply chain in real time and act.

What it does

SupplyGuard ingests CI/CD events into Splunk and runs an autonomous agent on every build:

• SENSE the dependency-manifest diff from Splunk via the Splunk MCP Server
• DETECT known CVEs and typosquatting (real Levenshtein distance — e.g. reqursts vs requests)
• INVESTIGATE with the foundation-sec Splunk hosted security model (malicious? confidence?) and map cross-repo impact
• DECIDE block the build / open a remediation PR / file a report / flag
• ACT — block the build, behind a human-approval gate
• LOG the decision to index=cicd as an audit + NIS2 Article 21 evidence trail

In the demo it catches build payment-service#1247, which added reqursts@2.1.3 (one edit from requests) and log4j-core 2.14 (CVE-2021-44228, CVSS 10), triages with the hosted model, maps 3 affected repos, and blocks the build.

How we built it

• Splunk MCP Server — the agent reads index=cicd via run_splunk_query, with the full streamable-HTTP initialize handshake + Bearer-token auth.
• Splunk Hosted Models — foundation-sec-1.1-8b-instruct classifies typosquats and writes the NIS2 narrative.
• HEC + SPL — a Python collector streams CI/CD events to index=cicd; SPL does CVE correlation (lookup), install-spike detection (eventstats), and NIS2 scan-coverage posture.
• Dashboard Studio — a live SOC dashboard shows builds blocked, CVEs, NIS2 %, a 7-day risk profile, and the agent's decision audit trail.
• A responsible-autonomy approval gate; air-gapped demo (zero network) by default.

Challenges we ran into

• The Splunk MCP Server exposes one query tool (run_splunk_query), not separate metrics/alert tools — so everything is SPL, and the client must perform the MCP initialize handshake before any tool call (the #1 thing that silently breaks a client that "works" offline).
• SPL has no native levenshtein() — typosquatting distance is computed in Python, and the old join correlation was replaced with lookup/eventstats to avoid the subsearch anti-pattern.
• Keeping the whole pipeline runnable air-gapped for judging while still wiring real Splunk Cloud paths.

Accomplishments that we're proud of

• A genuinely agentic loop that doesn't just alert — it blocks the build, with a human-approval gate.
• Runs live on real Splunk: a populated Dashboard Studio dashboard backed by index=cicd.
• A net-new Splunk data source (the build pipeline), net-new detection (dependency CVEs + typosquatting), and a net-new compliance angle (NIS2 Article 21).
• Honest engineering: real MCP handshake, real hosted-model calls, no fabricated SPL, no hardcoded secrets.

What we learned

• The build pipeline is a rich, underused Splunk data source.
• MCP makes Splunk a clean read-surface for an AI agent — the handshake + run_splunk_query is all you need.
• foundation-sec is well-suited to security-domain triage and compliance-narrative generation.

What's next for SupplyGuard

• Wire live remediation to real GitHub/GitLab PRs.
• Ingest SBOMs (CycloneDX/SPDX) and transitive-dependency graphs.
• Expand typosquatting beyond Levenshtein (homoglyphs, keyboard distance) and pull OSV / GitHub Advisory feeds via Splunk Threat Intelligence Management.

Built With

• dashboard-studio
• foundation-sec
• hec
• model-context-protocol
• python
• spl
• splunk
• splunk-hosted-models
• splunk-mcp-server