Companies spend billions of dollars on new software application development, writes Jeff Luszcz, pictured, Vice President of Product Management at software firm Flexera.
Internally developed applications drive competitive advantage for leading companies. Developers often use Open Source Software (OSS) and proprietary components to provide the critical functionality inside these applications. Web-based, external-facing applications are a key opportunity for profitability, but using third-party components without careful oversight is a potential for risk organisations. According to research by Gartner and Symantec, nearly 90 percent of software attacks tend to be aimed at the application layer.
To this end, Chief Security Officers (CSO) invest in firewalls, Web-based authentication, intrusion detection and identity management systems. Yet, these solutions are only securing the perimeter by managing traffic to the applications. None of these solutions focus on securing the applications from the inside out by hardening application code or managing vulnerability defects.
Application security for third-party component strategy requires process, training and tools. It also requires a partnership between security and engineering teams on two key elements: accurate inventory of open source and proprietary components in use provided by the engineering team, and a system to associate these projects in use with known and published vulnerabilities managed by the security team.
Why OSS application security?
The benefits of OSS are obvious. It reduces cost of development, shortens development cycles and can lower the total ownership cost of applications, if managed well. Open source components range from well-known components and applications like Linux, Open Office and Android, to less well-known core infrastructure components like OpenSSL or zlib and then a long tail of millions of other open source components.
The typical application’s composition has changed from only using a few third-party components to now depending on hundreds of third-party components with the vast majority coming from open source projects.
Once difference between open source components and traditional proprietary components is that unlike commercially supported OSS operating systems and packaged applications, only one out of every 10 major open source projects has a commercial services community supporting it. Development organisations using OSS components are pretty much “on their own” when it comes to patches, upgrades, vulnerability assessments and similar tasks that are normally part of a commercial services contract.
Furthermore, while developers dispersed across the world are able to incorporate open source, freeware, public domain, evalware (demos of commercial software), etc. into the code they are writing – they do so without triggering the usual checkpoints in the procurement process. Without these controls, this third-party software is likely undetected, unmonitored and untracked. As a result, IT organisations are unaware of the composition of their code base. In recent studies, Flexera found that applications written within the last five years contained 50 percent or more open source code, by a line of code count. Of that 50 percent of open source code, more than 70 percent was undocumented and unknown to the engineering team. Therefore, when open source code goes undocumented, its existence within enterprise applications threatens the security of this vital, intangible asset.
Developing an application security strategy
It is the responsibility of security, development and IT teams to ensure that their developers use processes that produce secure software. Working together, these three departments can effectively insert application security for open source into the overall security strategy by:
– Conducting pre-deployment, code-level security reviews and penetration tests for their internally developed code
– Insisting that code-level audits be conducted by outsourced development and business partners
– Ensuring that all other third-party code included in their software applications is identified and tracked for security flaws and updated version information; and
– Safeguarding that internally developed applications have adequate checkpoints that enable thorough audit trails
Development organisations therefore must continue acquiring the high level of security expertise, identify processes for producing secure software, adopt them and consistently use them when they produce, enhance, maintain and rework software supporting a strong application infrastructure.
This means that application development, security and IT teams must work together. Neither role benefits from a siloed existence. For example, quality assurance and virus prevention are not mutually exclusive in application development.
Development teams often mistakenly believe that security is solely the responsibility of dedicated security professionals. For many organisations, the development process is solely focused on designing, architecting, coding and testing applications to ensure that they fulfil functional requirements. With today’s strained budgets and resources, applications are not adequately tested for coding defects, vulnerability assessments or conditions that could leave the applications exposed to hackers. Likewise, the mandate for security and IT teams is typically focused on defending the perimeter against external attacks. But security professionals are not coders, and so are often unaware that the decisions made during development, materially impact the deployed applications they are mandated to protect.
Whereas neither the development nor security/IT teams can adequately cover application security problems alone, hackers are well versed in coding methodologies and security, so are exploiting this gap. CSOs should task their engineering managers with ensuring that the development, security and IT teams are working together to secure deployed applications. A good place for the teams to start is monitoring open source project sites and other sources for vulnerability alerts, based on existing OSS inventory, assessing relevance of alerts against internal usage and making recommendations for version or patch upgrades as relevant. Thereafter, developing and executing an application security strategy will ensure that the organisation is able to take advantage of OSS, while ensuring the highest levels of security. OSS management tools that facilitate a pragmatic approach to application security are available. CSOs should consider this…now.
