| | May 202119CIOReviewAccording to the 5th Annual Report on Global Open Source Software Development [1], 85% of modern applications are built from open source components. The percentage is higher for modern JavaScript web applications, with 97% of the code in a modern web application coming from open source component packages. So, you can say that a large majority of your application's code is written by a distributed group of strangers rather than your development team. When it comes to creating applications, the developers usually decide on the programming languages they use. They also select which open-source components to include in their applications. While I am all for empowering developers, there needs to be more due diligence applied to the open source component selection process. Not all open source components are created equal, and in the same annual report [1], 10.3% of all Java libraries downloaded from the maven central repository in 2018 had known vulnerabilities. That figure is higher for JavaScript components, with 51% of the downloaded components having known security vulnerabilities. Vulnerabilities are also prevalent in older components, with those released three years ago or later having 65% more known vulnerabilities [1]. There needs to be an appropriate selection process in place for open source components. This would prevent open source components with known vulnerabilities from being introduced into the application. There has been an uptake of open source consumption in the past five years [1]. And during that time, there has also been a 71% increase in open-source related breaches. The selection process must be lightweight, so it does not impede development, and it should ideally be automated. All new components should be scanned for any known vulnerabilities. It should also be from a reputable source, and the version used should be less than three years old. The benefit of this is not introducing known vulnerabilities into your application and using components that are more likely to be well supported by the open-source community. As modern applications become more dependent on open source components, one of the biggest challenges we're facing is stale dependencies. Stale dependencies are when an application's open-source components become outdated and are not getting the bug or security fixes that have been addressed by their newer versions. Keeping open source components up to date is not a trivial task as new versions are occasionally not backward compatible. They can introduce breaking changes, and there is potentially a substantial economic cost associated with it. However, as open-source components make up a significant portion of an application's code, usually, most of the security vulnerabilities reside. Letting dependencies become stale and only addressing them once a security vulnerability has been detected is disruptive and slows development significantly. While open source components allow applications to be developed quickly, the associated maintenance effort required is often neglected. This is commonly referred to as the open-source "tax". What organisations need to be doing is scheduling work to address this "tax" on a regular basis. A best practice approach is to mandate that applications must not have stale dependencies when released. Besides, time must be set aside to address stale dependencies in the other applications which are not actively being developed. The benefit of reducing stale dependencies is the reduction in the number of future security vulnerabilities and the time required to address them. As the bulk of modern applications are created using open source components, doing due diligence during the open-source selection process and dealing with stale dependencies will address many potential security vulnerabilities. These additional controls, coupled with other vulnerability scanners, automated security scanning tools, and penetration testing, will help to speed up development, create more secure applications and reduce business risks. The future of application security is to shift further left. Edwin Kwan
< Page 9 | Page 11 >