CivicShield

• 

  CivicShield groups Splunk security logs into one incident case and shows affected pod, package, risk level, AI insight, and response status.

• 

  Evidence Timeline shows the detection path from Splunk events, helping the user understand the incident before running response actions.

• 

  The Response workspace lets the user run Kubernetes containment actions and records the result in the audit trail for later review.

• 

• 

• 

Inspiration

I wanted to build something that connects security logs to actual response actions. Splunk is very useful for storing and searching logs, but raw logs can still be hard to understand quickly, especially when several events are connected to the same incident.

For this project, I focused on a Kubernetes supply-chain security scenario. I wanted CivicShield to help a user understand what happened, review the evidence, and then take a response action without jumping between too many tools.

What it does

CivicShield is a Splunk-powered incident response workbench for Kubernetes security logs.

The app takes security events from Splunk and groups them into one incident case. It shows the affected pod, namespace, suspicious package, risk level, and evidence timeline.

It also uses an AI explanation layer to summarize the incident in plain language. After reviewing the evidence, the user can run response actions such as quarantining a pod or applying a deny-egress NetworkPolicy.

The response actions are human-in-the-loop. The app does not automatically change Kubernetes. The user reviews the evidence first, then chooses the action.

How we built it

I built the frontend with React and Vite, and the backend with FastAPI and Python.

Splunk is used as the evidence source. The demo logs are indexed in Splunk, and the backend queries those logs to build the incident case, evidence timeline, and response playbook.

The AI explanation layer uses Gemini to summarize the structured Splunk evidence. Kubernetes response actions are handled through backend routes that run kubectl-backed actions against a local Docker Desktop Kubernetes cluster.

The main workflow is:

Splunk logs → FastAPI backend → incident analysis → AI explanation → React frontend → Kubernetes response → audit trail.

Challenges we ran into

One challenge was designing the right workflow. At first, my sample logs included both detection events and response events together. That made the incident look like it was already finished before the user did anything.

I changed the design so Splunk starts with only detection evidence, and the response actions happen later when the user clicks them in CivicShield. This made the app feel more realistic.

Another challenge was connecting AI in a useful way. I did not want AI to replace Splunk or invent information. In the final version, Splunk stays the source of truth, and AI only explains the structured evidence in a more readable way.

I also had to debug the Kubernetes response flow, especially making sure the local cluster was running and that the pod label and NetworkPolicy were actually applied.

Accomplishments that we're proud of

I am proud that CivicShield is not just a dashboard. It connects investigation and response in one flow.

The app can show Splunk evidence, explain the incident with AI, let the user review the evidence timeline, run Kubernetes containment actions, and record the result in an audit trail.

I am also proud that the response actions are real in the demo. The user can quarantine the pod and apply a deny-egress NetworkPolicy, then verify the result directly with kubectl.

What we learned

I learned that building a security workflow is not only about showing data. The order of the user experience matters a lot.

The user needs to first understand the case, then review evidence, then choose a response action, and finally confirm that the action worked.

I also learned more about how Splunk can be used as an evidence layer, how AI can explain structured security data, and how Kubernetes response actions can be connected to a web application.

What's next for CivicShield

Next, I would like to make CivicShield support multiple incidents instead of one demo case.

I also want to write response audit events back into Splunk, so Splunk can store both the original evidence and the response history.

Future improvements could include native Splunk MCP Server integration, Splunk Hosted Models support, better dependency intelligence, and an approval step before high-impact response actions.

Built With

• api
• css
• desktop
• docker
• enterprise
• fastapi
• gemini
• github
• javascript
• kubectl
• kubernetes
• networkpolicy
• python
• react
• rest
• splunk
• vite