Failure PatternDecision layer
The PatchClock SBOM Theater Trap: Agencies Publishing CycloneDX Files Nobody Reads
Symptom: Client dashboards show a fresh CycloneDX SBOM after every tagged release, yet no one on the agency side has opened a CVE alert in weeks. Root cause: PatchClock generates SBOMs and alerts from lock files, but the tool has no way to force a human to triage a CVE; agencies treat artifact generation as the deliverable and skip the review step.
By InnovaAI ResearchPublished
How do you recognize it?
- •Client dashboards show a fresh CycloneDX SBOM after every tagged release, yet no one on the agency side has opened a CVE alert in weeks
- •Support period pages and security.txt go live on client domains, but the client's own marketing site still carries an expired disclosure copy because renewal warnings were routed to an unmonitored inbox
- •Article 14 incident drafts sit in PatchClock with the 24-hour clock already running while the agency waits on client sign-off for facts the tool cannot verify
- •Agency bills a compliance retainer for three clients but the workspace shows only one product connected, meaning two clients are paying for SBOM generation that never runs
- •Founding member offer seats (5 people, 3 products) get consumed by internal staff, leaving no seat for the client contact who must actually file the ENISA report
Why does it happen?
- •PatchClock generates SBOMs and alerts from lock files, but the tool has no way to force a human to triage a CVE; agencies treat artifact generation as the deliverable and skip the review step
- •The 24-hour, 72-hour and 14-day Article 14 clocks start on incident detection, not on agency acknowledgement, so a slow client escalation path burns the deadline before drafting begins
- •Support period and security.txt publication is hosted by PatchClock, but the copy on the vendor's own site is separate and only flagged by expiry warnings that default to email, which agencies rarely forward to a shared queue
- •Plan limits are counted in products and people, so agencies that onboard clients under their own workspace rather than the client's hit the 3-product ceiling on the founding member tier and silently stop generating SBOMs for later clients
How do you fix it?
- •Open each connected product in the PatchClock workspace and confirm composer.lock and package-lock.json are being read on tagged releases; disconnect and reconnect any product whose last SBOM timestamp predates its latest release
- •Re-point CVE alert and security.txt expiry notifications to a shared agency triage inbox or channel, then assign one named owner per client product inside PatchClock
- •Audit seat and product counts against the plan ceiling (3 products and 5 people on the founding member offer, 20 products and 15 team members on the Agency plan at 79 € per month) and move overflow clients to their own workspaces
- •Run a tabletop Article 14 drill in PatchClock's incident runbook so the client sees the 24-hour clock expire in a test, then agree in writing who declares an incident and who signs the ENISA submission
More on PatchClock
- StrategyWhy PatchClock Turns CRA Deadlines Into Agency Retainer Revenue
- ConceptPatchClock Retainer Ladder
- Evaluation RulePatchClock Rule: Adopt Only When a Client Ships PHP Into the EU and Has No Security Owner
- Decision FrameworkPatchClock: Buy vs Skip (PHP Vendors Shipping Into the EU)
- Implementation BlueprintPatchClock CRA Compliance Retainer Build (7-10 days)
- Operating ProcedurePatchClock Client Release Onboarding (Delivery)
More for Compliance Workflows
- Failure PatternsThe Peko Free-Tier Trap: Why Agencies Fail to Convert Lint Runs Into Retainers
- Failure PatternsThe InfiniHash App Store Evidence Gap Trap: Why Agencies Fail With Compliance Retainers
- Failure PatternsThe Evidence Theater Trap: Why Compliance Workflows Stall After the First Audit
- Failure PatternsThe Framework Lock-In Trap: Why Compliance Workflows Collapse When the Vendor Changes the Rules