Audit Your Code With a Coding Agent

Use Cloudflare's audit skill to find, verify, and fix a code vulnerability.

Introduction

30 Second Summary

A small app can work perfectly on the surface. A hidden weakness may still be sitting inside it.

In this project, you will use Cloudflare's open-source security audit skill with a coding agent to inspect a small repo you own. After fixing one confirmed issue, you will rerun the audit to prove that finding has disappeared.

What You'll Build

When your audit finishes, you can show a before-and-after report where one confirmed security finding disappears after your fix.

By the end of this project, you'll have:

A reproducible audit trail that pairs the code map in architecture.md with a coverage ledger of every checked area.
Structured findings in findings.json that you can sort into confirmed, rejected, or still needing validation.
A before-and-after security report in REPORT.md that proves one confirmed finding disappeared after your fix.
Secret Mission: An optional challenge to push your skills further.

Are there any prerequisites?

You need Node.js plus a coding agent whose model supports tool use and parallel sub-agents. Your model provider may charge for the audit run.

Before We Start

The audit skill starts from your terminal. Node.js supplies the npx command that installs it.

The audit runs inside a coding agent. Its model needs tool use plus parallel sub-agents.

You also need access to your model provider's usage page. That page gives you a baseline for the audit's eventual cost.

In this step, get ready to:

Verify the Node.js toolchain from your terminal.
Confirm your coding agent can run the audit.
Record your model usage baseline.

Check your command-line tools

Your terminal is where you run the skill installer later. A version number confirms that each required command is available.

macOS

Press Command-Space bar to open Spotlight.
Type Terminal into the search field.
Press Return to open Terminal.

Windows

Press Windows key+S to open search.
Type PowerShell into the search field.
Press Enter to open PowerShell.

Display both installed versions by running these commands:

node --version
npx --version

What do these checks prove?

The node --version command confirms that the Node.js runtime is available.
The npx --version command confirms that the package runner is available.

Compare your terminal with the outcomes below.

✔️ I see two version numbers

Your command-line toolchain is ready. You can use npx to install the audit skill in a later step.

ⓧ A command is missing

Install the LTS release of Node.js. Its installer supplies the Node.js runtime plus npm.

Open the official Node.js download page in your browser.
Download the LTS installer for your operating system.
Run the downloaded installer.
Accept the installer's default options.
Close your terminal after the installation finishes.
Reopen your terminal using the instructions above.
Run the two version checks again.

Still missing a command?

Close every terminal window after installing Node.js. A fresh terminal reloads the command locations on your PATH.

If a command is still unavailable, help me troubleshoot my Node.js installation.

Prepare your coding agent

The agent needs permission to inspect files plus the ability to use tools. Its model also needs support for parallel sub-agents.

Start your coding agent using its official launch method.
Check the signed-in state shown by the agent.
Choose the matching outcome below.

✔️ My agent is signed in

Confirm that the agent displays a prompt area for a new request.
Confirm through the agent's official model documentation that your selected model supports tool use.
Confirm through the same documentation that your selected model supports parallel sub-agents.

Your agent is signed in and ready to work against a repository. Leave the prompt area empty for now.

ⓧ My agent is signed out

Open the account area in your coding agent.
Start the agent's official sign-in flow.
Complete the authentication request in your browser.
Return to your coding agent.
Confirm that the agent now shows your signed-in account.
Confirm through the official model documentation that your selected model supports tool use plus parallel sub-agents.

ⓧ I need a coding agent

Review the official documentation for a coding agent available to you.
Confirm that its model supports tool use plus parallel sub-agents.
Install the coding agent from its official source.
Start the coding agent using its official launch method.
Complete the agent's sign-in flow.
Confirm that the agent displays a prompt area for a new request.

Agent sign-in not working?

Check that your browser completed the authentication request. Return to the agent after the browser confirms access.

If the signed-in state still does not update, help me troubleshoot my coding agent sign-in.

