Scan EXE, MSI, APK and IPA App Binaries with Safeguard

To scan an EXE, MSI, APK or IPA when you do not have the source, upload the compiled file and let a binary analyser unpack it, identify the libraries embedded inside, work out their versions and match them against known vulnerabilities and licenses. The output is a software bill of materials (SBOM) for the thing you actually ship or install, not for the repository you hope it was built from. In Safeguard this is a file upload from the Integrations page: click Connect on the Upload App Binary card, name the project and version, drop the file, and the result appears as a project with dependencies, vulnerabilities and licenses.

This post covers why binaries need their own scan, what the standards ask of you, what lives inside each format, a binary intake process you can run with any tool, and then the exact Safeguard flow as its docs describe it, with the limits stated plainly.

Key takeaways

• A binary scan answers a different question from a source scan: what is in the artifact that ships, including vendored, statically bundled and SDK code that never appears in a manifest.
• NIST SP 800-218 (SSDF), NIST SP 800-161 Rev. 1, CISA's 2026 Minimum Elements for an SBOM, OWASP Top 10 2025 A03 and OWASP MASVS-CODE-3 all expect you to know the components in software you build or buy. A binary scan is often the only way to get that list for third party and legacy software.
• Safeguard's Upload App Binary integration (GA) uploads and scans an app binary: a Windows EXE, MSI or DLL, an Android APK or an iOS IPA.
• SBOM generation and analysis (GA), SCA and vulnerability management (GA) and license compliance (GA) then work on the uploaded binary the same way they work on a repository.
• Policies, gates and guardrails (GA) can act on the result. Gate actions are Block, Warn and Notify; approval runs through exceptions.
• Uploads go through the web console. The Safeguard CLI (GA) does not upload binaries to the platform; its docs point to safeguard analyze for local analysis only. The documented /v1 upload API is not available yet.
• Heavily obfuscated, encrypted or unusually compressed binaries can produce incomplete results. A statically linked binary may show few or no dependencies.

Why scan a binary at all

Most software composition analysis starts from source: a lockfile, a pom.xml, a go.sum. That works when you own the repository and the build. It stops working in four common situations.

You did not build it. A vendor ships you an MSI for a desktop agent, a line of business tool or a device management client. You will never see their repository. The installer is the only thing you can inspect, and it is also the thing that runs on your fleet.

The build adds things the manifest does not list. Mobile apps are the clearest case. An Android release build pulls in Gradle dependencies, but it also carries native .so libraries for each processor architecture, and third party SDKs for analytics, crash reporting and advertising that arrive as prebuilt artifacts. An iOS app embeds frameworks that can come from CocoaPods, Swift Package Manager or a vendor's zip file. Windows applications often ship a folder of DLLs that were copied in by hand years ago.

The source and the artifact drift apart. Release builds differ from debug builds. Build flavors differ from one another. A hotfix built on someone's laptop differs from the one in CI. If you only scan source, you are trusting that the artifact matches it. Safeguard's own docs list "verifying shipped binaries match source" as one of the reasons to run binary analysis.

The software is old. Legacy applications outlive their build systems. The manifest may be gone, the build server decommissioned, the original team moved on. The binary is still in production.

In all four cases the honest inventory is the one taken from the artifact. That is what binary composition analysis does, and it is why it sits alongside source scanning rather than replacing it. For the general method, see what binary composition analysis is and binary analysis for supply chain verification.

What the standards expect

None of the documents below says "scan your binaries". They do say you must know what components are in the software you produce or acquire, track their vulnerabilities and share that information. For software you cannot see the source of, a binary scan is how you meet that expectation. This section summarises the documents; it is not legal or audit advice.

NIST SP 800-218, the Secure Software Development Framework

NIST published SP 800-218 in February 2022. Its abstract describes a core set of secure development practices that help producers reduce vulnerabilities in released software, and notes that purchasers can use the same vocabulary when they talk to suppliers during acquisition. Two tasks matter most here. PS.3.2 asks producers to collect, safeguard, maintain and share provenance data for all components of each software release, and gives an SBOM as the example. PW.4.4 asks you to verify that acquired commercial, open source and all other third party components comply with your requirements throughout their life cycles; its first example is to check regularly for publicly known vulnerabilities in vendor modules that the vendor has not yet fixed. If you produce software, a binary scan of each release is evidence of what actually shipped. If you buy software, it is one way to check a supplier's claims.

