How to Manage Third-Party Code Risk: Vendor Libraries, APIs, and Plugins

Open source dependency management is now well understood by most engineering teams. Most organisations have automated scanning for known vulnerabilities in their package dependencies, and the practice of checking a dependency's health before adopting it is becoming standard. But third-party code risk extends well beyond the open source packages in your requirements file. Vendor SDKs, third-party API integrations, and content management system plugins all represent code your engineering team did not write, cannot directly audit, and cannot unilaterally patch when a vulnerability is discovered.

The risk profile of these categories differs from open source dependencies in important ways. Open source dependencies are typically transparent: the source code is public, vulnerability disclosures are public, and patch availability is visible. Vendor SDKs and commercial plugins are often opaque: the source is proprietary, vulnerabilities may not be publicly disclosed, and patching depends on the vendor's own release cycle. An organisation that has mature open source dependency management but has not thought systematically about vendor code risk has addressed only part of the problem.

Vendor SDK Risk

Vendor SDKs are particularly common in the categories of analytics, payment processing, identity management, and marketing automation. These are often loaded into applications with broad permissions because the SDK vendor needs access to session data, user behaviour, or transaction information to provide the service. The security question that should be asked before adopting any SDK is: what access does this code require, what does it do with data it accesses, and what happens to our application if this SDK is compromised or begins behaving maliciously?

The answer to these questions requires more than reading the vendor's marketing material. It requires reviewing the SDK's actual network activity, understanding what data it collects and where it sends it, and assessing what would happen to your application's security posture if the SDK were to be modified by a supply chain attacker. For high-permission SDKs, this assessment should be a formal step in the vendor onboarding process, not an afterthought. Many significant supply chain incidents have involved exactly this vector: trusted third-party code with legitimate access being modified to extract data.

Third-Party API Integrations

When your application integrates with a third-party API, you are extending your attack surface to include that API's behaviour. If the third-party API is compromised or returns unexpected data, your application needs to handle that safely. If authentication to the third-party API uses a long-lived credential, that credential needs to be stored securely and rotated on a defined schedule. If the integration handles sensitive data, that data is now potentially visible to the third-party provider, which may have implications for your privacy obligations.

The risk management approach for third-party API integrations combines procurement-side assessment with technical controls. On the procurement side, you need to understand the vendor's own security practices, their breach notification obligations, and their data handling policies. On the technical side, your application should validate and sanitise all data received from third-party APIs rather than trusting it as safe, should use short-lived credentials or token rotation where the API supports it, and should monitor the integration for anomalous behaviour. An integration that begins returning unexpected data volumes or calling endpoints it has not previously accessed is a signal worth investigating.

Content Management System Plugins and Extensions

Plugins and extensions for content management systems represent a particularly high-risk third-party code category for several reasons. The plugin ecosystem for most widely-used CMS platforms includes thousands of plugins with varying levels of maintenance and security practice. Many plugins have access to the entire CMS database, the web server filesystem, and user session data by default. And the update cycle for plugins is often managed less rigorously than the CMS core, because updates are perceived as less urgent and the sheer number of plugins makes comprehensive update management difficult.

The approach to managing plugin risk starts with reducing the number of installed plugins to only those that are actively needed and actively maintained. An inactive plugin with three years of unpatched vulnerabilities is a risk that provides no benefit. For plugins that are genuinely needed, the assessment questions are: does the developer have a track record of releasing security patches, is the plugin actively maintained, and is there a disclosure history that suggests the developer takes security reports seriously? A plugin with multiple unpatched CVEs and no response from the developer is a risk that should prompt either finding an alternative or accepting an elevated risk level explicitly.

Building a Third-Party Code Inventory

Managing third-party code risk systematically starts with knowing what third-party code you have. Most organisations that have not done this exercise discover they have significantly more third-party code in their systems than they realised: SDKs added by marketing teams directly to production without engineering review, API integrations that were built by a previous employee and are no longer documented, plugins installed years ago for a feature that is no longer used. The inventory process itself is often the highest-value step because it makes visible the risk that was already present but unknown.

Once you have an inventory, prioritise by access level and data sensitivity. Third-party code with access to authentication systems, payment data, or personal information warrants the most scrutiny. For each high-priority item, document what the code does, what access it requires, who the vendor is, when it was last updated, and what the process is for receiving and applying security updates. This documentation does not need to be elaborate, but it needs to exist. A third-party code risk you cannot see is one you cannot manage.

• Build a complete inventory of third-party code before assessing risk
• Assess SDKs for data access scope and supply chain integrity risk
• Validate and sanitise all data received from third-party APIs
• Reduce the number of installed plugins to only actively maintained, necessary ones
• Include third-party code security assessment in vendor onboarding
• Define a regular review cycle for the third-party code inventory

If your organisation wants to conduct a systematic third-party code risk assessment or integrate this into your development security processes, contact us at info@cyberlinx.com.au.