Skip to main content
Glama
SumitDalavi

cspm-noise-reduction-agent

AI-Driven CSPM Noise Reduction Agent

CI Pipeline Release Release Workflow Glama Smithery SBOM License: MIT

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.

  1. Ingestion & Deduplication: Collapses multiple findings into single underlying issues based on CVE, package, and resource.

  2. Contextual Scoring: Adjusts base CVSS scores using runtime context (e.g., internet reachability, loaded in memory, public exploit availability).

  3. Prioritization: Outputs a drastically reduced list of actionable tickets.

  4. (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

CVE + Package + Resource

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 get_prioritized_findings directly and help developers patch the issues automatically.

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.md

Setup & Usage

1. Run the Backend API

cd backend
npm install
npm run build # or run with ts-node
npx ts-node src/index.ts

The API will start on http://localhost:3000.

2. Run the Frontend Dashboard

Open a new terminal:

cd dashboard
npm install
npm run dev

Navigate 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 test

Expected:

PASS tests/api.test.ts
  ✓ should return the deduped and scored report
Tests: 1 passed, 1 total

Check

Expected Result

API Response

curl http://localhost:3000/api/report returns { "metrics": { "raw_findings_count": N, "deduplicated_count": M, "actionable_tickets_count": K }, "tickets": [...] }

Dashboard UI

Loads at http://localhost:5173, shows ~90% noise reduction

MCP Tool

npx ts-node src/index.ts mcp starts stdio MCP server; Claude can call get_prioritized_findings


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 test

Performance 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 Cache or Map structures 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

backend/data/aws_security_hub_fixture.json — actual ASFF format used in E2E tests.

Jira/ServiceNow output

Stubbed

Adapter interfaces exist; no real ticket creation

LLM summaries

Simulated

Deterministic text when no OPENAI_API_KEY; mock delay when key present

🚀 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 .env for 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-agent
  • Integrity & 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

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 tool
get_prioritized_findingsB

Analyzes raw CSPM findings, deduplicates them, and returns a prioritized list of actionable tickets.

ParametersJSON Schema
NameRequiredDescriptionDefault
top_nNoNumber of top tickets to return (default: 10)
use_llmNoWhether to generate LLM summaries (requires OPENAI_API_KEY env var)

TDQS

B3.1/5.0
Behavior2/5

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.

Conciseness5/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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. 1 tool updatev0.1.0
    • First observedget_prioritized_findings

TDQS

B3.4/5.0

Scored across 1 tool

Disambiguation5/5

With only one tool, there is no possibility of confusion or misselection. The single tool's purpose is clear and unambiguous.

Naming Consistency5/5

The tool name 'get_prioritized_findings' follows a clear verb_noun snake_case pattern. With only one tool, consistency is trivially satisfied.

Tool Count3/5

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.

Completeness3/5

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

ActivityMaintained
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

  • A
    license
    Not graded
    quality
    B
    maintenance
    Provides 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.
    1
    MIT
  • A
    license
    Not graded
    quality
    C
    maintenance
    Enables 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