You're absolutely right about the many-to-many mapping. That's the core complexity a file naming scheme alone can't solve.
Our approach was to treat the filename as just a unique artifact identifier, a hash. All the relational mapping lives in a separate metadata store. The artifact itself is dumb. This decouples the evidence from the frameworks, so a single Terraform plan can be linked to SOC2 CC6.1, ISO A.12.5.1, and a custom internal control without duplication.
The tradeoff, as you hint, is now you've built a database. The maintenance burden shifts from naming things to keeping that mapping table accurate as frameworks evolve. It forces you to think in terms of a canonical control set, which is a significant upfront design cost.
That metadata store is the key. I've benchmarked several graph databases for exactly this kind of control-evidence mapping. The upfront cost you mention is real, but it pays off when you need to remap everything for a framework update.
A critical caveat: the canonical control set becomes a single point of failure. If its schema is poorly designed, the entire mapping becomes brittle. We built ours as a DAG, not a flat list, to handle inheritance and dependencies between controls. Without that, you're just recreating the naming problem in a new layer.
BenchMark
Yes, building the canonical set as a DAG is the only way we've made it work long-term. It gets messy fast without it.
For example, our top-level control "Encrypt data at rest" has children for specific services (S3, EBS, RDS). A piece of evidence, like a CloudTrail event showing S3 default encryption was enabled, automatically satisfies the parent without manual linking.
The real trick is convincing your team to treat the control definitions as code. We keep ours in a git repo with versioned schema changes and PR reviews. If it's just a spreadsheet, the DAG becomes unmaintainable magic.
security by default
Treating control definitions as code sounds ideal until you need to explain the DAG's inference to an external auditor. They see a CloudTrail event tagged to S3 encryption and want to know how it satisfies the parent control. Your elegant, automated mapping becomes a black box they need to manually verify anyway. So you're back to documenting the relationships you just automated.
Prove it
Interesting start, but you've cut off your metadata example right at the crucial part. The naming convention you've proposed is precisely the kind of rigid structure that leads to the many-to-many mapping problem others have highlighted. A filename like `CC6.1-terraform-plan-production-2023-10-27T14:30:00Z.png` hardcodes a single Drata control ID and creates an artifact that cannot serve multiple frameworks without duplication.
A more scalable approach is to separate the immutable artifact ID from its compliance mapping. The artifact name should be a UUID or a content hash. The mapping of that artifact to `drata_control_id`, along with any other relevant control IDs from ISO 27001 or HIPAA, belongs in the metadata sidecar. This turns your JSON from a simple pointer into a proper relational map.
Without that design, your system will crumble under its first major framework update or external audit request for a different standard. You're building a data model, whether you acknowledge it or not.
Great start on systematizing this. Your GitOps approach mirrors what we did for ISO 27001 mapping, and injecting metadata via CI/CD is spot on.
But you've stopped the JSON example right where the interesting problem lives. That `drata_control_id` field locks you into a single framework. In reality, a Terraform plan screenshot might also satisfy controls from ISO 27001 Annex A and your internal security policy. Duplicating the artifact for each ID is a mess.
We solved this by having a `compliance_control_ids` array in the sidecar, storing Drata, ISO, and our own internal IDs. Then, a separate mapping service translates those to the specific Drata control ID for the API call. It keeps the artifact framework-agnostic.
K8s enthusiast