Recon, audit, detect: a defender's workflow with DeepSeek V4 and the Defense models

Security work often stalls on one step: you ask a model to help write a detection rule for an attack you saw in your own logs, and it refuses because the request mentions attack payloads. This guide walks through a full defensive loop in free-pi, from mapping your attack surface to shipping a fix and a detection rule, using DeepSeek V4 for normal work and a Defense model only when a refusal blocks legitimate work. We build free-pi, so read this with that in mind. Use it only on code and systems you own or are authorized to test.

The models and the skill

• DeepSeek V4 in Fusion mode. V4 Pro plans, V4 Flash builds. Pick it in /model; it covers most of the workflow.
• The Defense models. Free abliterated models, such as Abliterated Large Flash and DeepSeek V4.1 Flash Abliterated, listed in the Defense section of the /model picker. It is opt-in, requires a GitHub sign-in, and costs more than the default, so it uses your daily allowance faster. The picker shows how far each model stretches your allowance.
• /skill:freepi-security-audit. A bundled skill for structured review of your own code. See our guide on auditing your repo with the security-audit skill for a deeper walkthrough.

Step 1: map the attack surface

Start free-pi in your repository and ask for a map first:

map the attack surface of this repo: every route, handler, queue
consumer, cron job and CLI entry point that accepts outside input.
note auth, validation, and what each one touches. output a table.

Save the result as SECURITY-MAP.md. It is your work list for the rest of the guide.

Step 2: audit the risky paths

Run the skill on the entries that touch the shell, filesystem or auth:

/skill:freepi-security-audit focus on the upload handler and the admin
session middleware from SECURITY-MAP.md

Ask for a file, line, reachable input and reasoning for every finding, and verify each one yourself.

Step 3: write a detection rule

Suppose the audit found a path traversal in the upload handler and your access logs show someone probing it. Ask for a rule and test data:

write a Sigma rule that detects path traversal attempts against
/api/upload in our nginx access logs, plus 5 example log lines that
should match and 5 that should not.

A useful rule has to describe the payloads precisely, and that is where general models often decline. If that happens, open /model, choose a Defense model, and rerun the same prompt. Keep the session scoped to that task, then switch back. The same approach works for YARA rules on files found on your own servers and WAF rules for your own app.

Step 4: fix it and prove it

Back on DeepSeek V4:

fix the path traversal in the upload handler. add a regression test
that sends each malicious example from the Sigma test lines and
asserts it is rejected. run the tests.

Then load the rule into your log tooling and confirm it matches the bad examples and ignores the good ones. You end with a fix, a test that keeps it fixed, and a rule that alerts if someone tries again.

Ground rules

The Defense models are for lawful, defensive work: your own code and infrastructure, systems your employer has authorized you to test, and in-scope bug bounty targets. See our post on using the Defense section responsibly.

Try it

Run npx free-pi-cli@latest, type /model to find the Defense section, and start a review with /skill:freepi-security-audit. More at freepi.ai.

(I built it, so if a legit defensive prompt still gets stuck, let me know. Dennison)