A Defense-In-Depth and Layered Approach to Software Supply Chain Security

red warning button; photo source: 123RF.com
Photo source: 123rf.com

Posted: March 1, 2024 | By: Abdul Rahman

Summary

In this article, we will discuss the confluence and utility of using software supply chain (SSC)-focused frameworks (The Updated Framework [TUF] and the in-toto framework), combined with behavioral approaches using artificial intelligence (AI) aligned with the National Institute of Standards and Technology (NIST) Cybersecurity Framework (CSF), to generate a truly comprehensive approach for SSC security [1]. Such a “defense-in-depth” approach recognizes that these frameworks by themselves fall short of addressing the guidelines for the integrity of SSCs. We will also examine the common attacks currently employed against SSCs and how both frameworks can be utilized to prevent such attacks, along with suggestive alignment with required compliance frameworks [1–3].

Additionally, we will explore the possibilities, challenges, best practices, benefits, and potential uses of AI computing models to assure the security of high-value SSCs. Of all the potential uses of emerging AI-enabled and machine-learning (ML) tools to promote cybersecurity in the defense community, their application to protecting software supply chains may be one of the most promising given the massive volume of coding information involved [4]. The U.S. Department of Defense’s (DoD’s) Chief Digital and Artificial Intelligence Office (CDAO), which the department recently established in June 2022, is already seeking to use AI and ML tools to conduct analysis within digital engineering and cyber supply chain use cases [5].

Because the success of an AI/ML tool depends, in part, on acquiring useful data in a timely manner, curating stored data plays a central role in producing high-efficacy predictions. Reasoning over these features drives recommendations for optimizations, leading to improvements in overall SSC security. This includes identifying the following:

  • Potential software-build bottlenecks (inclusive of on-premise, cloud, and hybrid),
  • Usage trends,
  • Vulnerabilities aligned with using libraries (e.g., dynamic link libraries, portable executables, etc.), and
  • Fraudulent actions.

To protect critical military and homeland security SSCs, AI/ML-based supply chain analysis can be trained on a broad set of local, distributed, network, and end-point data to infer the probability of security threats and vulnerabilities in the supply chain.

Background

An SSC refers to a collection of software modules, libraries, and components built by third parties and the processes involved in developing and assembling software distributions. One leading software developer notes that an SSC includes all “networks of information about the software,” including its hardware, operating systems, and cloud services; the software’s sources “like registries, GitHub repositories, codebases, or other open-source projects”; and even the people who write its code [6]. Today’s enterprise software products are intentionally engineered to draw upon broad software communities to enable more efficient, familiar, and interoperable baselines. Developers achieve this by leveraging code sourced from external (but interconnected) libraries and modules that may serve different purposes for an application (e.g., encryption, authentication, and networking).

Although efficiencies are gained through this form of community development, it also presents numerous opportunities for introducing harmful vulnerabilities and weaknesses, as an entity that acquires such software has limited visibility into and surety of the build’s security [2]. Specifically, admitting dependencies through SSC development processes facilitates exploitable software code that can yield numerous (and cascading) vulnerabilities into the postbuilt product code baseline (see Figure 1). As a result, the security of an application’s SSC is crucial to ensure that the final software product remains free from malicious elements like backdoors (whether “hidden” or unintentionally built) or other vulnerabilities. A compromised SSC can have a widespread impact, as it will most likely affect multiple users simultaneously.

Figure 1

Figure 1. An Enterprise’s Visibility, Understanding, and Control of Its SSC Decreases With Each Layer of the Broader Development Community’s Involvement (Source:  NIST [2]).

The “SolarWinds” cyberattack levied in 2020 against multiple U.S. federal government systems by foreign adversarial groups precisely exploited these types of shortcomings in software supply chain security [7, 8]. In what the U.S. Government Accountability Office (GAO) has called “one of the most widespread and sophisticated hacking campaigns ever conducted against the federal government and private sector” [9], a threat actor compromised SolarWinds’ “Orion” information technology administration suite by injecting malicious backdoor code into a routine software update package (see Figure 2). The threat actor, later identified by the intelligence community as the Russian Foreign Intelligence Service, was able to monitor affected systems, scrape information, and alter “command and control” activities. Even worse, the SolarWinds compromise went undetected for nearly 12 months [9].

