Fifteen Guidelines for a Healthy Software Supply‑Chain Dependency Management (Part 2)

Pre‑inclusion Checks (9 items)

1. Design Review : Verify that external packages have clear documentation and a well‑designed API; check for compatibility notes on future upgrades.

2. Code‑quality Review : Examine source code for readability, consistency, and safety; enable compiler warnings such as -Wall and watch for unsafe constructs like unsafe in Go, Rust, Swift.

3. Automated Testing : Ensure the package includes runnable test cases that pass, and consider coverage, race detection, memory‑usage and leak detection.

4. Debugging & Maintenance : Review the issue tracker for open bugs, their age, and resolution rate; assess commit activity and the number of maintainers.

5. Usage Popularity : Check how many other packages depend on it; high adoption often signals better maintenance and quicker bug fixes.

6. Security : Confirm the package handles untrusted input safely, and verify it is not listed in the NVD for known vulnerabilities.

7. License Review : Ensure the package’s license is present and compatible with your project; avoid risky licenses such as AGPL or WTFPL.

8. Transitive Dependencies : Inspect the package’s own dependencies; indirect dependencies can introduce the same risks as direct ones.

9. Custom Isolation : If a package cannot be safely isolated, consider wrapping it behind a thin interface or copying only the needed parts.

Post‑inclusion Usage (6 items)

1. Encapsulation : Define a small interface that abstracts the dependency, exposing only the functionality you need.

2. Runtime Isolation : Run the dependency in a sandbox or separate process (e.g., Chrome extensions, gVisor) to limit crash impact.

3. Avoid When Risk Is High : If a dependency is too risky and cannot be isolated, drop it entirely or replace the risky part.

4. Update Strategy : Regularly evaluate upgrade costs versus bug‑fix benefits; perform manual verification before automated upgrades.

5. Continuous Monitoring : Track versions, hash signatures, and newly introduced indirect dependencies; verify integrity with cryptographic hashes.

6. Periodic Re‑assessment : Re‑evaluate each dependency at upgrade time and on a regular schedule for security history and maintenance status.

Example: The infamous event-stream incident showed how a tiny transitive dependency ( left-pad ) could break thousands of projects when removed.

Overall, rigorous pre‑check criteria, disciplined post‑use practices, and ongoing monitoring together form a robust defense against supply‑chain failures and security breaches.