APSA v1.3.0

APSA 1.3.0 — dependency evidence and analysis depth

New

• Gradle dependency evidence: version-catalog aliases referenced from shipped dependency configurations become declared candidates; application-module gradle.lockfile runtime coordinates are exact. A declared candidate is superseded only when every shipping application that reaches it resolved the package. Library-module lockfiles never supersede, partial inputs keep every candidate, and with unparsed project references only an application's own declarations can be superseded.
• AAB feature modules: non-base protobuf manifests are decoded; their components and deep links carry the module name and declared delivery. Identity and application flags still come only from the base manifest, and audits stay partial.
• Mach-O code integrity (BINARY-IOS-CODE-INTEGRITY): CodeDirectory page and entitlement-slot hashes are recomputed. A mismatch is reported as modified with a warning; encrypted (App Store) or unsigned executables stay not-run or unverifiable. The CMS signature, certificate chain, team and provisioning are not authenticated.
• Parser depth: byte-preserving Swift adaptations (@_documentation(visibility:), #warning/#error, empty tuples, token-level nonisolated(unsafe)) and Objective-C NS_ENUM-family macros, NSLocalizedString comment: labels and one kept branch per preprocessor conditional. Adapted files stay partial; an Objective-C function overlapping a normalized conditional is skipped as uncertain.
• Android bulletin history and chipsets: apsa intel backfill --source android --since YYYY-MM [--until YYYY-MM] fetches an explicit, bounded month range. Device info may add soc_manufacturer, soc_model and vendor_security_patch; chipset and kernel entries use the older of the platform and vendor patch levels, and chipset_vendor is recorded beside the patch-level state without replacing it.

Upgrading from 1.2

• Catalog aliases used in shipped configurations can receive CVE matches again. Application-lockfile matches are exact and therefore version-affected; the default policy fails on high and critical ones. Other modules' lockfile coordinates stay declared candidates.
• Lockfile-resolved findings get a new identity (location gradle.lockfile), so only_new treats them as new and existing waivers no longer match. Re-approve baselines after upgrading.
• APSA does not check that dependency locking is enabled or the lockfile current, and merges the release runtime classpaths of every application module. --source-module scans only that module's directory.
• With --online, catalog aliases used in shipped configurations and the release-runtime lockfile coordinates of every module, including transitive coordinates and private group IDs, are sent to OSV; there is no exclusion list. One run still queries at most 100 packages (as in 1.2.0): packages without a recent OSV result first, and among them declared packages before transitive lockfile coordinates. Unresolved or unsupported entries use no budget. Measured application lockfiles hold 179–412 shipped coordinates, so one run leaves the rest not-run and the online audit incomplete (exit 3 under the default fail_on_partial policy); repeated runs within a day advance through the remainder. Unresolved aliases and unsupported ecosystems keep online audits incomplete on every run.
• IPA reports gain BINARY-IOS-CODE-INTEGRITY. Consistent hashes do not prove authenticity (a re-signed modified binary is consistent); a mismatch is a warning, not a finding.
• Android bulletin records cached by 1.2.0 derive their vendor scope from the component name. intel sync refreshes only recent bulletins; use intel backfill for older months.
• Unmodified 1.2.0 packaged skills upgrade with apsa skill install without --force; user edits stay protected.

Fixed during release review

• Within the OSV budget, an application lockfile no longer crowds out directly declared packages, and packages in ecosystems OSV does not support no longer consume budget slots.

Evidence and limits

• Gradle's own resolution as oracle on three frozen public-app holdouts: first blind results holdout-1 198 TP / 22 FP, holdout-2 90 / 9, holdout-3 63 / 1; after fixes made once the truth was seen (reported separately) 198 / 3, 194 / 27 (17 of the 27 from Pocket Casts wear/TV sibling apps) and 121 / 2. See DEPENDENCY_RESULTS.md.
• Independent vulnerable/fixed source pairs with truth frozen before scanning: TP 5 / FN 6 / FP 1 / TN 10. See FPFN_RESULTS.md.
• Every evaluation harness was re-run on the final release runtime; results are recorded in RELEASE_READINESS.md. Scope and limits: NEXT_ANALYSIS.md.
• Known gaps: Gradle projectDir remapping, NS_ASSUME_NONNULL_BEGIN, CodeDirectory scatter, Apple and vendor bulletin history, OSV batch querying. No physical device was used.
• A scan with no findings does not establish that an app is secure; affected versions do not prove exploitability.

Full Changelog: v1.2.0...v1.3.0