DET0628: Detection of Supply Chain Compromise
DET0628 is a mobile ATT&CK detection strategy for Supply Chain Compromise, tied to technique T1474. Its practical value is that compromise may occur before...
Analyst context for executives and security teams
DET0628 is a mobile ATT&CK detection strategy for Supply Chain Compromise, tied to technique T1474. Its practical value is that compromise may occur before an app, update, dependency, tool, or delivery path reaches the organization or end user, making traditional endpoint-only thinking insufficient. For leaders, this is a reminder to validate trust in mobile software sources, build/update pipelines, and third-party dependencies—not just monitor devices after deployment.
Executive priority
Treat this as a resilience and governance priority rather than only a SOC alerting problem. Because the related technique covers manipulation of development tools, environments, repositories, open-source dependencies, source code, and update/distribution mechanisms, executives should ask whether mobile software intake and release processes produce evidence that can support incident decisions, vendor assurance, audit readiness, and rapid containment if a trusted component is later questioned. Budget and control prioritization should focus on visibility across software provenance, update channels, dependency risk, and mobile app distribution paths for Android and iOS environments where relevant.
Technical view
ATT&CK provides no official detection text for this detection strategy, so SOC and detection teams should not assume a prescribed analytic exists. Use the relationship to T1474 as the operating scope: validate whether the organization can detect suspicious changes or anomalies in mobile software supply paths, including development tooling, development environments, source repositories, open-source dependencies, source code changes, and software update or distribution mechanisms. For incident response, confirm that teams can reconstruct what changed, who or what changed it, when it was distributed, and which Android or iOS users, devices, or applications may have received the affected component.
Likely telemetry
- Mobile application inventory and version history for Android and iOS where used
- Mobile app distribution and update records
- Source code repository audit logs and change history
- Build system and development environment logs
- Dependency and package metadata, including open-source dependency records
Detection direction
- Start by mapping mobile app intake, build, signing, release, and distribution workflows to identify where evidence is actually collected.
- Validate alerts or review processes for unexpected repository changes, dependency changes, build pipeline changes, signing or release anomalies, and unusual update distribution behavior.
- Tune detections with release calendars, approved maintainers, expected dependency updates, and authorized distribution channels to reduce false positives from normal development activity.
- Account for blind spots where third-party apps, external dependencies, vendor-controlled update mechanisms, or unmanaged mobile devices limit direct telemetry.
- Use relationship context to T1474 to keep detection engineering focused on supply chain paths rather than only on post-compromise device behavior.
Mitigation priorities
- Prioritize software provenance and change-control evidence for mobile applications and updates.
- Strengthen governance over source repositories, development environments, build systems, dependencies, signing, and release processes.
- Require review and approval paths for dependency, source code, and distribution changes that could affect Android or iOS users.
- Ensure incident response playbooks can identify affected app versions, distribution scope, and rollback or containment options.
- Use vendor and third-party assurance processes to cover areas where internal telemetry is unavailable.
Analyst notes and limits
This object is a detection strategy, not a full technique description. The supplied ATT&CK fields include no official description, no official detection guidance, no tactics, and no platforms for the strategy itself. The strongest usable context is the relationship stating that DET0628 detects T1474, Supply Chain Compromise, in the mobile ATT&CK domain, with the related technique associated with Android and iOS.
Coverage and risk cannot be inferred from this object alone. Local architecture, app sourcing model, mobile management coverage, development pipeline ownership, third-party dependency exposure, and available logs are required to determine practical detection maturity. No active exploitation, attribution, impact, or guaranteed detection is supported by the supplied data.
Detection of Supply Chain Compromise
No official description is available in the imported ATT&CK source object.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Mobile | T1474 | Supply Chain Compromise | This object detects Supply Chain Compromise. |
All related ATT&CK context
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | bbef8c1ce172… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack DET0628Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.