Record your usage baseline

Billing screens can feel high-stakes. This check only reads your current usage.

Before you check, do you expect the page to show no usage or activity from earlier work?

Open your model provider's official account portal in your browser.
Sign in with the account connected to your coding agent.
Open the provider page that displays model usage or billing activity.
Record the current value here: your current model usage total.
Bookmark the usage page for the audit comparison later.

You should see a current usage value or another provider-specific activity measure. That visible baseline confirms that you can track the audit's model consumption.

Where can costs come from?

Cloudflare's security audit skill is free under the MIT license. The model calls follow your provider's pricing.

The skill distributes audit work across sub-agents. Your saved usage page lets you compare activity after the run.

Cannot find a usage total?

Some providers report credits or tokens instead of currency. Record the current measure that your provider exposes.

If the account portal does not show any activity page, help me locate model usage for my provider.

Your readiness check

Your terminal shows one Node.js version plus one npx version.
Your coding agent shows a signed-in account plus an available prompt area.
Your provider page shows the baseline you recorded above.

Your terminal, coding agent, and usage tracking are ready. Next up, you will choose a small repository that gives the audit a focused target.

Create a Test Repository

Security audits are easier to judge when you already know one real flaw exists. A known SQL injection weakness gives the later audit a clear target.

You will create a local Git repository called security-audit-demo. Inside it, you will build a small SQLite app that concatenates user input into a query.

In this step, get ready to:

Create the local Git repository.
Build a runnable app with a deliberate SQL injection flaw.
Confirm the sample behaves as expected.

Prepare the Git repository

A Git repository gives the audit a bounded codebase to inspect. It also prepares the project for the verified fix you will commit later.

Return to the terminal from earlier.
Check whether Git is available by running this command:

git --version

What does this command do?

This command asks Git to print its installed version. A version in the output confirms that the Git command is ready.

Choose the result that matches your terminal.

✔️ I see a Git version

Git is ready to create your repository.

ⓧ Command not found

Git needs to be installed before the repository can be created. Use the tab for your operating system.

macOS

Start the Xcode Command Line Tools installer by running this command:

xcode-select --install

What does this command do?

This opens the macOS installer for the command-line tools that include Git.

Complete the installation dialog.
Restart the terminal from earlier.
Confirm Git is now available by running:

git --version

What should I see?

You should see a Git version in the terminal.

Windows

Open the official Git for Windows installer in your browser.
Download the installer for your computer.
Run the downloaded installer.
Keep the recommended installation options.
Restart the terminal from earlier.
Confirm Git is now available by running:

git --version

What should I see?

You should see a Git version in the terminal.

Linux

Open the official Git installation guide for Linux in your browser.
Run the installation command listed for your Linux distribution.
Return to the terminal from earlier.
Confirm Git is now available by running:

git --version

What should I see?

You should see a Git version in the terminal.

Git still unavailable?

Restart your computer if the installer completed but the command remains unavailable. This refreshes the terminal environment.

Still stuck? Help me troubleshoot why Git is unavailable after installation.

Move to your Desktop by running this command:

cd ~/Desktop

Where does this command take you?

This makes your Desktop the location for the new project folder. You will be able to find the repository without searching your computer.

Create the security-audit-demo repository by running these commands:

git init security-audit-demo
cd security-audit-demo

What do these commands do?

The first command creates security-audit-demo with Git repository metadata.
The second command moves your terminal into the new folder.

You should see a message confirming that Git initialized the repository. Your terminal now points to the security-audit-demo folder.

Confirm the repository state by running:

git status

What should I see?

Git should report a repository with no commits. The folder is ready for your sample application.

Use your coding agent repository picker to select the security-audit-demo folder on your Desktop.
Approve access if your coding agent asks for folder confirmation.

Your coding agent should now show security-audit-demo as its active repository.

Build the vulnerable sample app

