25-security-scanning-vulnerability-research

name	25-security-scanning-vulnerability-research
description	Understand how AI-powered security scanning works, from Anthropic Mythos to practical vulnerability triage and remediation workflows.

- Security Scanning & Vulnerability Research

Estimated time: 20 minutes Prerequisites: Module 01 (Claude Code installed and working), Module 24 recommended (Security-First Development)

Understand how AI-powered security scanning works, from Anthropic Mythos to practical vulnerability triage and remediation workflows.

Orientation

Print this once at the start:

You're learning AI-powered security scanning and vulnerability research.
This takes about 20 minutes.

We'll cover:
  1. Anthropic Mythos and Project Glasswing — the frontier security model
  2. Claude Security scanning — multi-stage verification
  3. Scoping scans — targeting directories and components
  4. Triaging findings — severity, false positives, prioritization
  5. Integration with team workflows — Jira, Slack, export
  6. SAST vs LLM audit — strengths, limits, responsible disclosure

You'll need:
  - Claude Code installed and working (Module 01)
  - A Git repository to scan (any project directory)
  - Jira MCP configured (for the challenge — optional for the walkthrough)

Quick Setup

If you've completed Module 01, you have everything needed for Steps 1-4. The challenge at the end requires Jira MCP (Module 05).

External Dependencies

This module references services and features at various availability levels:

• Claude Security (web) — limited research preview for Enterprise/Team customers. The web-based codebase scanning interface at claude.ai is not generally available. If you have access, you can follow the full experience. If not, the conceptual walkthrough still covers how it works.
• /security-review CLI command — available to all Claude Code users. This is the primary hands-on tool in this module.
• Jira MCP — needed for the challenge (creating tickets for findings). See Module 05 if not configured.

# Check Claude Security web access
if curl -sf "https://claude.ai" --max-time 5 &>/dev/null; then
  echo "EXISTS: claude.ai reachable"
  echo ""
  echo "  Claude Security web scanning is available to Enterprise/Team"
  echo "  customers with the research preview enabled."
  echo "  If you have access, you can explore it alongside this module."
else
  echo "INFO: claude.ai not reachable or not accessible"
fi

echo ""
echo "Two options:"
echo ""
echo "  FULL EXPERIENCE (recommended):"
echo "    /security-review is available in every Claude Code session."
echo "    Claude Security web access adds codebase-scale scanning"
echo "    but is not required for this module."
echo ""
echo "  CONCEPTUAL OVERVIEW:"
echo "    If /security-review is somehow unavailable, you'll learn"
echo "    all the concepts but won't run a live scan."

If Claude Security web access is not available, note which path the user is on but proceed -- the /security-review CLI is the primary tool in this module and is always available.

Progress Tracking

On module start, write a progress marker:

mkdir -p ~/.claude/courseware-progress && date -u +%Y-%m-%dT%H:%M:%SZ > ~/.claude/courseware-progress/25.started

Preflight

Audit current state before doing anything. Each check prints EXISTS or MISSING.

# Check 1 — Claude Code installed?
command -v claude &>/dev/null && echo "EXISTS: Claude Code" || echo "MISSING: Claude Code — run /learn-01-vertex-setup first"

# Check 2 — /security-review available (built-in command)
echo "EXISTS: /security-review is a built-in Claude Code command (always available)"

# Check 3 — Jira MCP configured (for challenge)?
if [ -f "$HOME/.claude/settings.json" ]; then
  python3 -c "
import json, os
d = json.load(open(os.path.expanduser('~/.claude/settings.json')))
servers = d.get('mcpServers', {})
found = False
for name in servers:
    if 'jira' in name.lower() or 'atlassian' in name.lower():
        found = True
        break
if found:
    print('EXISTS: Jira/Atlassian MCP configured')
else:
    print('MISSING: Jira MCP — needed for the challenge. Run /learn-05-atlassian-mcp to set up.')
" 2>/dev/null
elif [ -f ".mcp.json" ]; then
  python3 -c "
import json
d = json.load(open('.mcp.json'))
servers = d.get('mcpServers', {})
found = False
for name in servers:
    if 'jira' in name.lower() or 'atlassian' in name.lower():
        found = True
        break
if found:
    print('EXISTS: Jira/Atlassian MCP configured (project-level)')
else:
    print('MISSING: Jira MCP — needed for the challenge. Run /learn-05-atlassian-mcp to set up.')
" 2>/dev/null
else
  echo "MISSING: Jira MCP — needed for the challenge. Run /learn-05-atlassian-mcp to set up."
fi

