Managing software integrity risk
A new report details growing discrepancy in the quality standards businesses are applying to their internally developed code versus code supplied by third-parties.
It's no secret that companies of all kinds use third-party software in their own products. Mobile OEMs are a great example--new phones often contain code from of hundreds of code suppliers--both open source and proprietary.
A new "Software Integrity Risk Report" commissioned by software analyst Coverity and conducted by Forrester Research points to a growing discrepancy in the quality and security standards businesses are applying to their internally developed code versus code supplied by third-parties.
This can lead to an increased risk of software defects, translating to an increased risk of software failure and impact to brand image and revenue. The report also reveals a skewed risk-to-responsibility culture forming between companies and third-party developers.
From the survey:
- More than 40 percent of respondents said that problems from third-party code resulted in product delays or recalls, security vulnerabilities, increase in development time or revenue impact, and that these instances caused them to seek greater visibility into their code quality.
- Only 35 percent of companies conduct risk, security or vulnerability assessments for third-party code, compared to 70 percent of companies who conduct these tests on their internally developed software.
- In nearly one out of every two cases, the report found that the buyer side is held 100 percent responsible for quality and security issues found in third-party. On the contrary, third-party code suppliers are held 100 percent for these same defects one out of every ten cases.
I e-mailed with Coverity CMO Dave Peterson about what these results mean for businesses and development teams. He pointed out that development teams are being held responsible for integrity of software, even while most of it comes from external organizations over which they have no control.
According to Peterson, consumers will associate any software failure with the logo that's on the product, whether or not the code defect in question was in in-house code or from the code provided by one of a hundred third-party suppliers.
As part of effort to mitigate any potential fallout from faulty software, companies need to re-examine their internal code standards for quality and security and hold their third-party code suppliers to the same standards.