Pulse Flash Read: Don’t Let Open Source Become Open SoresOpen source, as a concept, seems to encapsulate the best of what the internet was intended for—a truly global teamwork-makes-the-dreamwork coding hivemind built on the principle that information should be shared.It’s a valuable tool for enterprise and amateur coders alike: enterprises make aspects of their code open source, and an aspiring developer on the other side of the world can discover flaws in that code or suggest improvements while simultaneously honing their technical skills. Perfect, right?Of course not. The open book of code that makes up open source libraries also means that whoever desires can peruse those pages purely to find — and exploit — vulnerabilities. Open source is full of these proverbial ‘unknown unknowns’. The communities running open source code databases are, of course, aware of this, and leverage the community hivemind to discover weaknesses and turn some of those ‘unknowns’ into ‘knowns’ by releasing crucial ‘patches’. The key for those using this code in their software is implementing those patches before the bad actors get in. It would be brilliant if the organizations using open-source code simply had to turn on auto-update and leave their devices connected to wifi overnight to implement these patches. However, organizations tend to have geological tech stacks that are formed with layers and layers of code from different eras. Each one of those layers could feature tiny pieces of code from dozens of open source libraries. If one of those libraries becomes compromised, would anyone in IT even remember if they used it? Each instance of open source across the whole code stack could turn into an open wound that, left untreated, could fester into a big problem for the whole organization.Keeping track of the ‘Software Supply Chain’ that forms the code stack is near impossible for teams relying on human oversight. Just because Hollywood Hackers spend Red Bull-fueled nights searching open source libraries for vulnerabilities doesn’t mean the security team can operate 24/7. It’s a wide issue that needs to be addressed before the tentacular reach of Big Data accelerates beyond the reach of organizations, who may find their data silos are actually about as leak-proof as the White House. Thankfully, awareness is being raised due to efforts such as the Open Source Security Foundation (OSSF), which brings leaders from across industries together with the common goal of increasing knowledge, creating guidelines, and delivering solutions that prevent open source security issues.Though we’ve seen DevOps adoption rise over the last few years to enhance cross-team continuous development efforts, embedding security into that collaborative effort seems to be proving problematic. Not from a tech standpoint. That might be the easier fix. The problem seems to stem from an internal culture stalemate. Dev and Sec simply don’t want to be teaming up to form any kind of common language or goal (though here’s a handy guide to how that might be overcome).While that’s a problem that needs some innovation and real-talk to fix, a number of vendors have stepped up to push security into that category, offering external DevSecOps tools specifically to tackle open source security (OSS). GitHub, perhaps the apogee of the open source community, has developed a suite of tools that automate security detection and deployment (including the reassuringly named ‘Dependabots’) and recently joined the OSSF. Synopsys stands alone in the top right corner of the Gartner Magic Quadrant in the category Gartner calls ‘Application Security Testing’, offering ‘end-to-end’ integration of automated security tools, from training through integration to management. HCL Software is named in the ‘visionary’ section of that same Magic Quadrant, and offers an affordable yet robust-sounding tool suite meant to augment the DevOps process called ‘OneTool’. Contrast deploys an ‘Intelligent Agent’ to detect and scan open source libraries within codestacks, enforcing custom policies in real-time. WhiteSource is aimed at those who are specifically seeking out open source libraries for development, and, frankly, has the nicest looking website. Maybe, if DevOps can find a way to fit security into a loving embrace and truly form the desired DevSecOps, and with the right toolkit, auto-update in some sense might just be possible after all.

Question

Pulse Flash Read: Don’t Let Open Source Become Open SoresOpen source, as a concept, seems to encapsulate the best of what the internet was intended for—a truly global teamwork-makes-the-dreamwork coding hivemind built on the principle that information should be shared.It’s a valuable tool for enterprise and amateur coders alike: enterprises make aspects of their code open source, and an aspiring developer on the other side of the world can discover flaws in that code or suggest improvements while simultaneously honing their technical skills. Perfect, right?Of course not. The open book of code that makes up open source libraries also means that whoever desires can peruse those pages purely to find — and exploit — vulnerabilities. Open source is full of these proverbial ‘unknown unknowns’. The communities running open source code databases are, of course, aware of this, and leverage the community hivemind to discover weaknesses and turn some of those ‘unknowns’ into ‘knowns’ by releasing crucial ‘patches’. The key for those using this code in their software is implementing those patches before the bad actors get in. It would be brilliant if the organizations using open-source code simply had to turn on auto-update and leave their devices connected to wifi overnight to implement these patches. However, organizations tend to have geological tech stacks that are formed with layers and layers of code from different eras. Each one of those layers could feature tiny pieces of code from dozens of open source libraries. If one of those libraries becomes compromised, would anyone in IT even remember if they used it? Each instance of open source across the whole code stack could turn into an open wound that, left untreated, could fester into a big problem for the whole organization.Keeping track of the ‘Software Supply Chain’ that forms the code stack is near impossible for teams relying on human oversight. Just because Hollywood Hackers spend Red Bull-fueled nights searching open source libraries for vulnerabilities doesn’t mean the security team can operate 24/7. It’s a wide issue that needs to be addressed before the tentacular reach of Big Data accelerates beyond the reach of organizations, who may find their data silos are actually about as leak-proof as the White House. Thankfully, awareness is being raised due to efforts such as the Open Source Security Foundation (OSSF), which brings leaders from across industries together with the common goal of increasing knowledge, creating guidelines, and delivering solutions that prevent open source security issues.Though we’ve seen DevOps adoption rise over the last few years to enhance cross-team continuous development efforts, embedding security into that collaborative effort seems to be proving problematic. Not from a tech standpoint. That might be the easier fix. The problem seems to stem from an internal culture stalemate. Dev and Sec simply don’t want to be teaming up to form any kind of common language or goal (though here’s a handy guide to how that might be overcome).While that’s a problem that needs some innovation and real-talk to fix, a number of vendors have stepped up to push security into that category, offering external DevSecOps tools specifically to tackle open source security (OSS). GitHub, perhaps the apogee of the open source community, has developed a suite of tools that automate security detection and deployment (including the reassuringly named ‘Dependabots’) and recently joined the OSSF. Synopsys stands alone in the top right corner of the Gartner Magic Quadrant in the category Gartner calls ‘Application Security Testing’, offering ‘end-to-end’ integration of automated security tools, from training through integration to management. HCL Software is named in the ‘visionary’ section of that same Magic Quadrant, and offers an affordable yet robust-sounding tool suite meant to augment the DevOps process called ‘OneTool’. Contrast deploys an ‘Intelligent Agent’ to detect and scan open source libraries within codestacks, enforcing custom policies in real-time. WhiteSource is aimed at those who are specifically seeking out open source libraries for development, and, frankly, has the nicest looking website. Maybe, if DevOps can find a way to fit security into a loving embrace and truly form the desired DevSecOps, and with the right toolkit, auto-update in some sense might just be possible after all.