More than a year after the massive SolarWinds cyber-attack, targeted companies continue to feel its ramifications in reputation and financial cost. Moreover, the global software supply chain remains vulnerable to deep and severe attacks, whether they come again from Russia – now increasingly in the cybersecurity spotlight due to fears of retaliation to U.S. sanctions – or from any other party.
As long as the world continues to choose fast over secure, nothing is safe. No one knows how many potential backdoors the SolarWinds attack alone created, allowing the persistent presence of malicious actors on a seemingly infinite number of networks or when the next attack will happen, with potentially more dire consequences. For example, six months after the discovery of the LOG4J vulnerability and its patches, we know that networks and products worldwide still go unpatched and exploited in all sorts of companies, big and small.
This must change. It must change from the inside out; programmers and developers should start building code more securely in the first place, and those who use cloud services, third-party black box software or the services of hub companies whose networks connect suppliers and customers should better understand how code-development affects security. This increased focus on the underlying technology itself will not completely prevent attacks, but it will reduce their numbers.
There are signs that the industry could indeed be moving in this very-needed direction, or at least toward having more discussions about it. The White House has recently hosted meetings with technology experts focused on this very topic. In addition, this spring, the SEC announced that it might require some companies to report cyber-attacks within four days and give details about their cybersecurity situation. This increased government attention is raising awareness and could also open the door to regulations, or at least universal best practices in coding protocols. Yet, regardless of eventual regulation, developers – and cybersecurity professionals at hub companies – should be thinking more now about the process for securely building their products.
Thinking Beyond Open-Source Coding
Of course, an ideal solution from a security perspective would be to move to open-source code. Although still vulnerable to attacks, open-source coding is transparent, severely crippling the ability of bad actors to conceal themselves. Yet, such an approach will never work on a large scale in the private sector as there is no way to prevent programmers from simply copying others’ novel code, leaving no way to protect intellectual property among software developers.
However, other steps could be nearly as effective, including integrating security features and testing into development tools and processes. For example, making grey and black box penetration testing a routine part of the software production process would go a long way in helping find vulnerabilities in the code that outsiders could potentially later find and access. Ideally, developers could also remedy or repair these vulnerabilities – or at least have crucial insights about them if they are used later.
The Importance of Code-Signing and Scanning Innovations
Implementing other methods to spot security flaws in code, including in open-source code, would also help. Innovations like code-signing would alert developers if any changes were made to the code before they use it, helping to spot hackers or backdoors before the code is implemented into the product. In addition, developing better source-code scanning technology is important for flagging vulnerabilities. Developers should also undergo training focused on building a product with a secure lifecycle and implement security protocols for merging and accessing the product code preventing cyber attacks from occurring due to faulty (or no) SDLC processes.
CISOs Need to Be Proactive
CISOs and IT professionals also have an active role to play. They need to evaluate the security of the products’ underlying code, taking full advantage of the software bills of material (SBOM), which lists all software components, which could soon be required by law – but that is only one side of it. This needs to be coupled with measures of code signing, scanning for flaws and keeping an updated list of components to spot newly-published weaknesses and vulnerabilities. It is increasingly important to ensure contracts with software service providers specify they are adhering to secure development practices.
With the world on high alert, and the private sector especially vulnerable to state-backed cyber-attacks, there has never been a better time to focus on the importance of building more secure code. This does not mean that all other aspects of cybersecurity, including threat intelligence, incident response plans and talented professionals, will be any less important. Yet, if the code underlying the software becomes more secure, these attacks could become fewer in number and their damage less far-reaching.