Project 20: Rootkit Defense Toolkit

Integrate all checks into a single defense toolkit.

Quick Reference

Attribute Value
Difficulty Level 3
Time Estimate 3-4 weeks
Main Programming Language Python (Alternatives: Python, PowerShell)
Alternative Programming Languages Python, PowerShell
Coolness Level Level 4
Business Potential Level 3
Prerequisites OS internals basics, CLI usage, logging familiarity
Key Topics toolkit orchestration, reporting

1. Learning Objectives

By completing this project, you will:

  1. Build a repeatable workflow for rootkit defense toolkit.
  2. Generate reports with deterministic outputs.
  3. Translate findings into actionable recommendations.

2. All Theory Needed (Per-Concept Breakdown)

Toolkit Orchestration and Evidence Pipelines

Fundamentals A defense toolkit orchestrates multiple checks into a repeatable workflow. Instead of running independent scripts manually, a toolkit defines the order, inputs, outputs, and evidence handling rules so results are consistent and auditable. For rootkit defense, orchestration matters because you often need to run integrity checks, cross-view diffs, and memory triage together. A pipeline approach ensures that each step uses trusted inputs and that evidence is stored with hashes and metadata.

Deep Dive into the concept Orchestration begins with dependency order. Boot integrity checks should run before OS-level checks because they determine trust. Cross-view diffs rely on stable snapshots to avoid inconsistent results. Memory triage requires evidence integrity. A toolkit defines this order and captures the outputs in a structured format.

Input trust is the central challenge. A toolkit running on a potentially compromised host must minimize reliance on in-host data. This is why toolkits often include host-side collection, offline baselines, and cryptographic validation. Where possible, the toolkit should record tool hashes and versions for reproducibility.

Evidence pipelines require consistent storage. The toolkit should create a case directory with subfolders for raw artifacts, reports, logs, and hashes. Each run should have a unique identifier, and every artifact should be hashed. Reports should include references to the source artifacts and hashes so the results can be validated.

Finally, orchestration should produce actionable output. A single consolidated report should highlight high-risk findings, provide next-step recommendations, and link to detailed artifacts. This transforms a collection of scripts into an operational defense capability.

How this fit on projects You will apply this in Section 4.1 (High-Level Design), Section 5.2 (Project Structure), and Section 12 (Completion Criteria). Also used in: P20-rootkit-defense-toolkit.

Definitions & key terms

  • Orchestration: Coordinating multiple tools and steps into a single workflow.
  • Pipeline: A sequence of steps with defined inputs and outputs.
  • Case directory: A structured folder containing all evidence and reports for a run.
  • Run ID: A unique identifier for each toolkit execution.

Mental model diagram

[Inputs] -> [Boot Checks] -> [Cross-View] -> [Memory Triage] -> [Report]
    |                                                      |
    v                                                      v
[Case Directory + Hashes] ----------------------------> [Audit Trail]

How it works (step-by-step)

  1. Initialize a case directory with a unique run ID.
  2. Collect boot and kernel integrity data.
  3. Run cross-view checks and capture diffs.
  4. Perform memory triage where applicable.
  5. Generate a consolidated report and hash all artifacts.

Minimal concrete example

$ ./rootkit_defense_toolkit --case 2026-01-01T10-00Z
[case] created reports/ and artifacts/
[boot] baseline compare: OK
[cross-view] process diff: 2 anomalies
[triage] memory report: saved
[report] consolidated_report.md

Common misconceptions

  • “Toolkit just runs scripts.” Without evidence pipelines, results are not defensible.
  • “Ordering doesn’t matter.” Some checks depend on earlier integrity validation.
  • “One report is enough.” You still need raw artifacts for verification.

Check-your-understanding questions

  • Why should boot checks run before OS-level checks?
  • What is the purpose of a case directory?
  • How do you make a toolkit run reproducible?

Check-your-understanding answers

  • Boot integrity determines whether OS-level observations can be trusted.
  • It organizes artifacts, hashes, and reports for auditability.
  • Pin tool versions, record inputs, and use deterministic IDs.

Real-world applications

  • Security operations toolchains for endpoint integrity audits.
  • IR toolkits used during incident response.

Where you’ll apply it You will apply this in Section 4.1 (High-Level Design), Section 5.2 (Project Structure), and Section 12 (Completion Criteria). Also used in: P20-rootkit-defense-toolkit.