Figure 2

Figure 2. GAO Depiction of How a Threat Actor Exploited SolarWinds’ Orion Software in 2010 (Source:  U.S. GAO [9]).

SSCs are integral to applications and systems widely used across the private and public sector, and securing them from hacking or adversarial intrusion is a critical national security objective. For example, the U.S. “National Cybersecurity Strategy Implementation Plan,” released in July 2023, details several federal initiatives to mitigate the risks to both public and private sector SSCs by making the digital ecosystem more “transparent, secure, resilient, and trustworthy” [10]. In part, these actions seek to increase trust in international software suppliers by requiring that federal entities and contractors follow cybersecurity supply chain risk management (C-SCRM) best practices.

The DoD is similarly focused on protecting military-specific SSCs. The Office of the Assistant Secretary of Defense for Sustainment (OASD[S]) recently listed the identification of SSC cyber vulnerabilities as one of its key activities in promoting acquisition security and is documenting existing source code exposures among the U.S. defense industrial bases [11]. The Office of the DoD Chief Information Officer is also working to finalize an enterprise-wide strategy for cyber supply chain risk management to guide protective actions for SSCs across the DoD [12].

An attack on an SSC occurs when malicious actors gain unauthorized access to and modify software at any point within the intricate software development supply chain, like what happened with the SolarWinds event. By introducing their own malicious code, attackers aim to compromise a downstream target within the same supply chain [13]. Taking immediate action to secure SSCs—actions above and beyond the base updating of risk management plans—is necessary to effectively mitigate the risks posed by adversarial groups to both U.S. government and military network operations within this well-funded and active landscape.

Introduction

Because current government policy guidance for supply chain risk management practice can best be characterized as broad and nonspecific [14], organizations whose SSCs are the targets of advanced persistent threats (APTs) or nation-state-supported actors require more robust guidance for addressing their vulnerabilities than typically offered (see Figure 3). Due to the complexity and diversity of exploits that threaten SSCs, cybersecurity guidance would benefit greatly from identifying actionable critical details that organizations can take to directly address SSC hardening. For example, C-SCRM practices presume that organizational maturity around SSC security exists. However, suggested organizational governance and action plans (e.g., an organizational SCRM plan) generally only loosely address the direction needed for the effective triage, mitigation, and remediation of the SSC vulnerabilities that lie at the heart of SSC exploitations [14].

Figure 3

Figure 3. Project Approach for Supply Chain Risk Management Practices (Source:  U.S. DoD [11]).

Recent data presented by Herr [13] at the USENIX Enigma conference in February 2021 suggest that SSC attacks comprise a growing set of trends that include more attacks from state actors (Russia and China) involving many of the common open-source projects used as dependencies within large organizations’ SSCs. Compromising software provided by developer tools available within popular app stores is a more efficient (cost and time) method for exploiting organizations; this path currently represents 25% of documented SSC security incidents. Injecting vulnerabilities, backdoors, and software exploits into software staged within public, open-source repositories forms another 26% of attacks on SSCs, sourced from software updates to include common package management tools [15]. Common package management tools targeted by bad actors for SSC attacks can include application updaters (e.g., the FireFox browser updater), library package managers (e.g., RubyGems, PHP composure, and PIP install PyPI), and system package managers (e.g., APTs, YUM, and YaST).

Securing SSCs requires adopting preventive strategies against potential attacks. This can be achieved by building a baseline and engaging in robust behavioral continuous monitoring practices. These behavior-based methods involve employing AI models to forecast, infer, predict, correlate, and specify likely weaknesses, avenues of approach, and attack vectors within SSC-embedded software. Within the NIST Cybersecurity Framework (CSF), five subcategories of actions within the “Supply Chain Risk Management” category (ID.SC) of the “Identify” function lay out the key minimum or baseline actions needed for C-SCRM and are mandatory for select federal agencies (see Table 1) [1].

