Back to Help Index

Software Genomics, Groups, And Drift

VersionGopher™ compares software evidence from scans: hashes, versions, paths, formats, archive metadata, signing clues, and provenance. That can support drift detection for managed fleets, but it can also show generic scan similarity when the scans came from unrelated places. In the app this appears as Drift — the dashboard tile and each scan's drawer panel — powered by the Software Genomics method described here.

Drift is for repeatable fleet scanning. Software Genomics relatedness is useful more broadly, but related scans are not automatically the same host, same fleet, or same business purpose.
Managed Fleet Drift

Best for IT shops and small businesses that periodically scan the same kind of machines with the same options. Designate a known-good scan, approve it as the durable baseline, and compare later captures to that intentional reference.

workstations servers kiosks golden images
Generic Scan Similarity

Best when users upload unrelated folders, software collections, mounted shares, downloads directories, or historical evidence. The scans may share tools, packages, archives, or hashes without being a controlled drift set.

shared tools common packages same installer
Incident Response And Forensics

Helpful for finding overlap, lineage, known hashes, vulnerable software, suspicious binaries, and archive clues. It is usually not a drift workflow unless the evidence set represents a controlled repeat scan of the same image or endpoint scope.

case folders mounted images offline drives
M&A And Diligence

Useful for comparing target-company evidence, product images, inherited software, and sensitive archives. Grouping helps organize work, but a group name by itself does not prove why the scan was uploaded or whether scans should be treated as drift.

business units product lines acquisition targets

Designate And Use A Trusted Baseline

VersionGopher 0.7.19 lets platform, organization, and group administrators designate an ordinary scan as an explicit reference. Managed endpoint scans and uploaded embedded or firmware scans use the same lifecycle. A designation starts as candidate; approval is a separate human decision, and a superseded reference can be retired without erasing its history.

  1. Choose a scan whose target, collector options, privileges, and environment represent the trusted state. Record its scan ID from the scan details or administrative workflow.
  2. Create the candidate with POST /api/scans/<scan-id>/baselines. Supply an optional label and notes, plus one baseline_type: golden_image, mission, approved_fleet, or reference.
  3. Review the candidate, then approve it with PATCH /api/baselines/<baseline-id> and JSON {"status":"approved"}. Use candidate to reset approval or retired when the reference is no longer current.
  4. Compare a later scan with GET /api/scans/<scan-id>/baseline-comparison/<baseline-id>. The result includes similarity and drift percentages, hash-set measurements, file additions/removals/changes, environment deltas, and a guardrail explaining what the evidence can and cannot prove.
  5. Use GET /api/baselines to list active references visible to your admin scope. Add ?include_retired=1 for lifecycle history. Stored comparisons are reused; reserve ?force=1 for an intentional recomputation.
The 0.7.19 baseline lifecycle is an authenticated administrator API workflow; a point-and-click baseline manager is still planned. Do not treat an ML score, a group name, or simple similarity as approval. Baselines and comparison scans must remain inside the administrator's authorized organization or group scope.

How To Use Groups For Real Drift

Groups are a sharing and organization boundary. They also give teams a practical way to keep comparable scans together. For drift, create groups whose purpose is narrow and repeatable.

A group does not make scans drift-compatible by itself. The scan target, collector options, cadence, privileges, host context, and user intent still matter.

Creating A Group Before You Deploy

Create the group before you enroll machines or upload scans, so nothing lands in a catch-all group by accident. Two ways to do it:

Whoever creates the group becomes its owner. Owners can add members and set roles later under Admin → Projects / Groups → Manage — you do not need to sort out membership before deploying. Machines enrolled through an MSI bootstrap or Intune deployment always land in the group tied to that deployment, and drift is measured within that group.

Recommended Group Pattern For IT Teams

Use one group for each fleet slice that should behave like a baseline. Keep scan methods deterministic so the differences VersionGopher sees are likely to be real software changes.

How To Read Related Scans

Software Genomics looks for shared software markers. Strong overlap can mean many things: the same endpoint scanned twice, a clone, a reimage, a shared baseline, a common vendor package, an archive copied between systems, or simply a popular tool appearing in many places.

Rules Of Thumb