Lesson 1: Ground Rules: Independence, Permission, Defence Only

Before you scan anything

Three ground rules come before any tooling, because they decide whether the rest of the course helps you or gets you into trouble. After them you'll build the small, deliberately vulnerable repository that every later lesson uses.

Rule 1: This course is independent, and the tools move

This course is independent of Anthropic. It is not written, reviewed or endorsed by them, and it reproduces none of their documentation text. Treat it like a colleague's notes on a tool: useful for judgement and workflow, never the authority on exact syntax.

That matters more than usual here, because almost everything we touch is pre-release:

• Claude Security plugin for Claude Code: in beta.
• Code Review on pull requests: a research preview, for Team and Enterprise plans.
• The managed Claude Security product: a public beta, Enterprise plan only.

Beta means commands, file names, plan availability and models can change between the day this was written and the day you read it. When this course and the official page disagree, the official page wins. Bookmark these:

Habit to build: before running a command from any tutorial (this one included), check it against the page above. It takes thirty seconds and saves you debugging a renamed flag.

Rule 2: Scan only code you are authorised to scan

A scanner that reasons about code produces a list of ways to break that code. Making that list about someone else's software, without permission, is a problem whatever your intentions were.

Anthropic's usage policy allows security work on systems you own or are authorised to test, and prohibits finding or exploiting vulnerabilities without authorisation. The managed product is stricter still: its help article limits you to code your organisation owns and has the rights to scan.

A quick decision guide:

"Authorised" also covers where the code goes. A scan sends source to a model, so your organisation's rules about which code may go to which provider still apply.

Write the answer down before you scan. A scope note keeps you honest and gives you something to show if anyone asks:

# SCOPE.md
Repository:    vuln-practice (local, created by me)
Owner:         me
Authorised by: me (owner)
In scope:      whole repository, all branches
Out of scope:  anything outside this directory
Tooling:       Claude Code session on my own account
Date:          2026-10-12

For real work, "Authorised by" is a named person or a ticket, and "In scope" is usually narrower: specific directories or one service.

Rule 3: Defence only

We use each vulnerability just far enough to prove it is real, with a minimal reproduction, and then we fix it. The course contains no weaponised exploits and no payload tuning, and we never point anything at systems we don't own. Treat findings as sensitive too: a report on a real codebase is a map for an attacker until the fixes ship.

Set up the practice repository

First confirm the three tools. The plugin's documentation asks for Python 3.9 or later on your PATH as python3, and for git for change scans and patches. It also needs a paid plan, API access or a supported third-party provider. I couldn't confirm a minimum Claude Code version on the official page, so check there.

claude --version    # Claude Code is installed and on PATH
git --version       # needed for change scans and patches
python3 --version   # must report 3.9 or later

Gotcha: on Windows, python may work while python3 doesn't. The plugin looks for python3 specifically, so fix that now. Run the commands below in Git Bash or WSL.

The repository is small enough to build yourself, so you know exactly what is in it. Create a seed, then clone it. The seed stays pristine, so you can always re-clone to reset.

mkdir vuln-practice-seed && cd vuln-practice-seed
git init -q && mkdir app

cat > app/users.py <<'EOF'
def find_user(db, name):
    # CWE-89: SQL built by string formatting
    return db.execute(f"SELECT id FROM users WHERE name = '{name}'").fetchall()
EOF

cat > app/ping.py <<'EOF'
import subprocess
def ping(host):
    # CWE-78: user input reaches a shell
    return subprocess.run("ping -c 1 " + host, shell=True)
EOF

cat > app/files.py <<'EOF'
def read_upload(filename):
    # CWE-22: no check that the path stays inside uploads/
    return open("uploads/" + filename).read()
EOF

cat > app/config.py <<'EOF'
# CWE-798: hardcoded credential (fake value)
API_KEY = "practice-key-not-real"
EOF

git add . && git commit -qm "Seed: deliberately vulnerable examples"

cd .. && git clone -q vuln-practice-seed vuln-practice && cd vuln-practice

Now list what you have:

grep -rn "CWE-" app/

app/config.py:1:# CWE-798: hardcoded credential (fake value)
app/files.py:2:    # CWE-22: no check that the path stays inside uploads/
app/ping.py:3:    # CWE-78: user input reaches a shell
app/users.py:2:    # CWE-89: SQL built by string formatting

That gives you four examples: SQL injection, OS command injection, path traversal and a hardcoded credential. The comments are a training aid. Real code doesn't label its bugs, and later we'll strip them to see what a reviewer finds unaided.

Never deploy this repo, and never put a real secret in it. The fake key is there to be found.

Finally, save the scope note from Rule 2 as SCOPE.md in vuln-practice and commit it. That is your first deliverable.

Key takeaways

• This course is independent of Anthropic. For commands, file names, plans and models, the official pages are the authority.
• The plugin is in beta, Code Review is a research preview and the managed product is an Enterprise-only public beta. Expect change and verify before you run anything.
• Neither public code nor code you can access is automatically code you may scan. Get authorisation and write the scope down.
• Defence only: a minimal reproduction, then the fix.
• Your practice repo has four labelled weaknesses (CWE-89, CWE-78, CWE-22, CWE-798) and a pristine seed to reset from.