Skip to main content

Now accepting design partners.

Request a demo

Integrations

Works with the tools your program already trusts.

REAEGIS reads from your pipeline and writes to your systems of record. Nothing you run is replaced.

REAEGIS reads from: Source control: GitHub, GitLab, Azure DevOps, Bitbucket. Scanners: Grype, Trivy, OpenSCAP, SonarQube. Infrastructure as code: Terraform, Kubernetes, Helm, Docker. REAEGIS writes to: Pull request: GitHub only. System of record: eMASS, ServiceNow, Jira. Transparency log: Rekor. In source control, GitHub is two-way: pushes in, pull requests out.

Three things happen at every connection.

The directory below uses three labels. Each one says which way data moves.

  • READS01

    REAEGIS takes in pushes, scan results and images.

  • WRITES02

    REAEGIS sends pull requests, POA&M updates, evidence and signed records.

  • TWO-WAY03

    Both directions on one connection. In source control, that is GitHub.

Find your tool.

Grouped by the job each tool does in the pipeline.

32 tools shown

01SOURCE CONTROL

Where REAEGIS reads pushes. GitHub also receives pull requests.

How a fix reaches GitHub
  • GitHubPUSHARERAMPART
    TWO-WAY

    Reads pushes, opens pull requests, sets commit status

  • GitLabPUSHRAMPART
    READS

    Reads pushes to protected branches

  • Azure DevOpsPUSHRAMPART
    READS

    Reads pushes to protected branches

  • BitbucketPUSHRAMPART
    READS

    Reads pushes to protected branches

02SCANNERS

Scan results REAEGIS takes in and validates as findings.

  • GrypeFINDADVERSARIUS
    READS

    Dependency and image vulnerabilities

  • TrivyFINDADVERSARIUS
    READS

    Dependency and image vulnerabilities

  • CheckovFINDADVERSARIUS
    READS

    Infrastructure as code checks

  • SemgrepFINDADVERSARIUS
    READS

    Static analysis

  • SonarQubeFINDADVERSARIUS
    READS

    Code quality results

  • OpenSCAPFINDADVERSARIUS
    READS

    STIG checks and CKL results

  • Tenable ACASFINDADVERSARIUS
    READS

    IAVA status

  • SnykFINDADVERSARIUS
    READS

    Scanner results

  • OSV-ScannerFINDADVERSARIUS
    READS

    Dependency vulnerabilities

  • TrufflehogFINDADVERSARIUS
    READS

    Secret detection

03SUPPLY CHAIN

What goes into a build, and the signature on what comes out.

How a record is verified
  • SyftBUILDRAMPART
    READS

    SBOM generation

  • Sigstore CosignATOCHRONICLE
    WRITES

    Signs every record and artifact

  • RekorATOCHRONICLE
    WRITES

    Anchors signed records in the public transparency log

04INFRASTRUCTURE AS CODE

Infrastructure files checked by the IAC_COMPLIANCE gate.

See the eleven gates
  • TerraformVERIFYRAMPART
    READS

    Evaluated against baselines on every push

  • KubernetesVERIFYRAMPART
    READS

    Evaluated against baselines on every push

  • HelmVERIFYRAMPART
    READS

    Evaluated against baselines on every push

  • DockerfilesVERIFYRAMPART
    READS

    Evaluated against baselines on every push

  • BicepVERIFYRAMPART
    READS

    Evaluated against baselines on every push

  • CloudFormationVERIFYRAMPART
    READS

    Evaluated against baselines on every push

05HARDENED IMAGES

Base images used when a fix rebuilds a container.

  • ChainguardBUILDARE
    READS

    Hardened base image for container rebuilds

  • Iron BankBUILDARE
    READS

    Hardened base image for container rebuilds

06SYSTEMS OF RECORD

Where status, results and evidence are delivered.

  • eMASSATOPHAROS
    WRITES

    POA&M status, results and artifacts

  • ServiceNowATOPHAROS
    WRITES

    GRC records

  • JiraFIXPHAROS
    TWO-WAY

    Tickets mirror findings and their status

  • Custom adapterATOPHAROS
    WRITES

    Your own system, through the adapter framework

