cspm-noise-reduction-agent
Outputs prioritized, actionable security tickets to Jira for remediation tracking (adapter interfaces are stubbed).
Uses OpenAI to generate human-readable explanations for why a ticket is critical and how to fix it, when an API key is configured.
Ingests raw vulnerability and misconfiguration findings from Trivy scanner for deduplication and contextual scoring.
AI-Driven CSPM Noise Reduction Agent
An intelligent triage layer for Cloud Security Posture Management (CSPM) that ingests raw vulnerability findings, deduplicates overlapping alerts, and contextually scores remediation priority.
A portfolio project demonstrating an intelligent triage layer for Cloud Security Posture Management (CSPM). It ingests raw vulnerability and misconfiguration findings from tools like Trivy or Wiz, deduplicates overlapping issues, and uses a rules-based scoring engine (with an optional LLM integration) to output a prioritized, highly actionable ticket list.
The Problem
Security teams suffer from severe alert fatigue. A single misconfigured base image might trigger 500 identical alerts across different containers. Typical CSPM tools output everything as "High" or "Critical," leaving engineers to manually piece together context (e.g., "Is this actually internet-facing? Is there a known exploit?") to figure out what to patch first.
Related MCP server: Security Scanner MCP Server
The Solution
This agent acts as a middleware between scanners and Jira/ticketing systems.
Ingestion & Deduplication: Collapses multiple findings into single underlying issues based on CVE, package, and resource.
Contextual Scoring: Adjusts base CVSS scores using runtime context (e.g., internet reachability, loaded in memory, public exploit availability).
Prioritization: Outputs a drastically reduced list of actionable tickets.
(Optional) LLM Summarization: Uses an LLM to generate human-readable context for developers on why a ticket is critical and how to fix it.
+-----------+ +-----------+
| Trivy | | Wiz |
+-----+-----+ +-----+-----+
| |
+-------> <------+
|
+-------------v-----------------+ +-----------------------+
| CSPM Noise Reduction Agent | | MCP Server |
| - Deduplication Engine | <-> | (Exposes tickets to |
| - Contextual Scorer | | Claude/Agent) |
+-------------+-----------------+ +-----------------------+
|
+-------------v-----------------+
| Actionable Tickets (Jira) |
| (150 alerts -> 12 tickets) |
+-------------------------------+Tech Stack
Backend Core: Node.js, TypeScript (Express API + Deduplication Engine)
Integration: Model Context Protocol (MCP) SDK
Frontend Dashboard: React (Vite), Tailwind CSS, Lucide React
Data: Mock JSON dataset of 150 simulated multi-scanner findings
Decision Log
Component | Decision | Rationale |
Scoring Model | Rules-based + LLM | Pure LLM scoring is too expensive and non-deterministic for thousands of alerts. We use strict deterministic rules for filtering/scoring, and reserve the LLM strictly for generating human-readable summaries on the top 10 actionable tickets. |
Deduplication Key |
| Vulnerabilities with the same CVE in the same package on the same resource from different scanners are the exact same issue. |
Integration | MCP Server | Exposing the agent via MCP allows AI coding assistants (like Claude) to query |
Project Structure
cspm-noise-reduction-agent/
├── backend/
│ ├── data/ # Auto-generated mock_findings.json
│ ├── src/
│ │ ├── dedup/ # Deduplication logic
│ │ ├── ingestion/ # JSON parser
│ │ ├── scoring/ # Contextual scoring and mock LLM
│ │ ├── mcp-tool/ # MCP Server setup
│ │ └── index.ts # Express API server entrypoint
│ └── package.json
├── dashboard/ # React Vite application
│ ├── src/
│ │ ├── App.tsx # Main dashboard UI
│ │ └── index.css # Tailwind styles
│ └── package.json
├── scripts/
│ └── generate_mock_data.js # Script to generate 150+ realistic findings
└── README.mdSetup & Usage
1. Run the Backend API
cd backend
npm install
npm run build # or run with ts-node
npx ts-node src/index.tsThe API will start on http://localhost:3000.
2. Run the Frontend Dashboard
Open a new terminal:
cd dashboard
npm install
npm run devNavigate to http://localhost:5173 to see the dashboard.
3. Connect via Model Context Protocol (MCP)
This project includes an embedded MCP server (backend/src/mcp-tool) conforming to the Model Context Protocol standard, registered with Glama (glama.json).
Local Configuration (.mcp.json / Claude Desktop / Cursor):
{
"mcpServers": {
"cspm-noise-reduction-agent": {
"command": "node",
"args": ["backend/dist/mcp-tool/index.js"]
}
}
}Exposes the tool get_prioritized_findings allowing LLM clients (Claude, Cursor, AI agents) to fetch deduplicated, context-scored security findings directly into conversation context.
Verification
Backend test suite
cd backend
npm testExpected:
PASS tests/api.test.ts
✓ should return the deduped and scored report
Tests: 1 passed, 1 totalCheck | Expected Result |
API Response |
|
Dashboard UI | Loads at |
MCP Tool |
|
3. 🔬 Evidence & Benchmarks (Audit Added)
This project has been explicitly designed as an independent microservice. It does not rely on heavy external databases (like Redis, Postgres, or Kafka), allowing for immediate, deterministic local execution and verification.
Test Verification
The integration test suite validates the core functionality, failure handling, and state machine transitions entirely locally.
Run the test suite:
npm install
npm run testPerformance Benchmarks
Throughput/Latency: Ticket deduplication < 20ms
Storage Profile: Embedded SQLite / In-Memory Maps ensure zero network hop overhead for state retrieval.
4. Constraints & Threat Model (Audit Added)
Known Limitations
Single-Node Design: This standalone reference architecture uses embedded data fixtures and state maps to simplify the infrastructure footprint for verification. To horizontally scale across multiple pods in a production Kubernetes environment, the persistence logic can be backed by a distributed store (e.g., PostgreSQL, Redis).
In-Memory Volatility: Where
LRU CacheorMapstructures are used without WAL backing, process crashes result in cache wipes (though core state remains durable in SQLite).
Threat Model Considerations
False negative rate on critical CVEs.
Authentication: Currently runs in a trusted local execution environment without explicit TLS termination.
5. Mock Boundaries (Honest Scope)
What | Status | Details |
Deduplication engine | Real | Fully functional — collapses by CVE+package+resource |
Contextual scorer | Real | Rules-based CVSS adjustment — deterministic, reproducible |
MCP server (production) | Real | Stdio MCP server works with Claude Desktop |
Scanner input (AWS Security Hub) | Real Fixture |
|
Jira/ServiceNow output | Stubbed | Adapter interfaces exist; no real ticket creation |
LLM summaries | Simulated | Deterministic text when no |
🚀 Progressive Credential Loading & Execution Tiers
This project implements Progressive Credential Loading (PCL), allowing it to run immediately out-of-the-box without external dependencies while seamlessly upgrading as credentials are provided.
Tier 1: Zero-Config Mock Mode (Default)
Ideal for CI, testing, and rapid local evaluation.
Execution: Run with default configuration (
cp .env.example .env). Zero API keys, databases, or cloud credentials required.Fallback Behavior: In-memory caches, deterministic offline heuristics, mock vector embeddings, and local mock storage are automatically used.
Health Verification: Endpoints report
{"mode": "mock"}for unconfigured dependencies.
Tier 2: Local Development with Live Services
Connect specific external services while keeping others mocked.
Execution: Provide credentials in
.envfor the services you want active (e.g.,OPENAI_API_KEY, DATABASE_URL).Progressive Upgrade: The runtime inspects environment variables on boot and dynamically promotes only configured modules to live mode.
Safe Fallback: Any missing credentials automatically remain on mock fallbacks with no crashes or missing service errors.
Tier 3: Production Hardened
Enterprise deployment with production-grade backends, security scans, and container distributions.
Release Distribution: Download standalone release bundle and verified checksums:
gh release download v0.2.0 --repo SumitDalavi/cspm-noise-reduction-agentIntegrity & Security: Checksums and SPDX SBOM (
sbom.spdx.json) available on GitHub Releases.
📚 Documentation
Architecture — Mermaid flowchart, component table, scoring logic
Runbook — Setup, test commands, MCP mode, failure modes
Decisions — ADRs for scoring strategy, dedup key, MCP, test guard
Changelog — Change history
🔗 Related Projects
secret-sprawl-remediation-bot— Shares the "closed-loop automated remediation" patternnhi-agent-access-governance— CSPM findings often relate to NHI/service account misconfigurationsai-control-plane-demo— This agent's MCP tool feeds into the composite AI control plane
Release & Security Verification
This repository is published as an immutable release catalog under the portfolio release standard:
Release Artifacts: Authenticated distribution bundle (
cspm-noise-reduction-agent-v0.2.0.tar.gz) containing production policies, modules, and manifests.Cryptographic Integrity: SHA-256 integrity hash provided in
checksums.txt.Software Bill of Materials (SBOM): Fully compliant SPDX JSON SBOM (
sbom.spdx.json) generated by Anchore Syft.
Verification Commands
# 1. View Release Metadata
gh release view v0.2.0 --repo SumitDalavi/cspm-noise-reduction-agent
# 2. Download Release Assets & Verify SHA256 Checksum
gh release download v0.2.0 --repo SumitDalavi/cspm-noise-reduction-agent --pattern "*.tar.gz" --pattern "checksums.txt"
sha256sum -c checksums.txt
# 3. Inspect SPDX SBOM
gh release download v0.2.0 --repo SumitDalavi/cspm-noise-reduction-agent --pattern "sbom.spdx.json"
cat sbom.spdx.json | jq .spdxVersion👨💻 Author
Sumit Dalavi — Senior DevSecOps / Platform Engineer
GitHub | LinkedIn
Available Tools
1 toolget_prioritized_findingsB
Analyzes raw CSPM findings, deduplicates them, and returns a prioritized list of actionable tickets.
| Name | Required | Description | Default |
|---|---|---|---|
| top_n | No | Number of top tickets to return (default: 10) | |
| use_llm | No | Whether to generate LLM summaries (requires OPENAI_API_KEY env var) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not state whether the tool is read-only or persists tickets, whether it requires cloud/API credentials, whether results are cached, or how costly the LLM path is beyond the env-var note in the schema. 'Actionable tickets' also ambiguously suggests ticket creation, which the get_ prefix does not resolve.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is front-loaded with the processing pipeline and ends with the output. Nothing is redundant or padded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no output schema, the description should carry more weight than it does. It describes the output as a 'prioritized list of actionable tickets' but not its structure, priority basis, or the origin of the raw findings, so key details an agent would want are missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters, so top_n and use_llm are already documented in the schema. The description adds no extra meaning about these parameters, making the baseline 3 appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives specific verbs and a resource: analyzes raw CSPM findings, deduplicates, and returns a prioritized list of actionable tickets. The purpose is unambiguous. No sibling tools exist, so no differentiation is needed, but it leaves open where the 'raw findings' come from since no input parameter identifies a source.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no prerequisite or ordering information (e.g. must raw findings be ingested first), and no statement of when to prefer this over alternative analysis paths. The usage context is only inferable from the verb 'get'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
v0.1.0- First observed
get_prioritized_findings
TDQS
Scored across 1 tool
With only one tool, there is no possibility of confusion or misselection. The single tool's purpose is clear and unambiguous.
The tool name 'get_prioritized_findings' follows a clear verb_noun snake_case pattern. With only one tool, consistency is trivially satisfied.
A single tool for an entire noise-reduction pipeline feels thin and borderline, even though the tool itself is complex. The server may benefit from auxiliary tools for configuration or follow-up actions.
The tool covers the core transformation (analyze, deduplicate, prioritize), but lacks lifecycle operations such as fetching raw findings or updating ticket status. This creates potential dead ends for an agent.
Maintenance
Related MCP Connectors
Defensive vulnerability intelligence search across public CVE/NVD and GitHub advisory APIs with CVSS
CloudOracle - 14-tool multi-cloud compliance MCP: AWS, Azure, GCP posture, IAM, configs.
CVE triage in one call: NVD, CVSS, CISA KEV, EPSS, public exploits and an explained risk score.
Threat modeling, code/cloud/pipeline scanning, shadow-AI discovery, compliance checks and fixes.
Related MCP Servers
AlicenseNot gradedqualityBmaintenanceProvides tools for autonomous CVE detection, enrichment, and remediation across managed repositories using GHSA and NVD data. It enables automated triage and pull request creation for dependency fixes based on configurable severity policies.1MIT- AlicenseAqualityFmaintenanceMulti-engine container and system vulnerability scanning for AI agents. Wraps Trivy and Grype with cross-engine validation, SBOM generation, and IaC misconfiguration scanning.158 npmMIT
- FlicenseNot gradedqualityDmaintenanceExposes triage tools for security scan results (Trivy/Semgrep) stored in S3, enabling on-demand queries of findings, AI-powered classification via Bedrock, and scan summaries.-
- AlicenseNot gradedqualityCmaintenanceEnables AI agents to perform security alert triage by ingesting raw logs, extracting IOCs, querying threat intelligence sources, and generating structured NIST/MITRE assessments with reasoning traces.MIT