We are in the final stages of evaluating a vendor who offers a "Claw" fork—a heavily modified version of the open-source Claw ERP. Our security team's standard RFP requirement, which was accepted by the vendor, stipulates the submission of a recent, comprehensive third-party penetration test report. Upon request, the vendor has now declined, offering only a generic "Security Overview" document and an attestation of SOC 2 Type II compliance.
This presents a significant data governance and risk assessment gap. From an integration architecture standpoint, the pen-test report is not merely a checkbox; it is critical for understanding the actual attack surface of the modified application, particularly its API endpoints and webhook implementations, which are central to our planned ecosystem. A SOC 2 report covers controls at a point in time, but does not detail technical vulnerabilities like:
* Insecure direct object references in REST APIs that could lead to data leakage across tenant boundaries.
* Weaknesses in the webhook signature validation or event payload consistency.
* Improper handling of authentication tokens in middleware layers.
Our procurement team is inclined to proceed, citing the SOC 2 as sufficient. I argue that accepting a modified product without this transparency is a substantial risk, especially concerning data consistency and integrity in our sync flows.
Has anyone encountered a similar impasse? I am seeking concrete, actionable strategies:
* **Legal/Procurement Leverage:** Specific contractual clauses you have successfully used to compel disclosure, perhaps under a strict NDA/confidentiality agreement.
* **Alternative Validation:** Technical evaluation rubrics or alternative security validation steps you employed when a full report was withheld (e.g., focused security questionnaire, insistence on a collaborative review session with their security architects).
* **Risk Acceptance Framework:** A structured format for documenting this specific gap as a known risk, including potential impact scenarios on data flow security, to formally present to our board.
Our current RFP template's security section, while requiring the report, lacks escalation mechanics for this refusal. I need to strengthen it for future use.
Any shared templates, clauses, or evaluation scorecard modifications would be invaluable.
Single source of truth is a myth.
You're right to be concerned, but your procurement team being "inclined to proceed" is the real red flag here. SOC 2 Type II is a check for their *internal controls*, not the security of the actual *software* they're trying to sell you. It's a compliance exercise, not a safety guarantee.
They've already accepted the requirement in the RFP. Their refusal now means one of two things: the pen test was never done, or the findings were so ugly they can't risk you seeing them. A heavily forked codebase is a custom attack surface. Their generic overview is meaningless for your specific integration risks.
I'd halt the process here. If they won't provide it, they've failed a core requirement they agreed to. Proceeding tells them your security gates are just theater.
Your mileage will vary