Dependency Review¶

Below are a list of dependencies that I have security reviewed and determined whether they pose an acceptable level of risk or not. These assessments are based on my review of the dependencies' security practices, code structure, CVEs, time to response, and other relevant factors.

How They Are Measured¶

The dependencies below are measured against an overall rubric of:

More specifically, here is the check list that I evaluate each dependency in the following order:

1. Socket.dev scoring
   • Evaluate alerts
   • Evaluate scores and their reasons
   • Allows for fail fast during dependency review.
2. Dependency maintenance and activity
   • Should generally have at least yearly activity
   • If not exhibiting yearly activity, it should have source code activity in its repository.
     • E.g. sequelize, publishes infrequently but is in active development in its repository.
   • Alternatively, if low activity is observed, it should then be so simple that it doesn't need frequent work/updates.
3. CI/CD Practices
   • SLSA Level 3 or higher is preferred
   • Credential-less systems
     • OIDC preferred
   • Human-free publishing
   • Human approvals are fine, this is meant to ensure that the build and publish process is fully automated in GH Actions/GL Runners
   • Unification of package management
   • Removal of dev time artifacts from production builds
4. Mean time to patch CVEs
5. Code Review
   • This is put lower in the list since it is an intensive and time-consuming process and fail-fast allows for time savings by quickly eliminating high-risk dependencies before investing time in code reviews.
   • The code review is a "trust but verify" step, ensuring that even if other checks pass, the code is still scrutinized for potential security issues.
6. Is the author open to security and/or other improvements
   • This is evaluated over time, not necessarily immediately.

Dependencies That Are Auto Approved¶

As an ex. Microsoft engineer in MSFT's SAS organization under CSEO, I got to see the security requirements and systems that Microsoft has for their external facing official products.

Microsoft follows SDL, and OSA which are enforced by 1ES and SAS internally. To protect HVAs, MSFT uses PAWs, and HREs to isolate and secure them using assume breach principles. These practices that I followed and studied while at MSFT and meet or exceeded my requirements for evaluating the security of dependencies.

I base my evaluation of acceptable risk off of the internal SAS standard at MSFT. Albeit, not as closely as I am a single person with limited resources. I still try my best! If you notice something that could be improved, please let me know.

Approved List¶

List of dependencies I have approved for use in my projects.

These meet my requirements based on how I define acceptable risk and security standards.

Ban List¶

Sometimes deps pass the sniff check, but fail upon deeper inspection. These are a list of dependencies that are deemed too risky or problematic to be used in any projects.