BreachLens

Home Page
Findings + How your vulnerabilities can be exploited
Findings color coded based on severity
Raw Scans
AI powered analyst

Write-Up

Most small businesses have zero visibility into their security posture. A proper audit costs money they don't have, so issues like missing email authentication or open SSL configs just sit there, unnoticed, until something goes wrong.

BreachLens gives anyone that visibility in seconds, for free, using only public data. You type in a domain, and it runs a fully passive scan — DNS records (SPF, DMARC, CAA), SSL/TLS health, security headers, cookie flags, exposed files, and subdomains pulled from certificate transparency logs.

The raw data isn't the interesting part — it's what happens next. Findings flow through a three-pass AI pipeline: one pass explains each finding individually in isolation (so findings don't anchor each other's framing), a second acts like a senior analyst synthesizing everything into an overall risk score and a prioritized "fix this first" summary, and a third writes a realistic exploit scenario based only on what was actually found — paired with copy-paste-ready fixes.

A core design principle runs through every layer: severity, risk score, and risk level are always computed deterministically, never by the AI. The AI's only job is explaining findings clearly. If it fails or times out at any stage, the system degrades gracefully through four independent fallback layers — per-finding, per-pass, per-report, and a top-level budget race — rather than breaking the report entirely.

This discipline paid off directly: spec-driven verification caught a real defect where scan results were silently leaking full HTTP response bodies into the report, violating the passive-only guarantee — caught by an automated property test, fixed, and re-verified before shipping.

The system is also honest about uncertainty — it only names a DNS provider when the match is solid, falling back to generic instructions rather than confidently guessing wrong.

BreachLens is stateless and database-free, making it fast, privacy-friendly, and trivial to deploy — exactly the kind of free, instant security check small businesses actually need.

How I used Kiro

The challenge: Small businesses and solo founders have no budget for a security audit, and most off-the-shelf scanners produce raw, jargon-heavy output nobody without a security background can act on. The opportunity was to make a passive scan readable, trustworthy, and instantly useful — without overclaiming or hallucinating findings.

How BreachLens solves it: It separates the scan (deterministic, fact-based) from the explanation (AI-generated), then layers a three-pass AI pipeline on top. Each pass is a clearly scoped component: Pass 1 classifies findings independently and concurrently so no finding anchors another's framing; Pass 2 synthesizes them into a unified risk picture with a deterministic score the LLM cannot override; Pass 3 generates a grounded exploit narrative constrained to only what was actually found. The result reads like a human analyst wrote it, while staying provably grounded in real findings.

Kiro features used: Full spec workflow (requirements → design → tasks) for six components: the passive scan engine, each of the three AI passes, the deterministic fallback system, and the fix-recheck feature — each spec'd, implemented, and verified independently with property-based testing (100–200+ iterations per property). The spec for each component captures not just what to build but why key decisions were made — for example, why per-finding concurrent calls beat batching (LLM output is token-bound, so N small parallel calls outperform one large sequential one), and why severity classification was pulled out of the LLM entirely into a fixed mapping.

How this shaped the build: Spec-driven verification wasn't just process — it caught real defects and actively shaped the implementation. One property test revealed that scan results were leaking full HTTP response bodies into reports, violating the passive-only guarantee; another caught a prototype-collision bug (a finding ID like "constructor" silently breaking object lookups) that recurred in two separate files once we knew the pattern. Several spec requirements were also revised mid-process when verification revealed divergence from the actual implementation — for example, the analyst-synthesis spec's timeout wording was corrected after code inspection showed a per-attempt (not total) timeout model, and a case-sensitivity gap in severity matching was found and fixed rather than just documented. Each time, the spec's isolation meant I could fix one component without touching neighboring logic or risking regressions elsewhere.

The repeated loop — spec, implement, verify with property tests, find an edge case, fix, re-verify — became the core development rhythm. Kiro's structure is what made that loop fast and safe across six independent specs rather than one fragile monolith.

All six spec folders are committed at .kiro/specs/ in the GitHub repo — each containing the full requirements → design → tasks artifacts that drove the build and verification suite for that component.