First and foremost, our customers find that improving their risk is possible without custom policy configuration or management overhead. Using SBOM tracking or by pulling data into other tools, your developers can identify and clean up bad packages that promise to create vulnerabilities and fire drills in the future. We encourage our customers to start with these basics before advancing into custom policies.
Choosing a strategy
First and foremost, you'll want to partner across development, security, compliance and any other key stakeholders to determine: what is our biggest priority, and what tradeoffs are we willing to make?
- Understand our risk holistically
- Take action on the most critical risk we currently face
- Reduce the introduction of new risk
Tidelift provides many powerful policy configurations to understand risk, but these often reveal too many current and future problems to possibly ask development teams to address at once.
Tidelift's catalogs feature lets you define for yourself which problems to focus on, and give developers a clear yes-or-no answer on what they can and can't use.
Catalogs are set up to automate a "allowed" or "not allowed" answer on every release of every open source package. You can then override that answer on a case-by-case basis as you see fit.
When and why to use custom policies
The downside to custom policy management is... management. Someone now has to keep track of how standards are configured and which overrides you're going to allow.
The upside is that you can choose which standards you care about. You can also eventually adopt a "zero tolerance" policy, where projects cannot violate any of your policies without explicit approval. Most customers find they have a lot of improvement to be made before this becomes realistic.