Evaluate the reputation and track record of the vendor. Check reviews, case studies, and references from other clients. Ensure the vendor is financially stable and likely to continue operating and supporting their products in the long term. Review the support options and service level agreements (SLAs) to ensure they meet your requirements. Ensure the vendor complies with data protection regulations and has robust measures for data encryption, access control, and privacy.

Usually I prefer to have a way out, i.e. if more than one vendor or solution exists I would invest in a thin wrapper around the interfaces to the 3rd party piece so that if there is a serious issue I could replace it. In addition I would invest in a set of tests on top of the wrapper so that I can compare vendors and evaluate alternatives. Also, it is vitally important to have a mechanism that allows to lock a specific version of the 3rd party element and only update it if and when the new version is tested in-house. If the source code is available, I would use git submodule mechanism, otherwise the packaging dependencies may help. When choosing a vendor or a solution I prefer a better documented and open source one.

When managing third-party dependencies, it’s crucial to ensure that potential risks are effectively mitigated. Here’s how I approach this: • Verify certifications, especially for SaaS providers, to ensure compliance with industry standards. • Request detailed SLAs, architecture for resilience, and business continuity plans (BCP). • Organize dedicated sessions with internal experts to cross-check their claims. • Ask for references to call and validate experiences. • Request a proof of concept (PoC) and performance reports to assess capabilities. This process ensures that any third-party integration is reliable and aligns with the system’s requirements.

Mitigate third-party dependency risks with these strategies: Vendor Due Diligence: Research vendors, evaluate their security practices, and check compliance with standards. Dependency Management: Use tools to track and update dependencies, automate vulnerability scanning, and generate alerts. Security Testing and Audits: Conduct regular security assessments, including penetration testing and code analysis. Incident Response Planning: Develop a comprehensive plan, establish communication channels, and practice incident response drills. Contractual Safeguards: Include strong security clauses, SLAs, and audit provisions in contracts. Monitoring and Logging: Implement robust monitoring and logging to detect anomalies and potential threats.

To mitigate risks with third-party dependencies, I would implement several strategies. First, thoroughly vet the reliability, security, and compliance of each third-party provider. Second, ensure modular design to allow easy replacement or updates of dependencies without affecting the entire system. Third, establish robust monitoring and fallback mechanisms to detect and address failures in real-time. Fourth, create a contingency plan with alternative providers if critical services are interrupted. Lastly, maintain regular updates and patches to stay protected from vulnerabilities and performance issues.

Here's what I usually do : 1) I see customer reviews i.e. what other are saying about this 3p dependencies, open issues and how quickly they respond. 2) Always test new version before taking it to production. 3) Make it enough configurable that you can switch to different 3p dependency on a eye blink ;). 4) Always keep monitoring that how they're performing, raise alarm/ticket if something out of the way 🙂

As per me we should be doing few things - Properly vet the Third part dependencies - Have process which constantly monitor these dependencies. In code it can be GHAS, Snyk, etc. In process it cane be annual or half yearly audits. - if there are certification requirements like SOC-2, ISO-27001 etc make sure that reports are thoroughly verified. - Check if the proper SLA is there and it meets the requirements. - Make sure if the Dependencies need to be replaced there are interfaces which makes it easier to replace.

All of the existing perspectives are valid and critical to mitigating risk. However, I have seen more failures due to the lack of expertise created or leveraged around third-party dependencies. Not having an excellent understanding of a dependency or tool, failure to build internal knowledge and lack of on-demand access to expertise associated with third-party tooling and dependencies have caused more negative outcomes than anything else in my experience. Having a tool your organization doesn't understand and thus cannot leverage successfully can be worse than not having the tool. Bringing a new dependency into your environment is never the end; you must have a plan to own, maintain, and operate things over time.

The first thing is to evaluate how many of those dependencies you need. Building on the shoulders of giants, as it were, is always great when you are getting started, but over time, supporting all that 3rd party code, especially if it's very rapidly evolving (one end of the spectrum) or if it's stale and gets abandoned (the other end) can be brutally expensive - consuming most of your in-house R&D time. Select dependencies that are widely adopted and vital. Try to avoid things that could wind up as abandonware, where you would wind up owning it, to support it yourself. Next, try to build an interface layer that lets you swap 3rd party packages. Finally, keep an eye on them. Do you need to patch? Replace? Be active.