The app uses an in-memory user table so every run starts from the same data. Its search query deliberately joins user-controlled text directly onto an SQL string.

Create app.py inside security-audit-demo by pasting the following code into your coding agent's file editor:

import sqlite3
import sys

def find_user(name):
    # Build an in-memory data set for a repeatable demo
    connection = sqlite3.connect(":memory:")
    cursor = connection.cursor()
    cursor.execute("CREATE TABLE users (id INTEGER, name TEXT, role TEXT)")
    cursor.executemany(
        "INSERT INTO users VALUES (?, ?, ?)",
        [
            (1, "Alice", "admin"),
            (2, "Bob", "viewer"),
        ],
    )

    # Deliberately concatenate user input for the audit exercise
    query = "SELECT id, name, role FROM users WHERE name = '" + name + "'"
    print(f"Running query: {query}")
    rows = cursor.execute(query).fetchall()
    connection.close()
    return rows

if __name__ == "__main__":
    # Read the search value from the command line
    search_name = sys.argv[1] if len(sys.argv) > 1 else "Alice"
    print(find_user(search_name))

What does this code do?

The in-memory database stores two sample users for each run.
The command-line argument becomes the user-controlled search value.
The query variable concatenates that value directly into SQL. This is the deliberate security flaw.
The final lines execute the query before printing matching rows.

Save app.py.

Before you run the app, do you expect the search for Alice to return a matching record?

Switch back to the terminal from earlier.
Run the app with the command for your operating system:

macOS

python3 app.py Alice

What should I see?

You should see the generated query followed by Alice's user record.

Windows

python app.py Alice

What should I see?

You should see the generated query followed by Alice's user record.

Linux

python3 app.py Alice

What should I see?

You should see the generated query followed by Alice's user record.

That is your first working result. The app prints Alice's record from its in-memory table.

App did not run?

Check that your terminal is inside the security-audit-demo folder.
Check that the filename is exactly app.py.
Try the command from another operating-system tab if your computer uses a different Python command.

Still stuck? Help me debug why app.py does not run or return Alice's record.

Document and verify the sample

The repository needs a short run guide so the starting behavior is reproducible. The guide also records that the unsafe query exists for this audit exercise.

Create README.md inside security-audit-demo by pasting the following content into your coding agent's file editor:

# Security Audit Demo

This sample app searches an in-memory SQLite user table.

## Run

On macOS or Linux:

```bash
python3 app.py Alice
```

On Windows:

```powershell
python app.py Alice
```

You should see Alice's user record in the output.

The query deliberately concatenates user input for this audit exercise.

What does this file record?

The run instructions give you a repeatable baseline for the audit. The final sentence documents why this repository contains unsafe code.

Save README.md.

✔️ Awesome, I've got everything!

Great. Double check that app.py and README.md are saved inside security-audit-demo.

ⓧ I'd like to double check the full code

Compare your complete app.py with this reference.

import sqlite3
import sys

def find_user(name):
    # Build an in-memory data set for a repeatable demo
    connection = sqlite3.connect(":memory:")
    cursor = connection.cursor()
    cursor.execute("CREATE TABLE users (id INTEGER, name TEXT, role TEXT)")
    cursor.executemany(
        "INSERT INTO users VALUES (?, ?, ?)",
        [
            (1, "Alice", "admin"),
            (2, "Bob", "viewer"),
        ],
    )

    # Deliberately concatenate user input for the audit exercise
    query = "SELECT id, name, role FROM users WHERE name = '" + name + "'"
    print(f"Running query: {query}")
    rows = cursor.execute(query).fetchall()
    connection.close()
    return rows

if __name__ == "__main__":
    # Read the search value from the command line
    search_name = sys.argv[1] if len(sys.argv) > 1 else "Alice"
    print(find_user(search_name))

Compare your complete README.md with this reference.

# Security Audit Demo

This sample app searches an in-memory SQLite user table.

