Integrating Third-Party Packages

March 11, 2022 | Posted by Neil Jain

Building out products and features is no longer about owning all the code used. As technology continues to grow at an astronomical rate, it remains necessary to utilize open-source code in the form of third-party packages and APIs.

Third-party packages and APIs enable you to leverage code written by other individuals to get to your goals faster and build out desired features with ease. A great example of this would be the requests package in Python. This package lets you simplify HTTP requests so you can automate your processes without worrying about the overhead. Though requests is a highly used and well-maintained package, there are thousands of other projects out there which can be leveraged—so how can you decide which package is best to use? Integrating with third-party code can be broken down into 3 major areas of consideration: vetting the package, determining security risks, and implementing the code.

Vetting a Package

Finding the right package to suit your needs is a difficult task but not impossible. First, determine if you need a third-party package by checking if the project you are aiming to implement is a common project. Often there will be solutions online that allow you to plug and play. Second, see if the project suffers from scope creep by ballooning into way more work than expected—this can be a clear indication of needing some external resource. Once you have decided that a third-party package is the solution you should not only find out the possible options and narrow them down by determining what each solution would make easier and harder for you, but should also determine what this solution would enable you to do in the future. A critical mistake is seeing only the short-term potential in a package without considering the long-term implications of incorporating this package into your code. Remember, once implemented, that package is now part of your codebase and for better or worse any extra features aiming to be built will require its support. To build a product with continued growth, aim for packages that solve your solutions now and leave room for improvement in the future. Finally, using anyone else’s code can lead to legal issues regarding the license and redistribution of the software. Make sure to double check their rules and reach out to anyone with expertise if you are not sure.

Questions to consider:

  1. Is a third-party package needed? If so, why?
  2. Is there a viable option out there?
  3. How does this package benefit/harm the maintainability of your code?
  4. Are there any legal issues?

Determining Security Risks

Once the package has been vetted, you should then look into the security risks. A fundamental principle in security is that you inherit the risk of any other product or code that you use. Using a third-party package will open you up to attack from multiple new attack vectors, and it becomes necessary to mitigate these issues. When looking at the package, look for things like how well it is maintained so any future issues will be resolved by the maintainers in a timely manner. Also, assessing what parts of the code this package will touch will help determine its potential impact. To determine impact you can follow the flow of data and see where in your database the package is able to read and write as well as if there are any leaks into inbuilt functions which can be leveraged for an attack. A great example would be using a third-party package for your login flow: this data is more sensitive and higher priority than a package used to solve unit testing issues. Finally, are there any known vulnerabilities for this package? Depending on the type of vulnerability, the purpose of the package, and your security posture, you may reject a package with known vulnerabilities or you may choose to risk accept the vulnerabilities and move forward with the package. Overall, it is important to be aware of what attack vectors you will be introducing into your codebase.

Questions to consider:

  1. Is the package well maintained?
  2. What new attack vectors does it open your product to?
  3. What parts of your product will the package be interacting with?
  4. Are there any known vulnerabilities?

Implementing the Code

When determining the package’s implementation, you need to worry about the support the package gives in terms of documentation and community. Having good documentation and people to answer questions can help you better utilize the resource and efficiently consume it. Also, make sure the package has code that is customizable in the form of interfaces, functions able to be overridden, well placed variables, etc. Having this customizability will enable the package to expand into additional functionality in the future. Finally, does this package change how you wish to implement your product/project? It’s important to consider the trade-offs between ease of implementation and any architectural changes necessary to bring this package into your project.

Questions to consider:

  1. Is there enough documentation and support for questions?
  2. Is the code customizable?
  3. Does this package drastically alter your implementation?