When nights are getting longer – part III
We pick up the threads from Digital Security 2020 and 2021 and take a closer look at risks related to software supply chains and continuity risks in supply chains.
IN DIGITAL SECURITY 20206 we first addressed supply chain risk in the article When the nights get long7. The article focused on security in the supplier interface, requirements setting, and how to create incentives and collaboration for security in deliveries, the supplier organisation, and down the underlying supply chain. In Digital Security 20218, we delved into software supply chain risk, and how best to defend against malicious attacks that would threaten a company's ability to conduct operations and serve its customers.
Everyone would wish, of course, that by now the topic of security in supply chains would have resolved itself. But alas, it is still highly relevant.
So now, in 2023 – after a 1-year hiatus from focusing on this topic in this publication – we once again address risks related to software supply chains and how the software bill of materials (SBOM) can contribute to handling them. Additionally, we look into continuity risks in supply chains, an issue also highlighted by the Defence and Total Preparedness Commissions in Norway.
Software Supply Chain
Threat actors are increasingly focusing on indirect attack vectors such as delivery and supplier chain attacks. Within software supply chain attacks, several sources report a dramatic increase. Sonatype, for example, reports a 633% increase over the past year in its latest edition of State of the Software Supply Chain9. Some of the explanation may lie in a fact Veracode highlights in its State of Software Security report10: Based on Veracode’s observations, “79% of the time, once a library is included, it never gets updated.”
Select Recent Attacks
Among major attacks of late, we can particularly take note of and learn from the following:
Okta
The identity and authorisation service Okta, Inc. was in the crosshairs of no less than three supply chain attacks in 2022.
In January, a subcontractor for call centre and customer service, Sitel, was compromised by the extortion group Lapsu$, which demonstrated its access by displaying screenshots of Okta's internal systems. Investigations revealed that customer data belonging to 366 businesses, approximately 2.5% of Okta's customers, was compromised. The entry point was through a third-party company, Sykes, recently acquired by Sitel.
In August, the IP telephony company Twilio was compromised – a service Okta used for sending one-time codes to its customers. A "minor number" of phone numbers and one-time codes were affected.
These first two incidents point towards the need for requirements for, and verification of, security in suppliers. It also highlights the need for security reviews as part of due diligence in acquisitions.
Finally, in December, parts of Okta's source code were exposed to unauthorised individuals when their GitHub account was compromised. Whether this last incident is definitively classified as a supply chain attack is not clear; there is speculation that the access was facilitated through one of the two previous incidents. Okta's statement that "Okta does not rely on the confidentiality of its source code for the security of its services" is somewhat reassuring: that's how it should be. However, access to source code is still useful to adversaries looking for exploitable vulnerabilities.
Theft of API keys and similar tokens often results from inadequate application security or weak handling of secrets (tokens, keys, etc.) in applications, development, build, and test environments.
GitHub
In April, GitHub was hit by a type of attack that has gained significant momentum in recent years: theft of various forms of authentication and access tokens.
This could involve information in cookies and short-lived access tokens, or longer-lived keys and session IDs. In the specific case, attackers successfully obtained OAuth access tokens – a form of identifying token used to provide access over a configurable period of time without requiring re-authentication – issued to third-party integrators Heroku and Travis CI. With the stolen OAuth tokens, attackers gained access to organisations using Heroku Dashboard and Travis CI products.
GitHub's investigations revealed that the attackers systematically searched downloaded content for additional keys and tokens that could provide even more access. In this way, the attackers obtained, among other things, an AWS API key. This then granted them access to GitHub's Node Package Manager (npm) production environment. Fortunately, without the ability to modify any npm packages, they could only download code.
There are several points to note here. First, theft of API keys and similar tokens often results from inadequate application security or weak handling of secrets (tokens, keys, etc.) in applications, development, build, and test environments.
Second, the cleanup and removal of old permissions that are no longer in use is another often- overlooked point, both in professional application development and use, as well as when we as individuals authorise third-party services and apps for access to our accounts on social media. It is reasonable to assume that in some organisations where Heroku and Travis CI tools were once authorised for access, the organisations no longer actively used these products.
Finally, the handling and follow-up measures taken have been commendable, from all parties involved.
GitHub, regardless of the incident, developed a service that scans code for secrets before it is uploaded to distribution channels.
From a supply chain perspective, it is worth highlighting notification and action: GitHub was quick to notify all affected users, and both Heroku and Travis CI notified their customers and implemented revocation and reissuance of tokens and keys for their services. The latter is not an easy decision, as it affects their services and customers, but it is the right decision to minimise damage and security risks.
Fishpig
For those who may not have heard of FishPig before, it is software for integration between the extremely popular publishing platform WordPress and the very widely used e-commerce software Magento. FishPig is used in over 200,000 online stores.
Attackers compromised FishPig's distribution servers, i.e. the servers from which customers retrieve software and updates. They uploaded modified versions of the software that, when downloaded and installed, infected customers' systems with the Rekoobe trojan, providing attackers with a backdoor into customers' systems. The damage potential was significant, as these are online stores with payment functions. Magento-based online stores have been a favoured target for financially motivated threat actors for years, leading to significant losses in some cases.
There may be reason to question the security monitoring at FishPig, as attackers had access for about 12 weeks before the then ongoing supply chain attack was uncovered.
From a supply chain perspective, this type of attack is challenging for customers because attackers succeeded in including their code in seemingly authentic software. Mechanisms for automatic updates – generally recommended from a security standpoint
– also limit the possibilities for actions such as test-running the update in security-instrumented test and sandbox environments before installation in production. In any case, measures such as test-running the update would be excessively resource-intensive for many of the affected customers.
While these attacks are challenging, better planning might have helped. Rekoobe is a known malware family, and endpoint detection and response (EDR) tools on Linux servers can be an effective tactic to detect its presence and behaviour. It is also crucial to subscribe to and respond to alerts from suppliers.
After the incident, FishPig provided exemplary guidance to affected customers, such as tools that enable even customers with limited expertise to clean up a compromised online store.
3CX
In March 2023, it was revealed that software from the IP telephony company 3CX had been compromised. The exact duration is unclear, but the first reports of observed anomalies among user organisations – initially assumed to be false positives – emerged March 22.
The legitimate software of 3CX, used by over 600,000 companies and more than 12 million daily end-users, turned out to have been supplemented with malicious code for DLL sideloading. In simple terms, this involves inclusion of instructions in the software installation routine to fetch additional code libraries (DLL) from an external source.
The 3CX attack harkens back to the well-known SolarWinds attack, and really all the way back to the attacks by "APT 1" on managed service providers (MSPs). One thing common to APT1, SolarWinds, and a portfolio of intermediate campaigns is the ability and willingness to use supply chain attacks (which have a very broad, visible impact) to take adversarial action on only a few select targets. This modus operandi, along with the absence of economic gain, points towards intelligence- motivated actors.
From a supply chain perspective, we note that the 3CX attack was actually made possible through another software supply chain attack on a company called Trading Technologies and their software for securities (futures) trading, X_Trader. Several security analysts and media outlets describe this as the first time one software supply chain attack has led to another.
The infected version of XTrader was simply downloaded and installed by an employee at 3CX. There is broad consensus among analysis companies that the XTrader campaign and the subsequent attack through 3CX's software are connected to the North Korean “Lazarus Group”.
The X_Trader campaign targeted several other companies, including at least two power companies in the USA and Europe.
The broad secondary campaign through 3CX, targeting the energy sector, and compromising software for securities trading all raise questions about whether the attacker's motivation was primarily economic or geopolitical. Even with strong attribution, it can be challenging to conclude, as Lazarus Group appears to be motivated by both.
Recursive Dependencies – A Persistent Challenge
We also observe that the organisation of some open-source ecosystems presents security challenges and opportunities for attackers, particularly in the way development handles dependencies. In this case, dependencies refers to code or software modules that another software project relies on and, therefore, is dynamically fetched and included. In some ecosystems, such as npm, these recursive dependency structures can be very deep.
Several attack concepts take advantage of this, as well as other aspects of how open-source development and distributionis organised:
Malicious dependencies – Event-stream incident1, 2018
In August 2018, a developer with the screen name "Antonio Macias" published the flatMap-stream parser library on npm. He contacted the developer responsible for the widely used parser library event-stream and suggested including the flatMap-stream parser library as a dependency to the event-stream parser library. That September, the next version of event-stream was released, dynamically incorporating flatMap-stream code. In October, the codebase of flatMap-stream was updated with malicious code. From that point on, all new installations of event- stream continued to automatically pull in flatMap-stream, thus also including the malicious code into event-stream.
Event-stream is a popular package and itself a dependency in at least 3,931 other packages. However, the real target of the attack was a single software project: the highly popular bitcoin wallet Copay. The introduced code in flatMap-stream was effective only within Copay, enabling the theft of bitcoins and private keys.
Dependency confusion – Alex Birsan, 2021
In Digital Security 2021, we discussed how security researcher Alex Birsan demonstrated “dependency confusion" attacks12 early in the year:
"An additional factor contributing to reducing time and cost is the dynamic use of third-party libraries like Node, JQuery, and Chartbeat. Dynamically included libraries are either downloaded when the application is built or when it runs in a browser. On one hand, such libraries often contribute to more secure code, as they frequently help programmers 'do things right,' while on the other hand, they increase the risk of compromise through the supply chain. This was aptly demonstrated in February when a security researcher described how he had exploited this type of dynamic download by publishing packages with conceptual 'malware' to various public frameworks (npm, RubyGems, and PyPI) with the same or nearly the same names as several major technology companies used for their internal modules."
The consequence was that automatic build tools at the affected companies loaded Birsan’s publicly published software components with the same names, instead of components from the company's private internal codebase. This behaviour basically allows for anyone gaining knowledge of internal package names, to replace private code with their arbitrary code.
Npm Manifest Confusion attack13, 2022
npm packages have a so-called "manifest file," which contains metadata about the code package and lists dependencies on other packages. Former GitHub employee Darcy Clarke has uncovered that there are no mechanisms comparing the published manifest file with the one included in the tar-compressed downloadable code package.
Many software security tools evaluated software packages only on the basis of the information in the standalone manifest file. Build tools, however, orchestrate the build process based on the version included in the tar-compressed package. This provides an opportunity for a publisher or attacker to include malicious or known vulnerable code in the included manifest file, and thus in the built software, while the standalone published manifest file may not mention it and security tools thus not detect it.
Repojacking, 2023
Security company Aqua Security published information14 in the summer of 2023 from a study of 1.25 million code projects on GitHub. They found that nearly 37,000 of the projects were vulnerable to a technique known as repojacking. The technique is simple and involves threat actors registering code projects with project or usernames that are no longer in use. This could be due to the user account being cancelled or the project changing its name. Projects having an affected project as a dependency may be unaware of the change and may thus continue trying to fetch the project's code from the original user account or project name. This gap allows threat actors to publish code that others automatically fetch and use in their projects, simply by re-registering the old name. Aqua Security has only scanned a small sample and claim the actual attack surface to likely be several million code projects – not just the nearly 37,000 identified.
What Do Norwegian Authorities Say?
Norwegian authorities, through reports from PST (Police Security Service), NSM (National Security Authority), and the Intelligence Service, have addressed various forms of threats and attacks through supply chains. We particularly note the following.
PST: National Threat Assessment 2023
«In January 2022, Lithuania experienced a comprehensive and complex reaction from the Chinese authorities when the country allowed Taiwan to open a representative office in Vilnius. Following the incident, Lithuania faced an influence campaign and several digital network operations. Additionally, the country was subjected to extensive supply chain pressure, service interruptions, and other formal and informal sanctions. Meanwhile, companies in Lithuania had difficulties obtaining Chinese parts and components. Chinese authorities also exerted pressure on businesses in other European countries to limit their trade with companies from Lithuania.»
«Over the past year, PST has observed that several state intelligence services or threat actors operating on their behalf have carried out so-called value chain attacks. These are network operations targeting weak and more peripheral points in a company's value chain, such as subcontractors. Companies with robust data security systems and procedures are vulnerable if their subcontractors do not have equivalent security measures. PST expects more network operations of this kind in 2023.»
«State actors employ a broad range of methods to bypass control mechanisms and secure access to technology and knowledge from Norwegian businesses. Tools such as fake documentation, complicated corporate structures, straw and front companies, and supply chains will also be utilised.»
Intelligence Service: Focus 2023
«Collaboration also creates vulnerability. Dependencies in supply chains are exposed, opening the door to extortion.»
NSM (National Security Authority): Risk 2023
«Even if a business has good physical and digital security, threat actors can exploit subcontractors with much weaker security to gain access to their true targets. This means we also need to secure ourselves well on the flanks.»
Several U.S. agencies and bureaus have distinguished them- selves in advocating for the need for transparency in software deliveries and supply chains, emphasising the use of SBOMs.
«Our security is no stronger than the weakest link in the supply chain.»
«Long and complex supply chains still pose a vulnerability that threat actors know how to exploit. In recent years, we have seen many examples of supply chain attacks against providers of ICT services with very large customer bases having extensive consequences.
Outside the digital realm, we also observe threat actors exploiting supply chains to gain access to their true targets. When the goal is to impact a major enterprise, it requires fewer resources to attack a less secure subcontractor or individuals.»
NSM (National Security Authority): Security Advisory
«Threat actors exploit the fact that functions and infrastructure in the state and society are interconnected in complex value chains. Incidents seemingly directed at values in one part of a value chain may, in reality, be constructed to target an actual goal elsewhere in the chain.»
«Insufficient oversight of supply chains and the absence of security requirements for suppliers in acquisitions and projects open up the possibility for threat actors to use procurement processes as a means to access values. Consequently, threat actors can impact the business through suppliers and subcontractors.»
Software Bill of Materials
Software bill of materials (SBOM) is a specification of all the components in a software package. This is now a widely recognised term, but the journey to this point has been long, and there is still some way to go.
SBOM milestones
Among the milestones achieved so far, it is worth highlighting:
October 2015: The SWID Tags standard from NIST published as ISO/IEC 19770-2:2015.
March 2018: Version 1.0 of CycloneDX, an SBOM standard from OWASP.
December 2020: ISO publishes "The ISO International Standard for open source license compliance" (ISO/IEC 5230:2020 – Information technology — OpenChain Specification), with requirements for a process for handling SBOM for delivered software.
2020/2021: The U.S. National Telecommunications and Information Administration (NTIA) publishes significant work from its Software Component Transparency initiative related to SBOM.
February 2021: President Biden signs Executive Order 14017 on
America’s Supply Chain, requiring SBOM for federal acquisitions.
May 2021: President Biden signs Executive Order 14028 on Improving the Nation’s Cybersecurity, requiring, among other things, security testing and vulnerability management, and emphasising the role of SBOM.
July 2021: NIST publishes its Recommended Minimum Standards for Vendor or Developer Verification (Testing) of Software Under Executive Order (EO) 14028.
August 2021: The open SBOM framework SPDX, from the Linux Foundation, is published as the standard ISO/IEC 5962:2021.
April 2023: Version 1.0 of the Supply-Chain Levels for Software Artifacts (SLSA) framework is published by the Open Source Security Foundation.
Despite several contributions being endorsed through the international standardisation organisations ISO and IEC, this list is dominated by United States elements, primarily for two reasons. Firstly, the technology industry and its actors, both on the non-profit and commercial side, are largely based in the U.S. Secondly, there is significant market influence when the U.S. federal sector begins to impose requirements on all its technology suppliers, leading to the operationalisation of directives and certifications, such as EO 14017 and 14028.
These measures, detailed through various directives and certifications not outlined here, have a global impact by compelling relevant suppliers to comply to be eligible for a supplier role going forward. This includes aspects like securing their software development environments, understanding their software supply chains, and being able to document their software deliveries through SBOMs.
A more prominent role in professional advice
Several U.S. agencies and bureaus have distinguished themselves in advocating for the need for transparency in software deliveries and supply chains, emphasising the use of SBOMs. Comprehensive introductory and training materials are available, particularly from the National Telecommunications and Information Administration (NTIA)15 and notably the highly productive Cybersecurity and Infrastructure Security Agency (CISA)16. The latter, for instance, states:
«A «software bill of materials» (SBOM) has emerged as a key building block in software security and software supply chain risk management. A SBOM is a nested inventory, a list of ingredients that make up software components. The SBOM work has advanced since 2018 as a collaborative community effort, driven by National Telecommunications and Information Administration’s (NTIA) multistakeholder process.
CISA will advance the SBOM work by facilitating community engagement, development, and progress, with a focus on scaling and operationalization, as well as tools, new technologies, and new use cases. This website will also be a nexus for the broader set of SBOM resources across the digital ecosystem and around the world.
An SBOM-related concept is the Vulnerability Exploitability eXchange (VEX). A VEX document is an attestation, a form of a security advisory that indicates whether a product or products are affected by a known vulnerability or vulnerabilities.»
In Europe as well, SBOM has gained increased attention from the authorities, including statements from ENISA, which in its Threat Landscape 2022 declares:
«It is almost certain that adversaries will further abuse this lack of visibility into dependencies, as well as the increased complexity and the trust organisations put into their suppliers, to gain a foot- hold within organisations. We need to highlight initiatives such as the Software Bill of Materials (SBOM) that aim at making such things more transparent and auditable. Gaining visibility into the web of third-party relationships and dependencies is a must.»
ENISA similarly emphasises this in Good Practices for Supply Chain Cybersecurity, linking it – like CISA – to vulnerability management:
«The handling of vulnerabilities has two aspects; one aspect is the monitoring of vulnerabilities which leads to an analysis on the vulnerabilities identified up to a patch delivered and deployed. The other aspect is the publishing of advisories, i.e. the vulnerability notifications. A vulnerability notification has the objective to warn product users of critical vulnerabilities and might recommend alternative mitigation measures to minimise the likelihood of an exposure. Tools that support the operators as well as the developers towards this direction are the software bill of materials and Vulnerability Exploitability eXchange concepts, and the Common Security Advisory Framework.»
A selection of relevant specifications and frameworks
CSAF: Common Security Advisory Framework (CSAF)17 is a specification from OASIS for the exchange of structured machine-readable security advisories. The transition to unified machine-readable structures for security advisories, rather than prose text that needs to be crafted and consumed by humans, is crucial for automation—both in terms of generation and, especially, in terms of receiving, processing, and further utilising the information in vulnerability management.
VEX: Vulnerability Exploitability eXchange (VEX) is a structured format for vulnerability information, specifically focused on communicating whether software is vulnerable to a particular vulnerability and providing recommendations for handling it. VEX is an information profile in CSAF, but VEX messages can also be part of other specified information structures, such as CycloneDX.
CycloneDX: OWASP CycloneDX18 is a comprehensive bill of materials (BOM) standard that not only specifies a structure for software bill of materials (SBOM) but also includes:
Software-as-a-service bill of materials (SaaSBOM)
Hardware bill of materials (HBOM)
Operations bill of materials (OBOM)
Vulnerability disclosure reports (VDR)
CycloneDX also has a profile for Vulnerability Exploitability eXchange (VEX)
SPDX: Software Packaged Data Exchange19 is an open standard for the SBOM format, supported by a consortium of stakeholders from the technology industry. It is now also formally standardised as ISO/IEC 5962:2021.
SWID: Software Identification (SWID) Tags is a format for describing a software object and originates from software asset inventory and management since 2012 when it was first specified as an ISO standard. The latest applicable formal standard is ISO/IEC 19770-2:2015. The format is part of specifications by, among others, the Trusted Computing Group (TCG) and the Internet Engineering Task Force (IETF). A SWID tag can also be part of a CycloneDX SBOM.
SLSA: Supply-chain levels for software artifacts20 is a security framework for software manufacturing and distribution. The framework includes guidelines, checklists and controls to counteract illegitimate influence, primarily on the integrity of the software, at all stages from production to use. Where SBOM can be compared to the ingredient list on food items, SLSA can be likened to guidelines for the safe manufacturing, distribution, and storage of food. To clarify, the framework encompasses manufacturing, not development, as SLSA does not address the quality of the code being written as it relates to security, but instead focuses on what happens afterward. The framework is useful for both manufacturers and consumers by providing guidance and measuring good security practices, respectively.
Continued scepticism – the chicken and the egg
While SBOM, along with VEX and CSAF, is promoted by both security professionals in general and influential authorities in particular, there is still some scepticism. Many critics doubt the value of SBOM, as many of the recipients do not have processes and tools in place to leverage the information. The structured information must be received and integrated into the organisation's processes and systems, including asset inventory and vulnerability management, to provide real value. Transfer and processing must also have tool support that facilitates a high degree of automation, as the information is dynamic and updated frequently.
It is legitimate to question the current value of requiring SBOM for all delivered software, especially since many organisations face significant challenges with basic processes and tools in knowing what they have (inventory) and managing vulnerabilities and vulnerability information (referred to collectively as vulnerability management). Vulnerability information, too, must be produced, distributed, and consumed in machine-readable formats that enable automation.
This is, to some extent, a classic "chicken and the egg" problem; no one invests in tools to handle information that does not exist, and few see the need to demand or provide information that few have the capability to effectively leverage.
However, many security experts agree that control over what you have and the vulnerabilities it contains is a prerequisite for adequate digital security. We must start somewhere, and just like the chicken and the egg, there is actually an answer21.
Tool support must also be in place at software producers to generate SBOM and VEX data in a resource-efficient and agile manner, and this tool support may also take time to implement.
Therefore, there is no reason to wait to state demands, and to meet them. Without requirements, nothing happens, and we will have a long wait for both chickens and eggs.
There must first be information to process, even though the tools and processes to manage it optimally and garner maximum value from it are still lacking in many organisations, and similarly remain to be introduced at many software producers. We cannot afford to remain in the status quo.
Today's situation in software management and software security is dire, and current practices do not work and do not scale. We imperatively need to transition to a high degree of automation in the exchange and use of software and vulnerability information.
Ensuring authenticity in opensource code – several initiatives on the horizon
Although code signing and publishing checksums that can be verified upon download are far from new, comprehensive and standardised solutions for scalable signing and traceable authenticity for open-source code have been lacking. This has led to much use of open-source components in software projects either relying on trust on insufficient grounds or depending on retrospective control using third-party tools searching for "known bad." Signing and traceable authenticity for open-source components, libraries, images, and more have therefore gained increasing attention. One such framework is Sigstore22, backed by Google, Redhat, Linux Foundation, Chainguard, and Purdue University.
Another approach to stay ahead, rather than searching for and uncovering malicious influence after the fact, is to use third parties who perform security vetting of popular open-source code and republish it in their own distribution channels. One such service that has gained much attention since its launch in 2022 is Google Assured Open Source Software23. While Sigstore ensures verifiable and traceable origin and authenticity, Google Assured Open Source Software goes considerably further, including:
Build process and documentation in accordance with SLSA-2
Comprehensive SBOM for each package, with additional information such as vulnerability information, in SPDX and VEX formats
Fuzzing24 and vulnerability testing
Distribution from infrastructure operated and secured by Google
Continuity and Availability Risks in Supply Chains
Several events, to some extent coinciding, have posed significant challenges in supply continuity in recent years, highlighting a different type of supply chain risk: supply continuity and availability disruptions. The societal impact of the Covid-19 pandemic, a ship stuck in the Suez Canal25, increased geopolitical tension with conflicts on various fronts, including trade, and the outbreak of war in Europe have each influenced supply continuity in their own way, and underscored how dependent the world has become on supply continuity, and thus vulnerable to such events.
The Pursuit of Efficiency
Since its origin in Japan in the 1950s and 60s, just-in-time production has spread widely as the preferred method for resource- and capital-efficiency optimised manufacturing. The concept, along with the necessary just-in-time logistics, permeates throughout the entire value chain and has, from the 1970s to the 1990s, gained global prevalence across industries.
In short, nothing is produced or delivered to the next link in the supply chain until there is a concrete need, order, or forecasted need for it. There are few or no buffers; all processes are optimised, and inventory is considered "waste" (cf. Lean/Kaizen).
This approach creates a significant need for coordination and vulnerability to consequences in case of disruptions in one part of the supply chain. Both of which only worsens as each link in the supply chain becomes ever more specialised, leading to more suppliers, and supply chains become deeper and broader. This has driven a different dimension of risk in supply chains: supply continuity risk. Including this as a “security risk” might inspire many interesting discussions over semantics and professional terminology, but it is undoubtedly a risk dimension that, since the last time we addressed suppliers and supply chains in Digital Security, has repeatedly manifested itself and gained increased attention. In the context of an increasingly tense geopolitical situation, control over the supply of critical goods and materials has been weaponised.
The Supply Chain – Part of Continuity and Resilience
In Digital Security 202226, largely based on the experiences of disruptions in supply chains and acute needs that arose in Ukraine in the weeks and months following the invasion, we argued that Norway should consider establishing buffer stocks of standard information and communication technologies (ICT) components. However, this is only one proposal within – broadly speaking – one industry. It is in part addressed to Norwegian authorities, based on our reflection that this is a form of essential national resource.
For businesses in general, including actors in critical sectors with fundamental national functions, an assessment of supply continuity risk and measures to address it must be part of each organisation's plans for continuity and resilience.
This opens a Pandora's box of information needs:
Do we have an overview of our critical resources, and do we know who the critical suppliers are?
Have we taken into account that the loss of some resources that may seem less critical in their nature can still cause continuity disruptions to the organisation?
Do we know who the critical sub-suppliers to the suppliers are, and how far down the chain can we gain and maintain visibility?
It also motivates innovative thinking regarding potential risk-reducing measures:
Given foreseeable scenarios in an ever more unpredictable world with heightened geopolitical tensions, could it make sense to actually tie up more capital in stockpiling critical resources?
Can we collaborate with someone on this? Perhaps even competitors? Can industry associations play a role in coordinating joint efforts?
Can we achieve such collaboration among competitors without breaching competition and anti-cartel laws and regulations?
Should we diversify the supply chain and spread supply continuity risk by establishing multiple alternative suppliers for the same critical resources?
Do we then know that the suppliers do not ultimately rely on the same critical input factors/sub-suppliers? (Thus nullifying most of the risk mitigation effect.)
Could the increase in security risk associated with broadening the supply chain, in which more suppliers and sub-suppliers become vectors for supply chain attacks against us, actually be greater than the reduction in supply continuity risk?
From Telenor Digital Security 2022:
It should be considered whether national emergency stockpiles for standard/"Commercial Off-the-Shelf" ICT components should be established. Prioritised product categories and products will require further analysis, but both basic network equipment, servers, and end-user equipment will be relevant. The emergency stockpiles can serve as a national buffer with continuous turnover. The arrangement must be binding for "member companies" to ensure that product categories are not kept in stock for a long time and become outdated. The companies we are referring to here are primarily public and private owners of critical infrastructure supporting essential societal functions.
Highlighted by the commissions
Both the Defence Commission and the Total Preparedness Commission emphasise in their assessments, both generally and within specific sectors, the importance of preparedness and resilience. The vulnerability created by long and complex supply chains is thoroughly discussed, with clear conclusions about the need for strengthening and measures — primarily initiated by, but certainly not exclusively in the context of — government agencies.
It is also noted that many critical components are produced by very few geographically concentrated actors or are dependent on input factors (minerals, etc.) where active sources are geographically concentrated. The vulnerability resulting from super-efficient just-in-time supply chains is also highlighted. Among the commissions' measures, we find: strengthened self-sufficiency, buffers, and emergency stockpiles, supplier diversity for having multiple options, and strict guidelines regarding which countries of origin we should dare to expose ourselves to or become dependent on for supplies.
From the report of the Total Preparedness Commission (NOU 2023:17), we would like to highlight, among other things:
«There is a need for greater resilience regarding the storage of critical input factors and increased self-preparedness. We have experienced a long period of globalisation and increasingly efficient but complex international supply chains. This has provided us with inexpensive trade goods. At the same time, our own stockpiles have been reduced, and in certain areas, we have become dependent on countries and regions with which we do not share common interests.»
«China continues to challenge the Western community in several ways. The country seeks to control strategic infrastructure, resources, and value chains.»
«The pandemic and the war in Ukraine have exposed vulnerabilities related to access to expertise and materials. It is not guaranteed that specialised expertise and spare parts are always available from abroad.»
«Societal functions are becoming increasingly dependent on long and complex digital value chains, making it more challenging to control all involved actors and subcontractors. Dependencies in multiple links increase the risk of vulnerabilities being exploited, digital services becoming unavailable, unauthorised access to sensitive content, and content being altered in a way that makes it uncertain what is genuine or false.»
«The close connection between digital systems and long digital value chains with often unknown dependencies on a large number of actors further complicates the work of digital security.»
«The Commission believes that digital services have become so crucial for maintaining critical societal functions that authorities must take greater responsibility for security across value chains and across all sectors of society.»
«To reduce digital vulnerabilities nationally in critical infrastructure, it has become increasingly important to determine which countries one does not want materials from or other forms of dependence. The Commission believes that going forward, Norwegian authorities must, to an even greater extent, set conditions and provide advice regarding which countries, technologies, and services are considered a risk to national security.»
6 Telenor Digital Sikkerhet 2020: https://www.telenor.no/binaries/om/digital-sikkerhet/Telenor_Digital_Sikkerhet_2020_1.pdf
7 This is a non-translatable pun on the dual meaning of the Norwegian word “nettene”, which can mean both “nights” and “networks”. It is the title of a popular Christmas carol, but in this context doubles up as a pointer to the fact that supply networks have gotten to be very long/wide.
8 Telenor Digital Sikkerhet 2021: https://www.telenor.no/binaries/om/digital-sikkerhet/digitalsikkerhet2021.pdf
9 https://www.sonatype.com/state-of-the-software-supply-chain/about-the-report
10 https://info.veracode.com/report-state-of-software-security-2023.html
11 https://snyk.io/blog/a-post-mortem-of-the-malicious-event-stream-backdoor/
12 https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610
13 https://www.bleepingcomputer.com/news/security/npm-ecosystem-at-risk-from-manifest-confusion-attacks/
14 https://blog.aquasec.com/github-dataset-research-reveals-millions-potentially-vulnerable-to-repojacking
15 https://ntia.gov/page/software-bill-materials
16 https://www.cisa.gov/sbom
17 https://docs.oasis-open.org/csaf/csaf/v2.0/os/csaf-v2.0-os.html
18 https://cyclonedx.org
19 https://spdx.dev
20 https://sisa.dev
21 https://www.science.org.au/curious/earth-environment/which-came-first-chicken-or-egg
22 https://www.sigstore.dev
23 https://cloud.google.com/assured-open-source-software
24 Fuzz testing or “fuzzing” aims to find potentially exploitable coding errors and security issues in software or networks by exposing them to large amounts of random and unexpected input data.
25 https://en.wikipedia.org/wiki/Ever_Given
26 Telenor Digital sikkerhet 2022: https://www.telenor.no/binaries/om/digital-sikkerhet/2022/Digital_sikkerhet_2022.pdf