Globally the digital transformation is in its infancy. The number of connected devices and our reliance on software will only continue to grow. While this has innumerable benefits for society and governments, it brings with it challenges that require proactive thought and action. The bad actors, whether they are nation-state actors, organized groups, or lone wolves, are all capable of using the latest technologies to carry-out their missions. As an industry, it is imperative that we move beyond our current modus operandi of reactively securing against threats and move to proactively developing new solutions to close as many attack vectors as possible.

Software supply chain attacks are becoming an increasing threat to industrial and national security. When you expand the definition to include firmware, that threat is amplified exponentially. There are a number of ways that these attacks are initiated or perpetrated, but they all have commonality in the manipulation of “trusted” code bases such as source code, drivers, and installers. The SolarWinds breach brought this vulnerability into the public eye, but there had been numerous breaches prior to SolarWinds and there have been numerous breaches since that attack.

Software supply chain attacks can be used in a number of ways by the bad actor to cause harm to the target, but it cannot be overstated that often times the encompassment of the victims requires a wide arc from the target. These types of attacks can be used to steal sensitive data, take-over machines or networks to launch further attacks, or even shut down critical infrastructure. The 2017 ransomware attack, NotPetya, for example, began from tainted software. Worse yet, these attacks often originate from inside “sealed” software, such was the case with SolarWinds, and can even result from the breach of the code server, as was the case with the PHP code injection when bad actors breached the server. The key takeaway from these examples is that code integrity needs to begin at the very beginning of the development process and continue through execution on the end-user device.

Defending against software supply chain attacks requires a layered approach. The layer we see having significant gaps is the validation layer for the installation and execution of applications. The concept of a validation layer is nothing new. Most applications have some form of validation process that occurs during installation, but in most cases the execution of this validation falls far short of what is required to truly check the code. See SolarWinds, for example.

The solution needs to  offer the flexibility to perform scheduled and on-demand checks to defend against changes to supporting libraries or drivers, as well as periodic checks for applications that run unattended for long periods of time. Another key vulnerability that is often overlooked is the embedded secrets that exist within the code bases themselves. It is believed this played a role in the SolarWinds breach where credentials were stored within plain text, either in the code or XML files. In many cases these credentials are a default password that the administrator is supposed to change. Far too often this does not happen.

To truly authenticate the application, the validation process needs to exist in a separate threat plane, and it needs to validate the actual software package, including source code, libraries, etc. Polymer Proof is a blockchain-based software validation tool that can protect the process from start to finish, including development, review, merge/publish, distribution, and execution. Utilizing Polymer Proof’s blockchain (Polymer Chain) for such a tool creates the necessary and challenging (to bad actors) secondary attack vector, along with powerful immutability not available in more pedestrian methods. As code is created and compiled, hash validation is performed to authenticate the components, as well as the compiled platform. Furthermore, as the application package is distributed and installed, it is checked again against the trusted hashes committed to the blockchain throughout the software development lifecycle. Such checks can also run periodically to prevent manipulation by actors that find alternative paths onto user machines. In addition, with Polymer Proof in place, software can be checked for embedded secrets by checking the hash to ensure the password has been changed, rehash the new package, and proceed. If the password has not been changed the system could begin reminding the administrator to do so – ensuring this critical vulnerability is closed.

Dell currently uses a somewhat similar non-blockchain embedded method to verify BIOS – but without the use of blockchain and a secondary application to perform the checks, the effectiveness of the solution is inadequate – leaving exposed too many opportunities to circumvent the process. Polymer Proof is uniquely positioned to deliver this type of solution for several reasons. First, the throughput capabilities of our blockchain allow even the most widely distributed and used software applications to be checked in real time. Second, while it is true that the hashing could be committed to virtually any blockchain, Polymer Chain is the only one to combine the necessary performance with cost-effectiveness, keeping the solution from being cost prohibitive. Finally, the architecture of our solution ensures virtually every vulnerability gap that can be closed is closed. Polymer Proof has the ability to protect code from the time it is created on a developer’s machine through the time it resides and runs on the end-user’s devices, providing a strong protective layer on the software supply chain.