insecure-source-code-management

Detect exposed version-control metadata and backup artifacts during authorized security testing.

2|Updated May 15, 2026
One-click install
npx skills add https://github.com/lNwNl/Methodos --skill insecure-source-code-management-lnwnl
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: insecure-source-code-management
Source: https://github.com/lNwNl/Methodos/tree/main/docker/opencode/skills/insecure-source-code-management
Command: npx skills add https://github.com/lNwNl/Methodos --skill insecure-source-code-management-lnwnl

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Exposes sensitive source-control metadata and backup/config artifacts that attackers can use to locate repositories, credentials, and internal infrastructure details.

Core Features & Use Cases

  • Detect VCS exposure: Probe common entry points for exposed Git, SVN, Mercurial, and related metadata such as .git/HEAD, .git/config, .svn/entries, and .hg/requires.
  • Differentiate 403 vs 404 accurately: Treat “403 on directory + 200 on specific files” as a strong signal that direct file fetching is still possible.
  • Support targeted recovery guidance: Select appropriate recovery/dumping tooling and prioritize high-value files like config, logs, refs, and object stores under authorized testing.

Quick Start

Use the insecure-source-code-management skill to probe a target for exposed .git/.svn/.hg paths and then recover repository metadata in an authorized assessment.

Frequently Asked Questions about insecure-source-code-management

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I check a website for exposed .git or .svn directory metadata?

Exposed .git directories are detected by probing paths like .git/HEAD and .git/config. A 403 response on the directory combined with a 200 response on specific files signals that direct file fetching is still possible and requires targeted validation.

Why does a 403 error on .git directory mean I can still fetch its files?

A 403 error on the .git directory itself does not always mean access is blocked. Treating 403 on the directory plus 200 on specific files as a strong signal reveals that direct file fetching is still possible and the repository metadata is exposed.

What is the best way to recover sensitive config files from exposed VCS metadata?

The best way to recover sensitive files is using targeted recovery guidance that selects appropriate dumping tools. It prioritizes high-value files like config, logs, refs, and object stores under authorized testing without unauthorized data movement.

Does this method detect exposed .env files and common backup artifacts?

Yes, this technique detects exposed backup and config artifacts such as .env files and common backup extensions. It identifies sensitive source-control metadata and configuration leaks discovered during authorized security testing.

Can I use VCS exposure probing for Mercurial .hg repository paths?

Yes, VCS exposure probing supports Mercurial by checking related metadata paths like .hg/requires. It detects exposed version-control metadata for Git, SVN, and Mercurial to help locate leaked repository and infrastructure details.