i've been building a thing called triagelens. you give it security logs, it finds the suspicious stuff, maps it to mitre att&ck, scores the whole run 0-100, and writes a short analyst-style report. but the feature i keep coming back to isn't a detection. it's that you can run the entire thing with no api key, no account, and no config file. sounds small. it took me two wrong turns to get there.

here's what kicked it off. i showed an early build to a friend who's also grinding through security certs. i said "just clone it and run it, it's easy." about twenty minutes later he texts me asking where the api key goes. there was a .env step. the readme mentioned it somewhere near the bottom. by the time he found it he'd already lost interest. the tool worked. the first thirty seconds of using it didn't, and that's the part that decides whether anyone sticks around.

that annoyed me more than a real bug would have. the detections were the part i actually cared about, and nobody was getting far enough to see them because setup ate the curiosity first.

so i changed what happens by default. there are three ways to run the report-writing layer now, and the one that loads first needs nothing:

• demo: rule-based text, no key, no network call. this is the default.
• ollama: a model running locally, so the logs never leave your machine.
• claude: cloud, writes the nicest summaries, needs a key.

you pick the provider in the ui and it saves to localStorage. no editing files. i went back and forth on that because storing config in the browser feels a little hacky, but the alternative was making every new person stop and edit a dotfile before they'd seen the tool do anything, and i'd just watched that kill it once.

the ai doesn't decide anything

quick architecture note, because it's the reason a no-key provider can even exist. the model never picks the findings. parsing, the detection rules, the att&ck mapping, the scoring, all of that is plain typescript with no model involved. same logs in, same findings out, every run. the provider only writes the prose at the end from findings that already exist. swap demo for ollama for claude and the findings and severities don't move, only the wording does.

so the default "demo" provider just templates the existing findings into readable text and skips the api entirely. the ai is an upgrade to the writing, not the thing doing the work.

a rule is just a function

the rules live in one file as pure functions. each looks at the parsed events and returns evidence strings, empty array if it didn't fire. here's roughly the encoded-powershell one:

{
  id: 'encoded-powershell',
  title: 'PowerShell launched with an encoded command',
  severity: 'high',
  techniques: techniques('T1059.001', 'T1027'),
  detect: (events) =>
    events
      .filter(
        (e) =>
          /powershell(\.exe)?/i.test(e.process ?? '') &&
          /\s-e(nc(odedcommand)?)?\b/i.test(e.commandLine ?? ''),
      )
      .map((e) => `encoded powershell on ${e.host}: ${e.commandLine}`),
}

nothing clever. -enc (or -e, or -encodedcommand) on a powershell process line is the tell, mapped to T1059.001 and T1027. because it's a plain function i can unit test it with five fake events and know it fires on exactly the case i want and stays quiet otherwise. no prompt tuning, no "please return valid json."

right now there are seven of these: encoded powershell, office spawning a child process (the classic malicious-doc chain), living-off-the-land binaries, execution out of a temp directory, windows log clearing, ssh brute force, and a successful login right after a brute-force burst. small list. it catches the obvious stuff and misses plenty.

why local actually matters

the ollama option isn't just a checkbox. the logs you'd most want to triage are exactly the ones you would not paste into some random cloud model. real auth logs, internal hostnames, usernames. with ollama the whole pipeline runs on your machine and nothing ships anywhere. for a learning tool that's a nice-to-have. for the actual job it's the difference between something you could use and something compliance would never let near a real log.

what's still rough

the honest list. it only reads evtx if you've already exported it to json, there's no native binary .evtx parser yet, so that export is an annoying manual hop. seven rules is not a lot. it is not a siem and i'm not pretending it is, it doesn't replace tuned detection content or a person deciding what actually matters. and the risk score is a weighted sum i tuned by hand on a handful of samples, so treat the exact number as a vibe, not gospel.

next on the list is sigma import, so nobody's stuck writing detections in my format, plus ioc extraction and exportable reports.

you can try it in the browser with the demo provider, no signup, sample log already loaded: triagelens.netlify.app
source: https://github.com/TiltedLunar123/triagelens

built with react, typescript, vite, and vitest for the rule tests. it works. not perfect but it works. if you write detections, tell me which of my seven rules is the weakest. that's the feedback i want most.