This page covers SITEY security from the vendor side. If you are evaluating us, the questions that matter are narrow: what do we hold, what crosses the network between your deployment and us, and how do we handle flaws in our own code. Answers below, without hedging.
Deployment model: your infrastructure, your data
SITEY is software you install and run yourself. You buy a license, download the installer, and deploy it inside your own environment. You roll out the agents to your own hosts. We do not provision servers for you, we do not connect to your network, and there is no remote access path from us into a customer deployment: no support tunnel, no jump host, no vendor-held credential.
The consequence is the important part. Your asset inventory, scan results, vulnerability findings, remediation plans, task history, agent telemetry and the platform database stay on your servers. We cannot hand them to a third party, lose them in a breach, or expose them through a misconfiguration, because we never receive them.
What we hold
Three categories, all commercial rather than security data.
| Data | Why we hold it |
|---|---|
| Account: name, work email, company name, password hash | Authentication to the customer portal, which gates license keys and downloads |
| License: key, plan, activation timestamps, machine fingerprint, hostname, product version | Proving a deployment is entitled to run and enforcing instance limits |
| Billing: Stripe customer and subscription IDs, invoices, card brand and last four digits as returned by Stripe | Subscription management, invoicing, and statutory accounting records |
Plus whatever you write to us in a support email. For this data we act as the data controller; we are not a processor of your security data, because none of it reaches us.
Payment security
Checkout runs on Stripe, a PCI DSS Level 1 service provider. Card number, expiry and CVC are entered on Stripe’s infrastructure and never touch ours. We do not see, store, log or transmit a primary account number, and we cannot: our systems only ever receive Stripe’s tokens and identifiers. Both plans on the pricing page use the same flow, whether you pay $599 monthly or $5,999 once.
The license activation channel
This is the only channel between your deployment and us. It is an outbound HTTPS call from your server to our license service. Nothing is initiated from our side.
| Field sent | Purpose |
|---|---|
| License key | Identifies the entitlement |
| Machine fingerprint (a one-way hash of stable machine attributes) | Binds a license to an instance so one key cannot run unlimited deployments. It is not reversible and describes nothing about the hosts you scan. |
| Hostname and product version | Lets you and us distinguish your own activations during hardware rotation or a support ticket, and determines update eligibility |
Not sent: scan targets, IP ranges, hostnames of scanned assets, findings, CVE counts, severity totals, credentials, user accounts from your deployment, agent output, or any database content. Detection content and the remediation knowledge base ship inside the release as a build-time bundle, so the platform produces remediation plans with no runtime internet access. One hostname on your egress allowlist is enough.
Software integrity
Releases are published with a SHA-256 checksum for every installer and agent package, and the installers are code-signed. Verify the checksum before you install; if it does not match what the download page states, do not run it and tell us. Downloads require an authenticated account tied to a license. Updates are initiated from your own console. We do not push code into your environment.
Vulnerabilities in our own product
We run SITEY against SITEY. Our build pipeline scans our own source, dependencies and containers with engines shipped in the product, and the findings go through the same eight-phase workflow customers use. Security-relevant fixes ship as patch releases rather than waiting for a feature train. Release notes state affected versions and severity so you can decide how quickly to roll out. A dependency inventory for any release is available on request.
Responsible disclosure
If you find a flaw in our website, our license service, or the SITEY software, email security@siteyvm.com. Include the affected component and version, reproduction steps, and the impact you believe it has. We acknowledge within three business days and give you an assessment within ten.
We will not pursue legal action against good-faith research, and we will not report you to your employer or hosting provider, provided you:
- test only against your own SITEY installation or our public website;
- do not run denial-of-service, load or physical testing, and do not attempt social engineering of our staff or customers;
- stop immediately and tell us if you reach data that is not yours, and do not copy, retain or share it;
- give us a reasonable window to ship a fix before publishing.
We credit researchers who want credit. We do not currently pay bounties, and we would rather say so than imply otherwise.
What we do not claim
We are not ISO 27001, SOC 2 or PCI DSS certified. SITEY maps findings and controls to ISO 27001, PCI DSS, SOC 2, GDPR, KVKK and BDDK so you can evidence your own compliance work. That is a product capability, not a certificate we hold, and anyone telling you otherwise is misreading our features page. We also publish no customer logos, testimonials or uptime figures we cannot substantiate.
Contact
Vulnerability reports: security@siteyvm.com. Everything else, including security questionnaires and data protection requests: info@siteyvm.com or the contact page. We answer questionnaires, though expect many items to be marked not applicable: they assume a hosted service, and SITEY is not one.
Outbound connections: exactly what leaves your network
SITEY runs on your own server and stores every finding, asset record and report in your own
database. Some features do reach outside your network, and you should know precisely which.
| Destination | When | What is sent | Optional |
|---|---|---|---|
| siteyvm.com | Licence activation and periodic re-validation | Licence key, a hashed machine fingerprint, hostname | No, required |
| Your configured AI provider (for example api.openai.com) | Only when AI triage, remediation or the assistant is enabled | Finding details needed for the analysis you requested | Yes, disabled until you add a key |
| services.nvd.nist.gov | CVE enrichment | CVE identifiers | Yes |
| api.msrc.microsoft.com and catalog.update.microsoft.com | Windows patch lookup and download | Product and KB identifiers | Yes, used by patch management |
| www.cisa.gov | Known Exploited Vulnerabilities catalogue | Nothing identifying, a catalogue download | Yes |
The AI provider is the one to think carefully about. If you enable AI triage or
remediation, the finding details required for that analysis are sent to the provider whose API key
you configured. That is your own account with that provider, under your own agreement with them,
not a SITEY-operated service. If your environment cannot allow this, leave the AI features
disabled and the platform runs without them.
If you need a fully isolated deployment, tell us before you buy and we will confirm which
features remain available.