Part 7 — Ship Compliance Evidence & Monitor

Six parts, six real fixes — a parameterized query and a rotated key, a dependency bump behind an SCA gate, a signed non-root image, a Terraform plan two Rego rules now guard, an IDOR and an XSS confirmed gone by an authenticated DAST scan. None of that is provable yet. A fix that only exists as "the pull request merged" is a claim, not evidence, and Part 1's own threat model already named the gap this closes — finding nine, Repudiation, disposition Open — Part 7. Today you write an InSpec profile that encodes three of those fixes as controls you can rerun on demand, roll every stage's findings into one DefectDojo product, and wire a Sigma-authored Wazuh rule to Vulnerly's own access log that fires on the exact SQL-injection shape Part 1 found first — proving not just that it was fixed, but that you'd know if it ever came back.

What Part 1's ninth finding is still waiting on

☺ Like you're 10: Eight gaps in the fence got patched one at a time. The ninth gap was never a hole at all — it was "nobody's checking whether the patches hold."

Reread Part 1's findings table for a moment. Eight of its nine rows name a concrete flaw in Vulnerly's code, dependencies, container, or Terraform — SQL injection, the leaked key, the IDOR, the vulnerable dependencies, the unsigned image, the public bucket, the open security group — and Parts 2 through 6 closed every one of them, in order, each with its own committed proof. The ninth row is different in kind, not degree: "No centralized findings, evidence trail, or alerting — even once Parts 2-6 fix six real bugs, nothing proves any of it happened or stays fixed," tagged Repudiation, disposition Open — Part 7 (DefectDojo + InSpec + Wazuh). That row was never about a bug in the app. It's about the app's proof — and proof doesn't get produced automatically just because the other eight rows did.

Three real gaps sit inside that one row, and they need three different tools, not one bigger one. First: six parts each produced findings in a different shape — Semgrep JSON, a gitleaks report, Trivy JSON, Checkov and Conftest output, ZAP's before/after reports — scattered across six pipeline runs with no single place that shows "here is everything wrong with vulnerly, right now." Second: every fix so far is proven exactly once, at merge time, by the check that caught the original bug. Nothing re-asks the question next week. Third: even a perfectly fixed app has no way to notice someone trying the old attack again — a patched SQL injection and a SQL injection nobody's watching for look identical from the outside until the day the patch quietly regresses.

The shape of this part: evidence, verification, watching

☺ Like you're 10: Three separate jobs, three separate tools — one that files every report in one drawer, one that re-checks the patches with its own hands, and one that stands at the one door somebody already tried to pick.

Each of the three tools this page uses solves exactly one of the three gaps above, and none of them substitutes for the others — DefectDojo detects nothing, InSpec doesn't watch anything continuously, and Wazuh doesn't care whether last month's Terraform plan was clean. That's deliberate: compliance & governance and detection engineering & security observability both make this same point in general — verification and monitoring are different disciplines with different failure modes, and bolting them together into one tool tends to do both jobs worse than doing them separately, well.

Adding the one thing the app never needed before: access logging

☺ Like you're 10: You can't put a camera on a door if nobody ever writes down who walked through it — so first, someone has to start keeping a guest book.

Every earlier part checked Vulnerly from the outside, at build time, or against a snapshot. None of them needed Vulnerly to remember its own request traffic, so it never has — app/src/index.js still boots a plain Express app with no request logging at all. That has to change before Wazuh has anything to watch. Add morgan in Apache's combined format, which — critically for what's coming — includes the raw request line, query string and all:

// app/src/index.js — Part 7 adds the one line Parts 1–6 never needed
const express = require("express");
const morgan = require("morgan");
require("dotenv").config();

const app = express();
app.use(morgan("combined"));   // every request, including the raw query string, to stdout

// ...the rest of app.js is unchanged since Part 6's route split into app/src/routes/transactions.js

Commit it, let Part 2's and Part 3's gates wave a one-dependency, one-line change through, and redeploy the same way every earlier part did — a new signed digest, admitted because Kyverno still verifies it:

kubectl set image -n vulnerly deploy/vulnerly vulnerly=ghcr.io/YOU/vulnerly:sha-<new digest>
kubectl -n vulnerly rollout status deploy/vulnerly
kubectl -n vulnerly logs deploy/vulnerly --tail=5

A combined-format line looks like this — this exact shape is what the decoder later in this page parses, so look at it closely before moving on:

