Third-Party Audits
"How we evaluate and monitor the external dependencies and vendors we bring into projects."
Hammad MajidWhy this exists
Every npm package and SaaS tool is a risk we accept on the client's behalf. Most supply-chain attacks target the code we trust without auditing. This process makes that trust deliberate.
Operational Flow
Pre-adoption review: Check three things before adding a dependency: weekly downloads, date of last update, and open CVE history.
npm packages: Run `npm audit` before adding packages and before every release. Abandoned packages (no updates in 18 months) require lead sign-off.
SaaS vendors: Confirm vendors storing client data have a SOC 2 report, a privacy policy, and a signed data processing agreement (DPA).
Permission review: Grant minimum scopes to integrations. Challenge broad requests like 'read all repositories' before approving.
Ongoing monitoring: Enable Dependabot on all repositories. Merge dependency updates within 14 days.
Vendor changes: Reassess integrations within five days if a vendor is acquired or changes their data terms.
Removal: Prune unused packages on a rolling basis. Do not keep old code 'just in case'.
What good looks like
- A developer checks npm trends and runs an audit before adding a utility, listing the results in the PR.
- Dependabot updates are reviewed and merged weekly instead of sitting in the pull request queue.
- The project lead reviews and documents vendor terms updates to confirm client data remains safe.
What NOT to do
- Don't add packages based only on search rankings. Check downloads and update history.
- Don't integrate a vendor that touches client data without a signed DPA. Brand reputation is not a legal contract.
- Don't let Dependabot alerts pile up. An open backlog of dependency PRs is a major security risk.
The xz Utils backdoor incident in 2024 showed that supply chain attacks are patient and don’t require mistakes on your part. They succeed because teams trust dependencies without checking them. We cannot audit every line of external code, but we can track what we add and why we add it. The goal is managed risk, not zero risk.
Client reviews will eventually ask whether all data processors have signed DPAs. You want to answer yes immediately. Get DPAs signed before writing integration code. Good vendors have them ready, and checking this upfront keeps you from having to fix a compliance gap later.