References

  • Incident response toolchain design patterns
  • DFIR evidence handling guides

Key insights Orchestration turns scattered checks into a trustworthy defense workflow.

Summary Define order, preserve evidence, and produce consolidated, auditable outputs.

Homework/Exercises to practice the concept

  • Sketch a pipeline that runs boot checks before cross-view checks.
  • Design a case directory layout for a toolkit run.

Solutions to the homework/exercises

  • Your pipeline should show integrity checks first, then cross-view, then triage.
  • A case layout should include artifacts/, reports/, logs/, and hashes.txt.

Integrity Baselines, Hashing, and Drift Management

Fundamentals An integrity baseline is a recorded snapshot of trusted system components and their cryptographic hashes. In rootkit defense, baselines allow you to detect subtle changes to bootloaders, kernels, drivers, and critical configuration files. A hash is a fingerprint; when it changes, the underlying content has changed. Baselines must be stored out-of-band so a compromised system cannot rewrite them. Drift management is the discipline of updating baselines after legitimate changes and documenting why a change is expected. Without drift management, baselines either generate noise or become obsolete.

Deep Dive into the concept A baseline is only meaningful if you trust the state you captured. That means you collect it from a known-good system state and you store it where it cannot be modified by an attacker. For boot and kernel integrity, the baseline should include paths, hashes, sizes, signer metadata, and version identifiers. Hash choice matters: SHA-256 or better is standard for integrity. You also need to record the hash tool version and operating system build because differences in tooling or build can change file layouts or metadata.

Drift is inevitable because software updates change files. The mistake is treating drift as noise. Instead, drift should be managed as a controlled change process. When a patch is applied, you update the baseline with evidence: the patch ID, the time, and the list of changed components. Some teams sign baseline files or store them in a WORM location to prevent tampering. Another approach is to store baselines in a central secure system and compare the local system to that secure copy.

The baseline schema should be explicit. For each component, include: file path, hash, signer, file size, timestamp, and expected owner/permissions. This allows you to detect not just content changes but also permission changes that might signal tampering. If you run baselines across multiple OSes, create a common schema but allow OS-specific fields (e.g., Authenticode signer on Windows, module signing key on Linux, SIP state on macOS).

Operationally, baselines are only useful if there is a diff workflow. A diff tool should categorize changes: expected (known patch), suspicious (unsigned driver appears), and unknown (hash mismatch without explanation). The diff output should be actionable: it should highlight what changed, where, and how to reproduce the check. If a system is compromised, baselines enable you to identify the earliest point of drift and decide whether to rebuild.

Finally, baselines are not just for detection; they are for accountability. A well-maintained baseline program forces teams to document changes, which makes stealthy tampering harder to hide. In rootkit defense, the baseline is the anchor that turns “unknown” into a measurable delta.

How this fit on projects You will apply this in Section 3.2 (Functional Requirements), Section 3.5 (Data Formats), and Section 6.2 (Critical Test Cases). Also used in: P03-integrity-baseline-builder, P08-boot-integrity-monitor, P20-rootkit-defense-toolkit.

Definitions & key terms

  • Baseline: A trusted snapshot of component hashes and metadata used for comparison.
  • Drift: Any change between current state and baseline, whether legitimate or malicious.
  • Hash: A cryptographic fingerprint that changes when file contents change.
  • WORM storage: Write-once, read-many storage to prevent tampering with baselines.

Mental model diagram

[Known-Good System]
   |  (hash + metadata)
   v
[Baseline JSON] --(stored offline)--> [Comparison Engine]
   ^                               |
   |  (hash live system)           v
[Current System] -------------> [Diff Report]

How it works (step-by-step)

  1. Collect hashes and metadata from a known-good system state.
  2. Store the baseline offline or in a secured repository.
  3. Collect the same fields from the live system.
  4. Compare current state to baseline and categorize drift.
  5. Update baseline only after verified change approval.

Minimal concrete example

{
  "component": "kernel",
  "path": "/boot/vmlinuz-6.6.8",
  "sha256": "9f...",
  "signer": "Build Key",
  "version": "6.6.8",
  "collected_at": "2026-01-01T10:00:00Z"
}

Common misconceptions

  • “Baselines are set-and-forget.” Without updates, they become noisy and ignored.
  • “Hashes alone are enough.” Metadata like signer and permissions provides additional context.
  • “Storing baselines on the same host is safe.” A compromised host can tamper with them.

