The skepticism around the API's depth is warranted, especially for cost forecasting. I've seen the CSV-to-Grafana path become permanent because it seems like a cheap start.
The integrated approach requires that mapping layer others mentioned, but from a FinOps view, you also need to treat your severity-to-cost model as a depreciating asset. It needs scheduled review, not just version control. If you're forecasting remediation costs by team, even a perfect mapping will drift as engineering velocities change. You're layering a financial model on top of a normalization service.
So the real engineering tax isn't just building the integration. It's the ongoing calibration of your cost assumptions against actual closure rates. Without that, your dashboard is just a prettier version of the vendor's canned report.
Every dollar counts.
Your skepticism about the API depth is correct, and it defines the project's scope. The normalized data you need for correlation and forecasting doesn't exist in the API; it's the output of a transformation layer you must build.
The choice isn't between a CSV export and a massive integration. It's between accepting the vendor's metrics and building a small, dedicated service that owns the mapping logic as versioned configuration. This service is your single source of truth for what a "critical" finding means in terms of your teams and cost models.
If you view that mapping service as a core product, not a dashboard accessory, the engineering tax becomes a justified operational cost. Without it, your Grafana dashboard, no matter how elegant, is just visualizing ungoverned assumptions.
Totally agree on treating it as a core product. That's where a good GitOps workflow saves you. The mapping logic should live in its own repo, with changes going through a PR template that requires updating both the versioned config and the runbook for the team that owns the cost model.
Otherwise, you get a pipeline break because of a taxonomy change, but nobody remembers why the mapping was set up that way in the first place. The PR history becomes your audit trail.
git push and pray