Third-Party Software Risks

Recently, {complink 8103|Coverity Inc.} commissioned the “Software Integrity Risk Report,” a study conducted with Forrester Consulting with an eye on quality and the software supply chain. More than 330 software development influencers were surveyed about their policies for managing software quality, security, and safety.

The study confirmed what I have discussed previously — that third-party code is prevalent in the embedded systems industry, and for good reason. The incorporation of third-party code can reduce costs, maximize development productivity, and speed time-to-market. It's evident that third-party code use is no longer merely a growing trend — it's the norm.

What is interesting about the report, is that given the extensive use of third-party code, less than 50 percent of the respondents reported that they test third-party code with the same rigor as internally developed code. Furthermore, only 44 percent of respondents said that they conducted automated code testing of third-party code in development, compared to 69 percent who conduct automated code testing of internally developed software. So it's not surprising that more than 40 percent of respondents reported problems with third-party code that resulted in product delays, recalls, security vulnerabilities, an increase in development time, or a curtailment of revenue.

Simply put, companies are not holding third-party software to the same level of accountability as internally developed software, and that carries a large risk. When you think about the reasons companies leverage third-party code, these same benefits are being compromised from software defects in the exact same code.

This doesn't mean that development teams aren't doing their job. Instead, these results emphasize the need to extend software integrity standards across all suppliers, internal and external. Developer testing, including technologies such as static analysis, should be a part of those standards.

Static analysis is a cost-effective, automated, and repeatable way to ensure the quality of software. Applied across the software supply chain, it affords businesses an insight into the integrity of code, both in-house and third-party.

9 comments on “Third-Party Software Risks

  1. prabhakar_deosthali
    July 20, 2011

    Normally the purpose of getting a third party to develop part of your software is to reduce that much burden on the internal team. If you select a third party which has its own internal stadards of testing their developed code before they deliver it to you then the duplication of the testing of that code can be avoided. The vendor should self-certify such code and also provide the test vectors and the assciated results. Such kind of self certification is required when you are getting the third part code to integrate into your product. 

  2. Daniel
    July 20, 2011

    Andy, you are right. There could be a chance of threat through third party software. I know certain equipments may exhibit a strange response in critical application, where malware is functioning at bank end. In most cases, the malware is embedding in hardware for spying and data retrieval purposes. In such cases, procuring software through reputed and trusted vendors are the only solutions. Since these malwares have time bound responses, most of the security software may fail to detect them at initial stages.

  3. jbond
    July 20, 2011

    I am amazed at how many companies employing third party software aren't too concerned about integrity and standards. Not only does this make them susceptible to viruses and malware but this could also seriously damage their reputations. I think there should be an across the board standard that all parties need to meet. 

  4. eemom
    July 20, 2011

    This doesn't make sense to me.  Why wouldn't third party code be subjected to rigorous testing?  Even if the company providing the code certifies it, the ones incorporating the code in their systems are the ones who are responsible for it.  Do they perform rigorous testing once the code is incorporated in their system? 

  5. HM
    July 20, 2011

    Third party softwares usually makes into the final product without rigorous testing that we expect to happen. The sense of responsibility kind of disappears when software is taken from third party. The attitude becomes like 'Arent they supposed to test it?' . And when things fail in the field then the engineering and testing team kind of blames the senior management for out sourcing! And guess what happens to the senior manager who selected the third party!!


  6. eemom
    July 20, 2011

    I would suggest that it is the responsibility of the management team that selected the third party software to test and ensure that said software will not cause problems after the fact.  The “lets not test and take our chances” approach can be too costly, why would they adopt such a mind set?

  7. ProcurementGDL
    July 20, 2011

    I totally agree prabhakar_deosthali  !  Companies should have a formal and rigorous code goverance policy and prCcess.   That process should be adaptable to external developers and be included in the SOW and contract.   The FDA already has s/w code governance for medical devices as failure can result in loss of life.  Ideally any company with a s/w interest should have the same mindset. 

    I'm not thrilled with EBN providing Coverity free advertising for their s/w dev services. However, the article has merit if it reminds us code goverance is vital in order to prevent catastrophe.  

  8. HM
    July 20, 2011

    There are always cases where original product company/owner wont be able to even test the third party software. For example take the case of the new phones that support third party apps. People install third party softwares and that can reduce the performance or battery life of the phone! Just did a search and see what I saw.

    Google blames third-party app developers for Android phones’ terrible battery life


  9. electronics862
    November 30, 2011

    Third-Party software will definitely reduce the price will it will lead to a delay in product response time. I should suggest rigorous testing will definetely will lead to management of risk levels and in better controlling. 

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.