Dependency Due Diligence

Last modified 10 Jul 2026 12:11 UTC
Work in progress

TODO: Intro

Read this entire document from start to end before introducing even the smallest tiniest dependency to the project.

Why?

  • Security. Even smallest dependency can completely compromise the system.

    • Consider supply chain attacks.

  • Maintainability

  • Legal: Copyright, CRA

How?

Risk-based approach. We have to trust the authors/maintainers. It is not realistic to check every line of code of all the dependencies.

Very few strong criteria, mostly green and red flags.

In case of any serious doubt about security or maintainability → avoid use of that dependency. Every dependency is a major obligation. Short term setback is better than long-term nightmare.

When not sure, talk to your team leader.

Copy-pasting any non-trivial code counts as dependency too!

Never copy-paste a code that you do not understand. Never add AI-generated code that you do not understand. You are personally responsible for any single line of code that you commit, no matter whether you have copied it, used AI to generate it, or used any other method. You have committed it, it is your code now. You are responsible.

Applies to AI-generated code too! Be doubly vigilant in that case.

Important: Never ever introduce new dependency without doing any of these checks! Never!

Outright Showstoppers

  • License: OSS, compatible with EUPL, no strong copyleft (GPL, AGLP; LGPL is fine) If not pure OSS (e.g. open core), this is a red flag, but may not be an outright showstopper if the OSS part of good.

  • Source code not available, or just "thrown over the fence" (no git repo). Never rely on binary artifacts alone. Always check the source code! You have to see the source code (including history) with your own eyes. Make sure the source code is sane: there is README, release notes, build files, license file (see below).

  • Vibe code

  • Starting dec 2027: no CE marking

Proportionality

  • Do we need it at all?

  • Better to implement ourselves?

  • No leftpad! Never! showstopper.

  • How big is it? Count source code lines if in doubt (e.g. cloc).

  • Avoid dependency creep! Every new dependency is a major obligation!

    • Better use dependencies from platform (Java, Spring), even if they are slightly worse.

  • The bigger the dependency, the deeper due diligence.

    • Security needs to be considered for all dependencies, even the smallest.

Liveness Check

  • Is the project alive?

    • When was last commit?

  • Is it maintained?

    • How many releases? How often? Regular release schedule?

    • How many maintainers? Single-person projects → huge risk

    • Is it maintained by a single company → risk

    • Are most commits made by a bot or placeholder account? → investigate, potential risk

  • Governance: Steward/Foundation?

  • Community: Does community exist?

    • Discussion? Mailing list? Forum?

    • How do mainatiners communicate? If arrogant or incomunicado → huge red flag

    • Open/resolved issues

    • Pull requests?

Quality

  • Basic sanity check (Always must be done):

    • Source code is available, including history

    • Make sure the source code is sane: there is README, release notes, build files, license file (see below).

  • Release notes

  • Quick look at the code

  • Documentation. No documentation → huge red flag

  • Tests?

  • Is the project overhyping AI, or does the code look AI-generated → investigate, be very vigilant, may be a showstopper (e.g. vibe code)

  • Red flags: exotic build system, exotic source code control (not git), strange build system setup (arcane plugins), private repositories (not maven central), non-standard licensing or commercial terms, paywalls, etc.

  • How old is the project? Too old or too young are risky.

  • Is the project stuck in the past? E.g. stuck in Java 8? → huge red flag

  • When in doubt: Download the code and build it. WARNING! Can be dangerous (Maven plugins, tests). Check the code visually and/or check provenance/governance/trustworthiness before attempting to build it! Do not import project to IDE before checking. IDE may build the project or execute parts of it without your knowledge.

  • Prototype!

Do not get fooled by brands.
Do not assume that a project is good just because it comes from a well-known organization. Many projects maintained by Google, Apache or Eclipse are quite bad. Do not get fooled and explore the project responsibly.

Security

  • Review release notes and documentation for mentions of security considerations

  • Check git log and/or releases for evidence of security patches.

  • Look for CVEs, security advisories, etc. Any evidence that the security process works for the project. (reasonable number of CVEs is in fact good sign, the project cares about security).

  • Automated security scan.

  • Transitive dependencies.

  • Consider supply chain attacks. Dangerous packages: NPM, PIP, etc.

  • After Dec 2027: Check for CE marking and associated documentation (CRA). No CE marking → showstopper.

Contributing

  • Is project open for contribution?

    • Check contribution guidelines

    • CLA requirement?

  • Can be build it?

  • Can we test it?

Plan B

  • Can we fork it?

  • Can we find alternative implementation?

  • Can we implement it ourselves? What would be the cost?

Maintenance

Remember that introduction of new dependency is just a beginning. The dependency needs to be maintained!

Was this page helpful?
YES NO
Thanks for your feedback