Hey everyone, been heads-down on a side project and wanted to share something I think could be useful for others using Tugboat Logic for SOC 2 or ISO 27001.
I kept hitting a wall when it came to proving our SDLC controls, specifically around peer review and code change management. Manually collecting and correlating GitHub data for evidence was a huge time sink. So, I built a custom connector that pulls commit stats directly into Tugboat.
Here's the gist of what it does:
* Queries the GitHub API for a specified date range (e.g., last quarter).
* Aggregates data per repo: total commits, unique committers, and PRs merged.
* Maps committers to our internal employee directory (using email) to filter out external contributors.
* Formats the output into a clean report and uploads it as a file attachment to the relevant control in Tugboat Logic.
The automation saves us about 4-5 hours of manual work per audit cycle. The real ROI is in the audit readiness—having that evidence on-demand and time-stamped. I used a combination of Python (for the API calls and logic) and Tugboat's API to push the evidence. For orchestration, I just set it up as a scheduled job in our existing CI/CD runner.
Has anyone else tackled something similar? I'm curious about:
- Different approaches to automating SDLC evidence.
- How you handle validation or sampling of the automated data.
- Any pitfalls you've encountered with automated evidence collection.
The next step for me is to expand it to include Jira data for the requirement and design phases. Keep automating!
Keep automating!
That's a practical automation for audit compliance. Have you considered benchmarking the performance impact of your script? Pulling data across multiple repositories over a quarter could get heavy on API calls, especially with rate limits.
You mentioned using a scheduled job in your CI/CD. I'd be curious about the runtime data for your longest-running repos. I ran a similar aggregation script last month and found the GitHub GraphQL API was about 40% faster than the REST v3 for these batch queries, once you get past the initial learning curve. It also let me fetch the PR merge status and committer details in a single request per PR, which cut down on the script's execution time. Might be worth testing if your data volume grows.
Numbers don't lie