# Teaching Script — Capstone C2: Build a Smart Contract or Cloud Security Harness

**Module**: C2 — Build a Smart Contract or Cloud Security Harness · **Duration**: ~90 minutes
**Format**: Verbatim transcript. Cues `[SLIDE N]` map to `03-slide-deck.html`.

---

[SLIDE 1 — Title]

This is Capstone Two: Build a Smart Contract or Cloud Security Harness. Ninety minutes. This is the second and final capstone of Course two-A. You completed Capstone One — you have the harness architecture: scope middleware, memory, tools, evidence, triage, report. You benchmarked it. Here you apply that architecture to a specialized domain — smart contract security or cloud security — and produce a publishable portfolio artifact. The deliverable is a one-page benchmark summary that goes on GitHub, LinkedIn, and Deepthreat-dot-A-I.

Three sub-sections. First, design and scoping — fifteen minutes choosing the track, defining the three modes, and writing the authorization document. Second, build and run — sixty minutes implementing the full pipeline against a real lab target. Third, benchmark and publish — fifteen minutes scoring against the domain benchmark and producing the one-page summary.

[SLIDE 2 — Same architecture, different domain]

The key insight from Capstone One: the architecture ports. The skeleton — scope middleware, memory, tools, evidence, triage, report — is domain-independent. You built it once. Now you apply it to smart contracts or cloud. What changes is the tool suite, the target, and the benchmark. The skills transfer directly. If you built Capstone One well, this capstone is a matter of swapping the domain layer onto a skeleton you already understand.

This capstone produces a publishable portfolio artifact. Not a script, not a prompt — a shippable, measurable, publishable security tool with a falsifiable benchmark score.

[SLIDE 3 — C2.1: Design and Scoping]

Sub-section one. Design and scoping. Fifteen minutes. You already have the architecture. The design work here is domain-specific: choosing the track, defining the three modes, selecting the tools, and writing the authorization document.

[SLIDE 4 — Two tracks, three modes each]

Two tracks. Smart contract audit harness, EVMbench-aligned. The target is a set of smart contracts on a forked mainnet or a Damn Vulnerable DeFi challenge. The harness runs three modes — Detect, Patch, Exploit — and is scored against an EVMbench subset. The deliverable is a client-ready audit report matching the structure top firms publish.

Or cloud posture plus red team harness. The target is an isolated AWS environment with deliberately misconfigured resources. The harness runs three modes — Detect, Remediate, Exploit — and is scored against a cloud posture benchmark, like a CIS AWS Foundations subset. The deliverable is a posture report with findings, evidence, and a remediation roadmap.

The three modes are the spine. For smart contracts: Detect finds vulnerabilities using Slither, Mythril, and LLM reasoning. Patch generates a fix that removes the vulnerability and preserves behavior — verified by re-running detection and the test suite. Exploit builds a working PoC on forked mainnet. For cloud: Detect identifies posture violations using Prowler and IAM analysis. Remediate applies a fix and verifies by re-scanning. Exploit attempts a controlled red-team action proving the exposure is real.

Let me be specific about what each mode produces. For smart contracts, Detect mode runs Slither for static analysis — reentrancy, integer issues, access control. It runs Mythril for symbolic execution on deeper paths. And it uses LLM reasoning over reorganized source, the context engineering from S eleven. The output is a set of candidate findings with location and vulnerability class. Patch mode takes each detected finding and generates a diff. The verification is two gates: re-run detection on the patched code — the finding must be gone, and no new findings introduced. And run the Foundry test suite — all tests must pass, behavior preserved. Exploit mode builds a PoC contract and transaction, runs it on the forked mainnet, and records whether the state changed as expected — did the funds move?

For cloud, Detect mode runs Prowler against the CIS benchmark and the IAM analyzer for over-permissive policies. The output is posture violations — misconfigured resources and violated controls. Remediate mode applies a fix — an IAM policy change, a security group tightening, a resource removal. The verification is two gates: re-scan the resource — the control must now pass. And verify the application still functions — the remediation did not break it. Over-remediation, like removing all permissions to make the scan clean, breaks the app and fails the gate. The correct fix tightens to least-privilege, not zero-privilege. Exploit mode attempts a controlled red-team action — assuming a role via an over-permissive policy, or accessing data in an exposed S3 bucket. The evidence is the API call chain and the access achieved.