## Run

On macOS or Linux:

```bash
python3 app.py Alice
```

On Windows:

```powershell
python app.py Alice
```

You should see Alice's user record in the output.

The query deliberately concatenates user input for this audit exercise.

Before you run the final checks, which user record do you expect the app to print?

Run the app before checking the repository state with the commands for your operating system:

macOS

python3 app.py Alice
git status

What should I see?

You should see Alice's record from the app. Git should also report app.py plus README.md as files waiting to be tracked.

Windows

python app.py Alice
git status

What should I see?

You should see Alice's record from the app. Git should also report app.py plus README.md as files waiting to be tracked.

Linux

python3 app.py Alice
git status

What should I see?

You should see Alice's record from the app. Git should also report app.py plus README.md as files waiting to be tracked.

You now have a working repository with a reproducible flaw. That gives the security audit a concrete result to find.

Your test repository is ready for inspection. Next up, you will install the security audit skill that examines it.

Install the Security Audit Skill

The deliberate flaw in security-audit-demo gives the audit a known issue to find. Your coding agent still needs a repeatable security workflow before it can inspect the repository.

The Cloudflare security audit skill provides that workflow through the Skills CLI. You will install the skill before confirming that your agent can see it without starting an audit.

In this step, get ready to:

Install the Cloudflare security audit skill with the Skills CLI.
Refresh the coding agent for security-audit-demo.
Confirm that the agent lists security-audit as an available skill.

Install the audit skill

The Skills CLI installs reusable instructions into a coding agent. The installer may ask which supported agent should receive the skill.

Return to the terminal you used to run security-audit-demo earlier.
Choose the coding agent you use for security-audit-demo if the installer asks where to install the skill.
Approve the installation if the installer asks for confirmation.
Install the skill by running this command:

npx skills add cloudflare/skills --skill security-audit

What does this command do?

The npx command launches the Skills CLI for this installation.
The cloudflare/skills value identifies the repository that supplies the skill.
The --skill option narrows the installation to the security-audit identifier.

Wait for the installation command to finish.

Good progress. You should see a successful installation confirmation that names security-audit.

Installation did not finish?

Check your internet connection if the installer cannot reach the repository.
Close your terminal before reopening it if the installer does not start.
Run the installation command again if you selected a different coding agent.

Still stuck? Help me troubleshoot why the security audit skill installation is failing.

Refresh your coding agent

Coding agents load their available skills into a session. Refreshing the session gives your agent a chance to discover the newly installed skill.

Return to the coding agent session for security-audit-demo.
Refresh the current agent session using its reload control.
Start a new agent session in security-audit-demo only if your agent has no reload control.

Your refreshed session now has access to the latest set of installed skills.

Verify the skill is available

The agent's available-skills list provides the final installation check. This check leaves the deliberate SQL-injection flaw untouched.

Before you check, do you expect the newly installed skill to appear in the agent's available-skills list?

Open the available-skills list in your coding agent.
Find security-audit in the list.
Check the security-audit-demo file tree for unexpected audit report folders.

You should see security-audit listed as available. Your repository should still contain its existing application files without a new audit report folder.

Skill missing from the list?

Confirm that you refreshed the same coding agent selected during installation.
Restart the agent session if a refresh does not update its available skills.
Repeat the installation if the terminal did not confirm completion.

Need another pair of eyes? Help me find why the installed security-audit skill is missing from my coding agent.

Your agent can now load the security audit workflow. Next up, you will run it against security-audit-demo to create the first audit artifacts.

Run the Initial Security Audit

Cloudflare's security-audit skill is available in your coding agent. That setup gives you a repeatable way to inspect the deliberate flaw in your repository.

This first run captures evidence before any fix changes the code. The output stays in ../security-audit-output/before-fix so your baseline remains separate from the repository.

In this step, get ready to:

