Skip to main content

How Repo Scans Work

Overview​

Repo scans are designed to answer a real software review question, not just a pattern-matching question.

Instead of only saying this ZIP contains risky strings, Dralvia tries to tell you:

  • what software unit was reviewed
  • what projects exist inside the archive
  • what risky execution paths were observed
  • what dependency and provenance trust signals were found
  • whether your team should pass, review, or block the repository change

The normal repo scanner flow is static. It does not execute repo code during the standard review.

1. Validate and catalog the upload​

First, Dralvia validates and safely extracts the repository archive.

This stage is responsible for:

  • archive format validation
  • size and extraction limits
  • traversal and symlink protections
  • archive hash generation
  • repo identity metadata capture
  • scan lineage metadata

If you provide repo context such as provider, owner, repo name, ref, commit, or pull request, that information stays attached to the scan so later rescans and exports can be tied to the same review unit.

2. Partition the repository into real projects​

If the archive is a monorepo, Dralvia tries to split the result into meaningful subprojects or workspaces instead of collapsing everything into one long mixed list.

This matters because a single repository can contain:

  • frontend packages
  • backend services
  • worker processes
  • infrastructure folders
  • release tooling

By grouping projects first, Dralvia can explain which project is actually responsible for a finding.

3. Inspect code, automation, and execution paths​

After extraction, Dralvia reviews the repository for risky software-delivery behavior.

This includes:

  • install hooks and postinstall behavior
  • npm, Python, Rust, Java, Go, and container-related build signals
  • Git hooks
  • GitHub Actions and GitLab CI workflows
  • self-hosted runner exposure
  • secret echo patterns
  • exposed credentials, found by known-format detectors (private keys, cloud keys, provider tokens) and an entropy-validated generic detector that drops low-randomness false alarms; each secret finding carries a confidence level
  • remote bootstrap patterns such as curl | sh
  • Docker build steps
  • shell-heavy automation

This stage is important because many high-impact supply-chain incidents do not start from an obviously malicious repository. They start from a normal repository that contains unsafe automation or release logic.

4. Review dependencies and lockfiles​

Dralvia reviews dependency structure and lockfile quality so your team can see whether the repository is deterministic and trustworthy enough for release.

The review can include:

  • direct dependency graph by project
  • shared dependencies across projects
  • floating version ranges
  • rewritten sources
  • vendored or local dependencies
  • lockfiles that do not cover all manifests
  • integrity gaps and generated lock drift

When controlled enrichment is available, Dralvia can also add:

  • package advisory matches for pinned dependencies across npm, Python (PyPI), Go, Rust (crates.io), and Java (Maven), using the public OSV advisory database
  • publisher or maintainer drift signals

The scanner still remains useful even without enrichment, but enrichment adds more context for dependency trust decisions.

5. Review provenance and release trust​

Dralvia also looks at provenance and release evidence, not just manifests and scripts.

This includes:

  • provenance records such as in-toto or SLSA-shaped statements
  • Sigstore bundle-shaped files
  • signature material
  • builder identity hints
  • subject digest matches
  • commit-binding hints

Then Dralvia compares that provenance view against:

  • release workflows
  • committed release artifacts
  • attested shipped artifacts

That is how the product can now explain whether release outputs are actually linked back to reviewed source, or whether the repository has release files with weak or missing linkage.

6. Build the final result​

When analysis is complete, Dralvia produces a result that can be used by both people and downstream systems.

The result can include:

  • findings
  • grouped summaries by family, path, ecosystem, and project
  • dependency graph summary
  • execution path summary
  • workflow and IaC packs
  • artifact review summary
  • provenance summary
  • release linkage summary
  • fix guidance
  • engineering and AppSec ticket summary
  • exports such as SARIF, SBOM, provenance, gate, suppression, and manifest

7. Produce a CI-style recommendation​

The repo scanner does not stop at raw findings. It also produces a clearer recommendation for merge or release workflows.

Possible outcomes are:

  • pass
  • review
  • fail

This recommendation is built from:

  • finding severity and type
  • workflow and pipeline risk
  • dependency and enrichment signals
  • degraded or incomplete scan state
  • release-linkage evidence
  • selected CI gate policy profile

Why this matters​

A repository can look normal on the surface and still be risky to trust.

Examples:

  • a monorepo may contain one safe application and one dangerous bootstrap path
  • a dependency update may look small but come with publisher drift
  • a release artifact may exist in the repo without strong provenance linkage
  • a workflow may quietly escalate blast radius through self-hosted runners or over-broad permissions

The scanner exists to make those relationships understandable before your team merges, ships, or adopts the code.

Limits and ethics​

Only scan repositories you own or are authorized to assess.

Dralvia does not execute repository code during the normal static repo scan flow. If your organization needs deeper execution or sandbox review, that should be handled as a separate controlled workflow, not assumed inside the default repo scan.