Product Security Hub started as a web application. You log in, manage your threat models, scan your SBOMs, triage vulnerabilities, document residual risks. Everything lives in one platform. That was the whole point.
But the more I used it for client work, the more I realized I was doing the same sequences of clicks over and over. Pull up a component. Check its requirements. Update three fields. Save. Move to the next one. The platform had all the right data. I just needed a faster way to work with it.
So we built a full REST API.
What That Actually Looks Like
I’ll walk you through what a real workday looks like now.
A client engineer tells me they’ve implemented a specific security control on one of their device components. Say they’ve added certificate pinning to their network communication module. That single change affects multiple records in PSH. The associated requirements need to be updated to reflect the control is now in place. The threat that this control mitigates might need its status updated. Any residual risk tied to that threat might need its scoring justification revised.
In the web app, that’s 15 minutes of clicking through records, finding the right fields, updating each one. Not hard, but repetitive.
With Claude Code and the API, I describe the change in plain English. Claude pulls the relevant component data from PSH, identifies which requirements, threats, and risks are affected, drafts the updates, and pushes them back through the API. Everything lands on the review screen in PSH where I check the changes and approve them.
The same work that took 15 minutes of clicking takes 2 minutes of conversation.
Import Templates Are the Secret
One of the things that makes this work so well is PSH’s import template system. Every record type in the platform has a standardized import template. Vulnerabilities, components, requirements, risks. You can pull the template down through the API, populate it with data, and import it back. The platform validates the data, shows you what’s going to be created or updated, and you approve the import.
This is the same workflow a user would follow manually. Download the Excel template, fill it in, upload it. The API just lets Claude Code do the filling.
When I need to load a new product into PSH for a client, I pull down the component import template, have Claude Code work through the client’s architecture documents and populate the template, then import it. What used to be a full afternoon of data entry becomes a 30 minute session where I’m reviewing and approving instead of typing.
Vulnerability Triage at Scale
This is where it gets really interesting. PSH has built in context aware AI for vulnerability triage. When new CVEs are found on an SBOM, the system can evaluate them against the product’s architecture, threats, and controls to determine actual exploitability.
But with the API, I can also do this externally. Claude Code pulls the product context from PSH (the threat model, trust boundaries, component relationships, design controls), analyzes the new CVEs against all of that context, and pushes triage results back to PSH’s review screen.
Why would I do it externally when PSH has built in triage? Flexibility. Sometimes I want to run a custom analysis that goes beyond the standard triage workflow. Maybe I want to compare vulnerability exposure across three different products at once. Maybe I want to generate a client briefing document alongside the triage. Maybe I want to chain multiple steps together in a way that the web UI doesn’t support.
The API means PSH is the system of record, but it’s not the only way to interact with the data. The platform handles governance, traceability, and audit trails. The API handles whatever custom workflow I need on top of that.
The Real Workflow
Here’s what my Monday morning actually looks like.
I open Claude Code. My clients’ products are in PSH. I ask Claude to pull the latest scan results across all active products. It hits the API, pulls new vulnerabilities, and gives me a summary. “Product A has 3 new CVEs since last week, all Low exploitability. Product B has 12 new CVEs, 2 are High. Product C is clean.”
I focus on Product B. Claude pulls the full context for that product and works through the 12 new CVEs. It drafts triage assessments with reasoning for each one. I review them, adjust the two I disagree with, and Claude pushes the results back to PSH through the import workflow.
Then a client emails me. Their engineering team updated a component and they need the SBOM and associated records updated. I have Claude pull the current SBOM data, make the changes, and push the update back. The client’s PSH workspace now reflects the current state of their product.
All of this happened in my terminal. I opened the PSH web app once, to spot check a couple of records. The rest was Claude Code and the API.
Why This Matters Beyond My Workflow
I’m a power user. Most PSH customers will use the web app and the built in AI and never touch the API. That’s fine. The platform is designed for that.
But the API changes what PSH is. It’s not just a web application. It’s a product security data platform that any tool can interact with. Today it’s Claude Code. Tomorrow it could be a customer’s internal automation, a CI/CD pipeline that triggers scans on every build, or a reporting tool that pulls compliance data for board presentations.
The key is that PSH remains the system of record. Every change, whether it comes through the web UI, the built in AI, or the API, goes through the same validation, the same review workflow, the same audit trail. The source doesn’t matter. The governance does.
What I’ve Learned
After months of working this way, a few things stand out.
The API doesn’t replace the web app. It extends it. There are plenty of tasks where clicking through the UI is faster than describing what I want to Claude. But for anything repetitive, anything that touches multiple records at once, or anything that benefits from pulling data across products, the API wins.
The import template pattern is underrated. Having a standardized format for every record type means any external tool (AI or otherwise) can interact with PSH without custom integration work. You don’t need to understand the internal data model. You just fill out the template and import.
The review screen is the governance layer. I never let Claude Code write directly to production data. Everything goes through the import review screen. I see exactly what’s going to change, approve it, and the audit trail shows that a human reviewed and accepted the changes. That matters for FDA submissions and audits.
Product security is moving toward platforms, not point tools. The companies building custom integrations between 5 different security tools are solving the right problem the hard way. A single platform with a real API gives you the same flexibility with a fraction of the integration work.
If you’re managing product security across multiple devices and spending hours on repetitive data management, there’s a better way. And it starts with treating your security platform as infrastructure you can build on, not just a web app you log into.