Trinetra: Security for Builders

Up to this point the master class has lived mostly in the realm of ideas. We traced, in Mythos, how the work of finding and weaponizing software flaws is being handed to machines, and we sketched, in the Autonomous SOC, what it looks like when defenders answer that shift with automation of their own. This chapter is where the argument meets the keyboard. The platform we will use is called Trinetra, reachable at trinetra.nirvik.ai, and its tagline tells you who it is built for: Security for Builders. It is not a console for a distant security team to peer at your work from above. It is a tool meant to sit inside the workflow of the people who actually write the code, and to help them find and repair weaknesses before those weaknesses become someone else’s opportunity.

See where things break first

Before running the tool, it helps to have a mental picture of where software fails. The Attack Surface Maps are interactive diagrams of four everyday systems — an e-commerce app, a mobile app, a connected car, and a smart device — with every weak point, its likely issues, and its defenses. The kinds of issues Trinetra surfaces in the lab are exactly the ones marked on those maps.

What Trinetra does

Trinetra is not a single monolithic scanner; it is a swarm of more than thirty specialized agents (32 today) that work in concert, each narrow and focused and good at one job. Together they cover the whole security surface, organized into six families:

Agent family	Focus	Specialists
Code & Supply Chain	source-code flaws, dependencies	8
Pentest & Recon	attacker’s-eye probing, exposure	8
Cloud & Infrastructure	cloud config, IaC, posture	5
Posture & Governance	standards, policy, hygiene	5
Threat & Response	detection, triage, response	3
CI/CD & Orchestration	pipeline integration, automation	3

When you connect a target — a repository, a URL, an API endpoint, a cloud account, or any combination — Trinetra fingerprints what you have, picks the right skills, and the agents scan in parallel across code, dependencies, cloud config, TLS, and runtime all at once. The findings are then triaged, deduped, and translated into plain English: each one ranked, explained like a mentor would (what it is, why it matters), and paired with a concrete fix you can click straight through to in your code.

From there the loop closes in one of two ways, and both matter for this lab:

• Automatic pull requests. Rather than dumping a report in a separate dashboard, Trinetra can open a pull request carrying the suggested fix — the repair enters the same review-and-merge pipeline you use for every other change. A pull request (PR) bundles the exact lines being changed, a description of why, and a place for teammates to comment and approve. The fix lands exactly where developers already work, with no context-switch.
• Automated reviews in CI/CD. The CI/CD & Orchestration agents let Trinetra run as an automated reviewer on every push and pull request in the repository — shifting security left into the build pipeline so new vulnerabilities are caught and commented on continuously, not in a once-a- quarter audit. Security becomes part of the development workflow rather than a gate bolted onto the end of it.

It works where you already work — GitHub, the major clouds (AWS / GCP / Azure), any framework, and Docker / Kubernetes — and runs on the LLM setup you trust, including bringing your own provider key. For this lab we will use a single repository and the analyze → PR path by hand, but keep the bigger picture in mind: in real use, this is running continuously across your whole pipeline.

Why the name fits

Trinetra means “three-eyed” — Shiva’s third eye, the one that sees what ordinary sight misses. It is a fitting name for a tool whose job is to perceive the vulnerabilities hiding in plain sight within your code, the ones a routine read-through glides past, before an attacker’s automated tooling finds them first.

Where it fits in the post-Mythos world

The Mythos lecture made an uncomfortable claim concrete: if the generation of working exploits can be automated, then the time between a vulnerability becoming known and an attacker being able to use it collapses toward zero. In that world, patch latency — the lag between a flaw existing and a fix shipping — stops being a metric on a quarterly report and becomes something close to existential. The window in which you are exposed is exactly the window your adversary’s tooling needs, and that window is shrinking.

There are only two honest responses to a shrinking window. One is to shift left: to move security work earlier in the lifecycle, catching and fixing flaws while code is being written rather than after it has shipped and an incident has forced the issue. (The phrase comes from picturing the software timeline left-to-right, from authoring on the left to production on the right; “shifting left” means doing the work nearer the start.) The other is to shorten the find-fix loop itself, so that even the flaws you do not catch early get repaired in hours rather than quarters. Trinetra is aimed squarely at both. It does not merely detect — detection alone just produces a longer backlog — it drafts the fix, as a reviewable change, which is the slow and tedious part of the loop for a human to do by hand.

This is the Autonomous SOC pattern applied to the codebase: an AI agent does the heavy lifting of reading, reasoning, and drafting, while a human stays on the loop — not approving every keystroke, but reviewing and approving the consequential output. The post-Mythos chapter argues this is not optional cleverness but the only arithmetic that works once offense is automated; you can read more on the framing in our reference sources.

Connect repo → Trinetra analyzes → Findings (vuln + risk + fix)
            → Human triage/review → Open PR with fixes → Review + merge

A finding, walked through

To make this concrete, imagine a small internal web application written in Python using the Flask framework — the sort of thing a team spins up to look up customer records. Somewhere in it is a function that builds a database query by gluing user input directly into a SQL string:

query = "SELECT * FROM users WHERE name = '" + request.args["name"] + "'"

This is a textbook SQL injection flaw. Because the user’s input is pasted straight into the query text, an attacker can type input that is no longer just a name but a fragment of SQL — closing the quote, adding OR 1=1, perhaps appending a second statement that dumps the entire table. The analysis surfaces this line, names the vulnerability, and explains the risk in plain terms: any visitor who can reach this endpoint can potentially read or alter data they were never meant to touch. The proposed fix is the standard one — use a parameterized query, where the input is passed as a separate value the database driver treats strictly as data, never as code:

query = "SELECT * FROM users WHERE name = ?"
cursor.execute(query, (request.args["name"],))

The same shape of reasoning applies to a hardcoded secret — say an API key or database password committed directly into a config file, where anyone with read access to the repository (or to its history) effectively holds the keys. The finding flags the exposed value; the fix moves it to an environment variable or a secrets manager and, crucially, notes that the leaked value must also be rotated, since what has been committed must be treated as already compromised.

The human stays on the loop

The lecture’s warning about automated offense applies, in mirror image, to automated defense: a fix the tool drafts is a draft, not a decree. The discipline this lab will demand of you is exactly the supervisory judgment that the Autonomous SOC model depends on. Before you let any proposed change become a real pull request, you weigh it:

• Is the finding a real vulnerability, or a false positive — an alarm raised by a pattern that happens to be safe in this particular context? (A false positive is a flagged issue that, on inspection, turns out not to be a problem at all.)
• Is the proposed fix correct, and does it preserve the code’s intended behavior rather than quietly breaking it?
• Does the change need a test to prove the fix works and to guard against the bug creeping back in later?

Defend what you ship

The goal of the lab is not to merge as many machine-generated fixes as fast as possible. It is to ship a pull request you can defend — one whose risk you understand, whose change you have read, and whose correctness you would stake your name on in review.

How to read the findings

Treat each finding as a claim to be tested, not an answer to be accepted. Read the vulnerable code, reconstruct the risk in your own words, then check that the proposed fix actually neutralizes it. That habit is what turns an AI assistant into leverage instead of a liability.

With the framing in place, it is time to put hands on the platform. Continue to the hands-on lab, where you will connect a repository, run an analysis, triage what Trinetra finds, and open a fix you are prepared to stand behind.