WAIT — Single-maintainer risk — review before adopting

• Last commit 1d ago
• 4 active contributors
• MIT licensed
• CI configured
• ⚠ Small team — 4 contributors active in recent commits
• ⚠ Single-maintainer risk — top contributor 92% of recent commits
• ⚠ No test directory detected

_{Computed from maintenance signals — commit recency, contributor breadth, bus factor, license, CI, tests}

Harden Windows Security is a security hardening toolkit that automates Windows system hardening using only official Microsoft-supported methods (Group Policy, Windows Defender, DISM, BitLocker, etc.). It provides the Harden System Security app (C# WinUI3), AppControl Manager (Rust with C# interop for Application Guard policy management), and security configuration guides for Personal, Enterprise, Government, and Military threat levels. Core capability: apply battle-tested security baselines without proprietary tools or risky registry hacks. Monorepo structure with two primary applications: AppControl Manager (Rust workspace in AppControl Manager/ with eXclude/ subdirectories for modules like exploit_mitigations, ResourceValidator, group_policy) and Harden System Security (C# WinUI3 app, likely in root). Rust interop library bridges Rust backends to C# UI. Animated icon sources (Lottie JSON in Animated Icon Sources/) suggest modern XAML Islands integration.

Windows system administrators and security engineers who need to harden Windows 10/11 systems to meet compliance requirements (DoD, NIST, CIS benchmarks) while maintaining Microsoft support. Also appeals to security-conscious enterprises and government organizations seeking auditable, reproducible hardening via official channels rather than third-party security suites.

Production-ready with active ongoing development. The repo shows substantial C# codebase (8.2M LOC), published on Microsoft Store (9P7GGFL7DX57 for Harden System Security, 9PNG1JDDTGP8 for AppControl Manager), SLSA Level 3 compliance for secure builds, and comprehensive CI/CD workflows (CodeQL, Dependabot, VirusTotal scanning). Commits are recent and the project maintains strict security update cadence.

Low operational risk because it exclusively uses Microsoft's official APIs and Group Policy rather than modifying core system files. However, applying aggressive hardening policies can break line-of-business applications if not tested first—the tool requires expertise to customize per environment. Single maintainer (Violet Hansen) is a potential long-term sustainability concern; dependency surface is well-managed via Dependabot auto-merging.

Active development on AppControl Manager (Rust rewrite of policy tooling) and Microsoft Store deployments. GitHub workflows show recent work on MSIX packaging for Store distribution, automated security scanning (Dependabot, CodeQL, VirusTotal), and syncing to Azure DevOps. The copilot-instructions and ai-moderator workflows suggest automation of PR review and issue triage.

Clone and build: git clone https://github.com/HotCakeX/Harden-Windows-Security.git && cd Harden-Windows-Security. For C# projects, open in Visual Studio 2022+ with .NET 9 SDK. For Rust components (AppControl Manager), run cargo build --release in the AppControl Manager directory (note: workspace uses edition 2024, Rust 1.94+). MSIX packages are built via GitHub Actions workflows; local builds may require Windows SDK tools.

Daily commands: For the packaged apps: download from Microsoft Store (links in README). For local dev: Visual Studio → open .sln file → F5 to debug. For Rust: cd 'AppControl Manager' && cargo run --release (respects .cargo/config.toml workspace settings). Apps require Windows 10 21H2+ and Administrator privileges to apply policies.

• .github/CONTRIBUTING.md — Defines contribution guidelines and code standards that all contributors must follow to maintain security and consistency.
• .github/copilot-instructions.md — AI-assisted development guidelines ensuring consistent implementation patterns across the codebase.
• AppControl Manager/AppControl Manager.csproj — Primary project configuration defining dependencies, build targets, and platform requirements for the main application.
• AppControl Manager/App.xaml.cs — Application entry point and core initialization logic for the WPF AppControl Manager application.
• AppControl Manager/App.xaml — XAML application resources and root configuration for UI styling and dependency injection setup.
• .github/workflows/CodeQL Advanced - Quality.yml — Automated security scanning workflow required to maintain SLSA Level 3 compliance and detect vulnerabilities.
• .github/dependabot.yml — Dependency management configuration ensuring all external packages are automatically tracked and updated securely.

Add a New Security Hardening Control

1. Create a new C# analysis class in AppControl Manager/Analysis/ folder following FileIdentityAnalysis.cs pattern with validation logic (AppControl Manager/Analysis/FileIdentityAnalysis.cs)
2. Add UI components in App.xaml to expose the control in the user interface with proper XAML bindings (AppControl Manager/App.xaml)
3. Update App.xaml.cs or App.xaml_ACM.cs to wire up event handlers and control initialization (AppControl Manager/App.xaml.cs)
4. Create corresponding Rust interop binding if native Windows API calls are required via the Rust Interop Library workspace member (AppControl Manager/.cargo/config.toml)
5. Document the control in contributing guidelines and add tests via the appropriate workflow (.github/CONTRIBUTING.md)

Add Localization for a New Language

1. Add country flag image to Assets/CountryFlags/ folder following 240px or 96px naming convention (AppControl Manager/Assets/CountryFlags)
2. Update App.xaml with new language resource definitions and culture-specific strings (AppControl Manager/App.xaml)
3. Register language in App.xaml.cs initialization to enable runtime language switching (AppControl Manager/App.xaml.cs)
4. Submit PR with language files and ensure CodeQL quality checks pass (.github/workflows/CodeQL Advanced - Quality.yml)

Add a New Automated Security Check to CI/CD

1. Create new GitHub Actions workflow file in .github/workflows/ directory following existing Store build workflow naming conventions (.github/workflows/Build AppControl Manager for Store.yml)
2. Integrate with Dependabot configuration if checking dependencies, or CodeQL if analyzing code quality (.github/workflows/CodeQL Advanced - Quality.yml)
3. Reference the workflow in ai-moderator.yml or create separate trigger in workflow file (.github/workflows/ai-moderator.yml)
4. Update CONTRIBUTING.md to document the new automated check for developers (.github/CONTRIBUTING.md)

Implement a New Rust Interop Component

1. Create Rust crate in eXclude/ workspace member (e.g., exploit_mitigations, ResourceValidator, dism_capabilities, group_policy patterns) (AppControl Manager/.cargo/config.toml)
2. Configure Cargo.toml for the new crate following workspace.package settings with edition 2024 and MIT license (.github/FUNDING.yml)
3. Implement C# P/Invoke bindings in AppControl Manager to call the Rust FFI exports (AppControl Manager/App.xaml.cs)
4. Add automated testing in build workflow and ensure Virus Total scanning passes (.github/workflows/Repository And Package Scan on Virus Total.yml)

• C# / WPF — Native Windows desktop UI framework enabling direct Windows API integration for AppControl Manager with rich XAML-based UI and strong type safety.
• Rust (FFI Interop) — Memory-safe systems language for Windows API wrapper library (exploit_mitigations, ResourceValidator, DISM, Group Policy) with zero-cost abstractions and security hardening primitives.
• GitHub Actions + Dependabot — Declarative CI/CD enabling SLSA Level 3 compliance, automated dependency updates, and secure build reproducibility across MSIX and Store distributions.
• XAML / WinUI — Declarative UI definition enabling localization, accessibility, and modern fluent design system integration for multi-language support.
• MSIX Packaging — Containerized Windows application packaging for Store distribution with automatic updates, version management, and security sandbox isolation.

• Mixed C#/Rust codebase with FFI boundaries

  • Why: Enables safe Windows system-level operations while maintaining managed code safety and developer ergonomics in UI layer.
  • Consequence: Adds marshalling overhead (~5-10% perf) and requires careful memory lifetime management at FFI boundaries; mitigated by isolating interop to Analysis layer.

• SLSA Level 3 compliance with reproducible builds

  • Why: Ensures provenance and supply chain security for users downloading from Microsoft Store.
  • Consequence: Requires strict build environment isolation, signed commits, and reproducible codegen-units=1; adds ~30% build time overhead.

• Official Microsoft APIs only (no undocumented/internal APIs)

  • Why: Guarantees long-term compatibility and support as Windows evolves.
  • Consequence: Cannot use cutting-edge internal security features; limited to public APIs which may lag threat landscape.

• Multi-distribution (MSIX + Store vs. GitHub releases)

  • Why: Maximizes reach to enterprise (MSIX) and consumer (Store) users with automatic updates.
  • Consequence: Requires parallel build pipelines and Store certification delays (~24-48h) delaying emergency security patches.

• Linux or macOS support; Windows

Windows-only development: Rust and C# projects require Windows 10 21H2+ build environment (MSIX SDK, Windows App SDK). Code signing required for Store deployment: relies on GitHub secrets (code signing cert) not in repo. Rust workspace resolver = "3" and edition = "2024" require bleeding-edge Rust toolchain (1.94+); older versions will fail silently. Policy application is immediate and global; test in VM first—no rollback mechanism for aggressive hardening. Group Policy changes may require reboot; script must document this. Interop between C# and Rust has marshal/pinvoke boundaries; breaking changes in FileIdentityAnalysis.cs will crash the app.

• Application Guard (AppControl) Policy — The core output of AppControl Manager is signed XML policy documents that enforce executable whitelisting via kernel integrity checks; understanding AppControl is essential to contribute to policy generation
• Group Policy Objects (GPO) / ADMX Templates — The C# app applies hardening via Group Policy instead of registry hacks; GPO is the Microsoft-supported mechanism for scalable policy delivery across enterprises
• Windows Defender Application Control (WDAC) / UMCI (User-Mode Code Integrity) — Kernel-level code integrity mechanism that AppControl policies enforce; understanding UMCI is critical for the binary analysis and policy validation logic
• MSIX Package Format — Both apps are distributed as MSIX (Microsoft Store package format) via automated GitHub Actions workflows; contributors need to understand MSIX signing and manifest schema
• Cryptographic Hash Functions (SHA-256, SHA-384 for file signing) — AppControl policies rely on file hashes for executable whitelisting; FileIdentityAnalysis.cs likely computes and validates hashes for policy generation
• C#/Rust FFI (Foreign Function Interface) and P/Invoke — The Rust Interop Library bridges Rust backend (fast binary analysis) to C# WinUI3 frontend (user interaction); understanding marshaling and lifetime semantics prevents memory safety bugs
• SLSA Framework (Supply Chain Levels for Software Artifacts) — The repo is SLSA Level 3 compliant; contributors must maintain verifiable build provenance, signed artifacts, and reproducible builds via GitHub Actions

• microsoft/windows-itpro-docs — Official Microsoft Windows hardening documentation and Group Policy reference—the policy specifications this tool implements come from here
• nsacyber/Configuration-Management-Analysis-Project — NSA/CISA open-source hardening guidance and baselines; alternative policy source this project aligns with
• MicrosoftDocs/windows-dev-docs — WinUI3, Windows App SDK, and Windows.Security namespace documentation required to understand the C# app layer
• microsoft/AppControl-SecurityPolicies — Microsoft's official AppControl and Device Guard policy templates; AppControl Manager is a UI for building these

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive unit tests for AppControl Manager Analysis module (FileIdentityAnalysis.cs)

The AppControl Manager/Analysis/FileIdentityAnalysis.cs file exists but has no corresponding test file visible in the repo structure. Given this is a security-hardening tool dealing with file identity analysis (critical for AppControl policies), comprehensive unit tests would ensure the analysis logic is reliable and prevent regressions. This aligns with the SLSA Level 3 compliance goal mentioned in the repo description.

• [ ] Create AppControl Manager/Analysis.Tests/ directory structure
• [ ] Write unit tests for FileIdentityAnalysis.cs covering hash validation, certificate parsing, and edge cases
• [ ] Add test cases for malformed/invalid file inputs to ensure security robustness
• [ ] Integrate tests into the existing CI/CD workflows (reference: .github/workflows/CodeQL Advanced - Quality.yml)

Create GitHub Action workflow for automated Rust workspace build and testing (eXclude modules)

The repo has multiple Rust workspace members (exploit_mitigations, ResourceValidator, dism_capabilities, group_policy) defined in Cargo.toml with Rust 1.94 requirements, but no dedicated Rust CI workflow is visible in .github/workflows/. Currently only C# workflows and security scans exist. A Rust-specific workflow would ensure cross-platform compilation, clippy linting, and test coverage for these critical security modules.

• [ ] Create .github/workflows/Rust-Workspace-Build-Test.yml with matrix for Windows/Linux targets
• [ ] Add steps for cargo build, cargo test, and cargo clippy (with security lint rules)
• [ ] Configure to validate against the pinned rust-version = 1.94 in workspace config
• [ ] Ensure it runs on PR creation and commits to main (reference existing workflow patterns in codeql.yml)

Document security hardening mappings for AppControl Manager features with specific policy files

The repo emphasizes 'Official Supported Microsoft methods' and provides 'Personal, Enterprise, Government and Military security levels' but the file structure shows limited documentation mapping. AppControl Manager has 40+ animated icon sources suggesting multiple features, but no accompanying .md file explains which features correspond to which CIS Benchmarks, DISA STIGs, or Microsoft security baselines.

• [ ] Create docs/AppControl-Manager-Security-Mappings.md documenting each feature to official Microsoft/CIS/DISA standards
• [ ] Map each policy type (supplemental policies, base policies) to government/enterprise/personal use cases
• [ ] Cross-reference with existing PowerShell hardening scripts in the repo to show integration points
• [ ] Add this documentation link to README.md and .github/CONTRIBUTING.md for contributor guidance

• Add unit tests for FileIdentityAnalysis.rs: Analysis module has no visible test coverage in the file list; contribute tests for binary signature validation and hash computation
• Expand animated icon sources: 22 Lottie JSON icons in Animated Icon Sources/ are static; add accessibility labels and semantic naming (currently Blueprint.json, etc. lack descriptions) via a JSON schema + validator
• Document Rust interop boundary contract: Create a BINDING_SPEC.md explaining C# ↔ Rust marshaling rules, pointer lifetime semantics, and versioning strategy to reduce future interop bugs

The Harden-Windows-Security codebase demonstrates a strong security posture overall. No critical vulnerabilities were identified in the provided analysis scope. The project follows security best practices with SLSA Level 3 compliance, CodeQL scanning, dependency review, and VirusTotal scanning in CI/CD pipelines. Minor concerns include: (1) use of a non-existent Rust edition that should be corrected, (2) aggressive binary stripping that could complicate incident response, and (3) build configuration optimizations that may impact developer velocity. The presence of security-focused workflows, proper CODEOWNERS configuration, and security suggestion issue templates indicates mature security practices. No hardcoded secrets, injection vulnerabilities, or obvious misconfigurations were detected in the provided file structure.

• Low · Rust Edition Specification Uses Future Version — Cargo.toml - [workspace.package] section. The Cargo.toml workspace configuration specifies 'edition = "2024"', which does not exist yet. Rust editions are released every 2 years (2015, 2018, 2021). Using a non-existent edition could cause build failures or unexpected behavior in different environments. Fix: Update to a valid Rust edition (e.g., '2021' or '2015'). Verify with official Rust documentation for the latest stable edition.
• Low · Debug Information Stripping in Release Build — Cargo.toml - [profile.release] section. The release profile is configured with 'strip = "symbols"' which removes debug symbols. While this reduces binary size, it may complicate security incident response and debugging of production issues. Fix: Consider keeping debug symbols in a separate debug build or use 'split-debuginfo = "packed"' (already set) to maintain debuggability. For security-sensitive applications, ensure crash reports and monitoring can function without symbols.
• Low · LTO and Single Codegen Unit May Impact Build Performance — Cargo.toml - [profile.release] section. Configuration uses 'lto = "fat"' and 'codegen-units = 1' which significantly increase compilation time. This could impact CI/CD pipeline efficiency and developer experience. Fix: Consider using 'lto = "thin"' for faster builds while maintaining most optimizations, or make this configurable based on build context.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/HotCakeX/Harden-Windows-Security shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live HotCakeX/Harden-Windows-Security repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/HotCakeX/Harden-Windows-Security.

What it runs against: a local clone of HotCakeX/Harden-Windows-Security — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in HotCakeX/Harden-Windows-Security | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 31 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of HotCakeX/Harden-Windows-Security. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/HotCakeX/Harden-Windows-Security.git
#   cd Harden-Windows-Security
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of HotCakeX/Harden-Windows-Security and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "HotCakeX/Harden-Windows-Security(\\.git)?\\b" \\
  && ok "origin remote is HotCakeX/Harden-Windows-Security" \\
  || miss "origin remote is not HotCakeX/Harden-Windows-Security (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 4. Critical files exist
test -f ".github/CONTRIBUTING.md" \\
  && ok ".github/CONTRIBUTING.md" \\
  || miss "missing critical file: .github/CONTRIBUTING.md"
test -f ".github/copilot-instructions.md" \\
  && ok ".github/copilot-instructions.md" \\
  || miss "missing critical file: .github/copilot-instructions.md"
test -f "AppControl Manager/AppControl Manager.csproj" \\
  && ok "AppControl Manager/AppControl Manager.csproj" \\
  || miss "missing critical file: AppControl Manager/AppControl Manager.csproj"
test -f "AppControl Manager/App.xaml.cs" \\
  && ok "AppControl Manager/App.xaml.cs" \\
  || miss "missing critical file: AppControl Manager/App.xaml.cs"
test -f "AppControl Manager/App.xaml" \\
  && ok "AppControl Manager/App.xaml" \\
  || miss "missing critical file: AppControl Manager/App.xaml"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 31 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~1d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/HotCakeX/Harden-Windows-Security"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.