Can brand categorization inspire SCA innovation?

Open Source Software (OSS), Security

Can the creation of a brand category inspire the expansion of existing products and motivate new entrants ?

Yes, this is what can happen with Software Composition Analysis (SCA).

Prior to 2014, Black Duck and Palamida were helping their customers comply with the terms of the licenses that covered the open source they used.

Enter the Heartbleed security vulnerability in open source, and those vendors added reporting of previously disclosed security vulnerabilities in open source. This was an opportunistic leap forward.

Then came the marketing experts. They created the Software Composition Analysis category and now there is a bold direction to inspire innovation.

Yes, open source licenses and security vulnerabilities in open source are still important, but all levels of the software supply chain should care about all the non-functional requirements (NFRs) of software they get from all suppliers.

Whose software to analyze

A Procurement team (with a capital P, not just the finance team) should analyze the composition of software they source from any supplier: commercial software vendors, partners, outsourcers, acquired companies, other divisions and groups within their own company, and (yes) open source authors too.

What software NFRs to analyze

Software can be flawed in many ways: non-compliance to open source license terms and existence of previously disclosed security vulnerabilities are only two of them. When a company develops its own software (either for its own use or for the use of others), it analyzes many NFRs of that software. Since procured software is intended to be an efficient time and cost replacement for in-house developed software, the same analysis should be applied to procured software. A Procurement team should analyze all of the following NFRs of the software they source:

  • Quality
  • Maintainability
  • Scalability
  • Extensibility
  • Portability
  • Compatibility
  • Reusability
  • Usability
  • Accessibility (by those with disabilities)
  • Exportability (based on distribution and use of cryptography)
  • Vulnerability (previously undiscovered, analogous to anomaly-based IDSs)
  • Vulnerability (previously disclosed, analogous to signature-based IDSs)
  • Licensability

Granted, in-house developed software doesn’t always meet every one of these NFRs, but the Procurement team should acknowledge more than just the final two on this list.

The marketers who created the Software Composition Analysis category have pointed the way as a challenge to existing and new SCA product providers to create products and services that analyze many more NFRs.

See ISO/IEC 25010:2011 (aka SQuaRE) and FURPS for more detailed treatments of NFRs.