Run the complete security audit workflow against security-audit-demo.
Create the initial audit evidence outside the repository.
Confirm that the deliberate SQL injection becomes a confirmed finding.

Start the baseline audit

A useful audit request defines the target before the agent starts. It also gives every generated artifact a predictable location.

Writing beside the repository may trigger a permission request. That request is expected because the output folder sits outside the agent's current workspace.

Switch back to the coding agent from the previous step.
Confirm that the agent's current workspace is security-audit-demo.
Ask the agent to audit the current repository with the installed security-audit skill.
Specify ../security-audit-output/before-fix as the output folder.
Require the skill's complete workflow of mapping, hunting, challenging, recording, verifying, and reporting.
Request architecture.md, coverage-ledger.md, findings.json, and REPORT.md as the audit evidence.
Require findings.json to pass the skill's schema validation.
Send the audit request from the agent's chat composer.

How does the workflow build confidence?

Mapping traces the application's security-relevant structure before the agent judges individual lines.
Hunting uses the coverage ledger to record reviewed areas and potential leads.
Challenging tests each lead against the surrounding code before it becomes a finding.
Recording stores the surviving findings in structured data.
Verification checks the evidence and validates the structured output.
Reporting turns the verified results into a readable baseline.

You'll see the agent begin inspecting app.py and the rest of the repository. That activity confirms the audit is using your code as its target.

Audit did not start?

Check that the agent still lists the security-audit skill as available.
Check that the current workspace is security-audit-demo.
Refresh the agent if it lost the skill after the previous step.

Still stuck? Help me start the installed security-audit skill against my current repository.

Watch the audit evidence appear

The audit can take several minutes while the agent follows leads through each phase. Keeping the target repository small gives every lead room for proper validation.

The architecture map shows how data reaches security-sensitive code. The coverage ledger records where the agent looked and which leads it considered.

Keep the audit run active in your coding agent.
Review each permission request before approving it.
Approve repository reads that target security-audit-demo.
Approve output writes that target ../security-audit-output/before-fix.
Use Finder on macOS or File Explorer on Windows to open the folder containing security-audit-demo.
Open the adjacent security-audit-output/before-fix folder.
Confirm that architecture.md and coverage-ledger.md appear during the run.

You'll see architecture.md describe the application's security-relevant data flow. You'll also see coverage-ledger.md record reviewed code areas and investigated leads.

What do these files prove?

The architecture map proves that the agent traced the application before evaluating findings. This gives each finding a clear connection to the code's data flow.

The coverage ledger makes the review inspectable. You can see which areas were examined instead of treating the final report as a black box.

Return to the coding agent from earlier.
Leave the audit running until the agent reports that the workflow is complete.

Verify the report and findings

Structured findings make the audit reproducible. The human-readable report makes the same evidence easier to review before you change any code.

Read the agent's completion summary.
Confirm that all six audit phases completed.
Check that the summary confirms successful validation of findings.json.
Switch back to the ../security-audit-output/before-fix folder.
Confirm that architecture.md, coverage-ledger.md, findings.json, and REPORT.md are present.

Before you open the report, make a mental prediction about whether the deliberate query construction becomes a confirmed finding.

Open REPORT.md from the before-fix folder.
Locate the finding about user-controlled input being concatenated into a SQL query.
Open findings.json from the same folder.
Confirm that the same SQL-query string concatenation is recorded as a confirmed finding.

You'll see the deliberate SQL-query construction recorded as a confirmed finding in the initial audit evidence. That result proves the skill traced the user-controlled input through to the vulnerable query.

Your baseline is complete. You now have a validated record of the flaw before any fix changes its behavior.

Finding not confirmed?

Check that the agent audited security-audit-demo instead of the output folder.
Check that app.py still contains the deliberate SQL-query string concatenation from earlier.
Ask the agent to complete the validation phase if the lead remains unverified.

Need help? Help me understand why the deliberate SQL-injection flaw was not confirmed.

