Tron - Threat Response & Open-source Neutralizer

TRON: From vulnerability detected to MR merged, automatically.

Comment

Inspiration

Every team using AI to write code faster is creating a new problem they have not solved yet. GitLab calls it the AI paradox, AI accelerates code creation but security remediation, vulnerability fixes, and compliance checks remain entirely manual. The average time to remediate a known vulnerability is 60+ days. Most teams never get to the bottom of the security queue at all.

We have lived this problem. A CRITICAL CVE gets published, a ticket gets created, it sits in the backlog, gets deprioritised, and three sprints later someone finally bumps the version. Meanwhile the application is running a package with a publicly available exploit.

When GitLab announced the Duo Agent Platform we saw the opportunity to build something that does not just report vulnerabilities, but actually neutralizes them. Automatically. Before the developer even has to think about it.

What it does

TRON is an autonomous DevSecOps agent built natively on the GitLab Duo Agent Platform. It scans your repository across five security surfaces and fixes everything it can, without waiting to be asked.

Five security surfaces in one agent:

  • Dependencies — detects CVEs in Python, Node.js, Ruby, Java, Rust, Go, PHP, and .NET packages. Calculates minimal safe upgrades. Commits the fixed manifest. Opens a ready-to-merge MR.

  • Containers — scans Dockerfiles and docker-compose files for vulnerable base images, hardcoded secrets in ENV, curl pipe bash patterns, running as root, and 10 other insecure patterns.

  • Infrastructure as Code — scans Terraform, Kubernetes, Helm, and Ansible files for CIS Benchmark violations — public S3 buckets, open security groups, unencrypted RDS, wildcard IAM permissions, privileged containers.

  • Cloud Config — scans AWS, GCP, and Azure configuration files for hardcoded credentials, disabled CloudTrail, overprivileged service accounts, and storage misconfigurations.

  • APIs — scans OpenAPI, Swagger, and GraphQL specs for OWASP API Top 10 violations — missing authentication, HTTP Basic auth, API keys in query parameters, PII field exposure, missing rate limiting.

How you trigger it:

Open a chat and just tell → @tron, inititate nightly things on main branch Mention @tron in any MR or issue comment → full scan runs.
Open a merge request → CI pipeline posts @tron automatically.
Every night at midnight → scheduled scan covers the full repository.

What it produces:

One main tracking issue per run with a complete vulnerability summary. One child issue per CVE, each linked to its own remediation MR. Every MR has Closes #issue so merging it automatically closes the issue. Full audit trail. SBOM in CycloneDX and SPDX formats.

How we built it

TRON is built entirely on the GitLab Duo Agent Platform using a hybrid prompt and data architecture.

The agent layer — a single agents/agent.yml with a 13-phase system prompt. Every phase is marked COMPLETE when finished so the agent never loops. The agent reads policy configuration and security databases at runtime rather than relying on training knowledge.

The flow layer — six specialist YAML flow files, one per security surface. The agent reads these files inline using read_file and executes their logic directly. No separate triggers needed. One @tron runs all six.

The data layer — local intelligence databases the agent cross-references at runtime:

  • security/known_exploits.json — 14 packages with CVE details, CVSS scores, fixed versions, and exploit availability flags
  • security/base_image_advisories.json — 28 vulnerable Docker base images with safe alternatives
  • security/iac_misconfigurations.json — 20 CIS-mapped IaC rules
  • security/api_security_patterns.json — OWASP API Top 10 patterns

A finding in both the GitLab advisory database and the local database is flagged as HIGH CONFIDENCE, backed by two independent sources.

The policy layer — config/policy.yml and config/ecosystem_policy.yaml define all org-specific rules. Severity thresholds, upgrade strategies, forbidden licenses, allowed base images — all configurable without touching agent code.

The tool layer — Python files in tools/analysis/ define the algorithms for dependency graph building, attack path analysis, version resolution, and risk scoring. The LLM reads these files as reference and reasons from their logic. This grounds the AI's reasoning in deterministic code rather than training guesses.

The SBOM engine — an 8-phase pipeline in sbom_platform/ that generates CycloneDX and SPDX Software Bill of Materials with cryptographic validation, license classification, provenance tracking, and immutable audit trails for SOC2 compliance.

Exploit confidence scoring — for each HIGH or CRITICAL vulnerability TRON calculates an exploit confidence score from 0 to 100:

$$\text{score} = 50 + 30 \cdot \mathbb{1}[\text{exploit available}] + 20 \cdot \mathbb{1}[\text{direct exploitable}] + 10 \cdot \mathbb{1}[\text{high confidence}] - 10 \cdot \mathbb{1}[\text{non reachable}]$$

