Why would it? Component-based development, rooted in the principles of service-oriented architecture, delivers cross-functional efficiency barely dreamed of ten years ago. For developers, components provide a highly functional starting point. Rarely is there a need to build from scratch. Customization simply requires stitching together open source or custom components with minimal code.
And that’s a good thing. It’s a derivation of the open source philosophy itself. Re-use, consistency, stability, peer review to name a few of the principles we all know – the technical benefits in the era of components are easy to see.
The promise of smarter development is realized on the business side too. Increased productivity speeds delivery to customers, which makes everyone happy. Plus, re-use of the same frameworks and components provides the consistency needed to create and maintain stable applications.
So it’s easy to make the case that software is not so much written as it is “assembled”. Metrics from the Central Repository and recent survey results show us that modern applications are 80-90% component-based. It’s like a “Lego” – approach; the bricks stick together with glue that is the custom code. Everyone’s recipe for the glue may be slightly different, but the bricks – all the same. Every time.
Not all components can be trusted – some have flaws.
In 2012, there were 8 billion component requests from Central. While that’s mind-blowing in itself, there is another set of metrics that’s even more so – the millions of requests for outdated and vulnerable frameworks and components. We saw 46 million downloads of insecure versions of the 31 most popular security libraries and frameworks. Eighteen thousand organizations downloaded a version of the Struts framework with a severe security flaw. More disturbing is that 4,000 organizations downloaded an older version of Struts with a flaw so severe it can be exploited with a simple HTTP request – even from a mobile phone.
Simon Phipps, independent open source consultant and a director of the Open Source Initiative, emphasized the importance of component management in a recent NetworkWorld article :
“Cyber security is on the national political agenda, but do we really understand what it takes to be secure? Now that enterprise development has become component based, rather than using custom code running off-the-shelf platforms, it’s time for enterprise development to wake up and smell the black hats. They’re targeting your components, not just your servers.” — Simon Phipps
Vulnerabilities create financial and reputation exposure.
Clearly component-based development holds great promise; the risk associated however, is just as great. The average annualized cost of cyber crime for 56 organizations in a recent Ponemon survey is $8.9 million per year while the average number of days to resolve cyber attacks is 24 with an average cost of $24,475 per day – or a total cost of $591,780 over the 24-day period.
These stats further illustrate the real-world risk of insecure and vulnerable components:
- A 2013 Verizon Business data breach investigations report noted that 99% of the of attacks were not highly difficult, and that 75% of breach victims were targets of opportunity.
- The cost of cybercrime will increase 10% per year through 2016 due to continuing discovery of new vulnerabilities. (Gartner Top 2012 predictions)
These scenarios are not theoretical. Internal or external attackers look for an “in” through the component layer since they can re-use the exploit on many applications.
Sadly the rise of component usage has resulted in a rise of unmanaged risk – that is, the lack of collective effort that oversees security and license updates. Most organizations lack the security tools that are suitable for complete analysis of the software development lifecycle.
- Only 12% of security personnel say all of their organization’s applications meet regulations for privacy, data protection and information security. 15% of developers feel the same way. (Ponemon, 2012)
- Close to half (44%) of developers stated there is absolutely no collaboration between their development organization and the security organization when it comes to application security. (Ponemon, 2012)
- 76 percent or large organizations surveyed have no control over what components are being used in software development projects and even more alarming is that 65 percent don’t maintain an inventory of components used in production applications. (Sonatype, 2013)
Components drive the need for a supply chain management approach.
It’s also interesting to consider the rate at which flawed components make it into production applications. Perhaps surprisingly (or maybe not), the rate of flawed components doesn’t diminish significantly as you move through the development lifecycle. Organizations are not weeding out flawed components before they make it into production applications that are running the business.
Since components are sourced from multiple sources and custom developer efforts are often distributed or party outsourced, it’s important that we approach component management from a supply chain perspective.
It’s not just a security issue – licensing and quality play a key role.
By now you’ve realized that securing against vulnerabilities is only part of it – quality and licensing are equally as important to oversee throughout the software supply chain as well. Unlike the supply chains in other industries with existing standards, the same level of scrutiny isn’t in place for service level agreements (SLAs), strong contracts between third parties, and components sourced from open source projects. This is why we’re making the case for Good Component Practice. The same level of across-the-board standards can and should be applied to the software lifecycle.
The dilemma becomes where to start. Typically, OSS project teams are not security experts. We know it’s not a reckless free-for-all without any standards – many developers have personal or team level of security they abide by but many projects lack an overall security policy or enforcement strategy.
To complicate matters even further, take into consideration the volume and variety of modern components. Complexities associated with each mean that issues are not isolated… in fact they are viral. Take the Struts example again. Even if a fix has been made, that’s not the end of the problem – you have to ensure that all projects that depend on Struts have been updated. Many organizations don’t know where components are being used and are not aware of the particular components that have security, licensing or quality problems to know where to begin to look for those relationships.
In addition to managing where components are embedded, there is an additional challenge in managing component dependencies. The diagram below illustrates a typical application. (The center circle in the dependency diagram on the right represents an application.) Notice how the application leverages a large number of components, and those components have dependencies on other components.
Understanding and managing the first level components in the application is difficult but that is not enough; you need to manage the dependencies as well.
The dependencies may put you at risk – security, IP, quality – and as illustrated here, those risks may be buried deep in the dependency graph. What’s needed is a complete view of the transitive dependencies. Problems may occur in the outer region of the graph in a leaf node – as illustrated by the Spring-beans/camel example – and have a ripple effect throughout.
State of the industry – there is room for improvement.
Let’s take a step back though and take a look at the current state of the industry.
How are organizations overseeing the process of component management? We know a few things:
- Manual processes (i.e. paper-based) still dominate. Paper-based or locally maintained rules are at odds with agile development. Even if workflow automates the approval process, a weeks long approval process doesn’t work for short, agile-based development cycles. Additionally, while some organizations have written policies, most are not enforceable (i.e. there are no real consequences to not following procedure.)
- Developer-resistance is real. This is a result of the attempt by many organizations to create a ‘golden repository’ of components when components are run through a laborious approval process before inclusion. If a developer wants to use a component not on the list (for reasons such as experimentation or adding new functionality) they must wait for the approval process to kick in. This slows or stops development and can lead to a few things: bypassing policies, acceptance of risk, use of suboptimal (yet approved) components or use of a new component intending to get approval (with lack of follow-through). When you think about it, you can see why this happens. Developers are tasked and measured by fast application delivery. When faced with the choice of speed or security, developers prioritize speed first. It’s not like there is intent to create insecure apps; developers just lack ready access to information on each and every component and are under intense pressure to deliver.
- Focus on problem discovery late in the development cycle forces developers to circle back and rework their programs. Many security or license enforcement tools today identify potential problems late in the development cycle. Sometimes it’s so late they have to decide whether to “ship or delay” – typically they ship, which means shipping with vulnerabilities. Since the tools are focused on problem discovery, they don’t help automate or streamline the fix process.
OWASP & other industry standards are responding.
The good news is we see the tide turning away from individualized management and towards the establishment of organizational best practices. Open Web Application Security Project (OWASP) has included the security of component parts as one of the Top 10 considerations. OWASP A9 Using Components with Known Vulnerabilities addresses the need to manage the security risk related to components.
We have extended our Good Component Practices approach to support OWASP A9 efforts by starting the OWASP Good Component Practices Project, which documents a set of best practices for managing OSS component vulnerability within enterprise applications.
It’s also interesting to note that it’s not just OWASP, other industry standards are recognizing the critical role that components play. The Payment Card Industry (PCI) standard requires secure component practices by reference to OWASP Top 10.
Even if OWASP isn’t guiding your effort, there is still a need to adopt an official OSS policy. Let’s be clear about this – policy doesn’t have to put a vice on creativity or innovation. When well managed, an OSS policy guides decision-making, provides clarity and supports enforcement. Some may see policy as a ‘security’ tax – it doesn’t have to be. Real benefit is derived.
In fact, operating from a detailed, enforceable policy is an ideal state. Guiding principles on security allow developers to continue to move quickly while meeting the needs of security, legal/compliance and OSS licensing. It’s like the old phrase about singing from the same songbook. Guesswork is reduced with everyone following the same rules.
Managing risk while containing cost can seem like a tradeoff, but doesn’t have to be. Not if you’re tracking issues throughout the software lifecycle. Right now, many organizations place remediation efforts at the end of the development process. (Ask any developer who has used scanning technology about the time waste of chasing down false positives.) Savings – in both time and money – comes by tapping that component intelligence throughout the lifecycle.
Once an application hits production – you need to keep monitoring for new vulnerabilities. Extension of these principles into production provides the basis for flexible, faster remediation and builds on trust. Fundamentally, trust is what good component practice comes down to. If you trust component validity from the start, and trust the team is acting on the guidelines set forth, when it comes to monitoring issues in production, you’re already operating from a basis of known entities. But applications and components are not static (neither are the hackers) – you need to proactively monitor and alert new vulnerabilities that are discovered.
Introducing Good Component Practices.
Our industry is at a tipping point – either adopt a formalized practice or accept tremendous risk. Not much of a choice, is it? We’ve defined that practice, dubbed it GCP or “Good Component Practices” and are outlining the methods to achieving it here in this book.
GCP is intended to spawn best practices and spur innovation. When components (and the larger component ecosystem) are managed – like the way manufacturers run a modern supply chain – there is a huge and lasting impact to all sectors of business and government. GCP is a somewhat altruistic notion – the idea is as participation grows, so does an overall reliability factor. The ability to trust grows exponentially as a critical mass is achieved.
We’ve illustrated how components & the larger component ecosystem can have a huge and lasting impact to businesses, organizations, government, etc. and how if not managed appropriately, the negative impact. GCP is intended to address major security concerns that could cripple a business, an economy, a nation-state even. Last fall, former Secretary of Defense Leon Panetta strongly warned the “not if but when” scenario of cyber warfare on critical US infrastructure systems. GCP plays a role in shoring up these systems and their interconnected parts against increasingly sophisticated adversaries.
Just like other significant technology trends & major supply chain efforts, entire industries or vendor categories will grow to support component-based development. Why? Everyone realizes how much is at stake for companies who leave themselves vulnerable.
This GCP book is intended to jump-start the community effort and to help initiate a conversation by way of this Website. Sonatype will play a supporting role by providing the infrastructure for a community site, recruiting app dev & CISO experts for moderation and as content contributors. Chapters will be produced and released on a rolling schedule and will include Quick Start guides, considerations for implementation (e.g. securing the supply chain, how to securing delivery, etc.) as well as hot topics (big data, cloud). Sonatype also will be looking for expert peer reviewers to provide comment and evaluation before chapters are released to the larger community.
We welcome your participation in this community effort. Please join us.