The Lego Block Phenomena of Software Development

A multibillion dollar company, founded in 1932, grew to be the fourth largest toy company in the world by making a toy “brick” made of plastic that inspired millions of children to use their imagination. In the 1990’s, Lego hired creative talent to expand on the basic “brick” to include fashionable colors and realistic objects and themed-based sets in an attempt to grow the business and expand into theme parks, software, publishing all pumping out new product at a relentless pace.

In 2004 the company announced that earnings could not cover a substantial loss and that restructuring and a new strategy was necessary to return to profitability. Out went the creative talent, the splashy product launches, the theme parks, the magazines, etc. and the result was a five year strategy to return to the core of making plastic “bricks” for kids to use their imaginations with. By 2009 the company became the fifth largest toy company worldwide and they are now the fourth largest. So what does this story have to do with software development? The answer…actually my answer ...is there are two parallels worth identifying.

The first is that today software development resembles the concept of “snap-together” Lego bricks representing the assembly process. Requests from Central, the former Maven repository for open source code, will reach 13 billion this year. Developers improve their time to market capabilities and potentially the quality of their software by using code libraries already developed and reused for the specific functionality necessary.

The good news is that reusable code has clearly arrived…the not so good news is that it has vulnerabilities in many of the most commonly used components. Estimates indicate that 46 million downloads in 2012 included insecure components or code with high-risk security vulnerabilities. Once the code is assembled by developers they often will not scan or test the security of the open source libraries instead assuming that because it is commonly used it must be secure. Many of the component libraries may not even be used for functionality so they are not scrutinized for security. And this is where the second parallel with Lego’s history may apply. Lego created artificial parts to stimulate the creative process and make it easier for kids to assemble unique objects. The result was that kids preferred to use the basic bricks to then apply their own creativity and imagination to. The similarity is that software developers don’t seek massive libraries and prefer core functionality that is easy to understand and assemble. Developers need help assessing the quality (security) of the components that they want to use so they can make trade-off decisions on which components to use and which ones to avoid. There are few crowd-sourcing solutions identifying the severity of security vulnerabilities available today. GitHub has a social network capability that makes it easy to share information but the amount of information about security or privacy vulnerabilities is very limited.

Large organizations that hire lots of developers to enhance and develop custom applications are discovering that their application portfolios are experiencing high vulnerability density increases due to the increase in consumption of open source libraries. So the promise of re-usable software that has been discussed for decades is certainly here and now we need a way to purify the resiliency of open source libraries at their source or before they are assembled into applications by developers. We need this for open source code in Central and GitHub which is widely used by mobile application developers.

Security professionals recognize the benefits of meeting time to market demands for software development to support the business needs. This means that testing software for vulnerabilities after it is assembled leads to constraints on time to market demands and little or no opportunity for the developer to learn from experience and avoid certain code libraries on future projects. Applying scanning to components prior to the release into a repository is the ideal option but that is more difficult to enforce and may discourage submissions. An alternative approach is to apply a filtering or scanning capability after the download process that tells the developer what the vulnerability density is enabling the developer to choose components with a lower vulnerability density. Security professionals would also like to see the enforcement of policy in the build process so that those components with the highest risk score (vulnerability density) can be blocked from the build process.

These controls would enable developers to produce higher quality applications without the constraints of security testing after the application is “assembled” or built. It reminds me of an analogy that one of the most effective ways of increasing the speed of a race car is to enhance the braking capability. The lower the quality of brakes, the slower the driver will go as a result of a lack of confidence in the braking ability. You can try this sometime in an empty parking lot…drive around with using the brake at all and you will see that you inability to brake will slow you down. Add the brake and you increase your confidence and speed. The same is true of applying controls to the development process at the front-end. Developers will increase their speed or time to market capabilities due to higher confidence in the quality of the open source components in use.

Security professionals need to consider innovation in the controls to improve the quality of software development by ensuring the Lego “bricks” (or open source software) are resilient.

Several large banks that are members of the Financial Services Analysis Center (FS-ISAC) are participating on a working group that is recommending control types for software security and one of the recommendations is to address the need for improved capabilities in governing the acquisition and use of open source code libraries. There are a small number of vendors that offer potential solutions in for this specific control type and fortunately the newer products provide functionality to address the majority of the risks of using open source code libraries.

So the fancy objects that Lego creatively developed in the late 90s did little to improve growth and almost caused Lego to consider bankruptcy and their focus on building the basic “bricks” are what kids really wanted. For open source…less may be more to developers who want solid functionality in the components they seek but not layers of complexity in the numerous libraries filled with potential vulnerabilities. Making these vulnerabilities transparent will help encourage developers to use tools to identify them while in development making the software ecosystem more resilient.