Repo Scan

Skill: Repository Scan — Cross-Stack Source Code Audit

Supplementary Files:

• payloads.md — Repository scanning commands, classification scripts, and analysis payloads organized by scan phase
• test-cases.md — Structured test cases for surface classification, dependency detection, hotspot mapping, and complete audit workflows

Summary

Repo Scan skill domain covering assessment operations.

Domain: assessment

Description

Cross-stack source code asset audit that classifies every file, detects embedded third-party libraries, and delivers actionable verdicts per module. This skill is used during white-box penetration testing and security code reviews to understand what code is present, what's third-party, and where security risks may hide.

Difference from security-review: security-review provides a checklist for auditing security patterns. This skill focuses on mapping and classifying the codebase itself — understanding what code exists, what's custom vs third-party, and where to focus security analysis.

Use Cases

• White-box penetration test preparation: understand the target codebase structure before deep analysis
• Open-source security audit: map the attack surface of a project before hunting vulnerabilities
• Third-party library inventory: identify embedded dependencies with known vulnerabilities
• M&A security due diligence: assess code quality and security of an acquired codebase
• Supply chain audit: verify what third-party code is actually running in the target

Core Tools

Methodology

Repo Scan Four-Phase Process

Phase 1: Surface Classification

Enumerate and tag every file:

# Count lines of code by language
cloc --by-file . --json

# Identify file types and structure
find . -type f | sed 's/.*\.//' | sort | uniq -c | sort -rn

# Detect third-party directories
find . -type d \( -name "vendor" -o -name "node_modules" -o -name "third_party" -o -name "external" -o -name "libs" -o -name "deps" \)

Classify each file as:

• Project code — written by the project authors
• Third-party code — embedded libraries, vendored dependencies
• Build artifacts — compiled output, generated files
• Configuration — settings, deployment files
• Test code — test fixtures, mock data

Phase 2: Library Detection

Identify embedded third-party libraries:

# Scan for known libraries and CVEs
trivy fs --scanners vuln .
grype dir:. --output json

# Check specific library versions
grep -r "version" vendor/*/package.json
grep -r "VERSION" libs/*/*.h

Phase 3: Security Hotspot Analysis

Focus review on high-value targets:

# Find authentication-related code
grep -rn "password\|auth\|token\|session\|login" --include="*.py" --include="*.js" --include="*.java" .

# Find database interaction
grep -rn "query\|execute\|cursor\|select\|insert\|update" --include="*.py" .

# Find file operations
grep -rn "open(\|readfile\|upload\|download\|include\(" --include="*.php" .

# Secret scanning
trufflehog filesystem . --json
gitleaks detect --source . --report-format json

Phase 4: Verdict and Report

Assign verdicts per module:

Cross-Stack Coverage

Defense Perspective

• Inventory everything: You can't secure what you don't know exists
• Pin dependencies: Lock exact versions to prevent supply chain attacks
• Remove dead code: Every line of code is a potential attack surface
• Separate concerns: Third-party code should be isolated from business logic
• Automate scanning: Integrate repo scanning into CI/CD pipelines

Report Template

# Repository Scan Report
*Target: [repo/project] | Date: [date] | Depth: [fast/standard/deep]*

## Executive Summary
[Total files, languages, third-party ratio, key findings]

## Classification Summary
| Category | Files | Lines of Code | Percentage |
|----------|-------|---------------|------------|
| Project Code | N | N | N% |
| Third-Party | N | N | N% |
| Build Artifacts | N | N | N% |

## Detected Libraries
| Library | Version | Known CVEs | Status |
|---------|---------|------------|--------|
| [Name] | [X.Y.Z] | [N CVEs] | [Outdated/Current] |

## Module Verdicts
| Module | Verdict | Rationale | Security Priority |
|--------|---------|-----------|-------------------|
| [Name] | Core Asset / Extract / Rebuild / Deprecate | [Why] | [High/Med/Low] |

## Security Hotspots
[High-priority files/directories for deep security review]

## Recommendations
[Prioritized action items based on verdicts and findings]

Detection Methods

Repository Activity Audit

• Mass cloning: Single token cloning many repos; suspicious pattern.
• Code search anomalies: api.github.com/search/code API abuse; rate limit violations.
• Commit frequency: New contributor with many commits to security-sensitive files.

SIEM Detection Rules

• Splunk SPL: index=github audit | stats count by actor, action | where action="git.clone" | sort -count
• GitHub Advanced Security: Secret scanning, CodeQL alerts in PRs.
• GitGuardian / GitPrey: Secret detection in repositories.

Defense Evasion Techniques

Stealth Cloning

• Slow & distributed: Pace cloning; below per-token rate limit.
• Multiple tokens: Use multiple credentials; spread across many sources.
• Mirror via CI: Use legitimate CI pipeline to mirror repos; appears as routine sync.

Code Search Stealth

• Use authenticated API: api.github.com/search/code over browser search (rate-limited but less suspicious).
• Local mirror: Clone repos locally; search offline.
• Fork + scan: Fork target repo privately; scan without revealing interest.

Orchestration

ECC Loop Pattern

• Pattern: Batch Processing (classify → detect → map → scan → verdict across multiple files/modules)
• Rationale: Repository scanning processes many files in batch — classification, dependency detection, and hotspot analysis all operate across the entire codebase simultaneously
• Integration: security-review (consumes repo-scan output for targeted review), terminal-ops (evidence capture), continuous-learning (pattern extraction from scan results)

Cross-Skill Pipeline

repo-scan → security-review → verification-loop → chronicle
    ↓                                                          ↑
search-first (find tools)                continuous-learning (persist patterns)

Quality Gate

• Pre-condition: Repository accessible, scanning tools installed
• Post-condition: All files classified, dependencies inventoried, hotspots mapped, verdicts assigned
• Verification: Third-party ratio calculated, secret scan completed, report generated