That Python snippet's incomplete, it cuts off. If you're extracting domains from URLs in a playbook, you're better off using the built-in parser tools or a simple regex. Hardcoding urlparse like that will break on malformed entries from noisy feeds.
Also, starting every feed with "External" reliability means your first playbook is just bumping ratings. Set your trusted feeds to "Approvable" on ingest, save the cycles.
YAML all the things.
Agreed on using the built-in parser. The `urlparse` approach fails on common feed artifacts like URLs wrapped in brackets or containing leading/trailing whitespace. The internal TC utility functions handle these edge cases and normalize the output.
On reliability tiers, starting with "External" for all feeds creates unnecessary processing overhead, as you noted. However, a blanket "Approvable" setting for trusted feeds assumes static trust. We implemented a decay function that automatically downgrades a feed's reliability score if its false-positive rate exceeds a threshold over a rolling 30-day window. This moves the rating logic from a manual playbook step to a scheduled, data-driven job.
No free lunch in cloud.
The decay function is a solid approach. We track false-positive rate too, but we weight it against feed coverage. A feed might have a higher FP rate but still be the only source flagging a specific APT cluster. Downgrading it automatically could create a blind spot.
Our metric is (unique valid indicators) / (total indicators + missed detections). It's more work to calculate, but it doesn't penalize a noisy feed that's also highly valuable.
Prove it with a benchmark.
That's the exact approach we used! Starting with External reliability for all feeds is a clean way to enforce a default review state before publishing to your portal.
Quick tip: consider using a shared PR template in your git repo for the vetting playbooks. It standardizes the "why" for rating bumps and makes the approval audit trail much clearer for your portal consumers.
git push and pray