Skip to main content

Repo Scanner

What this product does​

Dralvia Repo Scanner helps your team answer a practical question:

Can we trust this repository enough to merge it, release it, or hand it to another team?

It is not just a file-pattern scanner. It reviews a repository as a software delivery unit and explains:

  • what repository was reviewed
  • which branch, ref, commit, or pull request it belongs to
  • which projects or workspaces were found inside the archive
  • what risky install, build, release, and CI paths were observed
  • what dependency, lockfile, provenance, and release-trust signals were found
  • whether the result should be treated as pass, review, or fail

What Dralvia looks for​

The Repo Scanner looks across several supply-chain layers at once.

Repository identity and scan lineage​

Dralvia records the review context so rescans and exports stay tied to the same software review unit:

  • provider, owner, and repo name
  • branch, tag, or ref
  • commit SHA
  • optional pull request or change-request label
  • archive SHA-256
  • scan lineage metadata for later rescans, enrichments, and exports

Project and workspace structure​

If the ZIP contains a monorepo, Dralvia does not flatten everything into one unreadable list. It groups the review by real projects or workspaces so your team can see:

  • which subproject is affected
  • which ecosystem it belongs to
  • which findings matter most for that project
  • which dependency graph belongs to which project

Static execution paths​

Dralvia reviews the places where code can start running automatically, including:

  • install scripts
  • postinstall hooks
  • build steps
  • release scripts
  • GitHub Actions
  • GitLab CI
  • Docker build steps
  • shell automation and bootstrap scripts

This matters because many supply-chain incidents come from trusted codebases that still contain dangerous execution paths in automation.

Dependency and lockfile trust​

Dralvia reviews dependency manifests and lockfiles to help you understand whether the repository is pinned and predictable, or loose and risky.

Examples include:

  • floating version ranges
  • source rewrites to Git URLs or local file paths
  • vendored or local dependencies
  • missing lockfile coverage
  • integrity mismatches and generated lock drift
  • advisory matches from controlled enrichment
  • publisher or maintainer drift where registry metadata is available

Provenance and release trust​

Dralvia reviews provenance signals instead of only counting whether a provenance-looking file exists.

It can inspect:

  • in-toto statements
  • SLSA-style predicates
  • Sigstore bundle-shaped records
  • signature material
  • subject digest matches
  • builder identity hints
  • commit-binding hints

It also compares release workflows, committed release artifacts, and attested subjects so your team can tell whether shipped artifacts are actually linked back to reviewed source.

What the result means​

Each repo scan produces a human-readable result plus machine-usable exports.

The first screen now leads with a verdict-first summary so reviewers can understand the outcome faster before diving into the deeper supply-chain panels.

Main result areas​

A typical result can include:

  • verdict headline and risk score
  • top reasons for the strongest release or supply-chain drivers
  • trust and provenance summary
  • recommended next step
  • processing snapshot
  • overall risk score and level
  • findings grouped by family, path, ecosystem, and project
  • dependency graph by project
  • execution paths and release chains
  • workflow and IaC risk packs
  • binary and generated artifact review
  • provenance summary
  • controlled enrichment summary
  • release artifact linkage
  • merge and release recommendation
  • engineering and AppSec handoff summary

CI gate output​

The repo scanner also produces a clearer CI-style recommendation:

  • pass: no current signal suggests the repository should be blocked
  • review: a person should review before merge or release
  • fail: blocking supply-chain issues were found and the change should stop until fixed

This is meant to reduce ambiguity for engineering teams. Instead of opening a raw JSON export and deciding what it means, the team gets a direct recommendation with supporting reasons.

The UI does not replace the detailed review sections. It changes the order and readability of the first screen so the release recommendation, strongest reasons, provenance/trust context, and next action appear before the denser technical breakdowns.

The repo journey now also standardizes its state handling:

  • an explicit empty state before any artifact is submitted
  • a shared processing state while the artifact is under review
  • a dedicated top-level error state if the scan fails before a usable result is returned
  • a partial-result banner when the existing CI gate or workflow metadata says coverage is degraded or unknown

What your team can export​

Depending on the scan and feature availability, Dralvia can produce:

  • JSON result export
  • SARIF
  • SBOM
  • provenance export
  • suppression export
  • CI gate export
  • ticket summary export
  • signed manifest and artifact links
  • EvidencePack (Dralvia's exportable evidence report), when enabled for your environment

What Dralvia does not do in this flow​

The repository scanner is designed to stay safe and controlled.

It does not:

  • execute repository code as part of the normal static repo review
  • blindly trust provenance files just because they exist
  • assume a monorepo is one single project
  • treat every binary file as equally suspicious

Good use cases​

The Repo Scanner is especially useful when your team needs to:

  • review third-party source before adoption
  • review internal repositories before release
  • validate CI or release changes in pull requests
  • inspect risky monorepos with mixed ecosystems
  • export a CI gate summary for downstream approval workflows