Given that repurposed third-party code and open-source code are one of the worst threats to enterprise cybersecurity, you might assume that Google addressing the issue would be of great assistance. Think again.
Repurposed third-party code and open-source code are one of the largest threats to enterprise cybersecurity, so you would expect Google’s Assured Open Source Software service to be of great assistance.
Think again.
Google’s pitch is as follows: “Assured OSS enables enterprise and public sector users of open source software to easily integrate the same OSS packages that Google uses into their developer workflows. Packages curated by the Assured OSS service are routinely scanned, analyzed, and fuzz-tested for vulnerabilities; have corresponding enriched metadata incorporating Container/Artifact Analysis data; are built with Cloud Build including evidence of verifiable SLSA-compliance; are verifiably signed by Google; and are distributed from a Google-protected Artifact Registry.”
Depending on the end user, this service may or may not be valuable. For some businesses, particularly small and medium-sized businesses, it may be beneficial for small operations without a dedicated IT team. However, things are drastically different for larger businesses.
As with all aspects of cybersecurity, we must begin with trust. Should IT have faith in Google’s efforts? Many malware-laden or otherwise problematic apps have already been approved for the Google Play app store. (To be fair, this is also true of Apple’s app store.)
This proves my point. Finding security vulnerabilities in code is extraordinarily challenging. No one will do it perfectly, and Google (and Apple) do not have the business model to properly staff those areas. So they rely on unreliable automation.
Don’t get me wrong. What Google is attempting is an excellent endeavor. However, the most important enterprise IT question is whether or not this program permits them to do anything differently. I contend that it will not.
IT must examine every piece of code, especially open source, for bugs. This could consist of malicious software, ransomware, backdoors, or anything else nefarious. However, there will also be accidental holes. It is difficult to completely combat typos and sloppy coding.
It cannot be justified for programmers not to double-check the code generated by this Google program. And no, knowing that Google uses this internally should not make CIOs, IT directors, or CISOs feel warm and fuzzy.
This raises a larger issue: all businesses should check and double-check every line of code they access from outside sources, without exception. Consequently, this is where reality meets the ideal.
Chris Wysopal, one of the founders of the software security firm Veracode, provided compelling arguments when we discussed Google’s move. One disconnect exists between developers and IT management, while another exists between IT management (CIO) and security management (CISO).
Regarding the initial disconnect, IT may issue as many policy announcements as desired. If developers on the ground choose to disregard these directives, enforcement becomes necessary. With every line-of-business executive breathing down IT’s neck and demanding everything immediately — and given that these individuals are the ones generating revenue, they will likely win any battles with the CFO or CEO — enforcement is challenging.
This presupposes that IT has indeed issued edicts mandating that external code be double-checked to determine which code is malicious and which is benign. This is the second point of contention: CISOs, CSOs, and CROs will all want routine code-checking, whereas IT Directors and CIOs may take a less aggressive stance.
This Google action poses a risk that can be described as a false sense of security. There will be a temptation for some IT professionals to use Google’s offering as an excuse to give in to time pressures from LOBs and forego cybersecurity checks on anything from Google’s Assured program. Simply put, this entails placing complete (and blind) faith in Google’s team to catch everything.
I cannot conceive of a Fortune 1000 (or their privately held equivalents) IT executive believing and acting in this manner. But if business leaders are pressuring them to move quickly, it is a relatively face-saving excuse for them to do what they know they shouldn’t.
This forces us to confront some unpleasant truths. Is Google Assured a safer alternative to unchecked code? Absolutely. Will it be flawless? Of course not. Therefore, it is prudent for IT to continue its previous activities and examine all source code. This renders Google’s effort largely irrelevant to the business.
But it’s never that simple, and never has been. Wysopal argues that many businesses do not conduct the necessary checks. Google Assured is an improvement over what we had a month ago if this is true, which I regrettably concede is likely.
In other words, if you are already cutting too many corners and intend to continue doing so, Google’s decision may be beneficial. It is irrelevant if code-checking is rigorous.
Wysopal also argues that Google’s scale is far too small to be of much assistance, regardless of a company’s code-checking methodology. “This project would have to be scaled up tenfold to make a significant impact,” said Wysopal.
What do IT leaders who do not rigorously inspect code do? “They expect someone else to discover the weakness” (and then fix it). The enterprise is a relatively ignorant consumer of open source. “If a vulnerability is discovered by a third party, they want an update system in place,” said Wysopal. “It is uncommon to find a business with a strict policy that is enforced effectively. Most organizations permit developers to choose open source without a strict procedure. As soon as app security begins to impede performance, it is circumvented.
Google’s action is good news for those who have taken too many shortcuts with security. How many of these organizations exist? This is debatable, but I fear that Wysopal may be closer to the truth than anyone would like to admit.