Check-your-understanding questions

  • Why should baseline data be stored offline?
  • What fields beyond hashes are useful in a baseline?
  • How do you reduce false positives from software updates?

Check-your-understanding answers

  • Offline storage prevents a compromised system from rewriting the baseline.
  • Signer, file size, version, and permissions help identify suspicious changes.
  • Track patch IDs and update baselines only after verified changes.

Real-world applications

  • System integrity monitoring in regulated environments.
  • Golden image compliance validation for server fleets.

Where you’ll apply it You will apply this in Section 3.2 (Functional Requirements), Section 3.5 (Data Formats), and Section 6.2 (Critical Test Cases). Also used in: P03-integrity-baseline-builder, P08-boot-integrity-monitor, P20-rootkit-defense-toolkit.

References

  • NIST SP 800-94 (Guide to Intrusion Detection and Prevention Systems)
  • CIS Benchmarks - integrity monitoring guidance

Key insights A baseline turns invisible changes into measurable drift with accountability.

Summary Hash baselines detect tampering, but only if you store and update them correctly.

Homework/Exercises to practice the concept

  • Design a baseline schema for boot files and drivers.
  • Write a diff rule that labels changes as expected or suspicious.

Solutions to the homework/exercises

  • Your schema should include path, hash, signer, size, timestamp, and OS build.
  • A diff rule should check for missing patch IDs or unsigned new components.

Cross-View Detection and Independent Sources of Truth

Fundamentals Cross-view detection compares two or more independent perspectives of system state to detect manipulation. Rootkits hide by intercepting the interfaces your tools use. If you only rely on one view, a rootkit can lie to you consistently. Cross-view techniques break that illusion by comparing a user-space list to a raw kernel list, or a filesystem API to a raw disk scan, or a socket table to packet captures. Any mismatch is a signal that warrants investigation. Cross-view does not require certainty; it is about exposing contradictions.

Deep Dive into the concept Rootkits operate by tampering with enumerators. On Windows, a kernel rootkit might filter the list of processes returned by NtQuerySystemInformation. On Linux, it might hook getdents to hide files. On any platform, the API layer is a chokepoint. Cross-view detection exploits the fact that it is hard to perfectly falsify every independent source. If you compare the output of an OS API with raw memory scanning or direct disk reads, you can discover objects that exist but are hidden.

The challenge is that independent views are rarely perfectly aligned. Processes can exit between scans; files can be created and deleted; network connections can be short-lived. Cross-view detection therefore requires correlation logic. You must normalize identifiers (PIDs, inode numbers, connection 5-tuples), apply time windows, and handle transient artifacts. A well-designed cross-view tool uses tolerance thresholds and timestamps to reduce noise without ignoring real anomalies.

A strong cross-view strategy uses at least one view that is difficult for the rootkit to tamper with. For example, scanning raw memory structures or parsing raw disk blocks bypasses normal API hooks. Host-based monitoring (hypervisor introspection, external packet capture) provides another strong view. You can also use data from a different privilege domain, such as an EDR agent running with kernel access compared to a user-space tool. The key is to establish independence; otherwise you are comparing two views that are both compromised.

Cross-view detection is not a verdict; it is a lead. When you see a mismatch, you must investigate and validate. That may include additional scans, signature checks, baseline comparisons, or memory forensics. For defenders, the value is speed: cross-view techniques can rapidly surface anomalies in a large system without needing full reverse engineering. In rootkit defense, cross-view is your primary tactic for detecting stealth.

How this fit on projects You will apply this in Section 3.2 (Functional Requirements), Section 4.4 (Algorithm Overview), and Section 6.2 (Critical Test Cases). Also used in: P09-cross-view-process-audit, P10-cross-view-file-audit, P11-network-stealth-detection, P12-memory-forensics-triage.

Definitions & key terms

  • Cross-view: Comparing multiple independent sources of system state to detect inconsistencies.
  • Enumerator: An interface that lists system objects (processes, files, connections).
  • Independent view: A data source the rootkit cannot easily tamper with in the same way.
  • Correlation window: A time or state window used to match objects across views.

Mental model diagram

View A (OS API) --> [List A]
View B (Raw/External) --> [List B]
             |
             v
         [Diff Engine] --> [Anomalies]