10.0.1.23 - - [17/Aug/2026:10:22:03 +0000] "GET /reconciliation/search?merchant=acme HTTP/1.1" 200 512 "-" "curl/8.4.0"

Rolling every stage's findings into one DefectDojo product

☺ Like you're 10: One filing cabinet, one drawer per part, instead of six different desks each holding one part's own pile of sticky notes.

Stand up DefectDojo the way the hub already placed it — in the platform namespace of the same vulnerly-dev cluster Kyverno already lives in, via its Helm chart rather than the Docker Compose quickstart, since this is meant to stay up alongside everything else you've already built:

helm repo add defectdojo https://raw.githubusercontent.com/DefectDojo/django-DefectDojo/helm-charts
helm repo update
helm install defectdojo defectdojo/django-defectdojo -n platform \
  --set createSecret=true \
  --set host=defectdojo.platform.svc.cluster.local

kubectl -n platform get pods -l app.kubernetes.io/name=django-defectdojo
kubectl -n platform port-forward svc/defectdojo-django-defectdojo 8443:443   # leave running

# from the dashboard: Settings → API v2 Key, then export it
export DD_API_TOKEN=<your-token>
export DD_URL=https://localhost:8443

Create the one Product every Engagement will hang off of, then import each part's own report into its own Engagement — import-scan for the first run of each, exactly as the DefectDojo tool page describes:

curl -sk -X POST "$DD_URL/api/v2/products/" \
  -H "Authorization: Token $DD_API_TOKEN" -H "Content-Type: application/json" \
  -d '{"name":"vulnerly","description":"The whole seven-part capstone app","prod_type":1}'

# Part 2 — two Tests in one Engagement: the gitleaks and Semgrep gates
curl -sk -X POST "$DD_URL/api/v2/import-scan/" -H "Authorization: Token $DD_API_TOKEN" \
  -F "product_name=vulnerly" -F "engagement_name=vulnerly · Part 2 · SAST & secrets" \
  -F "scan_type=Semgrep JSON Report" -F "file=@semgrep-report.json" -F "active=true"
curl -sk -X POST "$DD_URL/api/v2/import-scan/" -H "Authorization: Token $DD_API_TOKEN" \
  -F "product_name=vulnerly" -F "engagement_name=vulnerly · Part 2 · SAST & secrets" \
  -F "scan_type=Gitleaks Scan" -F "file=@gitleaks-report.json"

# Part 3 — Trivy's SCA gate
curl -sk -X POST "$DD_URL/api/v2/import-scan/" -H "Authorization: Token $DD_API_TOKEN" \
  -F "product_name=vulnerly" -F "engagement_name=vulnerly · Part 3 · SCA gate" \
  -F "scan_type=Trivy Scan" -F "file=@security/evidence/trivy-image-report.json"

# Part 5 — Checkov's IaC scan
curl -sk -X POST "$DD_URL/api/v2/import-scan/" -H "Authorization: Token $DD_API_TOKEN" \
  -F "product_name=vulnerly" -F "engagement_name=vulnerly · Part 5 · IaC policy" \
  -F "scan_type=Checkov Scan" -F "file=@checkov-report.json"

# Part 6 — both ZAP reports, before and after, side by side
curl -sk -X POST "$DD_URL/api/v2/import-scan/" -H "Authorization: Token $DD_API_TOKEN" \
  -F "product_name=vulnerly" -F "engagement_name=vulnerly · Part 6 · DAST run" \
  -F "scan_type=ZAP Scan" -F "file=@security/zap/reports/staging-before.json"
curl -sk -X POST "$DD_URL/api/v2/import-scan/" -H "Authorization: Token $DD_API_TOKEN" \
  -F "product_name=vulnerly" -F "engagement_name=vulnerly · Part 6 · DAST run" \
  -F "scan_type=ZAP Scan" -F "file=@security/zap/reports/staging-after.json"

gitleaks-report.json doesn't exist yet — Part 2's job gates on exit code alone, with no JSON artifact saved. Rerun it once with --report-format json --report-path gitleaks-report.json added to produce the evidence file rather than reopening that page to change a job that already works. Confirm each parser name against your own installed version's /api/v2/test_types/ before trusting the strings above verbatim — the tool page flags exactly this as something that shifts release to release.

Writing the InSpec profile: three controls, real evidence

☺ Like you're 10: Three short questions you can ask the real, running system at any time — not "did we fix it once," but "is it still true right now."

Scaffold the profile and give it four inputs so nothing below hardcodes a name that might change:

inspec init profile security/inspec-profile
inspec check security/inspec-profile   # structure only — no target contacted yet

# security/inspec-profile/inspec.yml
name: vulnerly-capstone-baseline
title: Vulnerly Capstone Compliance Baseline
maintainer: you
license: Apache-2.0
summary: Three controls proving Parts 3, 4, and 5's fixes are still true today, not just the day they merged.
version: 1.0.0
inputs:
  - name: k8s_namespace
    type: string
    value: vulnerly
  - name: k8s_deployment
    type: string
    value: vulnerly
  - name: export_bucket
    type: string
    value: vulnerly-transaction-exports
  - name: aws_endpoint
    type: string
    value: "--endpoint-url http://localhost:4566"   # LocalStack; blank this out for real AWS
supports:
  - platform: linux

Control 1 — the running Pod, not the Dockerfile, must not run as root. Part 4 added a non-root USER to the Dockerfile and a Kyverno policy that refuses an image without one. Neither of those is what actually matters day to day: what matters is the UID the real process is running as, right now, inside the real Pod. This control skips the source entirely and asks the cluster directly:

# security/inspec-profile/controls/container.rb
control 'vulnerly-container-01' do
  impact 1.0
  title 'The running vulnerly Pod must not execute as root'
  desc 'Part 4 hardened the Dockerfile and gated admission with Kyverno. This control proves the deployed reality matches that promise, independent of whether the source or the policy have drifted since.'
  tag part: 'Part 4 — sign & harden the container'

  describe command("kubectl -n #{input('k8s_namespace')} exec deploy/#{input('k8s_deployment')} -- id -u") do
    its('exit_status') { should eq 0 }
    its('stdout.strip') { should_not be_empty }
    its('stdout.strip') { should_not eq '0' }
  end
end

Control 2 — the export bucket must not be public-read. If you haven't already, apply Part 5's now-fixed infra/main.tf against a free, local LocalStack sandbox — a few seconds to stand up, nothing to tear down that costs anything:

docker run -d --name localstack -p 4566:4566 localstack/localstack

# tflocal wraps terraform and rewrites the AWS provider's endpoints for you —
# infra/main.tf itself needs no changes to run against LocalStack
pip install terraform-local
cd infra && tflocal init -input=false
tflocal apply -auto-approve

Then the control itself. InSpec's typed AWS resources don't cleanly expose an ACL's grantee list, so this reaches for the same escape hatch the InSpec tool page already shows for exactly this reason — the generic command resource — and checks for the one string that means "world-readable," the AWS-defined AllUsers grantee group URI:

# security/inspec-profile/controls/iac.rb
control 'vulnerly-iac-01' do
  impact 1.0
  title 'The transaction-export bucket must not be public-read'
  desc "Part 5's Checkov + OPA gate blocks a public-read ACL from ever being *applied* through Terraform. This control checks the *deployed* bucket instead — the only way to catch a change made by hand, straight through a console, after the fact, which a plan-time policy can never see."
  tag part: 'Part 5 — IaC scanning & policy'

  describe command("aws s3api get-bucket-acl --bucket #{input('export_bucket')} #{input('aws_endpoint')} --output json") do
    its('exit_status') { should eq 0 }
    its('stdout') { should_not match(/AllUsers/) }
  end
end

Control 3 — no unresolved critical-severity CVE in the built image. Rather than re-running Trivy inside the InSpec run itself, this control reads Trivy's own JSON output as durable evidence, using InSpec's built-in json resource — a real reused artifact, not a fresh scan pretending to be one:

mkdir -p security/evidence
trivy image --format json --output security/evidence/trivy-image-report.json \
  ghcr.io/YOU/vulnerly:sha-<current digest>

# security/inspec-profile/controls/sca.rb
control 'vulnerly-sca-01' do
  impact 1.0
  title 'No unresolved critical-severity CVEs in the built image'
  desc "Part 3's Trivy gate already blocks a build carrying a critical CVE at merge time. This control re-reads that same scan shape as durable evidence, so 'the gate passed once' survives past the one CI run that produced it."
  tag part: 'Part 3 — SCA gate (Trivy)'

  report = json('../evidence/trivy-image-report.json')
  criticals = report.params.fetch('Results', []).to_a
    .flat_map { |r| (r['Vulnerabilities'] || []) }
    .select { |v| v['Severity'] == 'CRITICAL' }

  describe criticals do
    it { should be_empty }
  end
end

