Trident is a self hosted platform for identifying, correlating, reviewing, and prioritizing vulnerabilities in source code.
The problem is not finding vulnerabilities. Static analyzers, dependency scanners, secret detection tools, and configuration scanners already do that well. The problem is what comes next. A typical scan can produce hundreds or thousands of findings with very little context about which ones actually require immediate attention.
Trident addresses that problem by combining deterministic security tooling, AI assisted review, adversarial analysis, and code governed triage.
Twelve security scanners run against the codebase and normalize their results into a common finding model. Findings are correlated and deduplicated before AI review. A council of specialized LLM experts then evaluates the remaining findings, challenges conflicting assessments, and sends contested or high severity findings to an independent judge.
The resulting findings are prioritized from P0 through P4 based on exploitability, reachability, impact, and other factors that can be supported by the available code and evidence.
This is a scanning and triage pipeline. The models contribute analysis and reasoning, while application code controls scoring, prioritization, persistence, and enforcement of deterministic rules.
Model Reasoning With Deterministic Guardrails
One of the design goals was determining where model reasoning works well and where deterministic controls are still required.
A hardcoded secret provides a useful example.
Across the models tested, hardcoded secrets were consistently evaluated using the most severe interpretation:
remote_unauth / auth_bypass / trivial
That assessment can be reasonable when looking at the finding in isolation, but it ignores an important constraint. Exploiting a secret stored in source code generally requires access to the source itself. Without evidence that the secret is exposed through another path, the vulnerability should not be treated as anonymously remote reachable.
On one real scan, model reasoning alone resulted in 34 P0 findings.
Applying a deterministic class guard reduced that number to 13. The remaining P0 findings were genuinely remote reachable, with no over escalations against the expert graded evaluation sample.
The same principle is applied throughout Trident. Models perform analysis, but deterministic application logic establishes boundaries where model judgment alone is not sufficiently reliable.
Twelve Deterministic Scanners, One Schema
Each scanner runs through an independent adapter that converts its results into the same internal finding schema.
Everything downstream, including correlation, expert review, triage, attack chain analysis, and reporting, operates on that normalized representation rather than scanner specific output.
SAST
- Semgrep using security audit, OWASP Top 10, and secrets rulesets
- Bandit
- gosec
Dependencies
- Trivy
- Grype
- pip audit
- npm audit
- OSV Scanner
Secrets
- gitleaks
- TruffleHog, including verification of whether discovered credentials are live
Infrastructure and Configuration
- Checkov for Terraform, Dockerfile, Kubernetes, and CloudFormation analysis
Go Reachability
- govulncheck, which identifies vulnerabilities associated with code paths that are actually called
Correlation Before AI Review
Raw scanner output is correlated before any model evaluates a finding.
Trident groups findings using file location, normalized CWE, line proximity, package information, and other available evidence.
Multiple CVEs associated with the same vulnerable package can be collapsed into a canonical finding rather than appearing as dozens of separate records.
When independent scanners identify the same underlying issue, that corroboration increases confidence in the finding instead of creating additional work for the reviewer.
The council reviews correlated findings rather than raw scanner output.
A Council of Security Experts
Trident uses specialized experts for different vulnerability classes, including injection, authentication, cryptography, dependencies, secrets, and configuration.
Experts initially review findings independently.
When their conclusions conflict, or when an assessment is uncertain, the finding enters a second review where experts can see and challenge the reasoning produced by the other reviewers.
This is not a majority vote.
Contested findings are sent to an independent judge for adjudication. Findings at or above high severity also receive independent judge review even when the council agrees.
Testing showed that model confidence alone was not a reliable indicator of correctness, so confidence is treated as supporting information rather than a reason to bypass additional review.
Finding Vulnerabilities the Rules Miss
Deterministic scanners remain the primary discovery mechanism, but Trident can also direct LLM experts toward portions of the codebase that warrant deeper inspection.
A sink pattern analysis identifies files and code regions containing security relevant behavior such as SSRF capable calls, unsafe deserialization, disabled template escaping, and similar patterns.
Experts receive code surrounding the actual sink rather than being given a filename and an arbitrary portion of the file.
During testing against a real target, this approach identified two reflected XSS templates that had not appeared in previous scanning passes.
Experts can also use bounded repository exploration tools, including grep, file reading, and definition lookup.
Tool use is controlled through per job limits so large repositories cannot create unrestricted model activity or cost.
Code Governed Triage
The council proposes an assessment. It does not assign the permanent priority by itself.
Confirmed findings are evaluated using code inferable factors such as:
- Impact
- Attack vector
- Exploitability
- Reachability
- Fix effort
A deterministic rubric converts those factors into a P0 through P4 priority.
The model is not called again to determine the final tier.
Additional class guards constrain categories that repeatedly produced inflated model assessments during testing.
A hardcoded secret cannot be treated as more reachable than local unless additional evidence demonstrates a remote exposure path.
A hygiene finding such as weak hashing, missing CSRF protection, or debug mode cannot receive an impact greater than denial of service unless an identified attack chain demonstrates a higher consequence.
When a guard changes an assessment, Trident preserves both the model’s original conclusion and the deterministic reason for the override.
The resulting priority remains traceable and auditable.
Priority Model
- P0: Fix immediately
- P1: Address during the current sprint
- P2: Schedule for remediation
- P3: Backlog
- P4: Hygiene or opportunistic remediation
Red Team Attack Chains
Trident performs a separate adversarial review across confirmed findings to identify realistic attack chains.
Individual vulnerabilities that appear moderate in isolation can become significantly more important when combined.
When a confirmed finding becomes part of a supported attack chain, its priority increases by one tier.
The relationship between the vulnerabilities and the reasoning behind the chain remain part of the finding record.
Vulnerability Workbench
Trident provides more than a severity score.
The findings interface exposes the verdict and rationale produced by each expert, disagreement between reviewers, judge decisions, deterministic overrides, and the final priority.
The triage interface turns findings into a working remediation queue.
Each priority tier includes an associated handling approach. A P0 finding is treated as requiring immediate action outside the normal remediation cycle. A P4 finding can be addressed opportunistically or documented when remediation is not justified.
Repositories do not require a Git remote.
A local directory can be selected through the browser, packaged locally, and uploaded directly for analysis.
Measuring Performance
Trident includes deliberately vulnerable evaluation targets and hand built scorecards to measure whether the system is identifying expected vulnerabilities.
The evaluation process uses a blinded semantic and structural matcher so the model performing the analysis does not receive the expected answer.
Current evaluation results include:
Demo banking application, 0.92 recall
OWASP training application, 13 of 13 expected findings identified after the sink pattern improvement
The evaluation framework is intended to measure the complete scanning and analysis pipeline rather than assuming that individual scanner or model output is correct.