NIST SP 800-161 Rev. 1, supply chain risk management

SP 800-161 Rev. 1 (May 2022, with updates as of 1 November 2024) is NIST's guidance on cybersecurity supply chain risk management. Its abstract names the concern directly: organisations have reduced visibility into how the technology they acquire is developed and integrated, and products may be vulnerable because of poor development practices in the supply chain. Binary analysis of acquired software is a practical response to that visibility gap.

CISA's 2026 Minimum Elements for an SBOM

On 29 July 2026, CISA, the NSA, the FBI and international partners published the 2026 Minimum Elements for a Software Bill of Materials. It updates and replaces the minimum elements the NTIA published in 2021. CISA describes an SBOM as an "ingredients list" for software, says the minimum elements apply to all software, and notes that some software types may need additional elements. If your contracts or customers ask for an SBOM that meets the current minimum elements, the SBOM has to describe the delivered software. For third party binaries, a binary scan is often the only source of that description you control. The older NTIA 2021 list is now history.

CISA's Software Acquisition Guide

CISA's Software Acquisition Guide for Government Enterprise Consumers (published 1 August 2024) helps acquisition teams assess suppliers' security practices across four phases of software ownership: supply chains, development practices, deployment and vulnerability management. It is written so that contracting and requirements staff can ask the right questions without becoming security experts. A binary scan gives those teams an independent artifact to compare against what a supplier says in a questionnaire.

OWASP Top 10 2025, A03 Software Supply Chain Failures

The 2025 OWASP Top 10 widened the old "components with known vulnerabilities" item into A03, Software Supply Chain Failures. Among the conditions that make you vulnerable, it lists not tracking the versions of all components you use, including transitive ones, and not scanning for vulnerabilities regularly. Among the defences, it recommends that you centrally generate and manage the SBOM of your entire software and continuously inventory component versions on both client and server. A desktop installer or a mobile app is client side software; it belongs in that inventory.

OWASP MASVS, MASVS-CODE-3

For mobile apps, the OWASP Mobile Application Security Verification Standard has a control that reads, in full, "The app only uses software components without known vulnerabilities." You cannot test that control against an APK or IPA without knowing which components are inside it. A binary scan of the release build is the most direct way to answer it, because it sees the SDKs and native libraries the build system actually packaged.

Apple's third party SDK requirements

Apple's developer support page on third party SDKs reminds developers that they are responsible for all the code an SDK includes in their app. Since WWDC23 Apple has introduced privacy manifests and signatures for SDKs, and it lists commonly used SDKs that must include a privacy manifest when you submit a new app or an update that adds one. Signatures are required when those SDKs are used as binary dependencies. That requirement is about privacy and integrity, not vulnerabilities, but it shows the platform owner treating embedded SDKs as a supply chain concern. Knowing which SDKs and versions are in your IPA is the starting point for both.

What is inside each format

Each format packs dependencies differently. Knowing where they live tells you what a scanner can find and where it will struggle.

Windows EXE and DLL (Portable Executable)

Windows executables and libraries use the Portable Executable (PE) format, which Microsoft documents in full. A PE image carries tables the operating system uses at load time, including an import table that names the DLLs and functions the image depends on. That table is one source of dependency information. A PE file can also carry an attribute certificate, which Microsoft describes as a way to associate verifiable statements with an image, such as a manufacturer's statement of the expected message digest. For .NET applications, the managed assemblies carry their own metadata, which is how a scanner can identify NuGet packages inside a compiled application.

What makes EXEs hard: libraries can be statically linked, which leaves no separate DLL and no import entry to read. Version information may be stripped. Application folders often contain DLLs with no version resource at all.

Windows Installer (MSI)

Microsoft describes Windows Installer as an installation and configuration service provided with Windows, with a standard format for component management. An MSI package describes the files, components and registry entries an application installs, and it usually carries the files themselves. Scanning an MSI means unpacking it first, then analysing every EXE and DLL inside. This is why "file extraction" comes before "dependency detection" in any binary pipeline.