Your before-fix evidence now captures the vulnerable starting point. Next, you'll review the report's validation statuses and decide which findings deserve action.

Review and Classify Findings

Your coding agent has finished the initial security audit. Its output captures what the agent examined before any fixes change the evidence.

The report becomes useful when each lead has a clear status. You will classify every lead before selecting the confirmed SQL injection issue for the next step.

In this step, get ready to:

Review the human-readable findings in REPORT.md.
Classify the structured records in findings.json.
Select the confirmed SQL injection finding for remediation.

Review the audit evidence

The REPORT.md file explains the audit conclusions for a human reader. The findings.json file preserves the structured evidence behind those conclusions.

Switch back to the coding agent from the previous step.
Use its file-opening control to open ../security-audit-output/before-fix/REPORT.md.
Read the validation status for each issue listed in the report.
Use the same file-opening control to open ../security-audit-output/before-fix/findings.json.
Compare each structured record with its matching report entry.

You should see the deliberate string-concatenated SQL query identified as a confirmed finding. You have now tied the report conclusion to the structured evidence behind it.

Cannot open the audit files?

Check that the file-opening control is looking one folder above security-audit-demo.
Confirm that you selected the before-fix folder inside security-audit-output.

Still stuck? Help me locate audit files written outside my repository.

Classify each audit result

An audit status tells you how much confidence to place in a lead. Each status also determines the next action for that lead.

What do the classifications mean?

Confirmed means the audit found enough evidence to support the security issue.
Rejected means the lead failed the audit's challenge or verification work.
Needs validation means the available evidence cannot settle the lead yet.

Return to ../security-audit-output/before-fix/findings.json.
Place every record into the bucket indicated by its validation status.
Return to ../security-audit-output/before-fix/REPORT.md.
Check that each narrative conclusion matches the corresponding bucket.

A bucket can be empty if the audit produced no results with that status. The important check is that every recorded lead has a clear classification.

Select the confirmed issue

Your next fix needs a finding that the audit has already supported with evidence. The deliberate string-concatenated query meets that threshold.

Return to the SQL injection record in ../security-audit-output/before-fix/findings.json.
Confirm that the record is classified as confirmed.
Match the record to the corresponding finding in ../security-audit-output/before-fix/REPORT.md.
Select the confirmed SQL injection issue as the finding to fix.
Keep both files unchanged as your before-fix evidence.

Before your final check, which status do you expect both files to assign to the string-concatenated SQL query?

Check the SQL injection entry in ../security-audit-output/before-fix/findings.json.
Check the matching entry in ../security-audit-output/before-fix/REPORT.md.

Both files should identify the SQL injection issue as confirmed. That shared status gives you a clear target for the fix.

Your before-fix evidence is reviewed. Next, you will fix the selected query before rerunning the audit to check whether the finding disappears.

Fix and Verify the Finding

The first audit gave you a confirmed SQL-injection finding in app.py. That evidence now points to a precise change in the code.

A parameterized query separates SQL structure from user-controlled data. The database handles that input as a value.

The application must still run after the change. A fresh security audit then checks whether the finding is gone.

In this step, get ready to:

Replace the vulnerable SQL construction in app.py.
Record the working fix in Git.
Produce after-fix audit evidence that proves remediation.

Fix the vulnerable query

The current query combines user-controlled input with SQL text. Parameterization keeps those two parts separate at execution time.

Switch back to the coding agent that is already open in the security-audit-demo repository.
Ask the agent to identify the string-concatenated SQL in app.py.

The response should point to the query that incorporates user-controlled input.

Ask the agent to replace that construction with a parameterized query without changing the application's intended behavior.
Ask the agent to show the resulting diff for app.py.

You should see the SQL template separated from the user-controlled value. The value should be passed through the database query interface.

Why does parameterization close the flaw?

String concatenation can let crafted input alter the meaning of a query. A parameterized query ensures the database treats the supplied input as data.