Run the whole profile, keep a dated JSON reporter output as evidence, and hand that file to DefectDojo the same way every other stage's report already landed there — a profile result is a finding source like any other:

inspec exec security/inspec-profile \
  --reporter cli json:security/evidence/inspec-results.json

# InSpec — control vulnerly-container-01: PASSED
# InSpec — control vulnerly-iac-01: PASSED
# InSpec — control vulnerly-sca-01: PASSED
# 3 successful, 0 failures, 0 skipped

Proving the profile fails, not just passes

☺ Like you're 10: A smoke detector nobody's ever actually tested with smoke is a hope, not a working alarm. Prove it screams before you trust that it will.

A profile that has only ever returned green hasn't proven anything yet — it might be checking the wrong thing entirely and you'd have no way to tell. Deliberately break exactly one of the three fixes, rerun the same profile, and confirm the matching control — and only that one — turns red:

# re-widen the bucket by hand, straight through the API — no Terraform involved at all
aws s3api put-bucket-acl --bucket vulnerly-transaction-exports \
  --endpoint-url http://localhost:4566 --acl public-read

inspec exec security/inspec-profile --reporter cli
# InSpec — control vulnerly-container-01: PASSED
# InSpec — control vulnerly-iac-01: FAILED   (exactly the one you broke)
# InSpec — control vulnerly-sca-01: PASSED

# put it back
aws s3api put-bucket-acl --bucket vulnerly-transaction-exports \
  --endpoint-url http://localhost:4566 --acl private
inspec exec security/inspec-profile --reporter cli
# InSpec — control vulnerly-iac-01: PASSED   (green again, within the same minute)

Closing the loop: a Sigma rule, a Wazuh rule, and a real test that fires it

☺ Like you're 10: Fixing the lock stops today's fox. A camera on that exact door tells you the moment a fox tries the handle again — even after the lock is already good.

Part 2 already made Vulnerly's reconciliation search endpoint safe against a real SQL injection — the query is parameterized now, and no crafted merchant value can change its structure. That fix does not mean nobody will ever try. Write the detection logic once, portably, the way detection engineering & security observability argues every rule should exist — as a Sigma rule, in git, before it's translated into whatever backend actually runs it:

# detections/vulnerly-sqli-attempt.yml
title: SQL Injection Attempt Against Vulnerly's Reconciliation Search
id: 5e2a9c40-6b31-4f2e-9c1a-7d3b8e410007
status: experimental
description: >
  Flags a request to /reconciliation/search whose query string contains a
  SQL metacharacter or keyword shaped like an injection attempt — the exact
  endpoint Part 1's threat model flagged as Tampering, and Part 2 later
  fixed with a parameterized query. This rule proves the attempt itself
  stays visible even though it can no longer succeed.
references:
  - capstone-threat-model.html#attack-path-1
  - https://attack.mitre.org/techniques/T1190/
author: Shift-Left Squad
date: 2026-08-17
logsource:
  category: webserver
  product: vulnerly
detection:
  selection:
    cs-uri-query|contains:
      - 'UNION'
      - 'SELECT'
      - 'OR 1=1'
      - "OR '1'='1"
      - '--'
      - '%27'
  path_filter:
    cs-uri-stem: '/reconciliation/search'
  condition: selection and path_filter
falsepositives:
  - A merchant name that legitimately contains the substring OR or a stray apostrophe — rare; check Vulnerly's own merchant table before tuning this out
level: high
tags:
  - attack.initial_access
  - attack.t1190

Wazuh isn't a native Sigma compilation target — the detection-engineering page says as much plainly — so this gets hand-translated into Wazuh's own decoder and rule XML rather than run through a converter. First, teach the manager to parse a combined-format access log line into fields:

<!-- /var/ossec/etc/decoders/local_decoder.xml -->
<decoder name="vulnerly-access">
  <prematch>^\S+ \S+ \S+ \[\d</prematch>
</decoder>

<decoder name="vulnerly-access-request">
  <parent>vulnerly-access</parent>
  <regex>"(\S+) (\S+) HTTP\S+" (\d+) </regex>
  <order>http_method, http_uri, http_status</order>
</decoder>

Then the rule itself — Sigma's selection block becomes a single pcre2 field match, and its path_filter is folded straight into the same pattern since Wazuh rules don't have Sigma's separate named-selector syntax. Local IDs start at 100000, exactly as the Wazuh tool page insists on, so a future upstream rule at a low ID can never collide with this one:

<!-- /var/ossec/etc/rules/local_rules.xml -->
<group name="vulnerly,sqli,">
<rule id="100200" level="12">
  <decoded_as>vulnerly-access-request</decoded_as>
  <field name="http_uri" type="pcre2">/reconciliation/search\?.*(UNION|SELECT|OR%201%3D1|OR\s+'1'='1|--|%27)</field>
  <description>Possible SQL injection attempt against Vulnerly's reconciliation search endpoint — Part 1, attack path 1</description>
  <mitre>
    <id>T1190</id>
  </mitre>
  <group>attack.initial_access,attack.t1190,</group>
</rule>
</group>

Stand up Wazuh with its own all-in-one quickstart — a single host is plenty for this lab — then point its collector at the log stream Part 7's new morgan middleware is now producing:

curl -sO https://packages.wazuh.com/4.x/wazuh-install.sh
sudo bash wazuh-install.sh -a

sudo mkdir -p /var/log/vulnerly
kubectl -n vulnerly logs -f deploy/vulnerly >> /var/log/vulnerly/access.log &

<!-- /var/ossec/etc/ossec.conf — appended on the manager -->
<localfile>
  <log_format>syslog</log_format>
  <location>/var/log/vulnerly/access.log</location>
</localfile>

sudo /var/ossec/bin/wazuh-control restart

# lint the new rule against a known-bad line before trusting it against real traffic
sudo /var/ossec/bin/wazuh-logtest
> 10.0.1.23 - - [17/Aug/2026:10:22:03 +0000] "GET /reconciliation/search?merchant=%27%20OR%20%271%27%3D%271 HTTP/1.1" 200 512 "-" "curl/8.4.0"
=> **Rule id: '100200'** (level 12) -> 'Possible SQL injection attempt against Vulnerly's reconciliation search endpoint — Part 1, attack path 1'

Trigger it for real, against the live endpoint — the parameterized query means the response comes back clean, but the alert is what's being tested here, not the query:

curl -s "http://vulnerly.local/reconciliation/search?merchant=foo%27%20OR%20%271%27%3D%271" -o /dev/null

tail -f /var/ossec/logs/alerts/alerts.json | jq 'select(.rule.id=="100200")'
# {
#   "rule": { "id": "100200", "level": 12, "description": "Possible SQL injection attempt..." },
#   "data": { "http_uri": "/reconciliation/search?merchant=%27%20OR%20%271%27%3D%271", "http_status": "200" }
# }

That's the loop closed: the exact attack shape Rocky named in Part 1, unable to succeed since Part 2, is now something the platform notices the instant anyone tries it — regression or fresh attempt, either one. The same decoder-plus-rule pattern generalizes directly: a second, much smaller rule watching CI logs for a credential-shaped string reappearing in a future commit would close the matching half of Part 1's attack path 1 the identical way, catching a regression of Part 2's other fix with the same "count and combine" shape this page just walked through once, in full.

What "done" looks like for Part 7 — and for the whole capstone

☺ Like you're 10: Nine gaps found on day one, eight fixed one at a time, and now proof the fixes hold plus a camera on the one door someone already tried.

At the end of this part: a DefectDojo product named vulnerly holding an Engagement for Parts 2, 3, 5, and 6 with every finding rolled into one backlog; a three-control InSpec profile, proven in both directions, that passes against the real hardened environment and fails the instant one of those fixes is reverted; and a Wazuh rule, authored first as portable Sigma and hand-translated into live XML, that fired on a real request carrying Part 1's original attack shape. That closes Part 1's ninth finding — Repudiation, Open — Part 7 — and with it, the capstone: nine findings named on day one, six concrete fixes proven working, and now durable evidence plus a live watch on the one door somebody already tried. The hub tracks all seven parts in one place if you want the full arc end to end; from here, the CDP study plan and the CDP exam guide are where this hands-on rep turns into exam readiness.

Milestones

☺ Like you're 10: Tick a box only once you've actually watched it happen on your own screen — a step that "sounds right" isn't the same as one you've verified.

Work these in order. Progress saves in this browser.

Part 7 closes the capstone: a DefectDojo product rolling up six parts of findings, an InSpec profile proven in both directions against the real environment, and a Sigma-authored Wazuh rule that fires on the exact attack shape Part 1 found first. Step back to the capstone hub for the full seven-part arc in one place, revisit Compliance & governance and Detection engineering & security observability for the concepts behind what you just built, and when you're ready to turn this hands-on work into exam readiness, the CDP study plan and the CDP exam guide are where to go next.