How it works (step-by-step)

  1. Collect list A using standard OS APIs.
  2. Collect list B using raw memory/disk or external telemetry.
  3. Normalize identifiers and timestamps.
  4. Diff the lists and flag mismatches.
  5. Validate anomalies with additional checks or baselines.

Minimal concrete example

api_processes: [1234, 1240, 1302]
memscan_processes: [1234, 1240, 1302, 1310]
hidden_candidates: [1310]

Common misconceptions

  • “Cross-view results are definitive.” They are indicators that require validation.
  • “One extra view is always enough.” Independence matters more than quantity.
  • “False positives mean the method is useless.” They usually indicate poor correlation logic.

Check-your-understanding questions

  • Why is independence between views critical?
  • What is a common cause of false positives in cross-view diffing?
  • How do you validate a suspected hidden artifact?

Check-your-understanding answers

  • If both views share a compromised interface, the rootkit can lie consistently in both.
  • Timing differences or transient objects that appear in one view but not the other.
  • Use additional telemetry, memory analysis, or disk scans to corroborate.

Real-world applications

  • Hidden process detection in incident response.
  • Filesystem integrity scanning in compromised systems.

Where you’ll apply it You will apply this in Section 3.2 (Functional Requirements), Section 4.4 (Algorithm Overview), and Section 6.2 (Critical Test Cases). Also used in: P09-cross-view-process-audit, P10-cross-view-file-audit, P11-network-stealth-detection, P12-memory-forensics-triage.

References

  • The Art of Memory Forensics - cross-view process analysis
  • Rootkit detection research papers on cross-view diffing

Key insights Cross-view checks reveal lies by forcing a system to contradict itself.

Summary Compare independent sources of truth to expose hidden processes, files, or connections.

Homework/Exercises to practice the concept

  • Design a diff algorithm that tolerates short-lived processes.
  • List two truly independent views for file enumeration on your OS.

Solutions to the homework/exercises

  • Use time windows and PID reuse checks to avoid false positives.
  • Combine filesystem APIs with raw disk parsing or offline scans.

Memory Forensics and Volatile Triage

Fundamentals Memory forensics is the practice of analyzing a snapshot of system RAM to identify processes, drivers, and artifacts that may not appear in standard OS listings. Rootkits hide by modifying in-OS APIs, but memory captures provide a lower-level view of the system state at a specific time. A memory triage process uses tools like Volatility to quickly extract high-signal artifacts: process lists, kernel modules, suspicious hooks, and anomalous drivers. The goal is rapid assessment, not full reverse engineering.

Deep Dive into the concept Memory captures represent the entire address space of the system at a point in time. This includes kernel data structures, process objects, loaded drivers, and sometimes decrypted secrets. Rootkits can hide by manipulating linked lists or API outputs, but the memory image preserves raw structures that can be scanned independently. Tools like Volatility implement “scan” techniques that search for signatures of structures rather than trusting pointers. This is how you find hidden or unlinked processes.

A triage workflow begins with profile and symbol resolution. Without the correct symbol tables, you cannot interpret kernel structures. This is the most common failure point: mismatched OS build or missing symbols. Once symbols are correct, triage focuses on a minimal set of plugins: process listings (pslist, psscan), module listings (modules, modscan), driver verification, and hook detection. The idea is to compare list-based plugins with scan-based plugins to surface hidden objects.

Evidence integrity applies to memory captures too. Acquisition tools can alter memory, so you must document tool versions and capture methods. For Windows, you might use winpmem; for Linux, LiME; for macOS, specialized acquisition tools. Each has trade-offs in stability and completeness. The acquisition must be done as early as possible because memory is volatile. Once captured, the image should be hashed and stored off-host.

In rootkit defense, triage is about prioritization. If you find hidden processes, unsigned drivers, or kernel hooks, you have high-confidence signals of compromise. Your report should focus on those signals and tie them to response actions: containment, further analysis, or rebuild. Memory forensics is not just a technical exercise; it is a decision-support tool. The output must be structured so responders can act quickly.

How this fit on projects You will apply this in Section 3.7 (Real World Outcome), Section 6.2 (Critical Test Cases), and Section 7.2 (Debugging Strategies). Also used in: P12-memory-forensics-triage.