A harness that only runs Detect is half a harness. The three modes together are the benchmark. Recall alone hides weaknesses in Patch and Exploit. This is the same lesson from Module S twelve — all three EVMbench scores must be reported together.

[SLIDE 5 — The authorization document is not a formality]

Write the authorization and scope document before you build. For smart contracts, it defines the contracts in scope — addresses and commit hashes — the forked block number, what the harness is authorized to do, and the engagement boundary. For cloud, it defines the AWS account ID, the regions in scope, the resources the harness may read and mutate, the actions it may take in Exploit mode, and the teardown procedure.

This is not a formality. For cloud especially, an exploit action against the wrong account or without blast-radius limits is a real incident. You are running a red-team action in Exploit mode — if that action hits the wrong target, you have a security incident on your hands. Write the authorization document. Define the blast radius. Set up the teardown. Then build.

[SLIDE 6 — C2.2: Build and Run]

Sub-section two. Build and run. Sixty minutes. Implement the full pipeline and run it against a real lab target.

[SLIDE 7 — The pipeline (both tracks)]

The pipeline is the C1 harness with domain-specific tools and modes. The build order is the same: scope middleware, memory, tools, evidence, triage, report. The difference is the tools and the mode loop.

For smart contracts: load the target contract source and the EVMbench metadata. Run Detect mode — Slither, Mythril, and the LLM reasoning over reorganized source. Collect candidate findings. Run Patch mode — for each detected finding, generate a patch and verify it by re-running detection and the Foundry test suite. Run Exploit mode — for each detected finding, build a PoC on forked mainnet, run it, and record success or failure. Triage to filter false positives. Generate the audit report.

For cloud: load the target environment and the control framework. Run Detect mode — the configuration scanner and IAM analyzer. Run Remediate mode — for each finding, apply a remediation and verify by re-running detection. Run Exploit mode — for each exposure, attempt a controlled red-team action. Triage and report.

Evidence is captured at every stage using the same tamper-evident chain from Capstone One. Finding links to evidence, with a sha256 hash, links to the tool call, links to the log line with the trace ID. The evidence shape is identical across domains — what changes is the raw output: a PoC transaction for smart contracts, a remediation diff or exploit chain for cloud. For a smart contract exploit, the evidence record contains the PoC transaction hash, the forked block number, the state diff, and the exploit contract source. A reviewer can replay the PoC on the same forked block and verify the same state change. For a cloud exploit, the evidence contains the API call chain — AssumeRole to ListObjects to GetObject — the scoped credentials used, and the data accessed. A reviewer sees exactly how the exposure was exploited and verifies the blast radius was contained.

The triage filter from Capstone One applies unchanged. Candidate findings move to confirmed only with linked evidence and a passing confidence threshold. Known false positives are filtered by rule — code, not LLM judgment. The false-positive rules are domain-specific: for smart contracts, a Slither finding on a test file is a false positive. For cloud, a Prowler finding on a resource in an excluded region is a false positive. But the triage state machine — candidate to confirmed or rejected — is the same.

[SLIDE 8 — Real lab targets]

A real lab target is non-negotiable. A harness tested only on toy examples is a hypothesis. The lab target makes the benchmark falsifiable — anyone can run the same target and compare their scores.

For smart contracts, you have three options. Damn Vulnerable DeFi — a set of deliberately vulnerable DeFi challenges, each with a known solution. DVD is ideal because the challenges are public, the solutions are known, and the protocols span real vulnerability classes: flash loan manipulation, price oracle abuse, governance attacks, lending-protocol liquidation logic. A harness that solves a DVD challenge has demonstrably found, understood, and exploited a real DeFi vulnerability. Forked mainnet — use Foundry to fork mainnet at a specific block and target a known-vulnerable contract, a historical exploit before the fix. This is the highest-fidelity target — the state is real, the contracts are real, and the PoC runs against the exact conditions that existed at the time of the exploit. Or an EVMbench subset — select ten to fifteen vulnerabilities from the dataset and run the three modes against each. Using the EVMbench subset makes your scores directly comparable to published results.

