Documentation

Packaging & Verification

Catalog apps are packaged from a public WinGet manifest by a pinned, repeatable pipeline. Custom apps are packaged from an installer URL you provide. This page describes each step and how to verify a package without taking our word for it.

How a package is built

text|package pipeline

1. Resolve   Read the WinGet manifest from microsoft/winget-pkgs for the app and version.
2. Download  Fetch the installer from the manifest URL.
3. Verify    Compare the installer SHA-256 against the manifest. Mismatch fails the build.
4. Wrap      Generate a PSADT 4.1.8 package (commands, detection, dialogs).
5. Package   Build the .intunewin with the Microsoft Win32 Content Prep Tool.
6. Upload    Create the Win32 app in your Intune tenant and upload the content.

In hosted mode, the packaging step runs in an ephemeral runner, and the installer and built package exist only for the duration of the job. In local mode (PACKAGER_MODE=local), packaging runs on your own Windows machine, so the installer and the built package reside there under your control.

What is pinned

Installers

Downloaded from the WinGet community manifest and copied byte-for-byte. Never modified, never re-signed.

Installer hash

SHA-256 verified against the manifest before packaging (strict mode). A mismatch fails the build.

PSADT

Version 4.1.8, downloaded from a pinned URL and verified against a pinned SHA-256.

Win32 Content Prep Tool

Microsoft IntuneWinAppUtil, downloaded from a pinned URL and verified against a pinned SHA-256.

Packaging scripts

The public IntuneGet packaging scripts, checked out at a reviewed commit that is recorded for each build.

Verify a package yourself

On the app page. Each app shows the installer source, the installer SHA-256, the PSADT version, the packaging commit, and the tested package profile.
In the QA report. The per-version report records the outcome, install and uninstall phases, detection, captured commands, and the VirusTotal result for the installer hash.
Against the manifest. Open the app in the WinGet manifest and compare the recorded SHA-256 with the one shown on the app page.
By running it yourself. Clone the repository and self-host to run the same pipeline with your own app registration.

Browse the app catalog Self-host with Docker

Source of truth

Catalog data comes from the WinGet community manifests at microsoft/winget-pkgs. The manifests, including their SHA-256 values, are public and can be checked against any package.

Limits to know about

The hosted packaging workflow runs in a private repository to keep tenant identifiers out of public workflow runs. The packaging scripts themselves are open source and used for every build.
For catalog apps, a mismatch between the manifest hash and the downloaded file fails the build rather than shipping a package. Custom apps have no manifest hash; IntuneGet calculates the SHA-256 from the installer you provide.
WinGet is a community source. If that risk profile does not fit your organization, self-host and point IntuneGet at your own catalog.

See the full permission list and data flow on the security page. Open the security page