KiroGraph-Sec: From AWS Summit Milano Slides, Through Kiro Specs, to a Cybersecurity Feature

This is the third part of my "Build in Public with Kiro" series. I'm an AWS Community Builder, and this is the story of what happens when you share something early, people actually care, and the project grows faster than you expected.

But also, the story of how a conference talk about VEX triage turned into a full SCA+ security module built spec-first with Kiro

🏃 TL;DR

Most SCA tools tell you "this dependency has a CVE." KiroGraph-Sec tells you whether that CVE is actually reachable from your HTTP routes, which entry points expose a hardcoded secret, and which public route reaches a vulnerable dep in two function calls. It does this by running a BFS over the same call graph KiroGraph already builds for code navigation.

Built spec-first in Kiro after an AWS Summit Milano talk by Maurizio Argoneto (AWS Hero) on automating VEX triage with AI. Covers 14 ecosystems. Ships CycloneDX SBOM and VEX, SARIF for GitHub Security tab, an HTML security dashboard, and a full MCP tool suite so your AI agent can query the security index instead of scanning files.

davide-desio-eleva / kirograph

Semantic code knowledge graph for Kiro: fewer tool calls, instant symbol lookups, 100% local.

KiroGraph

Semantic code knowledge graph for Kiro: fewer tool calls, instant symbol lookups, 100% local.

Inspired by CodeGraph by colbymchenry for Claude Code, rebuilt natively for Kiro's MCP and hooks system.

Full support is for Kiro only. Experimental integrations for 34 other MCP-capable tools (Cursor, Copilot, Claude Code, Windsurf, Cline, and more) are available with auto-detection. See Integrations for the full list.

Why KiroGraph?

When you ask Kiro to work on a complex task, it explores your codebase using file reads, grep, and glob searches. Every one of those is a tool call, and tool calls consume context and slow things down.

KiroGraph gives Kiro a semantic knowledge graph that's pre-indexed and always up to date. Instead of scanning files to understand your code, Kiro queries the graph instantly: symbol relationships, call graphs, type hierarchies, impact radius, all in a single MCP tool call.

The result is fewer tool…

View on GitHub

🎤 It Started With a Slide Deck in Milano

At the AWS Summit Milano, Maurizio gave a talk titled "Chi ha messo questo nel mio codice? Dalla Confusione al Controllo: Automazione del Triage VEX con l'IA" (roughly: "Who put this in my code? From Confusion to Control: Automating VEX Triage with AI").

The core argument was compelling and uncomfortable in equal measure: most developers today drop a question into an AI coding assistant and hope it figures out their security posture. That is not a strategy. That is delegation without accountability.

Maurizio's thesis: AI is a great reasoning engine, but it needs smart tooling underneath to do security work properly. When dealing with VEX documents (Vulnerability Exploitability eXchange), you do not want the AI to scan files blindly. You want it to query a semantic index that already understands your code structure. The AI should ask "is this vulnerability reachable from my entry points?" against a pre-computed graph, not trawl through source files hoping to figure it out from context.

While listening to Maurizio, it became clear that KiroGraph already enabled this kind of navigation, and that was exactly how he was using it.

The call graph, import edges, and architecture layers were already available. The dependency and vulnerability pieces were still missing, but the core foundation was already there.

I took photos of the slides, walked home, and opened Kiro.

I would also like to sincerely thank Maurizio for giving KiroGraph the opportunity to be featured at such an important conference.

📐 The Specs-First Approach

I didn’t start by writing code first. I let Kiro write the specs instead.

I really want to test this approach: copy-pasting conference foto, giving a raw description of the idea discussed with Maurizio, and seeing what I get.

Kiro in this modality generates three files, that effectively became the north star for the entire implementation: requirements.md, design.md, and tasks.md.

Here is a fragment from the requirements doc:

## Introduction

KiroGraph-Sec is a security analysis module that extends KiroGraph's semantic
knowledge graph with dependency vulnerability detection and reachability-aware
impact analysis. Unlike traditional SCA tools that only report "vulnerable
dependency present," KiroGraph-Sec leverages the existing call graph and
architecture graph to determine whether vulnerable code paths are actually
reachable from the application's entry points.

