Live Active security incident? Get immediate response
MITRE ATT&CK® Technique

T1474.001: Compromise Software Dependencies and Development Tools

Adversaries may manipulate products or product delivery mechanisms prior to receipt by a final consumer for the purpose of data or system compromise. Applications often depend on external software to function properly. Popular open source projects that are used as dependencies in many applications may be targeted as a means to add malicious code to users of the dependency.[1]

MobileT1474.001Sub-techniqueObject v1.1 Modified
Discuss defensive coverage Back to ATT&CK
Glexia's Take

Analyst context for executives and security teams

Analyst confidence High

This mobile ATT&CK sub-technique is about risk entering through the software supply chain before an app reaches users: external dependencies, open-source components, development tools, or delivery mechanisms can be manipulated so trusted mobile apps carry malicious code. For leaders, the practical issue is not just malware detection on Android or iOS devices; it is whether the organization can prove how mobile apps and third-party components are sourced, built, reviewed, and trusted before deployment or use.

Executive priority

Prioritize this as a mobile application and supply-chain governance issue. The business decision is whether mobile software risk is managed only at runtime, or also during procurement, development, dependency selection, and release assurance. Executives should ask for evidence that mobile app dependencies and development tools are governed through secure SDLC practices, that incident response can identify affected apps and versions, and that compliance evidence exists for third-party and open-source component oversight.

Technical view

ATT&CK lists Android and iOS platforms and provides no official detection text or tactics for this sub-technique. SOC, detection engineering, and IR teams should therefore validate coverage around the broader supply-chain compromise context: mobile app inventory, dependency/component records, build and release provenance, source repository changes, development tool integrity, and mobile app behavior after installation. The relationship to DET0704 indicates a detection strategy exists, but the supplied fields do not provide its analytic details. The XcodeGhost software relationship is useful as historical context that compromised development tooling can affect iOS apps, but it should not be treated as evidence of current activity in any environment.

Likely telemetry

  • Mobile application inventory for Android and iOS apps in use or distributed by the organization
  • Software dependency and open-source component records for mobile applications
  • Source code repository and build pipeline change history
  • Development tool and build environment integrity records
  • Mobile app signing, release, and distribution metadata

Detection direction

  • Validate whether mobile supply-chain detections cover both internally developed apps and third-party mobile apps used by the organization.
  • Tune monitoring around unexpected dependency changes, unexplained build or signing changes, and discrepancies between approved and distributed mobile app versions.
  • Correlate mobile runtime observations with build, dependency, and release records; endpoint-only or device-only telemetry may miss compromise introduced before installation.
  • Use the parent Supply Chain Compromise context to avoid treating this as only a mobile malware problem; the decisive evidence may live in development, procurement, and release systems.
  • Account for false positives from legitimate dependency updates, developer tooling changes, and normal release activity by requiring approved change records and version lineage.

Mitigation priorities

  • Apply Application Developer Guidance through secure SDLC practices for mobile applications, including developer education, secure design, and vulnerability reduction.
  • Maintain approved dependency and development tool governance for Android and iOS mobile app development.
  • Require traceability from source, dependency selection, build tooling, signing, and release to the final mobile app version.
  • Include mobile supply-chain compromise scenarios in incident response planning so teams can identify affected apps, versions, dependencies, and users quickly.
  • For third-party mobile applications, align procurement and vendor risk reviews to require evidence of secure development and dependency management where appropriate.
Analyst notes and limits

The supplied ATT&CK object is a mobile sub-technique under Supply Chain Compromise and is supported by NIST Mobile Threat Catalogue references plus one cited research reference on mobile in-app advertisements. The XcodeGhost relationship provides relevant example context for compromised development tooling in iOS, but the supplied data does not support claims about current exploitation, attribution, or customer exposure.

MITRE provides no official detection text and no tactic mapping in the supplied fields. The related detection strategy is named but not described here, so specific analytics cannot be asserted. Local architecture, mobile app ownership, MDM/MTD coverage, build pipeline logging, and dependency management practices are required to determine actual risk and detection coverage.

Official MITRE ATT&CK definition

Compromise Software Dependencies and Development Tools

