Digital supply chains are even more opaque than physical ones, and software supply chain attacks are on the rise: 61% of US businesses were impacted in the year up to April 2023. Yet, according to Gartner, only a few organisations have taken adequate steps to evaluate their supply chain cyber risks. This Gartner report provides three practices companies can use to detect and prevent supply chain attacks.
To help mitigate these threats, organisations can request software bills of materials (SBOMs) from their suppliers.
To address cyber risk in the supply chain, Gartner suggests three practices:
1. Adding software supply chain to vendor risk management
- Traditional external third-party risk management assessments (Security Scorecard, BitSight, Black Kite) do not provide an in-depth review of the software supply chain.
- A better approach is to request and evaluate evidence provided by the vendor. Vendors increasingly expect such questions during the procurement process.
- A vendor’s inability or unwillingness to accommodate such requests is an adverse signal of risk and should disqualify the vendor.
- When querying vendors, companies can use frameworks such as the “Secure Software Development Framework” (SSDF), published by NIST in response to the U.S. Presidential Executive Order 14028. It outlines four pillars.
- Preparing the organisation: Ensure people, processes and technology are ready to develop software in a secure manner. This includes defining security requirements, establishing appropriate roles and responsibilities and supporting toolchains.
- Protecting the software: Suggested practices include measures to prevent unauthorised access and tampering and verifying release integrity.
- Producing well-secured software: This includes secure software design, automated and manual review of code, and reuse of existing, well-secured software.
- Responding to vulnerabilities: This includes identifying and confirming the presence of vulnerabilities, along with prioritising and remediating them.
2. Demanding transparent into application security practices of vendors – alongside the composition and contents of the software they provide
- Commercial software increasingly relies on open-source and commercially sourced software libraries. The reuse of existing libraries offers benefits but introduces digital supply chain risks.
- The best-known example of this is the Apache Log4J vulnerability.
- Transparency can be achieved with SBOMs (software bill of materials). SBOMs list the individual components used in the creation of software.
- The inability or unwillingness of a vendor to provide an SBOM should be viewed as a risk and potentially disqualifying.
- SBOMs are created in a machine-readable format to facilitate data transfer between parties and to support automated review of them. Two principle formats are used to create SBOMs:
- SPDX, sponsored by the Linux Foundation, is codified in the ISO/IEC 5962 standard.
- CycloneDX is a project of the OWASP Foundation, seen as heavily focusing on security.
- SBOMs can speed up the response to serious vulnerabilities. Log4J was such a challenge because many organisations had no quick way to determine which piece of their software estate used the vulnerable code. SBOMs solve that problem.
3. Implementing dedicated testing and security evaluations for software that supports high-value or very sensitive systems.
- More aggressive security assessments are justified for systems that run extremely sensitive data or support critical functions. The same applies to those vendors who are perceived to pose a high level of risk but are required to fulfil the business purpose.
- For these critical systems, Gartner recommends establishing a cross-functional team of stakeholders, including from the vendor risk management function, the legal counsel, procurement, and line of business managers.
- A limited number of security vendors possess the capability to run automatic analysis of code to detect malware (e.g., ReversingLabs or Grammatech). These tools should be considered for high-value systems in addition to penetration testing or fuzzy testing.
- Before analysing external code, organisations should consult with their legal counsel to confirm their rights to perform testing.