{
	"id": "1106141e-e335-4696-8e14-d9de030eafe1",
	"created_at": "2026-04-06T00:20:52.40755Z",
	"updated_at": "2026-04-10T03:20:28.494992Z",
	"deleted_at": null,
	"sha1_hash": "455f4ad3e11a90edecb898895f6ca4cc4c328840",
	"title": "SPC-0 · Mobile Threat Catalogue",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 35929,
	"plain_text": "SPC-0 · Mobile Threat Catalogue\r\nArchived: 2026-04-05 17:03:05 UTC\r\nMobile Threat Catalogue\r\nMalicious Code in Open Source Software\r\nContribute\r\nThreat Category: Supply Chain\r\nID: SPC-0\r\nThreat Description: An adversary with access to open source code and knowledge of its particular use for the\r\nsystem being acquired can insert malicious code into open source software used for libraries.1\r\nThreat Origin\r\nSupply Chain Attack Framework and Attack Patterns 1\r\nExploit Examples\r\nCVE Examples\r\nPossible Countermeasures\r\nMobile App Developer\r\nTo increase the complexity of this attack, prefer open source software libraries for which integrity-checking\r\nmechanisms are provided (e.g., strong cryptographic hashes of source files, digital signatures) so the authenticity\r\nof the open source library can be verified.\r\nTo increase the complexity of this attack, when possible, obtain multiple instances of the same library as hosted by\r\nvarious sources (e.g., FTP mirrors) from which it should be available. Then evaluate all obtained versions for\r\nconsistency (e.g., compare strong hashes). If any discrepancies are detected, contact the open source software\r\ndeveloper.\r\nTo detect compromise of the integrity checking mechanisms of a given source of open source libraries,\r\nparticularly for security sensitive library functions, such as math or cryptographic libraries, contact the developer\r\nto verify the library is authentic.\r\nTo reduce the probability this variety of attack goes undetected at runtime, implement defensive programming.\r\nAny call to untrusted code that can impact critical functionality of the system should include checks on the output\r\nfor conditions that should always be true given an assumption the library behaves as expected.\r\nhttps://pages.nist.gov/mobile-threat-catalogue/supply-chain-threats/SPC-0.html\r\nPage 1 of 3\n\nTo protect open source library used by a product from modification, then if possible, package a verified authentic\r\ninstance of the open source library and apply cryptographic protections (e.g., strong hashing, digital signatures) to\r\nthe product to allow customers to verify the authenticity and integrity of all packaged components.\r\nTo prevent distributing a software package that contains maliciously modified open source libraries, perform\r\nsufficient functional testing of the complete system to verify that it exhibits correct and consistent behavior.\r\nApplication Developer\r\nTo increase the complexity of this attack, prefer open source software libraries for which integrity-checking\r\nmechanisms are provided (e.g., strong cryptographic hashes of source files, digital signatures) so the authenticity\r\nof the open source library can be verified.\r\nTo increase the complexity of this attack, when possible, obtain multiple instances of the same library as hosted by\r\nvarious sources (e.g., FTP mirrors) from which it should be available. Then evaluate all obtained versions for\r\nconsistency (e.g., compare strong hashes). If any discrepancies are detected, contact the open source software\r\ndeveloper.\r\nTo detect compromise of the integrity checking mechanisms of a given source of open source libraries,\r\nparticularly for security sensitive library functions, such as math or cryptographic libraries, contact the developer\r\nto verify the library is authentic.\r\nTo reduce the probability this variety of attack goes undetected at runtime, implement defensive programming.\r\nAny call to untrusted code that can impact critical functionality of the system should include checks on the output\r\nfor conditions that should always be true given an assumption the library behaves as expected.\r\nTo reduce the probability this variety of attack goes undetected at runtime, implement defensive programming.\r\nAny call to untrusted code that can impact critical functionality of the system should include checks on the output\r\nfor conditions that should always be true given an assumption the library behaves as expected.\r\nTo protect open source library used by a product from modification, then if possible, package a verified authentic\r\ninstance of the open source library and apply cryptographic protections (e.g., strong hashing, digital signatures) to\r\nthe product to allow customers to verify the authenticity and integrity of all packaged components.\r\nTo prevent distributing a software package that contains maliciously modified open source libraries, perform\r\nsufficient functional testing of the complete system to verify that it exhibits correct and consistent behavior.\r\nEnterprise\r\nTo increase the complexity of this attack, prefer open source software libraries for which integrity-checking\r\nmechanisms are provided (e.g., strong cryptographic hashes of source files, digital signatures) so the authenticity\r\nof the open source library can be verified.\r\nTo increase the complexity of this attack, when possible, obtain multiple instances of the same library as hosted by\r\nvarious sources (e.g., FTP mirrors) from which it should be available. Then evaluate all obtained versions for\r\nconsistency (e.g., compare strong hashes). If any discrepancies are detected, contact the open source software\r\ndeveloper.\r\nhttps://pages.nist.gov/mobile-threat-catalogue/supply-chain-threats/SPC-0.html\r\nPage 2 of 3\n\nTo detect compromise of the integrity checking mechanisms of a given source of open source libraries,\r\nparticularly for security sensitive library functions, such as math or cryptographic libraries, contact the developer\r\nto verify the library is authentic.\r\nTo protect open source library used by a product from modification, then if possible, package a verified authentic\r\ninstance of the open source library and apply cryptographic protections (e.g., strong hashing, digital signatures) to\r\nthe product to allow customers to verify the authenticity and integrity of all packaged components.\r\nTo prevent distributing a software package that contains maliciously modified open source libraries, perform\r\nsufficient functional testing of the complete system to verify that it exhibits correct and consistent behavior.\r\nTo prevent executing an application that relies upon a maliciously modified version of an open source library that\r\nis loaded dynamically at runtime (e.g., Dynamic Linked Library), perform verification of the library file prior to\r\nexecution. This may involve validating hashes, verifying digital signatures, or other integrity protection or\r\ndetection mechanisms on the host system.\r\nReferences\r\nSource: https://pages.nist.gov/mobile-threat-catalogue/supply-chain-threats/SPC-0.html\r\nhttps://pages.nist.gov/mobile-threat-catalogue/supply-chain-threats/SPC-0.html\r\nPage 3 of 3",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://pages.nist.gov/mobile-threat-catalogue/supply-chain-threats/SPC-0.html"
	],
	"report_names": [
		"SPC-0.html"
	],
	"threat_actors": [],
	"ts_created_at": 1775434852,
	"ts_updated_at": 1775791228,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/455f4ad3e11a90edecb898895f6ca4cc4c328840.pdf",
		"text": "https://archive.orkl.eu/455f4ad3e11a90edecb898895f6ca4cc4c328840.txt",
		"img": "https://archive.orkl.eu/455f4ad3e11a90edecb898895f6ca4cc4c328840.jpg"
	}
}