security: sign and verify Windows release artifacts; validate managed-policy deployment

[rblake2320]

Corrected scope

SelfConnect's Windows distributables do not yet have a production code-signing identity and the release workflow does not yet produce signed-and-verified MSI/MSIX/EXE artifacts. That can reduce publisher trust and can conflict with an organization's App Control for Business, AppLocker, Smart App Control, or procurement policy, depending on the actual deployed rules.

The earlier issue text was too broad:

• EV certificates no longer receive an automatic first-download SmartScreen bypass. Microsoft removed that behavior in 2024; OV, EV, and Azure Artifact Signing all still build reputation for new file hashes.
• AppLocker script rules cover .ps1, .bat, .cmd, .vbs, and .js. They do not make Authenticode-signing every Python .py source file the deployment solution.
• A DoD Impact Level, ATO, or managed-enterprise deployment does not create one universal requirement that can be proven solely by buying a certificate. The Authorizing Official and endpoint policy determine the accepted signer, package, path, hash, managed-installer, or allowlist rules.

Official references:

• https://learn.microsoft.com/windows/apps/package-and-deploy/smartscreen-reputation
• https://learn.microsoft.com/windows/apps/package-and-deploy/code-signing-options
• https://learn.microsoft.com/windows/security/application-security/application-control/app-control-for-business/applocker/script-rules-in-applocker
• https://learn.microsoft.com/windows/security/application-security/application-control/app-control-for-business/deployment/use-code-signing-for-better-control-and-protection

Engineering work that can be completed before certificate procurement

• Add a release signing stage for MSI/MSIX/EXE/PowerShell artifacts using SignTool or Azure Artifact Signing.
• Make release signing fail closed when an official release is requested but signer configuration, timestamping, or post-sign verification is absent.
• Verify every signed artifact with SignTool and record certificate subject, thumbprint, timestamp authority, digest, artifact SHA-256, workflow run, and source commit without exposing signing credentials.
• Publish wheel hashes and a verifiable build attestation/provenance record. Do not describe that as Authenticode signing of .py files.
• Document key custody, signer rotation/revocation, emergency release, timestamping, reproducible build limits, and rollback.
• Add unsigned-development versus signed-release modes so local development is not represented as release evidence.
• Add a controlled WDAC/AppLocker validation run against the intended package and policy. Record the exact policy XML/binary, Windows build, enforcement mode, signer rule, allow/deny events, and install/launch result.

Owner/external action

Choose an accepted signing route:

• Azure Artifact Signing (Microsoft's current recommended non-Store option where eligible), or
• an OV/EV certificate from an accepted CA, or
• Microsoft Store signing if that distribution path is appropriate.

Certificate/service enrollment and identity validation require the repository owner or organization. EV may still have procurement value, but it must not be justified as an instant SmartScreen bypass.

Closure evidence

Close only when:

1. The release pipeline signs and verifies every intended Windows distributable.
2. Signing keys are not exportable into repository or ordinary CI logs.
3. Timestamp and revocation behavior are tested.
4. A clean-machine install/launch is verified.
5. At least one representative enforced WDAC/AppLocker policy accepts the signed release and rejects the unsigned control artifact.
6. Public documentation states exactly what was tested and does not imply a DoD authorization, universal AV compatibility, or guaranteed SmartScreen reputation.