I've been running Secureframe for SOC 2 and ISO 27001 for about eight months now, and while the platform is decent for evidence collection and auditor hand-holding, its native reporting for ongoing operational visibility is frankly superficial. The "dashboard" they provide gives you a green/red status and some high-level percentages, but it tells you nothing about velocity, drift over time, or which specific control families are causing the most recurring toil for your engineering teams. If you're serious about FinOps and treating compliance as an engineering process, you need metrics.
So I built a pipeline to pull data from Secureframe's API into Grafana. The goal is to track compliance as a set of key performance indicators, not just a binary pass/fail. You can see control implementation trends, mean time to remediate findings, and correlate compliance activity spikes with deployment cycles. Here's the core of the collector script I wrote in Python; it runs as a Kubernetes CronJob every six hours.
```python
import requests
import pandas as pd
from datetime import datetime, timedelta
SECUREFRAME_API_KEY = os.environ['SECUREFRAME_API_KEY']
HEADERS = {'Authorization': f'Bearer {SECUREFRAME_API_KEY}'}
BASE_URL = 'https://api.secureframe.com/v2'
def get_all_pages(endpoint):
"""Handles pagination for Secureframe's API."""
results = []
url = f'{BASE_URL}/{endpoint}'
while url:
resp = requests.get(url, headers=HEADERS)
resp.raise_for_status()
data = resp.json()
results.extend(data.get('data', []))
url = data.get('pagination', {}).get('next')
return results
# Fetch controls and their status history
controls = get_all_pages('controls')
control_statuses = []
for control in controls:
history = get_all_pages(f'controls/{control["id"]}/status_history')
for entry in history:
entry['control_id'] = control['id']
entry['control_name'] = control['name']
control_statuses.append(entry)
# Convert to DataFrame for transformation, then ship to Prometheus via pushgateway
df = pd.DataFrame(control_statuses)
# ... further processing and metrics emission ...
```
The dashboard visualizes several key areas:
* **Control Health Over Time**: A stacked graph showing the count of controls by status (implemented, not_implemented, partially_implemented) per day. This exposes drift the moment it starts, not during a quarterly review.
* **Remediation Velocity**: Calculates the average and 90th percentile time between a control status changing to 'not_implemented' and returning to 'implemented'. This is a critical DevOps metric for your compliance loop.
* **Top Recurring Control Failures**: A table ranking control families (e.g., 'Access Control', 'Change Management') by the number of status regression events in the last 90 days. This tells you where to invest in automation or process fix.
* **Evidence Submission Latency**: Tracks the time delta between when an evidence item is requested (e.g., for a sample check) and when it is submitted. This identifies bottlenecks in your response workflow.
The initial setup took a weekend, but the payoff is concrete. Last month, this dashboard identified that our 'Logging & Monitoring' controls were regressing consistently 2-3 days after major deployments. The root cause was a Helm chart change that was inadvertently disabling a required sidecar in one namespace. The native Secureframe UI would have just shown a red 'failed' control a week later. We caught and fixed it in the same deployment cycle.
I'm publishing this because the compliance tool market is saturated with vendors selling 'peace of mind' but not operational intelligence. If you're already paying for Secureframe, you might as well extract the data and make it work for your engineering goals. The API is reasonably documented, though you'll need to handle pagination and some nested relationships.
Has anyone else built similar integrations? I'm particularly interested if you've found a way to pull cost data from your cloud provider and correlate cost spikes with compliance activity (e.g., a surge in evidence collection tasks after a new service launch).
—emma
FinOps first, hype last
This is such a cool idea! I've been staring at those same green/red percentages and feeling like I'm missing the real story. Pulling it into Grafana for trends makes total sense.
I'm just starting to learn orchestration, though. You mentioned it runs as a CronJob every six hours. Did you consider using Airflow or Prefect for this instead? I'm wondering if there's an advantage to handling retries or alerting if the API call fails, or is that overkill for something like this?
rookie
Great question! Honestly, my first pipeline version was a Prefect flow 😄 It handled retries and had a Slack alert if the Secureframe token expired. It was "proper" orchestration.
But I scrapped it because the schedule was so simple, and the API is remarkably stable. The CronJob is just a Python script in a container, and it's been running for months without a hiccup. Adding a full orchestrator felt like unnecessary overhead for this one task.
If you're learning orchestration, though, I'd say build it with Prefect first! It's a fantastic way to learn the patterns, and you can always simplify later. Plus, if you start pulling from multiple sources (like adding HR data for employee training compliance), you'll definitely want those dependencies and retries.
Data nerd out
Totally agree the native dashboards are just a compliance checkbox, not an engineering tool.
We track mean time to remediate findings as our primary KPI. It directly shows if the process is getting more efficient or if a specific control family (like access reviews) is becoming a bottleneck. Seeing that trend line move down over the last quarter proved the value of the tooling investment to leadership.
How are you handling historical data? Backfilling via the API when you first set this up was a pain for us.
Ship fast, review slower
Mean time to remediate is a solid metric, leadership loves a simple downward trend line.
For backfilling, the API pagination is the real blocker. I wrote a script that just loops and sleeps, dumping raw JSON to S3. It's ugly but it ran overnight. Once you have the raw payloads, you can transform and load them later without hitting the API again. I keep everything in S3 for that reason, it's cheap and you never know what you'll need to recalculate.
Beep boop. Show me the data.