Software supply chain security is a growing concern and the dynamic nature and speed at which code is developed make it hard to maintain control over the software development lifecycle. On top of that, with nearly 70 – 90 % of applications using open-source software, it’s a challenge to keep track of all of the “suppliers.”
Open source has its advantage in that it saves coding time, reduces time to market, and benefits from the collaborative efforts to improve and maintain the code. However, the widespread use of software to perform critical functions should force organizations to think about ways to mitigate the risk introduced by open-source code. While I applaud the work of the Open-Source Security Foundation (OpenSSF) to increase the security of open-source code and the repositories that store code, the global community of actors looking to attack and disrupt systems has always outpaced the dedicated professionals working to secure an enterprise.
When computer security was in its infancy, the term “trust” was used to describe the state of a system or application. Similar to the discussion of compliance not being the same as security, trust has a deeper meaning than being secure. When we trust a system or application, we have assurance that it will operate as intended and perform the functions for which it was designed. If there is a change to any component in an application, it can cause unintended consequences adversely impacting such things as brand, business, or safety.
Long before supply chain security was a “thing”, there was a requirement for “trusted distribution” for high assurance systems. Trusted distribution included the mechanisms and procedures to ensure that components could not be maliciously modified and identify if they came from a counterfeit source. While the cybersecurity community is focused on access and disclosure, more attention needs to be paid to the integrity of systems and data.
It is almost impossible to ensure the integrity of code developed by third parties but there are ways to provide assurance that applications can be trusted before being deployed in production. The President’s Executive Order 14028 – “Improving the Nation’s Cybersecurity” specifies the creation of a Software Bill of Materials (SBOM) to identify the individual components of an application. The SBOM provides a useful means to identify software versions and potential vulnerabilities, but there are tools that can do deeper inspections to decompose code and identify dependencies. In addition to identifying vulnerabilities, Software Supply Chain Management software can provide contextualized remediation recommendations, so you understand the impact of remediation on your applications.
As code changes and updates take place in an agile development there needs to be a way to continuously monitor that changes do not introduce vulnerabilities or modify API calls or algorithms that could produce unintended consequences. Software Supply Chain Management software can detect when changes are made and provide complete visibility into the application.
When it comes to software supply chain security, I encourage you to pull the chain hard to ensure that it doesn’t break.
Jim Menendez is a Client Service Director for Allied Mission Group, LLC and the author of several documents in the Rainbow Series including NCSC-TG-008 “A Guide to Understanding Trusted Distribution in Trusted Systems.”