This single paragraph captures the fundamental insight from Maurizio's talk: the problem with most SCA tools is not that they miss vulnerabilities. It is that they find too many and tell you almost nothing about which ones actually matter.

The design document defined the pipeline clearly:

code extraction → reference resolution → architecture analysis → security analysis

It was Kiro that figured out how the pipeline should run, and that the security analysis should depend on the previous steps, based on the KiroGraph code. Security runs last, after the call graph exists, because it needs to traverse it. This is the architectural constraint that makes everything else possible.

The Graph Model

Two new node kinds, three new edge kinds. That is it:

dependency  →  has_vulnerability  →  vulnerability
dependency  →  depends_on         →  dependency
dependency  ←  declared_in        ←  manifest file

The reachability verdict is the output of a BFS from all application entry points through call, import, and reference edges toward each Dependency_Node. Three possible outcomes:

• affected: a path exists. This CVE is reachable.
• not_affected: no path, no unresolved imports. You can document this with confidence.
• under_investigation: the traversal hit unresolved symbols (dynamic dispatch, reflection). Conservative by design: do not call it safe.

🔄 The Iterative Build: From 5 Ecosystems to 14

The first version of KiroGraph-Sec (0.19.0) shipped with the core pipeline: manifest parsing for npm, Maven, Go, pip, and Cargo; OSV integration; reachability analysis; and CycloneDX SBOM and VEX export.

I needed a working implementation to validate Maurizio's thesis in practice. Once it was up and running, the results were immediately tangible.

It was genuinely awesome: I found vulnerabilities in KiroGraph itself and could then iterate directly with Kiro, asking it to generate fixes and close them. The whole loop, from discovery to remediation, worked far better than I had expected.

Then I started closing gaps.

The reachability problem is what every other SCA tool avoids. Snyk charges for it and limits it to JS/Python. Trivy does not do it. OWASP Dependency-Check does not do it. KiroGraph-Sec does it for free, across 14 ecosystems, using the same call graph that already powers kirograph_context and kirograph_impact.

The ecosystem list grew quickly: NuGet, Gradle, RubyGems, Composer, Swift PM, Dart/pub, Elixir/Hex, and crucially, pyproject.toml support for modern Python projects (Poetry, PDM, Hatch, PEP 621), because nobody writes requirements.txt for new projects anymore. Plus pnpm-lock.yaml for the JavaScript monorepo crowd.

🔍 What Makes It Different

1. The Vulnerability That Does Not Actually Matter

kirograph vulns --verdict affected

[Risk: 8.2]  CVE-2023-44270  postcss@8.4.21  [affected]
  CVSS 7.5  EPSS 0.12 / 54th%
  reaches via: POST /api/compile -> buildStylesheet -> postcss.process
  Fix: npm install postcss@8.4.31

kirograph vulns --verdict not_affected

CVE-2024-1234  lodash@4.17.21  [not affected]
  CVSS 9.1  EPSS 0.03
  No reachable path from any entry point. No unresolved imports.

A CVSS 9.1 that does not affect you, and a CVSS 7.5 that does. Traditional SCA tools sort by CVSS and leave you to figure out the rest. KiroGraph-Sec sorts by risk score:

risk_score = reachability_factor × (0.4 × CVSS_normalized + 0.6 × EPSS) × staleness_bonus

The reachability_factor is 1.0 for affected, 0.5 for under_investigation, and 0.1 for not_affected. EPSS gets more weight than CVSS because it reflects actual exploitation probability in the wild, not theoretical severity.

2. Attack Surface Mapping

This is the feature that Maurizio's talk most directly inspired. Not "which deps have CVEs?" but "which HTTP routes reach vulnerable dependencies?"

kirograph attack-surface --public-only

Attack Surface  (47 routes total: 23 public, 24 authenticated)

Critical paths (routes reaching affected vulnerabilities):

