Supplier Security Explained: Security Best Practices for Outsourced Development

Updated: 29 October, 2024

20 October, 2024

Introduction to security in the context of outsourced development

Many organizations rely on outsourced software development to accelerate innovation, reduce costs, and access specialized expertise. However, outsourcing introduces unique challenges when it comes to maintaining strong application security. In this blog, I will explore application security best practices for outsourced software development, offering practical steps to ensure that security is systematically tackled throughout the software development lifecycle (SDLC).

In a nutshell, here are the three key elements of the outsourced development partnership in progressive difficulty based on OWASP SAMM.

• Evaluate suppliers based on your organization’s security requirements, ensuring they meet the necessary security standards before entering into a partnership.
• Incorporate security clauses in supplier agreements to ensure ongoing compliance with your organizational security policies and regulatory requirements.
• Provide clear security objectives to external suppliers, ensuring they understand your expectations and maintain proper security coverage throughout the development process.

Note that OWASP SAMM’s supplier security practice is focused on outsourced development. In that context, you have an official relationship with the supplier, governed by (hopefully) strict contractual agreements. In this scenario, you can mandate specific security practices, audits, and compliance requirements. This differs from the more informal or indirect relationships in open-source dependencies, where you don’t have contractual control over the supplier. This blog focuses only on outsourced development.

In the rest of this blog, I will provide an in-depth analysis of how to tackle outsourced development in a structured and systematic fashion.

Why supplier security matters?

Security is an essential quality of your applications that at the end of the day boils down to ensuring compliance and reducing risk. When dealing with outsourced software development, it’s essential to integrate security practices at every stage of the partnership to minimize that risk. Here are a number of key reasons why:

1. Post-delivery vulnerabilities: Once the software is delivered and integrated into your system, vulnerabilities in the code may go undetected. That would pose a risk to the your entire application. Ensuring that security was prioritized during development helps prevent vulnerabilities.
2. Ongoing support and patch management: Delivered software often requires ongoing updates and patches. Without security measures in place, outsourced vendors may fail to provide timely patches, leaving your system vulnerable to new threats.
3. Maintaining long-term integrity: After delivery, any insecure coding practices or hidden backdoors in the outsourced software could compromise system integrity, leading to data breaches or unauthorized access.
4. Compliance with regulations: Many industries have strict compliance standards (e.g., GDPR, HIPAA, CRA, NIS2, DORA, NIST SSDF, FISMA). Outsourcing also often involves sharing sensitive data with third-party vendors. Proper security ensures your organization remains compliant, avoiding costly fines and penalties.

Large organizations rarely need any convincing about the importance of this practice. Small and medium size enterprises might wonder whether this is really that important. Let’s see what the worst case scenario is when you don’t deal with security properly in the context of outsourced development.

How to fail a project when working with outsourced development?

Imagine you have a great, friendly relationship with your outsourced development team. You have a nice contract in place that deals with the typical things like payment terms, non-solicitation clause and other typical legalese. Your legal team might have even added some additional security-related clauses in that contract. What could go wrong? Here are 3 satirical scenarios of how to ensure the failure of your project.

Make sure your suppliers do not have any vetting process for third-party libraries

In most applications, third-party dependencies make up at least 80% of the codebase. Make sure your outsourced developers can pick any third party dependency as long as they can quickly deliver the solution. Chances are that one of those libraries (or one in its chain) will be outdated or unmaintained. All that’s needed now is a vulnerability after your software is deployed. Fixing it might become such a monumental challenge that even with strong legal agreements you might need to rebuild parts of the system to address that vulnerability.

Make sure your outsourced teams do not follow any secure coding practices

Forget about secure coding practices, just make sure the developers produce the solution as quickly as they possibly can. An exploitable vulnerability after the software is deployed is guaranteed. Feel free to spend some cash on pen testing after the initial system is delivered. While fixing the findings of the pen test the outsourced developers are likely to introduce new problems that will be no longer within the original pen test scope.

Don’t bother with discussing the timely security fixes

It’s November 2021. Everyone in your outsourced development team works as an ethical hacker by night and knows everything there is on secure coding practices. The delivered application is pristine from a security perspective. You don’t really care about patching because the application is as secure as it can be. The software system goes to production. A month later, Log4J strikes! Your system has a critical vulnerability that is trivial to exploit. Your outsourced team meanwhile is involved with another project and is unavailable until Mid 2022.

