Repeat-upload resilience is the ability to recognise a removed malicious app when it returns in a slightly changed form. It depends on correlating developer behaviour, package metadata, and visual or textual reuse so takedowns do not simply reset the attacker’s identity.
Expanded Definition
Repeat-upload resilience describes a platform’s ability to detect when a previously removed malicious app returns in a new upload that has been lightly modified to evade enforcement. In practice, the concept sits at the intersection of app integrity review, abuse detection, and identity correlation: the goal is not only to block one package, but to recognise the actor behind repeated submissions. That requires linking developer accounts, signing certificates, package names, iconography, descriptions, network indicators, and other reuse patterns that survive simple rebranding.
Definitions vary across vendors because no single standard governs this term yet. Some teams use it narrowly for app store moderation, while others apply it more broadly to software marketplaces, extension ecosystems, and mobile threat hunting. NHI Management Group treats it as a resilience property: the stronger the correlation logic, the harder it is for a removed publisher to reset enforcement by changing superficial attributes. The most common misapplication is treating repeat uploads as independent submissions, which occurs when moderation workflows only compare package hashes and do not preserve prior enforcement context.
Authoritative control thinking can be borrowed from NIST SP 800-53 Rev 5 Security and Privacy Controls, especially where continuous monitoring and incident handling are used to keep prior findings actionable across re-submissions.
Examples and Use Cases
Implementing repeat-upload resilience rigorously often introduces review latency and false-positive risk, requiring organisations to weigh enforcement speed against the cost of blocking legitimate developers who reuse common assets.
- A mobile app store flags a new upload because the developer account, certificate chain, and permission prompts match a removed malicious app that was repackaged with a different name.
- A browser extension marketplace correlates reused code fragments, identical remote endpoints, and near-duplicate screenshots to detect a policy violator returning after takedown.
- A software repository identifies a pattern of renamed packages published from the same maintainer identity after previous malware removals, using historical enforcement records to trigger manual review.
- An internal enterprise app catalog cross-checks publisher behaviour against prior abuse cases so a blocked third-party tool cannot simply be re-submitted under a fresh listing.
For platform teams, this is closely related to identity correlation and reputation persistence rather than pure malware scanning. Guidance from OWASP ASVS is not a direct definition of the term, but it reinforces the broader principle that security decisions should not rely on a single weak signal when stronger contextual checks are available. Repeat-upload resilience becomes strongest when multiple weak signals are combined over time, rather than evaluated in isolation.
Why It Matters for Security Teams
Security teams miss repeat-upload resilience when they assume removal is the end of the problem. In reality, takedown without persistence of context can reward adversaries by teaching them which traits were detected, then allowing them to modify only the obvious ones. That makes enforcement a moving target and turns platform trust into a brittle, manual process.
The operational impact is broader than content moderation. Re-upload abuse can be used to relaunch credential theft, ad fraud, phishing helpers, or malicious SDKs, especially where package ecosystems support fast iteration. A resilient review process preserves the history of abuse, the relationship between submissions, and the identity signals associated with publishers, which is why controls around logging, monitoring, and incident response matter. NIST control guidance in NIST SP 800-53 Rev 5 Security and Privacy Controls is relevant here because teams need durable records that support ongoing enforcement rather than one-off takedowns.
Organisations typically encounter the real cost of weak repeat-upload resilience only after the same actor returns under a new listing and abuses user trust again, at which point correlation across prior removals becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | DE.CM-1 | Continuous monitoring helps spot repeat abuse across fresh uploads and changed listings. |
| NIST SP 800-53 Rev 5 | AU-6 | Audit review supports correlation of prior removals with new submissions and publisher behavior. |
| OWASP Non-Human Identity Top 10 | NHI governance applies when publisher identities or automation accounts are reused to evade removal. | |
| NIST AI RMF | AI risk management supports persistent detection logic when models score re-uploaded content. | |
| OWASP Agentic AI Top 10 | Agentic workflows can automate review and correlate repeated malicious submissions. |
Preserve enforcement history and monitor re-submissions so recurring malicious publishers are detected early.
