MethodAtlas is a CLI tool that scans Java source trees for JUnit test methods and emits one structured record per discovered method — with optional AI-assisted security classification.
It is built for teams that must demonstrate test coverage of security properties to auditors, regulators, or security review boards: it separates deterministic source analysis from optional AI interpretation so that every result is traceable, repeatable, and defensible.
Security-focused teams in regulated industries need more than a passing test suite. They need to demonstrate which tests cover which security controls, at a level of detail that satisfies external review.
MethodAtlas addresses this by turning an existing JUnit 5 test suite into a structured inventory with minimal setup:
| Challenge | What MethodAtlas provides |
|---|---|
| "Show us your security test coverage" | AI-classified inventory with rationale per method |
| "Prove the tests haven't changed since last audit" | Per-class SHA-256 content fingerprints (-content-hash) |
| "Integrate this into our SAST pipeline" | Native SARIF 2.1.0 output, compatible with GitHub Advanced Security, VS Code, Azure DevOps, and SonarQube |
| "We can't send source code to external AI APIs" | Local inference via Ollama, or a two-phase manual AI workflow for air-gapped environments |
| "Classification must be consistent and auditable" | Closed, versioned security taxonomy with optional custom taxonomy aligned to your controls framework |
| "We need confidence scores, not just yes/no" | Per-method AI confidence scores (0.0–1.0) for threshold-based filtering and human-review queues |
| "Annotate the source files for us" | Apply-tags mode writes @DisplayName and @Tag annotations directly into source files |
- Deterministic test discovery — JavaParser AST analysis; no inference, no false positives on method existence
- SARIF 2.1.0 output — first-class integration with static analysis platforms and IDE tooling
- AI security classification — classifies each test method against a closed security taxonomy; supports Ollama, OpenAI, OpenRouter, and Anthropic
- Confidence scoring — per-method decimal score (
-ai-confidence); filter by threshold for audit packages - Content hash fingerprints — SHA-256 of the class AST text (
-content-hash); all methods in the same class share the same hash; enables incremental scanning and change detection - Apply-tags — writes AI-suggested
@DisplayNameand@Tagannotations back into source files; idempotent - Manual AI workflow — two-phase prepare/consume workflow for environments where API access is blocked
- Local inference — Ollama support keeps source code entirely within your network
- YAML configuration — share scan settings across a team or CI pipeline without repeating CLI flags
- Custom taxonomy — supply an external taxonomy file aligned to ISO 27001, NIST SP 800-53, PCI DSS, or your own controls framework
- Multiple output modes — CSV (default), plain text, and SARIF
Build and unpack the distribution archive, then:
cd methodatlas-<version>/bin
# Static scan — outputs fqcn, method, loc, tags
./methodatlas /path/to/project
# AI security classification (local Ollama)
./methodatlas -ai /path/to/project
# SARIF output — pipe to a file for upload to GitHub Advanced Security
./methodatlas -sarif /path/to/project > results.sarif
# SARIF + AI enrichment + content hash fingerprints
./methodatlas -ai -sarif -content-hash /path/to/project > results.sarif
# Apply AI-suggested annotations back into source files
./methodatlas -ai -apply-tags /path/to/testsSee docs/cli-reference.md for the complete option reference.
For each discovered JUnit test method, MethodAtlas emits one record.
Source-derived fields (always present, no AI required):
| Field | Description |
|---|---|
fqcn |
Fully qualified class name |
method |
Test method name |
loc |
Inclusive line count of the method declaration |
tags |
Existing JUnit @Tag values declared on the method |
content_hash |
SHA-256 fingerprint of the enclosing class (opt-in via -content-hash) |
AI enrichment fields (present when -ai is enabled):
| Field | Description |
|---|---|
ai_security_relevant |
Whether the model classified the test as security-relevant |
ai_display_name |
Suggested security-oriented @DisplayName value |
ai_tags |
Suggested security taxonomy tags (e.g. security;auth, security;crypto) |
ai_reason |
Short rationale for the classification |
ai_confidence |
Model confidence score 0.0–1.0 (opt-in via -ai-confidence) |
fqcn,method,loc,tags,ai_security_relevant,ai_display_name,ai_tags,ai_reason
com.acme.auth.LoginTest,testLoginWithValidCredentials,12,,true,SECURITY: auth - validates session token,security;auth,Verifies session token is issued on successful login.
com.acme.util.DateTest,format_returnsIso8601,5,,false,,,Tests date formatting only../methodatlas -ai -sarif /path/to/tests > results.sarifProduces a single valid SARIF 2.1.0 JSON document. Security-relevant methods receive SARIF level note; all other test methods receive level none. Rule IDs are derived from AI taxonomy tags (security/auth, security/crypto, etc.).
SARIF is natively consumed by:
- GitHub Advanced Security — upload via the
upload-sarifaction to surface findings in the Security tab - VS Code — SARIF Viewer extension renders results inline
- Azure DevOps — SARIF viewer pipeline extension
- SonarQube — import via the generic issue import format after conversion
./methodatlas -plain /path/to/projectHuman-readable line-oriented output, useful for terminal inspection and shell scripting.
See docs/output-formats.md for full format descriptions and examples.
SARIF is the OASIS standard interchange format for static analysis results. Adopting it means that MethodAtlas findings can be imported into any SARIF-compatible platform without custom tooling, and the format itself provides a stable, auditable record.
A SARIF result from MethodAtlas includes:
- Physical location — source file path relative to
%SRCROOT%and the method's start line - Logical location — fully qualified method name (
com.acme.auth.LoginTest.testLoginWithValidCredentials) with kindmember - Properties bag —
loc, optionalcontentHash, and all AI enrichment fields
This makes each SARIF finding independently traceable to a specific method in a specific class at a specific revision.
When -ai is enabled, MethodAtlas submits each parsed test class to a configured AI provider for security classification. The model receives:
- The closed security taxonomy — a controlled set of tags that constrains what the model can return
- The exact list of JUnit methods discovered by the parser — the model cannot invent or skip methods
- The full class source as context for semantic interpretation
Because discovery is AST-based and AI classification is constrained by a fixed tag set, the structural inventory is deterministic even when the semantic interpretation uses a language model.
| Provider | Value | Deployment |
|---|---|---|
| Ollama | ollama |
Local; source code stays on-premises |
| Auto | auto |
Tries Ollama first; falls back to API-key provider |
| OpenAI | openai |
Cloud |
| OpenRouter | openrouter |
Cloud (access to many models) |
| Anthropic | anthropic |
Cloud |
Pass -ai-confidence to add a 0.0–1.0 confidence score per method:
./methodatlas -ai -ai-confidence /path/to/tests | \
awk -F',' 'NR==1 || ($9+0) >= 0.7' # keep only high-confidence findings| Score | Meaning |
|---|---|
1.0 |
Explicitly and unambiguously tests a named security property |
~0.7 |
Clearly tests a security-adjacent concern |
~0.5 |
Plausible but ambiguous; candidate for manual review |
0.0 |
Not security-relevant |
See docs/ai-guide.md for the full interpretation guide.
Pass -content-hash to append a SHA-256 fingerprint of each class to every emitted record:
./methodatlas -content-hash -sarif /path/to/tests > results.sarifThe hash is computed from the JavaParser AST text of the enclosing class. All methods in the same class share the same value, and the hash changes only when the class body changes — not when unrelated files are modified.
Practical applications:
- Incremental scanning — skip classes whose hash has not changed since the last run
- Audit traceability — correlate a SARIF finding back to the exact class revision that produced it
- CI change detection — detect modified test classes between two pipeline stages without diffing source files
For environments where direct AI API access is blocked by corporate policy, MethodAtlas supports a two-phase manual workflow:
# Phase 1 — write prompts to files
./methodatlas -manual-prepare ./work ./responses /path/to/tests
# (paste each work file's AI prompt into a chat window, save the response)
# Phase 2 — consume responses and emit the enriched CSV (or apply tags)
./methodatlas -manual-consume ./work ./responses /path/to/tests
./methodatlas -manual-consume ./work ./responses -apply-tags /path/to/testsAll taxonomy and confidence flags apply equally in manual mode. The consume phase is incremental — you can process classes as responses arrive rather than waiting for the full batch.
See docs/ai-guide.md for the complete workflow.
Store shared settings in a YAML file so that CI pipelines and team members use consistent options without repeating flags:
outputMode: sarif
contentHash: true
ai:
enabled: true
provider: ollama
model: qwen2.5-coder:7b
confidence: true
taxonomyMode: optimized./methodatlas -config ./methodatlas.yaml /path/to/testsCommand-line flags always override YAML values. See docs/cli-reference.md for the complete field reference.
methodatlas-<version>/
├── bin/
│ ├── methodatlas
│ └── methodatlas.bat
└── lib/
├── methodatlas-<version>.jar
└── *.jar (runtime dependency libraries)
The startup scripts in bin/ configure the classpath automatically to include all JARs in lib/, so no manual setup is required after extraction.
| Document | Contents |
|---|---|
| docs/cli-reference.md | Complete option reference, YAML schema, and example commands |
| docs/output-formats.md | CSV, plain text, and SARIF output format descriptions |
| docs/ai-guide.md | AI providers, confidence scoring, taxonomy, apply-tags workflow, manual workflow |
