Supplier Security Explained: Best Practices to Manage Supplier Risk

Updated: 7 December, 2024

20 October, 2024

What is supplier risk management about?

Outsourcing software development has become a cornerstone for many organizations, enabling them to accelerate innovation, reduce costs, and tap into specialized expertise. However, outsourcing also introduces specific risks, particularly in ensuring strong application security throughout the development process. This is where supplier risk management plays a critical role. By systematically addressing supplier-related risks, organizations can maintain a secure software supply chain while reaping the benefits of outsourced development.

In this blog, I will explore best practices for supplier risk management in the context of outsourced software development, offering actionable steps to ensure security is embedded across the software development lifecycle (SDLC).

Here’s a quick overview of three key pillars of managing supplier risks in outsourced development, adapted from OWASP SAMM, listed in order of progressive difficulty:

1. Supplier Evaluation: Assess potential suppliers against your organization’s security requirements, ensuring they meet your security standards before forming a partnership.
2. Security Clauses in Agreements: Incorporate detailed security clauses in supplier contracts to guarantee compliance with your organizational security policies and regulatory obligations.
3. Defining Security Objectives: Communicate clear and measurable security objectives to suppliers, ensuring they understand your expectations and deliver consistent security coverage throughout the development process.

It’s important to note that OWASP SAMM’s Supplier Security practice focuses specifically on outsourced development, where you have a formal, contractual relationship with the supplier. Unlike open-source dependencies—where contractual control is absent—this relationship allows you to enforce specific security practices, audits, and compliance requirements.

This blog is dedicated to addressing supplier risk management for outsourced development, presenting a structured, systematic approach to managing supplier relationships effectively while prioritizing security.

Key takeaways about best practices for supplier risk management

• Supplier risk management is the process of identifying, assessing, and mitigating risks associated with third-party suppliers to ensure they meet security, compliance, and business requirements.
• The “Supplier Security” practice of OWASP SAMM directly helps in managing supplier risk.
• Conduct assessments, such as OWASP SAMM evaluations, to understand the security maturity of your development partners and identify areas for improvement.
• Focus on critical areas like secure dependency management, requirements-driven testing, and secure architecture to strengthen the security posture of outsourced teams.
• Include clear contractual agreements that define security responsibilities, timelines for vulnerability fixes, and liability for breaches caused by insecure code.
• Promote close integration with suppliers by sharing tools, development environments, and processes to ensure seamless collaboration and adherence to security expectations.
• While compliance certifications are helpful, they do not guarantee robust security practices. Focus on actual security performance over documentation.
• Establish feedback mechanisms to align supplier performance with your organization’s goals and continuously refine the relationship for long-term security success.
• Ensure suppliers commit to timely updates and patch management to address vulnerabilities and maintain the application’s security over its lifecycle.

Why supplier risk management matters?

Security is an essential quality of any application, fundamentally tied to compliance and the reduction of risks. When working with outsourced software development, implementing a robust supplier risk management strategy is essential to safeguard your applications at every stage of the partnership. Here are several reasons why effective supplier risk management is indispensable:

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 a priority during development through proactive supplier risk management helps prevent these issues.
2. Ongoing support and patch management: Delivered software often requires ongoing updates and patches. Without proper supplier risk management measures, vendors may fail to deliver timely patches, leaving your systems vulnerable.
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. Supplier risk management ensures these risks are mitigated during and after development.
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 supplier risk management ensures compliance, helping you avoid hefty fines and legal penalties. Proper supplier risk management ensures compliance, helping you avoid hefty fines and legal penalties.

While larger organizations may already recognize the importance of supplier risk management, small and medium-sized enterprises might question its necessity. But what’s the worst-case scenario when supplier risks aren’t addressed in outsourced development? Let’s explore the potential consequences.

How to fail a project when working with outsourced development?

Imagine you have a great, friendly relationship with your outsourced development team. You’ve crafted a solid contract covering typical clauses like payment terms, non-solicitation, and other legal formalities. Maybe your legal team even added a few security-related clauses for good measure. So, what could possibly go wrong? Here are three satirical scenarios that highlight how neglecting supplier risk management can lead to project failure.

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, you might be wondering: is it possible to ensure your outsourced development teams operate within an acceptable level of risk? In the next section, I’ll share a list of best practices for supplier risk management in outsourced software development.

How to manage supplier risk in your SDLC

Unsurprisingly, the Supplier Security practice of OWASP SAMM 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 for Supplier Risk Management

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 for supplier risk management?

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 for supplier risk management

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).

Roles and responsibilities in supplier risk management

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

• 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 Supplier Risk Management

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.
• How to make sure you are wasting your time implementing OWASP SAMM.