Dmitry Nikolaev - stock.adobe.co
Everyone knows the importance of updating software, but what about when software development teams encounter new versions of programming languages or frameworks?
Keeping codebase components up to date must be a top priority on any security checklist. If there is a vulnerability in open source code, it will inevitably become a vulnerability in any application using that code.
Software development today relies heavily on open source components -- by some accounts 60 to 80% of an application's codebase is open source. Beyond the slew of programming languages -- C, PHP and Java, to name a few -- there are several open source frameworks developers use. These code libraries -- including Laravel, Rails, Vue, Angular and jQuery Mobile -- provide a fundamental structure to support the development of an application.
With so many open source pieces in use -- and no shortage of vulnerabilities in open source code -- it's no surprise the challenge has made the OWASP Top 10 list every year since 2013.
As OWASP explained, "applications and APIs using components with known vulnerabilities may undermine application defenses and enable various attacks and impacts."
So why don't developers just update to the latest version code when it is released? Many are reluctant to upgrade development frameworks and components, fearing they may not be fully backward compatible and thus require a lot of time and effort to ensure the update doesn't break the application.
It is vital the codebase update process be built into each project's timeline. Any vulnerabilities found in a popular open source framework or component will be heavily exploited by hackers who are able to automate attacks against a large user base.
Here are three steps that can help developers maintain and complete the daunting task of ensuring secure codebase updates.
1. Create a codebase inventory
Project managers need to know exactly which components and frameworks are being used in each and every application. The 2017 Equifax breach occurred due to a vulnerable open source Apache Struts component in one of its customer web portals that the company was unaware was in use. Documenting and tracking each third-party component and how it is being used will enable development teams to know which software is running which functions in which application.
Knowing which component functions are in use also helps with patch prioritization. For example, if a vulnerable function is not being used, it is not high risk. Likewise, having a codebase component inventory can help in consolidation. If various components perform the same functions, consider opting for just one and remove the rest to reduce the number of possible updates and patches -- and, thus, potential vulnerabilities. Classifying the importance of each component in terms of criticality to business functions also helps during threat assessment and remediation strategies as prioritization is essential for teams to keep their applications secure while maintaining overall productivity.
2. Keep things patched
Even armed with a complete inventory of components, it is vital that app developers and security teams keep up with vendor updates and patch announcements. However, this can be tricky as information on open source vulnerabilities tends to be distributed across different sources. To keep things straight and ensure no updates are missed, designate a point person or Slack channel to receive all relevant security updates through whatever channel patch announcements are made.
Note, not every patch or update will be able to be applied immediately if there's a chance it may break the existing application. In these situations, figure out how to reduce the potential effects and likelihood of an exploit until the patch can be applied safely.
3. Employ automation
Automating open source updating and patching makes vulnerability management far more practicable and reduces the burden on development teams. Software composition analysis tools can help teams run automated security checks, identify open source components and libraries in their environments, and detect which components have known vulnerabilities that may put an application at risk. Tools such as WhiteSource and Black Duck can automatically find and fix open source security issues or open a pull request with updated versions when they detect an unsafe version in use.
Despite best efforts, some vulnerabilities may still make it through to production code. All pertinent information -- such as the component register, source code, documentation and emergency response plan -- must be readily available to enable post-release servicing of the application. An emergency response plan should cover how to handle critical patches as any application sitting on the internet will need a rapid response to prevent an attack exploiting any newly discovered vulnerability from succeeding.