Challenges of securing a software supply chain
A major area of concern for IT security teams is how to tackle the challenges posed by the increasing use of third-party platforms and services. The need for security that spans third parties applies across physical supply chains, software supply chains and outsourcing contracts.
In its 2021 UK CEO Outlook report, KPMG found that 81% of leaders considered protecting their partner ecosystem and supply chain just as important as building their own organisation’s cyber defences.
In January 2022, the White House convened government and private sector stakeholders to discuss initiatives to improve the security of open source software and ways new collaboration can drive improvement.
US president Joe Biden has made software security a national priority. His executive order on cyber security requires that only companies that use secure software development lifecycle practices and meet specific federal security guidance will be able to sell to the federal government.
The order also calls on the industry to drive forward the use of software bills of materials (SBOMs), which aim to make it easier for people and organisations purchasing software to understand what components were used to build the products they use.
Discussing the risks inherent in a software supply chain, Mike Gillespie, managing director and co-founder of independent security consultancy Advent IM, says: “We know that third-party breaches have been grabbing headlines for the past few years. Not only does this show no signs of changing but, as we continue to work in remote and hybrid styles, the results of poor technology implementation and poor security risk management potentially place more organisations at risk from each other. And we know only too well how fast links between supply chain partners get exploited these days.”
The latest available data from the UK Information Commissioner’s Office (ICO), looking at the third quarter of 2021, found that 51% of organisations have been breached due to a third party in the past 12 months. The ICO found that three-quarters of these breaches were due to third parties having too much privileged access.
Gillespie recommends that organisations work on becoming more joined up with better information flow for risk management. “Too few risk assessments start with a detailed, well-informed threat assessment, which means that risk treatment is often flawed,” he says.
Open source security pipeline
Modern software development draws heavily on using open source components. These components themselves often pull in other open source libraries, building, as the saying goes, on the shoulders of giants.
In May 2021, Biden issued an executive order to improve the security of software by establishing baseline security standards for the development of software sold to the government, which requires software developers to maintain greater visibility into their software and make security data publicly available.
In the complex world of a software supply chain, the challenge for a chief information security officer (CISO) is not only identifying all the potential open source components that have been used in an enterprise system, but also how to audit the maintainers of these projects, to ensure they have established secure coding practices and will fix vulnerabilities in a timely manner.
Given that freely available open source code can be pulled in from a repository like GitHub and then incorporated into enterprise software, there are no guarantees that the provider of the enterprise software will be able to put pressure on the code’s maintainer to fix any issues that arise.
Peter Zaitsev, Percona
Raw open source software tends to come “as is”, with no warranty and no obligations from either side, says Peter Zaitsev, CEO of Percona. “Things happen based on goodwill relationships and negotiations,” he adds. “If you want any guarantees – help and support, bugs fixed, old versions maintained, and so on – this all comes with commercial agreements with companies or individual developers.”
While the open source community talks about the licence of the project, and any code licensed under an open source initiative approved licence qualifies as open source, Zaitsev says: “Most open source is useless abandonware – you can find tens of millions of such projects on GitHub alone. To be useful, an open source project needs more than a licence – it needs at least proper governance.”
This, he says, needs, at the very least, to stipulate how decisions are made on what goes into the project and the way benevolent developers, acting in the interest of the users, can contribute to the project.
“This is why when choosing open source code software to depend on, it is a good idea to choose software with an established track record, backed by a reputable non-commercial organisation (for example, CNCF) or a commercial vendor that is directly interested in the market,” adds Zaitsev.
Many companies contribute open source code they have developed internally to solve a business problem, but they have no commercial interest in that code. One example of such a project is RocksDB, a storage engine maintained by Facebook, which manages the way data and metadata are stored.
Apache Kafka Streams is one of the open source components that makes use of RocksDB. In a blog post he co-wrote, Bruno Cadonna, a software developer at Confluent and Apache committer at Kafka, describes RocksDB as a “highly adaptable, embeddable and persistent key-value store”, adding that “many companies use RocksDB in their infrastructure to get high performance to serve data”.
In the blog, Cadonna and co-author Dhruba Borthakur, chief technology officer at Rockset, describes how to optimise RocksDB for Kafka Streams, for implementing highly scalable and elastic applications and microservices that process and analyse data stored in Kafka.
The blog post illustrates how third-party contributors in the open source community build on open source components to develop new products and services.
RocksDB technology is included in Percona Distribution for MySQL, and MongoRocks is a version of RocksDB for MongoDB. While Confluent, Rockset and Percona have commercial offerings built on top of RocksDB, there is a question of how organisations get things changed in a timely fashion.
“We always found Facebook’s RocksDB team quite practical and reasonable, though as with any internally focused open source, they are naturally focused on their own needs,” says Zaitsev. “They are not building a business around RocksDB.”
The software supply chain issue
Beyond the need for commercial contracts with service-level agreements to support bug fixes and security flaws in open source components, CISOs need to have a grasp of the full end-to-end software supply chain on which the organisation’s enterprise architecture is built.
Petra Wenham, a BCS volunteer with long-standing information security and information assurance experience, warns that the use of third-party platforms and services, and changes to the way a company’s IT infrastructure is provisioned, gives malicious actors a much larger attack surface to play with. Once access has been gained, the attacker has a broader range of opportunities to move through a target company’s IT infrastructure.
“With the assumption that the security team has a solid understanding of the organisation’s business and its internal and external processes, a good starting point would be to map out all the processes and sub-processes – IT, paper and others,” she says.
“The aim of this mapping is to identify the various boundaries between applications and services, including where third parties themselves use third-party services. In doing so, you should be able to identify what type of control you should have over the individual services and the interconnecting boundary between services.”
Elizabeth Huthman, cyber director at KPMG UK, points out that some organisations are smarter in their use of technology to enhance third-party risk management programmes. This, she says, means moving beyond point assessments, which can be out of date in a week, to the use of continuous control monitoring, which allows them to have an always live view of the risk environment.
Huthman says some KPMG clients are building in governance, risk and compliance (GRC) tools for enriched reporting, rather than relying on spreadsheets to input security metrics manually. Others are also trying to build a better picture of their IT landscape to know if another attack like Log4j is going to happen again, and which of the organisation’s suppliers are more susceptible.
But, as Huthman points out, “it is a huge challenge” to understand the risk further down a supply chain. “A lot [of organisations] are digging into the fourth-party layer due to the dependencies between third and fourth parties. I think as an organisation, we have to take a position. You are not going to get all the way down with every supplier. You have to extrapolate.”
The point Huthman makes is relevant to how CISOs manage the security risk inherent in complex enterprise architectures built on layers of highly interdependent software components, some of which may come from organisations – or are based on open source components – where the level of security may be at a lower level than what the business normally deems acceptable.
The reason a larger business may choose to work with smaller, more agile organisations, says Martin Tyley, head of cyber at KPMG UK, is that it enables them to innovate quicker. “Their skills are in agility and they are quick to innovate, but these characteristics come with more risk,” he says. “Sometimes you want someone else to do amazing things and bring in great stuff.”
But this will come at a risk. CISOs will need to balance the risk to the organisation with the risk associated with limiting the ability to innovate by taking advantage of what third-party providers have to offer.