Definitions & key terms

  • Memory image: A capture of system RAM used for offline analysis.
  • pslist: Volatility plugin that walks OS process lists.
  • psscan: Volatility plugin that scans memory for process objects.
  • Symbol files: OS-specific metadata needed to interpret kernel structures.

Mental model diagram

[Live System RAM] --(acquisition)--> [Memory Image]
        |                                  |
        v                                  v
  [Volatility Plugins] --> [Findings] --> [Triage Report]

How it works (step-by-step)

  1. Acquire memory image and record tool version and hash.
  2. Select correct OS profile/symbols for the image.
  3. Run list-based and scan-based plugins.
  4. Compare results to identify hidden objects.
  5. Write a triage report with evidence and next steps.

Minimal concrete example

vol.py -f mem.raw windows.pslist
vol.py -f mem.raw windows.psscan
diff pslist.txt psscan.txt

Common misconceptions

  • “Memory analysis replaces disk forensics.” Memory is a snapshot; it complements disk analysis.
  • “Any profile works if it’s close.” Incorrect symbols can lead to false results.
  • “Triage means full analysis.” Triage is fast, focused, and decision-oriented.

Check-your-understanding questions

  • Why do you compare pslist and psscan outputs?
  • What is the risk of using the wrong symbol file?
  • Why is memory acquisition prioritized in the order of volatility?

Check-your-understanding answers

  • psscan can find hidden processes that are unlinked from OS lists.
  • Wrong symbols misinterpret structures, producing false positives or missing objects.
  • Memory state disappears quickly and is changed by other collection steps.

Real-world applications

  • Incident response triage for suspected kernel compromise.
  • Malware analysis of stealthy threats.

Where you’ll apply it You will apply this in Section 3.7 (Real World Outcome), Section 6.2 (Critical Test Cases), and Section 7.2 (Debugging Strategies). Also used in: P12-memory-forensics-triage.

References

  • The Art of Memory Forensics - acquisition and analysis chapters
  • Volatility 3 documentation

Key insights Memory forensics reveals what the OS tries to hide.

Summary Capture RAM early, use correct symbols, and compare list vs scan results.

Homework/Exercises to practice the concept

  • Acquire a memory image in a lab and verify its hash.
  • Run pslist and psscan and document differences.

Solutions to the homework/exercises

  • The hash should be recorded before analysis and stored with the image.
  • Any process that appears only in psscan deserves investigation.

3. Project Specification

3.1 What You Will Build

A tool or document that delivers: Integrate all checks into a single defense toolkit.

3.2 Functional Requirements

  1. Collect required system artifacts for the task.
  2. Normalize data and produce a report output.
  3. Provide a deterministic golden-path demo.
  4. Include explicit failure handling and exit codes.

3.3 Non-Functional Requirements

  • Performance: Complete within a typical maintenance window.
  • Reliability: Outputs must be deterministic and versioned.
  • Usability: Clear CLI output and documentation.

3.4 Example Usage / Output

$ ./P20-rootkit-defense-toolkit.py --report
[ok] report generated

3.5 Data Formats / Schemas / Protocols

Report JSON schema with fields: timestamp, host, findings, severity, remediation.

3.6 Edge Cases

  • Missing permissions or insufficient privileges.
  • Tooling not installed (e.g., missing sysctl or OS query tools).
  • Empty data sets (no drivers/modules found).

3.7 Real World Outcome

A deterministic report output stored in a case directory with hashes.

3.7.1 How to Run (Copy/Paste)

./P20-rootkit-defense-toolkit.py --out reports/P20-rootkit-defense-toolkit.json

3.7.2 Golden Path Demo (Deterministic)

  • Report file exists and includes findings with severity.

3.7.3 Failure Demo

$ ./P20-rootkit-defense-toolkit.py --out /readonly/report.json
[error] cannot write report file
exit code: 2

Exit Codes:

  • 0 success
  • 2 output error

4. Solution Architecture

4.1 High-Level Design

[Collector] -> [Analyzer] -> [Report]

4.2 Key Components

Component Responsibility Key Decisions
Collector Collects raw artifacts Prefer OS-native tools
Analyzer Normalizes and scores findings Deterministic rules
Reporter Outputs report JSON + Markdown

4.3 Data Structures (No Full Code)

finding = { id, description, severity, evidence, remediation }

4.4 Algorithm Overview

Key Algorithm: Normalize and Score

  1. Collect artifacts.
  2. Normalize fields.
  3. Apply scoring rules.
  4. Output report.