At this point I hope that you are curious about whether it is possible to ensure your outsourced development teams can work at a level of risk you are willing to tolerate. In the next section, I will present a list of application security best practices for outsourced software development.

How to deal with outsourced development in your SDLC

Unsurprisingly, this security practice is largely about process and roles. There is not much tooling that you could use. You could require your suppliers to use the same set of tools your organizations does for the SDLC, but those tools are not really required to implement the supplier security practice.

The processes

Start with a SAMM Assessment of your outsourced development team

“If you can’t measure, you can’t improve.”! Your first job is to figure out what is the security maturity of your supplier. I am not aware of anything better than running an OWASP SAMM assessment to do that. I would recommend starting with a self-evaluation to be honest. Just provide your external team access to the SAMMY tool and ask them to fill out an evaluation. Self assessments are known to carry some subjectivity, but based on my experience so far I would say that the results are likely to be in the same ballpark.

Key SAMM practices your outsourced development team should ace

In my opinion your third-party development partner should score high for a number of SAMM practices. In general, I consider these practices more important. So I would also ask them to provide some more information on these. Here is a top 4 list of practices by the order of their importance and the type of evidence I would expect them to deliver.

• Software dependencies. What is the vetting process for managing dependencies? Is there a list of “known good” dependencies in place? Is there any tooling in place to scan the dependencies for vulnerabilities as well as other qualities (e.g., popularity, age)?
• Security requirements. Your supplier should take into account at least the very basic security requirements when developing an application or a component.
• Requirements-driven testing. Requirements-driven testing includes both control verification (positive test cases) as well as abuse testing (negative test cases). Ask for evidence on their policy when and how these are needed. Ideally unit and integration tests should be mandatory for all developers when providing a functionality. I would be less happy if they are leveraging QA with manual or end-to-end automated testing (e.g., Selenium, Cypress).
• Secure architecture. I would ask the team to provide more information on whether they know security design principles, whether they have reusable components and even reference architectures. It is also a good idea to check whether they have an establish set of technology and frameworks. More importantly though, is there a team in places that reviews the security quality of those frameworks and technologies.

I am well aware that I haven’t mentioned any SAST, DAST, SCA tooling here. I have rarely seen an organization that scores well on these items and doesn’t have a tooling in place. So honestly, I wouldn’t worry about the tooling that much.

Vendor compliance questionnaires and checklists

Many of you might know the typical excel questionnaire-style compliance checklists you have to fill out as a vendor. I have done my fair share of those. Some of those checklist items are highly relevant and I wouldn’t recommend against that. However in my experience compliance is not a good predictor of actual security practices. Your external partner may be ISO27001 certified, but score poorly on the SAMM practices that I have outlined above. On the other hand, a smaller team with a lot of tribal knowledge may have nearly no documentation in place, but score strongly on the key SAMM practices I have outlined in the previous section.

What are the key contractual security clauses when dealing with outsourced suppliers

Here is a list of most essential elements that you should sync with your legal team in increasing order of maturity.

Basic agreement with a minimum level of competence (Level 1)

Ensure basic security requirements, activities, and processes are included in your third-party contracts. Concretely, you should require a minimum maturity level for the most essential SAMM items. Here is a list of items you can start from.

1. The supplier should have a vetting and review process for software dependencies. No vulnerabilities should be present in the dependencies unless we explicitly sign off on those.
2. A list of most essential security requirements should be added to developed applications and components. I would recommend starting from the OWASP  Application Security Verification Standard (ASVS) level 1 requirements.
3. There should be a review process for all produced code. The review process should include unit and integration tests for all back-end logic including security requirements.
4. Timely patching for any vulnerabilities discovered after the software system has been delivered should be in the contract as well.
5. In general, it is a good idea to bring in Static Application Security Testing (SAST) and Dynamic Application Security Testing (DAST) tooling as a requirement. Tools are known to produce false positives and false negatives, but having some proven tools in place could help.
6. All outsourced developers should follow a minimal list of security training.

Formal agreements with clear responsibilities (Level 2)

Obviously, we are going to build on top of the items described in the previous section. In addition, you want to establish clear contracts that outline security responsibilities and expectations, including Service Level Agreements (SLAs). Concretely you might want to expand your contracts with items as follows:

• Guaranteed fix time for critical, high and medium vulnerabilities of 1, 7 and 30 days respectively. It is a good idea to agree on a triage process as well as a critical vulnerability might end up carrying low risk and vice versa;
• Mandatory penetration testing before any major release;
• Liability clauses for security breaches that hold your supplier responsible for any costs related to data breaches if it is proven that insecure code was delivered;
• Measure key performance indicators for your suppliers, such as vulnerability fix time and effort metrics.