07IDENTITY

How your people sign in.

Platform security
  • SAML 2.0NO STAGE OR ENGINE
    READS

    Enterprise sign-in

  • OpenID ConnectNO STAGE OR ENGINE
    READS

    Enterprise sign-in, with PKCE

  • CAC and PIVNO STAGE OR ENGINE
    READS

    Sign-in through your identity provider

The two-way connection, step by step.

One push, followed from the commit to a signed result. GitHub is the only source control where REAEGIS opens pull requests.

  • DeveloperAUTHOR
  • GitHubSOURCE CONTROL
  • REAEGISPLATFORM
  • Maya ReyesREVIEWER
  1. 1

    Developer pushes to a protected branch

    Developer sends git push to GitHub.
  2. 2

    GitHub sends the push event

    GitHub sends push event to REAEGIS.
  3. 3

    Gates are evaluated, commit status is set

    RAMPARTREAEGIS sends commit status to GitHub.
  4. 4

    A failed gate opens a finding

    ADVERSARIUSREAEGIS records finding 0482.
  5. 5

    A pull request with the fix is opened

    AREREAEGIS sends pull request #482 to GitHub.
  6. 6

    Maya Reyes approves and merges

    AC-5 reviewer is not the authorMaya Reyes sends approve, merge to GitHub.
  7. 7

    REAEGIS re-evaluates and signs the result

    RAMPARTCHRONICLEREAEGIS records signed record.
Sent by REAEGISSent by GitHub or a person
See how a fix is verified

Evidence lands where your assessor already looks.

REAEGIS does not replace your system of record. It keeps it current.

eMASS

The DoD system of record for RMF

WRITESPHAROS
  1. 01

    Export files

    In eMASS import format. Your ISSO uploads them.

  2. 02

    In-boundary agent

    Syncs POA&M status and results with a customer-owned PKI credential. REAEGIS never holds the key.

  3. 03

    Direct API

    Where network policy allows.

Which path fits your boundary

ServiceNow

WRITESPHAROS

GRC records, written through the adapter.

Jira

TWO-WAYPHAROS

Tickets mirror findings and their status.

What changes when the boundary does.

The same engines run in every model. These are the integration details that differ.

  • REAEGIS cloudRuns outside your boundary
  • In your boundaryInside an IL4 or IL5 environment
  • Air-gappedInside an enclave

WHAT DIFFERS

  • Vulnerability data

    NVD and OSV feeds

    REAEGIS cloud
    Live feeds (standard in this model)
    In your boundary
    Live feeds, or a mirror inside the boundary (set during scoping)
    Air-gapped
    Offline database, updated by scheduled transfer (standard in this model)
  • Transparency log

    Signed record anchoring

    REAEGIS cloud
    Public Rekor (standard in this model)
    In your boundary
    Public Rekor, or an internal log (set during scoping)
    Air-gapped
    Internal log (standard in this model)
  • eMASS path

    POA&M status and results

    REAEGIS cloud
    Export files your ISSO imports (standard in this model)
    In your boundary
    In-boundary agent, or direct API where network policy allows (standard in this model)
    Air-gapped
    Export files, inside the enclave (set during scoping)
  • Pull requests

    GitHub only

    REAEGIS cloud
    To your GitHub (standard in this model)
    In your boundary
    To your GitHub, inside the boundary (standard in this model)
    Air-gapped
    To your GitHub, inside the enclave (set during scoping)
  • Scanners

    As listed in the directory

    REAEGIS cloud
    All listed (standard in this model)
    In your boundary
    All listed, run inside the boundary (standard in this model)
    Air-gapped
    Bundled in the signed kit (standard in this model)
Compare the three boundaries

Run something that is not here?

Custom adapter

Tell us what you run and we will tell you plainly whether it fits.

Contact

Authorization is not a destination. It is a system property.

Request a demo and we will walk one finding from detection to signed evidence.

  • Federal programs

    Invitation only, with CAC and PIV.

    Request access
  • Commercial teams

    Self-register with single sign-on.

    Create a workspace
  • Pricing

    Plans start at $2,500 per month. In-boundary and air-gapped deployments are scoped per program.

    See pricing