Table 1. NIST Guidance for Organizational Supply Chain Risk Management Under the “Identify” Function of the NIST Cybersecurity Framework (Source:  NIST [1])

Category Subcategory Informative References
Supply Chain Risk Management (ID.SC): The organization’s priorities, constraints, risk tolerances, and assumptions are established and used to support risk decisions associated with managing supply chain risk. The organization has established and implemented the processes to identify, assess and manage supply chain risks. ID.SC-1: Cyber supply chain risk management processes are identified, established, assessed, managed, and agreed to by organizational stakeholders. CIS CSC 4 COBIT 5 APO10.01, APO10.04, APO12.04, APO12.05, APO13.02, BAI01.03, BAI02.03, BAI04.02 ISA 62443-2-1:2009 4.3.4.2 ISO/IEC 27001:2013 A.15.1.1, A.15.1.2, A.15.1.3, A.15.2.1, A.15.2.2 NIST SP 800-53 Rev. 4 SA-9, SA-12, PM-9
ID.SC-2: Suppliers and third-party partners of information systems, components, and services are identified, prioritized, and assessed using a cyber supply chain risk assessment process. COBIT 5 APO10.01, APO10.02, APO10.04, APO10.05, APO12.01, APO12.02, APO12.03, APO12.04, APO12.05, APO12.06, APO13.02, BAI02.03 ISA 62443-2-1:2009 4.2.3.1, 4.2.3.2, 4.2.3.3, 4.2.3.4, 4.2.3.6, 4.2.3.8, 4.2.3.9, 4.2.3.10, 4.2.3.12, 4.2.3.13, 4.2.3.14 ISO/IEC 27001:2013 A.15.2.1, A.15.2.2 NIST SP 800-53 Rev. 4 RA-2, RA-3, SA-12, SA-14, SA-15, PM-9
ID.SC-3: Contracts with suppliers and third-party partners are used to implement appropriate measures designed to meet the objectives of an organization’s cybersecurity program and Cyber Supply Chain Risk Management Plan. COBIT 5 APO10.01, APO10.02, APO10.03, APO10.04, APO10.05 ISA 62443-2-1:2009 4.3.2.6.4, 4.3.2.6.7 ISO/IEC 27001:2013 A.15.1.1, A.15.1.2, A.15.1.3 NIST SP 800-53 Rev. 4 SA-9, SA-11, SA-12, PM-9
ID.SC-4: 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. COBIT 5 APO10.01, APO10.03, APO10.04, APO10.05, MEA01.01, MEA01.02, MEA01.03, MEA01.04, MEA01.05 ISA 62443-2-1:2009 4.3.2.6.7 ISA 62443-3-3:2013 SR 6.1 ISO/IEC 27001:2013 A.15.2.1, A.15.2.2 NIST SP 800-53 Rev. 4 AU-2, AU-6, AU-12, AU-16, PS-7, SA-9, SA-12
ID.SC-5: Response and recovery planning and testing are conducted with suppliers and third-party providers. CIS CSC 19, 20 COBIT 5 DSS04.04 ISA 62443-2-1:2009 4.3.2.5.7, 4.3.4.5.11 ISA 62443-3-3:2013 SR 2.8, SR 3.3, SR.6.1, SR 7.3, SR 7.4 ISO/IEC 27001:2013 A.17.1.3 NIST SP 800-53 Rev. 4 CP-2, CP-4, IR-3, IR-4, IR-6, IR-8, IR-9

Including AI into C-SCRM best practices can amplify the use of existing frameworks claiming to provide “last mile” security to detect vulnerabilities already present in compromised SSCs. For example, TUF states that a software update system is only truly considered “secure” if it promptly recognizes the latest available updates, ensures the correct file downloads, and prevents any harm resulting from checking or downloading files [16]. However, TUF also acknowledges the possibility that a package could be compromised even before it reaches a software update repository.

