Having spent considerable time evaluating Secureframe's platform for orchestrating compliance evidence collection, I find their much-touted "integration marketplace" to be a point of significant architectural frustration. The core issue, in my professional opinion, is a fundamental misalignment between marketing terminology and engineering reality. Labeling these as "integrations" creates an expectation of bidirectional, automated data exchange—what many of us would call a true API integration. What we largely receive, however, are glorified webhook endpoints.
This design pattern shifts the burden of integration complexity entirely onto the customer's engineering team. Secureframe provides a trigger (a webhook) and a schema, but the actual work of polling the source system, transforming the data, and handling retries, errors, and authentication renewal is an external responsibility. This isn't an integration; it's an integration *hook*, and a fairly basic one at that.
Let me illustrate with a concrete example from the infrastructure domain. Consider the requirement for "Encryption at Rest" evidence from AWS. A true integration would involve Secureframe's backend using a read-only IAM role to periodically query AWS KMS via the AWS API, directly validate key policies, and link aliases to resources. What we often get instead is a mechanism where:
* Secureframe asks you to configure an SNS topic or an EventBridge rule to forward specific events.
* You must then ensure those events are captured, normalized, and posted to their webhook.
* The logic to correlate a `kms:CreateKey` event with an actual resource and its configuration is absent.
This pattern repeats across numerous services:
* **Vulnerability Management:** Expecting a webhook from Tenable/Wiz/Qualys instead of the compliance tool pulling via API on a schedule.
* **Identity & Access:** Webhooks for IdP events rather than SCIM or direct directory queries.
* **CI/CD:** Needing to push pipeline logs rather than the compliance platform having a read-only OAuth app to GitHub/GitLab APIs.
The operational overhead this creates is substantial. You are now running and maintaining "integration glue" code, which becomes a critical compliance path itself. This code needs:
* Secure credential storage.
* Error handling and dead-letter queues.
* Idempotency.
* Logging and audit trails.
A more robust architectural approach, which I would expect from a platform in this space, would be to offer genuine, managed integrations. Secureframe's backend should be the actor performing the API calls, using customer-provided credentials stored in a secure vault. This centralizes the logic, the error handling, and the audit log. The current webhook-centric model feels like a cost-saving measure that externalizes complexity and risk.
I'm curious if others in the community have hit similar walls. Have you built internal middleware to manage these "integrations"? Are there particular services where Secureframe's connector is actually a true, active integration, and how does that compare? The distinction between a push and a pull model in compliance automation is not trivial—it directly impacts reliability, auditability, and maintenance burden.
--from the trenches
infrastructure is code