For cloud, you have two options. An isolated AWS account — provision misconfigured resources with Terraform: public S3 buckets, over-permissive IAM roles, exposed security groups, disabled logging. The harness detects, remediates, and exploits in the isolated account. This is the real thing — real AWS APIs, real IAM evaluation, real resource behavior. Use a dedicated account, never a shared or production account. Teardown destroys everything. Or LocalStack — a local AWS emulator for faster iteration without a real account, though some services are imperfectly emulated. Use LocalStack for development, then validate on a real isolated account before publishing the benchmark.

Run the full pipeline. Record every finding with its evidence. The success criterion is not "it ran." It is "it produced confirmed findings with evidence for the known vulnerabilities or misconfigurations." A run that produces zero confirmed findings against a target with known bugs is a failed run. Debug the pipeline: did Detect find the bugs? Did the triage filter reject them erroneously? Did the evidence recorder fail to capture proof?

[SLIDE 9 — C2.3: Benchmark and Publish]

Sub-section three. Benchmark and publish. Fifteen minutes. This is the portfolio moment.

[SLIDE 10 — Three scores, reported together]

Score the three modes independently. For smart contracts: Detect recall — of the N known vulnerabilities, how many did the harness find? Patch quality — for each detected finding, did the patch remove the vulnerability and preserve behavior? Exploit success rate — for each detected finding, did the harness build a working PoC on forked mainnet? For cloud: Detect recall — of the N seeded misconfigurations, how many did the harness find? Remediation success — did the fix resolve it without breaking the application? Exploit success — did the red-team objective get achieved?

The Patch quality gate has two parts. Re-run detection on the patched code — the finding must be gone, and no new findings introduced. And run the Foundry test suite — all tests must pass, behavior preserved. A patch that removes the bug but breaks a test fails. A patch that fixes the specific PoC but leaves the underlying flaw — the trap from S eleven point four — fails. Both gates must pass. The Remediation gate for cloud is parallel: re-scan the resource, the control must now pass. And verify the application still functions. Over-remediation — removing all permissions to make the scan clean — breaks the application and fails the gate. The correct fix tightens to least-privilege, not zero-privilege.

Report all three together. A harness scoring eighty-five percent Detect, thirty percent Patch, thirty percent Exploit is a detection engine, not a harness. It finds bugs but cannot fix or exploit them. A harness scoring eighty percent across all three is a genuine tool. The scores are falsifiable — anyone can run the same target, the same DVD challenge, the same forked mainnet block, the same isolated AWS account, and compare. That falsifiability is what makes the score publishable.

[SLIDE 11 — The one-page summary is the asset]

Distill the benchmark and the client report into a single one-page summary. Harness name, target, date, a three-mode score table, and links to the full report and the evidence repository.

This one page is the portfolio asset. It goes on three platforms. On GitHub, it is the README for the harness repository, with the full report and evidence chain linked. On LinkedIn, it is a post showcasing the benchmark and the client report, positioning the work as a falsifiable security claim — not "trust me, I'm good," but "here is the scored evidence, run it yourself." On Deepthreat-dot-A-I, it is a demonstration asset showing the harness running against a real target with scored results.

The harness is the engine. The benchmark is the proof. The published summary is the portfolio. This is the culmination of Course two-A. What started in Course One with harness fundamentals — context engineering, tool design, memory, scope — and continued through Course two-A's security pillars — offensive, AppSec, cloud, smart contracts — ends here: a shippable, measurable, publishable security harness with a falsifiable benchmark score. Not a prompt. Not a script. A tool a client could receive, a benchmark a competitor could verify, and a portfolio piece you can publish. Begin with the design and scoping. Fifteen minutes. Then build, run, benchmark, and publish.