Software Engineering Security Part 5: Third Party source

To reduce the time to develop products, many software shops include third party source — often open source — into their product. This is a liability when the source has vulnerabilities.

Step One: Set up a license review board. Before including third party source, consider how it will be used and the license. Since many licenses prohibit certain behavior, a license approval board should decide what licenses are acceptable and under what conditions.

Step Two: Set up an inclusion review board. Practice good risk management before including the source. Identify risk attributes and assign a score before inclusion. Quantify the risk by investigating and ranking these factors:

• History of vulnerabilities. If a project had a high number of vulnerabilities in the past year, it has high risk. OpenSSL had 21 vulnerabilities in 2014.
• Project maturity. Code that is abandoned by it’s authors carries high risk. If some technology or code is already stale, it is high risk. Even if it is a hot piece of technology, it may be still be abandoned in favor of other technologies. Mature and stable projects will have lower risk.
• Ownership. If a team wants to include third party source but will not maintain it, it has high risk.
• Exposure. If the source exposes an external interface, it has more risk.

For example, apache has high exposure, but relatively low risk because of it’s maturity and recent history of vulnerabilities. Third party libraries used to parse untrusted input, e.g. XML or JSON parsers, may have high exposure and high risk due to recent vulnerabilities.

Step Three: Track third party software in use. Appoint an owner and a backup to watch for security updates from each third party package. The build process can be used to track third party source and create tickets to upgrade software. If there is an upstream OS vendor, consider using their updates.

Step Four: Have a maintenance strategy. Consider how source will be maintained and updated by the owners. Consider purchasing an update service from a vendor. If an upstream vendor does not cover the desired packages, consider automating updates from upstream source repositories.

Also consider running security tests aimed specifically at functionality exposed by the third party source. Report the findings back to the vendor or open source project.

Step Four: When there is a vulnerability, assign severity and follow process to update it. Third party source should be treated no differently from proprietary source when there are vulnerabilities.

Following the above steps is an effective risk management process for third party source.