Android APK

An APK is the installable Android package. It is an archive containing compiled code, resources, the AndroidManifest.xml and, for apps with native code, .so libraries for each supported architecture. Third party SDKs end up as compiled classes and native libraries inside it.

An Android App Bundle is a publishing format, not an installable one. Android's developer docs explain that Google Play uses your app bundle to generate and serve optimised APKs for each device configuration, and that the base module always lives in a base/ directory of the bundle. What a device installs is therefore a set of APKs, and an individual split APK holds only part of the app.

iOS IPA

An IPA is the archive used to distribute an iOS app. Inside it is the app bundle, with the main executable, embedded frameworks and resources. Dependencies arrive through CocoaPods, Swift Package Manager or prebuilt vendor frameworks. Swift and Objective C code is compiled to native machine code, so there is no bytecode metadata to read the way there is for Android's Java and Kotlin code; scanners rely on framework names, embedded metadata and version strings.

Source scan, manifest upload, existing SBOM or binary upload

Before you upload a binary, check whether a better input exists. Each input answers a slightly different question.

For software you build, the strongest position is both: scan the source on every pull request, and scan the release binary before it ships. Where the two lists disagree, you have found either a build step that adds components or a manifest that is out of date. For software you buy, ask the supplier for an SBOM and scan the binary anyway; the comparison is the useful part.

Step by step: a binary intake process any team can run

This process works with any binary analysis tool, including free ones. Run it for every third party application you deploy, and for every release build you publish.

1. Get the release artifact, not a convenient copy. Pull the installer from the supplier's official channel or your own release pipeline. Debug builds and internal test builds can carry different dependencies.
2. Record where it came from. Write down the source URL or pipeline run, the version, the date and a cryptographic hash of the file. You will need this when someone asks which build the SBOM describes.
3. Check the file is what it claims to be. Confirm the extension matches the content and that the file is complete. A truncated download produces an empty or misleading scan.
4. Unpack containers. Installers (MSI) and app archives (APK, IPA) contain other binaries. Your tool should extract them; if it does not, do it yourself and scan the contents.
5. Generate an SBOM. Use CycloneDX or SPDX so other tools can read it. Record the tool name and version in the SBOM metadata.
6. Match components against vulnerability data. Look at severity, whether the vulnerability is known to be exploited, and whether a fixed version exists.
7. Check licenses. Embedded libraries bring their licenses with them. A copyleft library statically linked into a commercial binary is a legal question, not only a security one.
8. Decide and record. For each finding, decide: accept with a reason, ask the supplier for a fix, rebuild with a fixed component, or block deployment. Write the decision down with an owner and a date.
9. Store the SBOM with the release. Keep it next to the artifact hash so the pair can be retrieved together.
10. Rescan on new disclosures. A binary that was clean last month may not be clean today. Re-run the vulnerability match against the stored SBOM, or rescan the binary, whenever significant new vulnerabilities are published.

A per-binary checklist you can copy

Decision table: what to do with a finding in a binary

How Safeguard does this

Safeguard handles binaries as a file upload in its Enterprise Software Supply Chain Manager. The integration is the Upload App Binary card, which the Integrations page describes as: upload and scan an app binary, a Windows EXE, MSI or DLL, an Android APK or an iOS IPA. The steps below follow the Binary Files and APK Upload pages on docs.safeguard.sh for that flow. Where the docs do not show a screen, this post describes the outcome instead of inventing one.

Step 1: open the upload integrations

1. Go to Integrations from the sidebar.
2. Use the type filter to show Upload integrations. The integrations overview lists the filter buttons as All, Source Code (SCM), Container Image, AI Model, Upload and Reset.
3. Click Connect on the Upload App Binary card. The same card takes Windows EXE, MSI and DLL files, Android APKs and iOS IPAs.

Step 2: enter project details

The Binary Files page lists three fields:

Use the same project name for every release of the same application and change only the version. The docs' own best practice section recommends consistent naming and uploading each release version separately, which keeps the history in one place.