Before the agent tests the change, predict whether ordinary input should behave differently after the query is secured.

Ask the agent to run the application using the existing instructions in README.md.

You should see the same successful application behavior that you confirmed before the audit. That is the risky code change done.

Application no longer runs?

Ask the agent to compare the parameterized call with the database interface already used in app.py.
Check that the SQL placeholder matches the value passed to the query interface.

Still stuck? Help me diagnose why the application stopped working after I replaced string-concatenated SQL with a parameterized query.

Record the fix in Git

A Git commit creates a durable checkpoint for the remediation. It also connects the code change to your before-fix evidence.

Ask the agent to show the repository's current working tree status.

You should see app.py listed as the file changed by this remediation.

Ask the agent to commit only app.py with the message Fix SQL injection with parameterized query.
Ask the agent to show the newest commit summary.

The newest commit should display Fix SQL injection with parameterized query. Your repository now has a clear remediation checkpoint.

Commit did not complete?

Check the agent's response for a missing Git author identity.
Ask the agent to explain the required local identity configuration without changing unrelated repository settings.
Retry the commit after the identity is configured.

Need help? Help me resolve the Git configuration issue that is preventing this security-fix commit.

Rerun the audit and compare evidence

A separate audit run tests the committed version of the repository. Writing the output to ../security-audit-output/after-fix preserves the original evidence for comparison.

Ask the agent to rerun the installed security-audit skill against the committed security-audit-demo repository.
Tell the agent to write the new evidence to ../security-audit-output/after-fix.

The rerun works through the repository again. A pause while the agent completes those audit phases is expected.

Ask the agent to list the files written to ../security-audit-output/after-fix.

You should see architecture.md, coverage-ledger.md, findings.json, and REPORT.md in the after-fix folder.

Before the comparison, predict whether the resolved finding should appear in both reports, one report, or neither report.

Ask the agent to compare ../security-audit-output/before-fix/findings.json with ../security-audit-output/after-fix/findings.json.

The before-fix findings should contain the confirmed SQL-injection issue. The after-fix findings should omit that resolved issue.

Ask the agent to compare ../security-audit-output/before-fix/REPORT.md with ../security-audit-output/after-fix/REPORT.md.

The original report should document the issue. The rerun report should no longer contain it.

Ask the agent to list the audit evidence preserved in both output folders.

Both folders should remain available. Together they show the vulnerable state and the verified remediation.

✔️ The finding is gone

You closed the audit loop. The application still runs after the fix while the after-fix evidence no longer reports the resolved SQL-injection finding.

ⓧ The finding still appears

The rerun has found evidence that still matches the original issue. Trace that evidence before treating the remediation as complete.

Ask the agent to confirm that the security-fix commit is the version currently being audited.
Ask the agent to inspect app.py for another path that builds SQL from user-controlled input.
Ask the agent to correct any remaining vulnerable query.
Ask the agent to rerun the application using README.md.
Ask the agent to rerun the audit into ../security-audit-output/after-fix.

Finding persists after another rerun?

Ask for help with the remaining evidence. Help me determine why the SQL-injection finding still appears after parameterizing the query and rerunning the audit.

Secret mission

Create a Remediation Evidence Chain

A clean rerun shows that the finding disappeared. This challenge turns your preserved reports plus the security fix commit into a reviewer-ready evidence chain that explains why the result changed.

Clean Up Your Resources

Your repository and audit evidence live in local folders. Keeping them creates no ongoing infrastructure charges.

The completed audit runs may still create model provider charges. Decide whether to keep your evidence available, pause your work for later, or delete the local folders entirely.

Resources you used:

The local Git repository at security-audit-demo with the committed SQL-injection fix.
The initial audit evidence at ../security-audit-output/before-fix.
The rerun audit evidence at ../security-audit-output/after-fix.

Keep everything running