[9.2] POST /api/compile      public      -> postcss@8.4.21 CVE-2023-44270 (2 hops)
[7.8] GET  /api/preview      public      -> lodash@4.17.20 CVE-2021-23337 (3 hops)
[4.1] POST /api/auth/login   public      -> bcrypt@5.0.0   CVE-2024-xxxx  (1 hop)

The BFS runs from every route node through call/import/reference edges to dependency nodes. The auth heuristic detects whether the path traverses functions named auth, authenticate, guard, middleware, etc. Public routes reaching vulnerable deps are your actual attack surface.

3. Secrets With Blast Radius

kirograph security secrets

CRITICAL  AWS Access Key ID                    src/config/aws.ts:14
          AKIA****  in configureAWS()  reachable from 4 entry points
          Rotate this key immediately and use environment variables

HIGH      Database URL with credentials        src/db/connection.ts:8
          postgres://****  in createConnection()  reachable from 12 entry points

Every other secrets scanner tells you file:line. This one tells you file:line, function, and how many entry points expose that function. That is the call graph doing the work that used to require manual review.

🤖 The MCP Integration: AI Does the Triage

Here is where Maurizio's vision closes the loop. KiroGraph-Sec exposes its full analysis as MCP tools, which means the AI coding assistant can query it without reading files:

kirograph_security()
-> "2 affected vulnerabilities, 3 under investigation, 0 not affected.
   Top risk: CVE-2023-44270 (Risk: 8.2) in postcss"

kirograph_reachability(target: "CVE-2023-44270")
-> "Verdict: affected
   Reaching entry points: 1
   Path: POST /api/compile -> buildStylesheet -> postcss.process
   Affected layers: api, service"

kirograph_attack_surface(publicOnly: true)
-> "3 public routes reach affected dependencies..."

The AI is not scanning files. It is querying a pre-computed semantic index and getting structured, actionable answers. This is exactly what Maurizio was describing: use AI as a reasoning layer over smart tooling, not as a replacement for the tooling itself.

If the agent is working on code that touches a vulnerable path, kirograph_context will automatically surface a security warning inline:

## Security Warning
- CVE-2023-44270 (CVSS 7.5, EPSS 0.12 / 54th%): postcss@8.4.21 (npm)
  reaches via: buildStylesheet
  Fix: npm install postcss@8.4.31

Moreover, KiroGraph-Sec introduces a set of security-focused MCP tools that allow the agent to answer the most common security, compliance, and software supply chain questions directly from the project graph. The goal is to provide actionable security insights through natural language queries, reducing the need to manually correlate information from multiple security tools and reports.

Topic	Example Question	MCP Tool	Why it was Developed
Security Overview	Give me a security overview of this project: total dependencies, CVE count, and verdict breakdown by reachability.	kirograph_security()	To provide a quick assessment of the project's overall security posture.
Reachability Analysis	**Is CVE-2023-44487 actually reachable from my entry points? **	kirograph_reachability()	To distinguish exploitable vulnerabilities from vulnerabilities that are merely present in dependencies.
SBOM Generation	Generate a CycloneDX 1.5 Software Bill of Materials for this project.	kirograph_sbom()	To support compliance requirements and dependency inventory management.
VEX Export	**Export the Vulnerability Exploitability eXchange with reachability verdicts for every CVE. **	kirograph_vex()	To communicate exploitability and reachability information alongside vulnerability data.
Attack Surface Analysis	Which HTTP routes expose vulnerable dependencies?	kirograph_attack_surface()	To identify externally accessible attack paths associated with vulnerable components.
Secrets Detection	**Are there any AWS keys, GitHub tokens, or database connection strings in the source code? **	kirograph_secrets()	To detect exposed credentials and sensitive information in the codebase.
Security Flow Analysis	Find SQL injection and path traversal patterns in the code.	kirograph_security_flows()	To identify common insecure coding patterns and risky data flows.
Supply Chain Health	Are there any abandoned packages or newly added packages that could be a supply chain risk?	kirograph_supply_chain()	To assess dependency health and detect potential supply-chain threats.
Dependency Confusion	Do we have internal packages whose names also exist in public registries?	kirograph_dep_confusion()	To identify dependency confusion and typosquatting risks.
Remediation SLA Tracking	Which CVEs have already breached their SLA threshold?	kirograph_remediation()	To monitor vulnerability remediation timelines and policy compliance.
License Compliance	Are there any GPL or AGPL dependencies that violate our policy?	kirograph_licenses()	To identify open-source license conflicts and compliance issues.
Dependency Staleness	Which dependencies are more than two major versions behind?	kirograph_staleness()	To highlight outdated libraries that may introduce security or maintenance risks.
Vulnerability Suppression	Suppress CVE-2024-1234 until December 31, 2026.	kirograph_vuln_suppress()	To manage false positives and accepted-risk scenarios.
Manual CVE Registration	Manually register CVE-2025-0001 against an internal package.	kirograph_vuln_add()	To track vulnerabilities affecting proprietary or internal software components.
Vulnerability Filtering	List all confirmed-reachable critical CVEs.	kirograph_vulns()	To enable focused analysis and prioritization of security findings.
CI/CD Security Reporting	Generate a SARIF report and fail the pipeline if critical vulnerabilities are found.	kirograph_security() + CI integration	To automate security validation and enforce policies during software delivery.