Challenges in SSC Security

Due to the complex and diverse supply chain within the U.S. government, its reliance on a vast and diverse network of suppliers and vendors for software components introduces a spectrum of challenges in securing the software components it employs. Addressing SSC challenges requires a combination of technical solutions, robust security practices, collaboration among stakeholders, and adherence to industry standards. It is crucial for organizations to prioritize SSC security to mitigate risks and protect against potential vulnerabilities and attacks. Federal entities sometimes lack complete visibility into their SSCs, including the origin, integrity, and security of components. This lack of visibility makes it challenging to identify and mitigate potential risks and vulnerabilities. In addition, relying on third-party vendors introduces risks in terms of the security practices and integrity of the software components provided.

The challenge lies in ensuring that these vendors adhere to strict security standards and supply secure software. A key weakness is the continued dependence on legacy systems and outdated software, much of it yet to be migrated or updated to newer, safer systems. These systems often have known vulnerabilities or lack necessary security updates, making them attractive targets for attackers. NIST CSF, C-SCRM, and Risk Management Framework (RMF) suggest controls and compliance requirements that manifest add complexity to SSC security [1–3). Meeting these requirements while ensuring the security and integrity of the supply chain can be challenging and very manually resource intensive. Finally, workforce challenges like organizational resource constraints and a shortage of cybersecurity expertise make it difficult to effectively manage and secure the SSC. This can impede the implementation of robust security measures and practices.

SSC Threats

Organizations and agencies in the United States should remain vigilant by implementing robust security measures, conducting regular risk assessments, and staying informed about emerging threats and attack vectors targeting SSCs. Both nation-state actors and APTs possess advanced capabilities and focus on developing aggressive, offensive cyberattack campaigns targeting the SSCs of U.S. organizations and government entities to gain unauthorized access, conduct espionage, or disrupt critical systems. These actors, who often have sophisticated tools, are well-funded, highly skilled, and focus on conducting both tactical and strategic operations ranging from establishing long-term access footholds in systems or networks to disrupting campaigns (e.g., false flag, fake news, and influence). They employ various techniques, such as exploiting supply chain intermediaries to include injecting exploits into software provided by public open-source repositories, software distributors, and defense industrial base (DIB) system integrators (SIs). Through infiltrating these trusted entities, they can inject malicious code, tamper with software components, or manipulate updates to distribute compromised software [13, 17].

For example, attackers inject malicious code or malware into legitimate software packages during development, distribution, or updates within publicly available repositories where key modules for enterprise software builds are staged. This can result in compromised software being delivered to end-users, allowing attackers to gain unauthorized access or control over systems. Nation-state and APT campaigns seek efficient (cost and time) means of gaining footholds within organizations. Herr [13] suggested that many of the SSC attacks have gone unreported since many of the dependencies or third-party libraries used in software development are exploited through embedding backdoors into the software, potentially leading to unauthorized access or data breaches. This current state encourages providers of software components for SSCs to embrace layered defense-in-depth approaches [18] that employ behavioral-based detections with AI, coupled with both software frameworks [16, 19], blockchains [20], and governance/compliance frameworks [1].

Proposing Layered SSC Security

Establishing mechanisms to verify the integrity and authenticity of software components throughout the SSC is the goal of any enterprise that depends on software sourced from multiple third-party providers. Gaps in existing approaches to SSC security suggest the need for a comprehensive defense-in-depth strategy that involves layering software frameworks to achieve the following:

  • Improve metadata cataloging of software artifacts (e.g., implementing TUF and/or in-toto on artifacts),
  • Use AI in behavioral-based detection approaches (i.e., use AI models to identify anomalies and points of compromise within an SSC),
  • Implement a private or public blockchain to serve as an immutable electronic data structure to enable on- and off-chain comparisons of SSC components, and
  • Align with the supply chain Identify portion (ID.SC) of the NIST CSF best practice recommendations [1].

