All your code is not your own: Securing third-party code for ISO 27001 compliance

Key takeaways

You probably already know that all your code is not your own. In fact, the vast majority of application code consists of open-source and third-party libraries and outsourced code alongside code developed in-house. Moreover, not only do you not own all your application code, but the platform on which the application runs is also third-party software: cloud services, web servers, networking software, and operating systems. Yet if there’s a data breach, your customers don’t care whether some third party wrote the software that was compromised – they’ll hold you responsible. 

The collaborative nature of modern software is clearly recognized in the updated International Standards Organization (ISO) 27001/27002 standards, which require organizations to “identify and implement processes and procedures to address security risks associated with the use of products and services provided by suppliers.” Although this is a daunting task, the ISO 27001 information security, cybersecurity, and privacy protection standard and its companion document, ISO 27002, both updated in October 2022, lay out guiding principles for protecting outsourced and third-party code as well as cloud services. 

Third-party software still needs security testing

It makes sense for an organization to use third-party libraries for common tasks such as handling network operations or rendering the user interface. Such pre-written code usually is stable, debugged, and ready to run. But widely-used code can also make an easy target for attackers looking for a big payback on their efforts. Fortunately, the security community continually monitors popular platforms and software for weaknesses or security breaches. ISO recommends that organizations keep an eye on disclosures and apply patches and updates promptly when available. Regression testing must follow to verify that existing code still works as intended. 

“Nevertheless, an organization cannot accept third-party software as-is,” warns Invicti CISO and VP of Information Security Matthew Sciberras. “They must perform security testing. SAST works well for open-source code, but for libraries accessed through an API where the source is unavailable, automated DAST and manual penetration testing are the only options,” he says. (SAST and DAST standing for static application security testing and dynamic application security testing, respectively.)

ISO 27002 details requirements for outsourced code

The advantages to outsourcing development are many, but the main advantage is that the outsourcing supplier can contribute skills lacking in your organization. As with code developed in-house, however, that outsourced code can carry security risks. Recognizing that the responsibility for protecting data remains with the organization, ISO 27002 stipulates a set of requirements for all stages of outsourced development. 

The first step ISO recommends is researching the outsourcing supplier: its reputation, documentation, and certifications. Special attention should be paid to security practices, given that the supplier will have access to your organization’s data. 

Next, it’s time to negotiate a strong contract. ISO says the contract should clearly delineate the responsibilities of both parties, including non-disclosure agreements where appropriate. The contract should also establish ownership of the completed code and intellectual property. Procedures and policies for secure design, coding, and testing should also be written into the contract, with an option to audit those procedures.

Access control is another crucial consideration. During development, the organization should provide the appropriate access level for any resources needed by the supplier, and both parties should establish secure procedures for code delivery. At termination of the contract, whether by delivery of the software or failure of the outsourcing company to comply with its terms, your organization should remove any access rights granted to the supplier, and the supplier should destroy all copies of the organization’s data and return any assets. And if at any time the outsourcing supplier becomes aware of a data breach involving its code, it should be contractually obligated to promptly notify your organization and work with you to remedy the situation.

Both the supplier and your organization should perform security testing. SAST can be used during development because you will have access to the source code, but DAST is also essential both during development and after deployment. Once the code is deployed, you should continue to monitor the supplier’s security procedures and practices to keep up with any reported vulnerabilities affecting third-party software used in the supplier’s code.

Cloud services requirements in ISO 27002

When it comes to cloud infrastructure, ISO 27002 requires an organization to negotiate a special agreement with its cloud service provider. In the agreement, the cloud service provider should be required to use industry-standard architecture and infrastructure. It must also protect your organization’s data by applying secure access controls and ensuring appropriate handling of any sensitive data.

Cloud service provider obligations should also include monitoring for intrusions and malware as well as ensuring dedicated support in gathering evidence should a breach occur. If the provider subcontracts any of its services, the same contractual terms need to be applied to subcontractors. To cover the entire lifecycle, at contract termination, the provider must return all data and configuration files to the organization and properly remove your data from its systems.

The bottom line

In the end, each organization is responsible for the confidentiality, integrity, and availability of its data – and that of its customers. Regardless of whether the software you use and the platform it runs on originate from your organization, a cloud provider, or an outsourced supplier or another third party, it’s you who must ensure the code is secure. One aspect of this is negotiating contractual agreements with outsourcing suppliers and cloud services. But the final assurance that the software is secure must come from security testing – and that means SAST where you have the source code and DAST everywhere, both during development and after deployment.