Close alignment and integration with suppliers (Level 3)

Maximize alignment between your organization and suppliers by integrating processes, tools, and milestones. Use common development paradigms, shared environments, and tools like code repositories to ensure proper communication and qualitative progress. Implement compensating controls, such as threat modeling or additional security checks, when suppliers cannot fully meet your objectives.

Note that in my experience large organizations will formally make all outsourced development team members as external / temp employees of the organization. This means they have to follow the same set of processes and procedures, use the same tools and development practices.

Feedback loops to and from other security practices

Feedback loops are about information transfer from and to other activities in your software development lifecycle. For teams striving to higher maturity it is especially important to have these feedback loops. Here is a non-exhaustive list of feedback loops that are related to supplier security. We list only the strongest links.

Overall strategy and metrics

Your organization’s overall strategy and metrics are an essential input to supplier relationships. They ensure alignment with business goals, risk appetite, and security expectations. By incorporating security metrics such as vulnerability counts or response times into supplier agreements, you create a framework for measuring and monitoring supplier performance. This helps hold suppliers accountable to the same standards as internal teams, ensuring they contribute effectively to the organization’s long-term objectives and maintain a strong security posture.

Organizational policies and compliance obligations

Organizational policies and compliance obligations are essential in shaping supplier relationships. They define the security and legal requirements that suppliers must adhere to. By incorporating these policies into contracts, you ensure that suppliers meet industry standards  and align with your internal procedures. This reduces the risk of non-compliance, helps maintain data privacy, and ensures that suppliers uphold the security practices necessary to protect your organization.

Outsourced team security awareness and education

You should align your supplier training with your organization’s standards. That will ensure that outsourced teams are equipped to handle the minimum level of security expectations. Ideally, your supplier could have an even higher level of standards and expectations when it comes to training.

Security requirements

Your organization’s security requirements are obviously a constraint for what your suppliers will deliver. Hence, it is crucial to align the two activities and set a unified standard for security applications and data to ensure that the supplier’s work does not introduce any gaps in your organization’s overall security posture.

Timely fixes for defects

It is critical to have the right framework in place to ensure that high risk vulnerabilities discovered in production are handled within a strictly specified timeframe. This is the most important practice to have in place when working with outsourced development. You should also probably have a process in place to assign risk to vulnerabilities (often referred to as vulnerability triage).

The roles and responsibilities

Here is a list of stakeholders and their responsibilities when it comes to supplier security.

• Vendor Management
  The responsibility of the vendor manager is to maintain the reliability of the supply chain by overseeing the selection, negotiation, and ongoing relationships with external suppliers, ensuring they meet the organization’s demand while adhering to strict quality, cost, and security standards.
• Cybersecurity Regulatory Compliance
  The responsibility of the cybersecurity regulatory compliance officer is to ensure that the organization adheres to relevant laws, regulations, and industry standards, thereby avoiding legal penalties and protecting its reputation.
• Product security strategy
  This responsibility of the product security strategy officer is to build out and scale a product security program, ensuring that products are developed with security in mind.

Conclusion: Implementing Security Best Practices for Outsourced Development

In the context of outsourced development, maintaining a strong security posture is essential to mitigating risks and ensuring compliance. As we’ve discussed throughout this blog, security best practices for outsourced development are not just about having a good contract in place. They are about creating a structured, systematic approach that involves continuous collaboration and oversight. From assessing supplier competence and aligning them with your security requirements to establishing formal agreements and integrating processes, security must be embedded in every stage of the relationship. By following these best practices, organizations can effectively reduce the risk of vulnerabilities in delivered software, ensure ongoing security compliance, and foster long-term partnerships with outsourced development teams that align with their overall security strategy.

Links with other SAMM practices

This section provides a list of other SAMM practices that are relevant for supplier security. We provide the specifics of these dependencies in the feedback loops subsection. Note that we only list the strongest links.

• Strategy and metrics will define your supplier security relationships.
• Your organizational Policy and compliance aspects should be communicated to your suppliers.
• Ideally, the same list of training from Education and guidance should be mandatory for the outsourced developers.
• Security requirements should be part of your supplier agreements.
• Defect management provides a feedback loop to your suppliers to make sure they provide timely fixes to any issues.

Resources and further reading

• OWASP SAMM Fundamentals Course.