Complexity Analysis:

  • Time: O(n) for n artifacts.
  • Space: O(n) for report.

5. Implementation Guide

5.1 Development Environment Setup

python3 -m venv .venv && source .venv/bin/activate
# install OS-specific tools as needed

5.2 Project Structure

project/
|-- src/
|   `-- main.py
|-- reports/
`-- README.md

5.3 The Core Question You’re Answering

“How do you operationalize rootkit defense into a repeatable process?”

This project turns theory into a repeatable, auditable workflow.

5.4 Concepts You Must Understand First

  • Relevant OS security controls
  • Detection workflows
  • Evidence handling

5.5 Questions to Guide Your Design

  1. What data sources are trusted for this task?
  2. How will you normalize differences across OS versions?
  3. What is a high-confidence signal vs noise?

5.6 Thinking Exercise

Sketch a pipeline from data collection to report output.

5.7 The Interview Questions They’ll Ask

  1. What is the main trust boundary in this project?
  2. How do you validate findings?
  3. What would you automate in production?

5.8 Hints in Layers

Hint 1: Start with a small, deterministic dataset.

Hint 2: Normalize output fields early.

Hint 3: Add a failure path with clear exit codes.

5.9 Books That Will Help

Topic Book Chapter
Rootkit defense Practical Malware Analysis Rootkit chapters
OS internals Operating Systems: Three Easy Pieces Processes and files

5.10 Implementation Phases

Phase 1: Data Collection (3-4 days)

Goals: Collect raw artifacts reliably.

Tasks:

  1. Identify OS-native tools.
  2. Capture sample data.

Checkpoint: Raw dataset stored.

Phase 2: Analysis & Reporting (4-5 days)

Goals: Normalize and score findings.

Tasks:

  1. Build analyzer.
  2. Generate report.

Checkpoint: Deterministic report generated.

Phase 3: Validation (2-3 days)

Goals: Validate rules and handle edge cases.

Tasks:

  1. Add failure tests.
  2. Document runbook.

Checkpoint: Failure cases documented.

5.11 Key Implementation Decisions

Decision Options Recommendation Rationale
Report format JSON, CSV JSON Structured and diffable
Scoring Simple, Weighted Weighted Prioritize high risk findings

6. Testing Strategy

6.1 Test Categories

Category Purpose Examples
Unit Tests Parser logic Sample data parsing
Integration Tests End-to-end run Generate report
Edge Case Tests Missing permissions Error path

6.2 Critical Test Cases

  1. Report generated with deterministic ordering.
  2. Exit code indicates failure on invalid output path.
  3. At least one high-risk finding is flagged in test data.

6.3 Test Data

Provide a small fixture file with one known suspicious artifact.

7. Common Pitfalls & Debugging

7.1 Frequent Mistakes

Pitfall Symptom Solution
Noisy results Too many alerts Add normalization and thresholds
Missing permissions Script fails Detect and warn early

7.2 Debugging Strategies

  • Log raw inputs before normalization.
  • Add verbose mode to show rule evaluation.

7.3 Performance Traps

Scanning large datasets without filtering can be slow; restrict scope to critical paths.

8. Extensions & Challenges

8.1 Beginner Extensions

  • Add a Markdown summary report.

8.2 Intermediate Extensions

  • Add a JSON schema validator for output.

8.3 Advanced Extensions

  • Integrate with a SIEM or ticketing system.

9. Real-World Connections

9.1 Industry Applications

  • Security operations audits and detection validation.
  • osquery - endpoint inventory

9.3 Interview Relevance

  • Discussing detection workflows and auditability.

10. Resources

10.1 Essential Reading

  • Practical Malware Analysis - rootkit detection chapters

10.2 Video Resources

  • Conference talks on rootkit detection

10.3 Tools & Documentation

  • OS-native logging and audit tools

11. Self-Assessment Checklist

11.1 Understanding

  • I can describe the trust boundary for this task.

11.2 Implementation

  • Report generation is deterministic.

11.3 Growth

  • I can explain how to operationalize this check.

12. Submission / Completion Criteria

Minimum Viable Completion:

  • Report created and contains at least one finding.

Full Completion:

  • Findings are categorized with remediation guidance.

Excellence (Going Above & Beyond):

  • Integrated into a broader toolkit or pipeline.