Integrations, and where we fit

Every enterprise we talk to already owns tools that overlap with part of what we do. A CMDB knows what servers exist. A scanner knows which of them are unpatched. A certificate manager knows what expires next month. None of them can tell you which of your cryptographic dependencies fails against a quantum adversary, or in what order to fix them. That gap is the whole product, and being precise about its edges is more useful than claiming to replace anything.

#The neighbours

Read the last column first. What we decline to duplicate is a more honest description of a product than what it claims to cover.

#The two directions data moves

Almost every integration is one of two shapes, and knowing which one you are building keeps the scope small.

Inbound context

You tell us what your estate is. Host lists, service ownership, environment labels, criticality ratings from your CMDB. This is what turns a finding from 'a weak cipher on 10.4.2.19' into 'a weak cipher on the settlement gateway, owned by the payments platform team, in production'. Ownership metadata improves prioritisation more than any additional detector.

Outbound findings

We tell your systems what we found. Findings to a ticketing queue, events to an SIEM, a CBOM to an architecture review, a signed export to an auditor. This is where the value is realised, because a finding nobody is assigned is a finding nobody fixes.

There is no third direction. We do not push configuration changes into your infrastructure, and we will not. A tool that can both find a weak cipher and silently change it is a tool whose blast radius nobody has modelled.

#What a realistic first integration looks like

Not an API build. The first integration on almost every engagement is a scheduled export into somewhere people already look, and it delivers most of the value of a deep integration for a fraction of the work.

1. 1

   Get ownership metadata in

   A flat file mapping hosts and services to owning teams, environments and criticality. Imperfect and current beats complete and stale. This single input changes prioritisation more than anything else you can send us.

2. 2

   Export findings on a schedule

   A periodic export of open findings with severity, owner and explanation, landing in the tracker your remediation teams already work from. No new console for anyone to learn.

3. 3

   Route the small number of urgent events

   One webhook, one router, three rules. Critical to on-call, high to the owning team, the rest to the weekly digest. See Where alerts land.

4. 4

   Only then automate the loop

   Once the manual path has run for a few cycles and you know which fields matter, replace the schedule with a programmatic pull. By then you are automating something you understand rather than guessing at a schema.

#Reconciling with an existing inventory

The most common integration question is what happens when our inventory and yours disagree. They will. Reconciliation is a project in its own right and worth planning for rather than discovering.

• We find things your register does not list. This is the usual case and it is the point. Undocumented services, forgotten test endpoints, embedded libraries nobody owns. Treat the delta as a finding about your register, not an error in ours.
• Your register lists things we cannot reach. Also common, and always worth investigating, because an unreachable asset is an unassessed asset. The boundaries are in What discovery will not do.
• Identity mismatch. The same asset appears under a hostname in your register and an address in ours. Agree a join key early — usually a stable service identifier rather than an address.
• Neither system is authoritative for both halves. Your register owns existence and ownership. We own the cryptographic facts. Resist the temptation to make one the master of everything.

What counts as an asset on our side, and how we identify one across runs, is defined in What counts as an asset. Read it before designing a join key.

#Choosing not to integrate

A defensible answer for a first engagement is to integrate nothing. Take the exposure report, work the top tier by hand, and prove the process before wiring it into anything. Integration multiplies a working process; it does not create one.

Our pilot estate makes the case for why the process is worth having before the plumbing: 42 assets discovered, 36 classified vulnerable, an aggregate score of 75 / 100, and a review that took 22 hours manually against 14 minutes with AutoPQC. None of that required an integration. It required knowing what to look for and in what order.