Adversaries may manipulate products or product delivery mechanisms prior to receipt by a final consumer for the purpose of data or system compromise. Applications often depend on external software to function properly. Popular open source projects that are used as dependencies in many applications may be targeted as a means to add malicious code to users of the dependency.[1]

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

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.

ATT&CK relationship table

Related techniques

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.

1 rows
Domain ID Name Relationship / procedure
Mobile T1474 Supply Chain Compromise This object subtechnique of Supply Chain Compromise.
Associated objects

Groups, software, and campaigns

Relationship explorer

All related ATT&CK context

uses · Malware S0297: XcodeGhost Mobile subtechnique of · Technique T1474: Supply Chain Compromise Mobile mitigates · Mitigation M1013: Application Developer Guidance Mobile detects · Detection Strategy DET0704: Detection of Compromise Software Dependencies and Development Tools Mobile
Mitigations

Mitigation direction

Mitigation Mobile

M1013: Application Developer Guidance

Application Developer Guidance focuses on providing developers with the knowledge, tools, and best practices needed to write secure code, reduce vulnerabilities, and implement secure design principles. By integrating security throughout the software development lifecycle (SDLC), this mitigation aims to prevent the introduction of exploitable weaknesses in applications, systems, and APIs. This mitigation can be implemented through the following measures: Preventing SQL Injection (Secure Coding Practice):

- Implementation: Train developers to use parameterized queries or prepared statements instead of directly embedding user input into SQL queries. - Use Case: A web application accepts user input to search a database. By sanitizing and validating user inputs, developers can prevent attackers from injecting malicious SQL commands.

Cross-Site Scripting (XSS) Mitigation:

- Implementation: Require developers to implement output encoding for all user-generated content displayed on a web page. - Use Case: An e-commerce site allows users to leave product reviews. Properly encoding and escaping user inputs prevents malicious scripts from being executed in other users’ browsers.

Secure API Design:

- Implementation: Train developers to authenticate all API endpoints and avoid exposing sensitive information in API responses. - Use Case: A mobile banking application uses APIs for account management. By enforcing token-based authentication for every API call, developers reduce the risk of unauthorized access.

Static Code Analysis in the Build Pipeline:

- Implementation: Incorporate tools into CI/CD pipelines to automatically scan for vulnerabilities during the build process. - Use Case: A fintech company integrates static analysis tools to detect hardcoded credentials in their source code before deployment.

Threat Modeling in the Design Phase:

- Implementation: Use frameworks like STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) to assess threats during application design. - Use Case: Before launching a customer portal, a SaaS company identifies potential abuse cases, such as session hijacking, and designs mitigations like secure session management.

**Tools for Implementation**:

- Static Code Analysis Tools: Use tools that can scan for known vulnerabilities in source code. - Dynamic Application Security Testing (DAST): Use tools like Burp Suite or OWASP ZAP to simulate runtime attacks and identify vulnerabilities. - Secure Frameworks: Recommend secure-by-default frameworks (e.g., Django for Python, Spring Security for Java) that enforce security best practices.

Change history

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 .

ATT&CK release
19.1
Object version
1.1
Created
Modified
Raw hash
2923dbe8612753c7...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.1 Current bundle 2923dbe86127…
Raw source

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.

Open mirrored raw JSON Open MITRE-hosted copy
Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [1]
    Grace-Advertisement

    M. Grace et al. (2012, April 16-18). Unsafe exposure analysis of mobile in-app advertisements. Retrieved November 17, 2024.

    Open source URL
  2. [2]
    NIST Mobile Threat Catalogue APP-6
    Open source URL
  3. [3]
    NIST Mobile Threat Catalogue SPC-0
    Open source URL
  4. [4]
    NIST Mobile Threat Catalogue SPC-10
    Open source URL
  5. [5]
    NIST Mobile Threat Catalogue SPC-15
    Open source URL
  6. [6]
    NIST Mobile Threat Catalogue SPC-3
    Open source URL
  7. [7]
    NIST Mobile Threat Catalogue SPC-9
    Open source URL
  8. [8]
    mitre-attack T1474.001
    Open source URL
Source and licensing

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.

Official MITRE ATT&CK site Official STIX data repository MITRE ATT&CK terms of use