top of page

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

The ISO 27001/27002 information security and privacy standards require organisations to negotiate responsibilities with an outsourcing supplier for delivering secure code.

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 recognised in the updated International Standards Organization (ISO) 27001/27002 standards, which require organisations 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 organisation 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 organisations 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 organisation 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 organisation. As with code developed in-house, however, that outsourced code can carry security risks. Recognising that the responsibility for protecting data remains with the organisation, 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 organisation’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 organisation 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 organisation should remove any access rights granted to the supplier, and the supplier should destroy all copies of the organisation’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 organisation and work with you to remedy the situation.

Both the supplier and your organisation 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 organisation 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 organisation’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 organisation and properly remove your data from its systems.

The bottom line

In the end, each organisation 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 organisation, 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.

Article originated in SC Magazine

ISO News is an aggregator of global media. All the content is available free on the internet, we have just arranged it in one platform for educational purposes only. In each article, the hyperlink to the primary source is included. All trademarks belong to their rightful owners, all materials to their authors. If you are the owner of the content and do not want us to publish your materials on our website, please contact us by email – and the content will be deleted within 24 hours.

14 views0 comments


Sponsored by:
bottom of page