Oryon Flow

In development · Early access

From signal to evidence.

Follow a Flow investigation: what it analyzes, how it checks a finding, what it requires from a fix and how results connect to technical requirements.

Fifteen tools, four surfaces.

15 Tools
  1. Code and secrets 4
  2. Dependencies and artifacts 4
  3. Infrastructure and deployment 3
  4. The running application 4
Distribution of the analysis catalog. Execution depends on the project and available profiles.
  • OpenGrep
  • Joern
  • Gitleaks
  • OSV-Scanner
  • Syft
  • Grype
  • Checkov
  • KICS
  • Terraform
  • ZAP
  • Playwright

Syft & Grype · Anchore · CC BY 4.0

An alert starts the investigation.

Verification preserves the difference between reproduced exploitation, an affected component and declared configuration.

Candidate

Independent verification

  • Confirmed
  • Refuted
  • Insufficient evidence

  • Investigates candidates from original source and groups shared causes.

  • Consults specialists and prepares executable verification methods.

  • Checks possible vulnerabilities against evidence and legitimate-behavior controls.

  • Separates confirmed, refuted and insufficient-evidence cases, without equating an affected dependency with demonstrated exploitation.

A patch needs evidence behind it.

Criteria and legitimate-use checks are fixed before a change. Delivery retains resolved cases and remaining work.

  1. Criteria and baseline

  2. Isolated change

  3. Verification and review

  4. Pull request for review

    GitHub

  • Admits confirmed findings with an identified repair target and a verifiable legitimate-use baseline.

  • Defines acceptance before patching and repeats security and behavior checks on isolated candidates.

  • Reviews changes separately and checks application order and composition between fixes.

  • Prepares GitHub pull requests and a delivery issue with evidence, remaining work and merge order. Your team decides integration.

Technical evidence, connected to your frameworks.

Flow maps evidence to selected technical requirements. It makes gaps visible and distinguishes observed status from projected status after fixes.

27Reference frameworks

64 selected requirements

  • 23Partial technical evaluation
  • 4Documentary reference
27 catalog frameworks: 23 with partial evaluation and 4 reference-only. These figures describe the catalog, not an organization's compliance level.
23 frameworks with partial technical evaluation
  • BIO2
  • BSI C5
  • CIS Controls
  • Cyber Resilience Act (CRA)
  • Cybersecurity Law (CSL)
  • Cyber Essentials
  • CyberFundamentals
  • DORA
  • Data Security Law (DSL)
  • ENS
  • FedRAMP
  • GDPR
  • HIPAA Security Rule
  • Australian ISM
  • ISMAP
  • LGPD
  • MLPS 2.0
  • NIS2
  • NIST CSF
  • NIST SP 800-53
  • OWASP ASVS
  • PIPL
  • SecNumCloud
4 documentary reference frameworks
  • ISO/IEC 27001
  • SOC 2
  • PCI DSS
  • MTCS

  • Links results to selected technical requirements in the reference frameworks.

  • Distinguishes observed status from the projected status after delivered verified fixes.

  • Retains criteria, traceability, gaps and evidence dates.

  • Keeps pending cases and limits visible; technical evidence does not equal certification.

Turn your evaluation into a next step.

Let's discuss your repository, team and the evidence you need.

Talk to the team
Privacy

This site uses cookies and local storage for technical operation, to remember your consent, and, if you accept it, to measure website usage. Measure Reddit campaign visits and installation clicks. Disabled until you allow marketing cookies.