What We Can Inner Source and Why
Inner source enables organizations to apply the practices of open source software development to proprietary code. Commercial products built in an inner source model potentially benefit from
- faster time to market, as contributions can come from across the organization
- improved quality, by leveraging expertise across organizational boundaries
- higher reuse, as components applied to one product can be more easily discovered and factored out into common libraries
- broader adoption, as teams have incentive to use products they directly contribute to
However, commercial products built in an inner source model may also put the organization at risk by exposing vulnerable code that could be exploited by bad actors. The impact of those exploits depends on the criticality of the exploited product or service to the organization (i.e., how many users depend on it, how much revenue does it generate, etc).
To effectively support inner source at Trimble, we must manage the risks. To do so, all products and services have been classified within Trimble Security Portal into one of three distinct risk categories based on their criticality to our business.
Classification: Enterprise Critical
If exploited, loss of service would have significant negative business, environmental, safety, or brand impact.
Examples
- Trimble Identity
- Tekla Structural Designer
- 3D Warehouse
Classification: Business Essential
If exploited, loss of service would have a significant negative impact on the operation of a particular business and its customers.
Examples
- Trimble Business Center
- Sefaira
Classification: Normal
If exploited, loss of service would be inconvenient for a particular business and its customers.
Examples
- StabiCAD for Revit
- Catalyst Service
Decision Diagram for Product Classification
A decision diagram of this classification, developed by xOps and Cybersecurity, is provided as an appendix. Trimble derives its inner sourcing policies directly from these classifications.
Enterprise Critical
Enterprise Critical products and services can only be inner sourced on a case-by-case basis through the TSDLC Exception Process. Exposing these code bases broadly could significantly increase Trimble’s security footprint, so thorough analysis of the risk to our business and ecosystem must be considered.
Business Essential
The owning business for this product or service may, at its own discretion, open this product to an inner sourcing contribution model. Businesses should carefully weigh the benefits and risks of such a move, including accepting the risk should their products be exploited.
Normal
The owning business for this product or service may, at its own discretion, open this product to an inner sourcing contribution model.
Inner sourced projects require effective product management. Successful inner sourcing initiatives at Trimble - including the HTTP API Standard, DevGuide, and Modus - all have one or more core contributors operating in a product management function, taking responsibility for maintaining the integrity of the project as a whole. For more guidance on how to set up an inner sourcing project, see an Introduction to Inner Source on the Trimble Dev Guide.
To learn more about making an existing codebase part of Trimble’s inner source initiative, see the contribution guide of the Trimble Open Source Store.
Risks of Inner Source
Inner sourcing involves sharing source code across different divisions and sectors. This increases the risk of sensitive code being exposed to unauthorized individuals, potentially through casual browsing or even a larger security breach like leaked credentials. The potential for poorly managed access controls in service of inner sourcing could open the door to intellectual property theft or a data breach that could be damaging to Company reputation or even customer identities.
Inner sourcing works best when consumers of common codebases also contribute back to the maintenance of the codebase. While the audience in an inner source model is not as large as the global Internet, maintainers of a project will need to contend with varying degrees of competence and quality from contributions. Additionally, there can be overhead and errors created if a project is popular enough to experience frequent merges from many sources.
Because inner sourcing encourages code reuse, it is likely that multiple applications will become dependent on the same codebase. The quality of common codebases can lead to critical issues to exist in multiple applications, causing widespread outages or vulnerabilities. Additionally, a common codebase without enough maintainers could result in bottlenecks for reviewing and merging contributions needed to meet project deadlines or fix vulnerabilities.
To assist with mitigating these risks it is important to implement robust access controls, create and communicate clear coding standards, provide secure coding training to developers, perform both automated and manual code reviews, and establish whatever is necessary for creating and maintaining strong communication channels between all Trimble developers.
Appendix I: Decision Diagram for Classifying Product and Service Risk Levels
For further details, review the Application Classification documentation (download).