When working in tandem, these layers can suggest major improvement proposals for SSC security wherein integration across each can support comprehensive SSC security. Such integrated measures offer better protection against mix-and-match attacks, malicious mirrors, and key compromise vulnerabilities (e.g., single or threshold of keys). Support of layered SSC security involves implementing best practices of access, validation control, and code change management to preserve the integrity of repository code commits (see Figure 4) [21].

Figure 4

Figure 4. Secure Software Commit Process (Source:  U.S. National Security Agency [NSA], Cybersecurity and Infrastructure Security Agency (CISA), and the Office of the Director of National Intelligence (ODNI) [21]).

The in-toto framework (intoto.io) is a system designed to secure the entire SSC, encompassing the development, building, testing, and packaging processes. It provides attestation of integrity and verifiability for each action performed throughout the supply chain, including code writing, compilation, testing, and deployment. The framework ensures transparency by disclosing the order of steps and actors involved. According to in-toto [19], the framework enables users to verify the intended execution of each step, authenticate the actors involved, and ensure that materials (such as source code) remain untampered between steps. TUF empowers developers to safeguard updated systems against repository compromises and attacks that focus on signing keys. It offers a robust approach to provide trust information about software, including meta-information about artifacts. Its primary objective is to authenticate the source of data stored in repositories. Additionally, it verifies the freshness of artifacts and maintains repository consistency, which are crucial steps for ensuring overall integrity and security in SSCs. TUF aims to prevent malicious behavior where attackers manipulate software artifacts in a way that the combined result can become malicious [16].

SSCs rely on Software Bill of Materials (SBOM) manifest data from various sources. Manipulation of this metadata has been shown to be an integral part of an SSC attack [17, 20]. To address this SSC security gap, researchers have suggested integrating a private blockchain to remove the hacker’s ability to alter SBOM entries [22]. Blockchain’s decentralized and immutable nature provides a transparent and tamper-resistant ledger for SSC security by tracking software components, verifying their integrity, and enhancing supply chain transparency. It provides an immutable and decentralized ledger that enhances trust and accountability in the supply chain [17]. An example has been demonstrated by Let’sTrace, which combines blockchain technology, federated learning, and both TUF [16] and in-toto [19] to enhance provenance in the cyber supply chain. Let’sTrace leverages blockchain technology to enable “smart contracts” for blockchain transactions, which establishes an immutable and transparent ledger for monitoring supply chain activities with greater efficiency and speed.

Two examples exist within the literature that could potentially support blockchain integration for SSCs. First, Let’sTrace incorporates TUF and in-toto frameworks to provide secure software updates and ensure the integrity of each step in the supply chain. As discussed earlier, these frameworks verify the authenticity and integrity of software components, preventing unauthorized modifications and ensuring trustworthiness throughout the supply chain [22]. Second, DeepChain is an intelligent framework for SSC security based on blockchain technology that integrates ML techniques to analyze software artifacts, detect anomalies, and identify potential security risks or vulnerabilities using a consensus mechanism based on the blockchain network to ensure the immutability and transparency of SSC activities [23]. Its enhanced data privacy and secure communications within the supply chain align with governance best practices through enhanced traceability, improved security auditing, and efficient collaboration among supply chain participants.

AI Models

AI models present multifaceted utilities for improving SSC security. AI algorithms can analyze vast amounts of data, detect patterns, and identify anomalies, allowing for faster and more accurate security assessments. (Note: A detailed discussion about specific AI approaches is beyond the scope of this article; however, Bandara et al. [22] provide ample motivation and treatment for the subject, leveraging a federated learning approach in support of SSC security.)

