I've been looking closely at our tech stack and found a bunch of open-source packages that weren't exactly what I expected. Things like unnecessary analytics SDKs, strange beta versions, and some unexpected outbound traffic that we didn't notice until it was in staging. I'm curious—how are you all catching potential issues with third-party packages before they make it to staging or production? Are there specific tools or strategies you use, maybe something that can work in CI? I'm open to any suggestions or experiences you can share!
5 Answers
There's a whole market around this called Software Bill of Materials (SBOM). I personally use the FOSSA CLI for tracking dependencies. We also limit connections to only what's necessary, disabling anything extraneous to minimize risk.
Implementing Software Composition Analysis (SCA) tools can really help spot issues early. We also make it a practice to review all tools' GitHub repos—looking at comments and last updates—to understand their current status and potential issues.
Before I install any package, I always check its GitHub repository. I want to see how actively it's being maintained—like the number of stars, the number of maintainers, and if there are many open issues, especially security-related ones. If a package has been untouched for months and has unresolved security issues, I definitely steer clear of it.
We have a system where developers can use their preferred tools, but our CI/CD pipelines only pull from our validated Git repositories. If any new third-party code is introduced, it undergoes a thorough review process, ensuring any risks are caught right away.
We have multiple layers of reviews for our dependencies. Every pull request must be approved by at least one other person, who also checks that our standards for adding dependencies are met. We have bi-monthly audits and an annual review process where security assesses all new dependencies against our compliance standards.
Can you use FOSSA without an API key? I only found info about using it with one.