Step 3: upload the file

Drag the file onto the upload area or click Browse, then wait for the upload to complete.

Step 4: review and submit

Review the file details, then click Upload Binary. The docs say you are then redirected to the Projects page, where the new project appears.

Step 5: let the analysis run

The Binary Files page describes the analysis in these stages:

1. File extraction. Unpacks archives and installers.
2. Dependency detection. Identifies embedded libraries.
3. Version identification. Determines component versions.
4. Vulnerability mapping. Matches components to the CVE database.
5. License detection. Identifies embedded license information.

Processing time depends on file size. Larger installers take longer.

Step 6: read the results

The result is a Safeguard project like any other. SBOM generation and analysis (GA) gives you the component list. SCA and vulnerability management (GA) shows the known CVEs against those components. License compliance (GA) shows the license information found. The APK Upload page summarises the result view as dependencies, vulnerabilities, licenses and security findings.

From there, the same project tools apply as for a repository. The Binary Files page points to the SBOM, Vulnerabilities and AI Remediate pages as next steps.

Step 7: put policy on it

Policies, gates and guardrails (GA) evaluate binary projects the same way they evaluate any other project. Gate actions are Block, Warn and Notify. Approval for a specific finding runs through exceptions: the Policies and Gates page describes clicking Request Exception, submitting it for approval, approvers being notified, and the exception being granted or denied. A reviewer can therefore accept one finding with a reason rather than switching the gate off. A sensible starting policy for third party binaries is to Warn on high severity findings and Notify the application owner, then tighten to Block for known exploited vulnerabilities once the process is settled.

What Safeguard looks for, format by format

The Binary Files page lists what it detects for each format. These are the docs' words, organised.

Windows executables, libraries and installers

Supported formats: PE files (.exe, .dll), MSI packages and .NET assemblies.

Detected:

• Embedded DLLs and libraries
• .NET NuGet packages
• Native dependencies
• Manifest information
• Digital signatures

The docs show an illustrative result for a Windows executable that lists embedded native DLLs with versions alongside .NET packages:

myapplication.exe (45 MB)
├── embedded: sqlite3.dll (3.39.0)
├── embedded: libcurl.dll (7.84.0)
├── .NET: Newtonsoft.Json (13.0.1)
├── .NET: System.Text.Json (6.0.0)
└── ...

That example is from Safeguard's docs, not from a scan run for this post.

For MSI packages, extraction matters most. The analyser has to open the installer before it can find the executables and libraries inside, which is the first stage in the list above.

Android APK

For APKs, the Binary Files page says it detects:

• Java and Kotlin dependencies
• Native libraries (.so files)
• Gradle dependencies
• Third party SDKs
• Manifest permissions

The APK Upload page describes the same analysis from the Android side. It scans native libraries, Java and Kotlin dependencies, third party SDKs (it names advertising, analytics and crash reporting as examples), the AndroidManifest.xml (permissions, components and metadata), build configuration (Gradle dependencies and build tools) and embedded resources.

For APKs, the APK Upload page adds two conveniences: the project name defaults to the APK name, and the version is auto-detected from the APK if available. Its support table:

The APK page names common dependency categories it detects, such as networking, image loading, analytics, crash reporting, advertising, UI frameworks and databases. Those are the libraries most mobile apps carry, and the ones most likely to be added by a product team without a security review.

iOS IPA

The Binary Files page lists IPA support and says it detects:

• CocoaPods dependencies
• Swift Package Manager dependencies
• Embedded frameworks
• System frameworks usage

System framework usage is worth a moment. It tells you which Apple frameworks the app links, which is context rather than a vulnerability list: those frameworks are patched through iOS updates, not through your release. The actionable part is the embedded third party frameworks and the CocoaPods and Swift Package Manager dependencies.

The CLI and the API: what works today

Two routes you might expect are not part of the binary upload story yet, and the docs say so.

The CLI does not upload binaries. The Binary Files page states plainly that the CLI does not upload binaries to the platform, and points to safeguard analyze --help for analysing a binary locally:

safeguard analyze --help

