Spectra Assure Free Trial
Get your 14-day free trial of Spectra Assure for Software Supply Chain Security
Get Free TrialMore about Spectra Assure Free TrialThroughout the past three years, a large number of open source software package repositories have been found to contain malware of various types. Major repositories include the Arch Linux User Repository (AUR)[10], Node.js NPM registry[11], the Ubuntu Snap Store[12], RubyGems[13], and the Python package repository PyPI[14]. It is clear that all of the installation and update pathways for software and library code used in an organization must have security controls applied to them to prevent and mitigate supply chain attacks. What follows is an overview of the policies and procedures to prevent, control, and mitigate a supply chain attack according to the NIST Cybersecurity Framework.[15] Included are specific case studies and concrete examples of how to use the ReversingLabs A1000 within these processes.
Figure 1: Timeline of Historical Supply Chain Attacks
The first core function described by the framework is to identify. This function can be divided into two main components, both of which allow the organization to understand the lay of the land, so to speak. The first is asset management. It is important to map the flow of information and data within the organization[16] and to catalog any external information systems[17]. With regards to supply chain, this means understanding how software is updated and where it is used within the organization. As for cataloging external systems, an inventory of where software is updated from is important. The second main component is to understand the business environment. The organization should identify any dependencies specific supply chain components have on the delivery of the organization’s critical services.[18] This knowledge allows for prioritization of resources where they can be most effective.
Once the lay of the land within the organization is understood, risk assessment of various flavors are applied to the assets. Firstly, each external system in the supply chain should be assigned a trustworthiness value. “Trustworthy information systems are systems that are capable of being trusted to operate within defined levels of risk despite the environmental disruptions, human errors, and purposeful attacks that are expected to occur in the specified environments of operation.”[19] Secondly, threat intelligence gathered from information sharing forums and sources should be applied to the risk assessment process.[20] If attacks are found in the wild for a particular component in the supply chain, this intelligence needs to be used to adjust the risk assessed for that component. In turn, if the risk rises above a threshold, changes in the organization’s security posture should be made and additional controls should be applied.
Including threat intelligence in an organization’s security processes can be a complex task. A concept that allows this process to be more focused on what is most important to an organization is priority intelligence requirements (PIR). These are directives issued to an intelligence team that help them focus their collections and attention on specific systems and software used by the organization. Understanding the specifics of the organization’s supply chain informs the creation of PIRs specific to the vendors and sources used by the organization.
The next two core functions in the NIST framework are protect and detect. These are for developing safeguards to ensure the safety of the software supply chain and to detect malicious code that may compromise the organization. The most important aspect of the protect core framework function with regards to supply chain is to log all maintenance, specifically software upgrades.[21] In addition to the upgrade logs, the results of software testing such as done using the ReversingLabs A1000 should be documented for later analysis or forensics.
Taking a closer look at the ShadowPad supply chain attack mentioned above, the following process can be used to compare a previous known good version of the software to the potential update downloaded from the vendor. This process can be included in an IT department’s change management process, if they have a formal process. It can also be used ad-hoc during an IT department’s process for update testing before organization-wide rollout.
The first step is to obtain the old version which is known good and upload that file to the A1000.[22] After the analysis is complete, upload the upgrade candidate file.[23] Then open both analyses and compare them side-to-side, focusing on two main areas of the analysis results: capabilities and indicators. A change in either of these areas is a red flag that further, deeper analysis must be performed before this upgrade is allowed.
Video 1: Side by Side Analysis of ShadowPad nssock2.dll in ReversingLabs A1000
In addition to this side by side analysis, the designation of the file’s threat as well as the results from TitaniumCloud analysis should be examined. In the case of ShadowPad, the file is marked malicious with a threat designation of “Win32.Trojan.Shadowpad” and a wide variety of AV scanner engine detections.
Figure 2: A1000 Threat and TitanumCloud Results
The NetSarang software packages are Windows PE software, but the A1000’s analysis is not restricted to this file type only. Examining the Transmission bittorrent client for macOS as an example, a similar process can be followed. After the known good and potential upgrade .dmg format files have been uploaded to the A1000, the unpacking functionality is used to drill down to the executable file contained in the install package. In most macOS software installation packages of format .dmg, one must navigate the A1000’s extracted files feature to analyze the executable. Inside the .dmg is a folder with the name of the program. Inside that is a directory with the file extension .app. Then inside that, the binary to analyze is in the Contents/MacOS/ directory.
Video 2: Unpacking macOS Package
Once both samples are unpacked, the capabilities and indicators for each can be compared side by side in the same way used with ShadowPad and Windows PE files.
Video 3: Side by Side Analysis of Transmission in ReversingLabs A1000
Even if you are installing software for the first time, and do not have an older known good file as a reference, these same analysis results can be used to check if a file has the capabilities one expects. In the case of Android apps, check for the expected permissions. In this example, we take a closer look at the Exodus Android spyware found in the Google Play Store on March 29th of this year. Examining the Android capabilities using the A1000, we see a few potentially problematic entries: camera, location services, microphone, and networking. If any of these capabilities are not expected for the app, this is an indication that the file needs to be more closely analyzed before allowing it to be installed.
Figure 3: Exodus Android Spyware Capabilities
In a similar way, the Android app’s requested permissions can be analyzed for suspicious combinations. In the following screenshot we can see that Exodus requests permission to connect to the Internet as well as to read the user’s SMSs. Suspiciously for an app that deals with SMS, it only requests read permission without requesting send permission.
Figure 4: Exodus Android Spyware Permissions
In any security program, it is essential to have processes that are repeatable and automated. Outlined in the detect core function of the NIST framework, is continuous monitoring. The specific control of malicious code protection in turn describes periodic scans.[24] In the case of software supply chain analysis, this process can be an automated component of change management. This can include programmatic comparison of the API output from the A1000 in the specific fields checked in the examples above: capabilities and indicators. Any change in the number or type of entries in these fields should trigger an alert and kick off human intervention and deeper analysis.
Hopefully, readers have learned about supply chain security controls that can be put to use immediately using the A1000, even if automating the process is still in the future.
The NIST Cybersecurity Framework isn’t the only standard that customers may wish to follow when implementing supply chain security controls using the ReversingLabs A1000. What follows is a chart of standards that pertain to this process specifically.
TYPE | STANDARD | CODE | SECTION | TITLE |
Supply Chain | NIST Cybersecurity Framework | ID.SC-4 [25] | Supply Chain Risk Management | Suppliers and third-party partners are routinely assessed using audits, test results, or other forms of evaluations to confirm they are meeting their contractual obligations. |
Supply Chain | NIST 800-53 (Rev. 4) | SA-12 [26] | System and Services Acquisition | Supply Chain Protection |
Supply Chain | ISO/IEC 27001:2013 | A.15.2.1 [27] | Supplier service delivery management | Organizations shall regularly monitor, review and audit supplier service delivery. |
Supply Chain | NERC CIP-013-1 | 1.2.5 [28] | Supply Chain Risk Management | Verification of software integrity and authenticity of all software and patches provided by the vendor for use in the BES Cyber System |
General | NIST Cybersecurity Framework | DE.CM-4 [29] | Security Continuous | Malicious code is detected |
General | NIST 800-53 (Rev. 4) | SI-3 [30] | System and Information Integrity | Malicious Code Protection |
General | CIS Controls | 8.1 [31] | Malware Defences | Utilize Centrally Managed Anti-Malware Software |
General | ISO/IEC 27001:2013 | A.12.2.1 [32] | Controls against malware | Detection, prevention and recovery controls to protect against malware shall be implemented, combined with appropriate user awareness. |
Read our Supply Chain Research Blog on NPM package malware in The NPM package that walked away with all your passwords
Our Research Blog on PyPI package malware in SupPy Chain Malware – Detecting malware in package manager repositories
Or our Research Blog on ASUS Live Update attack in Forging the ShadowHammer
[1] https://web.archive.org/web/20111029105944/http://www.linuxfoundation.org/news-media/blogs/browse/2011/08/cracking-kernelorg
[2] https://unit42.paloaltonetworks.com/new-os-x-ransomware-keranger-infected-transmission-bittorrent-client-installer/
[3] https://www.welivesecurity.com/2016/08/30/osxkeydnap-spreads-via-signed-transmission-application/
[10] https://www.bleepingcomputer.com/news/security/malware-found-in-arch-linux-aur-package-repository/
[14] https://blog.reversinglabs.com/blog/suppy-chain-malware-detecting-malware-in-package-manager-repositories
[16] NIST Framework ID.AM-3
[17] NIST Framework ID.AM-4
[18] NIST Framework ID.BE-4
[20] NIST Framework ID.RA-2
[21] NIST Framework PR.MA-1
[22] Sample SHA1: 298a5e5e7b144e1ae5b7912f91379fae4f58b2e5
[23] Sample SHA1: f1a181d29b38dfe60d8ea487e8ed0ef30f064763







Researchers built a worm that reasons about hosts it infects, and the open-weight models powering it sit outside AI-provider safety controls.
While prompt injection and data disclosure remain concerns, excessive agency climbed the list — not surprising with recent security incidents.