# Check 4 — Git repo available for scanning?
if git rev-parse --is-inside-work-tree &>/dev/null; then
  REPO_ROOT=$(git rev-parse --show-toplevel 2>/dev/null)
  FILE_COUNT=$(find "$REPO_ROOT" -maxdepth 3 -type f \( -name "*.py" -o -name "*.js" -o -name "*.ts" -o -name "*.go" -o -name "*.java" -o -name "*.rb" -o -name "*.rs" -o -name "*.c" -o -name "*.cpp" -o -name "*.sh" \) 2>/dev/null | wc -l | tr -d ' ')
  echo "EXISTS: Git repo at $REPO_ROOT ($FILE_COUNT scannable source files)"
else
  echo "MISSING: Not inside a Git repository — cd into a project before scanning"
fi

Print a summary of what was found. If Claude Code is MISSING, stop and direct to Module 01. If Jira MCP is MISSING, note that the challenge will need it but continue with the walkthrough.

Step 1 -- Anthropic Mythos and Project Glasswing

This step is conceptual -- no tools to run. The context here frames why AI security scanning matters.

Tell the user:

Before we run any scans, let's understand what's behind them.

Anthropic built a frontier model called Mythos specifically for
security research. Unlike general-purpose Claude, Mythos was trained
to find vulnerabilities, understand exploit chains, and verify that
findings are real -- not just pattern-matched noise.

The numbers tell the story:

  23,000+ issues found across 1,000+ open source projects
  6,202   high-severity or critical-severity findings
  90%+    validated as true positives (not false alarms)

Notable discoveries:
  - A 27-year-old vulnerability in OpenBSD
  - A certificate forgery exploit in wolfSSL
  - Issues in codebases that had been audited by humans multiple times

What makes Mythos different from a SAST scanner is depth. It doesn't
just match regex patterns against known vulnerability signatures.
It reads the code, reasons about data flow, understands what an
attacker could do with a weakness, and then attempts to verify
its own findings before reporting them.

Mythos can find AND exploit vulnerabilities -- Anthropic reports
an 83% first-attempt success rate when generating working exploits
for confirmed findings. This is what makes the model both powerful
and why responsible disclosure matters.

Then explain Project Glasswing:

Project Glasswing is Anthropic's initiative to apply Mythos at scale
across critical open source infrastructure. Partners include:

  AWS, Apple, Cisco, Google, Microsoft, Linux Foundation,
  and other major organizations

Together they've committed $100M+ in model usage credits to scan
the open source software that powers most of the internet.

Why this matters for your daily work:

  1. The /security-review command uses the same underlying approach
     (multi-stage verification, semantic code understanding)
  2. Findings from Glasswing improve the models you use every day
  3. The triage patterns we'll learn apply whether the scanner
     is Mythos, Claude, or a traditional SAST tool

Step 2 -- Claude Security Scanning

Tell the user:

Claude Security scanning uses a multi-stage verification approach.
Instead of a single pass through the code, it works like this:

  Stage 1: Initial scan
    The model reads the code and identifies potential issues.
    At this stage, findings include both real problems and
    false positives.

  Stage 2: Self-challenge
    The model challenges its own conclusions. For each finding,
    it asks: "Is this actually exploitable? Under what conditions?
    Could this be a false positive?" This dramatically reduces
    noise compared to traditional scanners.

  Stage 3: Verification
    For remaining findings, the model attempts to construct a
    proof of concept or exploitation path. If it can't demonstrate
    the issue is real, it downgrades or drops the finding.

Each finding that survives all three stages includes:
  - Confidence score (how certain the model is)
  - Severity level (Critical / High / Medium / Low)
  - Impact description (what could go wrong)
  - Reproduction steps (how to trigger the issue)
  - Suggested patch (how to fix it)

Demonstrate by running /security-review on the current directory. Explain to the user what you're about to do:

Let's run a security review on the current project directory.
The /security-review command analyzes the codebase and reports
findings with severity, confidence, and remediation guidance.

Run the security review. After results come back, walk through each finding (if any) and explain:

For each finding, note:
  - The file and location
  - The severity and confidence score
  - Whether the finding includes reproduction steps
  - The suggested fix

If the scan returns no findings, that's a valid result too --
it means the scanned code doesn't have issues the model can
identify with high confidence.

Step 3 -- Scoping Scans

Tell the user:

Full-project scans are useful but not always what you need.
You can scope security reviews to specific areas:

  By directory:
    Review only the API layer, only the auth module, or only
    recently changed files. This is faster and more focused.

  By concern:
    Ask for a review focused on a specific vulnerability class:
    "Review this directory for SQL injection vulnerabilities"
    "Check the authentication flow for session management issues"
    "Look for hardcoded secrets or credential exposure"

  By change set:
    Review only the files changed in a recent commit or PR.
    This is the most common workflow in daily development.

Explain how to scope a review:

When you run /security-review, you can provide context about
what to focus on. The model uses this to prioritize its analysis.