That command is shown as it appears in the docs; it was not run for this post. For the platform to scan a binary, upload it through the console. The Safeguard CLI (GA) remains the right tool for scanning source directories, Git repositories, container images and existing SBOMs on your own machine, which its docs describe with safeguard scan.

The /v1 binary upload API is not available. The Binary Files page includes an example of requesting an upload URL from a /v1 endpoint, but the same page carries a banner saying every path under the /v1 REST API returns 404 today and describes the intended shape only. Do not build automation on it yet. If you need repeatable binary scanning in a pipeline today, the documented options are the console upload, or generating an SBOM in your own pipeline and uploading it through the Existing SBOM integration.

Requirement, what Safeguard does, what you still own

Third party binaries versus your own release builds

The same upload serves two different jobs, and they lead to different actions.

Third party binaries. You are a consumer. You cannot change the code. The scan gives you an inventory and a list of known issues to take to the supplier, and a basis for a deployment decision. Keep the SBOM with your vendor record, and rescan each new version the supplier ships. For a broader view of tracking these, see tracking vendor supplied binaries in your runtime.

Your own release builds. You are the producer. The scan checks that the artifact matches what your source scan said. When it finds a component the source scan did not, trace where it came from: a vendored folder, a prebuilt SDK, a build plugin. Then decide whether it belongs in a manifest so that source scans and automated fixes can see it next time. For Android specifics, see Android APK supply chain verification.

What Safeguard does not do

• It does not upload binaries from the CLI. The CLI's binary analysis is local. Platform scans of binaries go through the console upload.
• It does not offer a working binary upload API today. The /v1 endpoints shown on the Binary Files page return 404 and describe the intended shape only.
• It cannot see through heavy obfuscation, encryption or unusual compression. The docs list obfuscated code, custom compression, encrypted content and very old formats as limitations. Obfuscated APKs may have limited dependency detection, and encrypted resources cannot be fully analysed.
• It cannot list what left no trace. A statically linked binary may show few or no dependencies. The docs' troubleshooting for "No dependencies found" names static linking and obfuscation as likely causes and suggests analysing individual components.
• It does not fix a vendor's binary. When the vulnerable component is inside software you bought, the fix has to come from the supplier. Safeguard gives you the evidence to ask for it.
• It does not replace your release decision. Gates apply your policy; deciding the policy, granting exceptions and signing off a release remain your job.
• It does not handle Apple's privacy manifest and SDK signature requirements. Those are part of Apple's submission process and Xcode's checks.
• It does not decide whether a split APK set is complete. The APK page says to upload the base APK for split APKs. Features delivered in other splits may not be covered by that scan, so scan the universal APK where you can.

Common mistakes

Scanning the debug build. The APK page and the Binary Files page both recommend release builds. Debug builds can include testing libraries and miss release only dependencies.

Scanning one flavor and calling it done. Build flavors and variants can include different dependencies. The APK page recommends scanning each variant. The same applies to Windows editions and regional builds.

Treating an empty result as clean. "No dependencies found" usually means the analyser could not see them, not that there are none. Check for static linking and obfuscation before you sign anything off.

Scanning a split APK and assuming it is the whole app. What a device installs from the Play Store can be a set of split APKs. The APK page says to upload the base APK for split APKs, so know which features live in other splits before you sign off.

Losing the link between SBOM and artifact. An SBOM without a version and a hash for the file it describes is hard to defend. Record both in the project version and description fields.

Naming every upload differently. Uploading "MyApp final", "MyApp v2 real" and "myapp-release" as separate projects destroys your history. Keep one project per application and change only the version.

Scanning once. Vulnerability data changes after you scan. Plan a rescan when new vulnerabilities are disclosed, and rescan every new supplier release.

Uploading binaries from untrusted sources. The docs' security best practices say to upload only from trusted sources and to limit who can upload. Treat the upload card like any other path into your environment.

FAQ

Can Safeguard scan an EXE without the source code?

Yes. The Binary Files integration generates an SBOM from compiled binaries without access to source code. Upload the .exe through the Upload App Binary card on the Integrations page, and Safeguard extracts, identifies and version-matches the embedded libraries, then maps them to known CVEs and licenses.