For SSCs, AI forms one layer of the proposed defense in-depth strategy to provide risk assessment associated with software components, repositories, software providers, DIB SIs, and other SSC providers within the supply chain. For example, AI that continuously assesses vendor reputation and their security track record (e.g., an analog to the three-digit consumer credit score used by vendors to track and rate financial risk) can be a source of enrichment for making informed decisions for selecting and managing software suppliers and alerting security operators if vendors fall below an accepted threshold [24, 25].

A core goal of AI is to integrate within current workflows and tools to automate and orchestrate various security processes within the SSC. This includes automating vulnerability scanning, threat detection, and incident response for improving response times and enabling efficiency in workflows. These techniques are being employed to establish baseline behaviors and analyze deviations to help identify potential security threats, including malicious code injections, unauthorized access, and unusual patterns of behavior (Microsoft research has active efforts in this area; see Figure 5). AI enables predictive analytics in SSC security. By analyzing historical data, AI models can forecast potential security risks and vulnerabilities, helping organizations proactively address them before they manifest.

Figure 5

Figure 5. Overview of the Commit Detector Components, Data Flow, and Output in the “Anomalicious” Tool Proposed in 2021 (Source:  Gonzalez et al. [26]; Made Available by CC BY 4.0).

Predictive analytics also assist in risk assessment, identifying weak points in the supply chain and implementing preventive measures. AI-powered tools are being used to gather, analyze, and share threat intelligence across the SSC ecosystem. These tools typically consist of the following components: (1) enterprise order management validation through attestations, (2) audit trails for provenance (i.e., artifact creation, lineage, and modification), and (3) audit trail integration for people-product integrated SBOMs (e.g., products like ActiveState, GitLab, and Tenable can support these functions). Disseminating actionable intelligence to relevant stakeholders promotes process efficiencies through collaboration and enables a more comprehensive approach to security across the supply chain.

A necessary element of AI consists of identifying potential vulnerabilities in software components/modules/libraries to ensure compliance with security standards while recommending secure coding practices. Development Security Operations (DevSecOps) pipelines can effectively incorporate AI into the build process/development lifecycle to enable organizations minimization of vulnerabilities injected by bad actors that could be exploited in the supply chain [27].

AI-powered systems can continuously monitor an SSC in real-time, detecting suspicious activities and unauthorized access. AI is well-suited for automation of regular security audits and assessments of the SSC to identify potential vulnerabilities, risks, and gaps in security controls (i.e., alignment with RMF, C-SCRM, and CSF). This enables organizations to proactively address potential exploits and vulnerabilities while receiving timely alerts to facilitate more rapid response to security incidents and mitigate potential damage. In addition, the ability to instrument AI in conjunction with security documentation workflows can facilitate autocompletion and updating of required compliance documentation. AI can also be engineered within workflows in security orchestration automation and remediation (SOAR) tools to automate various security processes, reducing manual effort and increasing efficiency. Tasks such as vulnerability scanning, threat intelligence analysis, and incident response can be actively integrated within SOAR and/or DevSecOps pipelines, freeing up security personnel from manually intensive processes to focus on more complex issues [24, 25, 27].

The ID.SC portion of Identify within the NIST CSF [1], the best practices within C-SCRM recommendations [2] and RMF [3] for SSC security, provide high-level guidance to identify, assess, and mitigate risks introduced through supply chain vulnerabilities. These all lend themselves to governance workflows and processes that center around collaboration, communication, and documentation between various parties and stakeholders within an organization.

Conclusions

The integration of AI in SSC security could empower both military and key national security SSC systems to enhance their threat detection, response capabilities, operational efficiency, risk assessment, and overall resilience against cyberthreats. Effective AI-enabled systems can empower leadership to stay ahead of emerging risks, protect critical systems, and safeguard sensitive information–together significantly enhancing the security posture of the nation. By leveraging AI in a layered, defense-in-depth SSC security architecture, the government can improve its ability to detect and respond to attacks, secure critical systems, and maintain the integrity of the SSC, thereby enhancing overall cybersecurity readiness.

