There has been a fundamental shift in the way code is developed in the past 15 to 20 years. Today, developers do far more re-using of existing code than creating code from scratch. Taking advantage of the millions of open source libraries available has become standard operating procedure. And this new model comes with tremendous benefits – both for developers, and for the business – allowing both to move and innovate with unprecedented speed. Ultimately, with everyone creating code this way, it has become a necessary practice in order to remain competitive.
But what about security? Shouldn’t open source code be more secure because it’s got millions of eyeballs on it? The reality is that it’s becoming increasingly clear that the “eyeball theory” is simply not playing out, and that open source code is just as vulnerable as in-house-developed code. In fact, in many ways, open source code is less secure, if you consider that reusable code means reusable vulnerabilities, and that a breach in one piece of open source code has far-reaching implications. And the bad guys know that attacking open source code gives them the most bang for their buck – one breach, millions affected. In addition, with the pace of open source libraries being generated, vulnerabilities are also being generated faster than anyone can keep track of.
How should security professionals approach this new threat landscape? If stopping open source library use is not an option, how do you secure its use? Our Virtual Summit, The Open Source Library Conundrum: Managing Your Risk, set out to tackle this complicated and critical issue. We gathered experts across and beyond our company to give you advice and tips on all sides of this issue – the problem, the solutions, the process, and the technology. Of note is the keynote speaker for this summit, OWASP founder Mark Curphey. CA Veracode recently acquired Mark’s company SourceClear, which has a groundbreaking approach to open source library security – centered around the idea that the accuracy of your security testing of open source code is critical. For instance, you may be using a vulnerable open source library, but are you using the vulnerable part of that library? This approach and Mark’s expertise are woven throughout the Summit.
Check out the Summit to get:
Get more details on the Summit sessions and how to register here.