By Eric Baize, vice president, product & application security at Dell Technologies
In the last few months, Perspectives has featured articles about the importance of secure product development and how you can apply it to in-house software development. But what happens if some of the software you’re using isn’t your own? Companies often use third-party software as components of their own products. That brings a whole new challenge to product security by involving a third party.
Licensing third-party software or using open-source software is often cheaper than in-house development in the short term and allows the developer to focus on innovation. However, you can’t apply the same end-to-end secure development practices to code that you don’t own. The recent vulnerability in the Log4j open-source component impacted a large number of commercial products and was a reminder of the responsibility of vendors using third-party software. Incidents such as this point out the importance of (1) screening your suppliers’ secure development practices; (2) negotiating vulnerability -fix SLAs in contracts; (3) trusting your suppliers but verifying third-party code; and (4) keeping track and monitoring vulnerabilities in third-party software embedded in your code.
Open-source security
Most third-party software is open-source and there is no supplier to negotiate with. In this model, a community of developers makes the source code readily available. The model’s transparency and low cost are appealing, but it still limits your control over the development process. That’s an acute problem in a world where secure development lifecycle (SDL) practices are rare. Volunteer developers are often more interested in creating new features than securing existing ones. The Linux Foundation’s most recent survey on open-source developer activities found them spending just 2.27% of their time responding to security issues.
Even large open-source projects can fall afoul of security issues. The Log4Shell vulnerability in the popular Log4Shell2 Java logging software is a prime example. Industry is responding to the open-source security problem. The Open Source Software Security Foundation (OSSF), of which Dell is a board member, is a collection of vendors working together to secure open-source software. It met with government officials at a White House summit in January 2022 to create strategies for improving open-source security. OSSF’s plan spans 10 activities, including code audits, better scanning and supply chain initiatives. One notable component is the use of software bill of materials (SBOMs), which the U.S. government mandated in its Executive Order on Improving the Nation’s Cybersecurity.
Analyze, evaluate, then define expectations
An SBOM documents the components of your code and where they came from. It gives you and your customers better visibility into what proprietary or open-source third-party code might reside inside your software. Use the SBOM as the basis for analyzing the context of that third-party code. Explore how it integrates with other parts of the product. Evaluate how relevant any vulnerabilities in a component are to the rest of the product. That will help when responding to any security issues that emerge in the code. Having analyzed that context, define expectations with third-party software suppliers. Identifying who created a component in your software is a good first step as it allows the developers to track and apply third-party security updates promptly. But what happens when vulnerabilities in third-party software are not addressed?
For commercially licensed third-party software, that discussion might result in a support contract between your company and the supplier that specifies a timeframe for addressing vulnerabilities. This sometimes works in open-source projects too, where individual maintainers make their time available. Alternatively, allocate internal resources to understand and contribute to the open-source software so thatyou can find and fix security vulnerabilities yourself. You can then feed those changes upstream to the supplier.
It’s time to focus on the supply chain
The software supply chain is extensive and complex. It doesn’t just involve your suppliers but also their suppliers. Ultimately, those organizations might be responsible for fixing security vulnerabilities, but the responsibility of ensuring your software supply chain’s security begins with you.
This means being accountable for the third-party code and services you use. Avoid “cargo cult” culture, where programmers blindly use third-party code without understanding what it does.
Put security standards in place for third-party software and hold your suppliers accountable for meeting them and your developers accountable to enforcing them and verifying third-party code as part of your Secure Development Lifecycle.
We all know that as good as your secure development lifecycle process may be, all software has bugs and a subset of these bugs are vulnerabilities. But taking these steps will help increase your chances of avoiding upstream security problems—and decrease the likelihood of your software making the headlines for the wrong reasons.
This article is the fourth in a four-part series on secure product development. Be sure to check out the rest of the articles in the series:
Why your coding team needs to use a secure development lifecycle
Catching bugs on the loose: vulnerability management for software developers
How to grow a secure software culture from the inside out