During a session at RSA Conference 2012, Adobe Systems Inc.'s Brad Arkin said Adobe's Acrobat/Reader product set has thousands of lines of C and C++ code that was written before the year 2000. With that level of technical debt, does the product pose too great of an ongoing threat for enterprises?
The technical debt or legacy code that exists in most major software products, including security products, is perhaps the most significant barrier in maintaining adequate levels of software security in an enterprise. While organizations may enact secure development life cycles for new code under development, legacy code is typically not updated, or even reviewed, for new standards unless a security bug emerges. Organizations with strong systems development life cycles (SDLCs) will go back and find related instances, as Microsoft did for MS12-034, to help minimize the implications of unchecked technical debt from past software development.
Ask the expert!
Have questions about enterprise information security threats for expert Nick Lewis? Send them via email today! (All questions are anonymous.)
Companies can reap significant benefits by rewriting software, APIs, or even major components for operating systems, but as Microsoft demonstrated with its rewrite of the UDP stack for Windows Vista and subsequent security bulletin, there are also risks involved with writing new code. Adobe made some major architectural changes, including the addition of sandboxing, in recent versions of Reader and changed other functionalities that affected security, but it still needs to support its legacy file formats. Supporting legacy file formats or unsecure legacy features also adds to the technical debt.
Enterprises can use an alternative PDF reader to minimize exposure to the unsecured software and avoid some of the technical debt, but if the alternative PDF readers support some of the unsecure functionalities, the initial risk might not be reduced significantly. Alternative PDF readers like the Google Docs PDF viewer and others without the unsecured functionality could be used because they do not need to support the technical debt that Adobe currently supports.
This was first published in September 2012