Together, these MCP tools enable KiroGraph-Sec to move beyond simple vulnerability enumeration by providing context-aware security analysis, reachability assessment, supply-chain visibility, and compliance support directly through the agent interface.

🧰 Beyond the Core: The Full KiroGraph-Sec Suite

After the initial release, the module grew into something broader than a traditional SCA.

Supply chain health. For each npm/PyPI/Cargo dependency, KiroGraph-Sec fetches the OpenSSF Scorecard score, maintainer count, and days since last activity. A Scorecard of 2/10 combined with a single maintainer on a critical transitive dependency is a risk that CVSS does not capture.

Dependency confusion detection. This checks whether your internal package names also exist in public registries. It is how the ua-parser-js attack worked. A one-line check in principle, but nobody does it automatically.

SAST-lite via call graph. Instead of AST-pattern matching (which generates enormous false positive rates), this uses the call graph to find dangerous data flows: SQL queries built from controller-like functions, eval() calls reached from request handlers, readFile calls in download-handling functions. Each finding is tagged with its OWASP Top 10 category.

CI/CD integration. kirograph security ci-report --format sarif produces a valid SARIF 2.1.0 file that uploads directly to GitHub's Security tab as code scanning results. --fail-on affected gives you a security gate with a clean exit code.

Remediation SLA tracking. Knowing about a CVE is not the same as fixing it. KiroGraph-Sec records when each vulnerability was first detected, when a fix became available, and surfaces overdue items (critical: 7 days, high: 30 days, medium: 90 days).

📊 The Dashboard

kirograph security export --open

This generates a self-contained HTML file, no server or external dependencies required, with 10 tabs: Overview, Vulnerabilities, Attack Surface, Secrets, SAST Flows, SBOM, VEX, Licenses, Staleness, Remediation. The Vulnerabilities tab defaults to sorting by risk score, shows EPSS badges, and lets you expand each CVE to see the call paths. The SBOM and VEX tabs include one-click CycloneDX JSON download.

💡 What the Kiro Specs Workflow Taught Me

Writing specs before code, particularly with Kiro, forced decisions that would otherwise have been deferred to implementation time. The requirements document defined what a Reachability_Verdict meant before a single line of traversal code existed. The design document resolved the pipeline ordering question (security runs after architecture) before the two modules had any coupling.

When Kiro generated tasks from those specs, it produced a dependency graph that was almost exactly right. The implementation followed the spec, not the other way around.

The most useful line in the entire spec turned out to be this one, from the design doc:

The key differentiator from traditional SCA tools is the reachability analysis: by leveraging KiroGraph's existing call graph, import edges, and architecture layers, KiroGraph-Sec can classify vulnerabilities as affected, not_affected, or under_investigation based on whether vulnerable code is actually reachable from the application's entry points.

🚀 Getting Started

npm install -g kirograph
kirograph init --index

Then enable the security module in .kirograph/config.json:

{
  "enableArchitecture": true,
  "enableSecurity": true,
  "securityDatabases": ["OSV"],
  "securityAutoEnrich": true
}

Run kirograph index, then:

kirograph security               # overview
kirograph vulns                  # sorted by risk score
kirograph attack-surface         # routes to vulnerable deps
kirograph security export --open # full dashboard

If KiroGraph-Sec is enabled, you will get a convenient steering file with examples on how to run a security audit workflow. In Kiro IDE, type /kirograph-security to activate the step-by-step security audit workflow.

---
inclusion: manual
---

# KiroGraph: Security Audit Workflow

Follow these steps for a structured security audit using the knowledge graph.
Activate this workflow before a release, after adding dependencies, or when asked to review security posture.

## Steps

### 1. Overview
kirograph_security()

Note: total dependencies, vulnerability count, verdict breakdown, stale warning count.

### 2. Triage reachable vulnerabilities

kirograph_vulns(verdict: "affected")

Focus only on confirmed reachable CVEs. Sort output by EPSS score (exploitation probability) first, then CVSS severity.

**Act immediately on:** EPSS >= 0.5 (actively exploited). Patch regardless of CVSS.
**Prioritize:** EPSS 0.1–0.5 over low-EPSS high-CVSS entries.
**Low urgency:** EPSS < 0.1 — use CVSS + reachability for triage.

### 3. Deep-dive reachability for critical CVEs
For each high-priority CVE from step 2:

kirograph_reachability(target: "<CVE-ID or package name>")

This shows: exact call paths from entry points, affected architectural layers, distinct path count.

- `affected` verdict with known entry points → fix this dependency
- `not_affected` → no reachable path, document and move on
- `under_investigation` → unresolved symbols, treat conservatively

### 4. Check for under-investigation CVEs

kirograph_vulns(verdict: "under_investigation")

For each: run `kirograph_reachability` to see what symbols are unresolved. If you can determine
the symbol is not called, you can downgrade to not_affected manually.

### 5. License compliance

kirograph_licenses(policy: true)

Review any DENY violations — these must be resolved before shipping.
WARN violations should be documented and approved by the team.

### 6. Dependency staleness

kirograph_staleness(threshold: 0.5)

Score guide: 0.3+ = worth reviewing, 0.7+ = significantly behind.
Cross-reference with step 2 results: stale + vulnerable = highest priority.

### 7. Refresh data if needed
If vulnerability data looks stale (flagged in step 1) or dependencies changed recently:

kirograph_vulns(refresh: true)


### 8. Export compliance artifacts

kirograph_sbom()   // Software Bill of Materials
kirograph_vex()    // Vulnerability Exploitability eXchange


## Interpretation Reference

| Signal | Meaning | Action |
|--------|---------|--------|
| `affected` + EPSS >= 0.5 | Actively exploited, reachable | Patch immediately |
| `affected` + CVSS >= 9.0 | Critical, reachable | Patch this sprint |
| `affected` + CVSS 7.0–8.9 | High, reachable | Plan fix within 2 weeks |
| `not_affected` | No reachable path found | Document, no action needed |
| `under_investigation` | Reachability unclear | Manual review required |
| Stale >= 0.7 | Very outdated | Review for accumulated CVEs |
| License DENY | Policy violation | Must resolve before release |

🏁 Conclusion

Maurizio's talk framed the problem perfectly: AI without smart tooling is just pattern-matching over files. The value comes from giving it a structured index to query, one that understands your code's call graph, architecture, and dependencies simultaneously.

KiroGraph-Sec is that index for security. It does not replace the AI agent. It gives it something worth querying.

The full source is at github.com/davide-desio-eleva/kirograph. The security module ships as part of version 0.19.0.

As per other modules, KiroGraph-Sec has it's own inspired mascotte.

🙋 Who am I

I'm D. De Sio and I work as a Head of Software Engineering in Eleva.
As of June 2026, I’m an AWS Certified Solution Architect Professional and AWS Certified DevOps Engineer Professional, but also a User Group Leader (in Pavia), an AWS Community Builder and, last but not least, a #serverless enthusiast.