OmniGuard

Source evidence, Jira remediation, and a matching rescan in one reviewable security workflow.

Comment

Inspiration

A security finding can lose its context as soon as it becomes a ticket. The developer sees a warning, the reviewer sees a status, and neither can easily tell whether the changed source was checked under the same conditions.

OmniGuard brings that context into Jira: the source behind a finding, the analysis that produced it, and the rescan used to verify the remediation. It is built from scratch as an independent project, with a local Rust security core and a separate Atlassian Forge app.

What it does

The workflow is scan → inspect evidence → create Jira remediation → import a matching rescan → record verification → complete the issue.

The local CLI analyzes Solidity syntax trees and can use native compiler facts to follow selected helpers, storage aliases and modifiers. Reports include exact source excerpts, locations, related declarations and SHA-256 snapshots. JSON, SARIF and complete source bundles make the results inspectable and reproducible.

The Forge dashboard independently checks an imported bundle's source hashes, excerpts, spans, finding identities and declared coverage. A reviewer can then create a real Jira Task. The remediation retains its engine, rule, compiler and analysis-mode baseline.

When the fixed source is imported, verification requires a changed source snapshot, complete compatible coverage and the absence of the tracked rule in the relevant file. A source-only zero-finding rescan cannot verify a task created from compiler analysis. The app writes a verification comment and offers an explicit Jira completion action. The record survives a reload.

How it is built

The Rust core uses tree-sitter Solidity syntax trees, optional native solc AST facts and bounded ordered-effect analysis. It runs without Node, Atlassian credentials or a chain connection. The Foundry-compatible CLI and authored local EVM witnesses are separate from the hosted integration.

The Forge app uses a Jira project page, Custom UI, a resolver, installation-scoped KVS and Jira APIs acting as the current user. Trusted project context, permission checks, duplicate-request handling and uncertain-outcome protection support the remediation flow. Forge validates the supplied evidence; it does not execute the scanner or attest that a supplied report is truthful.

The interface uses an evidence ledger, readable source excerpts, visible keyboard focus, text-labelled states and responsive layouts. Focused checks cover contrast, keyboard operation, narrow-screen reflow, reduced motion and recovery after a failed local rescan.

Challenges and lessons

The hard part is preserving meaning across a handoff. Cross-file evidence needs the correct digest for each source; a profile upgrade cannot silently change an existing review baseline; and a failed request must not leave a stale success message or create duplicate Jira issues.

The same principle applies to incomplete analysis. Unsupported dispatch and exhausted analysis bounds are reported explicitly, so an incomplete result cannot quietly become a verified fix. A later privacy review also removed an unused importer account-ID field and added a project-admin cleanup that preserves the actual evidence and Jira history.

What is demonstrated

  • Twelve Solidity rule classes, 38 passing Rust tests and 31 passing Forge tests, with both frontend builds and reproducible package checks passing in CI.
  • Three local effect-vault execution witnesses, including a 128-run paired fuzz property.
  • A frozen synthetic review matching 24 of 26 expected labels. Explicit-super dispatch and one composed-modifier case remain incomplete. These fixture measurements do not estimate production accuracy.
  • Real production remediation on cs0lutions as KAN-6, including rejection of a weaker rescan, verification comment 10005 and persistent Done status.
  • Public-link installation and the same workflow on a separate temporary Jira site as OGTEST-1, using the same administrator account.

The public captioned walkthrough shows the development workflow and a clearly labelled production result. Production is now Forge 2.1.0; engine 0.1.4 remains unchanged.

Try it and what comes next

The project guide provides the Forge installer and three isolated fixture reports. A Jira administrator can install the app; the demonstration needs no local compiler, wallet or live-chain transaction. The source repository includes build instructions, fixtures, tests and measured limitations.

This early release focuses on a reviewable Solidity-to-Jira workflow. The separate Bitbucket integration is a scaffold. Broader analysis, additional languages, live pull-request binding and Rovo features are future work. Source bundles remain stored, so reviewers should read the privacy notice and use authorized isolated material.

Built With

Share this project:

Updates

Submission history