Claw's recent "security disclosure" for SDK 2.1 is a masterclass in damage control, not engineering. They've patched a single, glaring CVE (CVE-2024-xxxxx) while ignoring the architectural debt that made it possible. Calling this a "security-focused release" is a stretch.
Here's my breakdown after running their new version through our internal procurement checklist:
* **The "Fix":** They've added input validation on the `claw.ingest()` method. Good. It should have been there in 1.0. It's a localized patch.
* **The Unaddressed Core Issue:** The SDK's telemetry layer still uses the same implicit, non-configurable HTTP client for all outbound calls. No opt-out, no custom certificate pinning, no proxy support for air-gapped environments. This fails our procurement rule #3: "Vendor libraries must not hide network dependencies."
* **Compliance Gap:** Their updated security whitepaper still lacks a clear data flow diagram (DFD) for the SDK. Without that, we can't complete our PIAs for GDPR/CCPA. This is a blocker for any regulated environment.
What I learned from this "disclosure":
1. Vendor security announcements are often reactive, not proactive. The benchmark should be their *entire* architecture's security posture, not their patch velocity.
2. Our evaluation framework now includes a new test: "Does a vendor's security update address root causes, or just symptoms?" Claw's update scores low.
Anyone else done a tear-down? Specifically, have you validated if their new input sanitization is comprehensive, or just a blocklist for the exploit vector they got burned on?