How do I scan an MSI installer for vulnerable components?

Upload the .msi through the Upload App Binary card. The analysis starts with file extraction, which unpacks installers, and then analyses the executables and libraries inside. The result is a project with an SBOM, vulnerabilities and license information.

Can I scan an iOS IPA file?

Yes. The Binary Files page lists .ipa and says it detects CocoaPods dependencies, Swift Package Manager dependencies, embedded frameworks and system framework usage.

Can I upload binaries with the Safeguard CLI?

No. The docs say the CLI does not upload binaries to the platform. safeguard analyze --help shows the local analysis options. Platform scans of binaries go through the console upload.

Is there an API for binary uploads?

The Binary Files page shows a /v1 example, but the page's own banner says the /v1 REST endpoints return 404 today. Use the console, or upload an SBOM produced in your pipeline through the Existing SBOM integration.

Why did my binary scan find no dependencies?

The docs list static linking and obfuscation as likely causes. Encrypted sections and non-standard compression can also limit results. Try analysing individual components, such as the DLLs inside an installer, separately.

Should I scan the binary if I already scan the source?

For your own releases, yes, at least before each release. The binary shows what actually shipped, including vendored files and prebuilt SDKs that never appear in a manifest. Compare the two results and fix the gap.

Can policies block a release based on a binary scan?

Yes. Binary projects are projects, so policies and gates apply. Gate actions are Block, Warn and Notify, and approval runs through exceptions.

Most of what a binary scan finds will need a fixed version from somewhere: from your own rebuild if you own the code, or from upstream or your supplier if you do not. The section below covers how Safeguard helps when you own the build and a fix exists, and what happens when upstream has none yet.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

None of these demos shows a binary upload; that happens in the console's Integrations page, as described above. They show what happens next when a binary scan points back at a dependency in a build you own: an assistant that fixes the dependency in your repository, on your machine, with your approval at each step.

The CLI demo is a real session. It installs the CLI, opens the interactive terminal, asks it to fix a lodash CVE in a repository, and the assistant reads the finding and advisory, asks before any command that changes something, edits package.json, runs the install and tests with approval, and prints a summary without pushing anything. If your release binary carries a vulnerable library that comes from your own manifest, the same request works against that repository.

Click through it at your own pace, or open it full screen.

The desktop app demo is a real session too. The CLI session appears in the desktop app's conversation list, you ask for work on your computer, pick the folder, and Approve or Deny each command and file edit until the upgrade is done and tests pass. For a Windows team that ships an installer, this is the same fix flow from a desktop window instead of a terminal.

Click through it at your own pace, or open it full screen.

The mobile app demo is a real Android session. The same conversations appear on the phone, "Work on my computer" sends the task to a computer running the CLI, and you approve the command on the phone with Allow once, Allow for turn or Deny. A mobile team that scans its APK or IPA before release can approve the dependency fix from the phone while the build machine does the work.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• Safeguard docs: Binary Files integration
• Safeguard docs: File Uploads
• Safeguard docs: APK Upload
• Safeguard docs: ESSCM Integrations overview
• Safeguard docs: Existing SBOM
• Safeguard docs: Manifest File Upload
• Safeguard docs: CLI
• Safeguard docs: Policies and Gates
• NIST SP 800-218, Secure Software Development Framework
• NIST SP 800-218 full text (PDF)
• NIST SP 800-161 Rev. 1, Cybersecurity Supply Chain Risk Management Practices
• CISA: 2026 Minimum Elements for a Software Bill of Materials
• CISA: Software Acquisition Guide for Government Enterprise Consumers
• OWASP Top 10 2025: A03 Software Supply Chain Failures
• OWASP MASVS: MASVS-CODE
• Apple Developer: Third party SDK requirements
• Android Developers: About Android App Bundles
• Android Developers: The Android App Bundle format
• Microsoft Learn: PE Format
• Microsoft Learn: Windows Installer
• CycloneDX specification overview
• SPDX

Download Safeguard at safeguard.sh/download, and read the product documentation at docs.safeguard.sh.

Last reviewed: 25 October 2026. Product capabilities change; check docs.safeguard.sh for the current state.