References

  1. NIST. Framework for Improving Critical Infrastructure Cybersecurity (CSF). Version 1.1, https://www.nist.gov/cyberframework/framework, 16 April 2018.
  2. NIST. Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations. Special Publication 800-161 Revision 1, https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-161r1.pdf, May 2022.
  3. NIST. “NIST Risk Management Framework (RMF).” Special Publication 800-5, https://csrc.nist.gov/Projects/risk-management/sp800-53-controls/downloads, 6 July 2023.
  4. Tucker, P. “How DoD Is Experimenting With AI for Enhanced Cybersecurity.” DefenseOnehttps://www.defenseone.com/technology/2023/05/how-dod-experimenting-ai-enhanced-cybersecurity/385922/, 3 May 2023.
  5. Dretzka, E. “Technical Exchange Patterns With [x]BOMs.” DoD CDAO, https://repo1.dso.mil/platform-one/bullhorn-delivery-static-assets/-/raw/master/cso/community-of-practice/04-13-2023-DevSecOps-CoP-SW-Modernization-I-Plan-FINALv3.pdf, pp. 23–34, 14 April 2023.
  6. Red Hat, Inc. “What Is Software Supply Chain Security?” https://www.redhat.com/en/topics/security/what-is-software-supply-chain-security, 14 December 2022.
  7. Zetter, K. “The Untold Story of the Boldest Supply-Chain Hack Ever.” WIREDhttps://www.wired.com/story/the-untold-story-of-solarwinds-the-boldest-supply-chain-hack-ever/, 2 May 2023.
  8. Wong, W. “Keep Software Supply Chains Secure With New Federal Guidance.” FedTech Magazinehttps://fedtechmagazine.com/article/2023/03/keep-software-supply-chains-secure-new-federal-guidance, 7 March 2023.
  9. U.S. GAO. “Cybersecurity: Federal Response to SolarWinds and Microsoft Exchange Incidents.” GAO-22-104746, report to congressional addressees, https://www.gao.gov/products/gao-22-104746, 13 January 2022.
  10. The White House. National Cybersecurity Strategy Implementation Plan. Washington, DC, https://www.whitehouse.gov/wp-content/uploads/2023/07/National-Cybersecurity-Strategy-Implementation-Plan-WH.gov_.pdf, 13 July 2023.
  11. U.S. DoD. “Supply Chain Risk Management Framework, Project Report – Phase I.” OASD(S), https://www.acq.osd.mil/log/LMR/.scrm_report.html/DoD_SCRM_Framework_ Report_Phase_I.pdf, 15 February 2023.
  12. U.S. GAO. “Information and Communications Technology: DoD Needs to Fully Implement Foundational Practices to Manage Supply Chain Risks.” GAO-23-105612, report to congressional committees, https://www.gao.gov/assets/gao-23-105612.pdf, 18 May 2023.
  13. Herr, T. “Breaking Trust– Shades of Crisis Across an Insecure Software Supply Chain.” Presentation at the USENIX Enigma 2021 conference, virtual seminar, https://www.usenix.org/conference/enigma2021/presentation/herr, 2 February 2021.
  14. Boyens, J., C. Paulsen, N. Bartol, K. Winkler, and J. Gimbi. “Key Practices in Cyber Supply Chain Risk Management: Observations From Industry.” NIST Interagency Report 8276, https://nvlpubs.nist.gov/nistpubs/ir/2021/NIST.IR.8276.pdf, February 2021.
  15. Samuel, J., N. Mathewson, J. Cappos, and R. Dingledine. “Survivable Key Compromise in Software Update Systems.” New York, NY: Association for Computing Machinery, Proceedings of the 17th ACM Conference on Computer and Communications Security, https://doi.org/10.1145/1866307.1866315, October 2010.
  16. TUF. “Overview.” https://theupdateframework.io/overview/, accessed on 20 July 2023.
  17. Shetty, S. “Assured Cyber Supply Chain Provenance Using Permissioned Blockchain.” Project overview, University of Illinois Urbana–Champaign, https://iti.illinois.edu/credc/researchactivity/assured-cyber-supply-chain-provenance-using-permissioned-blockchain, 2020.
  18. U.S. Department of Homeland Security. “Recommended Practice: Improving Industrial Control System Cybersecurity with Defense-in-Depth Strategies.” Industrial Control Systems Cyber Emergency Response Team, https://www.cisa.gov/sites/default/files/recommended_practices/NCCIC_ICS-CERT_Defense_in_Depth_2016_S508C.pdf, September 2016.
  19. in-toto. “What Is In-Toto?” https://in-toto.io/in-toto/, accessed on 20 July 2023.
  20. Shetty, S. S., C. A. Kamhoua, and L. L. Njila, eds. Blockchain for Distributed Systems Security. Hoboken: John Wiley & Sons, 2019.
  21. U.S. NSA, CISA, and ODNI. “Securing the Software Supply Chain: Recommended Practices Guide for Developers.” Ensuring Security Framework (ESF) Working Panel, https://media.defense.gov/2022/Sep/01/2003068942/-1/-1/0/ESF_SECURING_THE_SOFTWARE_SUPPLY_CHAIN_DEVELOPERS.PDF, August 2022.
  22. Bandara, E., S. Shetty, A. Rahman, and R. Mukkamala. “Let’sTrace — Blockchain, Federated Learning and TUF/In-Toto Enabled Cyber Supply Chain Provenance Platform.” Presented at the 2021 IEEE Military Communications Conference (MILCOM), San Diego, CA, https://doi.org/10.1109/MILCOM52596.2021.9653024, 29 November–2 December 2021.
  23. Weng, J., J. Weng, J. Zhang, M. Li, Y. Zhang, and W. Luo. “DeepChain: Auditable and Privacy-Preserving Deep Learning with Blockchain-Based Incentive.” IEEE Transactions on Dependable and Secure Computing, vol. 18, no. 5, pp. 2438–2455, https://doi.org/10.1109/TDSC.2019.2952332, 1 September–October 2021.
  24. Yang, J., Y. Lee, and A. P. McDonald. “SolarWinds Software Supply Chain Security: Better Protection With Enforced Policies and Technologies.” In R. Lee (ed.), Software Engineering, Artificial Intelligence, Networking and Parallel/Distributed Computing, Springer, https://doi.org/10.1007/978-3-030-92317-4_4, January 2022.
  25. Singh, S. P., J. Rawat, M. Mittal, and C. Bhatt. “Application of AI in SCM or Supply Chain 4.0.” In S. L. Fernandes and T. K. Sharma (eds.), Artificial Intelligence in Industrial Applications, Springer, https://doi.org/10.1007/978-3-030-85383-9_4, December 2021.
  26. Gonzalez, D., T. Zimmerman, P. Godefroid, and M. Schaefer. “Anomalicious: Automated Detection of Anomalous and Potentially Malicious Commits on GitHub.” Presented at the 2021 International Conference on Software Engineering (ICSE), retrieved from the arXiv database, https://arxiv.org/abs/2103.03846, 9 March 2021.
  27. Akter, M. S., et al. “Software Supply Chain Vulnerabilities Detection in Source Code: Performance Comparison Between Traditional and Quantum Machine Learning Algorithms.” The 2022 IEEE International Conference on Big Data, Osaka, pp. 5639–5645, https://doi.org/10.1109/BigData55660.2022.10020813, December 2022.

Biography

Dr. Abdul Rahman is a subject matter expert in the design and implementation of cloud analytics and architectures that support situational awareness tools for cyber network operations for commercial and government customers. He has over 25 years of information technology experience, including software development, network engineering, systems design, systems architecture, security, and network management. He has published widely on topics in physics, mathematics, and information technology. Dr. Rahman holds Ph.D.’s in mathematics and physics.

Focus Areas

Want to find out more about this topic?

Request a FREE Technical Inquiry!