A supported version-control metadata artifact is publicly served
A supported version-control metadata path returned content matching a Subversion, Mercurial, or Bazaar artifact signature.
Why it matters
Public version-control metadata can reveal deployment artifacts that were not intended to be served. The observed artifact should be reviewed in the context of the actual deployment.
How ShipReady detects it
What it inspects
ShipReady probes only /.svn/wc.db, /.hg/requires, and /.bzr/branch-format on the scanned origin.
What triggers a finding
The rule requires HTTP 200 and a vendor-specific signature: a SQLite header for Subversion, bounded non-HTML Mercurial requires content with a recognised token, or a non-HTML Bazaar marker.
What the evidence shows
One supported path returned content matching ShipReady's native metadata signature for the reported version-control system.
Limits of this check
ShipReady does not retrieve additional repository files, reconstruct source or history, inspect .git, or establish that historical secrets exist. It does not follow redirects; non-200, unmatched, unanswered, or edge-blocked responses do not trigger the rule.
How to fix it
Stop serving version-control metadata
Remove the reported artifact from public output and publish only the intended application build.
Review related deployment artifacts
Check server and CDN static-file rules for other unintended working-copy files without assuming they are exposed.
How to verify the change
Request the reported path after deployment
Fetch the exact reported metadata path without credentials.
Expected: The path no longer returns the version-control metadata artifact.