CheatEngine.SDK is a Windows x64 SDK for Cheat Engine 7.7 plugins: a NuGet package with managed libraries, Roslyn analyzers and generators, MSBuild assets and a native protection bridge. This page says which versions receive security fixes, how to report a vulnerability privately, and how to check that a package came from this repository.

When a new release line ships, the previous line stops receiving fixes; the table is updated in the same pull request.

Report vulnerabilities privately through GitHub private vulnerability reporting: https://github.com/CheatEngineNet/CheatEngine.SDK/security/advisories/new.

Never report a vulnerability in a public issue, discussion or pull request.

A report can be triaged fastest when it identifies the exact combination that was run:

• the CheatEngine.SDK version and its contentHash, both read from the plugin's packages.lock.json (never recomputed);
• the SHA-256 of cheatengine-sdk-lua-bridge.dll in the plugin output folder;
• the Cheat Engine build (for example 7.7.0.10621) and the SHA-256 of the executable you started, usually cheatengine-x86_64.exe;
• the plugin load profile (managed plugin through hostfxr, historical CLR loader, or Native AOT) and the SHA-256 of ce.runtimeconfig.json when the managed route is used;
• the Windows version and the output of dotnet --info;
• the impact (what an attacker controls and what they gain) and a minimal reproduction.

Hashes can be read with PowerShell, for example Get-FileHash -Algorithm SHA256 "$env:ProgramFiles\Cheat Engine\cheatengine-x86_64.exe". Remove user names and private paths from logs. Never attach Cheat Engine binaries, target binaries or raw debugger dumps; describe them by name, version and hash instead.

In scope:

• the CheatEngine.SDK package: its libraries, analyzers, source generators, MSBuild build assets and the bundled native protection bridge cheatengine-sdk-lua-bridge.dll;
• the bridge sources under native/cheatengine-sdk-lua-bridge;
• this repository's build, test and release workflows, including the provenance of published packages.

Out of scope:

• vulnerabilities in Cheat Engine itself: report them upstream at https://github.com/cheat-engine/cheat-engine;
• vulnerabilities in CheatEngine.Client: report them at https://github.com/CheatEngineNet/CheatEngine.Client/security/advisories/new;
• use of Cheat Engine or of a plugin against software or processes you are not authorized to inspect or modify.

• An acknowledgement within 7 days and a triage decision within 14 days, on a best-effort basis: the project has a single active maintainer.
• Fixes are coordinated through a GitHub Security Advisory on this repository, which credits the reporter unless they ask otherwise.
• A fix ships as a new package version with a Security entry in CHANGELOG.md. The advisory is published once the fixed package is available on nuget.org.

Packages are built, tested, packed and published by the release.yml workflow of this repository from a version tag, through NuGet trusted publishing (no long-lived API key), and the published package gets a GitHub build provenance attestation. RELEASING.md describes the process.

A package therefore has two files with different hashes:

• the package attached to the GitHub release, which is the attested file: gh attestation verify CheatEngine.SDK.<version>.nupkg --repo CheatEngineNet/CheatEngine.SDK;
• the package served by nuget.org, which nuget.org re-signs with its repository signature, so its SHA-256 differs from the GitHub asset: dotnet nuget verify --all CheatEngine.SDK.<version>.nupkg.

The contentHash that NuGet writes into a consumer's packages.lock.json is computed without the repository signature, so it identifies the package content independently of where it was downloaded.

Two binaries are committed on purpose; everything else is built from source.

OpenSSF Scorecard's two Binary-Artifacts findings are accepted project exceptions. Keeping the exact Lua fixture preserves production behavior in tests; keeping the verified bridge supports local builds and package creation from a clean checkout. Neither finding is dismissed as a false positive. The checks described below remain mandatory.

• native/cheat-engine/lua53-64.dll is the unmodified 64-bit Lua library of a Cheat Engine 7.7 installation, SHA-256 C95DCDFA0F60F97B43D970D77FD1BB907AF4DE04B500A3C89A99600B20B35BD2 (its README). Tests and benchmarks bind it so that they exercise the Lua a plugin binds in production; it is never packed.
• native/cheatengine-sdk-lua-bridge/runtimes/win-x64/native/cheatengine-sdk-lua-bridge.dll is the native protection bridge that the package ships. CI builds it once from its C source and xmake.lua with the pinned toolchain and supplies that build to downstream tests and packaging. CI checks the committed DLL's exported source fingerprint; package tests check its committed hash, PE shape, imports and exports against the audit manifest. The workflow does not compare independent rebuilds or schedule release rebuilds. A source fingerprint does not prove that a DLL's executable bytes came from those sources: trusting the committed asset and its manifest remains an accepted risk for local builds.

CI / Gate is required on main, including checks against the latest base branch, with no bypass actors. The current single-maintainer workflow does not require independent human or code-owner approval: doing so would block merges without another active reviewer. The Code-Review finding records real historical approvals and cannot be repaired by changing past commits or by treating automated reviews as human review.

The required check is bound to the GitHub Actions integration, not to an immutable workflow. A collaborator who can change the repository's CI workflows can change the check's behavior in the same pull request. Without independent review or an organization-managed required workflow, the rule protects against failed or missing CI but does not protect against a malicious maintainer changing CI itself.

The repository uses FsCheck generated-input tests for the Engine API spec parser in its normal CI suites. This is bounded property-based fuzz testing, not continuous coverage-guided fuzzing of the complete SDK or native bridge.

The project has not enrolled in the OpenSSF Best Practices badge program. The CII-Best-Practices finding remains open until a maintainer registers the project and supplies accurate, evidence-backed answers to the program's criteria; the Scorecard badge in the README is a different program.