Software Composition Analysis (SCA) has become an essential part of modern software development, with a primary focus on analyzing and managing the risks associated with open-source software (OSS) components. However, the importance of proprietary components in software applications cannot be overlooked.
These homegrown components are the backbone of many software systems and contribute significantly to a business as they are not open-source and publicly available, by definition. What is the significance of governing proprietary components and how how can software intelligence help? Let's find out.
To start with, it’s essential to understand that proprietary components make up much of the software application’s value. While OSS could represent as much as 70% of the codebase of a custom application, proprietary source code includes proprietary algorithms, business logic, or other code that is specific to the needs of the organization.
Think of a software application as a cake, and the proprietary components as the secret ingredient that makes it unique and special. The OSS components are the icing on top, but without the secret ingredient, the cake wouldn’t be complete. Just like a secret ingredient, proprietary components play a crucial role in the software application and must be managed properly, especially since they’re often shared by multiple applications across an organization.
Software intelligence products support governance of proprietary/commercial components for several reasons including:
- Improved visibility: Proprietary components are often developed and maintained in-house, and as such, their usage and status may not be well documented or understood. A software intelligence product that automatically inventories proprietary components can provide organizations with a centralized repository of information about these components, enabling more informed decision-making about the software application.
- Obsolescence risks: Proprietary components may become obsolete over time, leading to compatibility issues or other problems with the software application. By having a software intelligence product for governing these components, organizations can keep track of obsolescence risks and take proactive measures to address any potential issues.
- Better collaboration: Proprietary components may be developed by different teams within an organization or by external contractors. A common platform for cataloging proprietary components–in the context of the applications using them–can help teams collaborate more effectively, ensuring that all components of the software application are up-to-date and functioning properly.
All the above being said, let’s now see how CAST Highlight can help organizations govern proprietary components.
Proprietary Components in CAST Highlight
At the portfolio level, from the Software Composition dashboard, the Proprietary Components tab automatically aggregates detected components and enables users to review various component information:
- Component name: the name of the component as declared in the dependency files of an application (e.g., pom.xml, package.json, etc.) and extracted during a scan (see the list of supported package managers and dependency files).
- Component Type: by default, a component is categorized as Unknown until a user marks it as Proprietary.
- Component Status: similar to OSS components, proprietary components can be marked as Allowed, Denied or To be reviewed. The case for a Denied proprietary component can be, for example, a legacy homegrown framework which has been replaced by another one and needs to be removed from applications.
- Component tags: similar to application tags, users can create and attach custom tags to a component to organize and aggregate the Proprietary Component view. The top tags are displayed at the top of the dashboard.
- Component description: users can add a description for each component so that non-technical users can easily understand the purpose of a component. The description can also be used to give more details on the component’s lifecycle (e.g., this component should be decommissioned by 2028, ensure your application are not using version 5.0.0 or below, etc.).
- Component Versions: this number indicates how many distinct versions of a given component are referenced across the application portfolio.
- Applications: this number indicates how many applications reference a given component, by version.
From the user interface, clicking on one of the different component categories will populate the table with the corresponding components. For instance, clicking on “See All” under Proprietary Components will display components categorized as proprietary within the current portfolio. You can also click on a specific tag to populate the component table with components associated with this tag.
From this screen, you can also search for a component directly by name by typing in the search and optionally filtering the results by focusing on a specific component type (proprietary, unknown) or status (allowed, denied, to be reviewed). Similarly to other dashboards in CAST Highlight, you can also apply high-level filters (by domain, by technology, survey answers, etc.).
Finally, from a component list, you can also edit a component and change its information (type, status, description, associated tags).
From the table, clicking on the number of applications will list all applications referencing this component with the corresponding version (if any). Clicking on the number of versions will list all the versions of the clicked component and the corresponding applications referencing them. This is an efficient feature when, for instance, you’re an Enterprise Architect and must ensure that application owners are modifying their applications to upgrade the business-critical homegrown component to the latest version. This ensures that the portfolio is homogeneous and uses the best version of this component, while reducing maintenance effort on obsolete versions.
Identifying Proprietary Components at the application level
At the application, the list of proprietary components and related information (type, status, description, tags, etc.) can be retrieved from the Software Composition tab, in the secondary component table of SCA results. From this screen, you can also edit detected components to change their properties (type, status, description, tags.
Proprietary component information is also reported in the Excel BOM export (see the “Proprietary” tab) as well as in the CycloneDX BOM.
We hope we've illustrated how governing proprietary components in software applications is crucial for managing risks, ensuring compatibility, and promoting effective collaboration within organizations. Software intelligence tools, like CAST Highlight, provide improved visibility, help identify obsolescence risks, and facilitate better collaboration among teams.
With these tools, organizations can make more informed decisions about their software applications and ensure that their proprietary components are properly managed.