Assured Open Source Software service<\/a> would be a big help. <\/span><\/p>\nThink again.<\/span><\/p>\nHere\u2019s Google\u2019s pitch: \u201c<\/span>Assured OSS enables enterprise and public sector users of open source software to easily incorporate the same OSS packages that Google uses into their own developer workflows. Packages curated by the Assured OSS service are regularly 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 an Artifact Registry secured and protected by Google.\u201d<\/span><\/p>\nThis service may or may not be useful, depending on the end-user. For some companies \u2014 especially small and mid-sized businesses \u2014 it might have value for small operations with no dedicated IT team. But for larger enterprises, things are very different.<\/span><\/p>\nLike everything in cybersecurity, we must start with trust. Should IT trust Google\u2019s efforts here? First, we already many malware-laden or otherwise problematic apps have been approved for the Google app store, Google Play. (To be fair, it\u2019s just as bad within Apple\u2019s app store.)<\/span><\/p>\nThat makes the point. Finding any security issues in code is extraordinarily difficult. No one is going to do it perfectly and Google (and Apple) simply don\u2019t have the business model to staff those areas properly. So they rely on automation, which is spotty.\u00a0<\/span><\/p>\nDon’t get me wrong. What Google is attempting is a very good thing. But the key enterprise IT question is whether this program will allow them to do anything differently. I argue that it won\u2019t.<\/span><\/p>\nIT needs to scan every single piece of code \u2014 especially open source \u2014 for any problems. That might include intentional problems, such as malware, ransomware, backdoors, or anything else nefarious. But it will also include accidental holes. It\u2019s hard to fully fight against typos or sloppy coding.\u00a0<\/span><\/p>\nIt\u2019s not as though coders\/programmers can justify not double-checking code that comes from this Google program. And no, the knowledge that this is what Google uses internally shouldn\u2019t make any CIO, IT Director or CISO feel all warm and fuzzy.<\/span><\/p>\nThat brings up a bigger issue: all enterprises <\/span>should<\/span><\/i> check and double-check every line of code that they access from elsewhere \u2014 no exceptions. That said, this is where reality meets ideal.\u00a0<\/span><\/p>\nI discussed the Google move with Chris Wysopal, one of the founders of software security firm Veracode, and he made some compelling points. There are a few disconnects at issue, one between developers\/coders and IT management, the other between IT management (CIO) and security management (CISO).\u00a0<\/span><\/p>\nAs for the first disconnect, IT can issue as many policy proclamations as it wants. If developers in the field choose to ignore those edicts, it comes down to enforcement. With every line-of-business executive breathing down IT\u2019s neck, demanding everything right away \u2014 and those people are the ones generating the revenue, which means they will likely win any battles with the CFO or CEO \u2014enforcement is difficult.<\/span><\/p>\nThat assumes IT has, indeed, issued edicts demanding that outside code be checked twice to see what code is naughty and nice. That\u2019s the second conflict: CISOs, CSOs and CROs will all want code-checking to happen routinely, while IT Directors and CIOs may take a less aggressive position.<\/span><\/p>\nThere is a risk from this Google move, one that can be described as a false sense of security. There will be a temptation from some in IT to use Google\u2019s offering as an opportunity to give in to the time pressure from LOBs and to waive cybersecurity checks on anything from Google\u2019s Assured program. To be blunt, that means deciding to fully (and blindly) trust Google\u2019s team to catch absolutely everything.<\/span><\/p>\nI can\u2019t imagine a Fortune 1000 (or their privately-held counterparts) IT exec believing that and acting that way. But if they’re getting \u00a0pressure from business leaders to move quickly, it\u2019s a relatively face-saving excuse to do what they know they shouldn\u2019t do.<\/span><\/p>\nThis forces us to deal with some uncomfortable facts. Is Google Assured more secure than unchecked code? Absolutely. Will it be perfect? Of course not. Therefore, prudence dictates that IT needs to continue what it was doing before and check all code. That makes Google\u2019s effort rather irrelevant to the enterprise.<\/span><\/p>\nBut it\u2019s not that simple and it never is. Wysopal argues that many enterprises simply do not check what they should. If that’s true \u2014 and I sadly concede it likely is\u2014 then Google Assured is an improvement over what we had last month.<\/span><\/p>\nIn other words, if you\u2019re already cutting too many corners and plan to continue doing so, Google\u2019s move can be a good thing. If you\u2019re strict about code-checking, it\u2019s irrelevant.\u00a0<\/span><\/p>\nWysopal also argues that Google\u2019s scale is far too small to help much, regardless of an enterprise\u2019s code-checking approach. \u201cThis project would have to scale 10-fold to make a big difference,\u201d Wysopal said.\u00a0<\/span><\/p>\nWhat do those IT leaders who do <\/span>not <\/span><\/i>strictly check code do? \u201cThey wait for someone else to find the vulnerability (and then fix it). <\/span>The enterprise is kind of a dumb consumer of open source. If a vulnerability is found by someone else, they want a system in place where they can update,\u201d Wysopal said. \u201cIt\u2019s rare to find an enterprise with a strict policy and that they are enforcing well. Most allow developers to select open source without any strict process. As soon as app security starts to slow things down, it gets bypassed.\u201d<\/span><\/p>\nGoogle\u2019s move is good news for those who’ve cut too many security corners. How many of those enterprises are out there? That\u2019s debatable, but I am afraid that Wysopal may be more right than anyone wants to admit.<\/span><\/p>\nhttp:\/\/www.computerworld.com\/category\/security\/index.rss<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"![](\"https:\/\/images.idgesg.net\/images\/article\/2020\/08\/secure_binary_stream_circuits_lock_data_flow_security_code_coding_process_transaction_by_suebsiri_gettyimages-1035624750_2400x1600-100854428-large.3x2.jpg?auto=webp&quality=85,70\"\/)
<\/p>\n
Credit to Author: Evan Schuman| Date: Tue, 31 May 2022 02:30:00 -0700<\/strong><\/p>\n\n