Common scoping patterns:

  Scan a subdirectory:
    "Run /security-review on the src/auth/ directory"

  Scan recent changes:
    "Run /security-review on files changed in the last commit"

  Scan for a specific class of vulnerability:
    "Run /security-review looking specifically for
     injection vulnerabilities and input validation issues"

  Scan with business context:
    "This is a public-facing API that handles payment data.
     Run /security-review with that context."

The more context you provide, the better the model can
prioritize and focus its analysis.

Step 4 -- Triaging Findings

Tell the user:

Not every finding requires immediate action. Triage is the process
of assessing each finding and deciding what to do with it.

Severity levels:

  CRITICAL — Actively exploitable, high impact, fix immediately
    Examples: remote code execution, authentication bypass,
    SQL injection in a public endpoint

  HIGH — Exploitable with some prerequisites, significant impact
    Examples: stored XSS, privilege escalation, insecure
    deserialization with attacker-controlled input

  MEDIUM — Requires specific conditions to exploit, moderate impact
    Examples: CSRF without sensitive actions, information
    disclosure of non-sensitive data, missing rate limiting

  LOW — Theoretical risk, minimal impact, or defense-in-depth
    Examples: verbose error messages, missing security headers
    on non-sensitive endpoints, outdated but unexploitable deps

Triage decisions:

  FIX NOW      — Critical and High severity, confirmed real
  SCHEDULE     — Medium severity, add to sprint backlog
  ACCEPT RISK  — Low severity, document and move on
  FALSE POSITIVE — Mark as not applicable, document why

Walk through how to evaluate a finding:

For each finding, ask these questions in order:

  1. Is this real?
     Does the code actually do what the finding claims?
     Check the specific lines cited. Sometimes the model
     misreads the control flow or misses a guard clause.

  2. Is this exploitable?
     Even if the code has a weakness, can an attacker
     reach it? Is the vulnerable path behind authentication?
     Is the input sanitized upstream?

  3. What's the blast radius?
     If exploited, what's the worst case? Data loss?
     Service disruption? Credential exposure? The answer
     determines whether this is Critical or Medium.

  4. How hard is the fix?
     A one-line fix for a Critical finding should be
     deployed today. A complex refactor for a Low finding
     goes in the backlog.

Step 5 -- Integration with Team Workflows

Tell the user:

Findings are only useful if they reach the right people
and get tracked to resolution. Here's how to integrate
security scanning into your team workflow.

Jira Integration

For actionable findings, create Jira tickets with:

  Summary:  [Security] <vulnerability type> in <component>
  Priority: Maps to severity (Critical->Highest, High->High, etc.)
  Description:
    - What was found (the vulnerability)
    - Where it is (file, line, function)
    - Impact (what could go wrong)
    - Reproduction steps
    - Suggested fix
    - Scan date and tool used

Using the Jira MCP (Module 05), you can create these tickets
directly from Claude Code without switching to a browser.

If Jira MCP is configured, demonstrate creating a sample ticket (do not actually create one during the walkthrough -- save that for the challenge):

Example Jira ticket creation via MCP:

  Project:     RHDPOPS
  Issue type:  Task (or Bug if your project has a security type)
  Summary:     [Security] Potential path traversal in file upload handler
  Priority:    High
  Description: Full finding details including reproduction steps
  Labels:      security, scan-finding

We'll create a real ticket in the challenge.

Export Formats

For reporting and audit trails, findings can be exported as:

  Markdown — paste into a PR description or Confluence page
  CSV      — import into a spreadsheet for tracking
  Jira     — create tickets directly via MCP (as shown above)

The /security-review output is already formatted for readability.
Copy it into your team's preferred tracking system.

Notification Patterns

Common integration points for security findings:

  PR reviews:
    Run /security-review on changed files before merge.
    Include findings in the PR description.

  Sprint planning:
    Export Medium/Low findings as backlog items.
    Schedule based on risk and fix complexity.

  Incident response:
    Critical findings get immediate Jira tickets,
    Slack notification to the security channel,
    and a fix PR within 24 hours.

Step 6 -- SAST vs LLM Audit

Tell the user:

Traditional SAST (Static Application Security Testing) and
LLM-based security audits serve different purposes. Neither
replaces the other.

SAST tools (Semgrep, Snyk, CodeQL, Bandit):
  Strengths:
    - Deterministic: same code always produces same findings
    - Fast: can scan millions of lines in seconds
    - Low false-positive rate for known vulnerability patterns
    - Integrates into CI/CD pipelines natively
    - Established CVE databases and rule libraries

  Weaknesses:
    - Only finds what it has rules for
    - Misses novel vulnerability classes
    - Struggles with complex data flow across files
    - Cannot reason about business logic flaws