No action is needed. Choose this option if you want to preserve the repository with its before-and-after audit evidence.

Keep security-audit-demo so you can revisit the parameterized SQL fix.
Keep ../security-audit-output/before-fix as evidence of the original confirmed finding.
Keep ../security-audit-output/after-fix as evidence that the finding disappeared after remediation.
Review your model provider's usage page to confirm the final cost of the completed audit runs.

Pause - I'll come back to this later

Close the coding agent session to pause your work. Your repository and both sets of audit evidence stay ready for another review.

Close the coding agent session from earlier.
Keep security-audit-demo in its current location.
Keep ../security-audit-output/before-fix in its current location.
Keep ../security-audit-output/after-fix in its current location.
Review your model provider's usage page to confirm the final cost of the completed audit runs.

Delete - I don't want to use this again

Deletion is permanent because it removes the fix commit and both audit reports from your machine.

Review your model provider's usage page to record the final cost of the completed audit runs.
Choose the instructions for your operating system below.

macOS

Switch back to the coding agent terminal from earlier.
Confirm that the terminal prompt is inside security-audit-demo.
Remove the repository and its audit evidence by running these commands:

cd ..
rm -rf security-audit-demo security-audit-output
ls

What Do These Commands Do?

The first command moves the terminal into the folder containing both local resources.
The second command permanently deletes the repository and the complete audit output folder.
The final command lists the folders that remain.

You should see neither security-audit-demo nor security-audit-output in the final folder listing.

Still See Either Folder?

Check that your terminal started inside security-audit-demo. A different starting location points the commands at another parent folder.

Close any editor or agent process that still has a file from either folder open.

Help me safely remove the local audit folders.

Cleanup is complete. Your machine no longer holds the demo repository or its audit evidence.

Windows

Switch back to the coding agent PowerShell terminal from earlier.
Confirm that the terminal prompt is inside security-audit-demo.
Remove the repository and its audit evidence by running these commands:

Set-Location ..
Remove-Item -Recurse -Force security-audit-demo
Remove-Item -Recurse -Force security-audit-output
Get-ChildItem

What Do These Commands Do?

The first command moves the terminal into the folder containing both local resources.
The next two commands permanently delete the repository and the complete audit output folder.
The final command lists the folders that remain.

You should see neither security-audit-demo nor security-audit-output in the final folder listing.

Still See Either Folder?

Check that your terminal started inside security-audit-demo. A different starting location points the commands at another parent folder.

Close any editor or agent process that still has a file from either folder open.

Help me safely remove the local audit folders.

Cleanup is complete. Your machine no longer holds the demo repository or its audit evidence.

Linux

Switch back to the coding agent terminal from earlier.
Confirm that the terminal prompt is inside security-audit-demo.
Remove the repository and its audit evidence by running these commands:

cd ..
rm -rf security-audit-demo security-audit-output
ls

What Do These Commands Do?

The first command moves the terminal into the folder containing both local resources.
The second command permanently deletes the repository and the complete audit output folder.
The final command lists the folders that remain.

You should see neither security-audit-demo nor security-audit-output in the final folder listing.

Still See Either Folder?

Check that your terminal started inside security-audit-demo. A different starting location points the commands at another parent folder.

Close any editor or agent process that still has a file from either folder open.

Help me safely remove the local audit folders.

Cleanup is complete. Your machine no longer holds the demo repository or its audit evidence.

Nice Work!

You did it. You completed a reproducible security audit on code you own.

You've learned how to:

Ran a six-phase audit workflow against your own repository. The resulting evidence makes the review reproducible.
Validated findings.json against the skill's schema. You sorted each lead into confirmed, rejected, or needs validation.
Resolved the confirmed SQL injection vulnerability with a parameterized query. You recorded the change in Git. The clean rerun proves that the finding disappeared.
Secret Mission: Used the optional challenge to push your security audit workflow further.

Ready to quiz yourself?