A score of 80–100 means Actively Exploitable — Fix Immediately.
A score of 50–79 means Likely Exploitable — Fix within 24 hours.
A score below 50 means Low Exploit Risk — Fix in next release.

Challenges we ran into

The GitLab Duo schema is strict. Fields like routing:, version:, and consumers: that look like they should work cause schema validation failures. We spent significant time learning exactly which fields are valid and which are not.

create_commit uses a different project identifier than list_vulnerabilities. The commit tool expects a numeric project_id while the vulnerability tools expect a string project_full_path. When the agent confused an MR iid (like 55) with the project id (like 35139603) every commit failed silently. We fixed this by making get_project the very first tool call in every run and explicitly documenting which format each tool requires.

The agent would loop infinitely on file reads. Without explicit phase completion markers, TRON would read known_exploits.json and manifest files repeatedly, hitting the context window limit and restarting. We fixed this with Phase N COMPLETE markers and a global rule that each file is read exactly once per run.

Automatic triggers without Settings access. The consumers: block in agent YAML is not supported in the current schema, and routing: blocks also fail validation. We discovered that the only reliable automatic trigger for custom agents on the current platform is assigning an issue to the TRON service account, a native GitLab Duo external agent trigger that requires zero setup and zero Settings access. This became our primary activation mechanism alongside @tron mentions in comments.

Accomplishments that we're proud of

A single @tron covers five security surfaces. No separate agents to configure, no separate pipelines to maintain. One assign or one mention runs the full suite.

Policy-as-code architecture. Every enforcement threshold lives in YAML configuration files. Change policy.yml once to update the behaviour of all six agents simultaneously.

Full issue traceability hierarchy. Every TRON run produces one main tracking issue with all child issues attached. Each child issue links to its remediation MR. Merging the MR closes the issue automatically. The security team has a complete audit trail with zero manual linking.

Hybrid AI + deterministic architecture. The LLM reads real Python algorithm files as reference. Dependency graph logic, attack path classification, version resolution, all grounded in actual code, not training guesses. This makes findings reproducible and explainable.

The dependency attack graph. TRON generates a Mermaid diagram classifying every vulnerable package as DIRECT_EXPLOITABLE, TRANSITIVE_EXPLOITABLE, or NON_REACHABLE. Each node is colour-coded. Exploit paths are labelled on the arrows. A developer can look at one diagram and understand exactly where their risk is concentrated.

What we learned

Building on GitLab Duo Agent Platform taught us that prompt engineering at production scale is a systems design problem, not just a writing problem. The hardest bugs were not hallucinations, they were loop prevention, state management, and parameter type mismatches between tools.

We learned that hybrid architecture, LLM reasoning combined with structured data and algorithm files, produces significantly more reliable output than prompting alone. Giving the agent real code to reason from is more effective than describing the algorithm in natural language.

We also learned that autonomous agents need explicit completion markers and verification steps at every phase. Without them, the agent optimises for appearing to make progress rather than actually making it.

What's next for Tron - Threat Response & Open-source Neutralizer

Native event triggers — as the GitLab Duo Agent Platform matures and supports consumers: event blocks natively, TRON will fire on merge_request_opened, vulnerability_detected, and pipeline_failed as first-class platform triggers — no CI bridge required.

Vulnerability auto-response — vulnerability_trigger_flow.yml is designed and ready. The moment GitLab's advisory database receives a new CVE, TRON checks every repository in the organisation and commits fixes before the security team is even aware of the new CVE.

Cross-repository scanning — scan every project in a GitLab group in a single TRON run. Produce an organisation-wide security posture report with aggregate risk scores across all repositories.

Compliance automation — automated SOC2, HIPAA, and PCI-DSS evidence generation using the SBOM audit trail engine. Compliance reports generated on demand or on a weekly schedule.

Predictive intelligence — ML-based risk prediction that flags packages likely to receive a CVE before one is published, based on maintenance activity, publisher reputation, and historical vulnerability patterns.

Multi-language expansion — deeper support for Go modules, Rust crates, and Java Maven beyond the current Python and npm focus.

Fully automatic CI-based triggers — .gitlab-ci.yml jobs using CI_JOB_TOKEN that post @tron automatically via the GitLab API on every MR opened, pipeline failure, push to main, and nightly schedule. All four trigger jobs are already designed and ready in our repository. Zero Settings access required since CI_JOB_TOKEN is injected automatically into every pipeline by GitLab. Activation requires only pushing .gitlab-ci.yml to the repository.

Built With

Share this project:

Updates