LLM audit (Claude Security, /security-review):
  Strengths:
    - Finds novel vulnerabilities (no predefined rules needed)
    - Understands semantic meaning and business logic
    - Can reason about multi-step exploit chains
    - Generates reproduction steps and fix suggestions
    - Adapts to unfamiliar codebases and languages

  Weaknesses:
    - Non-deterministic: may find different things on repeat scans
    - Slower than rule-based scanners
    - Cannot yet understand cross-service trust boundaries well
    - Higher compute cost per scan
    - May hallucinate findings (the multi-stage verification
      mitigates this, but doesn't eliminate it entirely)

Best practice: use both.
  - SAST in CI/CD for every commit (fast, deterministic baseline)
  - LLM audit for periodic deep reviews and pre-release checks
  - LLM audit for new codebases where SAST rules may not cover
    the technology stack

Responsible Disclosure and CVE Process

If you find a vulnerability in open source software:

  1. Do NOT disclose publicly before notifying the maintainer
  2. Check the project's SECURITY.md or security policy
  3. Report through the project's preferred channel
     (usually [e-mail] or a GitHub security advisory)
  4. Allow reasonable time for a fix (typically 90 days)
  5. If a CVE is warranted, the maintainer or a CNA files it

For internal projects:
  1. Create a Jira ticket with restricted visibility
  2. Notify the team lead and security contact
  3. Fix in a private branch, merge after verification
  4. Document the finding and fix for future reference

The AI model that found the vulnerability does not get credit
for the CVE — you do, as the researcher who validated and
reported it.

Verification

Run all preflight checks again as PASS/FAIL:

PASS=0
TOTAL=3

# Check 1 — Claude Code
command -v claude &>/dev/null && { echo "PASS: Claude Code installed"; PASS=$((PASS+1)); } || echo "FAIL: Claude Code"

# Check 2 — /security-review available
echo "PASS: /security-review is a built-in command"; PASS=$((PASS+1))

# Check 3 — Git repo available
git rev-parse --is-inside-work-tree &>/dev/null && { echo "PASS: Inside a Git repository"; PASS=$((PASS+1)); } || echo "FAIL: Not inside a Git repository"

echo ""
echo "$PASS/$TOTAL checks passed."

If all pass, print:

All checks passed.

You now understand:
  - How Anthropic Mythos and Project Glasswing work
  - Multi-stage verification in Claude Security scanning
  - How to scope scans to specific directories or concerns
  - Triage workflows for severity assessment
  - Integration patterns for Jira, export, and notifications
  - The complementary roles of SAST and LLM audits

If any fail, tell the user which step to revisit.

Challenge

Use /security-review to scan a project directory for vulnerabilities.

Steps:
  1. Pick a project directory (the current repo, or cd to another one)
  2. Run /security-review on that directory
  3. Triage the findings by severity (Critical/High/Medium/Low)
  4. Create a Jira ticket using Jira MCP on the RHDPOPS project:
     - If actionable findings exist: create a ticket for the
       highest-severity finding with full details
     - If no findings: create a ticket documenting the clean
       scan result (project scanned, date, files covered)

Tell me:
  1. What project was scanned
  2. How many findings were reported
  3. Severity breakdown (Critical/High/Medium/Low)
  4. The Jira ticket key you created (e.g., RHDPOPS-XXX)

Challenge Verification

To verify, check that the Jira ticket was created properly using the Jira MCP:

1. Retrieve the ticket the user created using mcp__mcp-atlassian-prod__getJiraIssue with the ticket key and cloudId: 2b9e35e3-6bd3-4cec-b838-f4249ee02432
2. Verify the ticket contains:
   • A summary that references a security finding or clean scan
   • A description with scan details (project, date, finding or clean result)
   • Appropriate severity/priority mapping
3. Confirm the scan results the user reported are consistent (finding count and severity breakdown)

If the Jira ticket exists and contains reasonable security scan details, write the completion marker:

date -u +%Y-%m-%dT%H:%M:%SZ > ~/.claude/courseware-progress/25.done

Then print:

Module 25 complete.

You can now:
  - Run AI-powered security scans with /security-review
  - Scope scans to specific directories, concerns, or change sets
  - Triage findings using the Critical/High/Medium/Low framework
  - Create Jira tickets for actionable vulnerabilities
  - Explain the difference between SAST and LLM-based audits
  - Follow responsible disclosure practices

Key takeaways:
  - Use SAST in CI/CD for every commit (fast, deterministic)
  - Use /security-review for deep periodic audits and new codebases
  - Multi-stage verification reduces false positives significantly
  - Always verify findings before escalating — check the code yourself
  - Responsible disclosure protects users and the open source ecosystem

Next module: /learn-26-claude-agent-sdk

Questions or feedback? https://github.com/rhpds/claude-code-courseware/issues